想象你是一家快递公司的调度中心主管，你的大客户每天都要把几十个集装箱的货物从上海发到北京。过去，你只和一家运输公司合作，所有货物都排在同一条高速公路上——这就是传统的单路径 TCP。遇到春运拥堵，或前方高速临时封闭，整个发货流程只能停下来重新绕路，货物送达时间完全不可控。后来你引入了一套“多车队并行运输”方案：同一个总运单下的货物被拆成许多小包裹，分别交给走不同路线的车队，比如高铁车队、高速公路车队、备用乡道车队；每个车队都有独立的“车队长”负责本车队的装载和速度，而总调度中心负责拆单、协调车速、分配货量，甚至在某个车队遇到拥堵时把后续包裹平滑地转给其他车队，客户全程无感。这套方案就是多路径 TCP（MPTCP）。它让一条 TCP 连接可以同时在 WiFi、蜂窝网络等多条物理链路上传输数据，从而聚合带宽、提升吞吐，并在网络切换时保持连接不断。下面我们就从一单货物要如何拆、如何派、如何控速、如何切换，来看懂 MPTCP 的核心机制。

岗位关联

对 AI 从业者而言，理解 MPTCP 能让你在数据同步、边缘推理和分布式训练的网络瓶颈面前，多一种“多条路并行”的优化思路，是构建高性能 AI 基础设施的重要一环。

目录
  1. 可视化演示
  2. TCP 单路径瓶颈
  3. MPTCP 协议架构
  4. 子流管理机制
  5. 拥塞控制耦合
  6. 负载分配调度
  7. 无线网络无缝切换
  8. 部署实践与应用成效
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示MPTCP多路径子流架构与带宽聚合、耦合拥塞控制算法、WiFi与蜂窝网络无缝切换的吞吐量变化过程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

'+_captions.subflow+'

TCP 单路径瓶颈

先说痛点。传统 TCP 连接就像你和一家运输公司签的“单车队合同”：无论你的货物多么急需，所有包裹都只能塞进同一支车队，走同一条高速公路。这条路能同时容纳多少辆货车，取决于两个因素：车速（带宽）和单程耗时（往返时延）。如果路况好但路程远，或者路程近但路很窄，你都无法在单位时间内发出足够多的货。当你要从上海运一批 10GB 的大模型参数到北京时，单路径 TCP 的吞吐量会被拥塞窗口（一时间内允许发出去的未确认数据量）和丢包率牢牢锁住，加再多带宽也没用。

从网络技术角度看，单路径 TCP 受到“带宽时延积”的限制。带宽时延积（BDP）就是这条“高速公路”上最多能同时奔跑的数据量，它等于链路的带宽乘以往返时延。网络设备中的接收窗口、发送窗口本质上要能装得下 BDP，否则链路利用率就会很低。更麻烦的是无线切换：当手机从 WiFi 走到室外，原有 TCP 连接必须断开，再建立新连接，中间的数据要重传、要重新慢启动，就像高速封闭后所有车都得倒回起点重新排队。

回到比喻：单车队方案最大的问题不是车不够多，而是整条链路只有一个起点、一条路、一个车队长。路被堵死，吞吐归零；车队重新集结，延迟飙升。MPTCP 的思路，就是让一个总运单从诞生起就支持多个车队并行，从根上绕开单点瓶颈。

BDP=BW×RTT\displaystyle \text{BDP} = \text{BW} \times \text{RTT}
BDP 告诉我们：一条链路能“在途”存放多少数据。发货节奏再快，路上铺不满车，吞吐也上不去。
  1. 带宽 BW公路的最大通过率，即链路每秒能传输的比特数，单位为 bit/s。
    BW=传输比特数时间\displaystyle \text{BW} = \frac{\text{传输比特数}}{\text{时间}}
  2. 往返时延 RTT一列货车从出发到到达再返回出发地所需的总时间，单位是秒。
    RTT=T发送+T传播+T排队+T处理\displaystyle \text{RTT} = T_{\text{发送}} + T_{\text{传播}} + T_{\text{排队}} + T_{\text{处理}}
  3. 带宽时延积 BDP两者相乘得到“路上最多同时存在的比特数”，即网络中可缓冲的在途数据上限。
    BDP=BW×RTT\displaystyle \text{BDP} = \text{BW} \times \text{RTT}

