TCP之滑動窗口協議(動畫演示)

裝載！！！！！！！至

1. CSDN博主的《解析TCP之滑動窗口(動畫演示)》，網址：https://blog.csdn.net/yao5hed/article/details/81046945?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-3&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-3
2. CSDN博主的《TCP-IP詳解：滑動窗口（Sliding Window）》，網址：https://blog.csdn.net/wdscq1234/article/details/52444277

該文章只是對兩個文章的內容的總結，主體內容來自這兩個部分。

b站上有一個視頻比較nice的可視化了滑動窗口的機制。

來自於up主 今天單詞背了嗎O_o 的tcp滑動窗口的完美解釋，網址：https://www.bilibili.com/video/BV1FE411C7dk?from=search&seid=6007213953266071805

---

---

1. TCP背景介紹

從傳輸數據來講，TCP/UDP以及其他協議都可以完成數據的傳輸，從一端傳輸到另外一端，TCP比較出衆的一點就是提供一個可靠的，流量控制的數據傳輸，所以實現起來要比其他協議複雜的多，先來看下這兩個修飾詞的意義：

1. Reliability ，提供TCP的可靠性 ，TCP的傳輸要保證數據能夠準確到達目的地，如果不能，需要能檢測出來並且重新發送數據。
2. Data Flow Control ，提供TCP的流量控制 特性，管理髮送數據的速率，不要超過設備的承載能力。
   爲了能夠實現以上2點，TCP實現了很多細節的功能來保證數據傳輸 ，比如說 滑動窗口適應機制 ，超時重傳機制，累計ACK等，這次先介紹一下滑動窗口的一些知識點 。

2. 滑動窗口引入

IP層協議屬於不可靠的協議，IP層並不關心數據是否發送到了對端 ，TCP通過確認機制來保證數據傳輸的可靠性 ，在比較早的時候使用的是send–wait–send 的模式，其實這種模式叫做stop-wait模式 ，發送數據方在發送數據之後會啓動定時器，但是如果數據或者ACK丟失，那麼定時器到期之後，收不到ACK就認爲發送出現狀況，要進行重傳 。這樣就會降低了通信的效率，如下圖所示，這種方式被稱爲 positive acknowledgment with retransmission (PAR)

滑動窗口機制可以優化一下PAR效率低的缺點 ，比如我讓發送的每一個包都有一個id，接收端必須對每一個包進行確認，這樣設備A一次多發送幾個片段，而不必等候ACK，同時接收端也要告知它能夠收多少，這樣發送端發起來也有個限制。當然還需要保證數據發送的順序性，儘量不要亂序。可以允許一段時間內的亂序情況，比如說先緩存提前到的數據，然後去等待需要的數據，但是如果一定時間需要的數據還沒來就DROP掉，不管他，繼續進行下一個步驟。

3. 滑動窗口機制的概念

滑動窗口實現了TCP流控制。首先明確滑動窗口的範疇 ：TCP是雙工的協議 ，會話的雙方都可以同時接收和發送數據。TCP會話的雙方都各自維護一個發送窗口 和一個接收窗口 。各自的接收窗口大小取決於應用、系統、硬件的限制（TCP傳輸速率不能大於應用的數據處理速率）。各自的發送窗口則要求取決於對端通告的接收窗口 ，要求相同 。

滑動窗口解決的是流量控制 的的問題，就是如果接收端和發送端對數據包的處理速度不同，如何讓雙方達成一致。接收端的緩存傳輸數據給應用層，但這個過程不一定是即時的，如果發送速度太快，會出現接收端數據overflow，流量控制解決的是這個問題。

---

發送方的發送緩存內的數據 都可以被分爲4類:

1. 已發送，已收到ACK
2. 已發送，未收到ACK
3. 未發送，但允許發送
4. 未發送，但不允許發送
   其中類型2和3都屬於發送窗口 。

---

接收方的緩存數據 分爲3類：

1. 已接收
2. 未接收但準備接收
3. 未接收而且不準備接收
   其中類型2屬於接收窗口。

---

窗口大小代表了設備一次能從對端處理多少數據 ，之後再傳給應用層。緩存傳給應用層的數據不能是亂序的，窗口機制保證了這一點。現實中，應用層可能無法立刻從緩存中讀取數據。

4. 滑動機制

1. 發送窗口只有收到發送窗口內字節的ACK確認 ，纔會移動發送窗口的左邊界。
2. 接收窗口只有在前面所有的段都確認的情況下才會移動左邊界 。當在前面還有字節未接收但收到後面字節的情況下，窗口不會移動，並不對後續字節確認。以此確保對端會對這些數據重傳。
3. 遵循快速重傳、累計確認、選擇確認等規則 。
4. 發送方發的window size = 8192;就是接收端最多發送8192字節，這個8192一般就是發送方接收緩存的大小。

