現實中，很多的信道，其實是不可靠的。
什么是可靠？不錯、不丟、不亂。
可靠數據傳輸協議
1、可靠數據傳輸對應用層、傳輸層、鏈路層都很重要
2、網絡前十大問題之一
3、信道的不可靠特性決定了rdt的復雜性
可靠數據傳輸可以從不同的角度理解，
以下是從提供的服務來看：
（a）provided service
紅線上：應用層，發送進程和接收進程
紅線下：傳輸層，提供可靠數據傳輸服務
注意，理論上底層提供的信道傳輸服務是安全可靠的，但在實現中並不是
以下是從服務的實現來看
（b）service implementation
注意，此時底層是一個不可靠的信道，unreliable channel
rdt基本結構
1、rdt_send()：單向，說明上層調用下層之后就不管了
2、udt_sen()：雙向，對於不可靠信道傳輸需要控制數據流動
3、rdt_rcv()：雙向，對於不可靠信道傳輸需要控制數據流動
4、deliver_data()：單向，說明底層接收方的傳輸協議把所有的工作做好之后，才把數據正確的交付給上層
注意，以下各rdt版本中只考慮單向數據傳輸，但控制信息是雙向流動的，
並且，利用狀態機FSM（狀態、事件、活動，狀態在圓圈里，事件在線上，活動在線下）刻畫傳輸協議
rdt1.0可靠信道上的可靠數據傳輸
注意，由於100%可靠，所以，只需發，無需控制，所以FSM有限狀態機獨立
rdt2.0產生位錯誤bit error的信道（只有該因素）
底層信道可能產生位錯誤
問題：接收方要知道收到分組錯沒錯？如果錯了得想辦法重傳？或者恢復？
解決：告訴接收方，合作處理
（1）檢測位錯誤：udp的校驗和方法
（2）從錯誤中恢復
ACK：acknowledgements
NAK：NegativeAcknowledgment
注意，基於上述（1）和（2）的重傳機制的rdt協議稱為ARQ（Automatic Repeat reQuest）
rdt2.0引入的新機制：差錯檢測（1）、接收方反饋控制信息（2）、重傳（2）
FSM：
注意，發送方一個狀態wait for call from above不夠了，需要加一個等待對方（接受方）控制消息的狀態wait for ack or nak；另外，在接收方仍為一個狀態，但是增加了一個事件，判斷收到的是否分組發生錯誤，可以使用udt_send(NAK)或者udt_send(ACK)發送給發送發
rdt2.1、2.2
rdt2.1：
發現rdt2.0的缺陷：當ACK或者NAK出錯發送方是無法處理的，
因此加入新的機制，那就是序列號機制。
rdt2.2：
將NAK去掉（不需要），用ACK確認最后的一個分組，可以代替它
rdt3.0信道既會發生錯誤，也可能會丟失分組
當發送的過程中丟包了，發送方則一直等待和接收方沒有反應
當發送方發送的數據到了接收方，發過來的ACK丟了
...