TCP乱序传输-CSDN博客

互联网初始目标是提供二次核打击能力，就是说当被炸了一次之后，还能继续反击，显而易见，严重故障时的生存能力是这个网络的首要目标。

大卫克拉克本人说互联网架构没有考虑性能，管理及安全，至少是没有将这些目标排在优先的位置。针对现如今的各种高性能需求，基于互联网假设的优化手段显然满足不了，彻底的高性能目标需要对根基架构做彻底重构。

推荐大卫克拉克的《互联网的设计和演化》。

说说TCP的保序和乱序。

TCP的流式假设和互联网的分组交换是相悖的，幸运的是，路由总是收敛到稳定状态，重收敛是罕见的，过程是迅速的，因此稳定的路由是常态。

该常态下，TCP流会沿固定路径被路由到接受端，数据包几乎是按序到达的，只在短暂的反常态下，才有短暂的乱序。

发生乱序时，要么接收端暂存乱序段，期望不久后空洞被填充，否则GBN也能完全覆盖乱序造成的空洞，总之，TCP始终能确保行为的正确。

但按序传输显然是低效的，这种低效不是很容易理解。我尝试描述。
设TCP流的RTT是T，窗口为W，如果按序传输，一个RTT内，会有至多W个报文inflight，按照Little定律，我们可以算出：

W

=

λ

∗

T

W=\lambda *T

W=λ∗T

那么

λ

\lambda

λ就是发送端的发送速率。如果把保序传输约束去掉，在多条路径(Multipath)同时发送，理论上inflight会接近发送端发送能力的极限：

n

W

=

n

λ

∗

T

nW=n\lambda *T

nW=nλ∗T

拥塞控制可以针对端主机而不是针对流，这样做对ISP计费也能降低复杂性。

不允许乱序传输的原因是接收端内存消耗太大，在内存昂贵的1970年代～1980年代，乱序传输并不现实。
如今内存已不是问题，自然会顺理发展到逐步解除保序约束，但即便Multipath TCP有点并行传输的意思，也依然没有完全解除保序约束，且subflow更多地被用于Standby而不是LB。

我想这是思维定势没被打破，在传统观念里，TCP乱序传输还能叫TCP吗？就像工人们不能接受丢包必须重传一样，不能乱序，不能丢包的观念，是当代传输优化的障碍。

姑且不谈Multipath，谈谈路由器转发。

路由器没有保序职责，保序逻辑会对数据包增加额外操作，延时会因此增加，哪怕是一小点。早期路由器没有为TCP专门保序，因为早期带宽低，不需要并行操作或并行度很低，天然保序。但现在不一样了。

依然是Little定律，假设路由转发的时间为常数t，入口速率为\lambda，路由器内同时执行转发的数据包数量C：

C

=

λ

∗

t

C=\lambda *t

C=λ∗t

若要支撑更高速率\lambda，C就要很大，这意味着需要更多池化的计算单元并行工作，但凡并行就会乱序。为了迎合TCP的保序传输：

• 要么对并行操作增加保序逻辑。
• 要么根据元组状态串行一条流。

无论哪一个都需要增加额外逻辑，额外逻辑对性能是伤害。假设接收端配备足够大的内存，这个保序处理显然就不必要了。

当前主机内存显然已足够，但为什么路由器依然还在迎合TCP呢？还是木桶效应，为保证可用性，得保证最low的可用性。你需要知道自己能完全覆盖的系统中最low的点。

除了路由器，所有具有每跳行为(PHB)的设备均有同样的保序问题。

回顾一下，1970年代～1980年代，网络带宽低，接收端内存小，因此路由器无需额外的昂贵的专门保序就是天然保序，对接收端而言，保序就不需要太大内存，低带宽和低内存相互支撑。

2000年代～2010年代后，带宽迅猛增加，接收端内存也迅猛增加，路由器的额外保序逻辑越来越昂贵，代价越来越大却不再有收益，理论上讲接收端内存同步增加，高带宽和高内存依然相互支撑，保序就不必要了，但现实并非如此，思维定势和木桶效应让TCP保序传输保留了下来。

并且，Multipath也未竟全功。

读《互联网的设计和演化》有感。

浙江温州皮鞋湿，下雨进水不会胖。