第六章 HTTP/2 (Hypertext Transfer Protocol Version 2)

一、导读

1.1 本章学习目标

理解 HTTP/2 的设计目标和核心特性：二进制分帧、多路复用、头部压缩、服务器推送和流优先级

掌握 HTTP/2 的二进制分帧层（Binary Framing Layer）的工作原理

深入理解 HTTP/2 多路复用如何消除 HTTP/1.x 的连接级队头阻塞

掌握 HPACK 头部压缩算法的设计原理和静态表/动态表机制

理解 HTTP/2 流优先级和依赖关系的工作方式及其对资源加载的影响

了解 HTTP/2 服务器推送的机制、使用场景和潜在问题

掌握 HTTP/2 的流量控制和连接管理

能够分析 HTTP/2 对 Web 性能的具体影响，并制定相应的优化策略

1.2 为什么本章如此重要

HTTP/2 是 Web 协议发展史上最重要的升级之一。它从根本上改变了浏览器和服务器之间的通信方式，解决了 HTTP/1.x 长期存在的多个性能瓶颈。自 2015 年发布以来，HTTP/2 的采用率持续增长，目前已被超过 90% 的顶级网站支持。

HTTP/2 的核心创新是二进制分帧层——它将 HTTP 请求和响应分解为更小的二进制帧，不同消息的帧可以在同一个 TCP 连接上交错传输。这意味着多个请求和响应可以真正并行处理，不再受队头阻塞的限制。对于包含大量资源的现代 Web 页面，这一改进带来了显著的性能提升。

HPACK 头部压缩是 HTTP/2 的另一项重要创新。HTTP/1.x 中，每个请求都携带大量重复的头部信息（如 User-Agent、Accept 等），在移动网络等低带宽环境中，头部开销可能占总传输量的 30% 以上。HPACK 通过维护静态表和动态表来消除重复头部，将头部压缩到原来的几十分之一。

理解 HTTP/2 的工作原理对于现代 Web 性能优化至关重要。许多为 HTTP/1.x 设计的优化策略（如域名分片、资源合并、内联资源）在 HTTP/2 环境下不仅无效，反而可能有害。开发者需要重新思考资源组织方式，充分利用 HTTP/2 的多路复用和流优先级特性。

1.3 核心问题引导

HTTP/2 的二进制分帧层是如何工作的？帧有哪些类型？

HTTP/2 的多路复用如何消除 HTTP/1.x 的队头阻塞？TCP 层的队头阻塞是否也被消除了？

HPACK 的静态表和动态表分别存储什么内容？它们如何协同工作实现头部压缩？

HTTP/2 的流优先级和依赖关系如何影响资源加载顺序？

HTTP/2 的服务器推送解决了什么问题？它有什么局限性和潜在风险？

从 HTTP/1.1 迁移到 HTTP/2 后，哪些之前的优化策略需要调整？

HTTP/2 的流量控制机制是如何工作的？它与 TCP 的流量控制有什么区别？

HTTP/2 相比 HTTP/1.x 在性能上有哪些具体提升？在什么场景下提升最明显？

二、核心概念详解

2.1 二进制分帧层

HTTP/2 引入了二进制分帧层（Binary Framing Layer），这是 HTTP/2 与 HTTP/1.x 最根本的区别。HTTP/1.x 是文本协议——请求和响应以纯文本格式传输，每行以 CRLF 结尾。HTTP/2 是二进制协议——所有通信都被分解为二进制帧，帧的解析更高效且不容易出错。

HTTP/2 定义了两种基本帧类型：数据帧（DATA frames，携带请求或响应的有效载荷）和控制帧（包括 HEADERS、SETTINGS、WINDOW_UPDATE、PING、GOAWAY 等）。每个帧包含 9 字节的帧头：3 字节的长度、1 字节的类型、1 字节的标志和 4 字节的流标识符。

流（Stream）是 HTTP/2 中的核心概念。每个流是 TCP 连接内的一个双向字节流，拥有唯一的 31 位标识符。一个 HTTP 请求-响应对对应一个流。多个流可以在同一个 TCP 连接上并行传输，帧可以交错发送——这就是多路复用的基础。

连接（Connection）对应一个 TCP 连接。HTTP/2 中，一个域名只需要一个连接（而非 HTTP/1.x 的多个连接），所有请求都通过这一个连接的多路复用来传输。这大幅减少了连接建立的开销（DNS、TCP、TLS），也提高了拥塞控制的效率。

