速读原著-TCP/IP(糊涂窗口综合症)
第22章 TCP的坚持定时器
22.3 糊涂窗口综合症
基于窗口的流量控制方案，如 T C P所使用的，会导致一种被称为“糊涂窗口综合症 S W S(Silly Window Syndrome）”的状况。如果发生这种情况，则少量的数据将通过连接进行交换，而不是满长度的报文段[Clark 1982]。
该现象可发生在两端中的任何一端：接收方可以通告一个小的窗口（而不是一直等到有大的窗口时才通告），而发送方也可以发送少量的数据（而不是等待其他的数据以便发送一个大的报文段）。可以在任何一端采取措施避免出现糊涂窗口综合症的现象。
- 接收方不通告小窗口。通常的算法是接收方不通告一个比当前窗口大的窗口（可以为0），除非窗口可以增加一个报文段大小（也就是将要接收的 M S S）或者可以增加接收方缓存空间的一半，不论实际有多少。
- 发送方避免出现糊涂窗口综合症的措施是只有以下条件之一满足时才发送数据： ( a )可以发送一个满长度的报文段； ( b )可以发送至少是接收方通告窗口大小一半的报文段； ( c )可以发送任何数据并且不希望接收 A C K（也就是说，我们没有还未被确认的数据）或者该连接上不能使用N a g l e算法（见第1 9 . 4节）。条件( b )主要对付那些总是通告小窗口（也许比 1个报文段还小）的主机，条件 ( c )使我们在有尚未被确认的数据（正在等待被确认）以及在不能使用 N a g l e算法的情况下，避免发送小的报文段。如果应用进程在进行小数据的写操作（例如比该报文段还小），条件( c )可以避免出现糊涂窗口综合症。
这三个条件也可以让我们回答这样一个问题：在有尚未被确认数据的情况下，如果 N a g l e算法阻止我们发送小的报文段，那么多小才算是小呢？从条件 ( a )中可以看出所谓“小”就是指字节数小于报文段的大小。条件 ( b )仅用来对付较老的、原始的主机。步骤2中的条件( b )要求发送方始终监视另一方通告的最大窗口大小，这是一种发送方猜测对方接收缓存大小的企图。虽然在连接建立时接收缓存的大小可能会减小，但在实际中这种情况很少见。
一个例子 现在我们通过仔细查看一个详细的例子来观察实际避免出现糊涂窗口综合症的情况，该例子也包括了坚持定时器。我们将在发送主机 s u n上运行s o c k程序，并向网络写 6个1 0 2 4字节的数据。
sun % sock -i -n6 bsdi 7777但是在主机b s d i的接收过程中我们加入一些暂停。在第 1次读数据前暂停4秒，之后每次读之前暂停2秒。而且，接收方进行的是 2 5 6字节的读操作：
bsdi % sock -i -s -P4 -p2 -r256 7777最初的暂停是为了让接收缓存被填满，迫使发送方停止发送。随后由于接收方从网络上进行了一些小数目的读取，我们预期能看到接收方采取的避免糊涂窗口综合症的措施。
图2 2 - 2是传输6 1 4 4字节数据的时间系列（我们去掉了连接建立过程）。我们还需要跟踪在每个时间点上读取数据时应用程序的运行情况、当前正在接收缓存中的数据的序号以及接收缓存中可用空间的大小。图 2 2 - 3显示了所发生的每件事情。
图2 2 - 3中的第1列是每个行为的相对时间点。那些带有3位小数点的时间是从t c p d u m p的输出结果（图2 2 - 2）中得到的，而小数点部分为 9 9的则是在接收服务器上产生行为的估计时间（使这些在接收方的估计时间包含一秒的9 9 %仅与图2 2 - 2中的报文段2 0和2 2有关，它们是我们能够从t c p d u m p的输出结果中看到的由接收主机超时引起的仅有的两个事件。而在主机 b s d i上观察到的其他分组，则是由接收到来自发送方的一个报文段所引起的。这同样是有意义的，因为这就使我们可以将最初的 4秒暂停刚好放置在发送方发送第 1个数据报文段的时间 0前面。这是接收方在连接建立过程中收到它的S Y N的A C K之后将要获得控制权的大致时间）。
当接收到来自发送方的数据时，接收方缓存中的数据增加，而当应用进程从缓存中读取数据时，数据就减少。接下来我们关注的是接收方发给发送方的窗口通告以及这些窗口通告是什么。这样就可以使我们看到接收方是如何避免糊涂窗口综合症的。
前4个数据报文段及其A C K（报文段1 ~ 5）表示发送方正在填充接收方的缓存。在那个时刻发送方停止了发送，但仍然有更多的数据需要发送。它将自己的坚持定时器置为最小值 5分钟。当坚持定时器时间到时，就发送出 1个字节的数据（报文段 6）。接收的应用进程已经从接收缓存中读取了2 5 6字节的数据（在时刻 3 . 9 9），因此这个字节被接受并被确认（报文段 7段）。但是通告窗口仍为0，由于接收方仍然没有足够的空间来接收一个满长度的报文，或者不能腾出缓存空间的一半。这就是接收方的糊涂窗口避免措施。
发送方的坚持定时器被复位，并在 5秒后再次到时（在时刻1 0 . 1 5 1）。然后又发送一个字节并被确认（报文段8和9），而接收方的缓存空间还不够用（1 0 2 2字节），使得通告窗口为0。
发送方的坚持定时器在时刻 1 5 . 1 5 1再次时间到，又发送了另一个字节并被确认（报文段1 0和11）。这一次由于接收方有 1 5 3 3字节的有效缓存空间，因此通告了一个非 0窗口。发送方立即利用这个窗口发送了1 0 2 4字节的数据（报文段1 2）。对这1 0 2 4字节数据的确认（报文段1 3）通告其窗口为5 0 9字节。这看起来与我们在前面看到的小窗口通告相抵触。
在这里之所以发生这种情况，是因为报文段 11段通告了一个大小为 1 5 3 3字节的窗口，而发送方只使用了其中的1 0 2 4字节。如果在报文段1 3中的A C K通告其窗口为0，就会违反窗口的右边沿不能向左边沿移动而导致窗口收缩的 T C P原则（见第2 0 . 3节）。这就是为什么必须通告一个5 0 9字节的窗口的原因。
接下来我们看到发送方没有立即向这个小窗口发送数据。这就是发送方采取的糊涂窗口避免策略。相反，它等待另一个坚持定时器在时刻 2 0 . 1 5 1到时间，并在该时刻发送 5 0 9字节的数据。尽管它最终还是发送了一个长度为 5 0 9字节的小数据段，但在发送前它等待了 5秒钟，看是否会有一个A C K到达，以便可以将窗口开得更大。这 5 0 9字节的数据使得接收缓存仅剩下7 6 8字节的有效空间，因此接收方通告窗口为 0（报文段1 5）。
坚持定时器在时刻2 5 . 1 5 1再次到时间，发送方发送 1个字节，于是接收缓存中有 1 2 7 9字节的可用空间，这就是在报文段 1 7所通告的窗口大小。
发送方只有另外的5 11个字节的数据需要发送，因此在收到 1 2 7 9的窗口通告后立刻发送了这些数据（报文段 1 8）。这个报文段也带有 F I N标志。接收方确认数据和 F I N，并通告窗口大小为7 6 7（见习题2 2 . 2）。
由于发送应用进程在执行完 6个1 0 2 4字节的写操作后发出关闭命令，发送方的连接从E S TA B L I S H E D状态转变到F I N _ WA I T _ 1状态，再到F I N _ WA I T _ 2状态（见图1 8 - 1 2）。它一直处于这个状态，直到收到对方的 F I N。在这个状态上没有设置定时器（回忆我们在 1 8 . 6节结束时的讨论），因为它在报文段 1 8中发送的F I N被报文段1 9确认。这就是为什么我们看到发送方直到接收到F I N（报文段2 1）为止没有发送其他任何数据的原因。
接收应用进程继续每隔 2秒从接收缓存区中读取 2 5 6个字节的数据。为什么在时刻 3 9 . 9 9发 送A C K（报文段2 0）呢？这是因为应用进程在时刻 3 9 . 9 9读取数据时，接收缓存中的可用空间已经从原来通告的7 6 7（报文段1 9）变为2 8 1 6，这相当于接收缓存中增加了额外的 2 0 4 9字节的空间。回忆本节开始讲的第 1个规则，因为现在接收缓存已经增加了其空间的一半，因此接收 方现在发送窗口更新。这意味着每次当应用进程从 T C P的接收缓存中读取数据时，接收的 T C P将检查是否需要更新发送窗口。
应用进程在时间5 1 . 9 9发出最后一个读操作，然后收到一个文件结束标志，因为缓存已经变空。这就导致了最后两个完成连接终止的报文段（报文段 2 1和2 2）的发送。