版權(quán)聲明：本文為博主原創(chuàng)文章，轉(zhuǎn)載請注明博客地址： https://blog.csdn.net/zy010101/article/details/90377225

上一篇中已經(jīng)有一個可靠數(shù)據(jù)傳輸?shù)幕緟f(xié)議——rdt3.0了。這個協(xié)議的致命問題是“效率太低了”。如果想讓rdt3.0能夠使用，我們就必須解決“停等”這個問題。直觀的方式就是“允許發(fā)送方一次性發(fā)送多個分組”。這樣就能大大提高物理鏈路的利用率。

這樣我們就必須設(shè)置更大的位數(shù)來表示“編號”，以及更大的緩存空間來緩存更多的分組。 這就是計算機網(wǎng)絡(luò)中的“流水線技術(shù)”。我們只要能在計算機網(wǎng)絡(luò)中實現(xiàn)“流水線技術(shù)”，那么rdt3.0就能實際實現(xiàn)了。在計算機網(wǎng)絡(luò)中實現(xiàn)“流水線技術(shù)”的方法是“滑動窗口協(xié)議”。

GBN

GBN協(xié)議（回退N步），它允許發(fā)送多個分組而不需要等待確認。但它受限制于窗口的大小N。

GBN協(xié)議也常被成為滑動窗口協(xié)議。在GBN協(xié)議中，發(fā)送方首先檢查窗口大小是否是滿的，如果沒有滿，那么就產(chǎn)生一個分組并將其發(fā)送，并且同時更新變量。如果窗口已經(jīng)滿了，那么發(fā)送方給上層指出已滿。然后上層會等一會再來試。發(fā)送方收到ACK應(yīng)答的方式是“累計確認”。這表明接收方已經(jīng)正確接受到序列為N的以前的所有分組。當(dāng)超時事件發(fā)生的時候，GBN協(xié)議是“回退N步”來進行處理的。它將已經(jīng)確認收到之后所有已發(fā)送但未確認的分組重傳。這樣能夠保證分組的順序。

接收方需要做的事情比較簡單，如果序號為n的分組正確接受，并且它之前的所有分組也是正確接收到了，那么就返回一個ACK，否則丟棄該分組，并且按照最近接受的分組，重新發(fā)送該分組的ACK。

GBN的缺點很明顯就是重傳的時候，需要傳輸大量的分組，這個問題在網(wǎng)絡(luò)環(huán)境比較糟糕的情形下，會導(dǎo)致非常多的重傳出現(xiàn)。一個示例如下

在這個示例中窗口大小是4。我們回退4步進行重傳，即將2，3，4，5都重新傳輸一次。

SR

GBN的缺點是明顯得，有些分組其實是沒有必要重傳的。那么為了不進行沒必要的重傳，我們在接收方設(shè)置緩存，讓亂序到達的分組緩存起來。這時很明顯，發(fā)送方只需要重傳哪些沒有收到ACK應(yīng)答的分組，這樣就必須為每一個分組設(shè)置一個定時器。

發(fā)送方收到ACK，如果該分組序號在窗口內(nèi)，則SR標記該分組為已接受。如果該分組序號等于窗口起始位置序號，那么該窗口移動到具有最小序號的未確認分組處，然后發(fā)送該窗口內(nèi)可發(fā)送但未發(fā)送的分組。

接收方此時也擁有一個窗口，如果分組序號在該窗口范圍內(nèi)，并且以前沒收到過，那么緩存該分組，回復(fù)一個ACK給發(fā)送方。如果分組序號等于窗口起始位置的序號，那么將以前緩存的（小于起始位置）的分組和該分組一起交付給上層。如果接收方收到的序號是在該窗口起始位置的左側(cè)（小于起始位置）。那么需要返回一個ACK。其余情形下，一律丟棄分組。

下面是一個示例。左邊是發(fā)送方，右邊是接收方。

在SR（選擇重傳）協(xié)議中，我們需要面對的最難的問題是有限序列號，該情形下，可能會產(chǎn)生下面的困境。

接收方無法判斷這個序號0到底是之前的分組序號，還是新的分組序號。因此窗口的大小和序號之間的關(guān)系必須是合理的。

Ns是發(fā)送方窗口大小，Nr是接收方窗口大小，k是序號的位數(shù)。