TCP：超时和重传

检查连续重传之间不同的时间差，它们取整后分别为1、3、6、12、24、48和多个64秒。后面将看到当第一次发送后所设置的超时时间实际上为1.5秒（它在首次发送后的1.0136秒而不是精确的1.5秒后，发生的原因已经解释过），此后该时间在每次重传时增加1倍并直至64秒

这个倍乘关系被称为 指数退避 。可以将该例子与TFTP例子比较，在那里每次重传总是在前一次的5秒后发生

首次分组传输（第6行，24.480秒）与复位信号传输（第19行，566.488秒）之间的时间差约为 9分钟

在一个分组重传时会产生这样一个问题：假定一个分组被发送。当超时发生时，RTO如第一个例子中显示的那样进行延长，分组以更长的RTO进行重传，然后收到一个确认。那么这个ACK是针对第一个分组的还是针对第二个分组呢？这就是所谓的 重传多义性问题 :

• 当一个超时和重传发生时，在 重传数据的确认最后到达之前，不能更新RTT估计器 因为并不知道ACK对应哪次传输（也许第一次传输被延迟而并没有被丢弃，也有可能第一次传输的ACK被延迟）
• 如果 数据被重传 RTO已经得到了一个指数延长，在 下一次传输时使用这个延长后的RTO
• 没有被重传 的报文段而言， 除非收到了一个确认，否则不要计算新的RTO

将使用以下这些例子来检查TCP的超时和重传、慢启动以及拥塞避免等方方面面的实现细节

使用sock程序和如下的命令来将32768字节的数据从主机slip发送到主机vangogh.cs.berkeley.edu上的discard服务：

slip$ sock -D -i -n32 vangogh.cs.berkeley.edu discard

slip通过两个SLIP链路与140.252.1以太网相连，并从这里通过Internet到达目的地。通过使用两个9600b/s的SLIP链路，期望能够得到一些可测量的时延

该命令执行32个写1024字节的操作。由于slip和bsdi之间的MTU为296字节，因此这些操作会产生128个报文段，每个报文段包含256字节的用户数据。整个传输过程的时间约为45秒，可以观察到了一个超时和三次重传

当该传输过程进行时，在slip上使用tcpdump来截获所有的发送和接收的报文段，并通过使用 -D 选项来打开socket debug功能，这样便可以通过运行一个修改后的trpt(8)程序来打印出连接控制块中与RTT、慢启动及拥塞避免等有关的多个变量

图21-2显示的是前5秒中的数据和确认的传输过程。虽然仅能够在运行tcpdump的主机上测量分组发送和接收的时间，但在本图中希望显示出分组正在网络中传输（它们确实存在，因为这个局域网连接与共享式的以太网并不一样）以及接收主机何时可能产生ACK

注意：在本图中已经将报文段按照在主机slip上发送和接收的序号记为1~13和15。这与在这个主机上所收集的tcpdump的输出结果有关

慢启动算法是在一个连接上发起数据流的方法，但有时会达到中间路由器的极限，此时分组将被丢弃。拥塞避免算法是一种 处理丢失分组 的方法

该算法假定由于分组受到损坏引起的丢失是非常少的（远小于1%），因此分组丢失就意味着在源主机和目的主机之间的某处网络上发生了拥塞。有两种分组丢失的指示：

• 发生超时
• 接收到重复的确认

  拥塞避免算法和慢启动算法是两个目的不同、独立的算法

  但是当拥塞发生时，希望降低分组进入网络的传输速率，于是可以调用慢启动来作到这一点

  在实际中这两个算法通常在一起实现

拥塞避免算法和慢启动算法需要对每个连接维持两个变量：一个拥塞窗口 cwnd 和一个慢启动门限 ssthresh 。这样得到的算法的工作过程如下：

1. 对一个给定的连接，初始化cwnd为1个报文段，ssthresh为65535个字节
2. TCP输出例程的输出不能超过cwnd和接收方通告窗口的大小
   • 拥塞避免：是发送方使用的流量控制，发送方感受到的网络拥塞的估计
   • 而通告窗口则是接收方进行的流量控制，接收方在该连接上的可用缓存大小有关
3. 当拥塞发生时（超时或收到重复确认）：
   • ssthresh被设置为当前窗口大小的一半
   • cwnd和接收方通告窗口大小的最小值，但最少为2个报文段
   • 如果是超时引起了拥塞，则cwnd被设置为1个报文段（这就是慢启动）
