當傳送端應用程序產生資料很慢、或接收端應用程序處理接收緩衝區資料很慢，或二者兼而有之；就會使應用程序間傳送的報文段很小，特別是有效載荷很小。 極端情況下，有效載荷可能只有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毫秒。
糊塗視窗綜合症
當傳送端應用程序產生資料很慢 或接收端應用程序處理接收緩衝區資料很慢，或二者兼而有之 就會使應用程序間傳送的報文段很小，特別是有效載荷很小。極端情況下，有效載荷可能只有1個位元組 而傳輸開銷有40位元組 20位元組的ip頭 20位元組的tcp頭 這種現象就叫糊塗視窗綜合症 如果傳送端為產生資料很慢的...
糊塗視窗綜合症
當傳送端應用程序產生資料很慢 或接收端應用程序處理接收緩衝區資料很慢，或二者兼而有之 就會使應用程序間傳送的報文段很小，特別是有效載荷很小。極端情況下，有效載荷可能只有1個位元組 而傳輸開銷有40位元組 20位元組的ip頭 20位元組的tcp頭 這種現象就叫糊塗視窗綜合症 如果傳送端為產生資料很慢的...
糊塗視窗綜合症
糊塗視窗綜合症 摘自tcpip協議詳解.卷1 基於視窗的流量控制方案，如t c p所使用的，會導致一種被稱為 糊塗視窗綜合症s w s silly window syndrome 的狀況。如果發生這種情況，則少量的資料將通過連線進行交換，而不是滿長度的報文段 clark 1982 該現象可發生在兩端...