滑動窗口協議、GBN、SR之間不得不說的故事

首先我們來介紹什么是滑動窗口協議

滑動窗口協議（Sliding Window Protocol），屬于TCP協議的一種應用，用于網絡數據傳輸時的流量控制，以避免擁塞的發生。該協議允許發送方在停止并等待確認前發送多個數據分組。由于發送方不必每發一個分組就停下來等待確認，因此該協議可以加速數據的傳輸，提高網絡吞吐量。關于TCP協議的介紹，可以查看我的另外一條博文《計算機網絡自頂向下》知識體系梳理

如果許多客戶向主機以很快的速度發送大量的數據包，但是接收方卻沒有如此高的接收數據的能力，這個時候，我們就要控制發送方的發送速度，控制它不要過快，要求發送方限制它已經發出但未經確認的幀的數目，使得網絡傳輸效率得以提高，滑動窗口協議就是這么來的。
在任何基于自動重發請求進行錯誤控制的通信協議中，接收方必須確認收到的數據包。
如果發送方在合理的時間內沒有收到確認，則重發數據。沒有聽到確認的發送方不知道接收方是否實際接收到分組（數據可能在傳輸中丟失或損壞）。 如果錯誤檢測顯示損壞，則數據包將被接收方忽略，并且不會發送確認。 因為網絡傳輸的時延，將有大量時間被用于等待確認，導致傳輸效率低下。

定義

傳輸的每個部分被分配唯一的連續序列號，接收方使用數字并以正確的順序放置接收到的數據包，丟棄重復的數據包并識別丟失的數據。

工作原理

簡單來說：第一個和第二個包發送過去后，收到第一個確認包就把第三個包發送過去，圖示如下（圖片來源于網絡）：

在這張圖里我們可以看到，灰色1，2，3號包已經發送完畢，并且已經收到了ACK，4，5，6，7號包是黃色的，表示已經發送的，沒收到ACK的意思就是也不知道對方接收到了沒有，但還沒有收到ACK，8，9，10號包是綠色的，表示還未發送，白色部分表示還未讀入內存，要等到4-10號包收到ACK后才會有所動作。

發生丟包時

這種情況可能是我們包發過去，對方的ACK丟了；或者是我們的包并沒有發生過去，對方沒有收到ACK。
此時的情況：一直在等ACK，如果一直等不到ACK發過來，我們就會把讀進緩存的ACK包也一起發送過去，但這個時候窗口已經發滿了，說一并不能讀取12號包，而是在一直等待5號包的ACK。

當ACK包一直發送不過來的情況時

解決方法：超時重傳
ACK是要按照順序發送的，也就是說，必須等到5的ACK收到，才會把6-11的ACK發送過去，這樣做的目的是為了保持滑動窗口的順序。

上圖可以看出5號包已經接受ACK，后面的6，7，8號包也發送過去，窗口便繼續向后移動。

GBN協議

后退N幀ARQ協議對傳統的自動重傳請求（ARQ,Automatic Repeat reQues）進行了改進，從而實現了在接收到ACK之前能夠連續發送多個數據包。

工作過程

GBN協議中，發送方在發完一個數據幀后，連續發送若干個數據幀，即使在連續發送過程中收到了接收方發來的應答幀，也可以繼續發送。且發送方在每發送完一個數據幀時都要設置超時定時器。只要在所設置的超時時間內仍未收到確認幀，就要重發相應的數據幀。如：當發送方發送了N個幀后，若發現該N幀的前一個幀在計時器超時后仍未返回其確認信息，則該幀被判為出錯或丟失，此時發送方就不得不重新發送出錯幀及其后的N幀

確認過程

接受幀只允許按順序接受幀。為了減少開銷，累計確認允許接收端在連續收到好幾個正確的確認幀后，只對最后一個數據幀發確認信息，或者可以在自己有數據要發送時才將對以前正確收到的幀加以捎帶確認。這就是說，對某一數據幀的確認就表明該數據幀和這以前所有的數據幀均已正確無誤地收到了。

SR協議工作原理

SR協議是當接收方發現某幀出錯后，其后繼續送來的正確的幀雖然不能立即遞交給接收方的高層，但接收方可收下來，存放在一個緩沖區中，同時要求發送方重新傳送出錯的那一幀。一旦收到重新傳來的幀后，就可以原已存于緩沖區中的其余幀一并按正確的順序遞交高層。顯然，SR減少了浪費，但要求接收方有足夠大的緩沖區空間

舉例說明

答案是C
在這里有讀者肯定就要問了，為什么1不重發？
答案很簡單：因為GBN采用的是累積確認機制，收到編號為2的幀時，便不會再去管前面編號為1的幀是否收到。
所以重發的幀編號是在3后面的，編號為4，5，6，7的幀。

總結

以上是生活随笔為你收集整理的三句话介绍清楚滑动窗口协议/GBN/SR的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。