網絡基本功（十一）：TCP窗口調整與流控

網絡基本功（十一）：TCP窗口調整與流控

 

轉載請在文首保留原文出處：EMC中文支持論壇https://community.emc.com/go/chinese 

 

介紹

 

前文已經介紹過了TCP滑動窗口大小的重要性。在客戶端與服務器的鏈接中，客戶端告知服務器它一次但願從服務器接收多少字節數據，這是客戶端的接收窗口，即服務器的發送窗口。相似地，服務器告知客戶端一次但願從客戶端接收多少字節數據，也就是服務器的接收窗口和客戶端的發送窗口。

要理解爲何窗口大小會產生波動，首先須要理解它的含義。最簡單的方式是它表明了設備對於特定鏈接的接收緩存大小。即，窗口大小表明一個設備一次可以從對端處理多少數據，以後再傳遞給應用層處理。

更多信息

 

當服務器從客戶端接收數據，它就將數據放在緩存中，服務器必須對數據作如下兩步操做：

確認：服務器必須將確認信息發回客戶端以代表數據接收。

傳輸：服務器必須處理數據，將它傳遞給目標應用程序處理。

區分開這兩件事情是很是重要的。關鍵在於基本的滑動窗口機制中，數據於接收時確認，但並不必定當即從緩存中傳輸出去。也就意味着當接收數據速度快於接收TCP處理速度時，緩存有可能被填滿。當這一狀況發生時，接收設備須要調整窗口大小已防止緩存過載。

因爲窗口大小可以以這種方式管理鏈接兩端設備數據流的速率，TCP就是以這種方式實現流控這一傳輸層很是典型的任務。流控對於TCP來講是很重要的，由於它是設備間互通狀態的方式。經過增長或縮小窗口大小，服務器和客戶端可以確保對端發送數據的速度等同於處理速度。

 

減少窗口大小以下降發送速率：

 

首先看一下客戶端到服務器的數據傳輸，以下圖所示。

客戶端傳輸140字節數據至服務器。以後，客戶端的可用窗口還剩下220字節：發送窗口的360字節減去發送的140字節。

一段時間事後，服務器接收到140字節並將它們放在緩存中。如今，理想的狀況下，140字節進入緩存，確認以後馬上從緩存移出。也就是說，緩存有足夠的大小來容納客戶端發送的全部數據。緩存的空閒空間維持在360字節，所以告知客戶端窗口大小保持不變。

只要服務器處理速度和數據進入速度相同，窗口大小就會保持在360字節。客戶端在接收到140字節的確認信息以及窗口大小保持不變的信息以後，將360字節窗口向右移動140字節。因爲如今未確認字節數爲0，所以客戶端又能夠發送360字節數據。對應於以前可用窗口的220字節，加上剛剛確認的140字節數據。

然而，現實中服務器可能須要處理數十，數百乃至數千個TCP鏈接。TCP可能沒法馬上處理數據，或應用應用程序自己沒法接收140字節數據。任何一種狀況下，服務器TCP都沒法馬上將140字節從緩存中移出。這時，除了發回確認信息給客戶端之外，服務器會想要告知客戶端更改窗口大小，以表示緩存已經被部分寫入了。

假設咱們接收到140字節，但只能發送40字節給應用程序，緩存中剩下100字節。當發送140字節的確認信息，服務器將發送窗口縮小100字節，至260字節。當客戶端從服務器接收到這一片斷，它將會看到140字節的確認信息並將窗口向右滑動140字節。在滑動過程當中，將大小縮減至260字節。能夠認爲將窗口左端滑動140字節，但右端僅滑動40字節。新的稍小一些的窗口保證服務器從客戶端接收最多260字節數據，以適應接收緩存中的剩餘空間，以下圖的1-3步所示。

 

縮減發送窗口以中止發送新數據：

 

若是服務器沒法接收任何新數據會怎麼樣呢？假設客戶端下一次傳輸180字節，可是服務器太忙碌而沒法對其進行處理。這種狀況下，服務器將這180字節緩存下來，而且在確認信息中，將窗口大小從260字節縮減爲80字節。當客戶端接收到180字節的確認信息，它也會看到窗口縮減了180字節，它會滑動與縮減一樣的大小，告知服務器：我確認接收180字節數據，但不容許你再發送新的數據。也能夠看做窗口左端滑動180字節，但右端維持不動。只要右端不移動，客戶端就沒法發送更多數據。這一過程顯示在上圖的4-6中。

 

關閉發送窗口：

 

窗口調整能夠經過雙方設備來完成。若是服務器從客戶端接收的數據持續快於推送給應用的速率，則服務器將會繼續減少接收窗口。假設發送窗口減少至80字節，客戶端發送第三個請求，長度爲80字節，但服務器仍處於繁忙狀態。以後服務器將窗口減少爲0，也稱爲關閉窗口。這一信息告知客戶端服務器已通過載，它須要完全中止發送數據，如上圖最後一步所示。以後，當服務器負載減輕時，能夠再次增長這一鏈接的窗口，容許更多數據傳輸。