什麼是糊塗窗口綜合症
當發送端應用進程產生數據很慢、或接收端應用進程處理接收緩衝區數據很慢，或二者兼而有之；就會使應用進程間傳送的報文段很小，特別是有效載荷很小。 極端情況下，有效載荷可能只有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毫秒。