2.2 多路复用与流管理

HTTP/2 的多路复用是其最重要的性能特性。在 HTTP/1.x 中，即使使用持久连接，响应也必须按请求顺序返回（队头阻塞）。HTTP/2 通过将请求和响应分解为独立的帧，允许不同流的帧在同一个 TCP 连接上交错传输。

流的生命周期包括几个状态：idle（空闲，流已创建但未发送任何帧）、open（打开，双方都可以发送帧）、half-closed（半关闭，一方已发送完数据）、closed（关闭）。流的创建通过发送 HEADERS 帧开始，通过发送带有 END_STREAM 标志的帧结束。

流优先级允许客户端告知服务器哪些流更重要。每个流可以指定一个权重（1-256）和一个依赖关系（依赖于另一个流）。服务器根据这些信息决定帧的发送顺序。例如，HTML 文档的流优先级最高，CSS 和关键 JavaScript 次之，图片和非关键资源最低。

然而，HTTP/2 的多路复用只解决了应用层的队头阻塞。底层的 TCP 层仍然存在队头阻塞——如果 TCP 报文段丢失，整个连接上的所有流都会被阻塞，直到丢失的报文段被重传。这个问题直到 HTTP/3 使用基于 UDP 的 QUIC 才得以解决。

2.3 HPACK 头部压缩

HPACK（HPACK: Header Compression for HTTP/2）是专门为 HTTP/2 设计的头部压缩算法。HTTP 头部有两个显著特征：不同请求之间有大量重复的头部字段（如 User-Agent、Accept），且头部通常以明文传输（不能被 Gzip 压缩，因为 Gzip 在应用层而头部在 HTTP 层）。

HPACK 使用两个表来压缩头部：静态表（Static Table）包含 61 个预定义的常见头部字段（如 :method: GET、:status: 200、content-type 等），通信双方无需协商即可使用；动态表（Dynamic Table）在通信过程中动态维护，记录已经传输过的头部字段，后续相同的头部只需发送索引号。

HPACK 的编码方式包括：完整头部（新头部，不在任何表中）、索引头部（引用静态表或动态表中的条目）、增量更新（向动态表添加新条目）、动态表大小更新。对于典型的 HTTP 响应，HPACK 可以将头部大小从数百字节压缩到几个字节。

HPACK 还考虑了安全性。它使用了霍夫曼编码（Huffman Coding）来压缩头部值，同时避免了 CRIME/BREACH 等压缩侧信道攻击——HPACK 的压缩状态不暴露给应用层，攻击者无法通过观察压缩后的大小来推断加密数据的内容。

2.4 服务器推送

HTTP/2 的服务器推送（Server Push）允许服务器在客户端请求之前主动发送资源。当服务器知道客户端在请求某个资源后还需要其他关联资源时，可以提前推送这些资源，减少客户端的请求-响应往返。

服务器推送通过 PUSH_PROMISE 帧实现。服务器发送 PUSH_PROMISE 帧告知客户端"我即将推送一个资源"（包含该资源的请求头信息），然后发送 HEADERS 和 DATA 帧推送实际数据。客户端收到后可以：接受推送并缓存资源；如果已经有该资源的缓存，发送 RST_STREAM 帧取消推送；或者如果策略不允许推送，禁用推送功能。

服务器推送的典型应用场景：HTML 文档请求时推送关键的 CSS 和 JavaScript 文件；CSS 文件请求时推送引用的字体和图片；API 响应时推送关联的预取数据。

然而，服务器推送在实践中面临多个挑战：服务器难以准确预测客户端需要哪些资源（可能推送客户端已缓存的资源，浪费带宽）；推送的资源占用连接带宽，可能延迟其他关键资源的传输；过多的推送可能导致网络拥塞。因此，现代 Web 开发中，服务器推送的使用趋于保守，<link rel="preload"> 通常被认为是更可控的替代方案。

2.5 HTTP/2 流量控制

HTTP/2 的流量控制机制与 TCP 的流量控制是两个独立的层次。TCP 流量控制基于接收窗口（rwnd），控制的是 TCP 层面的字节流。HTTP/2 流量控制基于 WINDOW_UPDATE 帧，控制的是每个流和整个连接的发送速率。

HTTP/2 流量控制的粒度更细：可以针对单个流进行流量控制（如限制某个低优先级流的发送速率），也可以针对整个连接进行流量控制（如限制连接的总发送速率）。初始窗口大小为 65535 字节，可以通过 WINDOW_UPDATE 帧动态调整。

