摘要

  • QUIC 多路径第 21 版规范了路径协商、标识、验证、确认、状态与恢复，却明确把分组调度和详细重传策略留给端点。
  • 两个已验证 Path ID 只证明存在两个可区分的协议上下文，不证明有两份独立容量；它们可以共用四元组，更可能共用物理瓶颈。
  • 容量、韧性和业务收益必须由拓扑、拥塞、调度决策及应用结果共同证明，不能从路径数量倒推。

一次扩容复盘会上，供应商展示了最有说服力的一页：一条连接拥有两个 Path ID，两条路径都完成验证，两个拥塞控制状态各自正常。结论写成“可用容量提升至两倍”。然而压测一开始，两条曲线同时触顶，总吞吐几乎没有增加。

协议没有失效。失效的是从“两个身份”跳到“两份资源”的推理。

《Managing multiple paths for a QUIC connection》第 21 版在 2026 年 3 月获得 IESG 批准并进入 RFC Editor 队列；截至 10 月 2 日，状态为等待第二位编辑。它尚未成为 RFC，不能提前写成既成标准。但文本已经足够明确地划出一条重要边界：它解决多个路径如何在同一 QUIC 连接中被可靠表达的问题，不替使用者证明底层资源彼此独立。

端点会协商多路径能力。Path ID 单调增加且不得复用，每条路径拥有从零开始的独立分组编号空间。连接 ID 将相应状态绑定到路径；客户端发起路径，服务器验证；PATH_ACK、PATH_STATUS 与 PATH_ABANDON 分别承载确认、偏好和弃用信息；恢复及拥塞状态按路径维护。

这些机制非常具体，但“路径”是协议对象。草案明确允许不同 Path ID 使用相同的地址与端口四元组。即使四元组不同，也不能据此断言两条路径没有在基站、接入环、隧道出口、骨干端口或云端队列处汇合。

验证回答“能不能到”，不回答“有多少”

路径验证的核心意义，是确认对端能够在相应地址接收分组，并约束放大风险。它没有测量空闲带宽，也没有检查价格、流量额度、数据辖区或用户授权。一个路径可以已验证却拥塞；可以标记 AVAILABLE 却昂贵；可以在测试时通畅，却与主路径共用故障域。

AVAILABLE 也只是让对端按自己的逻辑分配流量。BACKUP 表示希望在仍有其他可用路径时保留该路径，但端点可以不采纳这种偏好；如果所有路径都为 BACKUP，草案没有规定统一的优先顺序。调度政策仍然属于实现和应用。

因此，“两条路径可用”最多是一项候选集事实。要声称容量增加，至少还需要说明瓶颈是否独立、两条路径怎样竞争、调度器是否真正投放负载，以及应用最终取得了什么结果。

独立控制状态不等于独立瓶颈

第 21 版要求按路径保存拥塞状态，这是为了让行为不同的路径能够分别响应，不是给物理拓扑盖章。若两个控制器同时向一个瓶颈加压，它们各自都可能遵守本地规则，而总效果却占据比单一流更多的份额。RFC 6356 针对多子流耦合拥塞控制讨论的公平性问题，正说明“每条路径各自正确”不能自动推出“整体公平”。

证据应从曲线的相关性继续向下追。两条路径的排队时延是否同步上升？丢包是否在同一时段出现？减载一条路径后，另一条是否立刻获得相近容量？路由和接入资料能否支持不同故障域？这些观察仍不一定给出唯一答案，却比 Path ID 的数量更接近资源事实。

PMTU 也具有路径属性。即使两条 Path ID 共用四元组，草案仍允许它们拥有不同的 PMTU。实现可以为了稳妥而采用共同的较小值，但那是本地简化，不是网络证明。若重传换到另一条路径，分帧方式可能改变。只记录“重传成功”，会丢失分组尺寸、路径选择和应用交付之间的联系。

调度器决定资源怎样被看见

多路径草案没有规定哪个路径承载下一个分组。调度器可以按时延、拥塞窗口、成本、流类型或私有指标选择。详细重传策略也在范围之外：可在原路径、另一条路径或多条路径上重传。

这种自由会反过来塑造证据。一个路径因为早期样本较好而获得更多流量，也就获得更多新样本；另一个路径因少用而显得“信息不足”。如果模型把样本数量当成置信度，最初的微小偏好可能自我强化。最终报告中的“最佳路径”也许是调度器长期偏爱的路径，而不是经过公平比较后的赢家。

PATH_ACK 还能经不同路径返回。所谓某条路径的 RTT，可能包含去程、另一条回程和调度器的选择。时间戳可以精确，归因却不完整。把复合 RTT 用作容量预测，会让测量误差进入下一轮调度。

对于有序流，分组到达也不是终点。后续字节即使从快路径抵达，应用仍可能等待慢路径上的早期缺口。跨路径重传成功，并不证明应用更早拿到可用数据。容量声称若只停在传输层，很容易把“移动了更多分组”误写成“完成了更多工作”。

一条可审计的容量证据链

运营方可以要求每次关键调度保留以下链条：

  1. Path ID、连接 ID 与当时的四元组；
  2. 验证结果及其时间；
  3. 双方的 AVAILABLE/BACKUP 信号；
  4. 候选路径的拥塞、丢包、PMTU 与确认回程；
  5. 共享或独立瓶颈的支持证据；
  6. 调度器版本、输入与原因码；
  7. 被分配的数据类别、流及截止时间；
  8. 成本、额度、安全与同意约束；
  9. 重传和乱序情况；
  10. 应用完成时间与质量结果；
  11. 可执行的回退方案。

这条链不会强迫所有实现采用同一调度算法。它只要求把协议事实、本地决定和业务结果分开保存。于是“容量没有增加”可以被进一步解释为共享瓶颈、错误调度、过期验证、PMTU 限制，或应用被有序交付阻塞，而不是笼统地归咎于多路径。

IESG 审议记录曾触及调度政策、路径数量、额度和同意等问题。文本获得批准，不等于某个厂商的调度器、某个套餐的成本模型或某个业务目标同时获得认证。标准化的是共同语言，不是每一个使用共同语言作出的决定。

严谨的结论应写成：当时观察到两个协议可接受路径；某版本策略按这些输入进行了分配；拓扑和测量提供了这些独立性证据；应用取得了这个结果。删除中间任一层，都会让“双路”从可检验事实滑向营销修辞。

来源