掌握TCP/IP鏈路層滑動窗口協議

引語

萬丈高樓平地起，靠的就是深厚的地基

什麼是流量控制

流量控制涉及對鏈路上的幀的發送速率的控制 ，以使接收方有足夠的緩衝空間來接收每個幀。例如，在面向幀的自動重傳請求系統中 ，當待確認幀的數量增長時 ，有可能超出緩衝存儲空間而形成過載 。流量控制的基本方法是由接收方控制發送方發送數據的速率 ，常見的方式有兩種 ： 中止-等待協議和滑動窗口協議 。

流量控制的一些知識點

1. 接收端抑制發送端的依據：接收端緩衝區的大小
2. 流量控制的目標是接收端，是怕接收端來不及處理
3. 流量控制的機制是丟包

中止-等待流量控制的基本原理

發送方每發送一幀，都要等待接收方應答信號，以後才能發送下一幀；接收方每接收一幀，都要反饋一個應答信號，表示能夠接收下一幀，若是接收方不反饋應答信號，則發送發必須一直等待。每次只容許發送一幀，而後就陷入等待接收對方確認信號的過程當中，於是傳輸效率很低。

滑動窗口流量控制的基本原理

在任意時刻，發送方都維持一組連續的容許發送的幀的序號，稱爲發送窗口；同時接收方也維持一組連續的容許接收的序號，稱爲接收窗口。發送窗口用來對發送方進行流量控制，而發送窗口的的大小 Wt 表明尚未收到對方確認信息的狀況下發送方最多還能夠發送多少數據幀。同理，在接收端設置接收窗口是爲了控制能夠接收哪些數據幀而不能夠接收哪些數據幀。在接收數據方只有收到當前數據幀的序號落入接收窗口內才容許將該數據幀收下，若接收的數據幀落在接收窗口以外，則一概將其丟棄。

下圖給出了發送窗口和接收窗口的工做原理。

滑動窗口的重要特性

1. 只有接收窗口向前滑動時（同時接收方發送確認幀）發送窗口才有可能（只有發送方收到確認幀纔是必定）向前滑動。
2. 從滑動窗口的概念看，中止-等待協議、後退N幀協議和選擇重傳協議只有在發送窗口大小和接收窗口大小有區別。
   中止等待協議：發送窗口大小=1，接收窗口大小=1；
   後退N幀協議：發送窗口大小>1，接收窗口大小=1；
   選擇重傳協議：發送窗口大小>1，就收窗口大小>1;
3. 當滑動窗口大小爲1時，可保證幀的有序接收；
4. 數據鏈路層的滑動窗口協議中 ，窗口的大小在傳輸過程當中是固定的（注意與傳輸層的滑動窗口協議的區別）。

可靠傳輸機制

數據鏈路層的可靠傳輸一般使用確認幀和超市重傳兩種機制來完成。

確認幀是一種無數據的控制幀，這種控制幀使得接收方可讓發送方知道哪些內容被正確接收。有些狀況下爲了提升傳輸效率。將確認幀捎帶在一個回覆幀中，成爲捎帶確認。

超時重傳是指發送方在發送某一個數據幀之後就開始一個計時器，在必定時間內若是沒有獲得發送的數據幀的確認幀，那麼就從新發送該數據幀，直到發送成功爲止。

自動重傳請求（Auto Repeat reQuest, ARQ），經過接收方請求發送方重傳出錯的數據幀來恢復出錯的幀，是通訊中用於處理信道所帶來差錯的方法之一。
傳統自動重傳請求分爲三種，即停等式（Stop-and-Wait）ARQ、後退N幀（Go-Back-N）ARQ以及選擇性重傳（Selective Request）ARQ。後兩種協議是滑動窗口技術與請求重傳技術的結合，因爲窗口尺寸開到足夠大，幀在線路上能夠連續流動，所以又稱爲連續ARQ協議
。

對於中止-等待協議，因爲每發送一個數據幀就中止並等待，所以用1bit編號就夠。在中止-等待協議中，若連續出現相同發送序號的數據幀，代表發送端進行了超時重傳。連續出現相同序號的確認幀，代表接收端收到了重複幀。
此外，爲了超時重發和斷定重複幀的須要，發送方和接收方都需設置一個幀緩衝區。發送端在發送完數據幀時，必須在其發送緩存中保留此數據幀的副本，這樣才能在出差錯時進行重傳。只有在收到對方發來的確認幀ACK時，方可清除此副本。

由下圖可知，中止-等待協議通訊信道的利用率很低 。爲了克服這一缺點 ，就產生了另外兩種協議 ，即後退 N幀協議和選擇重傳協議。

多幀滑動窗口協議與後退N幀協議（GBN）

在後退N幀ARQ中，發送方不須要收到上一幀的ACK後纔開始發送下一幀，而是能夠連續發送幀。當接收方檢測出失去的信息幀後，能夠要求發送方重發最後一個正確接收的信息幀以後的全部未確認的幀；或者當發送方發送了N個幀後，若發現該N個幀的前一個幀被判爲出錯或丟失，此時發送方就不得不重傳該出錯幀及隨後的N個幀。換句話說，接收幀方只容許按順序接收幀。

如圖所示，源站向目的站發送數據幀 。當源站發完 0 號幀後，能夠繼續發送後續的 1 號幀、2 號幀等。源站每發送完一幀就要爲該幀設置超時計時器 。因爲連續發送了許多幀，因此確認幀必需要指明是對哪一幀進行確認 。

