文章目錄

• 一. 流量控制
• • ① 必要性
  • ② 數據鏈路層 VS 傳輸層
  • ③ 定義
  • ④ 方法
  • • 1）停止等待協議
    • 2）滑動窗口協議
    • • 關系：
      • 包括：
    • 3）協議對比
• 二. 停止-等待協議
• • 必要性
  • 應用情況
  • • ① 無差錯情況
    • ② 有差錯情況
    • • 1）數據幀丟失，或檢測到幀出錯。
      • 2）ACK丟失
      • 3）ACK遲到
    • ③ 性能分析
    • • 結論
      • 解析圖
      • 信道利用率 && 信道吞吐率
      • • 1）定義
        • 2）例題
• 三. 后退N幀協議（GBN）
• • ① GBN的滑動窗口
  • ② GBN發送方要做的三件事
  • ③ GBN接收方要做的事
  • ④ 運行圖
  • ⑤ 滑動窗口長度
  • ⑥ GBN重點總結
  • ⑦ 例題
  • ⑧ 性能分析
• 四. 選擇重傳協議（SR）
• • ① 滑動窗口
  • ② SR發送方必須響應的三件事
  • ③ SR接受方要做的事
  • ④ 運行圖
  • ⑤ 滑動窗口長度
  • • • 公式：$Wtmax$ = $Wrmax$ = 2^n-1
      • 限制原因：
  • ⑥ SR協議重點 && 例題
  • • • 重點
      • 例題
  • ⑦ 思維導圖

ppt來源：王道考研B站教程

一. 流量控制

① 必要性

較高的發送速度和較低的接收能力不匹配的話，會造成傳輸出錯

② 數據鏈路層 VS 傳輸層

層模式流量控制手段

數據鏈路層	點對點	收不下就不回復確認
傳輸層	端到端	給發送端一個窗口公告

③ 定義

控制發送速率，使接收方有足夠的緩沖空間來接收每一個幀。

④ 方法

1）停止等待協議

2）滑動窗口協議

關系：

解決了流量控制，以及可靠傳輸（通過發送方自動重傳）

包括：

• 后退N幀協議（GBN)
• 選擇重傳協議（SR）

3）協議對比

也就是說，其實停等協議也可以看成是一種滑動窗口協議。

二. 停止-等待協議

下簡稱”停等協議“

必要性

• 底層信道會出現丟包問題。
• 流量控制

應用情況

① 無差錯情況

0幀、1幀為編號。ACK為確認幀。（acknowledgement frame）
注意：幀編號可以重復利用，比如此處0，1就是不斷給新幀重復使用的。

② 有差錯情況

停等協議的有差錯情況，都是基于超時計時器來進行處理的。
讓我們在第一種差錯情況中對超時計時器進行更多的介紹。

1）數據幀丟失，或檢測到幀出錯。

• 數據幀丟失：即接收端并沒有接收到數據幀。
• 檢測到幀出錯：接收端接收到了數據幀，但是檢測到數據幀出錯了。

這兩種都產生一樣的結果：接收端不返回ACK。

下圖中，感嘆號部分的原因為：

• 保留副本：可能需要重新發送這個幀（由于之前丟失或出錯）。
• 必須編號：防止重復。
  

2）ACK丟失

描述：接收端接收到數據了，但是發送給發送端的ACK丟失了的情況。

解決流程：
i) 由于沒有回收到ACK，觸發了超時計時器，發送端重新發送當前數據幀。
ii) 接收端再次收到當前數據幀，由于我們有編號，于是判斷這是重復幀，丟棄重復幀，并且再次傳ACK。
iii) 發送端接收到ACK，錯誤解決。（當然，如果又丟失則繼續這個流程）

3）ACK遲到

描述：接收端接收到數據了，但是ACK遲到了，觸發了超時計時器的情況。

解決流程：
i) ACK遲到導致觸發超時計時器，發送端重傳數據幀。
ii) 接收端收到重復數據幀，丟棄重復幀，并重傳ACK。
iii) 發送端在某刻終于收到遲到ACK，由于編號重復，丟棄遲到ACK。

③ 性能分析

結論

簡單，信道利用率太低。

解析圖

可見一個周期中，RTT占了很大的比例。

信道利用率 && 信道吞吐率

1）定義

2）例題

• RTT = 雙向傳播事延 = 2 * 30ms
• 此處TD = L / 4kb/s，TA題干未給，不計。（見解析圖中的公式變量。）
  

三. 后退N幀協議（GBN）

GBN：Go Back N

首先來一個GBN協議與前面的停等協議的對比圖吧！

停等協議

GBN協議

由停等協議到GBN協議，有兩個前提：

• 必須增加序號范圍
• 發送方要緩存多個分組

① GBN的滑動窗口

傳送幀分為三個部分：

• 發完被確認的幀
• 還能發送的幀（即正在發送窗口里的幀）
• 還不能發的幀
  