4. 当新的数据被对方确认时，就增加cwnd，但增加的方法依赖于是否正在进行慢启动或拥塞避免：
   • 如果cwnd小于或等于ssthresh，则正在进行慢启动，否则正在进行拥塞避免
   • 慢启动一直持续到回到当拥塞发生时所处位置的半时候才停止（因为记录了在步骤2中给制造麻烦的窗口大小的一半），然后转为执行拥塞避免

慢启动算法初始设置cwnd为1个报文段，此后每收到一个确认就加1。这会使窗口按指数方式增长：发送1个报文段，然后是2个，接着是4个……

拥塞避免算法要求每次收到一个确认时将cwnd增加1/cwnd。与慢启动的指数增加比起来，这是一种 加性增长 。有时希望在一个往返时间内最多为cwnd增加1个报文段（不管在这个RTT中收到了多少个ACK），然而慢启动将根据这个往返时间中所收到的确认的个数增加cwnd

所有的4.3BSD版本和4.4BSD都在拥塞避免中将增加值不正确地设置为1个报文段的一小部分（即一个报文段的大小除以8），这是错误的，并在以后的版本中不再使用

但是，为了和（不正确的）实现的结果对应，我们在将来的计算中给出了这个细节

4.3BSD Tahoe版本仅在对方处于一个不同的网络上时才进行慢启动。而4.3BSD Reno版本改变了这种做法，因此，慢启动总是被执行

图21-8是慢启动和拥塞避免的一个可视化描述：

图中以段为单位来显示cwnd和ssthresh，但它们实际上都是以字节为单位进行维护的

假定当cwnd为32个报文段时就会发生拥塞，于是设置ssthresh为16个报文段，而cwnd为1个报文段在时刻0发送了一个报文段：

• 假定在时刻1接收到它的ACK，此时cwnd增加为2
• 接着发送了2个报文段，并假定在时刻2接收到它们的ACK，于是cwnd增加为4（对每个ACK增加1次）
• 这种指数增加算法一直进行到在时刻3和4之间收到8个ACK后cwnd等于ssthresh时才停止
• 从该时刻起，cwnd以线性方式增加，在每个往返时间内最多增加1个报文段

正如在这个图中看到的那样，术语 慢启动 并不完全正确。它 只是采用了比引起拥塞更慢些的分组传输速率 ，但在慢启动期间进入网络的分组数增加的速率仍然是在增加的。只有在达到ssthresh 拥塞避免 算法起作用时，这种增加的速率才会慢下来

拥塞避免算法的修改建议1990年提出。在例子中已经可以看到这些实施中的修改

在收到一个失序的报文段时，TCP立即需要产生一个ACK（一个重复的ACK）。这个重复的ACK不应该被迟延。该重复的ACK的在于让对方知道收到一个失序的报文段，并告诉对方自己希望收到的序号

由于不知道一个重复的ACK是 由一个丢失的报文段 引起的，还是由于仅仅出现了 几个报文段的重新排序 ，因此等待少量重复的ACK到来。假如这只是一些报文段的重新排序，则在重新排序的报文段被处理并产生一个新的ACK之前，只可能产生1~2个重复的ACK。如果一连串收到3个或3个以上的重复ACK，就非常可能是一个报文段丢失了。于是就重传丢失的数据报文段，而无需等待超时定时器溢出。这就是 快速重传算法 。接下来执行的不是慢启动算法而是拥塞避免算法。这就是 快速恢复算法

在图21-7中可以看到在收到3个重复的ACK之后没有执行慢启动。相反，发送方进行重传，接着在收到重传的ACK以前，发送了3个新的数据的报文段（报文段67,69和71）

在这种情况下没有执行慢启动的原因是由于收到重复的ACK不仅仅告诉我们一个分组丢失了。由于接收方只有在收到另一个报文段时才会产生重复的ACK，而该报文段已经离开了网络并进入了接收方的缓存。也就是说，在收发两端之间仍然有流动的数据，而 不想执行慢启动来突然减少数据流

这个算法通常按如下过程进行实现：

1. 当收到第3个重复的ACK时：
   • 将ssthresh设置为当前拥塞窗口cwnd的一半
   • 重传丢失的报文段
   • 设置cwnd为ssthresh加上3倍的报文段大小
