我试图了解 MPTCP 如何将其自身与在多条路径上运行的“正常”TCP 实现区分开来。
具体来说，我想知道 TCP 的最佳实现对于数据包重新排序的鲁棒性是否真的不如 MPTCP 实现。
我遇到了两个有趣的消息来源，首先TCP Linux 中数据包重排序的分析。它描述了 TCP 实现如何以各种方式或多或少高效地处理重新排序。这不是关于 MPTCP，而是关于多路径上的 TCP！该论文强调了一种有趣的策略，显然是在默认的 Linux TCP 解决方案中实现的（有趣的是，也用于更具实验性的 TCP Westwood 实现）（在这里，我所说的“有趣的策略”是使用 DSACK 来区分重新排序的数据包和数据包丢失）。
但奇怪的是，后一个链接将 Linux TCP 解决方案与 MPTCP 进行了比较，并得出结论，MPTCP 效率较低。不过，这是在每秒兆字节数量级的低带宽上进行的。MPTCP 的吞吐量非常稳定，但显然总体上不如 Linux TCP 高效。
现在，我已经看过了2012 年 MPTCP 绩效分析这在多个地方表明，当流量通过具有广泛差异 RTT（这对于数据包重新排序很常见）的链路以及千兆字节容量的链路时，MPTCP 会因重新排序而受到很大的影响。
现在，我的问题是……MPTCP 如何以及在何处遭受重新排序？MPTCP 描述自己为每个单独的链接创建子流，其中子流本质上是一个小型 TCP 连接。我不明白的是，如果 MPTCP 在每个单独的流上验证其数据包的到达顺序，它怎么还会遭受数据包重新排序呢？
我的直觉是，当子流“合并”时，可能需要对数据包进行重新排序，但不应混淆数据包是丢失还是仅仅延迟（无序），这意味着不应出现由无序数据包导致的重大性能损失。
答案1
我已经找到了足够的答案这篇 MPTCP 论文本质上，MPTCP 对“整体”流以及每个流都具有顺序顺序。这意味着 MPTCP 在数据包重新排序方面理论上应该不比 TCP 有优势。
MPTCP 接收器使用连接级序列号按顺序重新组装来自不同 [SubFlows] 的数据流，以按顺序将它们传递到应用层。因此，MPTCP 使用数据排序映射 (DSM) 在两个序列间距之间进行转换。图 1 中可以清楚地描绘出 DSM，其中数据包 (5-S2) 的数据序列号等于 5，子流序列号等于 2。当且仅当子流序列和数据序列都符合预期时，到达的数据包才被称为按顺序到达。