一、包失序

包失序原因

在IP网络中出现包失序的原因在于IP层不能保证包传输是有序进行的

这一方面是有利的（至少对IP层来说），因为IP可以选择另一条传输链路（例如传输速度更快的路径），而不用担心新发送的分组会先于旧数据到达，这就导致数据的接收顺序与发送顺序不一致

还有其他的原因也会导致包失序。例如，在硬件方面一些高性能路由器会采用多个并行数据链路[BPS99]，不同的处理延时也会导致包的离开顺序与到达顺序不匹配

失序问题可能存在于TCP连接的正向或反向链路中（也可能两者同时存在）。数据段的失序与ACK包的失序对TCP的影响有一定差别。回忆一下，由于非对称路由，经常会出现ACK经不同于数据包的链路（和不同路由器）传输

在反向链路中

当传输出现失序时，TCP可能会在某些方面受影响

如果失序发生在反向(ACK)链路，就会使得TCP发送端窗口快速前移，接着又可能收到一些显然重复而应被丢弃的ACK。由于TCP的拥塞控制行为，这种情况会导致发送端出现不必要的流量突发（即瞬时的高速发送）行为，影响可用网络带宽

在正向链路中

如果失序发生在正向链路，TCP可能无法正确识别失序和丢包

数据的丢失和失序都会导致接收端收到无序的包，造成数据之间的空缺

当失序程度不是很大（如两个相邻的包交换顺序），这种情况可以迅速得到处理。反之，当出现严重失序时，TCP会误认为数据已经丢失。这就会导致伪重传，主要来自快速重传算法

回顾一下前面介绍过的快速重传：

回忆一下之前的讨论，快速重传是根据收到重复ACK来推断出现丢包并启动重传，而不必等待重传计时器超时

由于TCP接收端会对接收到的失序数据立即返回ACK，以此来帮助触发快速重传，因此网络中任何一个失序的数据包都会生成重复ACK

由于网络中少量失序情况是常见的，假设一旦收到重复ACK，发送端即启动快速重传，那么就会导致大量不必要的重传发生。为解决这一问题，快速重传仅在达到重复阈值后才会被触发

dupthresh阈值见前面介绍：

演示案例

下图描述了上述情况：

图中左半部分表示在轻微失序的情况下TCP的操作，这里的dupthresh设为3。单个重复ACK不会影响TCP的行为

右半部分表示出现严重失序时的情况。由于出现了3次失序，对应生成了3次重复ACK，因此触发了快速重传，使得接收端收到了一个重复报文段

总结：
- 区分丢包与失序不是一个很重要的问题。要解决它需要判断发送端是否已经等待了足够长的时间来填补接收端的空缺
- 幸运的是，互联网中严重的失序并不常见[JO3]，因此将dupthresh设为相对较小值（如缺省值为3）就能处理绝大部分情况
- 即便如此，还是有很多研究致力于调整TCP行为来应对严重失序[LLYO7]。有些方法可动态调整dupthresh，如 Linux的TCP实现

二、包重复

尽管出现得比较少，但IP协议也可能出现将单个包传输多次的情况。例如，当链路层网络协议执行一次重传，并生成同一个包的两个副本。当重复生成时，TCP可能出现混淆

演示案例

考虑下图中的情况，包3重复生成三个副本

从图中可看到，包3的多次重复会使得接收端生成一系列的重复ACK，这足以触发伪快速重传，使得非SACK发送端误认为包5与包6更早到达

利用SACK（特别是DSACK），就可以简单地忽略这个问题。采用DSACK，每个A3的重复ACK都包含报文段3已成功接收的信息，并且没有包含失序数据信息，意味着到达的包（或ACK）一定是重复数据

TCP通常都可防止此类伪重传