2. 每次收到另一个重复的ACK时，cwnd增加1个报文段大小并发送1个分组（如果新的cwnd允许发送）
3. 当下一个确认新数据的ACK到达时：设置cwnd为ssthresh（在第1步中设置的值）
   • 这个ACK应该是在进行 重传后的一个往返时间内对步骤1中重传的确认
   • 这个ACK也应该是对 丢失的分组和收到的第1个重复的ACK之间的所有中间报文段的确认
   • 这一步采用的是 拥塞避免 ，因为当分组丢失时已经将当前的速率减半

通过使用tcmdump和sock debug选项来观察一个连接，就会在发送每一个报文段时看到cwnd和ssthresh的值。如果MSS为256字节，则cwnd和ssthresh的初始值分别为 256 和 65535 字节。每当收到一个ACK时，可以看到cwnd增加了一个MSS，取值分别为512, 768, 1024, 1280等。假定不会发生拥塞，则最终拥塞窗口将超过接收方的通告窗口，意味着通告窗口将对数据流进行限制

一个更有趣的例子是观察在拥塞发生时的情况。使用与21.4节同样的例子。当这个例子运行时发生了4次拥塞。为建立连接而发送的初始SYN有一个因超时而引起的重传，接着在数据传输过程中有3个分组丢失

下表显示了当初始SYN重传并接着发送了前7个数据报文段时变量cwnd和ssthresh的值。使用tcpdump的记号来表示数据字节：1:257(256)表示第1~256字节

• 当SYN的超时发生时，ssthresh被置为其最小取值（512字节，在本例中表示2个报文段）。为进入慢启动阶段，cwnd被置为1个报文段（256字节，与当前值一致）
• 当收到SYN和ACK时，没有对这两个变量做任何修改，因为新的数据还没有被确认
• 当ACK 257到达时，因为cwnd小于等于ssthresh，因此仍然处于慢启动阶段，于是将cwnd增加256字节
• 当收到ACK 513时，进行同样的处理
• 当ACK 769到达时，不再处于慢启动状态，而是进入了拥塞避免状态。新的cwnd值按以下方法计算： \begin{equation} cwnd \gets cwnd + \frac{segsize * segsize}{cwnd} + \frac{segsize}{8} \end{equation}

考虑到cwnd实际上以字节而非以报文段来维护，因此这就是前面提到的增加1/cwnd。在这个例子中计算：

为 885 字节。当下一个ACK1025到达时：

为 991 字节

正如我们在前面描述的，在这些表达式中包括了不正确的256/8项来匹配实现计算的数值

这个cwnd持续增加一直到在图21-6所示的发生在10秒左右的第1次重传。本表是使用与图21-6相同数据得到的图表，并给出了cwnd增加的数值

前6个值就是为图21-9所计算的数值。要想直观分辨出在慢启动过程中的指数增加和在拥塞避免过程中的线性增加之间的区别是不可能的，因为慢启动的过程太快

现在来解释在重传的3个点上所发生的情况。回想起每个重传都是因为收到3个重复的ACK，表明1个分组丢失了。这就是 快速重传算法 。ssthresh立即设置为当重传发生时正在起作用的窗口大小的一半，但是在接收到重复ACK的过程中cwnd允许保持增加，这是因为每个重复的ACK表示1个报文段已离开了网络。这就是 快速恢复算法

图21-10表示了cwnd和ssthresh的数值。第一列上的报文段编号与图21-7对应：

cwnd的值一直持续增加，从图21-9中对应于报文段12的最终取值（1089）到下表中对应于报文段58的第一个取值（2426），而ssthresh的值则保持不变（512），这是因为在此过程中没有出现过重传

• 报文段60和61：当最初的2个重复的ACK到达时它们被计数，而cwnd保持不变
• 当第3个重复的ACK到达时，ssthresh被置为cwnd的一半，而cwnd被置为ssthresh加上所收到的重复的ACK数乘以报文段大小（也即1024加上3倍的256），然后发送重传数据
• 报文段64~66, 68和70：又有5个重复的ACK到达，每次cwnd增加1个报文段长度
• 报文段72：最后一个新的ACK到达时，cwnd被置为ssthresh（1024）并进入正常的拥塞避免过程。由于cwnd小于等于ssthresh（现在相等），因此报文段的大小增加到cwnd，取值为1280
• 当下一个新的ACK到达（没有在图21-11中表示出来）时，cwnd大于ssthresh，取值为1363