5. 滑動窗口機制的模擬程序

模擬程序，網址：http://www.exa.unicen.edu.ar/catedras/comdat1/material/Filminas3_Practico3.swf

稍微有缺陷 ：1. 丟包率如果設得太高，有時無論重發多少次都不能恢復正常 2. 窗口最大可爲10，其實應該爲9

明確發送端和接收端，發送A~S數據包 ，我們不會 從頭到尾分析，因爲過程比較長。

1. 簡化了窗口大小，雙方窗口大小都一直是4。
2. 設置一定的丟包率，否則沒什麼值得分析的，包括sender發送的數據包和receiver回覆的ACK包。
3. 簡化重傳機制，出現丟包則直接重傳，不等3個冗餘ACK和超時。
4. 既不是選擇重傳也不是退回N步，重傳的包是隨機的發。

5.1 具體分析

1. 首先發送端發送A,B,C,D四個包，但是A,B丟失，只有C,D到達接收端。
   

---

2. 接收端沒有收到A，所以不回覆ACK包。發送端重傳A,B,C,D四個包，這次全都到達了。
   

---

3. 接收端先獲得A，發ACK包A，但是中途丟失；獲得B後，根據累計確認的原則，發D的ACK包，然後窗口滑動。再次獲得C,D後，連續回覆2個D的ACK包，其中C對應的ACK包丟失。
   

---

4. 發送端連收2個D的ACK包，說明4個包對方都已收到，窗口滑動，發E,F,G,H包，其中G包丟失。現在整個序列的狀態：ABCD是已發送已確認，EFGH是已發送未確認，I~S是不能發送。
   

---

5. 接收端先收到E，發ACK包；收到F後發F的ACK包；未收到G，還是發F的ACK包；收到H，還是發F的ACK包。不幸的是，三個ACK包全都丟失。
   

---

6. 發送端收到E的ACK包，窗口向右滑動一位；然後再發送F,G,H,I，其中F丟失。
   
7. 接收端獲得I，因爲沒有G，只好回覆F的ACK包。相繼收到G,H包。
   

---

8. 接收端根據累計確認，連發兩個I包，其中H對應的丟失。窗口向右滑動。
   

---

9. 發送端接收I的ACK包後，向右滑動四位。發送J,K,L,M四個包，後面不再分析。
   

從上面的過程中，我們可以得到以下結論 ： TCP連接是通過數據包和ACK實現的，我們作爲第三者可以看到雙方發包的過程，但接受者在收到之前不知道發送方發的是什麼，同樣的，發送方在收到ACK前也不知道對方是否成功接收。

1. 發送方沒有收到接收方發回的ACK，就不能向右滑動 。假設發送方向接收方發了ABCD就滑動，只要對方沒收到A，就不能滑動，那麼就會出現二者不同步的局面。
2. 滑動窗口提高了信道利用率 ，TCP是發送報文段爲單位的，假如每發一個報文就要等ACK，那麼對於大數據包，等待時間就太長了。只要發送的報文在滑動窗口裏面，不用等每個ACK回來就可以向右滑動。本例中，開始接收端空着AB，只有CD，此時不能滑動；之後接收到EF和H，直接向右滑動2位，不必等G到位。
3. 窗口大小不能大於序號空間大小的一半 。目的是爲了不讓兩個窗口出現交迭 ，比如總大小爲7，窗口大小都爲4，接收窗口應當滑動4，但只剩3個序號，導致兩個窗口交迭。
4. 有一種情況沒出現 ：發送方發ABCD，接收方都收到然後向右滑動，但回覆的ACK包全丟了。發送方未收到任何ACK， timeout後會重發ABCD，此時的接收方按累計確認的原則，收到ABCD後只會重發D的ACK，發送方收到後向右滑動。

6 對比滑動窗口和擁塞窗口

滑動窗口是控制接收以及同步數據範圍的，通知發送端目前接收的數據範圍，用於流量控制，接收端使用 。擁塞窗口是控制發送速率的，避免發的過多，發送端使用。因爲tcp是全雙工，所以兩邊都有滑動窗口 。
兩個窗口的維護是獨立的，滑動窗口主要由接收方反饋緩存情況來維護 ，擁塞窗口主要由發送方的擁塞控制算法檢測出的網絡擁塞程度來決定的 。

擁塞窗口控制sender向connection傳輸數據的速率，使這個速率爲網絡擁堵狀況的函數。