HTTP/2 与 HTTP/3 核心改进详解

HTTP 协议是现代互联网的基石。从 1991 年的 HTTP/0.9 到 1999 年广泛使用的 HTTP/1.1，Web 发生了翻天覆地的变化。然而，HTTP/1.1 的许多设计逐渐成为性能瓶颈。HTTP/2 和 HTTP/3 正是为了解决这些问题而生，它们从根本上改进了数据传输方式，大幅提升了网页加载速度和用户体验。

本教程将深入浅出地介绍 HTTP/2 和 HTTP/3 的核心改进，帮助你理解它们为何更快、更高效。

HTTP/1.1 的时代局限

在进入改进之前，我们需要了解 HTTP/1.1 面临的主要性能问题：

1. 队头阻塞（Head-of-Line Blocking，HOL）：HTTP/1.1 基于请求-响应模型，在同一个 TCP 连接上，一个请求的响应必须按顺序返回。如果第一个请求的响应因为某种原因延迟了（如服务器处理慢），后续所有请求的响应都会被迫等待，即使它们早已准备就绪。浏览器通常通过开启多个并行 TCP 连接（通常 6~8 个）来缓解，但这并不能从根本上解决问题，且连接数过多会消耗大量资源。
2. 臃肿的头部（Uncompressed Headers）：每次请求都会携带大量重复的元数据（如 Cookie、User-Agent、Accept 等），这些头部信息从未被压缩，导致大量冗余数据传输。尤其在移动网络下，这种开销更为显著。
3. 文本协议效率低：HTTP/1.1 是一种纯文本协议，解析复杂、容易出错，且无法充分利用现代硬件的并行处理能力。

HTTP/2：基于二进制分帧的革新

HTTP/2 于 2015 年正式发布（RFC 7540），它并没有改变 HTTP 的语义（方法、状态码、头部字段等与 HTTP/1.1 一致），但大幅修改了传输方式。其核心目标是提升性能、降低延迟。

二进制分帧层

这是 HTTP/2 所有性能优化的基石。HTTP/2 不再使用文本格式，而是在 TCP 连接和应用层之间引入了一个二进制分帧层。这个层将传输的信息分割为更小的帧（Frame），并对它们进行二进制编码。

• 帧：是 HTTP/2 的最小通信单位。每种类型的帧都有特定的用途，如 HEADERS 帧用于传输 HTTP 头部，DATA 帧用于传输消息体。
• 流（Stream）：一个 TCP 连接上可以同时存在多个虚拟的流。每个流是一个独立的、双向的、有序的帧序列，用于承载一个请求-响应对。客户端发起的流具有奇数的流 ID，服务器推送的流具有偶数的流 ID。
• 消息（Message）：一个完整的 HTTP 请求或响应，由一个或多个帧组成。

这种分帧结构允许在同一 TCP 连接上，多个流的帧可以交错传输，并在接收端根据帧头中的流 ID 重新组装。这直接催生了多路复用。

多路复用（Multiplexing）

基于二进制分帧，HTTP/2 真正实现了完全的多路复用。客户端和服务器可以将多个 HTTP 请求/响应分解为独立的帧，交错地发送在同一个 TCP 连接上，接收方再根据流 ID 重新组装。这彻底解决了 HTTP/1.1 的队头阻塞问题（仅在应用层）。

关键优势：

• 单连接并行：浏览器只需与服务器建立一个 TCP 连接，就能并行下载所有资源（CSS、JS、图片等），极大减少了连接建立的开销和资源消耗。
• 优先级控制：HTTP/2 允许为每个流设置优先级和依赖关系。服务器可以根据优先级决定先发送哪些帧，确保关键资源（如 HTML、关键 CSS）优先到达。虽然实际实现中优先级可能很复杂，但提供了理论上的优化可能。

注意：HTTP/2 解决了应用层的队头阻塞，但底层 TCP 协议也存在队头阻塞。如果某个 TCP 包丢失，TCP 会要求重传，并阻塞后续所有包的交付，直到丢失包被修复。此时，HTTP/2 的所有多路复用流都会因此卡住。这是 HTTP/2 无法解决的隐患，也是 HTTP/3 出现的重要原因。

