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

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

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

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

定義

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

工作原理

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

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

發(fā)生丟包時(shí)

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

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

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

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

GBN協(xié)議

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

工作過程

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

確認(rèn)過程

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

SR協(xié)議工作原理

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

舉例說明

答案是C
在這里有讀者肯定就要問了，為什么1不重發(fā)？
答案很簡(jiǎn)單：因?yàn)镚BN采用的是累積確認(rèn)機(jī)制，收到編號(hào)為2的幀時(shí)，便不會(huì)再去管前面編號(hào)為1的幀是否收到。
所以重發(fā)的幀編號(hào)是在3后面的，編號(hào)為4，5，6，7的幀。

總結(jié)

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

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