MPTCP 协议架构

为了解决单路径瓶颈，MPTCP 在 TCP 协议栈里增设了一个“总调度中心”层。对上层应用来说，它仍然只看到一个普通的 TCP 连接，程序员不需要修改业务代码；对下层网络来说，它可以在多条物理链路上分别建立普通 TCP 连接，这些连接被称为“子流”，相当于车队里的一辆辆班车。总调度中心负责把应用层下来的字节流拆成一个个带统一序号的小包裹，再按调度策略分发给各条子流，最后在接收端按序号重组。

这里的关键是“共享序列号空间”。传统 TCP 的每个连接有一套独立的发送序号，而 MPTCP 的连接级序号是唯一的，子流只是运输这些序号的数据载体。类似物流总运单上每一车货物都有唯一运单号，无论货物从哪个分拣口上车，最终都按运单号重新装订成完整订单。如果通信对方不支持 MPTCP，则握手时自动退化为普通 TCP，从多车队退回单车队，保证兼容性。

总调度中心给了我们拆单的能力，但拆单之后如何把子流建起来、如何让它们活得好，就需要下一节的“子流管理机制”。

Ttotal=∑i=1NTi\displaystyle T_{\text{total}} = \sum_{i=1}^{N} T_i
多路径最理想的情况是总吞吐量等于所有子流吞吐量之和，像是 N 支车队同时卸货。
  1. 子流吞吐 \(T_i\)第 \(i\) 条子流的实际吞吐，它由该子流所在链路的带宽、时延与丢包共同决定。
    Ti=拥塞窗口大小RTTi\displaystyle T_i = \frac{\text{拥塞窗口大小}}{\text{RTT}_i}
  2. 子流数量 \(N\)MPTCP 同时维护的可用子流数量，取决于设备具备多少可用的物理网卡或网络接口。
    N=∑k=1MI(接口 k 可用)\displaystyle N = \sum_{k=1}^{M} \mathbb{I}(\text{接口 } k \text{ 可用})
  3. 总吞吐 \(T_{\text{total}}\)对全部子流吞吐求和，得到连接级聚合吞吐。若多条子流共享同一个瓶颈路由器，实际值会小于该和，这是拥塞控制要解决的问题。
    Ttotal=T1+T2+⋯+TN\displaystyle T_{\text{total}} = T_1 + T_2 + \cdots + T_N

子流管理机制

一支新车队不是喊一声就能加入的。MPTCP 通过一系列 TCP 选项完成“车队注册”：第一次建立连接时，双方在 SYN 包中携带 MP_CAPABLE 选项，互相确认“我支持多路径协议”；当其中一方发现新的可用地址或接口时，通过 ADD_ADDR 选项把自己的新地址告诉对方，对方可以用这个地址发起新的子流；当某条网络路径不可用时，则使用子流关闭机制把它移除，释放资源。

这套机制很像是货主与运输公司在第一次合作时先交换资质证明，之后每次增加新的分仓地址都会在总运单上登记，废弃的线路也会及时注销。子流的建立不需要另行创建上层连接，因为所有子流共享同一个应用身份；它们只是在传输层多做了一次握手，就像派一支新分队之前先打个电话确认路线。多子流也带来管理开销：每增加一条子流，都要维护独立的拥塞窗口、RTT 估计和重传定时器。

子流管理解决的是“车队的注册与注销”，但更复杂的问题是多个车队同时跑时如何避免在路上互相添堵，这就是多路径拥塞控制。

Coverhead=N×Csubflow\displaystyle C_{\text{overhead}} = N \times C_{\text{subflow}}
子流越多，管理成本线性增长，但吞吐收益并非线性，因此要按实际需求关闭闲置子流。
  1. 单子流开销 \(C_{\text{subflow}}\)每条子流都要维护滑动窗口、拥塞状态和往返时延统计，像每支车队都有独立的车辆清单和油耗表。
    Csubflow=Cwindow+Ctimer+Cstat\displaystyle C_{\text{subflow}} = C_{\text{window}} + C_{\text{timer}} + C_{\text{stat}}
  2. 子流数量 \(N\)可用子流的条数，通常不超过可用网卡数，多余的子流反而加重处理器和内存负担。
    N≤Minterface\displaystyle N \leq M_{\text{interface}}
  3. 总开销 \(C_{\text{overhead}}\)所有子流开销相加。当增加子流带来的吞吐提升小于管理成本时，MPTCP 会选择关闭低效子流。
    Coverhead=N×Csubflow\displaystyle C_{\text{overhead}} = N \times C_{\text{subflow}}

