目錄
基本概念
流量控制：別噎著啦！
可靠傳輸：快遞必達服務
傳輸差錯：現實中的意外
滑動窗口
基本概念
換句話說：批量發貨+排隊驗收
停止-等待協議 SW（發1份等1份）
超時重傳：
分組編號：
信道利用率
回退N幀協議 GBN（批量發貨，錯了就從錯的重發！）
選擇重傳協議 SR（只補丟的那杯）
基本概念
流量控制：別噎著啦！
概念：流量控制涉及對鏈路上的幀的發送速率的控制，以使接收方有足夠的緩沖空間來接收每個幀（數據鏈路層，點到點；傳輸層也有流量控制，端到端）巴拉巴拉～～
🍔?吃漢堡比喻：
你（發送方）喂朋友（接收方）吃漢堡
朋友嘴里塞滿時說："慢點！等我咽下去再喂！" → 這就是流量控制
如果不管不顧猛塞，朋友會吐（緩沖區溢出）
📱?手機內存例子：
舊手機接收大文件時跳提示："存儲空間不足"
發送方需要暫停發送 → 流量控制起作用
可靠傳輸：快遞必達服務
概念：盡管誤碼是不能完全避免的，但若能實現發送方發送什么，接收方就能收到什么，就稱為可靠傳輸 => 有確認機制和超時重傳機制 巴拉巴拉～～
換句話說：丟了就重發！
📦?網購快遞場景：
商家發貨后要求："收到請按1"（確認ACK）
三天沒回復？自動補發（超時重傳）
收到破損件？申請換貨（差錯重傳）
🚚?特別服務對比：
普通快遞（UDP）：丟了不賠
順豐保價（TCP）：丟件必賠
傳輸差錯：現實中的意外
1、比特錯誤：使用差錯檢測技術，接收方的數據鏈路層就可檢測出幀在傳輸過程中是否產生了誤碼
2、分組丟失、分組失序和分組重復：一般不出現在數據鏈路層，而在上層
🔧?常見問題：
比特錯誤 → 就像快遞單被雨水打糊
分組丟失 → 快遞車半路拋錨
分組亂序 → 快遞員不按樓層送貨
分組重復 → 商家不小心發了兩件
🌐?有線vs無線：
| 網絡類型 | 好比... | 可靠性需求 |
|---|---|---|
| 有線網絡 | 室內通話 | 小聲說也能聽清（一般不重傳） |
| 無線網絡 | 工地對講機 | 必須重復確認（必須可靠傳輸） |
一般情況下，有線鏈路的誤碼率比較低，為了減小開銷，并不要求數據鏈路層向上提供可靠傳輸服務。即使出現了誤碼，可靠傳輸的問題由其上層處理
無線鏈路易受干擾，誤碼率比較高，因此要求數據鏈路層必須向上層提供可靠傳輸服務
滑動窗口
基本概念
發送（接收）方維持一組連續的允許發送（接收）的幀的序號，稱為發送（接收）窗口
發送方：發送窗口的大小代表在還未收到對方確認信息的情況下發送方最多還可以發送多少個數據幀。只有發送方接收到確認幀后發送窗口才可能向前滑動
接收方：只有收到數據幀的序號落在接收窗口內，才允許將幀收下，否則丟棄
換句話說：批量發貨+排隊驗收
場景：奶茶店一次做5杯奶茶（窗口大小=5），顧客按順序取。
-
發送方：連續做5杯（不用等每杯確認），但最多做5杯。
-
接收方：只按順序喝，如果第3杯灑了，要求從第3杯重做（回退N幀）。
幀緩沖區：
1、目的：為了超時重發和判定重復幀的需要
2、實現方式：發送端在發送完數據幀時，必須在其發送緩存中保留此數據幀的副本，這樣才能在出錯時進行重傳（只有收到確認幀ACK時，才刪除副本）
停止-等待協議 SW（發1份等1份）
從滑動窗口機制的角度看，停止-等待協議相當于發送窗口和接收窗口大小均為1的滑動窗口協議
超時重傳：
1、接收端檢測到數據分組有誤碼時，將其丟棄并等待發送方的超時重傳
2、重傳時間一般略大于平均往返時間（平均 RTT），因為代價大，需要多來點時間避免又錯啦！
分組編號：
為了讓接收方（發送方）能夠判斷收到的數據分組是否重復，需要給數據（ACK）分組編號。由于停-等協議特性，只需一個比特編號即可（0、1）
場景：你給同學傳紙條，必須等他回復“收到”再傳下一張。
-
優點：簡單。
-
缺點：慢！（像玩“你拍一我拍一”）
信道利用率
1、發送方在一個發送周期內，有效發送數據的時間占整個發送周期的比例
2、信道利用率U = TD / (TD + RTT + TA)
回退N幀協議 GBN（批量發貨，錯了就從錯的重發！）
1、發送方連續發送幀，當接收方檢測出失序的信息幀后，要求發送方重發最后一個正確接收的信息幀后的所有未被確認幀
場景：你開了一家奶茶店，顧客一次性點了5杯奶茶（編號1~5）。
正常情況：你按順序做好5杯，顧客按順序喝（1→2→3→4→5）。
出錯情況：如果第3杯做錯了（幀錯誤），顧客會說：“從第3杯開始，全部重做！”
于是你把第3、4、5杯都重新做一遍（回退N幀）。
2、n比特編號，發送窗口大小：1 <= WT <= 2^n - 1 接收窗口大小：1
發送窗口（WT）：你最多能同時做多少杯奶茶（比如最多5杯）。
如果編號用
n個比特，最多能發?2^n - 1?杯（比如n=3，最多發7杯）。接收窗口（WR）=1：顧客一次只喝1杯，必須按順序，亂了就扔掉。
3、累計確認
-
顧客喝了第1、2、3杯后，只回復“3號收到”（代表1~3都OK）。
-
如果你沒收到確認，就全部重發（比如3號丟了，就重發3~5）。
稍待確認：或者在自己有數據分組要發送時才按累計確認規則進行捎帶確認
4、缺點
若信道的傳輸質量很差導致誤碼率較大時，不一定優于停止-等待協議
選擇重傳協議 SR（只補丟的那杯）
1、概述：設法只重傳出現差錯的數據幀和計時器超時的數據幀
- 每個發送緩沖區對應一個計時器，當計時器超時時，緩沖區的幀就會重傳
- 一旦接收方懷疑幀出錯，就會發一個否定幀NAK給發送方，要求發送方對NAK中指定的幀進行重傳
- 接收端要設置具有相當容量的緩沖區來暫存那些未按序正確收到的幀
場景：奶茶店發現第3杯做錯了，只重做第3杯，其他照常給。
優點：高效。
缺點：需要記錄哪杯錯了（復雜）。
2、缺點：需要開辟緩存空間用來存儲數據
3、n比特編號，窗口大小：WR <= 2^(n-1)
)
