MPTCP 深度解析系列（3/20）
团队会议室，白板上画着 TBU 的网络架构图——两张 SIM 卡、两条蜂窝链路、一条到云端的 MPTCP 连接。方案已经跑了半年，效果不错。
这时 CTO 指着白板问了一个问题："QUIC 现在也支持多路径了，我们还有必要用 MPTCP 吗？"
会议室安静了三秒。这个问题不好回答——因为 MPTCP 和 MPQUIC 不是同一个东西的两个版本，而是两条设计哲学截然不同的技术路线。一个扎根在内核深处，一个跑在应用层之上；一个背靠 TCP 的四十年积累，一个站在 QUIC 的全新地基上。
这篇文章，就是那三秒钟之后的完整回答。我们从五个维度拆解 MPTCP 和 MPQUIC 的差异，最后给出一个可操作的选型框架。
一、QUIC 速览：为什么又来一个多路径协议？
在对比之前，先快速建立对 QUIC 的基本认知。如果你已经熟悉 QUIC，可以跳到第二章。
一句话定义
QUIC 是 Google 在 2013 年发起、IETF 在 2021 年标准化（RFC 9000）的传输协议。它基于 UDP，内置 TLS 1.3 加密，是 HTTP/3 的传输层基础。
QUIC 的三个核心设计决策
理解 QUIC，只需要记住三件事：
第一，用户态实现。 QUIC 不在操作系统内核里跑，而是在应用程序的进程里跑。Chrome 浏览器里有一份 QUIC 代码，Cloudflare 的服务器里有另一份。这意味着每个应用可以独立升级自己的传输协议，不用等操作系统发版。
第二，Connection ID。 TCP 连接绑定四元组（源 IP、源端口、目的 IP、目的端口），换了 IP 就断连。QUIC 用一个 Connection ID 标识连接——IP 变了没关系，只要 Connection ID 对得上，连接就还在。这天生就有连接迁移的能力。
第三，流级别多路复用。 一条 QUIC 连接里可以同时跑多个独立的"流"（Stream）。Stream 1 丢了包，不影响 Stream 2 的交付。这解决了 HTTP/2 over TCP 的队头阻塞问题。
从 QUIC 到 MPQUIC
QUIC 虽然天生能做连接迁移（换 IP 不断连），但它同一时刻只走一条路径。MPQUIC（Multipath QUIC） 的目标是让 QUIC 同时使用多条路径——和 MPTCP 的目标一样。
MPQUIC 目前处于 IETF 标准化的最后阶段：draft-ietf-quic-multipath-20（2026 年 2 月更新），正在 IESG 评审，即将成为 Proposed Standard。它的核心扩展是引入 Path ID 和每路径独立的包序号空间，让不同路径的丢包检测和拥塞控制互不干扰。
打个比方：如果 MPTCP 是在老城区的道路系统上加建高架桥（在 TCP 上扩展多路径），MPQUIC 就是在一片空地上直接规划新城（基于 QUIC 的全新设计）。老城改造受制于历史包袱，新城规划更自由但基础设施还没建完。
图 1：MPTCP 在内核态作为 TCP 扩展运行，MPQUIC 在用户态基于 UDP 运行——两种截然不同的协议栈位置
二、五个维度，逐一对决
维度一：协议栈位置——内核态 vs 用户态
这是两者最根本的差异，几乎所有其他差异都由此衍生。
MPTCP 跑在内核态。 它的代码在 Linux 内核的 net/mptcp/ 目录里，和 TCP 协议栈深度集成。数据从应用层到网卡，走的是内核的零拷贝路径，可以利用网卡的硬件卸载能力（TSO、GRO、GSO）。在 10G 链路上，TCP 内核态吞吐可以轻松达到 ~8 Gbps。
代价是什么？迭代慢。改一行 MPTCP 的代码，要提交 patch、经过内核社区审查、等下一个内核版本发布（Linux 的发版周期约 9 周）、再等发行版更新。从写代码到用户用上，可能是半年。
MPQUIC 跑在用户态。 它的代码在应用程序的进程里，基于 UDP socket 收发数据。改完代码，重启进程就生效。想针对特定应用定制调度策略？直接改，不用动内核。
代价是什么？性能开销。每个数据包都要经历用户态/内核态的上下文切换，无法利用网卡的 TCP 硬件卸载。根据已有的测试数据，QUIC 用户态实现的吞吐量在 90 Mbps 到 4900 Mbps 之间，取决于具体实现和硬件——和内核态 TCP 的 8 Gbps 有明显差距。
类比：内核态像市政公路——修路要审批、工期长，但承载量大、路面质量高；用户态像私家车道——想怎么改就怎么改，但宽度有限，大卡车过不了。
维度一结论：高吞吐、低 CPU 开销场景，MPTCP 胜；快速迭代、应用定制场景，MPQUIC 胜。
实战：查看你的 Linux 内核是否支持 MPTCP：
# 检查内核 MPTCP 支持
sysctl net.mptcp.enabled
# 查看 MPTCP 相关内核模块
lsmod | grep mptcp
维度二：连接迁移与路径管理——四元组绑定 vs Connection ID
这个维度决定了"加一条新路径"有多容易。
MPTCP 的方式：每条子流是一条独立的 TCP 连接，绑定在四元组上。想加一条新路径？需要完整的 MP_JOIN 三次握手——带 Token、带 HMAC、双向认证（第 2 篇详细讲过）。整个过程至少 1 个 RTT。路径消失时，需要通过 REMOVE_ADDR 通知对端关闭对应子流。
MPQUIC 的方式：连接用 Connection ID 标识，不绑定四元组。想加一条新路径？在新的 IP:Port 上发送一个带 Path ID 的 QUIC 包就行——不需要额外的握手。路径消失？停止在该路径上发包，连接自动继续在其他路径上工作。
在 NAT 场景下，差异更明显。MPTCP 需要用 Address_ID 这个逻辑标识来绕过 NAT 地址变化的问题（第 2 篇讲过）。MPQUIC 的 Connection ID 本身就不依赖 IP 地址，NAT 改了 IP，Connection ID 不变，连接自然不受影响。
类比：MPTCP 加新路径像办理一张新银行卡——要带身份证去柜台、填表、验证、等审批。MPQUIC 加新路径像用手机 NFC 刷一下——碰一下就通了。
图 2：MPTCP 需要 MP_JOIN 三次握手建立新子流，MPQUIC 通过 Connection ID 直接在新路径上发包
维度二结论：路径动态变化频繁的场景（移动设备、车联网），MPQUIC 的路径管理更轻量。但 MPTCP 的 HMAC 认证提供了更强的安全保证。
实战：对比两种协议的路径建立开销：
# MPTCP：查看子流建立耗时（从 MP_JOIN SYN 到 ACK）
ss -Mtnpi | grep "subflows"
# QUIC：查看连接迁移事件（需要应用层日志）
# 以 quic-go 为例，启用 debug logging 可以看到 path 切换事件
维度三：队头阻塞——字节流 HOL vs 流级别独立
这是 QUIC 系列协议相对 TCP 系列最大的结构性优势。
MPTCP 的问题：MPTCP 对应用层暴露的是一个有序字节流。假设数据包 1-10 分配到子流 A，11-20 分配到子流 B。子流 A 的包 3 丢了，需要重传。这时子流 B 的包 11-20 全部到了，但 MPTCP 不能把它们交给应用——因为应用期望的是有序字节流，包 3 还没到，后面的都得等着。
这就是队头阻塞（Head-of-Line Blocking）。在路径异构的场景下（一条快一条慢），这个问题尤其严重——快路径的数据到了却交付不了，被慢路径拖后腿。
MPQUIC 的优势：QUIC 的多路复用是流级别的。Stream 1 的包丢了，只阻塞 Stream 1，Stream 2 和 Stream 3 照常交付。MPQUIC 更进一步——不同的 Stream 可以走不同的路径，路径 A 丢包只影响路径 A 上的 Stream，路径 B 上的 Stream 完全不受影响。
但这个优势有前提条件。 如果你的应用只有一个流（比如一条视频流、一个大文件传输），那 QUIC 的流级别独立性帮不上忙——因为只有一个流，丢包就是阻塞。在这种单流场景下，MPTCP 和 MPQUIC 的 HOL 表现差异不大。
MPTCP 也不是完全没有应对手段。接收端的重排序缓冲区可以缓解部分 HOL；冗余调度模式下，同一份数据同时走多条路径，任一路径先到即可交付，HOL 概率大幅降低。
图 3：MPTCP 的字节流 HOL——子流 A 丢包导致子流 B 数据无法交付；MPQUIC 的流级别独立——Stream 间互不阻塞
维度三结论：多流并发场景（HTTP/3、gRPC），MPQUIC 明显胜出；单流场景（视频流、大文件），差异不大。
维度四：标准化与生态成熟度
技术选型不能只看设计优劣，还要看"能不能用"和"有多少人在用"。
MPTCP 的成熟度：
- 标准：RFC 8684（2020），Standards Track，已标准化 6 年
- 内核支持：Linux 5.6+（2020）原生支持，持续迭代至 6.x 系列
- 商业部署：Apple iOS 7+（2013）部署 13 年，数亿台设备验证
- 行业标准：3GPP Release 16 ATSSS 选定方案
- 工具链：
ss -M、ip mptcp、nstat、Wireshark MPTCP dissector，诊断工具完善
MPQUIC 的成熟度：
- 标准：draft-ietf-quic-multipath-20（2026.02），IESG 评审中，即将成为 Proposed Standard
- 实现：picoquic (C)、quic-go (Go)、quiche (Rust/Cloudflare)、aioquic 扩展 (Python)
- 商业部署：大规模生产案例尚少，多数处于实验和测试阶段
- 行业标准：3GPP Release 18（5G Advanced）开始引入
- 工具链：各实现自带日志，Wireshark 支持 QUIC 解析但 multipath 扩展支持有限
成熟度的差距是客观存在的，但在快速缩小。MPQUIC 的标准化进程明显快于当年的 MPTCP——MPTCP 从 2009 年立项到 2020 年标准化用了 11 年，MPQUIC 从 2017 年开始讨论到 2026 年即将标准化，只用了约 9 年。但从"有标准"到"大规模部署验证"，MPTCP 又走了好几年。MPQUIC 还需要时间积累生产环境的经验。
图 4：MPTCP 从 2009 年立项到 2020 年标准化历时 11 年；MPQUIC 从 2017 年开始到 2026 年即将标准化约 9 年
维度四结论：今天选方案，MPTCP 的生态成熟度远超 MPQUIC。但 2-3 年后，这个差距会大幅缩小。
维度五：部署与中间设备兼容性
这是工程落地时最头疼的维度。
MPTCP 的部署挑战：MPTCP 的控制信息放在 TCP Options（Kind=30）里。第 2 篇详细分析过——运营商的 CGNAT、防火墙、DPI 设备可能剥离或篡改这些 Options，导致 MPTCP 握手失败。好消息是 MPTCP 有优雅降级机制：检测到 Options 被破坏，自动回退到普通 TCP，连接不断。坏消息是：回退之后你就失去了多路径能力，而这正是你最需要的东西。
另外，MPTCP 需要内核支持。如果你的设备跑的是 Linux 5.5 以下的内核，或者是 Windows/Android 等 MPTCP 支持有限的系统，部署就有门槛。
MPQUIC 的部署特点：MPQUIC 基于 UDP，封装在 QUIC 里。中间设备看到的是普通的 UDP 包，不会去动 QUIC 的头部（因为 QUIC 头部是加密的）。大多数 NAT 和防火墙都放行 UDP，所以 MPQUIC 的中间设备穿越性通常比 MPTCP 好。
但有一个反直觉的问题：部分企业网络和运营商会限制或限速 UDP 流量。在某些网络环境下，UDP 被当作"非主流"流量对待，QoS 策略会优先保障 TCP。这意味着 MPQUIC 可能面临"能穿过去但被限速"的尴尬。
MPQUIC 的另一个优势是不需要内核升级。它跑在用户态，应用自带 QUIC 库就行。这对于无法控制操作系统版本的场景（比如移动 App、第三方设备）是一个很大的加分项。
维度五结论：TCP Options 穿越性问题选 MPQUIC 更稳；但 UDP 限速问题在某些网络环境下反而是 MPQUIC 的短板。MPQUIC 的"免内核升级"部署优势在很多场景下是决定性的。
实战：测试你的网络环境对两种协议的兼容性：
# 测试 MPTCP Options 穿越性
# 方法：在两端抓包，对比 SYN 和 SYN-ACK 中的 Kind=30 是否完整
tcpdump -i eth0 -nn -X 'tcp[tcpflags] & tcp-syn != 0' | head -50
# 测试 UDP 穿越性和限速
# 方法：用 iperf3 的 UDP 模式测试
iperf3 -c <server> -u -b 100M -t 10
# 对比 TCP 吞吐
iperf3 -c <server> -t 10
三、总览：五维对比一张表
把五个维度的结论汇总：
| 维度 | MPTCP | MPQUIC | 胜出方 |
|---|---|---|---|
| 协议栈位置 | 内核态，高吞吐低开销 | 用户态，快速迭代灵活定制 | 看场景 |
| 连接迁移 | MP_JOIN 三次握手，安全但重 | Connection ID，轻量但认证弱 | MPQUIC |
| 队头阻塞 | 字节流 HOL，多流场景受限 | 流级别独立，多流场景优势大 | MPQUIC |
| 标准化成熟度 | RFC 标准化 6 年，生态完善 | 即将标准化，生态起步中 | MPTCP |
| 部署兼容性 | TCP Options 可能被剥离 | UDP 可能被限速 | 各有短板 |
四、5G ATSSS：两条路线的交汇点
如果说前面的对比是"理论分析"，那 3GPP 的选择就是"行业投票"。
Release 16（2020）：选择 MPTCP
3GPP 在 2018 年 12 月为 5G 的 ATSSS（Access Traffic Steering, Switching, Splitting） 框架选定了 MPTCP 作为传输方案，搭配 0-RTT Convert 协议做代理转换。原因很简单：当时 MPTCP 是唯一成熟的多路径传输标准。
比利时公司 Tessares 开发了商用的 MPTCP ATSSS 代理方案，韩国运营商 KT 率先在 5G 网络中部署，实测 session 建立时间缩短了一半以上。
Release 18（2024）：引入 MPQUIC
到了 5G Advanced（Release 18），3GPP 开始引入 MPQUIC 作为 ATSSS 的替代传输方案。Nokia Bell Labs 主导了这项研究。原因也很直接：QUIC 流量在互联网中的占比持续增长（HTTP/3 已经是主流），TCP 流量走 MPTCP 代理没问题，但 QUIC 流量如果也要先转成 TCP 再走 MPTCP，就多了一层不必要的转换。直接在 QUIC 层做多路径更自然。
两者并存，而非替代
Release 19 的架构同时支持 MPTCP 和 MPQUIC：
- TCP 流量 → MPTCP 代理 → 多路径传输
- QUIC 流量 → MPQUIC 代理 → 多路径传输
运营商根据业务类型和流量特征选择走哪条路。这不是"A 替代 B"，而是"A 和 B 各管一摊"。
这个架构选择本身就说明了一个事实：MPTCP 和 MPQUIC 不是竞争关系，而是互补关系。 5G 标准的制定者——全球最顶尖的通信工程师们——得出的结论和我们一样：不存在一个"万能方案"，只有"适合的方案"。
关于 5G ATSSS 的完整架构和部署细节，我们会在系列第 17 篇专门展开。
图 5：5G ATSSS 架构——UE 通过 ATSSS-LL 层选择 MPTCP 或 MPQUIC 代理，实现多接入链路的分流/切换/聚合
五、选型指南：什么场景选什么协议
回到 CTO 的问题。答案不是"选 A"或"选 B"，而是一个决策树。
选 MPTCP 的场景
- 高吞吐需求：大文件传输、视频回传，需要内核级性能
- 已有 TCP 应用：不想改应用层代码，MPTCP 对应用完全透明
- Linux 服务器环境：内核版本可控，能确保 5.6+
- 运营商网络已验证：TCP Options 穿越性测试通过
- 典型场景：车联网 TBU 视频回传、数据中心多路径、企业专线带宽聚合
选 MPQUIC 的场景
- 应用已基于 QUIC/HTTP3：CDN、Web 应用，协议栈天然匹配
- 多流并发：需要流级别调度，减少 HOL 阻塞
- 需要快速迭代：调度策略频繁调整，用户态可热更新
- 部署环境不可控：无法升级内核，或需要跨平台支持
- 典型场景：CDN 多路径加速、移动 App 弱网优化、边缘计算
我们团队的选择
对于无人车远程遥控驾驶场景，我们选了 MPTCP。原因：
- 延迟敏感：内核态的处理路径更短，每一毫秒都重要
- 单流为主：视频流是主要负载，MPQUIC 的流级别优势发挥不出来
- TBU 内核可控：我们自己编译 TBU 的 Linux 系统，内核版本不是问题。（注意不是都有团队有具备这样的能力，这里要谨慎）。
- 运营商专线：企业 APN 已验证 TCP Options 穿越性
但我们同时在跟踪 MPQUIC 的进展。未来如果 5G ATSSS 在国内运营商普及，或者我们的应用层协议迁移到 QUIC，MPQUIC 会成为自然的选择。
图 6：多路径传输选型决策树——根据吞吐需求、流量类型、部署环境和网络条件选择 MPTCP 或 MPQUIC
六、未来走向：融合还是分化？
短期（1-2 年）：各守阵地
MPTCP 继续深耕内核态高性能场景，Linux 内核每个版本都在完善调度器和路径管理器。MPQUIC 完成标准化，各实现库逐步稳定，开始出现早期的生产部署案例。
中期（3-5 年）：ATSSS 推动共存
随着 5G SA 网络的普及，运营商侧同时部署 MPTCP 和 MPQUIC 代理。终端设备根据流量类型自动选择——TCP 流量走 MPTCP，QUIC 流量走 MPQUIC。两者在 5G 网络中和平共处。
长期：三个变量决定走向
变量一：内核态 QUIC 是否出现。 Linux 内核已经有了 kTLS（内核态 TLS 加速）的先例。如果未来出现内核态 QUIC 实现，MPQUIC 的性能劣势将大幅缩小甚至消失。这会是一个 game changer。
变量二：运营商对 UDP 的态度。 如果全球运营商逐步放开对 UDP 的限速策略（随着 QUIC 流量占比超过 50%，这几乎是必然的），MPQUIC 的部署天花板将被打破。
变量三：应用层协议演进。 如果 HTTP/3 成为绝对主流，越来越多的流量天然跑在 QUIC 上，MPQUIC 的生态优势会不断放大。反过来，如果 TCP 在服务器间通信（gRPC over TCP、数据库连接等）中保持主导地位，MPTCP 的阵地就稳如磐石。
写在最后
回到会议室。CTO 的问题有了答案——但不是一个简单的"选 A 还是选 B"。
MPTCP 和 MPQUIC 不是替代关系，而是两条不同的技术路线，各自有最适合的战场。就像柴油发动机和电动机——不是谁淘汰谁，而是看你的车跑在什么路上、拉的是什么货。
如果你需要一句话总结：今天要上生产，选 MPTCP；面向未来做储备，关注 MPQUIC。 如果你的应用已经跑在 QUIC 上，那 MPQUIC 就是你的自然选择。
下一篇预告：「MPTCP 与中间设备（NAT/防火墙/运营商）的兼容性实战」——我们会深入到中国三大运营商的真实网络环境中，用实测数据告诉你 MPTCP 在哪些网络上能跑、在哪些网络上会翻车、以及翻车之后怎么救。