拥塞控制耦合

假设你手下的高铁车队和高速公路车队在某个城市的枢纽路口汇合。如果每支车队长都只盯着自己眼前的车速，遇到拥堵就猛踩刹车，路口会乱成一锅粥。TCP 的拥塞控制本来是为单路径设计的，如果 MPTCP 的子流各自独立进行拥塞控制，它们会共同抢占同一个瓶颈链路，导致多路径连接的总流量比单路径 TCP 更激进，对网络中其他普通用户不公平。

MPTCP 的耦合拥塞控制把各子流的拥塞窗口放进同一个“交通协调中心”：所有子流的窗口合在一起，作为一个整体感知拥塞。最经典的 LIA（Linked Increases Algorithm）算法规定，某条子流每收到一个 ACK，其拥塞窗口的增长量等于两个候选值中的较小者：一个是“归一化的整体增长量” \(\alpha / w_{\text{total}}\)，一个是“单路径 TCP 的增长量” \(1 / w_i\)。这样既能利用多条路径的带宽，又不会让整体发送速率超过“最差路径上单个 TCP 流”应有的水平。

耦合控制保证了公平，但吞吐提升还取决于调度员如何把包裹分给不同车队。如果分单不合理，哪怕路再多也是白搭。

Δwi=min⁡(αwtotal,1wi)\displaystyle \Delta w_i = \min\left(\frac{\alpha}{w_{\text{total}}}, \frac{1}{w_i}\right)
LIA 就像一个红绿灯协调系统：多支车队一起加速，但总流量不超过一条普通车道上的最大车流，保证对别人公平。
  1. 子流窗口 \(w_i\)第 \(i\) 条子流当前的拥塞窗口大小，表示这条车道上允许同时在途的包裹数。
    wi=cwndi\displaystyle w_i = \text{cwnd}_i
  2. 总窗口 \(w_{\text{total}}\)所有子流窗口之和，即整个多路径连接的在途数据总量。
    wtotal=∑i=1Nwi\displaystyle w_{\text{total}} = \sum_{i=1}^{N} w_i
  3. 系数 \(\alpha\)由各子流的窗口与 RTT 计算出的全局耦合系数，用于把总增长量按比例分配，让更快的路径增长更快。
    α=wtotal×max⁡i(wi/RTTi2)(∑iwi/RTTi)2\displaystyle \alpha = w_{\text{total}} \times \frac{\max_i \left(w_i / \text{RTT}_i^2\right)}{\left(\sum_i w_i / \text{RTT}_i\right)^2}
  4. 取最小 \(\min(\cdot,\cdot)\)同时满足“整体不过快”和“单条子流不冒进”两个约束，就像车队加速既要看全局绿灯，也要遵守每条车道的限速。
    Δwi=min⁡(αwtotal,1wi)\displaystyle \Delta w_i = \min\left(\frac{\alpha}{w_{\text{total}}}, \frac{1}{w_i}\right)

负载分配调度

总调度中心里有位“调度员”，它决定每一批包裹该上哪支车队。MPTCP 的默认调度器是 minRTT：每次先看所有子流的往返时延，把数据优先交给 RTT 最小的子流，因为它的新鲜度最高、反馈最快；当这条最快子流的拥塞窗口已经满载时，再让数据溢出到次快子流。从概率上看，子流被选中的权重与它的 RTT 成反比：RTT 越短，承载的数据越多。

这就引出了带宽聚合的关键：如果多个子流各自的瓶颈链路互不共享，那么总吞吐就接近所有子流带宽之和；如果它们共享同一个瓶颈，则总吞吐受限于瓶颈链路，调度算法只能帮助降低时延抖动。此外，MPTCP 还支持冗余传输，把同一个重要包裹复制到两条子流上，选先到的那份，用多花带宽换更低的尾部延迟，这在无线切换和丢包较多的场景下非常有用。

