糊塗視窗綜合症

2021-06-05 11:34:17 字數 1308 閱讀 5531

當傳送端應用程序產生資料很慢、或接收端應用程序處理接收緩衝區資料很慢,或二者兼而有之;就會使應用程序間傳送的報文段很小,特別是有效載荷很小。 極端情況下,有效載荷可能只有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頭 這種現象就叫糊塗視窗綜合症 如果傳送端為產生資料很慢的...

糊塗視窗綜合症

糊塗視窗綜合症 摘自tcpip協議詳解.卷1 基於視窗的流量控制方案,如t c p所使用的,會導致一種被稱為 糊塗視窗綜合症s w s silly window syndrome 的狀況。如果發生這種情況,則少量的資料將通過連線進行交換,而不是滿長度的報文段 clark 1982 該現象可發生在兩端...

糊塗視窗綜合症

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