第22章 TCP的坚持定时器

22.3 糊涂窗口综合症

基于窗口的流量控制方案，如TCP所使用的，会导致一种被称为“糊涂窗口综合症SWS (Silly Window Syndrome）”的状况。如果发生这种情况，则少量的数据将通过连接进行交换，而不是满长度的报文段[Clark 1982]。

该现象可发生在两端中的任何一端：接收方可以通告一个小的窗口（而不是一直等到有大的窗口时才通告），而发送方也可以发送少量的数据（而不是等待其他的数据以便发送一个大的报文段）。可以在任何一端采取措施避免出现糊涂窗口综合症的现象。

1. 接收方不通告小窗口。通常的算法是接收方不通告一个比当前窗口大的窗口（可以为0），除非窗口可以增加一个报文段大小（也就是将要接收的MSS）或者可以增加接收方缓存空间的一半，不论实际有多少。
2. 发送方避免出现糊涂窗口综合症的措施是只有以下条件之一满足时才发送数据：(a)可以发送一个满长度的报文段；(b)可以发送至少是接收方通告窗口大小一半的报文段；(c)可以发送任何数据并且不希望接收ACK（也就是说，我们没有还未被确认的数据）或者该连接上不能使用Nagle算法（见第19.4节）。

条件(b)主要对付那些总是通告小窗口（也许比1个报文段还小）的主机，条件(c)使我们在有尚未被确认的数据（正在等待被确认）以及在不能使用Nagle算法的情况下，避免发送小的报文段。如果应用进程在进行小数据的写操作（例如比该报文段还小），条件(c)可以避免出现糊涂窗口综合症。

这三个条件也可以让我们回答这样一个问题：在有尚未被确认数据的情况下，如果Nagle算法阻止我们发送小的报文段，那么多小才算是小呢？从条件(a)中可以看出所谓“小”就是指字节数小于报文段的大小。条件(b)仅用来对付较老的、原始的主机。

步骤2中的条件(b)要求发送方始终监视另一方通告的最大窗口大小，这是一种发送方猜测对方接收缓存大小的企图。虽然在连接建立时接收缓存的大小可能会减小，但在实际中这种情况很少见。

一个例子

现在我们通过仔细查看一个详细的例子来观察实际避免出现糊涂窗口综合症的情况，该例子也包括了坚持定时器。我们将在发送主机sun上运行sock程序，并向网络写6个1024字节的数据。

sun % sock -i -n6 bsdi 7777

但是在主机bsdi的接收过程中我们加入一些暂停。在第1次读数据前暂停4秒，之后每次读之前暂停2秒。而且，接收方进行的是256字节的读操作：

bsdi % sock -i -s -P4 -p2 -r256 7777

最初的暂停是为了让接收缓存被填满，迫使发送方停止发送。随后由于接收方从网络上进行了一些小数目的读取，我们预期能看到接收方采取的避免糊涂窗口综合症的措施。

图22-2是传输6144字节数据的时间系列（我们去掉了连接建立过程）。

我们还需要跟踪在每个时间点上读取数据时应用程序的运行情况、当前正在接收缓存中的数据的序号以及接收缓存中可用空间的大小。图22-3显示了所发生的每件事情。

图22-3中的第1列是每个行为的相对时间点。那些带有3位小数点的时间是从tcpdump的输出结果（图22-2）中得到的，而小数点部分为99的则是在接收服务器上产生行为的估计时间（使这些在接收方的估计时间包含一秒的99%仅与图22-2中的报文段20和22有关，它们是我们能够从tcpdump的输出结果中看到的由接收主机超时引起的仅有的两个事件。而在主机bsdi上观察到的其他分组，则是由接收到来自发送方的一个报文段所引起的。这同样是有意义的，因为这就使我们可以将最初的4秒暂停刚好放置在发送方发送第1个数据报文段的时间0前面。这是接收方在连接建立过程中收到它的SYN的ACK之后将要获得控制权的大致时间）。

图22-2 显示接收方避免出现糊涂窗口综合症的时间系列

当接收到来自发送方的数据时，接收方缓存中的数据增加，而当应用进程从缓存中读取数据时，数据就减少。接下来我们关注的是接收方发给发送方的窗口通告以及这些窗口通告是什么。这样就可以使我们看到接收方是如何避免糊涂窗口综合症的。

前4个数据报文段及其ACK（报文段1~5）表示发送方正在填充接收方的缓存。在那个时刻发送方停止了发送，但仍然有更多的数据需要发送。它将自己的坚持定时器置为最小值5分钟。

当坚持定时器时间到时，就发送出1个字节的数据（报文段6）。接收的应用进程已经从接收缓存中读取了256字节的数据（在时刻3.99），因此这个字节被接受并被确认（报文段7段）。但是通告窗口仍为0，由于接收方仍然没有足够的空间来接收一个满长度的报文，或者不能腾出缓存空间的一半。这就是接收方的糊涂窗口避免措施。

图22-3 接收方避免出现糊涂窗口综合症的事件序列

发送方的坚持定时器被复位，并在5秒后再次到时（在时刻10.151）。然后又发送一个字节并被确认（报文段8和9），而接收方的缓存空间还不够用（1022字节），使得通告窗口为0。

发送方的坚持定时器在时刻15.151再次时间到，又发送了另一个字节并被确认（报文段10和11）。这一次由于接收方有1533字节的有效缓存空间，因此通告了一个非0窗口。发送方立即利用这个窗口发送了1024字节的数据（报文段12）。对这1024字节数据的确认（报文段13）通告其窗口为509字节。这看起来与我们在前面看到的小窗口通告相抵触。

在这里之所以发生这种情况，是因为报文段11段通告了一个大小为1533字节的窗口，而发送方只使用了其中的1024字节。如果在报文段13中的ACK通告其窗口为0，就会违反窗口的右边沿不能向左边沿移动而导致窗口收缩的TCP原则（见第20.3节）。这就是为什么必须通告一个509字节的窗口的原因。

接下来我们看到发送方没有立即向这个小窗口发送数据。这就是发送方采取的糊涂窗口避免策略。相反，它等待另一个坚持定时器在时刻20.151到时间，并在该时刻发送509字节的数据。尽管它最终还是发送了一个长度为509字节的小数据段，但在发送前它等待了5秒钟，看是否会有一个ACK到达，以便可以将窗口开得更大。这509字节的数据使得接收缓存仅剩下768字节的有效空间，因此接收方通告窗口为0（报文段15）。

坚持定时器在时刻25.151再次到时间，发送方发送1个字节，于是接收缓存中有1279字节的可用空间，这就是在报文段17所通告的窗口大小。

发送方只有另外的511个字节的数据需要发送，因此在收到1279的窗口通告后立刻发送了这些数据（报文段18）。这个报文段也带有FIN标志。接收方确认数据和FIN，并通告窗口大小为767（见习题22.2）。

由于发送应用进程在执行完6个1024字节的写操作后发出关闭命令，发送方的连接从ESTA BLISHED状态转变到FIN_WA IT_1状态，再到FIN_WA IT_2状态（见图18-12）。它一直处于这个状态，直到收到对方的FIN。在这个状态上没有设置定时器（回忆我们在18.6节结束时的讨论），因为它在报文段18中发送的FIN被报文段19确认。这就是为什么我们看到发送方直到接收到FIN（报文段21）为止没有发送其他任何数据的原因。

接收应用进程继续每隔2秒从接收缓存区中读取256个字节的数据。为什么在时刻39.99发送ACK（报文段20）呢？这是因为应用进程在时刻39.99读取数据时，接收缓存中的可用空间已经从原来通告的767（报文段19）变为2816，这相当于接收缓存中增加了额外的2049字节的空间。回忆本节开始讲的第1个规则，因为现在接收缓存已经增加了其空间的一半，因此接收方现在发送窗口更新。这意味着每次当应用进程从TCP的接收缓存中读取数据时，接收的TCP将检查是否需要更新发送窗口。

应用进程在时间51.99发出最后一个读操作，然后收到一个文件结束标志，因为缓存已经变空。这就导致了最后两个完成连接终止的报文段（报文段21和22）的发送。