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不足，比如：
- 效率太慢，由於停等方式的存在，一個包沒處理好，發送端會一直等着。
- 超時機制的時間間隔怎么確定？長了不行，太慢，短了么，又會經常有重復發包的情況。