4. HTTP/1.1 vs HTTP/2 vs HTTP/3：多路复用、头部压缩、队头阻塞的底层原理
聊到HTTP协议演进，我其实挺感慨的。刚入行那会儿，大家还在为HTTP/1.1的六个连接并发沾沾自喜。后来移动互联网爆发，页面越来越重，问题就全暴露出来了。
今天咱们就掰开揉碎，看看这三个版本到底差在哪。说白了，就是一场「如何让网络更快」的持续进化。
4.1 HTTP/1.1：曾经的王者，现在的瓶颈
HTTP/1.1在1999年定稿，到现在二十多年了。它最大的贡献是引入了持久连接和管道化。
持久连接好理解——不用每次请求都重新建立TCP连接。但管道化呢？它允许你在收到上一个响应之前，就发送下一个请求。听起来不错对吧？
嗯，这里要注意：管道化在实际中几乎没人用。为什么？因为队头阻塞（Head-of-Line Blocking）这个老问题，它根本解决不了。
队头阻塞的本质：HTTP/1.1的请求-响应模型是严格串行的。一个请求没处理完，后面的请求就得排队等着。哪怕后面的请求只需要1ms，前面的请求卡了3秒，你也得等3秒。
我在项目中遇到过这样一个场景：一个页面加载了80个资源，浏览器最多开6个连接。每个连接上排着十几个请求，只要其中一个请求慢一点，整条线就堵死了。用户眼睁睁看着页面空白，那种体验，别提多糟糕了。
4.2 HTTP/2：多路复用带来的革命
2015年，HTTP/2来了。它最大的变化是引入了二进制分帧层。以前HTTP/1.1是文本协议，现在变成了二进制协议。这有什么好处？
- 多路复用：一个TCP连接上可以同时跑多个请求和响应，互不干扰
- 头部压缩：用HPACK算法把重复的头部信息压缩掉，节省带宽
- 服务器推送：服务器可以主动把资源推给客户端，不用等客户端请求
你想想看，多路复用是怎么做到的？其实就是把每个请求拆成一个个小帧，然后在同一个TCP连接上交错发送。接收方再根据帧头部的流ID重新组装。这样一来，一个请求慢，不会影响其他请求。
我个人习惯：在HTTP/2环境下，把原来分散到多个域名下的资源合并到一个域名。因为HTTP/2的多路复用，一个连接就够了，域名分片反而增加DNS查询开销。
但HTTP/2也有坑。它虽然解决了应用层的队头阻塞，但TCP层的队头阻塞还在。什么意思？
举个例子：一个TCP包丢了，后面的所有包都得等这个包重传成功才能处理。哪怕你发的是不同请求的数据，也得一起等着。这就是TCP层面的队头阻塞。
我曾经踩过的坑：在弱网环境下，HTTP/2的表现有时还不如HTTP/1.1。因为HTTP/1.1有6个连接，丢包影响范围小；而HTTP/2只有一个连接，一个丢包就卡住所有流。后来我们在弱网场景下做了降级处理，才解决了这个问题。
4.3 HTTP/3：基于QUIC的终极方案
HTTP/3直接换掉了底层传输协议。它不再用TCP，而是用Google开发的QUIC协议。QUIC基于UDP，但实现了TCP的可靠性。
为什么这么做？说白了，TCP是上世纪70年代设计的，那时候没人考虑移动互联网。TCP的握手需要1.5个RTT，加上TLS还要1个RTT，总共2.5个RTT才能开始传数据。而QUIC把连接建立和TLS握手合并了，0-RTT就能发数据。
更重要的是，QUIC彻底解决了队头阻塞。因为QUIC的每个流是独立的，一个流丢包只影响它自己，其他流照常传输。
| 特性 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 传输层 | TCP | TCP | QUIC (UDP) |
| 多路复用 | 不支持（靠多连接） | 支持 | 支持 |
| 头部压缩 | 无 | HPACK | QPACK |
| 队头阻塞 | 应用层+传输层 | 传输层 | 无 |
| 连接建立 | 2.5 RTT | 2.5 RTT | 0-1 RTT |
| 连接迁移 | 不支持 | 不支持 | 支持 |
核心结论：HTTP/3在弱网环境下的表现远超HTTP/2。尤其是移动网络下，用户切换Wi-Fi和4G时，QUIC的连接迁移特性让连接不会断开。这个特性在实际项目中太香了。
4.4 头部压缩：HPACK vs QPACK
头部压缩这块，我多说两句。HTTP/1.1的头部是纯文本，一个Cookie可能就几百字节。一个页面几十个请求，光头部就占了大量带宽。
HTTP/2的HPACK是怎么做的？它维护了一张静态表和一张动态表。常见的头部（比如:method: GET）直接查表，用索引代替。动态表则记录之前出现过的头部，后续请求直接引用。
HTTP/3的QPACK更复杂一些。因为QUIC的流是乱序到达的，QPACK需要处理头部表在不同流之间的同步问题。它引入了编码器流和解码器流，专门用来同步头部表的状态。
我建议：如果你还在用HTTP/1.1，先把头部大小降下来。比如把Cookie压缩、去掉不必要的自定义头部。这招立竿见影，比升级协议简单多了。
4.5 实际项目中的选型建议
说了这么多理论，到底怎么选？我根据实际经验给几个建议：
- 内网服务间调用：用HTTP/1.1就够了。内网延迟低、丢包少，HTTP/2和HTTP/3的优势不明显。而且HTTP/1.1的调试工具最成熟。
- 面向公网的Web应用：优先用HTTP/2。大部分浏览器都支持，部署简单。Nginx加几行配置就行。
- 移动端App：强烈推荐HTTP/3。移动网络丢包率高、延迟大，HTTP/3的0-RTT和连接迁移是杀手级特性。
- 视频/直播场景：HTTP/3最合适。队头阻塞对视频流的影响特别大，一个丢包可能导致画面卡顿几秒钟。
- 物联网设备：看情况。如果设备性能弱，HTTP/1.1更省资源。HTTP/3的QUIC实现比较复杂，对CPU和内存有要求。
我曾经犯过的错：在一个项目中，我一股脑全上了HTTP/2，结果发现某些老旧的中间件不支持，导致回退到HTTP/1.1时出现了兼容性问题。后来我学乖了，升级前一定先做灰度测试，确保回退机制没问题。
4.6 知识体系总览
下面这张图，是我梳理的HTTP协议演进的核心逻辑。你可以看到，每一次升级都在解决前一个版本的痛点。
看到这张图，你应该能理解为什么我说「没有银弹」。每个版本都有自己的适用场景，选型不是越新越好，而是越合适越好。
最后说一句：不管用哪个版本，监控和灰度永远是第一位的。我曾经在升级HTTP/2时，因为没做好回退机制，导致线上故障。从那以后，我每次协议升级都先在小流量上跑一周，确认没问题再全量。
想要更多资料，联系可可