② GBN發送方要做的三件事

簡單來說，就是：

• 與上層的交流：上層發送數據，發送方如果窗口滿，則退還數據給上層。（實際可以緩存數據）
• 對ACK采取累計確認方式。
  這里要舉個例子：發送0、1、2，只返回ack1，則說明：0，1都收到，重傳2。而非只收到1。
• 超時事情處理：重傳所有已發但未確認幀。
  舉個例子：發送0、1、2、3，返回ack1，超時后重傳2、3。
  （之后的SR協議就是對此處進行了優化。）
  

③ GBN接收方要做的事

下圖簡而言之就是：

• 正確按序收到n號幀后，發送ack N（累計確認），上傳數據給上層。
• 維護Expected_Seq_Num。
  舉個例子：發0、1、2、3，接收到0、2、3，則發ack0，expectedseqnum=1（期待接收幀是1）
  這里提了一下緩存失序幀，其實就是為SR協議引一下，因為SR協議會緩存失序幀。
  

④ 運行圖

圖中需要注意：

• 接收3、4、5后，都丟棄，并且發送的都是ACK 1。
• 超時計時器：超時后，重傳所有已發未確認幀，結合expectedseqnum=2來維護運行。
  

⑤ 滑動窗口長度

• 采取n比特對幀編號的情況：發送窗口尺寸W滿足：1 ≤ W ≤ $2^n$-1
• 原因：尺寸過大會導致接收方無法區分新幀與舊幀。
  如果不太了解為啥無法區分，可以到SR協議部分再看看解析。

⑥ GBN重點總結

這里直接看圖就好

⑦ 例題

做這道題需要的知識點：

• 累計確認
• GBN的重發機制

解析：由于收到了3號幀的確認，也就是ACK 3，那么由累計確認機制可知：0、1、2、3號幀都成功傳送。因此，只有4、5、6、7號幀需要重發。所以選C.4。

⑧ 性能分析

i) 優點：連續發送數據幀 => 提高信道利用率。
ii) 缺點：重傳時要把已經正確傳輸的數據幀重傳 => 傳送效率降低。

最后來一個GBN的思維導圖

四. 選擇重傳協議（SR）

SR：Selective Repeat

對于之前的GBN協議，我們了解其弊端：批量重傳。
而為了解決這一弊端，我們有一個解決方法：

單個確認，加大接收窗口，設置接收緩存，支持亂序（緩存亂序到達幀）

由此引出SR協議

① 滑動窗口

與GBN協議不同在于：

• 見接收方窗口的紫色部分6，新增緩存功能。
• 見發送方窗口的綠色部分3，支持亂序確認，也就是重傳時可以傳2，4而省略3。
• 下界：位于發送方窗口的最小序號位，下圖中為2號幀。
  

② SR發送方必須響應的三件事

• 上層調用同GBN，不贅述。
• ACK：與GBN不同，并非累計確認。具體可見圖中解釋。
  舉個例子：
  發0、1、2、3、4，收到ACK1 、2、3，那么說明0、4并沒有被正確接收。并且由于0是下界，因此不能移動窗口。于是重傳0、4，如果只返回ACK0，那么窗口移動，下界變成4。
• 超時事件：一個超時事件對應一個幀的重傳
  

③ SR接受方要做的事

分成三類。

• 接受亂序，緩存失序幀。如下圖的6號幀
• 比下界序號還小的幀，返ACK。（下圖5號幀前的01234，只是重新確認已發）
• 其他情況：忽略。

移動滑動窗口的情況：下界幀成功返回ACK。

④ 運行圖

• 2幀丟失后，3幀緩存，發送ACK3 （GBN則返ACK2）
• 2幀超時后，重傳2幀。（GBN則返2345）
• 移動窗口：重傳2幀后，2-5都成功了，移動下界到6。
  

⑤ 滑動窗口長度

公式：$Wtmax$ = $Wrmax$ = 2^n-1

限制原因：

同GBN，會導致接收方無法區分新幀與舊幀。
見圖左，與圖右流程：

• 共同點：最后都是接受0號幀
• 不同點：左邊是重傳（舊幀），右邊不是重傳（新幀）

解決方法：按公式給窗口長度，就不會出現這種二義性錯誤。

⑥ SR協議重點 && 例題

重點

直接見下圖

例題

考察知識：

• SR協議的重傳機制

解析：

• 1號幀已經確認，不需要重傳
• 0、2號幀超時，需要重傳
• 3號幀，沒超時，先不處理。

因此，最終只需要重傳0、2號幀，答案選A.2。

⑦ 思維導圖

終于補完這一小節的內容了= =，一篇博客拖了好久。
要抓緊寫完三四章的內容了！

總結

以上是生活随笔為你收集整理的【学习笔记】数据链路层——流量控制：停止等待协议、后退N帧协议（GBN)、选择重传协议（SR）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。