去年替一个做移动端实时音视频的团队看卡顿问题现象特别典型手机在WiFi信号衰减到临界点时自动切到蜂窝网络切换那一两秒画面必卡抓包看就是原连接的重传超时一路飙升等新连接建起来播放器缓冲已经见底了。当时他们第一反应是加大缓冲、加长重连退避治标不治本。真正的问题在于一条传输层连接从头到尾只绑定了一对地址物理链路一换这条连接的身份就失效了上层只能重建。多路径传输Multi-Path Transport就是冲着这个死穴去的——让一条逻辑连接同时跑在WiFi和蜂窝上或者在一条路断掉时把流量平移到另一条路上既不中断也不重建。这个领域里被讨论最多、工程落地最多的两套方案就是MPTCP和CMT-SCTP。前者是TCP的多路径扩展后者是SCTP在并发多路传输方向的延伸。很多人以为它们是同一件事的两种实现选哪个看喜好但真正跑过压测、调过内核参数、被中间设备坑过的人都知道两者的设计基因完全不同适用的场景也几乎不重叠。下面我按自己踩坑的顺序把这两套协议的机制、性能差异、落地条件拆开讲适合做移动端网络优化、CDN边缘调度、专网传输、以及想搞明白多路径到底难在哪儿的同学参考。1. 从一次换网卡顿说起多路径到底在解决什么1.1 单路径连接的三个死穴要理解多路径的价值得先把单路径的问题摊开。一条标准的TCP连接由四元组唯一标识源IP、源端口、目的IP、目的端口。这个设计在上世纪八十年代非常合理因为终端通常只有一块网卡、一个地址链路是固定的。但放到今天的移动设备上这套假设全面崩塌具体表现为三个绕不开的麻烦。第一个是地址变化即连接失效。手机从WiFi切到蜂窝源IP从内网地址变成运营商分配的地址四元组变了内核不会把新地址上的数据包认作旧连接的一部分只能走重连流程。TCP的重连意味着重新三次握手、重新慢启动、重新探测路径MTU一套下来几百毫秒到几秒不等对实时业务是致命的。第二个是带宽天花板锁死在单条链路上。哪怕用户同时开着WiFi和蜂窝两条链路加起来有80Mbps一条TCP流也只能用其中一条另一条纯闲置。更常见的情况是WiFi质量差、带宽低但免费蜂窝带宽高但计费用户希望能用WiFi就用WiFi而单路径协议没有任何表达这种偏好的手段。第三个是故障恢复只能靠重传超时。链路中途劣化时TCP要等到RTO触发、重传若干次、甚至等到上层超时才能确认路径真的不可用。这段时间里应用层看到的就是连接还在但数据不动了也就是俗称的假死。1.2 聚合、冗余、平滑迁移三种截然不同的用法多路径传输听起来是一个功能实际落地时至少对应三种完全不同的使用意图选型前必须先想清楚自己要哪一种因为不同协议对这三种意图的支持程度差别很大。带宽聚合是把多条路径的容量叠加起来用目标是吞吐量最大化。典型场景是大文件分发、备份同步、高清视频上传。这件事的技术难点不在于同时发包而在于接收端的乱序重组和发送端的拥塞控制耦合——两条路径的RTT、带宽、丢包率都不一样包到达的顺序会严重错乱接收缓冲区压力陡增而且如果拥塞控制各自为政聚合流会抢走单路径流的带宽形成公平性问题。冗余传输是把同一份数据在多条路径上各发一遍谁先到用谁。它不追求吞吐追求的是极低时延和高可靠性。实时音视频、工业控制指令、高频交易报单都属于这一类。这种模式对带宽是浪费的但换来了丢包场景下几乎零等待的重传效果。平滑迁移介于两者之间平时只用主路径主路径劣化时把流量切到备路径且不重建连接。这是移动端最常见的诉求也是最容易验证价值的一种用法。很多团队一开始奔着聚合去做着做着发现业务真正需要的是迁移白白增加了复杂度。这一点我在后面选型章节还会再提。1.3 为什么这件事非得下沉到传输层做有人会问应用层自己做多路复用不行吗比如同时开两条TCP连接一条走WiFi一条走蜂窝应用层做分片和重组。技术上可行但代价很高。应用层方案的问题在于它拿不到网络的真实状态。拥塞窗口、RTT估计、丢包检测、重传决策这些信息都在内核里应用层只能靠自己的应用层确认和超时来推断精度差一大截。而且应用层重传意味着数据要重新走一遍用户态到内核态的路径延迟比内核重传高出一个量级。更麻烦的是公平性——应用层开两条流在网络看来就是两条独立的TCP流它们会各自抢占带宽对同链路上的其他流量不友好也容易被中间的流量管理设备盯上。传输层做多路径最大的优势是能复用已有的拥塞控制框架和重传机制把多路径带来的额外复杂度路径管理、序列号映射、调度决策封装在一个大家已经信任的语义边界之内。上层应用看到的还是一条可靠的、有序的字节流改动量极小。这也是MPTCP能在Linux内核里被接受的根本原因——它对socket API的改动几乎为零。2. MPTCP的工程实现在TCP地基上盖二层楼2.1 一次握手把两端的账本对齐MPTCP最巧妙的地方在于它没有发明新的传输层协议号而是把自己伪装成一个TCP选项。这意味着中间设备只要不主动丢弃未知选项流量就能穿过去。代价是握手阶段要额外小心。连接建立时客户端在SYN里带上MP_CAPABLE选项和一个32位或64位的密钥。服务端如果支持在SYN-ACK里回自己的密钥。客户端最后在ACK里把双方的密钥回显一遍完成确认并带上连接级的标志位。这三步走完两端就建立了一个连接级的上下文后续所有子流都挂在这个上下文下面。这里有个实战中必须知道的细节MP_CAPABLE的回退机制。如果中间的防火墙或负载均衡器不认识这个选项直接丢包客户端会在超时后重试一次不带MP_CAPABLE的普通SYN。连接能建起来但退化成单路径TCP。这个设计保证了兼容性但也带来一个隐蔽的问题——你在抓包时看到连接正常却怎么也聚合不起来八成就是第一次SYN被中间设备吃掉了。排查方法是看握手阶段有没有出现两次SYN或者用ss -M确认这条连接是否被识别为MPTCP。提示判断一条连接是否真的走了MPTCP不要只看能不能连通要看内核有没有把它列进MPTCP连接表。连得上但没列出说明已经回退了。2.2 子流的增删与地址通告的安全设计主连接建立后两端需要知道对方还有哪些可用地址。MPTCP用ADD_ADDR和REMOVE_ADDR两个选项来交换这个信息。这里的设计很讲究地址通告不是明文裸奔的而是带一个基于密钥的HMAC签名防止路径上有人伪造地址把流量引到别处。签名这个设计在安全上是必要的但带来一个工程后果——地址通告必须在已建立的子流上发送因为只有已建立的子流才共享密钥。这就形成了一个先有鸡还是先有蛋的问题要开新子流得先通告地址要通告地址得先有子流。实际解法是主连接本身就算第一条子流地址通告在主连接上发对端收到后主动发起MP_JOIN去建立新子流。MP_JOIN的流程是三次握手加一轮HMAC校验发起方带上自己的token和随机数响应方回自己的随机数和HMAC发起方再回一个HMAC确认。这个流程能防止别人拿着截获的token来劫持子流。Linux内核里的操作方式是# 服务端把本机可用地址作为信号通告出去 ip mptcp endpoint add 10.20.0.11 dev eth0 signal # 客户端主动用某个本地地址发起子流 ip mptcp endpoint add 192.168.50.20 dev wlan0 subflow # 限制子流总数和可接受的对端地址通告数 ip mptcp limits set subflows 4 add_addr_accepted 2signal和subflow这两个标志位是最容易搞混的地方。signal表示我愿意把我的这个地址告诉对端让对端来连我subflow表示我想用这个本地地址主动去连对端。一个endpoint可以同时具备两个标志。做移动端场景时通常客户端只配subflow不配signal因为手机的WiFi地址在内网对端根本连不进来。2.3 DSS映射多路径乱序问题的核心解法这是MPTCP整个设计里最核心、也最难理解的部分。两条路径同时发数据接收端收到的包顺序一定是乱的——WiFi路径RTT 10ms蜂窝路径RTT 60ms同一个时刻发出的包走WiFi的早就到了。TCP原有的序列号机制在单路径上没问题多路径下就完全失效了。MPTCP的解法是引入两层序列号子流序列号SSN和数据序列号DSN。每条子流有自己的SSN和普通TCP的序列号语义一致用于该路径上的丢包重传。DSN是连接级的标识这块数据在整个字节流里的位置。DSS选项负责把SSN映射到DSN接收端靠这个映射把来自不同路径的数据块重新拼成有序的字节流。这个设计带来的直接后果是接收缓冲区需求大幅上升。慢路径上发的数据块在快路径上来回跑好几趟了还没到接收端必须把它后面的数据全部缓存着等。异质链路下RTT差距越大需要的缓冲区越大内核参数net.ipv4.tcp_rmem的上限就得相应调高。我见过一次线上问题WiFi RTT 8ms、LTE RTT 90ms默认接收缓冲根本不够表现是吞吐量莫名其妙地只有单路径的60%——因为缓冲区一满快路径就被流控挡住了。注意异构链路做聚合接收缓冲区要按最快路径的带宽 × 最慢路径的RTT差来估算而不是按单路径的老经验算。2.4 拥塞控制算法的耦合程度决定了公平性MPTCP有四种常见的拥塞控制算法LIA、OLIA、Balia、wVegas。它们解决的是同一个矛盾既要让聚合流量利用多条路径的容量又不能比对同链路上其他流量形成碾压。LIA的思路最直观每条子流的拥塞窗口增长速度取决于这条路径的窗口占该连接所有窗口之和的比例和这条路径的最优窗口之间的关系。如果某条路径的窗口已经达到它在单路径情况下的合理水平就不再激进增长把增量让给其他路径。这样做的结果是如果某条路径拥塞流量会自动向其他路径倾斜实现负载均衡。OLIA在这个基础上改进了收敛性尤其在不平衡链路下表现更好。Balia走的是另一套路子引入一个虚拟的补偿机制让每条子流的表现接近单独运行时的样子。实际选择上我的经验是同构链路两条带宽RTT接近的路径用默认的LIA就够异构链路优先试OLIA尤其是一条宽带低延迟加一条窄带高延迟的组合OLIA的收敛速度和稳定性明显更好。# 查看当前使用的算法 sysctl net.mptcp.congestion_control # 切换到OLIA需要内核编译时包含该算法 sysctl -w net.mptcp.congestion_contrololia值得注意的是MPTCP的拥塞控制算法并不是在用户态随便换的很多发行版的内核只编译了cubic和lia想用OLIA得自己确认/proc/sys/net/mptcp/available_congestion_control里有没有列出。3. CMT-SCTP的路径从电信信令网走出来的另一套基因3.1 SCTP的多宿本来不是为聚合设计的要理解CMT-SCTP必须先把SCTP原生的多宿特性讲清楚因为这两者经常被混为一谈。SCTP设计之初的诉求是电信信令传输的可靠性。它有一条关联association的概念一条关联可以绑定多个IP地址但这些地址的作用是故障切换不是并发传输。同一时刻只有一条路径是主路径其余是备路径靠心跳包定期探测可达性。主路径失效时关联会自动把传输切到备路径上这个切换对上层的socket API完全透明不重建关联。这个机制和MPTCP的平滑迁移非常像但有个本质差别SCTP的多宿切换发生在传输层内部不需要对端配合。只要关联已经建立本地主路径挂了本地直接换源地址发包对端接受来自不同地址的包因为关联ID识别而非四元组识别。这就是SCTP的四路握手和验证标签Verification Tag设计带来的好处。而CMTConcurrent Multipath Transfer是在这个基础上做的扩展让多条路径同时传数据而不是只做主备。从多宿到多路径一字之差复杂度差了一个数量级。3.2 接收窗口共享带来的rWND阻塞CMT-SCTP在学术论文里被讨论最多的问题就是rWND阻塞。SCTP的接收窗口是关联级的只有一个值所有路径共享。这个设计在故障切换场景下完全合理——反正同一时刻只有一条路在传。但一旦多条路径并发问题就来了。假设路径A带宽高延迟低路径B带宽低延迟高。发送端按照各自的拥塞窗口往两条路上发数据接收端收到后要按TSN传输序列号重组。如果路径B上有一个包迟迟不到接收端缓冲区里已经堆积了大量路径A的数据但因为一个TSN空洞整个接收窗口无法前移。窗口不前移SCTP协议规定就不能给发送端发新的窗口更新于是路径A也被迫停下来。这就是所谓的一条慢路拖死整条关联。同一个问题在MPTCP里也存在但MPTCP的处理更灵活一些它有单独的接收缓冲区通告机制MPTCP级别的流控而且Linux内核实现里对大缓冲区做了不少优化。SCTP的实现层面则更刚性尤其是早期的内核实现窗口管理非常保守。学术界对这个问题的解法是引入按路径的接收窗口但这就破坏了SCTP单一序列空间的设计美感也让协议实现复杂度上升。3.3 重传与路径独立性的内在冲突第二个硬伤是重传策略。SCTP的重传默认走主路径CMT场景下如果简单沿用这个策略慢路径上丢的包会跑到快路径上重传造成两个问题一是快路径的拥塞窗口被额外流量打乱二是接收端的乱序程度进一步加剧。改进方案是按路径重传哪条路上丢的就在哪条路上重传。听起来合理但和SCTP的快速重传机制冲突。SCTP的快速重传靠的是Gap Ack Report接收端报告我收到了TSN 100、101、103缺102。发送端收到三次这样的报告就快速重传102。在多路径下接收端的报告可能来自不同的路径发送端很难判断这个Gap是路径A造成的还是路径B造成的重传决策容易失准。业界有几个变体解决这个问题A-CMTAdvertised CMT通过调整窗口通告来缓解rWND阻塞CMT/RM引入潜在确认机制改进重传LS-SCTP用捆绑的方式减少确认开销。这些方案在仿真里效果都不错但落到真实网络里效果打折扣。3.4 中间盒兼容性SCTP落地最难迈的坎如果只看协议设计的优雅程度SCTP其实比TCP更先进四路握手防SYN flood、消息边界天然保留、多流避免队头阻塞、多宿原生支持。但它在公网上的普及率低得可怜根本原因就一个——中间设备不认识它。SCTP的IP协议号是132不是TCP的6也不是UDP的17。大量家用路由器、企业防火墙、运营商的NAT设备默认只放行TCP和UDPSCTP包直接被丢。更麻烦的是NATSCTP的多宿特性要求对端能直接访问本地的多个地址而在NAT后面这些地址都是私有的根本不可达。这就是为什么SCTP的实战部署几乎全部集中在可控网络里运营商内部信令网用M2PA、M3UA承载信令、数据中心内部的东西向流量、专网环境。一旦要跨公网就得靠隧道封装把SCTP包塞进UDP里而封装又引入了额外开销和MTU问题把原本的性能优势吃掉一大截。CMT-SCTP的处境更尴尬它连标准内核都不支持。Linux主线的SCTP实现只支持多宿故障切换要做并发多路径传输必须打补丁或者用用户态协议栈。用户态协议栈比如usrsctp性能远不如内核态一次系统调用的开销就能把多路径带来的收益抹平。所以在真实环境里CMT-SCTP更多停留在仿真验证阶段用ns-3跑出漂亮的曲线图但真正上生产的案例屈指可数。4. 把两者放进同一张测试台性能对比怎么做才不失真4.1 对比维度不能只看峰值吞吐网上不少对比文章喜欢贴一张聚合带宽达到两条链路之和的95%的图看着很漂亮但这种测试条件往往极度理想化两条同构链路、零丢包、同RTT、接收缓冲区调到最大。真实环境下这些条件一个都不满足。我做对比时习惯从六个维度看缺一个结论就可能翻车维度说明常见误区聚合吞吐多路径并发时的总吞吐只测同构链路忽略异构切换时延主路径失效到流量恢复的时间只测断开不测劣化但未断公平性对同链路单路径流的影响不做对照实验只看自己CPU开销每Gbps吞吐占用的CPU周期忽略接收端重组开销内存占用接收缓冲区峰值用默认参数测不做压力测试部署成本中间设备兼容性、内核依赖实验室环境跑通就以为能上线其中切换时延这一项最容易被低估。很多团队测的是网线拔掉多久恢复这个数字通常很好看因为断开是明确的信号。真正难的是劣化但未断——WiFi信号从-60dBm慢慢衰减到-85dBm丢包率从0%升到30%但链路还在这时候协议怎么判断该切、切多少、切多快。这才是移动场景的真实工况。4.2 对称链路与非对称链路的结论会反转这是我认为对比测试里最关键的一条经验在对称链路上MPTCP几乎全面胜出在非对称链路上两者的差距会急剧缩小甚至在某些场景下CMT的设计反而有优势。对称链路比如两条50Mbps、RTT都是20ms的链路下MPTCP的调度器可以非常激进地往两条路上均匀分发乱序程度可控接收缓冲区压力小聚合效率轻松达到90%以上。CMT在同等条件下理论上也能做到但因为rWND共享的问题实测通常会掉到70%到80%。非对称链路比如WiFi 100Mbps/RTT 5ms LTE 20Mbps/RTT 80ms下情况完全不同。MPTCP如果调度器策略不当会往慢路径上塞过多数据导致快路径被乱序拖累。这时候需要依赖调度器做智能决策——Linux内核从6.x开始引入了可插拔调度器默认策略是优先填满RTT最低的子流只在快路径拥塞窗口用尽时才往慢路径分。这个策略在异构链路下效果不错但也不是万能的。# 查看和切换调度器内核6.x及以上 sysctl net.mptcp.scheduler # 可选值通常包括 default / redundant / ndiffports / burst sysctl -w net.mptcp.schedulerredundantredundant调度器就是把数据在所有子流上各发一份牺牲带宽换时延和可靠性专门给实时业务用。ndiffports是单机多端口模拟多路径常用于单网卡环境下做实验不是真正的多路径。CMT在非对称链路上的表现则更有意思。因为它有明确的主路径概念当配置成主路径优先、备路径补充的模式时反而避免了盲目聚合带来的乱序问题。这也是为什么有些专网场景下工程师宁愿用SCTP的多宿切换也不愿意用MPTCP的聚合——他们要的本来就不是聚合。4.3 一条对照表看清差异把前面几节的内容收敛成一张表方便对照对比项MPTCPCMT-SCTP协议基础TCP扩展选项承载独立传输层协议协议号132连接标识仍依赖四元组 token验证标签与地址解耦多路径能力原生并发聚合需扩展标准实现仅主备切换握手开销三次握手 密钥交换四路握手COOKIE机制防泛洪乱序处理DSN/SSN双层序列号TSN单一序列空间接收窗口连接级 子流级双重管理关联级共享易阻塞中间盒兼容较好可回退普通TCP差多数NAT/防火墙不放行内核支持5.6起主线支持主线仅多宿CMT需补丁典型部署移动端、CDN、混合接入信令网、专网、数据中心内部公平性设计LIA/OLIA等成体系相对薄弱需额外机制4.4 实测中容易被忽略的观测指标跑完压测拿到吞吐数字只是第一步真正能说明问题的是几个过程指标。我通常会盯着看的有这么几个。子流利用率曲线。如果两条子流的吞吐曲线一条满一条瘪说明调度器没有真正发挥作用或者慢路径的拥塞窗口一直起不来。后者的常见原因是慢路径的RTT估计偏高导致窗口增长缓慢可以尝试调小初始RTO或者检查路径上的缓冲膨胀。乱序队列长度。这个指标直接反映接收端的压力。队列持续增长说明快慢路径差距过大调度策略需要调整队列忽大忽小说明路径质量在波动。Linux下可以通过ss -Mni看MPTCP子流的详细统计也可以读/proc/net/netstat里的MPTcpExt字段里面有乱序、重复、内存不足等各种计数器。重传率的分路径拆解。MPTCP的整体重传率看起来正常但拆到每条子流上看可能一条是0.1%另一条是8%。这说明慢路径质量已经不适合承载主力流量了应该降低它的权重或者干脆移出。# 查看MPTCP连接和子流 ss -M ss -Mni # 读取MPTCP扩展统计 grep -A2 MPTcpExt /proc/net/netstatSCTP侧对应的观测手段是# 查看SCTP关联状态 ss --sctp -a # 内核SCTP参数 sysctl net.sctp.path_max_retrans sysctl net.sctp.association_max_retrans sysctl net.sctp.hb_interval sysctl net.sctp.rto_initialpath_max_retrans控制单条路径的最大重传次数超过就标记该路径不可用。这个值默认是5在移动场景下偏保守——WiFi短暂抖动就可能触发路径切换来回切换本身就会造成吞吐抖动。我一般会把它调到8到10配合心跳间隔一起看。5. 选型落地从内核参数到线上排障5.1 一个实用的决策清单讲完原理和对比回到最实际的问题手上有个项目到底该选哪个。我给团队内部用的一套判断流程大致是这样几条。先问网络环境是否可控。如果两端都在自己的机房里中间不经过任何第三方设备SCTP系列是可选项。只要跨公网中间经过未知数量的NAT和防火墙MPTCP基本是唯一现实选择——不是因为它更先进而是因为它能被现有的网络基础设施放行。再问真正需要的是聚合还是迁移。如果只是想在WiFi和蜂窝之间无缝切换根本不需要CMT那种并发传输MPTCP的默认配置加上合理的调度策略就够了甚至SCTP原生多宿也能满足。如果需要叠加带宽才进入聚合方案的比较。然后问链路是同构还是异构。同构链路两条同规格宽带MPTCP的聚合效率很高收益明确。异构链路差距超过5倍时聚合的收益会打很大折扣先算一笔账假设快路径100Mbps、慢路径10Mbps理想聚合110Mbps实测大概率只有95到105Mbps之间还得付出接收缓冲翻倍、乱序重排CPU开销上升的代价。这种时候还不如直接用快路径把慢路径留作备份。最后问运维能力跟不跟得上。MPTCP的排障需要看双层序列号、看子流状态、看调度器行为比单路径TCP复杂得多。团队里如果没人能读懂ss -Mni的输出出问题时只能干瞪眼。这一条经常被忽略但往往是项目最终能不能稳定运行的决定因素。5.2 Linux上把MPTCP跑起来的最小配置理论说再多不如先把环境跑通。这里给一套我在测试环境常用的最小配置流程基于较新内核5.6以上建议6.1以上才能用调度器。第一步确认内核支持# 检查是否编译了MPTCP sysctl net.mptcp.enabled # 如果提示找不到说明内核没开这个选项第二步开启并设置限制sysctl -w net.mptcp.enabled1 sysctl -w net.mptcp.congestion_contrololia ip mptcp limits set subflows 4 add_addr_accepted 2subflows限制单条连接最多能有多少条子流add_addr_accepted限制能接受对端多少个地址通告。这两个值不要设太大子流不是越多越好——每条子流都要维护独立的拥塞控制状态和重传队列超过4条之后边际收益急剧下降反而增加调度复杂度。第三步配置端点。服务端通常是多网卡把可用地址通告出去ip mptcp endpoint add 10.20.0.11 dev eth0 signal ip mptcp endpoint add 10.20.1.11 dev eth1 signal客户端比如移动设备通常只需要主动发起子流ip mptcp endpoint add 192.168.50.20 dev wlan0 subflow第四步验证。用ip mptcp endpoint show确认端点配置生效用ss -M确认连接被识别为MPTCP用ss -Mni确认至少建立了两条子流。如果只看到一条回到2.1节检查握手回退的问题。第五步调接收缓冲区。异构链路下这一步不能省sysctl -w net.ipv4.tcp_rmem4096 87380 67108864 sysctl -w net.ipv4.tcp_wmem4096 65536 67108864上限给到64MB是偏激进的配置实际按快路径带宽 × 快慢路径RTT差 × 2估算更稳妥。给太大只是浪费内存不会提升性能给太小则会在聚合时形成流控瓶颈。5.3 上线后最先冒出来的几类问题环境跑通、Demo 验证通过和真正上线稳定运行之间还隔着好几道坎。按我遇到的频率排序大概是这么几类。第一类是聚合不生效退化成单路径。前面说过中间设备丢弃MP_CAPABLE选项导致回退。判断方法是在两端同时抓包看握手阶段服务端有没有回带MP_CAPABLE的SYN-ACK。如果没有问题在中间链路可以考虑换端口、换路径或者接受现实只做迁移不做聚合。第二类是聚合生效但吞吐不升反降。这个最迷惑人。原因通常有两个接收缓冲区不足导致快路径被流控拖住或者调度策略不当导致慢路径塞了太多数据。前者调tcp_rmem后者切调度器。还有一种隐蔽情况是路径MTU不一致快路径MTU 1500、慢路径MTU 1400子流建立时没有正确做PMTU发现导致慢路径上不停分片性能崩掉。第三类是切换过程中连接卡死。移动端从WiFi切到蜂窝时旧子流其实还没完全断开内核还在重传新子流已经建立两条子流同时存在但旧的那条永远发不出去也收不到确认。这时候需要设置合理的子流超时清理策略。MPTCP有个MPTCP_PM_ADD_ADDR相关的超时机制但对已经建立的僵尸子流清理不够积极。实践中可以通过应用层心跳或者主动调用ip mptcp endpoint delete来加速清理。第四类是多路径导致的计费问题。这条纯业务层面但很容易被技术同学忽略。用户连着WiFi时如果MPTCP把一部分流量分到了蜂窝哪怕只有几MB在某些计费模式下也会触发费用。上线前必须和业务方确认策略是WiFi优先仅在WiFi不可用时用蜂窝还是始终聚合。前者需要配置调度策略限制蜂窝子流的权重或者在应用层做链路感知。第五类是监控体系跟不上。单路径时代的监控看的是连接数、RTT、重传率多路径之后这些指标都要拆到子流维度还要新增子流数量、切换次数、聚合效率这些指标。如果没有提前埋点出问题时只能靠抓包效率极低。这一条我建议在项目立项阶段就列进需求别等到上线再说。我个人在实际操作中的体会是多路径传输这类技术的价值不在于技术上更先进而在于能不能在不改造现有基础设施的前提下解决真实问题。MPTCP之所以能落地很大程度上是因为它选择了妥协——伪装成TCP选项、允许回退、复用现有拥塞控制框架这些妥协在学术评价体系里可能是减分项在工程实践里却是决定成败的关键。CMT-SCTP的设计更纯粹、更优雅但它要求整个网络路径都为它让路这个前提在公网环境里几乎不可能成立。所以做技术选型时先别看协议设计得多漂亮先看你的网络环境愿意给它多少空间。还有一个容易被忽略的小技巧如果只是想在移动端做平滑切换而不需要聚合其实不一定要上MPTCPSCTP的原生多宿在可控环境里更轻量反过来如果目标明确是聚合带宽且链路同构MPTCP配默认调度器基本就能拿到想要的效果。想清楚边界再动手比选对协议更重要。