网络协议

HTTP/2 & HTTP/3
深度解析

从二进制分帧到 QUIC 协议，全面理解现代 HTTP 协议的演进、原理与革命性创新。

发布年份:2015 / 2022
核心改进:多路复用 / 0-RTT
底层协议:TCP → QUIC
HTTP 协议演进史

从 0.9 到 3.0 的 30 年进化

HTTP/0.91991
仅支持 GET纯文本响应无 Header
HTTP/1.01996
引入状态码支持 Header每次请求一个连接
HTTP/1.11997
持久连接管线化（有队头阻塞）分块传输
HTTP/2.02015
二进制分帧多路复用头部压缩服务器推送
HTTP/3.02022
基于 QUIC/UDP0-RTT 建连独立流内置加密
深入 HTTP/2

二进制时代
的性能革命

HTTP/2 于 2015 年正式发布（RFC 7540），源自 Google 的 SPDY 协议。它通过二进制分帧、多路复用和头部压缩等技术，大幅提升了 Web 性能。

HTTP/2 协议栈

HTTP 请求/响应
⬡ 二进制分帧层 (Binary Framing)
🔒 TLS 加密层（可选）
TCP 传输层
IP 层
⚠️ TCP 层的队头阻塞依然存在 — 一个包丢失会阻塞所有流

二进制分帧层

HTTP/2 将所有传输的数据分割为更小的消息和帧（Frame），并采用二进制格式编码。这使得解析更高效、更紧凑。

深入理解
每个帧包含 9 字节的帧头：长度(3B) + 类型(1B) + 标志(1B) + 流标识符(4B)。常见的帧类型包括 DATA、HEADERS、SETTINGS、WINDOW_UPDATE 等。

多路复用 (Multiplexing)

同一个 TCP 连接上可以并行发送多个请求和响应，互不干扰。彻底解决了 HTTP/1.1 的队头阻塞问题。

深入理解
每个请求/响应对被分配一个唯一的 Stream ID。多个 Stream 共享同一个 TCP 连接，按帧交错发送。接收端根据 Stream ID 重新组装。

头部压缩 (HPACK)

使用 HPACK 算法压缩 HTTP 头部。维护一个头部字段表，避免重复传输相同的头部信息。

深入理解
HPACK 使用静态表（61个预定义常用头部）和动态表（连接级别），结合霍夫曼编码实现高效压缩。可减少 80%~90% 的头部大小。

服务器推送 (Server Push)

服务器可以在客户端请求之前，主动将资源推送到客户端缓存中，减少往返延迟。

深入理解
服务器通过 PUSH_PROMISE 帧通知客户端即将推送的资源。客户端可以通过 RST_STREAM 帧拒绝不需要的推送。注意：Chrome 已于 2022 年移除了 Server Push 支持。

流优先级 (Stream Priority)

客户端可以为每个流分配权重和依赖关系，让服务器优先传输关键资源。

深入理解
使用依赖树 + 权重(1-256) 的方式。例如 CSS 可以依赖于 HTML，JS 依赖于 CSS，形成资源加载优先级链。

流量控制 (Flow Control)

基于窗口的流量控制机制，防止接收端被淹没。每个流和连接都有独立的流量控制窗口。

深入理解
接收端通过 WINDOW_UPDATE 帧告知发送端可用的缓冲区大小。初始窗口大小为 65,535 字节，可动态调整。

交互演示：多路复用

HTTP/1.1 串行请求
HTML
CSS
JS
IMG

😫 请求必须排队等待，总耗时 = 所有请求之和

HTTP/2 多路复用
HTML
CSS
JS
IMG

🚀 所有请求并行传输，总耗时 ≈ 单个最慢的请求

🔗 队头阻塞问题图解

HTTP/2 (TCP) — 存在队头阻塞
Stream 1
Stream 2
Stream 3
Stream 4
📦 P1 ✅
📦 P1 ✅
📦 P1 ✅
📦 P1 ✅
❌ 丢失!
📦 P2
📦 P2
📦 P2
⛔ 阻塞!
⛔ 阻塞!
⛔ 阻塞!
⛔ 阻塞!

TCP 层一个包丢失 → 所有流等待重传 → 全部阻塞！

HTTP/3 (QUIC) — 无队头阻塞 ✅
Stream 1
Stream 2
Stream 3
Stream 4
📦 P1 ✅
📦 P1 ✅
📦 P1 ✅
📦 P1 ✅
❌ 丢失!
📦 P2 ✅
📦 P2 ✅
📦 P2 ✅
⛔ 仅S1阻塞
✅ 继续
✅ 继续
✅ 继续

仅受影响的流阻塞重传，其他流继续正常传输！🎉

深入 HTTP/3

QUIC 驱动
的下一代协议

HTTP/3 于 2022 年正式标准化（RFC 9114），基于 Google 开发的 QUIC 协议。它用 UDP 取代 TCP，将传输层与加密层合并，实现了更低延迟和更强的连接稳定性。