爲了減小開銷 ，GBN協議還規定接收端不必定每收到一個正確的數據幀就必須當即發回一個確認幀 ，而是能夠在連續收到好幾個正確的數據幀後，纔對最後一個數據幀發確認信息 ，或者能夠在當本身有數據要發送時纔將對之前正確收到的幀加以捎帶確認 。這就是說 ，對某一數據幀的確認就代表該數據幀和這之前全部的數據幀均己正確無誤地收到了。

在圖中，ACKn 表示對第 n 號幀的確認 ，表示接收方己正確收到了第 n 號幀及之前的全部幀，下一次指望收到第 n+1 號幀 （也多是第 0 號幀）。接收端只按序接收數據幀 。 雖然在有差錯的 2 號幀以後接着又收到了正確的 6 個數據幀，但接收端都必須將這些幀丟棄。接收端雖然丟棄了這些不按序的無差錯幀 ，但應重複發送己經發送過的最後一個確認幀 ACK1 （ 這是防止己經發送過的確認幀 ACK1 丟失）。

後退N幀協議的接收窗口爲1，能夠保證按序接收數據幀。若採用n個比特對幀編號，則期發送窗口的尺寸 Wt 應知足：1 <= Wt <= 2^n - 1。若發送窗口的尺寸大於2^n - 1，則會形成接收方沒法分辨新幀和舊幀。‘

後退N幀協議一方面因連續發送數據幀而提升了信道的利用率，但另外一方面，在重傳時又必須把原來已發送正確的數據幀進行重傳（僅因這些數據幀的前面有一個數據幀出了錯），這種作法又使傳送速率下降。因而可知，若信道的傳輸質量不好致使誤碼率較大時，後退N幀協議不必定優於中止等待協議。

多幀重傳窗口與選擇重傳協議（SR）

只重傳出現差錯的數據幀或者是計數器超時的數據幀。

在選擇重傳協議中，每個發送緩衝區對應一個計時器，當計時器超時時，緩衝區的幀就會重傳。一旦接收方懷疑幀出錯，就會發送一個否認幀NAK給發送方，要求發送方對NAK中指定的幀進行重傳。

選擇重傳協議的接收窗口尺寸 Wr 和發送窗口尺寸 Wt 都大於1，一次能夠發送或接收多個幀。若採用 n 比特對幀編號，爲了保證接收方向向前移動窗口後，新窗口序號與舊窗口序號沒有重疊部分，須要知足條件：接收窗口Wr + 發送窗口Wt <= 2^n。假定仍然採用累計確認的方法，而且接收窗口 Wr 顯然不該超過發送窗口 Wt(不然無心義)，那麼接收窗口尺寸不該超過序號範圍的一半 Wr <= 2^(n-1)。當接收窗口爲最大值時，Wtmax = Wrmax = 2^(n-1)。

選擇重傳協議能夠避免重複傳送那些本已正確到達接收端的數據幀，但在接收端要設置具備至關容量的緩衝區來暫存那些未按序正確收到的幀。接收端不能接收窗口如下或窗口上界以上的序號的幀，所以所需緩衝區的數目等於窗口的大小，而不是序號數目。

補充問題

在中止-等待協議中 ，確認幀爲何不須要序號（如用 ACK0 和 ACK1 ) ?

答：
在中止等待協議中，發送方每發送一幀，都須要等收到接收方的確認幀後，才能進行下一幀的發送，而發送方收到的確認幀也必定是 本身剛剛發出去的數據幀的確認幀,無須加序號標記。

爲何當用n個比特進行編號時 ，若接收窗口的大小爲 1，則只有在發送窗口的大小 Wt <= 2^n-1 時，連續ARQ 協議才能正確運行 ?

答:
咱們舉一個具體的例子說明。例如用3比特可編出8個不一樣的序號，於是發送窗口的最大值彷佛應爲8。但實際上，設置發送窗口爲8將使協議在某些狀況下沒法工做。如今咱們就來講明這一點。

設發送窗口Wτ =8，發送端發送完0~7號共8個數據幀。因發送窗口已滿，發送暫停。假定這8個數據幀均已正確到達接收端，而且對每個數據幀，接收端都發送出確認幀。下面考慮兩種不一樣的狀況。

第一種狀況是:全部的確認幀都正確到達了發送端，於是發送端接着又發送8個新的數據幀，其編號應當是0~7。請注意，序號是循環使用的。因此序號雖然相同，但8個幀都是新的幀。

第二種狀況是:全部的確認幀都丟失了。通過一段由超時計時器控制的時間後，發送端重傳這8箇舊的數據幀，其編號仍爲0~7。

因而，當接收端第二次收到編號爲0~7的8個數據幀時，就沒法斷定:這是8個新的數據幀，或這是8箇舊的、重傳的數據幀。
所以，將發送窗口設置爲8顯然是不行的。

---

參考：
《計算機網絡》（王道計算機考研系列）

推薦閱讀：
【專題：JavaScript進階之路】
TCP三次握手和四次揮手
AJAX原理及常見面試題
ES6 尾調用和尾遞歸
JavaScript之函數柯理化
淺談 MVC 和 MVVM 模型

---

我是Cloudy，年輕的前端攻城獅一枚，愛專研，愛技術，愛分享。
我的筆記，整理不易，感謝關注、閱讀、點贊和收藏。
文章有任何問題歡迎你們指出，也歡迎你們一塊兒交流各類技術問題！