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

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

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

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

定義

傳輸?shù)拿總€部分被分配唯一的連續(xù)序列號，接收方使用數(shù)字并以正確的順序放置接收到的數(shù)據(jù)包，丟棄重復(fù)的數(shù)據(jù)包并識別丟失的數(shù)據(jù)。

工作原理

簡單來說：第一個和第二個包發(fā)送過去后，收到第一個確認包就把第三個包發(fā)送過去，圖示如下（圖片來源于網(wǎng)絡(luò)）：

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

發(fā)生丟包時

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

當(dāng)ACK包一直發(fā)送不過來的情況時

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

上圖可以看出5號包已經(jīng)接受ACK，后面的6，7，8號包也發(fā)送過去，窗口便繼續(xù)向后移動。

GBN協(xié)議

后退N幀ARQ協(xié)議對傳統(tǒng)的自動重傳請求（ARQ,Automatic Repeat reQues）進行了改進，從而實現(xiàn)了在接收到ACK之前能夠連續(xù)發(fā)送多個數(shù)據(jù)包。

工作過程

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

確認過程

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

SR協(xié)議工作原理

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

舉例說明

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。