上一篇中已經有一個可靠數據傳輸的基本協議——rdt3.0了。這個協議的致命問題是“效率太低了”。如果想讓rdt3.0能夠使用，我們就必須解決“停等”這個問題。直觀的方式就是“允許發送方一次性發送多個分組”。這樣就能大大提高物理鏈路的利用率。
這樣我們就必須設置更大的位數來表示“編號”，以及更大的緩存空間來緩存更多的分組。 這就是計算機網絡中的“流水線技術”。我們只要能在計算機網絡中實現“流水線技術”，那麼rdt3.0就能實際實現了。在計算機網絡中實現“流水線技術”的方法是“滑動窗口協議”。
GBN
GBN協議（回退N步），它允許發送多個分組而不需要等待確認。但它受限制於窗口的大小N。
GBN協議也常被成爲滑動窗口協議。在GBN協議中，發送方首先檢查窗口大小是否是滿的，如果沒有滿，那麼就產生一個分組並將其發送，並且同時更新變量。如果窗口已經滿了，那麼發送方給上層指出已滿。然後上層會等一會再來試。發送方收到ACK應答的方式是“累計確認”。這表明接收方已經正確接受到序列爲N的以前的所有分組。當超時事件發生的時候，GBN協議是“回退N步”來進行處理的。它將已經確認收到之後所有已發送但未確認的分組重傳。這樣能夠保證分組的順序。
接收方需要做的事情比較簡單，如果序號爲n的分組正確接受，並且它之前的所有分組也是正確接收到了，那麼就返回一個ACK，否則丟棄該分組，並且按照最近接受的分組，重新發送該分組的ACK。
GBN的缺點很明顯就是重傳的時候，需要傳輸大量的分組，這個問題在網絡環境比較糟糕的情形下，會導致非常多的重傳出現。一個示例如下
在這個示例中窗口大小是4。我們回退4步進行重傳，即將2，3，4，5都重新傳輸一次。
SR
GBN的缺點是明顯得，有些分組其實是沒有必要重傳的。那麼爲了不進行沒必要的重傳，我們在接收方設置緩存，讓亂序到達的分組緩存起來。這時很明顯，發送方只需要重傳哪些沒有收到ACK應答的分組，這樣就必須爲每一個分組設置一個定時器。
發送方收到ACK，如果該分組序號在窗口內，則SR標記該分組爲已接受。如果該分組序號等於窗口起始位置序號，那麼該窗口移動到具有最小序號的未確認分組處，然後發送該窗口內可發送但未發送的分組。
接收方此時也擁有一個窗口，如果分組序號在該窗口範圍內，並且以前沒收到過，那麼緩存該分組，回覆一個ACK給發送方。如果分組序號等於窗口起始位置的序號，那麼將以前緩存的（小於起始位置）的分組和該分組一起交付給上層。如果接收方收到的序號是在該窗口起始位置的左側（小於起始位置）。那麼需要返回一個ACK。其餘情形下，一律丟棄分組。
下面是一個示例。左邊是發送方，右邊是接收方。
在SR（選擇重傳）協議中，我們需要面對的最難的問題是有限序列號，該情形下，可能會產生下面的困境。
接收方無法判斷這個序號0到底是之前的分組序號，還是新的分組序號。因此窗口的大小和序號之間的關係必須是合理的。
Ns是發送方窗口大小，Nr是接收方窗口大小，k是序號的位數。
