HTTP/1.1、HTTP/2 与 HTTP/3：连接复用、队头阻塞和 QUIC（077）

一、HTTP 的演进史就是"解决队头阻塞"的演进史

HTTP 协议经历了三次重大版本迭代，每一次升级的核心目标都是解决前一个版本的性能瓶颈，尤其是队头阻塞（Head-of-Line Blocking）问题：

• HTTP/1.0：每个请求建立一个 TCP 连接，用完即关闭。简单但开销巨大。
• HTTP/1.1：引入持久连接和管道化，但队头阻塞严重。
• HTTP/2：引入多路复用，解决了应用层的队头阻塞，但 TCP 层的队头阻塞仍然存在。
• HTTP/3：基于 QUIC（UDP），彻底解决了 TCP 层的队头阻塞。

[图4：HTTP版本演进时间线——HTTP/1.0→1.1→2→3的时间线，标注每版本核心改进]

二、HTTP/1.1：持久连接与管道化的局限

HTTP/1.1 相比 HTTP/1.0 的核心改进：持久连接（Keep-Alive）默认开启，管道化（Pipelining）允许客户端在收到响应前发送多个请求，分块传输编码，Host 头部支持虚拟主机。

但管道化有致命缺陷：响应必须按请求的顺序返回。如果第一个请求的响应很慢（比如数据库查询耗时 3 秒），后面所有请求的响应都被阻塞——即使它们已经准备好了。

客户端发送：请求1, 请求2, 请求3
服务端处理：请求1(3秒), 请求2(10ms), 请求3(10ms)
服务端响应：响应1(3秒后), 响应2(3秒后), 响应3(3秒后)
                                    ↑ 队头阻塞

由于管道化在实践中几乎不可用（浏览器默认禁用），HTTP/1.1 的并发是通过多个 TCP 连接实现的——浏览器为每个域名同时打开 6-8 个 TCP 连接。但多个连接竞争带宽，TCP 的拥塞控制无法跨连接协调。

[图1：HTTP/1.1队头阻塞示意图——管道化中请求1慢阻塞后续请求，多连接并发的局限性]

三、HTTP/2：解决应用层队头阻塞

HTTP/2（基于 SPDY）的核心目标是在不改变 HTTP 语义的前提下解决性能问题：

• 二进制分帧：将所有数据拆分为帧（Frame），请求和响应被分解为 HEADERS 帧和 DATA 帧。
• 多路复用：一个 TCP 连接上可以同时发送多个请求/响应的帧，帧可以交错发送，不需要按顺序。这解决了 HTTP/1.1 的应用层队头阻塞。
• 流（Stream）：每个请求/响应对应一个 Stream，帧通过 Stream ID 关联。
• 头部压缩（HPACK）：大幅减少传输量。
• 服务端推送（Server Push）：服务端可以主动推送资源。

多路复用是 HTTP/2 最重要的特性。在一个 TCP 连接上，多个 Stream 的帧可以交错发送和接收，哪个 Stream 的响应先准备好就可以先发送。

但 HTTP/2 引入了新的问题：TCP 层的队头阻塞。因为所有 Stream 共享同一个 TCP 连接，如果 TCP 层有一个报文丢失，TCP 的重传机制会阻塞所有 Stream——即使丢失的报文只属于 Stream 1，Stream 2-100 的数据也必须等待 TCP 重传完成。在高丢包率的网络环境下（如移动网络），HTTP/2 的性能可能不如 HTTP/1.1 的多连接方案。

[图2：HTTP/2多路复用与TCP队头阻塞——多路复用解决应用层阻塞，但TCP丢包仍阻塞所有Stream]

四、HTTP/3：基于 QUIC，彻底解决 TCP 队头阻塞

QUIC（Quick UDP Internet Connections）是 Google 设计的基于 UDP 的传输层协议，被 IETF 标准化为 HTTP/3 的底层协议。QUIC 的核心思想是将 TCP 的可靠性、拥塞控制与 TLS 的加密、HTTP/2 的多路复用整合到一个协议中。

