HTTP/1.1、HTTP/2、HTTP/3 的队头阻塞分别发生在哪里？

HTTP/1.1 支持持久连接，但常见请求模式中一个连接处理能力受限；即使使用流水线，响应也需要按请求顺序返回，前面的慢响应会阻挡后续响应，浏览器通常通过多个连接缓解。HTTP/2 把请求和响应拆成二进制帧，在同一个连接里用流标识多路复用，从 HTTP 层消除了这种按响应顺序排队的问题，并提供头部压缩等机制。

HTTP/2 常运行在 TCP 上。TCP 必须按序交付字节，某个报文丢失时，后续已到达的数据也可能等重传，使同一连接中多个 HTTP/2 流一起受影响，这是传输层的队头阻塞。HTTP/3 基于 QUIC，QUIC 使用 UDP 承载，但在其上实现可靠传输、拥塞控制、安全握手与多流管理；某个流丢包时，不需要让其他独立流都等待同一条有序字节流补齐。

HTTP/3 仍可能受带宽、拥塞控制、应用依赖、QPACK 阻塞等因素影响，不能说它消除了一切排队，更不能说 UDP 本身就提供可靠性。真实页面收益还受服务端、CDN、网络和资源数量影响，应以协商到的协议和实测指标判断。

参考：MDN HTTP 演进。

同一 HTTP/2 TCP 连接里 A、B 两流复用，若一段 TCP 字节丢失，即使 B 后面的字节已到达，也可能等待缺口补齐。QUIC 把可靠有序交付限定在各流等机制内，A 流丢包可不必阻止独立 B 流交付；但两者仍共享网络带宽与拥塞限制。

不要把 HTTP/3 说成“不可靠 UDP”。WebSocket 协议协商与 HTTP 各版本关系也有细节，回答基本机制时应说明具体版本。

HTTP/1.1 支持持久连接，但常见请求模式中一个连接处理能力受限；即使使用流水线，响应也需要按请求顺序返回，前面的慢响应会阻挡后续响应，浏览器通常通过多个连接缓解。HTTP/2 把请求和响应拆成二进制帧，在同一个连接里用流标识多路复用，从 HTTP 层消除了这种按响应顺序排队的问题，并提供头部压缩等机制。