在快速重传和快速恢复阶段， 收到报文段66、68和70中的重复的ACK后才发送新的数据 ，而不是在接收到报文段64和65中重复的ACK之后就发送。这是 cwnd的取值与未被确认的数据大小比较 的结果。当报文段65到达时，cwnd为2048，但未被确认的数据有2304字节（9个报文段：46,48,50,52,54,55,57,59和63），因此不能发送任何数据。当报文段65到达后，cwnd被置为2304，此时仍不能进行发送。但是当报文段66到达时，cwnd为2560，所以可以发送1个新的数据报文段。类似地，当报文段68到达时，cwnd等于2816，该数值大于未被确认的2560字节的数据大小，因此可以发送另1个新的数据报文段。报文段70到达时也进行了类似的处理

• 时刻14.3发生下一个重传，也是因为收到了3个重复的ACK。因此当另一个ACK到达时，可以看到cwnd以同样的方式增长，之后降低到1024
• 时刻21.1也是因为收到了重复的ACK而引起了重传。在重传后收到了3个重复的ACK，因此观察到cwnd增加3个，之后降低到1280
• 在传输的后面部分，cwnd以线性方式增加到最终值3615

较新的TCP实现在路由表项中维持许多在本章已经介绍过的指标。当一个TCP连接关闭时，如果已经发送了足够多的数据来获得有意义统计资料，且目的结点的路由表项不是一个默认的表项，那么下列信息就保存在路由表项中以备下次使用：被平滑的RTT、被平滑的均值偏差以及慢启动门限。所谓 足够多的数据 是指16个窗口的数据，这样就可得到16个RTT采样，从而使被平滑的RTT过滤器能够集中在正确结果的5%以内

而且，管理员可以使用route(8)命令来设置给定路由的度量：前一段中给出的三个指标以及MT、输出的带宽时延乘积和输入的带宽时延乘积

当建立一个新的连接时，不论是主动还是被动，如果该连接将要使用的路由表项已经有这些度量的值，则用这些度量来对相应的变量进行初始化

看一下TCP是怎样处理一个给定的连接返回的ICMP的差错。TCP能够遇到的最常见的ICMP差错就是 源站抑制 主机不可达 网络不可达

当前基于伯克利的实现对这些错误的处理是：

• 源站抑制：拥塞窗口 cwnd被置为1个报文段大小来发起慢启动 ，但是 慢启动门限ssthresh没有变化 所以窗口将打开直至它或者开放了所有的通路（受窗口大小和往返时间的限制）或者发生了拥塞
• 主机不可达或网络不可达：实际上都被忽略，因为这两个差错都被认为是短暂现象。这有可能是由于中间路由器被关闭而导致选路协议要花费数分钟才能稳定到另一个替换路由。在这个过程中就可能发生这两个ICMP差错中的一个，但是连接并不必被关闭。相反，TCP试图发送引起该差错的数据，尽管最终有可能会超时

  当前基于伯克利的实现记录发生的ICMP差错，如果连接超时，ICMP差错被转换为一个更合适的的差错码而不是“连接超时”

  早期的BSD实现在任何时候收到一个主机不可达或网络不可达的ICMP差错时会不正确的放弃连接

当TCP超时并重传时，它不一定要重传同样的报文段。相反，TCP允许 进行重新分组而发送一个较大的报文段 ，这将有助于提高性能（当然，这个较大的报文段不能够超过接收方声明的MSS）。在协议中这是允许的，因为TCP是使用字节序号而不是报文段序号来进行识别它所要发送的数据和进行确认。

在实际中，可以很容易地看到这一点。使用sock程序连接到丢弃服务器并键入一行。接着拔掉以太网电缆并再键入一行。当这一行被重传时，键入第3行。我们预期下一个重传包含第2次和第3次键入的数据：

bsdi $ sock svr4 discard

hello there #第一行发送成功
#接着断开以太网电缆

line number 2 #本行被重传
and 3 # 在第2行发送成功之前键入本行
# 重新连接以太网电缆

图21-13显示了tcpdump的输出：

• 第1行：显示了"hello there"被发送
• 第2行："hello there"的ACK

接着拔掉以太网电缆并键入"line number 2"（14字节，包括换行）

• 第3行："line number 2"被发送
• 第4行和第行：重传"line number3"

键入"and 3"（6个字节，包括换行）

• 第6行：这个重传包括20个字节：键入的两行
• 第7~8行：继续重传这两行
• 第9行：当重传到达时，它确认了这20字节的数据

Next：TCP 坚持定时器

Previous：TCP 成块数据流

Home：目录