QUIC 如何解决 TCP 队头阻塞：QUIC 在 UDP 之上实现了自己的"流"概念——每个 Stream 独立管理，一个 Stream 的数据丢失只影响该 Stream，不影响其他 Stream。因为 QUIC 没有 TCP 那种"所有数据必须按序到达"的约束。

QUIC 的其他优势：0-RTT 握手（已建立过连接的客户端可零往返发送数据）、连接迁移（WiFi 切到 4G 时 IP 变了但 Connection ID 不变，连接不中断）、前向纠错（FEC）、用户态拥塞控制（如 BBR）。

QUIC 的挑战：UDP 被部分运营商限速/拦截、CPU 开销（用户态加密和拥塞控制）、生态成熟度、调试困难。

[图5：QUIC协议架构图——UDP之上的Stream多路复用、0-RTT握手、连接迁移、独立流控]

五、HTTP 版本演进对比

[图3：HTTP/1.1 vs HTTP/2 vs HTTP/3对比图——三列展示连接模型、多路复用、队头阻塞、握手开销]

六、Java 中的 HTTP 支持

// JDK 11+ HttpClient 支持 HTTP/2
HttpClient client = HttpClient.newBuilder()
    .version(HttpClient.Version.HTTP_2)
    .build();
HttpResponse<String> response = client.send(request, BodyHandlers.ofString());

HTTP/1.1：HttpURLConnection、Apache HttpClient、OkHttp。HTTP/2：JDK 9+ HttpClient、OkHttp、Netty。HTTP/3：JDK 尚未原生支持，需通过 Netty QUIC codec 等第三方库。

[图6：HTTP版本选型决策树——从场景出发引导到合适的HTTP版本]

七、面试常见误区

• "HTTP/2 的多路复用可以在一个连接上同时发送无限个请求" —— 有限制。SETTINGS_MAX_CONCURRENT_STREAMS 参数（默认 100）限制了并发 Stream 数量。
• "HTTP/3 就是 HTTP/2 over QUIC" —— 不准确。HTTP/3 的语义有所调整，如 QPACK 替代了 HPACK。
• "HTTP/2 一定比 HTTP/1.1 快" —— 在丢包率高的网络环境下，HTTP/2 的单连接 TCP 队头阻塞可能更差。
• "QUIC 就是 HTTP/3" —— QUIC 是传输层协议，HTTP/3 是应用层协议。QUIC 可以承载其他应用层协议。

八、总结

HTTP 的演进史就是"解决队头阻塞"的演进史：

1. HTTP/1.1：管道化尝试解决但失败，靠多连接并发。
2. HTTP/2：多路复用解决应用层队头阻塞，但引入 TCP 层队头阻塞。
3. HTTP/3：基于 QUIC（UDP），彻底解决 TCP 层队头阻塞，同时提供 0-RTT 和连接迁移。

选择建议：内部服务间通信用 HTTP/2，面向用户的 Web 服务用 HTTP/2 + HTTP/3，移动端 App 优先用 HTTP/3。

延伸阅读

• RFC 7540（HTTP/2）、RFC 9114（HTTP/3）、RFC 9000（QUIC）
• 《HTTP/2 in Action》
• 本系列相关篇目：075-076（TCP 相关）、078（HTTPS 与 TLS）

面试官视角：提问与回答

以下问题从面试官视角出发，考察你对 HTTP 协议演进的深度理解和实战经验。

Q1：HTTP/2 的多路复用解决了 HTTP/1.1 的队头阻塞，但为什么在高丢包率（> 2%）的网络环境下，HTTP/2 的性能反而可能不如 HTTP/1.1 的多连接？

这是因为 HTTP/2 的所有 Stream 共享同一个 TCP 连接。当 TCP 层有一个报文丢失时，TCP 的重传机制会阻塞所有后续数据——即使丢失的报文只属于 Stream 1，Stream 2-100 的数据也必须等待 TCP 重传完成。而 HTTP/1.1 使用 6-8 个独立 TCP 连接，只有发生丢包的那个连接受影响，其他连接正常传输。在高丢包率下，HTTP/2 的单个连接丢包概率更高（因为连接数更少，每个连接承载更多数据），而 TCP 重传的延迟（RTO 通常 200ms+）会阻塞所有 Stream。HTTP/3 通过 QUIC 的独立 Stream 解决了这个问题——每个 Stream 独立管理，一个 Stream 丢包不影响其他 Stream。