有了调度算法，多车队可以在“平稳路况”下高效并行。但无线环境的最大特点是路况瞬息万变：WiFi 信号变弱、蜂窝基站切换、电梯短暂失联，这时 MPTCP 的无缝切换能力就派上用场了。

pi=1/RTTi∑j=1N1/RTTj\displaystyle p_i = \frac{1 / \text{RTT}_i}{\sum_{j=1}^{N} 1 / \text{RTT}_j}
minRTT 调度器像快递分拣员：把货先塞给最近的运输线，最近的车队装满了再给次近的，保证整体送达最快。
  1. 子流入选概率 \(p_i\)调度器把数据包分配给子流 \(i\) 的概率，RTT 越小的子流获得越多分配。
    pi=1/RTTi∑j=1N1/RTTj\displaystyle p_i = \frac{1 / \text{RTT}_i}{\sum_{j=1}^{N} 1 / \text{RTT}_j}
  2. RTT 倒数 \(1/\text{RTT}_i\)把时延转换成“速度分”，时延越低分数越高。
    scorei=1RTTi\displaystyle \text{score}_i = \frac{1}{\text{RTT}_i}
  3. 归一化分母把所有子流的速度分加起来，保证概率之和为 1，形成完整的加权轮询。
    ∑i=1Npi=1\displaystyle \sum_{i=1}^{N} p_i = 1

无线网络无缝切换

传统 TCP 在无线切换时非常脆弱：手机离开 WiFi 覆盖范围，旧连接立刻中断，应用必须重新发起 TCP 握手，DNS 解析、TLS 协商都要重来一次，用户能明显感觉到“转圈”。MPTCP 的思路是“不要把鸡蛋放在一个篮子里”：手机同时开启 WiFi 和蜂窝两条子流，当 WiFi 信号衰减时，新的数据会逐渐被调度到蜂窝子流，而不是先断网再重连。由于应用层看到的连接始终存在，视频通话、文件传输得以无缝继续。

这种“先立后破”的切换方式极大降低了切换延迟。传统切换的耗时由三部分累加：检测链路断开、重建连接、恢复传输；而 MPTCP 的切换只需要调整调度权重，因为备用子流早就建立好了，检测到主路变慢的瞬间，数据就能转到备用子流上。测量显示，蜂窝与 WiFi 之间的 MPTCP 切换可以做到百毫秒级甚至零感知。

从单路径到多路径，从链路聚合到无缝切换，MPTCP 的每一项机制最终都要落到真实世界的部署效果上。

Tswitch=Tdetect+Tsetup+Trecover\displaystyle T_{\text{switch}} = T_{\text{detect}} + T_{\text{setup}} + T_{\text{recover}}
传统切换三项全都要做；MPTCP 因为预先维护多条子流，\(T_{\text{setup}}\) 几乎为 0，切换像司机提前变道而不是停车问路。
  1. 链路检测 \(T_{\text{detect}}\)判断当前路径是否变差的时间，通常依靠 RTT 抖动、丢包率或信号强度变化。
    Tdetect=连续超时次数×超时时间\displaystyle T_{\text{detect}} = \text{连续超时次数} \times \text{超时时间}
  2. 子流建立 \(T_{\text{setup}}\)建立新 TCP 子流所需的时间。MPTCP 在切换前已通过 ADD_ADDR 预建立子流，因此该项趋近于 0。
    Tsetup≈0\displaystyle T_{\text{setup}} \approx 0
  3. 数据恢复 \(T_{\text{recover}}\)拥塞窗口重新打开、未确认数据重传的时间。MPTCP 可在旧链路上继续恢复，不必重头再来。
    Trecover=RTT×log⁡2(目标窗口初始窗口)\displaystyle T_{\text{recover}} = \text{RTT} \times \log_2\left(\frac{\text{目标窗口}}{\text{初始窗口}}\right)

部署实践与应用成效

MPTCP 并不是停留在论文里的实验协议。在智能手机上，苹果的 Siri、iCloud 等应用很早就使用 MPTCP 同时利用 WiFi 和蜂窝网络，用户在地下室 WiFi 信号差时依然可以流畅完成请求；在数据中心，MPTCP 可以把多张网卡绑定到一个逻辑连接上，某条链路断掉时业务不断流，同时聚合多条链路的带宽。对 AI 基础设施来说更有价值的是分布式训练：GPU 服务器之间的梯度同步非常依赖带宽和连接稳定性，MPTCP 可以让模型同步时间显著缩短，减少 GPU 空转。

