Rdt2.1 和 Rdt2.2的詳細解釋
Rdt2.1 和 Rdt2.2的詳細解釋
🌵可靠數據傳遞中Rdt1.0, Rdt2.0, Rdt3.0 都很好理解，但是就是這兩個毒瘤一直在我腦袋裡面刺痛著我，經過一段時間的總結，我相信我能給大家一個比較好理解的解釋。
這倆為啥會出現？
既然大版本好是2.0，我們可以回憶一下2.0階段做了什麼事情
Rdt2.0中增加了檢驗糾錯的結構，也就是應答。
sender –>> receiver: 發送消息（備註：你看看對不對？）(跳轉到等待態)
receiver –>> sender: 啊對對對，這玩意是我想要的(receiver驗貨，正常ACK返回)
sender –>> sender: 爺終於放心了，可以發下一個了(狀態回溯到初始狀態)
receiver –>> sender: 不對啊，我不收(異常NAK)
sender –>> receiver: 重發
按理來說這個過程非常自然啊，receiver檢驗，sender等待，整個流程走完了，數據也發出去了，如果數據異常，sender也能夠重發，但是問題就在於，如果象徵著異常數據的標誌NAK也錯了，象徵著正常數據的ACK也錯了，sender該如何判斷？？？？它唯一的相信的東西沒了！！這個流程自然說不通了。
上述流程要完美髮生就必須要求ACK,NAK絕對不能出錯
可以事實上，非常容易出錯，好在我們還是有解決辦法的
解決之道
書中給出了三條解決之道：
- 通過另外的響應規則來應對突發情況，但是這個策略很明顯有問題，如果另外的響應也錯了怎麼辦？，所以書中沒有考慮這個策略
- 加一堆校驗碼，讓NAK，ACK擁有自我救贖的能力（自己把自己糾正過來，即使錯了），可行，但是划不來，新的校驗數據無疑會增大報文的體積，減低傳輸的效率
- 冗餘報文響應（這個名字是我按照我的理解起的，建議以書為標準 – 重發）：故名思義
graph LR
ACK不合法 –> 重發
NAK不合法 –> 重發
NAK拒絕 –> 重發
重發 –> 直到格式合法了數據正常了
Rdt 2.1
從發送端入手，虛線部分：
發送端先是不管三七二十一把數據封裝起來了，然後填上了0標誌位和校驗和發送到發送端，自己進入等待狀態。
此時接收到來自發送端的數據，接收端也從等待狀態進入到wait for 1 from below, 並且向發送發拋出了一個數據，內部有ACK，表示接受
如果接收方接受到了這個完整的ACK，那麼就是Rdt2.0的節奏了，這裡假設ACK錯了，不合法，由於接收方接收到了一個不合法的數據，那麼自然就重發
此時接收方還在等待1狀態，一檢查，發現發送發又給我發了一份數據，那我沒辦法啊，只能又發一個ACK回去，
如此往複直到發送方接收到數據之後，狀態轉移，向接受發發送了一個帶有1的報文，若接受方也能接受，那麼就皆大歡喜了
接受方和發送方都回到了最初狀態了，一次傳遞結束了！！！
很容易不是嗎？
注意點：發送發和接收方都在考驗彼此，一旦對面的數據給的不合法，或者發現了錯誤，就會通知對方，讓對方重發一次，直到雙方通訊完成，狀態回到初始態時候終止。
也許你會問，那這種等待，想Rdt2.0 那樣不是也行嗎？為啥得這樣做呢，這麼多狀態，不會眼花嗎？
其實這兩個狀態是有道理的，
Rdt2.0 中接受方只有一個狀態，就是初始態，但是初始態無法辨識當前接收方是否出現了問題，所以必須給接收方多安排一個狀態。
如此發送方也必須調整一下，
發送方從 0 – 1 – 0
接收方也從 0 – 1 – 0
當其中一方或者幾方處於1狀態時，必然意味著出現了意外狀況，就可以實現干預了。
Rdt2.2
Rdt2.2 的思想與Rdt2.1 是相同的，只是簡化了步驟，其實根本不需要發NAK，只需要發ACK，區別在於帶上不同的標誌以區分不同的階段
NAK –> ACK_0
NAK不合法
ACK –> ACK_1
如此就簡化了既要判斷ACK，又要判斷NAK的複雜場面，
只要報文不合法就重發，只要ACK 帶的值不是我想要的，你也得給我重發！！
