HTTP/1.1 时代，浏览器用多连接缓解队头阻塞；HTTP/2 把多个流放进单 TCP 连接；HTTP/3 再把载体换成基于 UDP 的 QUIC。表面都是「更快」，分层原因并不相同。

HTTP/2：应用层多路复用

同一连接上可并发多个请求流，头部也被 HPACK 压缩。收益很明显，但 TCP 丢包仍会卡住整条连接上的所有流——这是传输层队头阻塞。站点若资源多、RTT 高，HTTP/2 整体仍常优于 HTTP/1.1，却在剧烈丢包场景暴露局限。

QUIC 与 HTTP/3

QUIC 将加密、连接迁移、流复用下沉：

  • 流级别的丢失恢复，降低「一个流丢包拖死所有流」；
  • 连接标识不绑死四元组，终端切换网络时更平滑；
  • 握手路径与 TLS 结合更紧凑，有利于短连接与首次访问。

代价是运维可见性变化：传统 TCP 中间盒手段变少，排障要更多依赖终端指标、日志与专有诊断。

实践观察清单

  1. CDN/源站是否真正端到端支持 h3，而不是仅边缘宣称。
  2. 企业防火墙对 UDP/443 的策略是否误伤。
  3. 用 WebPageTest / 浏览器 DevTools 的协议列，验证真实协商结果。
研记：协议升级不是勾选功能，而是把瓶颈从「连接数」迁移到「丢包与迁移」的问题域。