业界公开测试中，MPTCP 在同设备具备 WiFi 与蜂窝双连接时，下行业务吞吐可以提升 1.4 到 2 倍；在数据中心用 4 条 10Gbps 网卡模拟时，聚合吞吐接近 40Gbps 的理论上限。当然，收益取决于路径是否真正独立。如果 WiFi 和蜂窝最终共享同一根光纤或同一个运营商网关，聚合效果会大打折扣，这时拥塞控制耦合反而成了防止拥塞的保障。

回头看整个物流系统：单路径瓶颈让我们明白为什么要修多路线；协议架构给出了总调度中心的图纸；子流管理、拥塞控制、负载分配、无缝切换分别解决了车队注册、路口协调、分单策略和突发换路的问题；最后部署数据验证了这套系统确实能让货物送得更快、更稳。

η=Tmptcp−TtcpTtcp×100%\displaystyle \eta = \frac{T_{\text{mptcp}} - T_{\text{tcp}}}{T_{\text{tcp}}} \times 100\%
吞吐提升率 \(\eta\) 直接量化了多路径方案的价值，是部署前评估、部署后验收最常用的指标。
  1. 单路径吞吐 \(T_{\text{tcp}}\)传统 TCP 在最优可用链路上的实测吞吐，作为基线。
    Ttcp=max⁡iTi\displaystyle T_{\text{tcp}} = \max_{i} T_i
  2. MPTCP 吞吐 \(T_{\text{mptcp}}\)使用多路径调度后整个连接的实际吞吐。
    Tmptcp=∑i=1NTi′\displaystyle T_{\text{mptcp}} = \sum_{i=1}^{N} T_i^{\prime}
  3. 提升率 \(\eta\)吞吐增量占基线的百分比，常用于对比不同调度策略和不同网络环境。
    η=ΔTTtcp×100%\displaystyle \eta = \frac{\Delta T}{T_{\text{tcp}}} \times 100\%

AI 应用场景

大规模分布式训练的数据同步

阶段：模型训练中的梯度聚合与 Checkpoint 保存

解决的问题：在千卡集群中，梯度同步需要频繁在 GPU 节点间传输大文件，传统单 TCP 连接容易受单链路带宽和偶发丢包限制，导致每次同步都要等待最慢的节点。MPTCP 可以聚合多网卡带宽，并利用多条路径冗余传输关键梯度，把同步时间降低 30% 以上。

具体案例：某大模型团队在 8 台 A100 服务器之间使用双 25Gbps 网卡跑数据并行训练，启用 MPTCP 后，AllReduce 阶段的整体吞吐从 23Gbps 提升到 46Gbps，训练步耗时缩短近一半。

端侧 AI 助手的实时语音交互

阶段：边缘模型服务接入与移动端推理

解决的问题：AI 手机助手在用户从办公室走到室外时，如果走传统 TCP，WiFi 断开会造成语音请求重连，交互延迟飙升。MPTCP 让 WiFi 与蜂窝子流并存，切换对上层不透明，用户说话不中断。

具体案例：一款车载语音助手在车辆穿越隧道时，通过 MPTCP 同时维护 4G 和 WiFi 子流，隧道内语音识别请求的失败率从 12% 降到 0.3%，连续对话保持率显著提升。

数据中心的模型推理高可用网络

阶段：在线推理服务部署与链路冗余

解决的问题：推理服务对长连接敏感，传统 TCP 在物理链路故障后需要重建连接，导致大量在途请求失败。MPTCP 让推理服务使用多网卡多路径，故障时数据自动切换到备用子流，用户侧无感知。

具体案例：某云厂商的 LLM 推理网关通过 MPTCP 聚合双上联 100Gbps 链路，在人为拔掉一条光纤的演练中，推理请求错误率仅出现 0.1% 的瞬时抖动，远低于传统方案的 8% 错误率。

Python 演示

