摘要

  • RFC 9897 规定端点如何协商 MP-DCCP、通告地址，并把新增子流鉴权后接入既有连接。
  • MP_CONFIRM 与 MP_JOIN 证明的是边界清楚的控制事实，不能证明调度器用了该路径、报文及时抵达、重排成功，或应用获得了韧性。

控制台一片绿色。第二条子流完成握手，连接标识可解析，HMAC 也把这次加入绑定到创建首条子流的双方。此时服务负责人问：主路径恶化时，究竟哪一个关键报文走了备用路径？控制日志没有答案。

RFC 9897 于 2026 年 1 月以 Proposed Standard 发布，RFC Editor 记录确认其出版身份。它扩展的是 RFC 4340 所定义的 DCCP；后者仍提供受拥塞控制但不可靠的数据报服务。MP-DCCP 可把多条 DCCP 子流呈现为一个连接，却不会把数据报变成可靠字节流。

首条子流协商 Multipath Capable 特性并交换主机密钥材料。后续子流携带 MP_JOIN、对端连接标识和新随机数，MP_HMAC 用来确认加入者属于原连接。这一机制很重要，因为它把经过鉴权的关联与任意流的自我声明区分开来。但关联成功仍未说明调度器把哪一个应用报文分配到了这条子流。

地址通告还低一层。MP_ADDADDR 通告地址和可选端口，用 HMAC 保护，并用序号区别新旧信息。对端可以保存，也可以丢弃。MP_CONFIRM 让选项交换可靠，但 RFC 明确说，接收主机的后续处理不属于这项确认的语义。因此，通告被确认不等于子流建成；子流建成也不等于数据面真的使用它。

这种区分是规范有意留下的。MP-DCCP 提供连接级序号和 RTT 信息，可供可选重排使用，也传递路径优先级提示；发送端采用什么调度算法、接收端是否以及如何重排、何时按什么顺序增删子流，都交给端点。协议甚至不协商子流数量上限，实现需要按资源自行限制。

真正的服务行为就在这些本地决定中形成。移动策略可以在主路径不再适合时尝试备用路径，但怎样挑选最合适的源地址与目的地址组合仍是实现决定。并发使用时，调度器逐包选路，拥塞控制和重排共同塑造结果。多条子流还可能共享同一个瓶颈，所以“有两条路径”既不证明故障域独立，也不证明容量增加。

安全边界同样有限。RFC 9897 在自己的密钥模型内保护加入流程和部分控制消息，却不自带应用可能需要的全部密码学保证；它因此指向 DCCP 上的 DTLS等端到端保护。地址标识也不能消除所有中间盒问题。DCCP-UDP提供一种穿越封装，但 RFC 9897 明确把它放在 MP-DCCP 范围之外。

规范从 RFC 8684借用了多路径术语和信令思路，并在路径数量限制处引用 RFC 8041。这些资料是上下文，不能把 MPTCP 的交付属性或运行经验直接移植给 MP-DCCP。IANA DCCP 参数登记表证明 Feature 10、Option 46、版本 0 与各多路径子选项拥有权威编号，却不证明某个端点实现正确。

运营方需要把四本账连起来。控制账记录能力协商、地址通告、确认、加入、随机数、密钥类型和回退关闭。路径账记录调度选择、四元组、拥塞许可、发送时刻、丢包和共享瓶颈。接收账记录到达、序号缺口、迟到与重排。服务账记录应用是否达到明确的切换、时延、连续性或聚合目标。

Heng Lu 的最小初始规范说明 RFC 无需规定一个万能调度器：共享互操作规则应保持精简，未来运行决定留在能观察、能回滚的本地。运行代码优先要求拿出报文和服务证据；现实层则阻止控制日志里的鉴权符号越权成为应用结果的证明。

标准给第二条路径提供了有纪律的加入方式。只有证据越过这次加入继续向前，韧性才真正开始。

Sources