【糊涂窗口综合征产生的条件】
当发送应用程序产生数据很慢，或接受应用程序读取数据很慢，或两者都有。
【发送端产生的症状】
发送数据的报文段很小，引起操作效率的降低。
例：若TCP发送的报文段只包括一个字节的数据，但是要发送41字节的数据报（20个字节TCP首部和20字节的IP首部）才传送1字节的数据。数据的传送效率是1/41,表示在非常低效率地使用网络的容量。
【解决方法】
防止发送端的TCP逐个字节地发送数据。必须强迫发送端的TCP收集数据，然后用一个更大的数据块来发送。
发送端的TCP的等待时间影响很大，如果等待时间过长，就会使整个过程产生较长的实验。如果等待时间不够长，就可能发送较小的报文段。
【Nagle算法】用于发送端的TCP
（1）发送端的TCP将它从发送应用程序收到的第一块数据发送出去，哪怕只有一个字节
（2）在发送第一个报文段以后，发送端的TCP就在输出缓存中累积数据并等待；或者接受端的TCP发送一个确认，或者数据已累计到可以装成一个最大的报文段，在这个时候，发送端的TCP就可以发送这个报文段
（3）重复（2）
优点：考虑到应用程序产生数据的速率，以及网络运输数据的速率。若应用程序比网络快，则报文段就更大（最大报文段）。若应用程序比网络慢，则报文段就比较小（小于最大报文段）
【接受端产生的症状】
如果接受端为消耗数据很慢的应用程序访问，比如一次只消耗一个字节。假定发送应用程序产生了1000字节的数据块，但接收应用程序每次只读取1字节的数据。如果发送端的发送的数率比较快，接受端的TCP输入缓存会满。接受端 的TCP就通知窗口大小为0，表示发送端必须停止发送数据。
接受应用程序从接收端的TCP输入缓存读取一个字节的数据，输入缓存就有了1字节的空间。接受端的TCP宣布窗口大小为1字节，发送端的TCP会只发一个字节数据的报文段。这样的过程一直继续下去。一个字节的数据被消耗掉，然后再发送只包含一个字节数据的报文段。
对于应用程序消耗数据比到达的慢产生的糊涂窗口综合征，有两种建议解决方法：
Clark解决方法：
只要有数据到达就发送确认，但宣布的窗口大小为0，直到或者缓存空间已能放入具有最大长度的报文段，或者缓存空间的一半已经空了。
延迟的确认：
一个报文段到达时并不立即发送确认。接受端在确认收到报文段之前一直等待，直到缓存有足够的空间为止。
延迟的确认
（1）防止了发送端的TCP滑动其窗口，当发送端的TCP发送完数据后，它就停下来了。
（2）减少了通信量。接受端不需要确认每一个报文段。
但是，延迟的确认可能迫使发送端重传其未被确认的报文段。
可以用协议来平衡这个优点和缺点，比如，定义确认的延迟不能超过500毫秒。
