转自：https://blog.csdn.net/vincent_yuan89/article/details/9492517
定义说明
（摘自TCPIP协议详解.卷1）
基于窗口的流量控制方案，如T C P所使用的，会导致一种被称为“糊涂窗口综合症S W S(Silly Window Syndrome）”的状况。如果发生这种情况，则少量的数据将通过连接进行交换，而不是满长度的报文段[Clark 1982]。
该现象可发生在两端中的任何一端：接收方可以通告一个小的窗口（而不是一直等到有大的窗口时才通告），而发送方也可以发送少量的数据（而不是等待其他的数据以便发送一个大的报文段）。可以在任何一端采取措施避免出现糊涂窗口综合症的现象。
1) 接收方不通告小窗口。通常的算法是接收方不通告一个比当前窗口大的窗口（可以为0），除非窗口可以增加一个报文段大小（也就是将要接收的M S S）或者可以增加接收方缓存空间的一半，不论实际有多少。
2) 发送方避免出现糊涂窗口综合症的措施是只有以下条件之一满足时才发送数据：( 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 )要求发送方始终监视另一方通告的最大窗口大小，这是一种发送方猜测对方接收缓存大小的企图。虽然在连接建立时接收缓存的大小可能会减小，但在实际中这种情况很少见。
什么是糊涂窗口综合症
当发送端应用进程产生数据很慢、或接收端应用进程处理接收缓冲区数据很慢，或二者兼而有之；就会使应用进程间传送的报文段很小，特别是有效载荷很小。 极端情况下，有效载荷可能只有1个字节；而传输开销有40字节(20字节的IP头+20字节的TCP头) 这种现象就叫糊涂窗口综合症
发送端引起的糊涂窗口综合症
如果发送端为产生数据很慢的应用程序服务(典型的有telnet应用)，例如，一次产生一个字节。这个应用程序一次将一个字节的数据写入发送端的TCP的缓存。如果发送端的TCP没有特定的指令，它就产生只包括一个字节数据的报文段。结果有很多41字节的IP数据报就在互连网中传来传去。
解决的方法是防止发送端的TCP逐个字节地发送数据。必须强迫发送端的TCP收集数据，然后用一个更大的数据块来发送。发送端的TCP要等待多长时间呢？如果它等待过长，它就会使整个的过程产生较长的时延。如果它的等待时间不够长，它就可能发送较小的报文段。Nagle找到了一个很好的解决方法，发明了Nagle算法。
接收端引起的糊涂窗口综合症
接收端的TCP可能产生糊涂窗口综合症，如果它为消耗数据很慢的应用程序服务，例如，一次消耗一个字节。假定发送应用程序产生了1000字节的数据块，但接收应用程序每次只吸收1字节的数据。再假定接收端的TCP的输入缓存为4000字节。发送端先发送第一个4000字节的数据。接收端将它存储在其缓存中。现在缓存满了。它通知窗口大小为零，这表示发送端必须停止发送数据。接收应用程序从接收端的TCP的输入缓存中读取第一个字节的数据。在入缓存中现在有了1字节的空间。接收端的TCP宣布其窗口大小为1字节，这表示正渴望等待发送数据的发送端的TCP会把这个宣布当作一个好消息，并发送只包括一个字节数据的报文段。这样的过程一直继续下去。一个字节的数据被消耗掉，然后发送只包含一个字节数据的报文段。
对于这种糊涂窗口综合症，即应用程序消耗数据比到达的慢，有两种建议的解决方法。
1 Clark解决方法 Clark解决方法是只要有数据到达就发送确认，但宣布的窗口大小为零，直到或者缓存空间已能放入具有最大长度的报文段，或者缓存空间的一半已经空了。
2 延迟确认 第二个解决方法是延迟一段时间后再发送确认。这表示当一个报文段到达时并不立即发送确认。接收端在确认收到的报文段之前一直等待，直到入缓存有足够的空间为止。延迟的确认防止了发送端的TCP滑动其窗口。当发送端的TCP发送完其数据后，它就停下来了。这样就防止了这种症状。
迟延的确认还有另一个优点：它减少了通信量。接收端不需要确认每一个报文段。但它也有一个缺点，就是迟延的确认有可能迫使发送端重传其未被确认的报文段。
可以用协议来平衡这个优点和缺点，例如现在定义了确认的延迟不能超过500毫秒