头部压缩（HPACK）

HTTP/2 使用 HPACK 算法对请求和响应头部进行压缩，大幅减少了冗余数据的传输。

HPACK 的核心原理：

1. 索引表：客户端和服务器各自维护一份静态表和动态表（合称索引表）。
   • 静态表：包含 61 个常见头部字段及其常见值的预定义条目（如 :method: GET）。
   • 动态表：在连接期间动态构建，将已经传输过的头部键值对缓存起来。
2. 编码表示：
   • 对于索引表中已存在的完整头部，只需发送对应的索引号（一个整数）。
   • 对于表中存在键但值不同，或需要添加到动态表的新头部，使用哈夫曼编码（一种高效的无损压缩算法）对原始字符串进行压缩后传输。
3. 安全性：HPACK 在动态表更新和哈夫曼编码时采用了特殊设计，避免压缩导致的安全攻击（如 CRIME 攻击）。

通过 HPACK，常见的 User-Agent、Cookie 等冗长且重复的头部在后续请求中可能只需几个字节，显著节省带宽。

服务器推送（Server Push）

服务器推送允许服务器在客户端明确请求之前，主动将客户端可能需要的资源“推送”给客户端。例如，当客户端请求一个 HTML 页面时，服务器可以分析出页面所需的 CSS 和 JS 文件，并在发送 HTML 的同时将这些资源推送给客户端。客户端可以将推送的资源缓存起来，当解析器需要它们时，直接使用缓存，无需再次请求。

推送流程：

1. 客户端发送请求，创建一个流（如流 1）。
2. 服务器响应 HTML 的同时，开启一个由偶数流 ID（如流 2）发起的 PUSH_PROMISE 帧。这个帧包含即将推送资源的头部信息（如 :path: /style.css）。
3. 客户端收到 PUSH_PROMISE 后，可以决定接受或拒绝（通过 RST_STREAM 帧）。如果接受，客户端会等待流 2 上的 DATA 帧。
4. 服务器开始发送推送资源的数据帧。

局限性：服务器推送在实践中可能造成资源浪费（推送浏览器已缓存的资源），且配置复杂。因此，其使用并未像预期那样普及，部分浏览器甚至已考虑移除它。但它依然展示了 HTTP/2 在减少往返次数上的设计思路。

HTTP/3：基于 QUIC 的进化

尽管 HTTP/2 带来了显著改进，但它依然运行在 TCP 协议之上。TCP 是几十年前为有线网络设计的可靠传输协议，在面对现代无线网络（高丢包、频繁切换）时，其固有问题被放大：由 TCP 丢包重传导致的传输层队头阻塞成为瓶颈。同时，TLS 握手的耗时也拖慢了连接建立速度。

HTTP/3 应运而生，它基于 QUIC 协议（Quick UDP Internet Connections），从根本上改变了传输层。HTTP/3 目前已被标准化为 RFC 9114。

QUIC 基础：从 TCP 到 UDP

HTTP/3 不再使用 TCP，而是使用 QUIC。QUIC 是一个基于 UDP 的、集成多路复用的安全传输协议。可以说，HTTP/2 解决了 HTTP 层面的队头阻塞，而 QUIC 解决了传输层面的队头阻塞。

QUIC 的关键特性：

• 基于 UDP：绕过了操作系统中 TCP 协议栈的限制，可在用户空间实现，迭代更快。
• 内置多路复用，无队头阻塞：QUIC 在传输层原生支持多路复用，多个 HTTP 请求的数据被封装在完全独立的 QUIC 流（Stream）中。如果某个流的一个数据包丢失，仅影响该流，其他流的传输完全没有阻碍。这彻底根除了 TCP 带来的队头阻塞。
• 加密必选：QUIC 集成了 TLS 1.3，加密不是可选项。所有 QUIC 报文（除了少量初始握手报文）都是加密的，提供了更好的隐私性和安全性。
• 0-RTT 和 1-RTT 连接建立：连接建立速度极快，详见下文。

