糊塗視窗綜合症
（摘自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毫秒。
糊塗視窗綜合症
當傳送端應用程序產生資料很慢 或接收端應用程序處理接收緩衝區資料很慢，或二者兼而有之 就會使應用程序間傳送的報文段很小，特別是有效載荷很小。極端情況下，有效載荷可能只有1個位元組 而傳輸開銷有40位元組 20位元組的ip頭 20位元組的tcp頭 這種現象就叫糊塗視窗綜合症 如果傳送端為產生資料很慢的...
糊塗視窗綜合症
當傳送端應用程序產生資料很慢 或接收端應用程序處理接收緩衝區資料很慢，或二者兼而有之 就會使應用程序間傳送的報文段很小，特別是有效載荷很小。極端情況下，有效載荷可能只有1個位元組 而傳輸開銷有40位元組 20位元組的ip頭 20位元組的tcp頭 這種現象就叫糊塗視窗綜合症 如果傳送端為產生資料很慢的...
糊塗視窗綜合症
當傳送端應用程序產生資料很慢 或接收端應用程序處理接收緩衝區資料很慢，或二者兼而有之 就會使應用程序間傳送的報文段很小，特別是有效載荷很小。極端情況下，有效載荷可能只有1個位元組 而傳輸開銷有40位元組 20位元組的ip頭 20位元組的tcp頭 這種現象就叫糊塗視窗綜合症 如果傳送端為產生資料很慢的...