课程笔记：HTTP/2 新特性——服务器推送（Server Push）

课程名称：计算机网络应用 核心摘要：本讲为 HTTP/2 系列的收尾课，重点讲解服务器推送（Server Push）的原理与 PUSH_PROMISE 帧的工作机制；并通过对比 HTTP/1.1 与 HTTP/2 的加载性能，引出 HTTP/2 的性能瓶颈在 TCP 层，进而预告 HTTP/3（基于 UDP + QUIC）的演进方向；最后指出 HTTP 协议默认不安全，面临窃听、冒充、篡改三大风险，为下一讲 HTTPS 做铺垫。

一、 核心概念与原理

1.1 服务器推送（Server Push）定义

• 服务器推送是 HTTP/2 的重要新特性之一，指服务器可以在客户端仅发起一个请求的情况下，主动向客户端推送多个响应资源。
• 客户端只需请求一个页面（如 index.html），服务器在返回该页面的同时，主动推送页面中引用的 CSS、JS、图片等静态资源，无需客户端再逐个发请求。
• 推送的资源可被缓存：在遵循同源策略的前提下，不同页面之间可以共享缓存，这是服务器推送的一大优势。

1.2 解决的核心问题

1.3 HTTP/2 性能直观对比（演示实验）

通过一张由 N 张小图片拼接而成的大图加载实验：

主流大站（如 Google、拉勾网）已普遍采用 HTTP/2；百度主站仍用 HTTP/1.1，但其部分图片资源已切到 HTTP/2。

二、 技术细节与协议分析

2.1 服务器推送的工作流程（基于二进制分帧）

HTTP/2 的最小通信单位是帧（Frame），每个帧属于一个流（Stream）。服务器推送依赖一种特殊的帧类型实现：

推送流程步骤

1. 客户端发起请求：客户端请求 index.html，使用一个奇数的 Stream ID（如 Stream 1）。
2. 服务器决定推送：服务器识别到该页面还引用了 CSS、JS 等资源，决定主动推送。
3. 服务器发送 PUSH_PROMISE 帧：
   • 该帧的 Type = PUSH_PROMISE（既不是 HEADERS 也不是 DATA）。
   • 帧中携带一个新建的 Stream ID（偶数，如 Stream 2、Stream 4）。
   • 该 Stream ID 由服务端创建，用于后续推送数据。
4. 客户端解析帧：客户端发现收到的是 PUSH_PROMISE 类型帧，准备接收该 Stream ID 对应的推送数据。
5. 服务器推送资源：服务器通过约定好的 Stream ID 发送一个又一个帧（HEADERS 帧 + DATA 帧）。
6. 客户端匹配接收：客户端依据帧中的 Stream ID 判断这些数据是服务端推送过来的资源，进行接收与处理。

2.2 关键帧与流的关系

原则：服务器推送必须基于客户端已有的请求来触发，不能凭空推送；推送前必须先发 PUSH_PROMISE 帧进行预告。

2.3 HTTP/2 性能瓶颈：TCP 层

HTTP/2 在应用层已做尽优化（二进制分帧、头部压缩、多路复用、服务器推送），再想提升性能就要改 TCP 协议本身。TCP 层的主要问题：

2.4 HTTP/3 演进预览

HTTP/2 与 HTTP/3 默认均不自带安全层，需要额外安装证书启用 HTTPS。拉勾网等站点使用 HTTP/2 + HTTPS（浏览器地址栏左侧锁标志）。

三、 实践应用与配置命令

3.1 浏览器开发者工具验证协议版本

在 Chrome 中打开网站 → 按 F12 打开 DevTools → 切换到 Network 面板 → 查看 Protocol 列：

h2     -> HTTP/2
http/1.1 -> HTTP/1.1
quic/  -> HTTP/3 (基于 QUIC)

3.2 服务器推送配置示例（Nginx）

# 开启 HTTP/2 服务器推送（Nginx 1.13.9+）
server {
    listen 443 ssl http2;
    server_name example.com;

    # 主动推送 index.html 引用的 CSS/JS
    location = /index.html {
        http2_push /style.css;
        http2_push /main.js;
    }

    # 或使用 Link 头自动推送
    # add_header Link "</style.css>; as=style; rel=preload, </main.js>; as=script; rel=preload";
}

说明：http2_push 指令用于显式声明推送资源；也可通过响应头 Link: <...>; rel=preload 让 Nginx 自动识别并推送。

四、 重点与难点提示

• 考点 1：服务器推送的核心机制——PUSH_PROMISE 帧的作用是"预告"推送所用的 Stream ID，必须先于推送数据发送。
• 考点 2：Stream ID 的奇偶规则——客户端发起用奇数，服务端推送用偶数，且由服务端创建。
• 考点 3：服务器推送基于客户端已有请求触发，不能无请求主动推送；遵循同源策略且可缓存、跨页面共享。
• 易错点：HTTP/2 的多路复用在应用层解决了 HTTP 层队头阻塞，但TCP 层的队头阻塞依然存在（一个包丢失阻塞整条连接）。
• 面试题：为什么有了 HTTP/2 还要 HTTP/3？——答：HTTP/2 性能瓶颈下沉到 TCP 层（慢启动、TCP 队头阻塞），HTTP/3 改用 UDP + QUIC 彻底规避 TCP 问题。
• 面试题：HPACK 与 QPACK 的区别？——分别用于 HTTP/2 与 HTTP/3 的头部压缩算法。
• 版本命名细节：官方称 HTTP/2 而非 HTTP/2.0，因为该版本没有子版本，下一个版本直接是 HTTP/3。

五、 课后疑问/遗留问题

1. 思考题：既然服务器推送能减少请求，为什么不是所有场景都启用？是否存在推送冗余资源反而浪费带宽的情况？（提示：客户端可能已缓存该资源）
2. 后续课程预告：HTTP/1.1、HTTP/2 默认均不安全（未开启安全连接），面临三大风险：
   • 窃听风险：数据明文传输，可被监听。
   • 冒充风险：服务端无法自证身份，黑客可伪装服务端骗取用户敏感信息。
   • 篡改风险：无报文完整性校验，中间代理可篡改明文数据。
3. 下一讲主题：开始讲解 HTTPS 协议——其安全措施引入了哪些算法、如何保证机密性/身份认证/完整性，以及如何将自己的 Web 应用从 HTTP 升级到 HTTPS（安装证书）。