HTTP/1.1、HTTP/2、HTTP/3 有什么区别？队头阻塞是怎么解决的？

🧑‍💻 面试官：HTTP/2 有多路复用，就完全没有队头阻塞了吗？

🙋‍♂️ 我：对，不同请求各走自己的流。

🧑‍💻 面试官：如果底层 TCP 丢了前面一段字节，后面的流能立刻交给应用吗？

🙋‍♂️ 我：底层还会等重传。

🧑‍💻 面试官：那 HTTP/3 用 UDP，是不是就不可靠，也完全不用等待了？

队头阻塞要问发生在哪一层。HTTP/2 改善 HTTP 消息排队，HTTP/3 进一步隔离不同传输流，但不消除所有等待。

面试速答（60 秒版）

HTTP/1.1 支持连接复用，但同连接的流水线响应仍受顺序限制，实践中常用多连接并发。HTTP/2 使用二进制帧和流，让多个请求在一个连接上交错传输，并通过 HPACK 压缩头字段。

但 HTTP/2 通常跑在 TCP 上，TCP 是有序字节流。丢失一段字节时，后续字节交付会等待，可能影响同连接的多个 HTTP 流。

HTTP/3 基于 QUIC。QUIC 使用 UDP 承载，但自己实现可靠流、丢包恢复、拥塞控制和安全机制，可以避免一条流的数据缺口直接阻塞其他独立流的交付。

这不等于永远更快或完全无阻塞。共享带宽、拥塞、流内部顺序和头部依赖仍存在，选用要看网络、服务端和客户端支持。

HTTP/2 多路流仍共享 TCP 交付，HTTP/3 将数据顺序限制主要隔离在各 QUIC 流内

知识点详解：从一条连接里的消息，到多条流里的数据

同连接复用，不代表响应能任意穿插

假设页面同时需要 HTML、样式和图片。HTTP/1.1 可以复用连接，避免每个资源都重新建连接；但在同连接流水线模式下，响应需要按规则顺序返回，前面慢响应会影响后面。

浏览器曾常用多个连接获得并发。这里的连接复用和 HTTP/2 的流多路复用不是同一概念。

也不要把 HTTP/1.1 说成每请求必须新建 TCP。版本能力、客户端行为和具体连接设置要分开。

HTTP/2 把消息切成能标识所属流的帧

每条流有自己的标识，连接上可以交错发送不同流的帧。接收方知道哪些帧属于样式、哪些属于图片，不需要把一份完整响应全部发送完再开始另一份。

HPACK 则针对头字段的编码和重复，和压缩图片、压缩响应体不是同一个功能。多路复用也不表示服务器业务代码自然并行或不受资源限制。

这一层改善的是 HTTP 消息传输组织。若底层 TCP 不交付缺口之后的字节，上层帧仍然拿不到。

QUIC 把可靠顺序放到不同流内部

假设一个 QUIC 包里携带了图片流的数据，丢包后该流需要恢复缺失内容。另一条独立样式流的数据已经完整到达，可以继续交付，不必为了补齐图片流而统一等 TCP 字节缺口。

但同一流内部，仍需满足有序交付；若多个流的数据恰好都受丢包影响，也会分别等待。共享拥塞控制和连接资源会让它们间接相互影响。

HTTP/3 的头部采用 QPACK，仍要处理压缩依赖的阻塞控制。所以“HTTP/3 没有任何队头阻塞”超出了实际保证。

升级协议不是性能问题的唯一答案

QUIC 集成 TLS 安全能力，支持相关连接迁移机制，但真正效果受到网络、设备、路径和实现影响。有的网络对 UDP 不友好，客户端还需要回退。

如果页面慢在服务器查询或 JavaScript 长任务，切 HTTP 版本不会自动解决。测试应分开看连接建立、丢包网络、资源并发和应用处理。

面试里先指出哪一层堵住，再说明新版本处理哪一部分，远比只列“二进制、压缩、快”清楚。

本题机制参考：HTTP/1.1、HTTP/2、HTTP/3、QUIC。

面试官继续追问

HTTP/2 是加密协议吗？

协议的帧机制与加密不是同一件事。浏览器中的常见部署使用 TLS，但不能把二进制编码当作加密。

HTTP/3 用 UDP，为什么还可靠？

UDP 只负责承载数据报；QUIC 在其上实现可靠流和恢复机制，可靠性来自 QUIC，不是 UDP 本身。

HTTP/2 一条连接的并发越多越好吗？

不一定。流限制、带宽、服务端处理和共享连接上的故障都需要评估，避免无上限堆请求。

面试速记卡

HTTP/1.1：可复用连接，流水线响应有顺序约束。

HTTP/2：帧＋流，多路复用；头字段用 HPACK。

TCP：共享有序字节流仍可能形成传输层阻塞。

HTTP/3：QUIC 独立流，头字段用 QPACK。

边界：可靠不等于无等待，新协议不自动修应用瓶颈。