文章目錄
- 前言
- 一、流水線協議
- 二、滑動視窗協議
- 1.GBN(回退N重傳協議)
- 2.SR(選擇重傳協議)
- 總結
前言
提示：以下是本篇文章正文內容
一、流水線協議
我們知道Rdt 3.0: 停等操作程序中浪費了大量的時間：
從而在Rdt 3.0上引入了流水線機制：為了提高資源利用率
流水線協議：
允許發送方在收到ACK之前連續發送多個分組，更大的序列號范圍，同時發送方和/或接收方需要更大的存盤空間以快取分組
如圖：
二、滑動視窗協議
滑動視窗協議：發送方和接收方各有一個快取陣列，發送方存放著：已發送且成功確認包序號、已發送未確認包序號 ，未發送包序號，接收方存放著：已接受包序號、正在接收包序號、未接收包序號，每個陣列有個兩個掃描指標，開頭和結尾，一起向后掃描，兩者形成一個視窗，所有被稱為視窗協議
滑動視窗協議(Sliding-window protocol)主要有兩類協議：GBN(go-Back-N，回退N重傳協議), SR(selective repeat，選擇重傳協議)
視窗：允許使用的序列號范圍，視窗尺寸為N：最多有N個等待確認的訊息
滑動視窗：隨著協議的運行，視窗在序列號空間內向前滑動
1.GBN(回退N重傳協議)
GBN內容：
(1)分組頭部包含k-bit序列號
(2)視窗尺寸為N，最多允許N個分組未確認
(3)確認ACK(n): 確認到序列號n(包含n)的分組均已被正確接收，可能收到重復ACK
注：接收者僅發送累計的確認 ，如果中間有資料缺失，就不予以確認
(4)為傳輸的分組設定計時器(timer)，若超時Timeout(n): 重傳序列號大于等于n，還未收到ACK的所有分組
發送方擴展FSM：
發送資料時要判斷視窗是否已經滿了
接收方擴展FSM：
ACK機制: 發送擁有最高序列號的、已被正確接收的分組的ACK，可能產生重復ACK，只需要記住唯一的expectedseqnum, ：接收方標記下一個按序接收的分組的序號
若亂序到達的分組：
1.直接丟棄，接收方沒有快取
2.重新確認序列號最大的、按序到達的分組
示例：
視窗大小為4，發送方發送資料包0，1，2，3，然后進入等待狀態，其中資料包2丟失，接收方回傳Ack0，1，視窗滑動繼續發送包4，5，此時包2計時超時，默認資料包2沒有收到，按照GBN，發送方重新發送資料包2，3，4，5，這里可以看出資料包重復了，
練習題：資料鏈路層采用后退N幀（GBN）協議，發送方已經發送了編號為0～7的幀，當計時器超時時，若發送方只收到0、2、3號幀的確認，則發送方需要重發的幀數是多少？分別是那幾個幀？
根據GBN協議作業原理，GBN協議的確認是累積確認，不會管中間所丟的資料包，所以，此時發送端需要重發的幀數是4個，依次分別是4、5、6、7號幀
2.SR(選擇重傳協議)
SR內容：
(1)接收方對每個分組單獨進行確認, 設定快取機制，為了快取亂序到達的分組，發送方就不會再次發送，限制已發送且未確認的分組
發送/接收方視窗
(2)如果計時器到點, 僅重傳該個未確認的資料報
(3)發送方視窗，N個連續的序列號， 發送者在流水線中最多有 N 個未確認的資料報
示例
滑動視窗的大小為4，發送資料包0，1，2，3，視窗滿了，停止發送，等待確認，其中資料包2丟失，依次確認資料包0，1，同時視窗向后移，依次發送資料包4，5，當資料包2超時，發送方會再次發送資料包2，同時快取亂序到達的3，4，5，當接收完資料包2后，滑動視窗后移，發送方繼續發送資料包
序列號空間大小與視窗尺寸需滿足
若序號位數k位(SR協議)，發送視窗和接收視窗尺寸最大是2**-1,即序號空間一半，
避免發生接收序號重疊，出現重復分組
總結
提示：這里對文章進行總結：
停等(stop-and-wait )協議：發送方發送資料，然后等待接收方通過ACK或者NAK反饋
流水線協議(Pipelined protocols)：允許發送方發送多個分組而無需等待確認
解決流水線的差錯恢復有兩種基本方法（滑動視窗協議）：
1.回退N步(Go-Back-N，GBN)：回退N步，接收方則是只接受最小的未接受幀，對錯序到達幀，都丟棄
2.選擇重傳(selective repeat，SR)：只重傳丟失的幀，亂序到達的幀快取起來
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/333661.html
標籤：其他
上一篇：DNS決議
下一篇：TCP/UDP面試題高頻詞匯詳解