糊塗視窗綜合徵

糊塗視窗綜合症是指當傳送端套用進程產生數據很慢、或接收端套用進程處理接收緩衝區數據很慢，或二者兼而有之；就會使套用進程間傳送的報文段很小，特別是有效載荷很小； 極端情況下，有效載荷可能只有1個位元組；傳輸開銷有40位元組(20位元組的IP頭+20位元組的TCP頭) 這種現象。

基本介紹

• 中文名：糊塗視窗綜合徵
• 起因：傳送端和接送端
• 解決辦法：Clark和延遲確認

傳送端引起

如果傳送端為產生數據很慢的應用程式服務(典型的有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毫秒。