HTTP/3 协议栈

HTTP 请求/响应
QPACK 头部压缩
⬡QUIC 协议
传输TLS 1.3
UDP
IP 层
✅ 传输 + 加密合并 — 每个流完全独立，彻底消除队头阻塞

基于 QUIC 协议

HTTP/3 不再使用 TCP，而是基于 QUIC（Quick UDP Internet Connections）协议，构建在 UDP 之上。

深入理解
QUIC 在用户空间实现，不依赖操作系统内核更新。将传输层和加密层合并，实现了更灵活的协议演进。

0-RTT / 1-RTT 建连

首次连接仅需 1-RTT（TCP+TLS 需要 2~3 RTT），再次连接可实现 0-RTT，极大减少延迟。

深入理解
QUIC 将传输握手和加密握手合并。客户端首次连接时缓存服务器配置，后续连接可直接发送加密数据（0-RTT）。

内置 TLS 1.3 加密

加密是 QUIC 的内置特性，所有 HTTP/3 连接默认加密。不再有明文 HTTP 的可能性。

深入理解
QUIC 强制使用 TLS 1.3，比 TLS 1.2 更安全且更快。连接建立和加密握手同步完成，无需额外 RTT。

独立流消除队头阻塞

每个流都是独立的。某个流的丢包只会影响该流，不会阻塞其他流的传输。这是对 HTTP/2 最关键的改进。

深入理解
HTTP/2 虽然解决了 HTTP 层的队头阻塞，但 TCP 层的队头阻塞仍然存在。QUIC 在传输层实现了真正的独立流，彻底解决此问题。

连接迁移 (Connection Migration)

使用 Connection ID 而非 IP+端口标识连接。切换 WiFi/4G 时连接不断开，无需重新握手。

深入理解
TCP 使用四元组（源IP、源端口、目标IP、目标端口）标识连接。QUIC 使用 Connection ID，网络切换时连接可以无缝迁移。

改进的拥塞控制

QUIC 实现了可插拔的拥塞控制算法，并在用户空间实现，支持更快速的迭代和优化。

深入理解
默认使用类似 TCP Cubic 的算法，但可轻松替换为 BBR 等更先进的算法。支持更精细的丢包检测（基于包号而非序列号）。

🏎️ 连接建立延迟对比

TCP + TLS 1.2 = 3 RTT
SYN
SYN-ACK
ACK
ClientHello
ServerHello
Finished
TCP + TLS 1.3 = 2 RTT
SYN
SYN-ACK+Hello
ACK+Finished
Data
QUIC 首次 = 1 RTT ⚡
ClientHello+Transport
ServerHello+Data
Data
QUIC 再次连接 = 0 RTT 🚀🚀
立即发送加密数据！

📱 连接迁移演示

WiFi
IP: 192.168.1.100
切换网络
4G/5G
IP: 10.0.0.55
TCP: 断开重连

四元组变化 → 连接失效 → 重新握手

QUIC: 无缝迁移

Connection ID 不变 → 连接继续 → 零中断

全面对比

HTTP/2 vs HTTP/3

特性
HTTP/2
HTTP/3
优势
传输层协议
TCP
QUIC (UDP)
HTTP/3
握手延迟
TCP + TLS = 2~3 RTT
首次 1-RTT，再次 0-RTT
HTTP/3
队头阻塞
TCP 层仍存在
完全消除
HTTP/3
多路复用
✅ 支持
✅ 支持（更优）
HTTP/3
头部压缩
HPACK (TCP)
QPACK (UDP)
持平
加密
可选 (TLS)
强制内置 (TLS 1.3)
HTTP/3
连接迁移
❌ 不支持
✅ 支持
HTTP/3
服务器推送
✅ 支持（已弃用）
⚠️ 规范支持，实践减少
持平
浏览器支持
所有主流浏览器
Chrome/Edge/Firefox/Safari
HTTP/2
部署复杂度
较低
较高（需 UDP 支持）
HTTP/2
核心要点

一张图总结

HTTP/2 的贡献

  • 二进制分帧 → 更高效的解析
  • 多路复用 → 并行请求无阻塞
  • HPACK 压缩 → 减少带宽消耗
  • 单一连接 → 减少 TCP 握手开销

HTTP/3 的突破

  • QUIC/UDP → 绕过 TCP 限制
  • 0-RTT 建连 → 极致低延迟
  • 独立流 → 彻底消除队头阻塞
  • 连接迁移 → 网络切换零中断

未来趋势

  • QUIC 生态持续成熟和普及
  • CDN 厂商全面支持 HTTP/3
  • WebTransport 基于 QUIC 构建
  • 加密成为协议的默认特性

协议的演进永不停歇 🚀

从 HTTP/0.9 的单行文本到 HTTP/3 的零延迟连接，每一次升级都在突破性能的边界。 理解这些底层原理，将帮助你构建更快速、更可靠的 Web 应用。

掌握原理优化性能面向未来