Q2：HTTP/2 的 HPACK 头部压缩和 HTTP/3 的 QPACK 有什么区别？为什么 HTTP/3 不能直接用 HPACK？

HPACK 依赖动态表（Dynamic Table），编码器和解码器维护一个共享的头部表，通过引用来压缩重复的头部。HPACK 的关键假设是"引用是顺序的"——因为 HTTP/2 在 TCP 上，TCP 保证数据按序到达，所以解码器可以按序处理引用。但 QUIC 的 Stream 之间没有顺序保证——Stream 1 的 HEADERS 帧可能比 Stream 2 的 HEADERS 帧晚到达，导致解码器无法按序处理 HPACK 引用。QPACK 解决了这个问题：它使用两个独立的单向 Stream 来传输动态表的更新（Encoder Stream 和 Decoder Stream），而请求 Stream 中的 HEADERS 帧只引用已经确认的表更新。这样即使 Stream 乱序到达，解码器也能正确处理引用。

Q3：QUIC 的 0-RTT 握手听起来很完美，但有什么安全风险？如何在生产环境中安全使用？

0-RTT 握手允许客户端使用之前会话的密钥加密数据，在第一个包中就发送应用数据。但这也意味着重放攻击——攻击者可以捕获 0-RTT 数据并在之后重放，服务端会收到重复的请求。如果 0-RTT 数据中有非幂等操作（如 POST 创建订单），重放会导致重复创建。解决方案：1）服务端只允许幂等操作（GET、HEAD）在 0-RTT 中发送。2）设置 0-RTT 数据的有效窗口（如 30 秒），过期的 0-RTT 数据被拒绝。3）客户端在 0-RTT 中只发送"安全"的请求。4）使用 0-RTT 的 Token 机制，每次新连接需要新的 Token。生产环境建议：默认禁用 0-RTT 的非幂等操作，仅在静态资源加载等幂等场景开启。

Q4：QUIC 在 UDP 之上实现了 TCP 的可靠性（重传、拥塞控制），但为什么不直接改进 TCP 而要基于 UDP 重新实现？

核心原因是 TCP 实现在操作系统内核中，改进 TCP 需要升级内核，而内核升级周期长、覆盖范围有限。QUIC 在用户态实现，可以快速迭代和部署（如 Google 的 QUIC 几个月就更新一次）。此外，TCP 的"中间件僵化"问题——很多网络中间设备（防火墙、NAT、负载均衡器）对 TCP 选项有特殊处理，新增 TCP 选项可能被中间设备丢弃，导致协议升级困难。QUIC 基于 UDP，UDP 本身就是"无状态"的，中间设备对 UDP 的干扰较少（除了部分运营商限速/拦截）。最后，QUIC 的设计目标之一就是"协议敏捷性"——QUIC 的版本协商和扩展机制比 TCP 更灵活。

Q5：你在一家电商公司，Nginx 反向代理到后端 Java 服务，前端用户使用 HTTPS。Nginx 和后端之间是内网，你会用 HTTP/1.1 还是 HTTP/2？为什么？

内网环境下，我推荐 HTTP/2。原因：1）内网丢包率极低（< 0.01%），HTTP/2 的 TCP 层队头阻塞问题几乎不存在。2）HTTP/2 的多路复用可以减少连接数——Nginx 和后端之间只需要少量 TCP 连接（甚至一个），而不是每个请求一个连接。这减少了 TCP 握手和 TIME_WAIT 的开销。3）HTTP/2 的头部压缩在长连接上效果显著——如果 Nginx 和后端之间有大量小请求，头部压缩可以节省带宽。4）HTTP/2 的流优先级可以让 Nginx 更精细地控制请求的调度。需要注意：set Nginx 的 keepalive 连接数、HTTP/2 的 max_concurrent_streams、以及后端的连接超时配置。如果后端是 JDK 8，确认 HttpClient 支持 HTTP/2（JDK 8 的默认 HttpClient 不支持，需要 OkHttp 或升级 JDK）。