38-tcp协议——由接收方引发的糊涂窗口

  不知道大家是否还有印象没，前面我们讲过糊涂窗口综合征是有可能产生于发送方或接收方中的任何一方，这是因为tcp是采用的全双工通信方式的，数据可以在任一方向上流动。

  对于由发送方引起的糊涂窗口综合征的解决办法，即nagle算法，已经介绍过了。那么由接收方引发的糊涂窗口综合征，又该怎么解决呢？有小伙伴可能会说nagle算法，但是nagle算法主要是针对发送方的，调整发送方发送数据的速率，好像并不能直接调整接收方应用进程读取数据的速率。

  我们先来看一下接收方是怎么引起糊涂窗口综合征的，这里我们先假设接收方的应用进程读取数据的速率很慢，每次只读1字节数据，具体过程如下：

图1-由接收方引起的SWS

  如图1所示，发送方缓存中有8192字节数据，而接收方缓存空间只有4096大小，发送方第一次就发送了4096字节数据，接收方接收到数据后，把数据暂时存储到缓存中，等待接收应用进程读取数据，但此时缓存空间已经被占满了，这时接收方会发送一个rwnd = 0 ，即窗口为0的通告。这意味着发送方必须暂时停止发送数据了。

  现在接收方应用进程从缓存中读取1字节数据，此时缓存空间腾出了1字节数据的空间出来，于是接收方就发送了一个rwnd = 1的通告，表示发送方可以发送数据了。此时发送方接收到后，发现对方只能接收1字节数据，于是发送方就只能发送1字节数据了（虽然发送方可以发送4096字节数据，但是被接收方限制了发送数据的大小，如果开启nagle算法，是可以避免发送方发送1字节的数据，同时接收方的应用进程也能多读取一点数据，但这并不能直接解决接收方应用进程处理数据很慢的问题），接收方接收到数据后，存储到缓存中，等待数据被读走，如果应用进程还是每次只读走1字节数据，那么将会一直持续这种情况。

  需要注意的是，此时糊涂窗口综合征是由于接收方而引起的，原因在于接收方应用进程读取数据的速率太慢。对于这种情况，有以下两种解决办法：
  1. Clark解决办法，就是在接收方缓存有一半空余的空间前提下，如果有数据发送过来就回复确认，如果接收方缓存中空余的空间不足一半，则一直发送rwnd = 0（即窗口为0）通告发送方，也就是不让发送方发送数据了。

  2. 推迟确认，也就是当接收方收到数据时不会立即发送确认，而是等待接收方的缓存有足够空间会发送确认。在接收方等待的同时，发送方也暂时停止了发送数据。

对于推迟确认这种方式也是有优缺点的：
  优点在于，在于它减少了通信量，即接收方不需要对每个报文进行确认。

  但缺点也很明显，如果接收方把确认时间推迟过长的话，可能会让发送方误认为报文丢失，而进行超时重传，而这种不必要的重传浪费了网络带宽。另外，tcp还使用了确认报文到达的时间来测量往返时间（RTT），推迟确认可能会干扰往返时间（RTT）的测量，导致重传时间变得过长。为了避免这几种情况，tcp规定了确认被推迟的时间最多不能超过500ms。