TCP滑動視窗

2021-07-15 16:50:55 字數 1690 閱讀 9845

假設a和b之間新建立了一條tcp連線。裝置a需要傳送一長串資料流,但裝置b無法一次全部接收,所以它限制裝置a每次傳送分段指定數量的位元組數,直到分段中已傳送的位元組數得到確認。之後,裝置a可以繼續傳送更多位元組。每乙個裝置都對傳送,接收及確認資料進行追蹤。

tcpbuffer中資料可以分為以下四類

1.已傳送已確認 資料流中最早的位元組已經傳送並得到確認。這些資料是站在傳送裝置的角度來看的。如下圖所示,31個位元組已經傳送並確認。

2. 已傳送但尚未確認 已傳送但尚未得到確認的位元組。傳送方在確認之前,不認為這些資料已經被處理。下圖所示14位元組為第2類。

3. 未傳送而接收方已ready 裝置尚未將資料發出,但接收方根據最近一次關於傳送方一次要傳送多少位元組確認自己有足夠空間。傳送方會立即嘗試傳送。如圖,第3類有6位元組。

4. 未傳送而接收方not ready 由於接收方not ready,還不允許將這部分資料發出。

傳送方和接收方必須就它們將要為資料流中的位元組指定的sequence number達成一致。這一過程稱為同步,在tcp連線建立時完成。為了簡化假設第乙個位元組sequence number是1

傳送視窗與可用視窗

傳送視窗:接收方允許傳送方一次能容納的未確認的位元組數

可用視窗:考慮到正在傳輸的資料量,傳送方仍被允許傳送的資料量。實際上等於第3類的大小。

確認處理

當以傳送但尚未確認得位元組收到確認之後,這時根據視窗大小向右移動,從而第二類被移動到了第一類。

當伺服器從客戶端接收資料,它就將資料放在快取中,伺服器必須對資料做以下兩步操作:

確認:伺服器必須將確認資訊發回客戶端以表明資料接收。

傳輸:伺服器必須處理資料,將它傳遞給目標應用程式處理。

區分開這兩件事情是非常重要的。關鍵在於基本的滑動視窗機制中,資料於接收時確認,但並不一定立即從快取中傳輸出去。也就意味著當接收資料速度快於接收tcp處理速度時,快取有可能被填滿。當這一情況發生時,接收裝置需要調整視窗大小已防止快取過載。

通過增加或縮小視窗大小,伺服器和客戶端能夠確保對端傳送資料的速度等同於處理速度。

減小視窗大小以降低傳送速率:

假設客戶端傳輸140位元組資料給伺服器且客戶端的傳送視窗為360位元組。

一段時間後,伺服器接收到140位元組,並把它們放入快取中,確認之後從快取移除。這種情況伺服器處理的速度與資料進入速度相同,視窗大小儲存在360位元組。將360位元組視窗向右移動140位元組。由於現在未確認位元組數為0,因此客戶端又可以傳送360位元組資料。

假設我們接收到140位元組,但只能傳送40位元組給應用程式,快取中剩下100位元組。當傳送140位元組的確認資訊,伺服器將傳送視窗縮小100位元組,至260位元組。當客戶端從伺服器接收到這一片段,它將會看到140位元組的確認資訊並將視窗向右滑動140位元組。在滑動過程中,將大小縮減至260位元組。可以認為將視窗左端滑動140位元組,但右端僅滑動40位元組。新的稍小一些的視窗保證伺服器從客戶端接收最多260位元組資料,以適應接收快取中的剩餘空間。

縮減傳送視窗以停止傳送新資料

如果伺服器無法接收任何新資料會怎麼樣呢?假設客戶端下一次傳輸180位元組,但是伺服器太忙碌而無法對其進行處理。這種情況下,伺服器將這180位元組快取下來,並且在確認資訊中,將視窗大小從260位元組縮減為80位元組。當客戶端接收到180位元組的確認資訊,它也會看到視窗縮減了180位元組,它會滑動與縮減同樣的大小,告知伺服器:我確認接收180位元組資料,但不允許你再傳送新的資料。也可以看作視窗左端滑動180位元組,但右端維持不動。只要右端不移動,客戶端就無法傳送更多資料。

TCP滑動視窗

目前建立在tcp協議上的網路協議特別多,有telnet,ssh,有ftp,有http等等。這些協議又可以根據資料吞吐量來大致分成兩大類 1 互動資料型別,例如telet,ssh,這種型別的協議在大多數情況下只是做小流量的資料交換,比如說按一下鍵盤,回顯一些文字等等。2 資料成塊型別,例如ftp,這種...

TCP滑動視窗

tcp滑動視窗是用來控制流量的,避免擁塞的發生。滑動視窗又包括接收端滑動視窗和傳送端滑動視窗,下面我們簡單分析一下。上圖顯示的是接收緩衝區,其中接收視窗也在其中。接收視窗的大小是8,即4 12,此時由a可知,接收端下乙個預計接收序列號4,當接收端接收到4 7之後,滑動視窗就會右移,此時接收端預計接收...

TCP 滑動視窗

push 慢啟動 隔乙個報文段確認 的策略實際就是因為 delayed ack,同時接收到兩個待確認的ack包時,就立即傳送確認包。滑動視窗例項 解決了快的傳送方 慢的接收方 隨後從接收方傳來另外兩個 ack,它們確認了最後的 4096位元組的資料 從4097到8192位元組 和fin 標號為819...