MPTCP 深度解析系列（1/20）
你坐在一辆行驶中的汽车里，手机正在跟同事视频通话。车辆驶出地库，WiFi 信号消失，手机切到 4G------画面冻住了一秒，声音断了一拍，然后恢复。
这一秒的卡顿，几乎每个人都经历过。我们习惯性地归咎于"信号不好"，但真正的原因藏得更深：TCP 协议在 1981 年被设计出来的时候，根本没考虑过一台设备会同时拥有多个网络接口。
一条 TCP 连接，从出生到死亡，只能绑定一对 IP 地址。换了网络，就意味着换了 IP，就意味着连接断了。你的手机明明同时有 WiFi 和 4G 两条路，TCP 却只肯走一条------另一条路空着，它看都不看一眼。
这个持续了 40 多年的"单路径枷锁"，就是 MPTCP（Multipath TCP，多路径 TCP）要打破的东西。
这篇文章，我会带你从头到尾看清 MPTCP 的全貌：它为什么诞生、怎么工作、标准如何从实验走向成熟、以及它正在进入哪些你意想不到的战场。
一、TCP 的单路径困境
要理解 MPTCP，得先理解 TCP 的"病根"在哪里。
四元组：一条连接的"身份证"
每一条 TCP 连接，都由四个要素唯一标识：
scss
(源 IP, 源端口, 目的 IP, 目的端口)这四个值在连接建立的瞬间就被锁死了。源 IP 变了？对不起，这条连接内核就认不出来了，只能断开重连。
打个比方：TCP 连接就像一条单车道公路，从你家门口直通目的地。路修好之后，你只能走这一条。哪怕旁边新开了一条高速公路，你也没法换过去------因为你的"通行证"上写的是老路的地址。
现代设备的尴尬
这个设计在 1981 年完全合理------那时候一台电脑只有一块网卡。但 40 年后的今天：
- 智能手机同时连着 WiFi 和 4G/5G，但 TCP 只能用一个。你走出咖啡厅，WiFi 断了，TCP 连接就断了，即使 4G 信号满格。
- 数据中心服务器有多块网卡、多条链路，但 TCP 连接随机选一条路径。多条路径之间负载不均，有的拥堵有的空闲。
- 车联网设备（比如我们做的 T-Box，Telematics Box Unit）插着多张不同运营商的 SIM 卡，理论上有多条独立链路可用，但 TCP 只走其中一条。另外几条链路？纯粹浪费。
已有方案为什么不行？
在 MPTCP 之前，人们不是没尝试过解决这个问题：
SCTP（流控制传输协议） 天生支持多宿主（multi-homing），一个连接可以绑定多个 IP 地址。听起来完美？问题是 SCTP 不是 TCP------它是一个全新的传输层协议。绝大多数应用程序只认 TCP 和 UDP，中间设备（防火墙、NAT）也不认识 SCTP 的包。部署了十几年，SCTP 在公网上几乎没有存在感。
应用层多连接 是另一个思路：应用程序自己建多条 TCP 连接，分别走不同的网络接口。但这意味着每个应用都要自己实现数据分发、重组、拥塞控制------而且多条连接之间无法共享拥塞信息，可能互相抢带宽。
VPN 隧道 可以把多条链路封装在一起，但额外的封装头开销大，而且隧道本身也是一条 TCP 或 UDP 连接，并没有从根本上解决问题。
我们需要的是一个方案：既能用多条路径，又对应用程序透明，还能穿越现有的中间设备。 这就是 MPTCP 的设计目标。
图 1：传统 TCP 只能走一条路径，WiFi 断开即连接中断；MPTCP 同时使用多条路径，任一路径故障数据自动切换
二、MPTCP 的核心思想
一句话定义
MPTCP 的核心思想可以用一句话概括：
在一条逻辑上的 TCP 连接之下，同时使用多条网络路径传输数据。
对应用程序来说，它看到的还是一个普通的 TCP socket------connect()、send()、recv()，一切照旧。但在传输层内部，MPTCP 悄悄把数据分散到多条"子流"（subflow）上，每条子流走不同的网络路径。
架构：连接、子流与双层编号
MPTCP 的架构可以这样理解：
图 2：MPTCP 分层架构------应用层看到一个 socket，MPTCP 层将数据分发到多条子流，每条子流走不同的网络接口
这里有两个关键概念需要区分：
- MPTCP 连接 （Connection）：逻辑层面的连接，应用程序看到的就是它。它有一套全局的数据序列号（Data Sequence Number, DSN），保证整个字节流的有序和完整。
- 子流 （Subflow）：每条子流就是一条普通的 TCP 连接，走一条独立的网络路径。每条子流有自己的子流序列号（Subflow Sequence Number, SSN），独立做拥塞控制和重传。
DSN 和 SSN 的双层编号是 MPTCP 最精妙的设计之一。发送端把应用数据按 DSN 编号，然后把数据块分配给不同的子流，每条子流用自己的 SSN 独立传输。接收端根据 DSN 把从不同子流收到的数据重新排序，拼回完整的字节流交给应用程序。
这就像一家快递公司同时用顺丰、京东、中通三家发货。每家快递有自己的运单号（SSN），但包裹上还贴着一个统一的订单号（DSN）。收件人根据订单号把包裹按顺序拼起来，不管它们是哪家快递送到的。
三大核心能力
MPTCP 的多路径架构带来三种能力，适用于不同场景：
带宽聚合：多条路径的带宽理论上可以叠加。比如 WiFi 有 50Mbps，4G 有 30Mbps，MPTCP 最理想情况下能达到 80Mbps。当然，"理想情况"三个字很重要------实际效果受很多因素影响，这个话题我们在第 12 篇会专门讨论。
无缝切换：一条路径断了，数据自动转移到其他路径，应用程序无感知。这就是 Apple 用 MPTCP 解决 Siri 在 WiFi/蜂窝之间切换的核心原理。
冗余传输：同一份数据同时在多条路径上发送，哪条先到用哪条。延迟取多条路径中的最小值。这对延迟敏感的场景（比如远程驾驶）极有价值------我们在第 15 篇会深入讲。
设计哲学：向后兼容，优雅降级
MPTCP 的设计者做了一个极其务实的决定：不发明新协议，而是作为 TCP 的扩展来实现。
具体来说，MPTCP 的所有控制信息都放在 TCP 报文头的 Option 字段里。中间设备（NAT、防火墙、负载均衡器）看到的仍然是合法的 TCP 包，不会因为"不认识"而丢弃。
更巧妙的是降级策略：如果某个中间设备把 TCP Option 中的 MPTCP 信息剥离了（这在现实中确实会发生），MPTCP 能检测到这种情况，然后优雅地回退到普通 TCP------连接不会断，只是失去了多路径能力。
这种"能用就用多路径，不能用就退回单路径"的设计哲学，是 MPTCP 能在真实互联网上存活下来的关键原因。相比之下，SCTP 的态度是"要么全用我，要么别用"------结果就是几乎没人用。
三、RFC 6824 ------ 从零到一的实验
IETF 立项：把学术理想变成工程标准
多路径传输的学术研究在 2000 年代就已经很活跃了。但学术论文和可部署的互联网协议之间，隔着一道巨大的鸿沟：你的协议能不能穿过全球数百万台 NAT 和防火墙？能不能在丢包、乱序、路径异构的真实网络上稳定工作？
2009 年，IETF（互联网工程任务组）正式成立了 MPTCP 工作组，目标就是把多路径传输从论文变成标准。工作组的核心力量来自比利时 UCLouvain 大学的 Olivier Bonaventure 团队------他们后来也是 Linux 内核 MPTCP 实现的主要贡献者。
RFC 6824：第一版标准（2013 年 1 月）
经过四年的设计、争论和测试，MPTCP 的第一个正式规范 RFC 6824 在 2013 年 1 月发布。它的标准状态是 Experimental（实验性）------IETF 用这个状态表示"协议设计基本可行，但还需要更多实际部署经验来验证"。
RFC 6824 定义了 MPTCP 的四大核心机制：
MP_CAPABLE（能力协商）：在 TCP 三次握手中，客户端和服务端通过 TCP Option 交换 MPTCP 密钥，确认双方都支持 MPTCP。如果任何一方不支持，连接自动回退为普通 TCP。
MP_JOIN（子流加入）：当设备发现新的网络接口可用（比如连上了 WiFi），可以发起一条新的 TCP 连接作为子流，通过 MP_JOIN 选项把它"加入"到已有的 MPTCP 连接中。
ADD_ADDR / REMOVE_ADDR（地址通告）：一端可以主动告诉对端"我还有这些 IP 地址可用"或"这个地址不能用了"，让对端决定是否建立新的子流。
DSS（Data Sequence Signal，数据序列信号）：这是 MPTCP 数据传输的核心------每个数据包都携带 DSN 到 SSN 的映射关系，让接收端能把来自不同子流的数据正确重组。
安全方面，RFC 6824 使用 HMAC-SHA1 算法来验证子流加入请求的合法性，防止攻击者伪造子流劫持连接。
图 3：MPTCP 连接建立的三次握手------双方通过 MP_CAPABLE 选项交换密钥，v1 允许在第三个 ACK 中携带数据
Apple 的"豪赌"：iOS 7 与 Siri
RFC 6824 发布仅仅 8 个月后，2013 年 9 月，Apple 在 iOS 7 中为 Siri 启用了 MPTCP。
这是一个大胆的决定。当时 MPTCP 还只是一个"实验性"标准，全球几乎没有大规模部署的先例。但 Apple 有一个非常具体的痛点：Siri 的语音识别请求需要发送到云端处理，而用户经常在走路、开车时使用 Siri，手机会在 WiFi 和蜂窝网络之间频繁切换。 每次切换，TCP 连接就断了，Siri 就"听不见"了。
Apple 的实现很克制------他们没有用 MPTCP 做带宽聚合，而是用了 Active/Backup 模式：WiFi 是主路径，蜂窝网络是备用路径。正常情况下数据只走 WiFi；WiFi 断了，流量瞬间切到蜂窝，用户无感知。
这个策略非常聪明：
- 不需要同时在两条路径上发数据，避免了调度复杂性
- 不会额外消耗用户的蜂窝流量（备用路径平时不传数据）
- 只需要解决"切换不断连"这一个问题，就已经带来了巨大的体验提升
Apple 的部署证明了一件关键的事：MPTCP 可以在真实的互联网上、在数亿台设备上、穿过全球各种运营商的网络正常工作。 这给了整个 MPTCP 社区巨大的信心。
实验阶段暴露的问题
但七年的实验期也暴露了不少问题：
中间设备兼容性仍然是最大的挑战。部分运营商的 NAT 设备、防火墙、甚至某些"性能增强代理"（Performance Enhancing Proxy）会修改或剥离 TCP Option，导致 MPTCP 握手失败。Apple 的解决方案是：检测到 MPTCP 不可用时，立即回退到普通 TCP。简单粗暴，但有效。
安全性方面，HMAC-SHA1 的强度在 2013 年就已经受到质疑。虽然在 MPTCP 的场景下被直接攻破的风险不高，但作为一个要长期使用的标准，升级加密算法是迟早的事。
互操作性也有问题。RFC 6824 的某些细节描述不够精确，导致不同厂商的实现之间存在兼容性问题------你的 MPTCP 和我的 MPTCP 握手能成功，但某些边界情况下行为不一致。
这些问题，都成了下一版标准要解决的课题。
四、七年磨一剑 ------ RFC 8684 的蜕变
为什么花了七年？
从 2013 年的 RFC 6824 到 2020 年的 RFC 8684，中间隔了整整七年。为什么一个协议的升级要这么久？
因为这不是在实验室里写论文------每一个改动都必须在真实互联网上验证。改了安全算法，要确认全球的中间设备不会因此出问题；改了握手流程，要确认和旧版本的兼容性；改了数据序列号的生成方式，要确认不会引入新的安全漏洞。
再加上 IETF 的工作方式是"粗略共识"（rough consensus）------不是投票表决，而是要在邮件列表上反复讨论直到大多数人没有强烈反对。这个过程本身就很慢。
但这七年不是白等的。每一年的部署经验都在为 v1 积累弹药。
图 4：从 2009 年 IETF 立项到 2020 年标准化，MPTCP 经历了探索期、实验期、成熟期三个阶段
RFC 8684 的关键改进
2020 年 3 月，RFC 8684 正式发布，标准状态从 Experimental 升级为 Standards Track（标准化）。这是 IETF 对一个协议能给出的最高认可------意味着"这个协议足够成熟，我们推荐广泛部署"。
以下是 v0 到 v1 的核心变化：
| 维度 | RFC 6824（v0） | RFC 8684（v1） |
|---|---|---|
| 标准状态 | Experimental | Standards Track |
| 安全算法 | HMAC-SHA1 | HMAC-SHA256 |
| 初始数据 | MP_CAPABLE 不携带数据 | 第三个 ACK 可携带数据 |
| 版本协商 | 无明确机制 | MP_CAPABLE 携带版本号 |
| 连接关闭 | 机制不完善 | 新增 MP_FASTCLOSE、MP_TCPRST |
| DSN 安全 | 起始值为 0，可预测 | 基于密钥随机生成 |
| 中间设备应对 | 被动回退 | 更完善的检测和回退机制 |
逐个展开说：
安全算法升级：从 HMAC-SHA1 升级到 HMAC-SHA256。SHA1 的碰撞攻击在 2017 年已经被 Google 实际演示过（SHAttered 攻击），虽然对 HMAC 的影响有限，但升级到 SHA256 是必要的安全加固。
MP_CAPABLE 携带数据：v0 的三次握手中，第三个 ACK 不能携带应用数据。v1 允许在第三个 ACK 中就开始发送数据，减少了一个 RTT 的延迟。对于短连接场景（比如 HTTP 请求），这个优化很有意义。
版本协商机制：v1 在 MP_CAPABLE 选项中明确携带了版本号字段。当一端支持 v1 而另一端只支持 v0 时，可以协商降级到 v0；如果连 v0 都不支持，就回退到普通 TCP。这种三级回退机制（v1 → v0 → TCP）让协议演进变得平滑。
连接关闭改进 ：v0 对连接异常关闭的处理不够完善。v1 新增了 MP_FASTCLOSE （快速关闭整个 MPTCP 连接）和 MP_TCPRST（携带原因码的重置），让连接的生命周期管理更加健壮。
DSN 安全加固：v0 的数据序列号从 0 开始，攻击者可以预测 DSN 值来注入伪造数据。v1 的 DSN 初始值基于密钥随机生成，大幅提高了数据注入攻击的难度。
从"实验性"到"标准化"意味着什么？
在 IETF 的体系里，Experimental → Standards Track 相当于一个协议的"毕业典礼"。
对于设备厂商和软件开发者来说，这是一个明确的信号：MPTCP 不再是"试试看"的实验品，而是一个被互联网标准组织正式认可的、可以放心在产品中使用的协议。
Linux 内核的里程碑：v5.6 合入主线
几乎与 RFC 8684 同时，2020 年 3 月，Linux 内核 v5.6 正式将 MPTCP v1 合入主线。
这件事的意义怎么强调都不为过。在此之前，要在 Linux 上使用 MPTCP，你需要使用 UCLouvain 团队维护的 out-of-tree 补丁------自己打补丁、自己编译内核。这对于生产环境来说门槛太高了。
合入主线后：
- 所有主流 Linux 发行版都可以直接使用 MPTCP，无需自编译内核
- MPTCP 的代码接受整个 Linux 内核社区的审查和维护
- 后续的内核版本持续完善 MPTCP 功能：路径管理器（Path Manager）、包调度器（Packet Scheduler）、sysctl 配置接口......
从 v5.6 到今天，每个 Linux 内核版本都在给 MPTCP 添砖加瓦。这些内核实现的细节------路径管理器怎么决定何时创建子流、包调度器怎么决定数据走哪条路------我们会在系列的第 6、7 篇中深入源码来讲。
五、MPTCP 的新战场
标准化和内核合入只是起点。MPTCP 真正的故事，正在几个新战场上展开。
图 5：MPTCP 的四大应用场景------移动设备、车联网、数据中心、5G ATSSS
5G ATSSS：运营商级别的多路径
3GPP 在 5G 标准中定义了一个叫 ATSSS（Access Traffic Steering, Switching, Splitting）的框架，而 MPTCP 是这个框架的核心传输协议之一。
简单说，ATSSS 让运营商可以在网络侧控制用户的流量如何在多条接入链路（比如 WiFi 和 5G）之间分配。它定义了三种模式：
- Steering（导引）：新的连接根据策略选择走 WiFi 还是 5G
- Switching（切换）：已有连接在链路之间迁移
- Splitting（分流）：同一连接的数据同时在多条链路上传输
这意味着 MPTCP 不再只是端到端的事------运营商也开始参与多路径的管理。这个话题我们在系列第 17 篇会详细展开。
车联网与云控驾驶
这是我个人最关注的场景，也是我们团队正在实践的方向。
远程驾驶（Teleoperation）对网络有极其苛刻的要求：端到端延迟要低于 100ms，而且不能有长时间的中断------因为方向盘那头没有人类驾驶员兜底。
车端的 T-Box 设备通常插着多张 SIM 卡，分属不同运营商。这天然就是 MPTCP 的用武之地：
- 冗余模式：同一帧视频数据同时通过两个运营商的网络发送，哪条先到用哪条。即使一个运营商的基站瞬间拥塞，另一条路径也能兜住。
- 无缝切换：车辆在行驶中会频繁切换基站，单条链路的延迟会出现尖峰。多路径可以"吸收"这种突发。
SIGCOMM 2023 上有一篇论文 CellFusion，做的就是多路径车到云视频流传输，跟云控场景高度吻合。我们在系列第 14 篇会详细讲方案设计，第 16 篇会精读这篇论文。
MPTCP vs MPQUIC：下一代之争
最后不得不提的是 QUIC。
QUIC 协议（HTTP/3 的传输层）也在发展多路径能力------MPQUIC。它和 MPTCP 的根本区别在于：
- MPTCP 在内核态：性能好，但迭代慢，改一行代码要等内核发版
- MPQUIC 在用户态：迭代快，但性能有额外开销（用户态/内核态切换）
两者不是简单的替代关系。在需要极致性能的场景（比如高吞吐数据传输），MPTCP 有优势；在需要快速迭代和灵活控制的场景（比如 CDN、Web 应用），MPQUIC 可能更合适。
这个对比值得单独写一篇文章来讲------那就是我们系列的第 3 篇。
写在最后
回到开头那个视频通话的场景。
如果你的手机用上了 MPTCP，WiFi 断开的瞬间，数据已经在 4G 链路上继续传输了------你甚至不会注意到网络切换了。如果你坐的那辆车用上了 MPTCP，车载摄像头的视频流正在同时通过两个运营商的网络回传到云端------任何一条链路的波动都不会影响远程操控的安全性。
从 2009 年 IETF 立项，到 2013 年 RFC 6824 发布，到 Apple 在数亿台 iPhone 上部署，到 2020 年 RFC 8684 标准化和 Linux 内核合入主线------MPTCP 用了 11 年，从一个学术想法变成了互联网基础设施的一部分。
而它的故事才刚刚开始。5G ATSSS 把它推向了运营商网络，车联网把它推向了生命攸关的场景，MPQUIC 的崛起则在倒逼它不断进化。
下一篇预告：「MPTCP 连接建立全流程：MP_CAPABLE / MP_JOIN / ADD_ADDR 握手详解」------我们会深入到每一个 TCP Option 的字节级别，看看 MPTCP 的握手到底是怎么完成的。