HTTP/2 流量控制的主要目的是防止发送方以超过接收方处理能力的速率发送数据，以及防止某个流占用过多连接资源。与 TCP 流量控制不同，HTTP/2 流量控制是逐跳的（Hop-by-Hop），只作用于直接相连的两端，不穿过中间代理。

三、深入分析与讨论

3.1 HTTP/2 对 Web 性能优化策略的影响

HTTP/2 的引入需要重新审视许多 HTTP/1.x 时代的性能优化策略。域名分片（Domain Sharding）在 HTTP/2 中应该被移除——HTTP/2 的单连接多路复用使得多个域名不仅不必要，反而有害。每个额外的域名都需要独立的 DNS 查询、TCP 连接和 TLS 握手，而且多个 TCP 连接之间的拥塞控制是独立的，可能导致网络资源的不公平分配。

资源合并（Concatenation）在 HTTP/2 中应该被谨慎使用。HTTP/1.x 中，合并多个 JavaScript 文件为一个可以减少请求数量。但在 HTTP/2 中，多个小文件可以通过多路复用并行传输，合并反而降低了缓存效率——修改一个文件就需要使整个合并文件的缓存失效。

资源内联（Inlining）同样需要重新评估。将 CSS 内联到 HTML 中在 HTTP/1.x 中可以减少一个请求，但在 HTTP/2 中，CSS 文件可以通过多路复用与 HTML 并行传输，而且独立的 CSS 文件可以被多个页面共享缓存。

取而代之的新优化策略包括：使用流优先级指导服务器优先发送关键资源；使用 <link rel="preload"> 提前声明关键资源；谨慎使用服务器推送预加载首屏关键资源；保持资源的细粒度拆分以提高缓存命中率。

3.2 TCP 队头阻塞对 HTTP/2 的影响

HTTP/2 的多路复用在应用层消除了队头阻塞，但底层的 TCP 层仍然存在队头阻塞。当 TCP 报文段丢失时，TCP 必须等待丢失的报文段被重传后才能将后续数据递交给应用层。由于 HTTP/2 的所有流共享同一个 TCP 连接，TCP 层的丢包会阻塞所有流。

这种影响在有损网络环境中尤为严重。研究表明，在 2% 丢包率的 WiFi 网络中，HTTP/2 的页面加载性能可能比 HTTP/1.x（使用 6 个并发连接）更差。原因是 HTTP/1.x 使用多个独立的 TCP 连接，一个连接的丢包只影响该连接上的请求；而 HTTP/2 的单连接设计意味着一个丢包会影响所有流。

这个问题是 HTTP/3 选择 QUIC（基于 UDP）的核心动机。QUIC 为每个流实现了独立的丢包恢复，一个流的丢包不会阻塞其他流。在 HTTP/3 中，HTTP/2 的 TCP 层队头阻塞问题被彻底解决。

3.3 HTTP/2 的部署实践与调优

在生产环境中部署 HTTP/2 需要考虑多个方面。服务器配置方面：大多数现代 Web 服务器（Nginx、Apache、Caddy）都支持 HTTP/2，通常只需简单的配置更改。HTTP/2 在浏览器中强制要求 HTTPS（TLS），因此需要先完成 TLS 配置。

连接管理调优：HTTP/2 的连接初始窗口大小（65535 字节）可能不够大，对于高带宽连接，应通过 SETTINGS 帧增大窗口大小以避免流控瓶颈。服务器的 SETTINGS_MAX_CONCURRENT_STREAMS 参数控制每个连接允许的最大并发流数，应根据服务器处理能力合理设置。

推送策略调优：如果使用服务器推送，应谨慎选择推送的资源——只推送确定客户端需要且未缓存的关键资源。监控推送资源的使用率（通过 X-Firefox-Spdy 或自定义头部），避免无效推送。考虑使用"Cache-Digest"或"Cacheability"头部让客户端告知服务器自己的缓存状态。

四、实践案例

4.1 案例一：HTTP/1.1 到 HTTP/2 的迁移与性能对比

一个内容丰富的新闻网站从 HTTP/1.1 迁移到 HTTP/2。迁移前，网站使用 4 个域名分片、CSS/JS 文件合并和关键 CSS 内联等 HTTP/1.1 优化策略。页面包含约 80 个资源，总大小约 3MB。

