Multipath TCP 让同一连接跨越多条路径

摘要

接入切换表面上是地址变化：一个地址失效，另一个地址可用。但对应用而言，真正有价值的并非地址本身，而是已经建立的会话状态与按顺序交付的字节。若必须重新建连，认证、请求状态乃至某些不能安全重放的操作都可能受到影响。

RFC 8684 把“连接”与“路径”拆开。一条 MPTCP 连接对应一个应用套接字，却可以包含多个子流。每个子流沿自己的路径表现为普通 TCP；连接层位于其上，维持应用所期待的可靠性与顺序。因此，一条子流退出，并不必然定义整条连接的终点。

这只是能力，不是保证。两端都必须成功协商 MPTCP，至少要有一条可用子流继续存在或能够建立，连接状态也必须保留。协议提供连续性的工具，却不替部署者证明无线覆盖、物理路由分离或备用路径质量。

第一条子流通过 MP_CAPABLE 表明双方支持 MPTCP，并交换该连接所需的密钥材料。若对端不支持，或途中设备让相关选项无法往返，连接可以安全回到普通 TCP。

新增子流不能仅凭另一个地址自动并入。新的握手携带 MP_JOIN：令牌指出它要加入哪条连接，随机数与基于初始密钥的 HMAC 用于确认这仍是同一对端点。即使认证通过，本地策略仍可拒绝。由此可见，第二条路径首先是一项准入决定，而非发现地址后的自然结果。

连接存续期间，ADD_ADDR 可以通告新地址，REMOVE_ADDR 可以撤销地址。地址标识符帮助信令应对 NAT 改写。但被通告的地址只是一名候选者；它不证明可达性、独立性、成本或性能。

控制边界由此清晰起来。网络提供可达性并影响实际转发路径；端点决定是否成功启用 MPTCP、哪些候选成为子流、哪些子流符合策略。旧式应用可能只看到一个普通套接字，却不知道路径与成本选择已在接口之下发生。

每条子流保留普通 TCP 的序号空间。MPTCP 另设一个 64 位连接级数据序号。DSS 信令把子流中的字节范围映射到这本总账，并可在连接层确认数据进度。

韧性来自这个双层结构。某条子流没有送达的数据，可以用相同的连接级序号在另一条子流上重传，并建立新的映射。接收应用看到的仍是同一条可靠、有序的字节流，无需自行合并两条独立 TCP 连接。

顺序也会带来代价。慢路径上的缺口可能阻挡已经从快路径到达的数据交付给应用。分组调度、跨路径重传与拥塞控制决定多路径究竟增加能力，还是增加乱序等待和状态负担。RFC 8041 把这些列为真实运维问题，而不是用“设备有两个接口”一笔带过。

RFC 8684 允许把子流标为常规或备用，并通过 MP_PRIO 请求改变优先级。一个看似简单的标志背后是商业选择：蜂窝链路可能提高可用性，却按流量计费；卫星路径可能可达，但时延很高；两条固定接入也可能共享同一管道或上游瓶颈。

RFC 6182 明确提醒，不同地址组合并不必然产生彼此独立的路径。它提出提高吞吐与韧性、维持 TCP 服务模型、避免在共享瓶颈对其他用户造成不公平影响等设计目标。这些目标不能替代特定网络中的测量结果。

因此，证据单位不应是“接口数量”，而应是协商后的连接：实际建立了哪些子流，哪些是备用，它们是否穿越不同故障域，连接级确认如何前进，哪些字节不得不换路重发。没有这些证据，多路径只是潜力标签。

中间设备可能删除 TCP 选项、改写地址或端口，甚至以不兼容方式修改载荷。RFC 8684 规定了安全反应：初始连接可以回退为普通 TCP；失效的新增子流可以被重置并移除；运行中失去有效映射的子流应被视为已经损坏。

于是，应用“仍能使用”并不证明多路径能力存在。只观察业务成功率的监控，会把两种完全不同的状态混为一谈：连接确实借另一条子流存活，或者 MPTCP 从未工作，只是普通 TCP 没有出错。Multipath TCP 让连接大于一条路径，也要求运维证据跨越所有子流。