文章目錄

• 概述
• 滑動視窗引入
• 固定視窗
• 滑動視窗
• 滑動視窗原理

概述

從網路傳輸資料來講，TCP、UDP以及其他協議都可以完成資料的傳輸，而TCP協議與其他協議不同的一點就是提供了一個可靠的，流量控制的資料傳輸方案。

• 可靠性 : TCP協議的保證資料能夠準確到達目的地，通過確認機制來實現。若未收到確認碼，超過超時時間之後則重新發送資料。
• 流量控制 : 資料傳送過程中，通過滑動視窗機制，保證流量傳輸不超過裝置的負載能力。

滑動視窗引入

TCP協議包括兩種視窗機制，分別為固定視窗和滑動視窗。

固定視窗

TCP協議是可靠協議，通過確認機制實現資料的可靠傳輸。即傳送方在傳送完資料之後啟動定時器，然後等待確認包的到來，若超過一定時間未收到確認包，則重新發送該資料。這種情況下，如果某個資料包多次傳輸失敗，則會直接影響後續資料包的傳送，非常影響傳輸效率。固定視窗傳送示意圖如下:

滑動視窗

滑動視窗的最大優勢為不需要對每個資料包進行確認，而是可以進行累積確認。
滑動視窗的幾個原則如下:

1. 對傳送資料做分段處理，並對每個段編號。
2. 滑動視窗的大小是動態變化的，每次由接收端連同確認碼一併返回。
3. 接收端對接收到的連續資料進行確認，若出現亂序傳輸，則將先到達的編號較大的資料快取，並等待資料到達。

由於TCP協議屬於全雙工協議，所以兩個端都包含傳送視窗和接收視窗。

滑動視窗的傳送方結構如下:

1. 傳送且已確認視窗 : 這個視窗內的資料表示已經發送成功並已經被確認的資料。
2. 傳送但未確認視窗 : 這個視窗內的資料表示已經發送成功但並沒有被確認的資料。
3. 未傳送但允許傳送的視窗 : 這個視窗內的資料表示尚未傳送但是允許被髮送的資料。
4. 不允許傳送視窗 : 這個視窗內的資料屬於接收端不允許傳送的資料，因為這些資料已經超出了傳送端所接收的範圍。
   傳送視窗簡易結構如下圖:
   

滑動視窗的接收方結構如下:

1. 接收但未處理視窗 : 這個視窗內資料屬於接收了但是還沒有被上層的應用程式處理，被快取在視窗內。
2. 接收但未確認視窗 : 這個視窗內資料屬於接收了但是還沒有來得及確認的資料。
3. 有空位但還未接收資料視窗 : 表示可以接收資料，但是資料尚未傳送過來的視窗。

滑動視窗原理

滑動視窗並不會對每一個報文段都回復確認碼ACK，而是對一個或多個報文段傳送一個確認碼。例如傳送方有1，2，3這3個報文段，首先一次傳送了1，2，3三個報文段，但是接收方提前接收到了2，3報文段，而1報文段還沒有到達，這時2，3報文段只能快取起來並等待1報文段的到來。如果1報文段一直不來，則2，3報文段將被丟棄；如果1報文段及時趕來，則傳送一個確認碼對1，2，3這3個報文段進行一次確認。
例子如下:

1. 假設有33-39這些資料待發送，TCP協議將它們分成四個報文段分別為seg1 33-34，seg2 35-36，seg3 37，seg4 38-39這四個段，並依次發給接收端。
2. 假設接收端之接收到了seg1，seg2，seg4。則此時接收端回覆一個ACK表示33-36已經成功接收，由於seg3尚未到達，所以將seg4快取起來。
3. 傳送端接收到ACK後將33-36這部分資料從“傳送但未確認視窗”移到“傳送且已確認視窗”，即將“傳送但未確認視窗”的左邊界右移4個單位。
4. 假設接收端傳送給視窗大小不變，則“傳送但未確認視窗”的右邊界繼續向右移動4個單位，只要不越進“不允許傳送視窗”即可。
5. 對於seg3，若一段時間後，接收端接收到了seg3，則傳送確認碼錶示seg3和seg4接收成功。若沒有收到seg3，則丟棄seg4。對應的，如果傳送端一段時間沒有接收到seg3的確認碼，則重傳seg3。