迁移后，移除了域名分片（合并为单一域名）、取消了资源合并（保持细粒度拆分以提高缓存效率）、移除了 CSS 内联（使用 preload 替代）。

HTTP/1.1 与 HTTP/2 性能对比：

性能提升主要来源于：消除了多个域名的连接建立开销、多路复用消除了队头阻塞、HPACK 减少了头部传输量。

4.2 案例二：HTTP/2 流优先级的优化实践

一个电商网站发现其首屏渲染时间不够理想。分析发现，浏览器虽然正确设置了流优先级，但服务器没有按照优先级顺序发送数据——非关键的第三方脚本和首屏图片在同一时间竞争带宽。

优化方案：在 Nginx 中配置了基于资源类型的流优先级策略——HTML 文档最高优先级、CSS 和关键 JavaScript 次之、首屏图片第三、非关键资源最低。同时使用 <link rel="preload"> 明确声明关键资源。

优化效果：

五、常见误区与注意事项

误区：HTTP/2 消除了所有队头阻塞。 HTTP/2 只消除了应用层的队头阻塞，TCP 层的队头阻塞仍然存在。在有损网络中，TCP 丢包会阻塞 HTTP/2 的所有流。只有 HTTP/3（QUIC）才能彻底解决这个问题。

误区：HTTP/2 中域名分片仍然有用。 域名分片在 HTTP/2 中不仅无用，反而有害。多个域名意味着多个 TCP 连接，每个连接独立进行拥塞控制，可能导致网络资源的不公平分配。HTTP/2 的单连接多路复用已经解决了并发问题。

误区：服务器推送总是能提升性能。 服务器推送如果推送了客户端已缓存的资源，就是浪费带宽。推送过多资源还会占用连接带宽，延迟其他关键资源的传输。应谨慎使用推送，只推送确定需要且未缓存的关键资源。

注意事项：HTTP/2 要求 HTTPS。 所有主流浏览器只在 HTTPS 连接上支持 HTTP/2。这意味着迁移到 HTTP/2 的前提是完成 TLS 配置。好消息是 TLS 1.3 的 1-RTT 握手大幅减少了加密的性能开销。

注意事项：HTTP/2 的连接复用需要合理管理。 虽然 HTTP/2 推荐使用单连接，但在某些场景下（如 CDN 和源站之间的回源连接），使用少量并行连接可能更高效，因为可以利用多个 TCP 连接的拥塞窗口。

六、本章小结

本章全面介绍了 HTTP/2 协议的核心特性及其对 Web 性能的影响。HTTP/2 通过二进制分帧层实现了高效的数据传输，通过多路复用消除了应用层的队头阻塞，通过 HPACK 压缩了冗余的头部信息，通过服务器推送减少了请求往返。

核心要点包括：HTTP/2 的二进制分帧层将所有通信分解为帧，不同流的帧可以交错传输；多路复用允许在单个连接上并行传输多个请求-响应，但 TCP 层的队头阻塞仍然存在；HPACK 通过静态表和动态表高效压缩头部；流优先级指导服务器优先传输关键资源；服务器推送可以提前发送关联资源但需谨慎使用。

HTTP/2 的引入要求开发者重新审视 HTTP/1.x 时代的优化策略——域名分片、资源合并和内联资源在 HTTP/2 环境下可能适得其反。理解 HTTP/2 的工作原理是进行现代 Web 性能优化的基础。

七、思考题与练习

描述 HTTP/2 二进制分帧层的结构，列举主要的帧类型及其作用。

解释 HTTP/2 多路复用的工作原理，以及它如何消除 HTTP/1.x 的应用层队头阻塞。

HPACK 的静态表和动态表分别包含什么内容？为什么 HPACK 不使用通用的压缩算法（如 Gzip）？

分析 TCP 队头阻塞对 HTTP/2 性能的影响，以及为什么这个问题在 HTTP/3 中得到了解决。

设计一个 HTTP/2 服务器推送策略，说明应该推送哪些资源、不应该推送哪些资源，以及原因。

列举至少五个从 HTTP/1.1 迁移到 HTTP/2 后需要调整的优化策略，并解释调整的原因。

比较 HTTP/2 的流量控制和 TCP 的流量控制的区别，解释为什么需要两层流量控制。

使用浏览器开发者工具分析一个 HTTP/2 网站的帧传输情况，观察多路复用和流优先级的实际效果。