摘要

  • MPTCP 通过无限映射退回普通 TCP 后，同一连接不得再恢复 MPTCP；这与暂时只用一条子流的 MPTCP 状态不同。
  • 想重新获得 MPTCP，必须另建连接，但新连接未必协商成功，原有应用工作也未必可以安全重做。

判断一次故障是否结束，往往先看流量是否恢复。对 MPTCP 的一种回退机制而言，这个问题问得还不够。字节可能一直没有停止传送，网络也可能重新具备多路径条件，但正在使用的连接已经无法重新利用 MPTCP。兼容性机制保住了眼前的通信，同时改变了它余下生命期的能力。

RFC 8684 第 3.7 节规定，通过无限映射回退以后，不得在同一连接中重新回到 MPTCP。这里的“同一连接”是关键限制：不是说设备从此不能用 MPTCP，不是账号被降级，也不是整个网络永久丧失多路径。它意味着这条连接已经作出的状态转换，不能靠等待链路恢复来撤销。

由此产生的管理问题不是要不要反对回退。回退可能恰恰避免了有价值的工作中断。问题在于，谁来决定这种状态可以维持多久，以及什么时候值得为恢复能力而换一条连接。传输层选择继续送达字节，并没有替应用回答这个问题。

先分清子流确认和连接确认

MPTCP 把一个有序字节流放在多条 TCP 子流上承载。每条子流有自己的序号，连接整体另有数据序号。DSS 信号建立二者的映射，使接收端能够知道某条子流中的字节应当放在整个数据流的什么位置。多条子流不只是多几个可以计数的入口，它们需要共同维持连接级的数据关系。

确认机制也因此分成两层。在正常 MPTCP 运行中，发送端不能只看到子流的 TCP 确认，就释放对应的发送缓存。数据还必须得到连接级确认，并且在所有曾经发送过这些数据的子流上得到确认。接收端可能先确认了某个 TCP 段，之后却因内存等原因丢弃为连接层暂存的数据。局部收到与整体确认不能混用。

无限映射改变了这套规则。它使用保留的数据级长度值零，为连接剩余部分建立映射。回退之后，发送端只使用子流确认来清理发送缓存；接收端应停止发送 MPTCP 的 Data ACK。通信按普通 TCP 继续。这里发生的是数据状态管理规则的改变，而不是调度器暂时选择了其中一条路径。

这些机制见 RFC 8684 第 3.3 与 3.7 节。它们确认的是规范所定义的传输状态，并不证明应用已经完成某项业务操作。决定是否断开并重做工作时，不能把传输确认当成业务结算凭证。

并非发现问题就整条回退

MPTCP 必须面对沿途设备删除选项或修改载荷的情况。载荷长度、内容或映射发生变化，都可能破坏子流序号与连接数据序号之间的关系。协商启用的校验和有助于发现相关问题，但它不是密码学身份认证，也不能据此认定有人恶意干预。

有多条子流时，校验失败可以通过关闭受影响子流、改在其他子流重传来处理。失败映射对应的数据不会得到连接级确认。其他子流仍可能保住 MPTCP。这与整条连接转为普通 TCP 是两种处置，不能因为两者都出现在“故障处理”中就合并描述。

只剩一条子流时，也不是无条件原地回退。要在不先关闭它的情况下使用无限映射，尚未确认的在途数据必须已知是连续的。子流数量为一不能证明这一点：当前子流可能还承载从另一条非正常关闭子流转来的重传数据。

MP_FAIL 指出失败映射开始处的数据序号。在适用的回退交换中，反方向也回到普通 TCP。如果数据不连续，规范还描述了通过重置、再可能建立一条新子流并立即应用无限映射的处理方式。这里的“新子流”仍服务于旧连接的回退，不是让这条旧连接重新拥有多路径能力的新 MPTCP 连接。

初始协商时丢失选项，与传输开始后映射受损，也不能统一套用一种恢复动作。有些情况应当关闭有问题的子流。规范没有提供一个能够无条件挽救所有损坏连接的转换开关。若没有协商校验和，这种载荷修改检测还需要来自其他层的信号。

一个计数，对应两种未来

仍处于 MPTCP 的连接，即使目前只有一条已建立或正在使用的子流，也可能继续增加子流。无限映射回退以后则不同：只允许一条子流发送，其他子流必须终止，同一连接不得再回到 MPTCP。监控页面都显示“一条”，并不代表它们具有相同的恢复能力。

所以，问题不能停留在“现在有几条路径”。还要知道连接是否仍然运行 MPTCP，还是已经完成向普通 TCP 的转换。数量是某个时点的观测；模式决定以后还允许发生哪些转换。只有前者而没有后者，就无法判断网络条件改善为什么没有带来预期能力。

应用能否看到这个区别，也需要证据。RFC 6897 描述的是抽象应用接口。其基本设计包括在建连前请求启用 MPTCP，建连后查询支持情况，以及查询已建立子流的地址。这并不证明某个今天实际部署的操作系统，按文中的符号名称提供了可靠的回退状态通知。附录中进一步讨论的回调能力属于后续研究方向，不能当成基本接口已经保证的功能。

该文档还提醒，子流列表会随时间过期。传统地址查询返回最初子流的地址，即使那条子流已经不再使用。日志中熟悉的对端地址因此不是当前路径清单。要把某个信号写进运维承诺，先要弄清实际实现究竟报告了什么。

恢复所需的是另一条连接

既然同一连接禁止回转，要重新争取 MPTCP 就需要另一条连接。这是从规范限制推导出的必要条件，不是下一次一定成功的充分条件。中间设备可能仍然产生同样的影响，多一个地址也不代表能够建立可用子流。

这使“维持当前工作”与“恢复多路径”成为两项需要分别考虑的动作。有限传输可以在旧连接中完成，再自然更新连接；长期会话可能需要更明确的更换边界。但应用是否允许恢复、哪些操作可以重做，必须由应用自己的完成与重放语义决定。换一个套接字不会自动消除旧操作结果不明的问题。

证据的年代与层级同样需要分清。RFC 8684 的发布记录 将其列为 2020 年 3 月的 Proposed Standard，替代旧版 MPTCP 规范；其已验证勘误 修正了 TCP Fast Open 示例中的过早数据确认，没有改变第 3.7 节的不可回转规则。RFC 6897 的记录 则标明它是 2013 年 3 月的 Informational 文档，本次勘误查询 未发现对应条目。本文据此分析设计约束，不声称测得任何现网的回退比例、事故原因或性能损失。

Lu Heng 在代理问题的讨论中，将决策权与后果承担放在同一张图景里；在说明 BTW 存在理由的文章中，他强调描述结构而非鼓动立场。用在这里，不是把回退说成失败，而是把它尚未解决的后续选择交代清楚：通信保住了，但谁有权决定何时更换它？