計算機網路————可靠性資料傳輸過程（rdt1.0 /rdt2.0 /rdt2.1 /rdt2.2 /rdt3.0）
rdt1.0
將資料的傳輸通道理想化，視為完全可靠，不丟包，不損失bit ，在這樣的情況下，傳送端傳送資料，接收端直接接收，並不考慮丟包，超時這些問題。
該協議中，都是直接傳送，直接接收。
rdt2.0
" 在 rdt2.0 中，我們將傳輸通道視為有可能發生位元錯誤 "
引進使用差錯檢測：檢驗發過來的包有沒有錯誤 （校驗和）——判斷決定是否重傳
接收方的反饋：接收方返回 NAK 或者 ACK ，分別對應資料錯誤和資料正確，這個也可以理解，總要告訴傳送端，你發過來的是對還是錯。
（假設：接收方收到資料A無誤，向傳送方傳遞ACK,返回值中途原值ACK →NAK。傳送方認為資料A無誤，立即進入下一個狀態。但是接收方一直等待發送方重傳資料A.）
rdt2.1
"發現了 rdt2.0 的致命缺陷，原來接收端返回的值也可能會出錯啊，萬一NAK出錯變成ACK（位元翻轉）了呢?"
該協議在 2.0 基礎上增加了一個序號值（在這裡，該序號在當前協議中只使用 0 和1 ，交替排列），這樣一來，傳送端和接收端都有了兩種序號狀態， 0 和 1 。
傳送端在 0 序號時傳送資料包，接收端此時期待 0 序號的資料包。如果資料傳送時發生 bit (位元)受損，此時接收端直接通過檢驗和發現錯誤，並返回 NAK ，傳送端接到 NAK 的返回值，然後重新發送 0 序號資料包。（但是注意，這完全和 rdt2.0 沒有任何分別，這是一種理想的狀態！！！）
接收端成功接收，但是返回 ACK的時候發生了bit（位元）翻轉，變成了 NCK ，這才是我們討論的重點！！接下來，我需要畫一張圖，來理清楚當返回錯誤的時候，怎麼通過序號來判斷並重傳資料。 )
rdt2.2
需要返回 NAK , ACK 兩種狀態可能太麻煩了，就將其全部改為ACK 只是返回的時候順便返回序號。
接收端收到包，不管正確與否，都返回 ACK ，同時附上序號，這個序號嘞，就是資料包傳送過來時的序號。另外的參照上圖，相信同學們都能有所收穫。
rdt3.0
上圖是 rdt3.0 傳送方的 FSM 圖，就拿右上角的狀態舉例，此時傳送端等待接收方返回的帶有“0”序號的 ACK ，它有三種行為：
倒計時定時器：規定時間內，若無反饋，則重傳
第一種：過程中未丟包，但是資料比特出錯或者不符合序號，和我們討論過的 rdt2.2 差不多，那麼此時就沒有任何動作，毫無作為就好了，等到時間間隔一到，當做超時處理，重發資料。
第二種：是真正的丟包了，所以時間一到，重新發送。
第三種最理想：啥事沒有，一切正常，跳到下一個狀態，等待發送下一個包
上面我加粗了一個不符合序號。
這裡的不符合序號，與期待的序號不符，有兩種情況：
1. 接收端反饋過程中，代表序號的那個 bit 錯誤，進行了翻轉——這就和 rdt2.2 中一樣
2. 我們上面引入了超時機制，但是有一種情形，萬一我發出去的資料包並沒有丟失，只是它跑的太慢而已呢？？那麼時間一到，傳送端誤以為丟包，重新發了一遍咋辦？？這就造成，接收端才收到你晚來的資料 0 號，還給你個 0 ，這時候你重傳的 0 號包接著又到了，接收端又給你一個0 ，作為傳送端，我會先後收到兩個 0 ，就註定後面一個 0 會被期待 1 號的狀態捕捉，這時傳送端啟動第一種處理方式——不作為，啥都不做。
rdt3.0不足，比如：
- 效率太慢，由於停等方式的存在，一個包沒處理好，傳送端會一直等著。
- 超時機制的時間間隔怎麼確定？長了不行，太慢，短了麼，又會經常有重複發包的情況。