python34 行
class Link:    def __init__(self, name, rate, rtt):        self.name = name        self.rate = rate        self.rtt = rtt        self.sent = 0  class MPTCP:    def __init__(self, links):        self.links = links     def weighted_min_rtt(self, total_mb):        weights = [1.0 / link.rtt for link in self.links]        total_weight = sum(weights)        for link, w in zip(self.links, weights):            link.sent = total_mb * (w / total_weight)        return sum(link.sent for link in self.links)  def main():    wifi = Link("WiFi", 10, 20)    cellular = Link("Cellular", 5, 45)    con = MPTCP([wifi, cellular])    total = 100.0    sent = con.weighted_min_rtt(total)    print("MPTCP total sent: %.1f MB" % sent)    for link in con.links:        print("%s carried: %.1f MB" % (link.name, link.sent))    print("Ideal aggregate bandwidth: %.1f MB/s" % sum(link.rate for link in con.links))  if __name__ == "__main__":    main()
目的：用加权 minRTT 调度器模拟 MPTCP 把一份数据按各子流 RTT 的反比进行分配，并输出理想聚合带宽。
  1. weights = [1.0 / link.rtt for link in self.links]把 RTT 换算成“速度分”，时延越低得分越高。
  2. total_weight = sum(weights)计算所有速度分的总和，用于后续归一化。
  3. link.sent = total_mb * (w / total_weight)按速度分占比分配数据量，模拟调度器分单。
  4. sum(link.rate for link in con.links)计算所有子流带宽之和，对应 MPTCP 的理想聚合吞吐。

常见误区

误区我一开始以为 MPTCP 就是把应用数据随便塞进几个独立的 TCP 连接里，每个连接单独传一部分，传输层和应用层都要感知多连接的存在。

正解实际上 MPTCP 对外仍然是一个逻辑 TCP 连接，有统一的连接级序列号。子流只是承载数据的分身，应用层完全无感。这就像总运单只有一份，但可以拆给多个车队去送，收货人不需要知道来了几辆车，只收到一张完整订单。

为何常见：因为“多路径”容易让人误以为就是“多连接”，而忽略了 MPTCP 在连接级做了统一协调。

误区既然 MPTCP 能把多条路加起来，那我开 10 条子流，速度就是原来的 10 倍吧？

正解吞吐提升的前提是各子流拥有独立瓶颈链路。如果 WiFi 和蜂窝最终共用同一根光纤或同一运营商出口，总吞吐仍受共享瓶颈限制；且每增加一条子流都会带来窗口、定时器、内存开销，子流过多反而可能降低整体性能。

为何常见：只看“带宽相加”的理想公式，忽略了现实中路径会共享物理资源的约束。

误区用了 MPTCP，从 WiFi 切到蜂窝就完全不会卡，像瞬移一样。

正解子流切换仍有路径检测和调度收敛时间，而且旧链路上在途的数据可能只能等待超时重传。MPTCP 的优势是把传统 TCP 的秒级重连降到百毫秒级并保持应用连接不断，但做不到绝对零延迟。

为何常见：把“应用连接不断”误解成“网络不发生任何丢包和延迟”。

误区每个子流都用自己的拥塞控制算法，加起来本身就是公平的，不用额外协调。

正解多个子流很可能汇聚到同一个瓶颈路由器，若各自独立控制，多路径连接会同时抢占瓶颈，总体流量显著超过普通 TCP，对其他流量不公平。LIA 等耦合算法通过共享窗口增量控制，让 MPTCP 既不失去多路径收益，也不比单路径更霸道。

为何常见：把拥塞控制看作“每条路各管各的”，忽略了不同路径可能共享关键节点。

面试题

Q1. MPTCP 与传统 TCP 最核心的区别是什么？

单选题 · easy

  • A.使用 UDP 传输数据
  • B.一个连接内可建立多条子流← 正确答案
  • C.不需要三次握手
  • D.只能用于无线网络

答案：B。MPTCP 的关键在于把一条逻辑 TCP 连接映射到多条子流上，子流各自走不同路径，但共享连接级序号。它仍然要三次握手，也兼容传统 TCP，并不局限于无线网络。

Q2. 下列哪个概念描述“一条链路上最多能同时在途的数据量”？

单选题 · easy

  • A.拥塞窗口
  • B.接收窗口
  • C.带宽时延积← 正确答案
  • D.最大传输单元

