木-Star1. 为什么TCP会“不够用”：多路径的起点是痛点
先说一个我经常在培训时抛给学员的问题：一条TCP连接，能不能同时走两条网线？答案听起来有点反直觉——不能。标准TCP连接的四元组（源IP、源端口、目的IP、目的端口）一旦确定，数据就只能在这唯一一条路径上传输。哪怕你的手机同时开着Wi-Fi和5G，服务器上明明挂着两块千兆网卡，一条TCP流也只会霸占其中一条链路，另一条闲着。
这个限制在早年不算什么大问题，但现在越来越难受。视频会议卡顿、大文件同步慢、跨机房数据迁移要等半天，很多时候不是带宽不够，而是单条路径没法把多路资源都用起来。于是就有了MPTCP（Multipath TCP，多路径TCP）。它做的事情用一个比喻就能说清：普通TCP是一条单腿走路的连接，MPTCP让这条连接长出多条腿——每条腿对应一条独立的TCP子流，可以走不同的网卡、不同的IP、甚至不同的运营商网络，但应用层看到的仍然是一条普通的TCP连接。
MPTCP握手的本质，就是这套“长腿机制”的起点。在第一条子流建立时，双方通过TCP选项完成能力协商和密钥交换；之后新子流加入时，又有一套独立的握手流程。这两个握手阶段是理解MPTCP全部行为的钥匙——包括它怎么确保兼容普通TCP、怎么防止会话被劫持、怎么在多条路径上保证数据不乱序。这篇文章我会从标准三次握手出发，一层层拆解MPTCP是如何扩展它的，并结合Linux内核实测和Wireshark抓包，把整个握手过程彻底讲透。适合对TCP有一定基础、想深入理解MPTCP原理，或者正准备在实验室里跑MPTCP测试的人。
1.1 单条连接的天花板，以及MPTCP为什么能突破它
先看一个实际例子。假设你有一台双网卡服务器，分别接在电信和联通的线路上，各自带宽都是100Mbps。客户端也从两条线路发起访问。如果走标准TCP，一条连接只会被分配到其中一个IP和端口组合上，所以这条连接最多跑满100Mbps。除非应用层自己拆成多条连接，否则200Mbps的总带宽跟你没什么关系。
MPTCP的思路完全不同。它不改变应用层接口——你打开一个socket，connect，read/write，和使用普通TCP的代码一模一样。但内核里的MPTCP协议栈会把这个socket拆成多个子流（subflow），每个子流是完整的TCP连接，拥有自己的四元组。这样，一条MPTCP连接就可以同时占用电信和联通两条链路，理论吞吐上限接近两者之和。
这套机制要工作，首先就得解决一个问题：两个通信端点怎么知道对方支持MPTCP？如果不知道，就退化成普通TCP，保证兼容性。这就是MPTCP握手要做的第一件事。我在实验室里第一次跑通MPTCP时，第一反应是“这玩意儿的手续比TCP多好多”，但每一条消息都不是白加的，后面逐个拆给你看。
1.2 三个容易混淆的概念：MPTCP连接、子流、TCP连接
很多人看MPTCP文档会蒙圈，因为里面同时出现了Connection、Subflow、TCP Connection三个词。这里必须先厘清。
MPTCP连接是上层看到的逻辑连接，对应应用程序的一个socket，有一条统一的字节流。子流是底层真正跑数据的TCP连接，每个子流都有自己的序列号空间、自己的拥塞控制状态，可以随时建立和关闭。而TCP连接就是大家熟悉的标准TCP连接，一个子流本质上就是一个普通TCP连接，只是多了MPTCP选项。
这三个概念之间的关系可以想象成“总公司—分公司”的关系。MPTCP连接是总公司，负责把应用层的数据流拆成一段段分配给各分公司；每个分公司（子流）是独立的TCP连接，自己负责可靠传输；但它们都受总公司统一调度。握手的第一阶段——MP_CAPABLE协商——就是在确认“你我之间要不要成立这个总公司”；第二阶段——MP_JOIN——是给总公司新增分公司（新腿）。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 第一阶段握手：MP_CAPABLE如何把三次握手变成“连接骨架”
好消息是，MPTCP不需要发明一套全新的建连协议，它直接复用TCP三次握手，只是在SYN、SYN-ACK、ACK这三个报文里塞了一个特殊TCP选项——MP_CAPABLE。所以从网络抓包看，它依然遵循三次握手的时序，只是每个包都“胖”了一点。
2.1 三次握手还是那三次，但选项变了
TCP有个很优雅的设计叫“选项字段”（TCP Options），它位于TCP头部末尾，最多40字节。MPTCP就是靠在这里面注册了自己的私有选项，type编号是30。普通路由器、交换机不认识这个选项也没关系——它们按TCP原样转发就行；不支持MPTCP的对端则会直接忽略这个选项，双方自然就按普通TCP通信。
这样设计的高明之处在于：MPTCP的能力协商是“渐进增强”的。不需要额外端口，不需要协议栈之外的任何配合，只要两端都开启了MPTCP，握手时就都能识别出对方带着MP_CAPABLE选项，于是这条连接自动升级为MPTCP连接。我经常跟人说，MPTCP的兼容性思路就是“在别人家大楼的电梯里多加了一个楼层按钮，按不按取决于双方，但电梯还是那部电梯”。
2.2 第一次SYN：带着“钥匙”来敲门
MPTCP握手的第一个关键动作，发生在客户端发出的SYN报文里。除了标准的TCP头部，客户端会在MP_CAPABLE选项里放入自己随机生成的8字节Key，业内常叫Sender Key。为什么要放Key？这跟MPTCP的身份认证体系有关——后续所有子流的加入，都需要通过密钥来验证“你确实属于这条MPTCP连接”，防止第三方往连接里塞假子流。这个Key就是整条MPTCP连接的主密钥。
从报文层级看，客户端发出的SYN中MP_CAPABLE选项大概长这样（以RFC 8684描述的v1版本为例）：
code复制TCP Option - Multipath TCP
Kind: 30
Length: 12
Subtype: 0 (MP_CAPABLE)
Version: 1
Flags: 0x00
Sender Key: 8e2f6c1a9b3d4e5f
注意这里只有发送方自己的Key，长度是8字节；选项总长度12字节，多出的字节用于对齐TCP选项。内核会保存这个Key，等收到对方答复后，双方就共同持有两个Key。
2.3 SYN-ACK：双方交换密钥，连接正式“互信”
服务端收到带MP_CAPABLE的SYN后，如果自身也支持MPTCP，就回复SYN-ACK，并在MP_CAPABLE选项里同时带上自己的Key和刚才收到的客户端Key。这就是为什么SYN-ACK里的MP_CAPABLE选项比SYN里多了8字节——它要把通信双方的主密钥都向对方确认一遍。
这个“同时带上双方Key”的动作很关键。它不只是告诉客户端“我支持MPTCP”，也是在告诉客户端：“我已经记住了你的Key，后面不管谁来声称自己是这条连接的一部分，都必须证明自己知道完整的密钥组合。”从这里开始，双方各自持有一对Key（本地Key和远端Key），它们会作为后续生成Token和HMAC的基础材料。
此时，服务端还会自动创建第一个子流。你没看错，第一次三次握手建立起来的那个TCP连接，本身就是MPTCP连接的第一个子流。它不需要额外的MP_JOIN流程，握手完成的那一刻，这条“腿”就已经能用了。
2.4 ACK：最后一次握手确认，连接进入“可用状态”
客户端收到SYN-ACK后，回复标准的ACK，并在MP_CAPABLE选项里再次把双方的Key带上。至此三次握手完成，MPTCP连接建立。从应用层看，connect()返回成功，socket可以正常read/write了；从MPTCP层看，连接已经获得了完整的密钥材料，后续任何新子流都有资格发起MP_JOIN。
我在实验室里用Wireshark抓包时，经常看到有人在这里犯迷糊：为什么ACK里还要带一遍Key？答案是防伪造。TCP三次握手本身并不对端到端身份做强验证，任何人都可能伪造一个SYN-ACK试图像中间人一样劫持连接。MPTCP的Key交换确保了后续所有扩展操作都基于双方共享的秘密，这在子流加入阶段尤为重要。所以这个ACK里重复携带Key，本质上是在“锁定”握手结果。
2.5 一条路径上的“初腿”抓包实战
如果你想亲眼验证这个第一阶段握手，在Linux上跑起来并不难。需要内核5.6以上（我测试用的是5.15），并确保MPTCP模块已加载：
bash复制# 检查内核模块
modprobe mptcp
sysctl net.mptcp.enabled
# 如果显示 0，先开启
sysctl -w net.mptcp.enabled=1
两端都开启后，用iperf3打流量，同时tcpdump抓包：
bash复制tcpdump -i eth0 -s 200 -v 'tcp'
在抓包文件里，SYN、SYN-ACK、ACK三个包都能看到“Multipath TCP”选项，展开后分别能看到sender key、receiver key。如果某个包里的MP_CAPABLE选项丢失或长度不对，说明中间链路有设备在剥除未知TCP选项——这是MPTCP部署中最常见的坑，后文会专门展开。
3. 子流是怎么“长”出来的：MP_JOIN的完整四次握手
第一次握手建立的子流，只是MPTCP连接最初的“一条腿”。真正体现MPTCP能力的是后续动态添加子流——比如手机从Wi-Fi切换到5G时，新建一条5G子流，同时保留Wi-Fi子流继续传输数据。这个添加动作就是通过MP_JOIN完成的。
3.1 为什么新子流需要四次握手
让人困惑的第一个问题：标准TCP建连只要三次握手，为什么MP_JOIN要四次？
原因在于MP_JOIN不只是建立一条TCP连接，还要完成“认证”。新子流发送SYN时，对方需要确认：你这家伙真的是从已经建立的MPTCP连接里来的，而不是黑客想搭一条私生子连接偷数据？三次握手提供不了这个安全担保，因为TCP序列号的随机性在现实中被证明是不够的。于是MPTCP专门加了第四个ACK步骤，用于承载带密钥的HMAC结果，完成双向认证。
换句话说，MP_JOIN四次握手的结构是：前两次交换非加密材料（Token、随机数），第三次用HMAC证明身份，第四次由对端确认。四步缺一不可。
3.2 Token：新子流的“接头暗号”
假设Wi-Fi连接已经建好，现在要加一条5G子流。新子流的SYN报文里，除了标准MP_CAPABLE之外，MPTCP层使用的是MP_JOIN选项，里面包含一个4字节的Token。这个Token是从初始握手的Key里经过哈希截断生成的，具体计算方式为：
code复制Token = SHA-256(Sender Key) 的前 4 字节
Token的用途是让接收方快速定位到这个SYN要加入哪条MPTCP连接。服务端维护着一张Token到MPTCP连接状态的映射表，收到MP_JOIN后先查Token，找不到就直接拒绝。这样设计也是为了安全：Token本身不是密钥的完整形态，即使被抓包抓走，也无法逆推出完整的Key。
3.3 随机数、Address ID和HMAC：一道完整的身份验证链
MP_JOIN的SYN里还带了两样东西：一个4字节的随机数（Sender Random Number）和一个Address ID（地址标识）。
关于Address ID多说一句：它是MPTCP用来标识“源地址来自哪条路径”的1字节编号，和IP地址、端口组合没有一一对应的强制关系。它让对端即使遇到NAT地址变化，也能认出这是同一条路径的延续。比如客户端在Wi-Fi下用192.168.1.10发起子流，Address ID设为1；切换到5G后换成192.168.2.20，可以把新子流的Address ID设为2，这样对端就知道来源地址变了。
服务端收到SYN后，会回复SYN-ACK，并在MP_JOIN选项里带上自己的随机数和一段截断的HMAC。HMAC的计算涉及到之前握手交换的双向密钥和双方随机数，具体公式在RFC 8684里有完整定义。这里不背公式，你只需要理解它的作用：它像一个“签名”，证明发送方确实知道初始握手的密钥。伪造者哪怕能伪造一个MP_JOIN SYN，也计算不出正确的HMAC。
最后一个ACK是身份验证的收尾。发起方收到SYN-ACK后，根据共享密钥计算出自己的HMAC，放到第三次ACK的MP_JOIN选项里发过去。接收方验证通过后，回复一个纯ACK。至此，新子流正式建立，加入MPTCP连接。
3.4 一个完整的MP_JOIN时序解读
把整个流程串起来就是这样：
| 步骤 | 方向 | 报文 | 关键内容 |
|---|---|---|---|
| 1 | 发起方→接收方 | SYN + MP_JOIN | Token、随机数、Address ID |
| 2 | 接收方→发起方 | SYN-ACK + MP_JOIN | 随机数、截断HMAC、Address ID |
| 3 | 发起方→接收方 | ACK + MP_JOIN | 截断HMAC |
| 4 | 接收方→发起方 | ACK | 确认子流加入成功 |
这四次交互里，第1步和第2步其实还在建立TCP连接（完成序列号同步），第3步除了自身的ACK作用，还承担了MPTCP层的认证报文功能，第4步则是纯确认。所以从TCP层面看，MP_JOIN依然是“三次握手+一个额外确认”，多出来的那一步完全是为了MPTCP安全认证。
我在真实抓包中对比过：一条MPTCP连接建立1条初始子流，随后添加2条新子流。初始子流3个包搞定，之后每个新子流都要4个包。抓包文件里能清晰看到MP_JOIN的三种类型（SYN、SYNACK、ACK）分别出现。
3.5 实战中的子流数量限制与路径管理
子流并非想加多少就加多少。Linux内核里有独立的限制参数，默认每个MPTCP连接最多允许添加4条额外子流，可以通过以下命令查看和修改：
bash复制# 查看当前限制
ip mptcp limits show
# 设置为最多8条额外子流
ip mptcp limits set subflow 8
另外还需要给新子流指定源地址。比如我想让一条子流从192.168.1.10发出，要先把地址登记为endpoint：
bash复制# 添加一个endpoint，允许用于subflow
ip mptcp endpoint add 192.168.1.10 dev eth0 id 1 subflow
我在做双路径测试时，发现一个容易忽略的坑：如果两块网卡的IP不在同一个网段，默认路由可能不会让子流从第二块网卡发出。这时候要么显式添加endpoint，要么配置策略路由，否则即使MPTCP协议完全正常，子流也建不起来。
4. 数据如何“分腿走”：DSN、SSN与映射规则
握手只是解决了“能不能建多条腿”的问题。真正让MPTCP有价值的，是它在数据传输阶段如何把应用层的一条字节流，拆到多条子流上，还能保证接收方按照正确的顺序还原。这块涉及三个核心概念：DSN（数据序列号）、SSN（子流序列号）和Data Sequence Mapping（数据映射）。
4.1 DSN：应用层眼里的“总账本”
每条TCP子流都有自己的序列号，这是TCP保证可靠的基石。但如果MPTCP直接在每条子流上独立传输数据，接收方就无法知道“这条子流里的第100字节，在整条应用数据流里排第几”。所以MPTCP定义了一个全局的数据序列号空间——DSN。
DSN从0开始，按字节递增，它对应的是应用层看到的那条统一字节流的绝对位置。发送方在某个子流上发送数据时，会在TCP选项里带上一个映射关系，告诉对端：“这个子流的SSN为X的位置，对应MPTCP层的DSN为Y，这段数据在这个映射里占N字节。”接收方根据这些映射，把不同子流收到的数据块重新拼成完整有序的数据流。
举一个简化例子：假设DSN 0-999这1000字节要发出去，发送方把0-499分配给子流A，500-999分配给子流B。子流A上的映射就标记“SSN=1000对应DSN=0，长度500”，子流B上则标记“SSN=2000对应DSN=500，长度500”。接收方收到后，先按子流内部机制保证SSN连续，再根据映射表按DSN排序，最终向上的read()调用拿到的依然是从0开始连续的数据。
4.2 Data Sequence Mapping：一条子流上“贴标签”
实际传输时，这个映射关系是通过TCP选项Data Sequence Mapping（DSM）下发的。它包含三个核心字段：子流序列号（Subflow Sequence Number，即SSN）、数据序列号（Data Sequence Number，即DSN）和长度（Data-Level Length）。发送方每发一段数据，都会评估怎么切分，并在合适的报文里附上映射。
这里有一个关键经验：MPTCP并不要求每个TCP报文都携带DSM选项。为了节省TCP选项空间，映射通常是“一个映射覆盖一大段连续数据”的，只要子流上后续数据的相对顺序没变，就可以沿用同一个映射。只有发生路径调度切换、发送新的一段映射时，才需要重新携带DSM。这也是为什么MPTCP抓包看起来没有想象中那么“吵”——很多报文里并没有MPTCP选项，它们按普通TCP承载数据。
4.3 接收端重组：如何应对乱序和重复
多路径发送最大的副作用就是乱序。子流A可能走Wi-Fi，延迟5ms；子流B走5G，延迟20ms。发送方交叉发送的数据，到达接收方时顺序可能完全打乱。MPTCP接收端需要按DSN做重排序缓冲。具体逻辑是：
- 每收到一个数据块，先用DSM把SSN映射到DSN。
- 将数据放入以DSN为索引的重排队列。
- 只有当DSN连续时，才向上层交出数据。
这意味着即使子流B先到达，如果它对应的是DSN 500以后的数据，也只能等在队列里，直到子流A把DSN 0-499的数据补齐。这个机制保证了应用层看到的字节流跟普通TCP一样顺序一致。
不过，重排队列也带来了延迟风险。如果某条子流丢包，接收方就得等重传，这期间即使另一条子流的数据已经到了，也无法向上交付。因此MPTCP的调度策略非常重要。Linux内核里默认的调度器叫“default”（实际上按最小RTT优先），还有roundrobin（轮询）、redundant（所有子流发相同数据）等可选。在实验室里我实测过：Wi-Fi和有线延迟差距超过30ms时，roundrobin吞吐反而不如default策略，因为重排等待抵消了多路径带宽收益。
4.4 拥塞控制：多条腿共用一套“刹车”
还有一个常被忽略但极其重要的细节：MPTCP的拥塞控制必须协同多条子流，不能各自为政。如果一个子流检测到拥塞就自己减少窗口，而另一个子流照常猛发，整体公平性会受到破坏，甚至会把共享瓶颈链路的普通TCP连接饿死。
标准TCP在这里常用的Reno算法无法直接套用，因为每个子流有独立的cwnd（拥塞窗口）。MPTCP专门定义了“耦合拥塞控制”（Coupled Congestion Control），核心思路是所有子流共享一个总窗口的增量。简单说：每个ACK到来时，整体窗口增长的量除以子流数量，而不是每个子流都单独上涨。这样既利用了多条路径的总带宽，又不会比单条TCP更激进。Linux内核里可以通过以下命令选择拥塞控制算法：
bash复制# 查看当前MPTCP拥塞控制
sysctl net.mptcp.mptcp_enabled
# 设置耦合拥塞控制算法
sysctl net.mptcp.mptcp_congestion_control=olia
常见的选项有olia（opportunistic linked increases，兼顾公平与吞吐）、lia（linked increases）、balia（balanced linked adaptation）等。我之前在丢包率1%的模拟链路上对比过，olia的表现最均衡，而在纯局域网低丢包环境下，lia和默认没有明显差异。
5. 抓包实测：从Wireshark里看清MPTCP握手全过程
原理归原理，不亲眼看到报文，心里总是不踏实。我在实验室里搭了一套最简MPTCP环境，把握手过程完整抓了下来。这里把全过程以及分析思路写出来，你可以照着复现。
5.1 环境准备：两台Linux主机加一根网线就够
最简单的实验拓扑：两台Linux主机（内核5.6+），一台当客户端，一台当服务端，通过eth0直连。为了让MPTCP真正使用两条路径，我给客户端额外加了一个虚拟网卡tap1，配置另一个IP，然后启用endpoint。
bash复制# 服务端
ip addr add 192.168.10.1/24 dev eth0
ip link set eth0 up
sysctl -w net.mptcp.enabled=1
# 客户端
ip addr add 192.168.10.2/24 dev eth0
ip link set eth0 up
# 创建一个虚拟网卡，模拟第二条路径
ip link add tap1 type dummy
ip addr add 192.168.20.2/24 dev tap1
ip link set tap1 up
# 把第二个地址登记为可用endpoint
ip mptcp endpoint add 192.168.20.2 dev tap1 id 2 subflow
注意：严格来说dummy网卡不会真正传输数据，这里只是为了在握手过程中产生第二条子流。如果你手头有USB网卡或Wi-Fi，用真实链路更好。
启动抓包：
bash复制tcpdump -i any -s 200 -w mptcp_handshake.pcap 'tcp'
然后跑应用：
bash复制# 服务端监听
iperf3 -s
# 客户端连接
iperf3 -c 192.168.10.1 -t 10
5.2 抓包结果逐字段解读
用Wireshark打开抓包文件，过滤tcp.option.mptcp，能看到三个阶段的MPTCP选项。
第一阶段是Initial Subflow的MP_CAPABLE握手。展开第一个SYN包里的Multipath TCP选项，能看到：
- Subtype: 0 (MP_CAPABLE)
- Version: 1
- Sender Key: 一串16进制数
再展开SYN-ACK包，能看到两个Key：一个是对端发来的Sender Key，一个是本端生成的Receiver Key。第三次ACK中两个Key依然都在。到这里，初始子流建立完毕。
接下来看新增子流的MP_JOIN包，Wireshark里会在TCP选项段显示Subtype: 1 (MP_JOIN)。第一个SYN里可以看到Token字段，它是一串4字节的十六进制值；紧接着是Sender Random Number和Address ID。你可以试着用openssl验证Token生成逻辑：
bash复制# 假设Sender Key为 0102030405060708
echo -n "0102030405060708" | xxd -r -p | openssl dgst -sha256
# 取前4字节，与抓包里的Token对照
SYN-ACK包里的MP_JOIN则多了一个Truncated HMAC字段，Wireshark会直接标注“Sender’s Truncated HMAC”。第三个ACK里同样带有HMAC字段。第四个纯ACK已经没有MPTCP选项，因为它只是TCP层确认。
我用一个表格归纳三次握手和MP_JOIN的差异，方便你对照抓包：
| 报文 | TCP层作用 | MPTCP选项 | 关键内容 |
|---|---|---|---|
| SYN | 建连请求 | MP_CAPABLE | Sender Key |
| SYN-ACK | 应答 | MP_CAPABLE | Sender Key + Receiver Key |
| ACK | 建连完成 | MP_CAPABLE | 双方Key |
| SYN（新子流） | 建连请求 | MP_JOIN | Token、随机数、Address ID |
| SYN-ACK（新子流） | 应答 | MP_JOIN | 随机数、HMAC、Address ID |
| ACK（新子流） | 认证提交 | MP_JOIN | HMAC |
| ACK（新子流） | 确认 | 无 | - |
5.3 如何在Wireshark里快速定位异常
实际抓包中你会遇到几种常见异常，先列三个最典型的：
第一种，SYN带MP_CAPABLE，但SYN-ACK里的MP_CAPABLE丢失了。这通常说明服务端不支持MPTCP，或者中间设备剥除了选项。这时连接会正常建立，但降级为普通TCP，应用层感知不到。想确认是不是中间设备干的事，可以在两端分别抓包对比：如果在服务端入接口能看到MP_CAPABLE，但出接口没了，那就是服务端协议栈的问题；如果进出都没了，就要查中间链路。
第二种，MP_JOIN的SYN发了，但SYN-ACK里没有MP_JOIN选项。这多半是服务端没找到对应的Token，或者服务端的子流限制满了。用ip mptcp limits show查一下限制，再确认Token是否匹配，基本能定位。
第三种，MP_JOIN三次认证包都正常，但第四个ACK没有如期出现。这是典型的“第三个ACK里的HMAC验证失败”，常见原因是对端内核MPTCP版本不兼容，或者两端配置的密钥算法不一致。Linux上可以用dmesg看有没有MPTCP相关报错。
6. 踩过的坑和想提醒你的事
到这里，MPTCP握手的主要链路已经讲完。但在实际部署和实验里，有几个坑不是看RFC就能避开的，我逐个说下我踩过的经验。
6.1 中间盒会“抹掉”MPTCP选项
这是MPTCP落地最大的敌人。很多企业防火墙、运营商NAT设备、老旧交换机，对未知TCP选项的处理方式是直接删除，而不是忽略。一旦被删，MPTCP握手第一阶段就会失败，连接自动降级为普通TCP。如果只是丢一个选项还好，最怕的是遇到“半残”设备：握手时MPTCP选项还在，但数据传输阶段被截断或改写，导致MPTCP层校验失败。
如果是自己的实验环境，排查思路很简单：在两端分别抓包，对比SYN和SYN-ACK里的选项长度。如果客户端发出的是12字节MP_CAPABLE，到服务端变成0，那就坐实了中间盒在动手脚。生产环境里，解决办法是修改MPTCP启用策略，或者干脆只在可信链路内网段启用MPTCP。
6.2 TCP选项只有40字节，MPTCP会“挤掉”SACK和Timestamps
TCP头部的选项区上限40字节。MPTCP选项本身要占12-24字节，如果再加上Timestamps（10字节）、SACK（最多40字节）、Window Scale（3字节），很容易超出限制。Linux的TCP协议栈在面对这种情况时，会有取舍行为——有时候会丢弃SACK选项，而这在高丢包链路上非常致命。
我在一次跨机房传输实验中，MPTCP连接建立成功，但传输吞吐反而低于普通TCP，后来定位到是SACK被“挤掉”了。内核日志里有明确的提示。解决办法是合理调整MPTCP端点配置，不必要的情况下不要给一条连接挂太多子流，或者启用TCP的TFO（Fast Open）扩展来节省部分握手选项空间。实际项目里，我通常建议一条MPTCP连接控制在2-3条子流，既保留多路径收益，又给SACK留足空间。
6.3 ADD_ADDR与REMOVE_ADDR：地址变化时“腿”的增删
移动场景下，设备IP会频繁变化，比如从Wi-Fi切到5G，源地址从192.168.1.10变成192.168.2.20。此时旧的子流已经无法继续收发数据，MPTCP不能靠重建连接来解决问题——那样应用层连接就断了。它靠的是ADD_ADDR和REMOVE_ADDR这两个信令选项，在已有的MPTCP连接上动态通告地址变化。
ADD_ADDR由地址变更方主动发出，包含新地址、端口和Address ID；对端收到后，可以选择主动发起一条新的MP_JOIN子流连到新地址上。REMOVE_ADDR则用来撤销不再使用的地址。我在测试Wi-Fi和5G切换时，抓包能看到序列：旧子流收到RST或超时，客户端发出ADD_ADDR通告新地址，服务端随即发起一条新MP_JOIN子流到新地址，整个应用层TCP连接从未中断。这个机制是MPTCP在移动端能落地的重要原因。
如果你在抓包里看到ADD_ADDR但没有后续MP_JOIN，多半是接收端的路径管理策略没允许自动添加子流。Linux上可以通过ip mptcp limits和ip mptcp endpoint配合调整，也可以在sysctl里关闭自动路径管理，手动控制何时添加。
6.4 性能测试怎么测才靠谱
最后提醒一下性能测试。很多人测MPTCP喜欢用iperf3默认参数，结果发现带宽上不去，就得出“MPTCP没用”的结论。其实iperf3默认是单线程单连接，对MPTCP来说这反而是正确的测试方式——你想验证的正是“一条应用连接能不能吃满多条路径”。但关键是要选择合适的测速时长和消息大小，短时间测试容易受慢启动影响。
我常用的测试方法是：
bash复制# 服务端
iperf3 -s -p 5201
# 客户端，30秒，使用8个并行线程（模拟真实应用，但仍跑在同一条MPTCP连接上）
iperf3 -c 192.168.10.1 -p 5201 -t 30 -P 8 -M 1400
这里-P 8不是创建8条MPTCP连接，而是创建8个iperf3线程，所有线程的数据都通过同一个MPTCP socket发送，这样能更好地压满多路径带宽。如果想看每条子流的实时速率，Linux下可以用ss -tM查看socket的详细子流信息：
bash复制ss -tM dport :5201
输出里会列出每个子流对应的本地地址、远端地址、发送和接收队列。如果你在这里只看到一个子流，即使MPTCP握手成功，也可能是因为路径管理没有把第二个endpoint加进去，回头检查ip mptcp endpoint show。
我在多组实验中确认过一个规律：MPTCP在“两条物理链路延迟相近、带宽相似”时提升最明显，可以接近线性叠加；当一条链路延迟远高于另一条时，收益取决于调度器能否智能地把更多数据放到低延迟链路上。所以不要一上来就盲目追求“多长几条腿”，先想清楚你的场景里，多条路径是不是真的各具独立带宽。
关于MPTCP握手，最后再说一点个人心得。它两次握手的结构——一次MP_CAPABLE完成能力协商和密钥下发，多次MP_JOIN完成子流认证和动态添加——其实是很多现代传输层协议设计的通用范式：先用最小代价建立可信通道，再在可信通道上灵活扩展资源。理解了MPTCP握手，你再看其他多路径协议（比如SCTP的部分建连逻辑），会有一通百通的感觉。如果你正在准备实验或生产部署，建议先从双网卡直连的环境开始，抓包确认两个阶段握手都完整通过，再逐步加入NAT、防火墙、动态IP这些真实网络中的变量。