4. QUIC 传输层核心：Stream 机制
聊到 QUIC 的传输层，Stream 机制绝对是绕不开的核心。我刚开始接触 QUIC 时，最大的困惑就是——为什么 HTTP/2 已经有了流的概念，QUIC 还要再搞一套？后来踩了几个坑才明白，QUIC 的 Stream 和 HTTP/2 的 Stream 根本是两码事。一个在传输层，一个在应用层，层级不同，解决的问题也不同。
说白了，QUIC Stream 就是一条独立的、有序的字节流。你可以把它想象成一根根独立的水管，每根水管里流自己的数据，互不干扰。就算其中一根堵了，其他水管照常工作。这就是 QUIC 解决 HTTP/2 队头阻塞问题的关键。
4.1 流 ID 与流类型
每个 QUIC Stream 都有一个唯一的标识符——流 ID。这个 ID 可不是随便分配的，它里面藏着不少信息。
| 流 ID 位 | 含义 | 说明 |
|---|---|---|
| 最低位（bit 0） | 客户端/服务端发起 | 0 = 客户端发起，1 = 服务端发起 |
| 次低位（bit 1） | 单向/双向 | 0 = 双向，1 = 单向 |
| 高位 | 流序号 | 从 0 开始递增 |
举个例子：流 ID 为 0 的流，最低位是 0，说明是客户端发起的；次低位是 0，说明是双向流。流 ID 为 3 的流，二进制是 11，最低位是 1（服务端发起），次低位是 1（单向流）。
我个人习惯在抓包时先看流 ID 的最低两位，能快速判断流的角色和方向。曾经有一次排查线上问题，发现服务端主动创建了大量单向流，客户端处理不过来。一看流 ID，全是奇数且第二位为 1，立刻定位到是服务端某个模块的 bug。
流类型总结：
- 双向流（Bidirectional Stream）：双方都可以发送和接收数据。流 ID 的 bit 1 = 0。
- 单向流（Unidirectional Stream）：只有发起方可以发送数据，接收方只能接收。流 ID 的 bit 1 = 1。
你想想看，为什么需要单向流？其实很多场景下，数据流向是固定的。比如推送通知、日志上报，服务端只需要单向发送，客户端不需要回复。用单向流可以减少状态管理的复杂度。
4.2 流状态机
每个 QUIC Stream 都有自己的生命周期。我刚开始学的时候觉得状态机很绕，后来画了一张图，一下子就清晰了。
状态流转其实不复杂。核心就几点：
- 流从 IDLE 开始，一旦开始传输数据就进入 OPEN 状态。
- 当一端发送完数据并发送 FIN 标志，这一端进入 HALF_CLOSED 状态。
- 当另一端也发送完数据，流进入 CLOSED 状态。
- 如果中途出错或需要取消，可以直接发送 RESET_STREAM 帧，进入 RESET 状态。
避坑指南： 我曾经在实现 QUIC 客户端时，忘记处理 HALF_CLOSED 状态。结果服务端关闭了发送方向，客户端还在傻等数据。排查了半天才发现，是状态机没处理好。记住：HALF_CLOSED 是正常状态，不是异常。
4.3 流优先级与流量控制
多个 Stream 同时传输，谁先谁后？这就涉及到流优先级了。QUIC 本身没有强制规定优先级策略，但推荐使用 Extensible Priorities 方案。
优先级说白了就是给每个流贴个标签：
- 紧急度（Urgency）：0 到 7 的数字，数字越小越紧急。
- 增量（Incremental）：布尔值，表示是否允许其他流插队。
举个例子，HTTP/3 中 HTML 页面的优先级通常设为 0（最紧急），而图片、CSS 等资源可以设为 3 或 4。这样浏览器能先拿到 HTML，解析后再请求其他资源。
流量控制这块，QUIC 比 TCP 灵活得多。TCP 只有一个连接级别的流量控制窗口，而 QUIC 有 两层级：
| 层级 | 控制对象 | 帧类型 |
|---|---|---|
| 连接级（Connection-Level） | 所有 Stream 的总数据量 | MAX_DATA |
| 流级（Stream-Level） | 单个 Stream 的数据量 | MAX_STREAM_DATA |
我建议你在实现时，先分配连接级窗口，再在流之间动态分配。曾经有个项目，我们给每个流分配了固定窗口，结果某个大流占满了所有配额，其他小流活活饿死。后来改成动态分配，问题就解决了。
注意： 流量控制窗口不是越大越好。窗口太大，接收方内存压力大；窗口太小，吞吐量上不去。我个人习惯初始窗口设为 16KB，然后根据 RTT 和丢包率动态调整。
4.4 流并发限制
QUIC 允许同时打开多个流，但总得有个上限吧？不然接收方内存会被撑爆。这个上限通过 transport parameter 协商：
- initial_max_streams_bidi：初始允许的双向流数量。
- initial_max_streams_uni：初始允许的单向流数量。
默认值通常是 100 左右。但实际项目中，我见过有人设成 1000，结果客户端瞬间创建大量流，服务端直接 OOM。嗯，这里要注意：并发流数量要根据服务器内存和处理能力来定。
流并发限制的更新通过 MAX_STREAMS 帧实现。接收方可以随时增加这个上限。比如服务端处理能力上来了，可以发一个 MAX_STREAMS 帧告诉客户端：「你可以再开 50 个流」。
实践经验：
- 初始并发流数建议设为 50-100，根据实际负载调整。
- 不要一次性把所有流都打开，留一些余量应对突发请求。
- 监控流关闭后的资源回收，防止流泄漏。
我曾经遇到过一个诡异的问题：服务端明明设置了最大并发流为 200，但客户端总是报「流被拒绝」。抓包一看，原来是服务端发送的 MAX_STREAMS 帧被丢包了，客户端没收到更新。后来我们在客户端加了个重试机制，问题解决。
总结一下，QUIC Stream 机制的核心就是：独立、灵活、可控。独立意味着每个流互不影响；灵活体现在优先级和流量控制的多层级设计；可控则是通过流 ID、状态机和并发限制，让开发者能精细管理每个流的行为。理解了这些，QUIC 的传输层就算入门了。