可靠數(shù)據(jù)傳輸原理
可靠數(shù)據(jù)傳輸?shù)膶崿F(xiàn)問題在應用層，運輸層，網(wǎng)絡層，鏈路層普遍存在茶没，本節(jié)在一般情境下討論可靠數(shù)據(jù)傳輸。
為上層實體提供的服務抽象：數(shù)據(jù)可通過可靠信道傳輸晚碾。
可靠信道
1.不錯 數(shù)據(jù)流中的比特不會反轉(zhuǎn)
2.不亂 所有數(shù)據(jù)包按其發(fā)送順序交付
3.不丟 數(shù)據(jù)包不會丟失
可靠數(shù)據(jù)傳輸協(xié)議設(shè)計
- 漸進地設(shè)計可靠數(shù)據(jù)傳輸協(xié)議的發(fā)送方和接收方
- 只考慮單向數(shù)據(jù)傳輸抓半，但控制信息雙向流動
- 利用狀態(tài)機刻畫傳輸協(xié)議
接口
可靠數(shù)據(jù)傳輸協(xié)議基本結(jié)構(gòu).png
Rdt 1.0——底層信道完全可靠
假定
- 底層信道完全可靠，即底層信道不錯格嘁，不亂笛求，不丟
狀態(tài)機
發(fā)送方.png
接收方.png
Rdt 2.0——底層信道可能有位錯誤
假定
- ！底層信道可能翻轉(zhuǎn)分組中的位糕簿，但假定接收方的反饋報文不會發(fā)送錯誤
- 底層信道不亂不丟
應對機制
差錯檢測
一種使得接收方可以確認分組是否含比特差錯的機制
- 利用校驗和檢測位錯誤
- ACK:接收方顯式通知發(fā)送方分組已正確接收
- NAK:接收方顯式通知發(fā)送方分組存在差錯
差錯恢復
- 發(fā)送方得知分組出錯后（收到NAK）探入，重傳分組
- 基于這種重傳機制的rdt協(xié)議稱為自動重傳請求協(xié)議（Automatic Repeat reQuest,ARQ）
停—等協(xié)議
發(fā)送方發(fā)出一個分組后懂诗，等待接收方的反饋（ACK或NAK）蜂嗽，在等待狀態(tài)下，發(fā)送方不會發(fā)出新的分組
新機制
- 差錯檢測
- 接收方反饋控制消息: ACK/NAK
- 重傳
狀態(tài)機
發(fā)送方.png
接收方.png
Rdt 2.1——接收方反饋可能受損
假定
- 殃恒！底層信道可能翻轉(zhuǎn)分組中的位植旧，特別的，接收方的反饋報文也可能發(fā)生錯誤
- 底層信道不亂不丟
應對機制
差錯檢測
- 為ACK/NAK增加校驗和
差錯恢復
- 發(fā)送方收到受損的接收方反饋報文后离唐，重傳當前分組
冗余分組問題
- 發(fā)送方對受損ACK或NAK直接重傳分組的策略病附，引入了冗余分組，為處理冗余分組：
發(fā)送方對分組編號亥鬓，接收方記住上一個收到的分組編號完沪，此處只需{0,1}編號；
接收方收到重復的分組時嵌戈，丟棄分組并發(fā)送該分組的ACK覆积；
新機制
- 增加了對反饋報文的差錯檢測機制和差錯恢復機制
- 引入了冗余分組問題
- 為每個分組增加了序列號{0，1}
狀態(tài)機
發(fā)送方.png
接收方.png
Rdt 2.2——無NAK消息協(xié)議
假定
同Rdt 2.1
- 底層信道可能翻轉(zhuǎn)分組中的位
- 底層信道不亂不丟
目標
- 在設(shè)計上消除反饋報文NAK以實現(xiàn)簡化
新機制
- 取消NAK
- 接收方在反饋報文ACK中加入對應分組的編號
-
冗余ACK策略
接收方收到錯誤分組i+1后熟呛，發(fā)送一個對分組i的ACK;
發(fā)送方收到對分組i的兩個ACK后技健，可斷定接收方?jīng)]有正確接收分組i+1,故應重傳分組i+1
狀態(tài)機
狀態(tài)機片段
Rdt 3.0——底層信道可能丟失分組
假定
- 底層信道可能翻轉(zhuǎn)分組中的位
- ！底層信道可能丟失分組
- 底層信道不亂惰拱，即分組被按其發(fā)送順序接收。
關(guān)注點
- 如何檢測丟包，丟包發(fā)生后如何處置
丟包檢測與恢復
- 發(fā)送方等待合理時間偿短，若該時間內(nèi)未收到ACK,則重傳分組
可能的情況：
- 發(fā)送方發(fā)送的數(shù)據(jù)分組丟失
- 接收方發(fā)送的ACK分組丟失
- 數(shù)據(jù)分組或ACK分組傳輸?shù)臅r延過長
冗余
- 接收方發(fā)送的ACK分組丟失會引發(fā)發(fā)送方重傳欣孤，其結(jié)果是接收方收到冗余數(shù)據(jù)分組
- 發(fā)送方發(fā)送的數(shù)據(jù)分組傳輸時延過長會引發(fā)發(fā)送方重傳，其結(jié)果是接收方收到冗余數(shù)據(jù)分組
- 接收方發(fā)送的ACK分組傳輸?shù)臅r延過長會引發(fā)發(fā)送方重傳昔逗，其結(jié)果是發(fā)送方收到冗余ACK
以上冗余狀況都可以依靠分組編號機制解決
狀態(tài)機
發(fā)送方.png
分析
Rdt 3.0能夠正確工作降传，但性能很差
原因在于停等機制，大部分的時間發(fā)送方都在等待對上一個分組的確認
由于停等機制勾怒，信道上的分組幾乎不可能亂序婆排，故rdt3.0是可以實際工作的，問題在于效率過低
