HTTP/2 与 HTTP/3：协议演进带来了什么

HTTP/1.1 的瓶颈

• 队头阻塞（HOL）：同一连接上的请求必须串行响应，前一个没回来后面全等着。浏览器为了并发，只能对同域名开 6 个左右 TCP 连接，连接管理开销大
• 每次请求都重复发送大量文本头部，冗余明显
• 只能在应用层做雪碧图、域名分片、资源合并等优化，本质都是绕协议的坑

HTTP/2 的核心改进

1. 二进制分帧 + 多路复用

数据拆成带流 ID 的二进制帧，多个请求/响应可以在同一条 TCP 连接上并发交错传输，互不阻塞（应用层不再有队头问题）。六个连接的 workaround 成为历史。

2. 头部压缩 HPACK

静态/动态表 + 哈夫曼编码，重复头只传索引，大幅减小请求开销。

3. 服务器推送（Server Push）

服务器可主动推送客户端可能需要的资源（该特性后来被 Chrome 移除，实际收益有争议，了解即可）。

4. 流优先级与流量控制，可标注关键资源优先。

代价是：所有请求复用一条 TCP 连接，TCP 层的队头阻塞仍在——一个 TCP 包丢失，整条连接的所有流都要等重传。

HTTP/3：换到 QUIC

HTTP/3 把传输层从 TCP 换成基于 UDP 的 QUIC：

• QUIC 原生多路复用，流之间真正独立——某个流丢包只阻塞该流，解决 TCP 层队头阻塞
• 连接建立与 TLS 握手合并（0/1-RTT），弱网和移动网络下更快
• 连接迁移：网络从 WiFi 切到 4G（IP 变化），用连接 ID 标识可以平滑续接不断连
• 内置加密，安全性进一步提升

实际部署现状

• HTTP/2 已非常普及，Nginx/Caddy/CDN 开启简单，浏览器普遍支持（要求 HTTPS）
• HTTP/3/QUIC 主流 CDN 和浏览器支持度已相当高，Nginx 新版本、Caddy 可直接启用
• 应用代码基本无感，是传输层升级；升级协议前先用性能数据确认瓶颈确实在连接层

一张图总结

HTTP/1.1：文本、串行 → 多 TCP 连接
HTTP/2：  二进制帧、单连接多路复用（解决应用层 HOL）
HTTP/3：  QUIC over UDP、独立流（解决传输层 HOL + 更快握手）

协议演进的主线非常清晰：不断消除"排队等待"、不断合并往返。对前端而言，知道这些底层变化，就能理解为什么很多老优化手段（域名分片、雪碧图）在现代协议下反而可能帮倒忙。