答案：C。带宽时延积（BDP）= 带宽 × 往返时延，表示链路管道中能容纳的在途数据。拥塞窗口和接收窗口是发送/接收端各自的限制，最大传输单元是单个数据包尺寸。

Q3. MPTCP 在首个 SYN 中用来协商多路径能力的 TCP 选项是？

单选题 · mid

  • A.MP_CAPABLE← 正确答案
  • B.ADD_ADDR
  • C.MP_JOIN
  • D.DSS

答案：A。MP_CAPABLE 是 MPTCP 的第一次握手选项，双方确认支持多路径；ADD_ADDR 用于通告新地址以新增子流，MP_JOIN 用于加入已有连接，DSS 用于数据序号映射。

Q4. 多路径拥塞控制 LIA 算法的核心目标是？

单选题 · mid

  • A.让每个子流窗口独立翻倍
  • B.保证整体不比单路径 TCP 更激进← 正确答案
  • C.消除所有网络拥塞
  • D.让各子流带宽完全相同

答案：B。LIA 通过耦合窗口增量，使多路径连接在共享瓶颈上对单路径 TCP 保持友好，既利用多路径资源，又不侵占普通流量的公平份额。

Q5. minRTT 调度器优先选择哪条子流发送数据？

单选题 · mid

  • A.带宽最大的子流
  • B.拥塞窗口最大的子流
  • C.往返时延最小的子流← 正确答案
  • D.丢包率最高的子流

答案：C。minRTT 调度器选择 RTT 最小的子流，因为时延越小，反馈越快、送达越快；当该子流窗口满载时再把数据交给次快子流。

Q6. MPTCP 在 WiFi 与蜂窝切换时能保持应用连接不间断，主要原因是？

单选题 · easy

  • A.它让基站扩展信号覆盖
  • B.它提前维护了多条可用子流← 正确答案
  • C.它压缩了所有视频数据
  • D.它改变了物理层调制方式

答案：B。MPTCP 让 WiFi 和蜂窝两条子流同时存在，切换只是改变调度权重，应用层看到的连接从未断开，因此不需要重新握手。

Q7. 在路径完全独立的前提下，MPTCP 总吞吐量的理想上限是？

单选题 · hard

  • A.最优子流带宽
  • B.所有子流带宽之和← 正确答案
  • C.所有子流带宽的平均值
  • D.单条路径的带宽时延积

答案：B。多条独立路径可并行传输不同数据，总吞吐理论上等于各子流带宽之和；若路径共享瓶颈，则实际值会被瓶颈链路限制。

Q8. 下列关于 MPTCP 的说法，正确的有哪些？

多选题 · mid

  • A.应用层无需感知子流变化← 正确答案
  • B.子流之间共享连接级序号← 正确答案
  • C.它必须同时使用 WiFi 和蜂窝
  • D.它可在多网卡设备上聚合带宽← 正确答案

答案：ABD。MPTCP 对应用层透明，子流共享统一序号；它不强制要求无线双网，有线多网卡同样适用，因此 C 错误，D 正确。

Q9. 关于 MPTCP 的拥塞控制耦合，下列说法正确的是？

多选题 · hard

  • A.多条子流可能共享同一瓶颈链路← 正确答案
  • B.独立拥塞控制会导致整体过于激进← 正确答案
  • C.LIA 需要限制总窗口增长速度← 正确答案
  • D.耦合后各子流必须使用相同拥塞窗口

答案：ABC。多子流可能在某个路由器汇聚，独立控制会总窗口过大，所以需要 LIA 限制整体增量。但各子流窗口仍可根据自己路径的 RTT 和丢包独立变化，D 错误。

Q10. 下列哪些属于 MPTCP 在实际部署中的收益或注意事项？

多选题 · extreme

  • A.手机可利用 WiFi 与蜂窝聚合提升吞吐← 正确答案
  • B.数据中心可用多链路冗余降低故障影响← 正确答案
  • C.子流数量越多越好
  • D.路径共享瓶颈时聚合收益会下降← 正确答案

答案：ABD。智能手机和数据中心是 MPTCP 的两大典型场景，多路径可提升吞吐与冗余。但子流过多会带来管理开销，且共享瓶颈会限制聚合收益，因此 C 错误。