糊塗窗口綜合症
![本頁使用了標題或全文手工轉換](http://upload.wikimedia.org/wikipedia/commons/thumb/c/cd/Zh_conversion_icon_m.svg/35px-Zh_conversion_icon_m.svg.png)
![]() | 此條目翻譯自其他語言維基百科,需要相關領域的編者協助校對翻譯。 |
![]() | 此條目需要精通或熟悉相關主題的編者參與及協助編輯。 |
糊塗窗口綜合症(Silly window syndrome),亦稱愚蠢窗口綜合症、愚笨窗口綜合症,是TCP流量控制實現不良導致的一種電腦網絡問題。當傳送程式緩慢地生產數據,接收程式緩慢地消耗數據,或者兩者同時存在時,滑動窗口運作會出現嚴重問題。如果一個伺服器無法處理所有傳入的數據而存在此問題,它會要求客戶端減少一次傳送的數據量(TCP網絡封包的滑動窗口)。如果伺服器仍然無法處理所有傳入的數據,窗口會隨此問題越來越小,有時甚至將使傳輸數據小於封包頭,使數據傳輸變得極為低效。這個問題的名字取自窗口縮小到「愚蠢」的值。當該綜合症發生時,連接上交換的數據段是小數據段而不是全尺寸的數據段[1]。
基於窗口的流量控制網絡協定,特別是使用非固定段大小的(例如TCP),都有可能陷入糊塗窗口綜合症[2]。
處理每個封包都存在一定量的開銷,封包數增加會增加網絡通訊的開銷,可能使數據處理量進一步減少。最終的結果就是抖動。
描述
[編輯]SWS 可能由 TCP 連接的任何一方引起:接收方應該等到可以發較大窗口通告再發窗口通告,但是沒有等而發了小窗口公告;傳送方應該等到數據夠多的時候一次性傳送一個較大的段,但是沒有等而發了較小的段[2]。
解決方案
[編輯]當傳送者與接收者之間沒有就數據流量或封包大小的容量同步時,則會發生窗口綜合症問題。如果糊塗窗口綜合症是由傳送方產生,則納格演算法發揮作用。 納格的解決方案要求傳送方傳送第一個段,即使它是小的,然後就等待直至收到一個ACK,或者累積到最大大小段(MSS)。如果糊塗窗口綜合症由接收方產生,則David D Clark演算法發揮作用。Clark的解決方案是關閉窗口,直到接收到最大段大小(MSS)的另一個段,或者緩衝區為半空。
糊塗窗口綜合症的成因有三種:
- 當伺服器宣佈空閒空間為0
- 當客戶端每次只能生成1個位元組
- 當伺服器一次只能消耗1個位元組
在糊塗窗口綜合症期間,通訊效率幾乎為零,因此該問題的持續時間應儘可能短。
TCP 的實現要滿足以下規則[2]:
- 接收方 TCP 不能通告小窗口。RFC 1122中定義的接收演算法是不通告比當前正被通告的窗口大的段(可以是0),直到窗口可以增加一個全尺寸段(即接收MSS)或者增加接收方緩衝區的一半大,以較小者為準。在兩種情況下,該規則可以發揮作用: 當緩衝區中的部分數據已被應用程式消費而緩衝區可用時,以及當TCP必須響應窗口探測時。
- 傳送方 TCP 不能傳送過小的段,納格演算法發揮作用。傳送方只有以下情況才能傳送段
- 待傳送的數據為一個全尺寸的段。
- TCP 可以傳送大小至少為另一端在此連接上通告的最大窗口大小的一半。
- 納格演算法啟動的情況下,TCP 在沒有急需 ACK 的數據的情況下,TCP 可以傳送任何它必須立即傳送的數據。
其中 2.1 是最直截了當的,直接避免了段的開銷過高的問題。2.2 避免主機總是通告過小的窗口。2.3 避免 TCP 在有急需 ACK 的數據的情況下還傳送比較小的段。如果傳送方應用程式一直在往連接寫入大小很小的數據,2.3 可以避免糊塗窗口。2.2 要求傳送方記錄接收方通告的最大窗口。
納格演算法禁止我們在有急需ACK數據的情況下傳送過小的段,那麼納格演算法中的小指的是多小呢?2.1 說明大小不能小於SMSS(接收方的MSS或者不超過PMTU的最大包大小)[2]。
傳送端糊塗窗口避免
[編輯]一種傳送TCP的啟發法方法是必須允許傳送程式執行「寫」呼叫,並在傳送大段之前收集每個呼叫傳送的數據。傳送TCP將延遲傳送段,直到它累積起合理數量的數據。這被稱為聚集(clumping)。
接收端糊塗窗口避免
[編輯]一種接收端的啟發式方法是維護可用窗口的內部記錄,並且延遲向傳送方宣告增加窗口大小,直到可以推進顯着的量。該數量取決於接收端的緩衝器大小和最大段大小。通過此方法可以防止接收端程式緩慢提取八位元組數據時宣告小窗口。
參考資料
[編輯]- Comer, Douglas E. Internetworking with TCP/IP 5. Prentice Hall: Upper Saddle River, NJ. 2006.
- Postel, J. NCP/TCP Transition Plan. 1981 [5 October 2016]. (原始內容存檔於2016-06-10).
Some TCP implementations did not protect against silly window syndrome.
- ^ Clark, D. D. Window and Acknowledgement Strategy in TCP. tools.ietf.org. [2020-02-27]. (原始內容存檔於2019-03-27) (英語).
- ^ 2.0 2.1 2.2 2.3 Fall; Kevin R. TCP/IP illustrated.—2nd ed. the United States of America: Pearson Education, Inc. 2012: 708. ISBN 0-321-33631-3.