信道自己是不可靠的,可靠性傳輸就是在傳輸層在不可靠的信道基礎上實現可靠性傳輸。api
1. 數據在傳輸的過程當中有可能回受損(本文主要說明這個問題)網絡
2. 數據在傳輸的過程當中有可能回丟失(下一篇文章說明)blog
傳輸層的可靠性協議就是解決上面兩個問題的基礎
從應用層的角度來,整個傳輸是可靠的,傳輸層屏蔽了不可靠的網絡層bfc
rdt:reliable data transfer,udt:unreliable data transferim
傳輸層發佈可靠傳輸的api給應用層,可是調用網絡層的不可靠服務,經過可靠數據傳輸協議最終實現可靠傳輸。數據
問題: 數據在傳輸過程當中是受損,接收方協議
方案:停等協議(數據發出去後發送方等待發送方反饋,等反饋沒有問題後再進行下一組數據的傳輸)img
ARQ(Automatic Repeat reQuest),自動重傳,若是數據受損,則從新再傳一次。di
停等協議示意圖
實現ARQ須要實現三個功能:
初版的問題
接收方的ACK或者NAK若是有損,發送方沒法識別怎麼辦?
針對初版的問題,最簡單的辦法是:若是發送方沒法識別也直接進行重傳。
這又會引入另一個問題,接收方有可能已經正確收到了以前的數據,再次重傳回致使接收方沒法區分當前數據是從新傳送的仍是新數據。
因此須要給數據增長一個惟一標識:序列號。