课程笔记：HTTP/2 新特性——多路复用
课程名称：计算机网络应用 核心摘要：本讲围绕 HTTP/2 的多路复用（Multiplexing）特性展开，先回顾 HTTP/1.1 持久连接与管道化技术存在的"队头阻塞"瓶颈，再阐述 HTTP/2 如何通过单一 TCP 连接承载数十/数百个并发 Stream（流）从根本上解决该问题，并解析 Stream、Frame、Stream ID 之间的关系及 WebSocket 的例外情形。
一、 核心概念与原理
- 持久连接（Persistent Connection）：HTTP/1.1 及之后增强版本中引入。建立一次 TCP 连接后不立即释放，可在同一连接上连续发送多个请求-响应对。
- 管道化技术（Pipelining）：HTTP/1.1 默认支持。允许客户端无需等待上一个请求的响应返回，即可连续发送多个请求。
- 关键限制：响应必须按请求的顺序返回。
- 致命缺陷：若第一个请求响应延迟，后续请求的响应即便服务端已生成也必须排队等待 → 即 队头阻塞（Head-of-Line Blocking）。
- 稳定性问题：HTTP 客户端必须随时准备应对 TCP 连接被关闭的情形，实际并不可靠。
- 多路复用（Multiplexing）：HTTP/2.0 引入的核心特性，本质是 流的复用。
- 前提：HTTP/2 连接是持久的，且通常只有一个 TCP 连接。
- 该单一 TCP 连接可承载 数十甚至数百个 Stream（流） 的并发复用。
- Stream（流）：在一个 TCP 连接内部建立的逻辑通道，可并发执行，互不干扰，具有隔离性。
- Frame（帧）：Stream 内部传输的数据单元；同一 Stream 内的帧必须有序，但不同 Stream 的帧可交错传输。
- Stream ID（流标识符）：每个 Stream 拥有唯一的整数 ID，由发起该流的一端分配；服务端据此对不同流的数据帧进行重组。
二、 技术细节与协议分析
1. HTTP/1.1 vs HTTP/2 连接模型对比
| 对比维度 | HTTP/1.1（含管道化） | HTTP/2 |
|---|---|---|
| TCP 连接数 | 可开多个（浏览器限制通常 4~6 个，配合域名分片） | 通常 单一 TCP 连接 |
| 请求/响应模式 | 串行；管道化下请求可连续发送但响应须按序 | Stream 并发执行，互不阻塞 |
| 队头阻塞 | 存在（HOL Blocking） | 从根本上解决 |
| 并发通道 | 依赖多开 TCP 连接 | 单连接内多 Stream 复用 |
| 数据交错的重组依据 | 无（按序返回） | 依据 Stream ID 重组 |
| 稳定性 | 连接可能被随时关闭 | 连接持久、可靠 |
| 效率 | 较低 | 远高于 HTTP/1.1 |
2. 多路复用工作机制
- 客户端与服务端建立一个持久 TCP 连接。
- 在该连接内部同时开启多个 Stream 通道（每个 Stream 类似于 HTTP/1.1 中的一个独立 TCP 通道）。
- 各 Stream 并发传输数据帧，不同 Stream 的帧在连接中混合交错传输。
- 到达对端后，依据帧头部携带的 Stream ID 将数据归入对应 Stream，完成数据流重组。
3. Stream 与 Frame 的并发规则
| 对象 | 是否有独立 ID | 是否可并发 | 说明 |
|---|---|---|---|
| Stream（流） | 有（Stream ID，整数） | 可并发 | 不同 Stream 间相互隔离、并发执行 |
| Frame（帧） | 无独立 ID | 不可并发 | 同一 Stream 内的帧必须有序；若需并发，则新开一个 Stream |
4. Stream 的建立与使用方式
- 单方面建立并使用：
- 客户端建立的流 → 仅由客户端向服务端发送数据。
- 服务端建立的流 → 仅由服务端向客户端发送数据。
- 双方共同维护（共享）：同一流上既可发送请求，也可接收响应，双向传输。
- 关闭：任一端点均可关闭 Stream（由操作系统底层实现，程序员无需手动处理）。
- ID 分配：Stream ID 由发起流的一端分配；一旦建立，对端也能获取该 ID，否则无法据 ID 重组数据。
5. 例外：WebSocket
- WebSocket 原生协议没有 Stream ID，未实现多路复用机制。
- 因此 WebSocket 不支持 HTTP/2 的多路复用特性，需特别注意。
三、 实践应用与配置命令
本讲以协议原理分析为主，未涉及具体实操命令。以下为理解多路复用的常用诊断与观察手段（供延伸学习）：
# 使用 curl 查看 HTTP/2 响应（需服务端支持 h2）
curl -I --http2 https://example.com
# 输出中 "HTTP/2 200" 表示已通过 HTTP/2 协议交互
# 利用 Chrome 开发者工具 → Network → Protocol 列可观察 h2 多路复用下的请求
# 使用 nghttp2 工具观察 HTTP/2 的 Stream 复用细节
nghttp -v https://example.com
# 输出中可见多个 STREAM[id=1] STREAM[id=3] 等并发流
四、 重点与难点提示
- 考点 1：HTTP/2 多路复用的本质是 Stream（流）的复用，而非 TCP 连接的复用。
- 考点 2：HTTP/2 通常只用 一个 TCP 连接，而 HTTP/1.1 依赖多开连接（4~6 个）+ 域名分片来提升并发。
- 考点 3：队头阻塞在 HTTP/1.1 管道化中无法根本解决，HTTP/2 通过 Stream 并发彻底消除。
- 考点 4：Stream 间可并发，Stream 内的 Frame 必须有序；帧无独立 ID，欲并发须新开 Stream。
- 考点 5：Stream ID 由发起方分配，对端据此重组数据流。
- 易错点：勿将"多路复用"误解为多开 TCP 连接；它指的是单连接内多 Stream 并发。
- 易错点：WebSocket 原生协议不支持 HTTP/2 多路复用（无 Stream ID）。
- 面试题：简述 HTTP/1.1 管道化与 HTTP/2 多路复用的区别？为何说 HTTP/2 解决了队头阻塞？
五、 课后疑问/遗留问题
- HTTP/2 虽解决了 HTTP 层的队头阻塞，但在 TCP 层 是否仍存在丢包导致的队头阻塞？后续课程是否会讲解 HTTP/3（QUIC）如何应对？
- Stream ID 的奇偶规则（客户端发起为奇数、服务端发起为偶数）具体如何分配？是否有限制？
- 实际生产环境中，如何通过抓包工具（如 Wireshark）直观观察 HTTP/2 帧（Frame）与流（Stream）的交错传输？
- HPACK 头部压缩与多路复用如何协同提升整体性能？二者关系将在后续课程展开。