HTTP/2 多路复用：一条连接同时跑多个请求

一句话定义：HTTP/2 的多路复用（multiplexing）是指在同一条 TCP 连接上同时传输多个独立的请求和响应，彼此互不排队、交错进行。

它是怎么做到的

HTTP/1.1 的基本节奏是“一问一答”：一条连接上同一时刻只能处理一个请求，前一个响应没回来，后面的只能等。这就是应用层的队头阻塞（head-of-line blocking）。虽然 HTTP/1.1 也提供过流水线（pipelining），但响应必须按请求顺序返回，实际效果有限，浏览器干脆不用它，改为对同一个域名开好几条连接，靠“多开窗口”缓解。

HTTP/2 换了一种思路：把请求和响应切成一个个带编号的小块（帧，frame），不同请求的帧可以交替发送，接收方按编号重新拼装。每个请求-响应对叫一个流（stream）。好比原来一个窗口只接待一位客户、办完才叫下一位；现在改成取号制，柜台在几位客户之间来回推进，谁的材料先齐就先办谁。

和相邻概念的区别

关键在最后一列。HTTP/2 只在应用层解耦了请求，底下仍是一条 TCP 连接。TCP 保证字节按序到达，一旦中间某个包丢了，后面的字节即使收到了也得在内核缓冲区里等着，直到重传补上。这一等，所有流一起停摆——HTTP/2 解决的只是“谁先办”，没解决“路只有一条”。

所以 HTTP/3 直接换掉传输层，改用基于 UDP 的 QUIC，把“流”的概念下移到传输层：某条流丢包只影响它自己，其余流照常前进。QUIC 还把连接建立和加密握手合并，弱网下重连更快。

对你的实际意义

对开发者：并发请求多、单个请求又小的场景，比如页面加载大量静态资源、微服务之间频繁调用、调用大模型 API 时同时发起多个请求，以及流式返回（如 SSE）与其他请求共存时，HTTP/2 的收益最明显——省掉反复建连的开销，也不必靠“多开连接”这种笨办法。

但要记住一个反直觉的点：在丢包率高的网络里（地铁、电梯、跨国链路），HTTP/2 的单连接特性可能让它不如“开多条连接”的 HTTP/1.1 稳，因为一个丢包会拖住所有流。这也是为什么面向移动端和跨境访问的服务值得考虑启用 HTTP/3。此外，多路复用让同一条连接上混着不同来源的请求，服务端做限流、观测和排障时要按流而不是按连接来看，否则容易误判。

各协议的支持情况和部署细节，以浏览器与服务端的官方文档为准。