HTTP3展望|HTTP协议篇

我们一起学习了 HTTP/2，你也应该看到了 HTTP/2 做出的许多努力，比如头部压缩、二进制分帧、虚拟的“流”与多路复用，性能方面比 HTTP/1 有了很大的提升，“基本上”解决了“队头阻塞”这个“老大难”问题。

原理拆解： HTTP/2 先用 HPACK 压缩重复的请求头，再把请求和响应编码为二进制帧。每个帧携带所属流的标识，因此连接可以交错发送多个流的数据，而不必等前一个响应完整结束。浏览器加载页面时，HTML、CSS 和图片可以共享一条连接；某个大图片响应尚未结束时，CSS 对应的帧仍可被调度发送。这消除了 HTTP/1.1 串行使用连接时的应用层等待，也减少了为并发请求建立大量连接的成本。

最小验证： 输入一个支持 HTTP/2 的 HTTPS 地址，验证协商出的协议版本并观察响应头；将地址替换为待测服务即可执行。

curl --http2 -sS -o /dev/null \
  -w 'http_version=%{http_version}\nstatus=%{http_code}\n' \
  https://example.com/

--http2 允许通过 TLS 的 ALPN 协商 HTTP/2，%{http_version} 输出实际采用的版本。服务支持且链路未降级时，预期看到 http_version=2 和成功状态码；若输出 1.1，应检查服务器、反向代理和本机 curl 的能力，而不能仅凭页面加载速度判断协议。

边界与排查： 多路复用并不等于整条链路不存在阻塞。所有流仍共享底层连接、带宽和拥塞状态；连接发生丢包时，TCP 的按序交付可能让多个流一起等待。验证性能时应同时记录协议版本、连接复用情况、丢包率和往返时延，并区分服务器处理慢、优先级调度不合理与传输层阻塞，避免把任何请求变慢都归因于 HTTP/2。

等等，你可能要发出疑问了：为什么说是“基本上”，而不是“完全”解决了呢？

这是因为 HTTP/2 虽然使用“帧”“流”“多路复用”，没有了“队头阻塞”，但这些手段都是在应用层里，而在下层，也就是 TCP 协议里，还是会发生“队头阻塞”。

这是怎么回事呢？

让我们从协议栈的角度来仔细看一下。在 HTTP/2 把多个“请求 - 响应”分解成流，交给 TCP 后，TCP 会再拆成更小的包依次发送（其实在 TCP 里应该叫 segment，也就是“段”）。

在网络良好的情况下，包可以很快送达目的地。但如果网络质量比较差，像手机上网的时候，就有可能会丢包。而 TCP 为了保证可靠传输，有个特别的“丢包重传”机制，丢失的包必须要等待重新传输确认，其他的包即使已经收到了，也只能放在缓冲区里，上层的应用拿不出来，只能“干着急”。

我举个简单的例子：

客户端用 TCP 发送了三个包，但服务器所在的操作系统只收到了后两个包，第一个包丢了。那么内核里的 TCP 协议栈就只能把已经收到的包暂存起来，“停下”等着客户端重传那个丢失的包，这样就又出现了“队头阻塞”。

由于这种“队头阻塞”是 TCP 协议固有的，所以 HTTP/2 即使设计出再多的“花样”也无法解决。

Google 在推 SPDY 的时候就已经意识到了这个问题，于是就又发明了一个新的“QUIC”协议，让 HTTP 跑在 QUIC 上而不是 TCP 上。

而这个“HTTP over QUIC”就是 HTTP 协议的下一个大版本，HTTP/3。它在 HTTP/2 的基础上又实现了质的飞跃，真正“完美”地解决了“队头阻塞”问题。

不过 HTTP/3 目前还处于草案阶段，正式发布前可能会有变动，所以今天我尽量不谈那些不稳定的细节。

这里先贴一下 HTTP/3 的协议栈图，让你对它有个大概的了解

原理拆解： HTTP/2 的流只存在于应用层。帧写入同一个 TCP 连接后，会变成连续的有序字节，再由 TCP 分段传输。假设流 A 的一个数据段丢失，而流 B 的后续字节已经抵达，接收端虽然可能确认已收到的范围，却不能越过缺口向应用交付后面的字节；直到重传补齐，HTTP/2 实现才有机会解析并分派这些帧。因此，一个段的丢失可能同时增加多个流的完成时间。

最小验证： 输入目标地址，创建一个 HTTP/2 连接并并发请求三个资源，验证多个请求确实复用同一会话。命令会输出协议调试信息和每个请求的完成结果。

nghttp -nv \
  https://example.com/ \
  https://example.com/index.html \
  https://example.com/favicon.ico

输出中的同一连接内会出现不同 stream_id，帧可交错出现，这证明应用层存在独立流。若某个资源返回 404，仍可观察协议行为；若提示命令不存在，需要安装提供 nghttp 的 nghttp2 客户端。这个命令不会主动制造丢包，所以不能仅凭一次正常结果证明没有传输层阻塞。

边界与排查： TCP 队头阻塞不代表每次丢包都会产生肉眼可见的长暂停，快速重传、较短的往返时延和接收缓冲可能掩盖影响；服务器计算、磁盘读取或应用限流也会形成相似瀑布图。工程验证应在受控测试环境中改变丢包率和时延，对比单流与多流的完成时间，并结合抓包中的重传、重复确认及时间戳判断。HTTP/3 已不应按早期草案状态理解，但其核心变化仍是以 QUIC 取代 TCP 承载 HTTP。