更快的连接建立

HTTP/2 + TCP + TLS 需要 2 个或 3 个往返时间（RTT）才能完成握手并发送第一个 HTTP 请求。HTTP/3 借助 QUIC，结合了传输握手和 TLS 握手，大幅缩短启动时间：

• 首次连接（1-RTT）：如果客户端是第一次连接服务器，QUIC 只需 1 个 RTT 即可完成握手，其中包括密钥协商和传输参数确认。相比 TCP + TLS 1.3 的 2-RTT 或 TCP + TLS 1.2 的 3-RTT，已有所减少。
• 重复连接（0-RTT）：当客户端之前连接过该服务器并缓存了服务器提供的预共享密钥（PSK）时，可以在第一个握手包中就携带加密的应用数据（如 HTTP 请求）。这意味着连接建立的延迟几乎为 0，非常适合移动网络切换场景。但需注意，0-RTT 数据存在重放攻击风险，不应用于非幂等请求。

连接迁移

在 TCP 中，连接由源 IP、源端口、目的 IP、目的端口四元组唯一标识。一旦客户端网络发生变化（如从 Wi-Fi 切换到移动数据），IP 地址或端口改变，所有 TCP 连接都会中断，必须重新建立。

QUIC 创新性地使用连接 ID（Connection ID） 代替四元组来标识一个连接。即使客户端的 IP 或端口改变，只要保持连接 ID 不变，连接就可以无缝迁移，无需重新握手。这对移动用户的体验提升尤为显著，视频观看、文件下载等都不会因为网络切换而中断。

HTTP/3 的头部压缩（QPACK）

HTTP/3 仍然需要对头部进行压缩，但它不能直接使用 HTTP/2 的 HPACK。因为 HPACK 依赖于流之间的严格顺序来维持动态表的一致性，而 QUIC 中流是严格独立的，乱序到达会破坏 HPACK 的动态表。

因此，HTTP/3 设计了 QPACK。QPACK 与 HPACK 类似，也使用静态表和动态表，但解决了多路复用下的顺序问题：

• QPACK 使用了两个独立的单向流：一个用于编码器向解码器发送动态表更新，另一个用于解码器向编码器确认更新。
• 这样，动态表的更新可以与包含头部字段的流完全解耦。即使承载请求数据的流乱序到达，只要动态表的指令按顺序被确认，头部就能正确解码。

QPACK 在保持高压缩率的同时，确保了在多路复用、无队头阻塞环境下的鲁棒性。

HTTP/2 与 HTTP/3 对比总结

迁移与实践注意事项

• 部署 HTTP/2：绝大多数现代 Web 服务器（Nginx、Apache、Caddy）和 CDN 都内置了 HTTP/2 支持，只需开启 HTTPS 并配置相应参数即可。客户端（浏览器）100% 支持。
• 启用 HTTP/3：需要在服务器软件中启用 QUIC 和 HTTP/3（例如 Nginx 需使用支持 QUIC 的分支，或使用 Caddy、LiteSpeed 等）。同时需要确保网络防火墙允许 UDP 443 端口通信，因为 HTTP/3 使用 UDP 而不是 TCP。
• 降级策略：HTTP/3 通过 HTTP/2 或 HTTP/1.1 的 Alt-Svc 头部宣告支持。浏览器会尝试升级到 HTTP/3，如果失败，会无缝回退到 HTTP/2 或 HTTP/1.1，对用户无感知。
• 性能测试：使用浏览器开发者工具的 Network 面板可以查看协议版本（显示为 h2 或 h3）。亦可使用 curl 等工具进行测试。

HTTP/2 和 HTTP/3 代表了 Web 性能优化的两个里程碑。HTTP/2 解决了应用层的多路复用和头部膨胀问题，而 HTTP/3 更进一步，从传输层根除了队头阻塞并带来了极速的连接体验。理解这些核心改进，能帮助你更好地优化网站性能，构建面向未来的快速 Web 应用。