一文帶你看可靠數據傳輸協議RDT前後三個版本的原理關係以及有限狀態機的解釋

自學計算機網絡系列，如果如果出現錯誤，還請給大佬指正。

寫在前面:這裏是小王成長日誌，一名普通在校大學生，想成學習之餘將自己的學習筆記分享出來，記錄自己的成長軌跡，幫助可能需要的人，平時博客內容主要是一些系統的學習筆記，項目實戰筆記，一些技術的探究和自己的一些思考。歡迎大家關注，你們的每一個評論點贊關注我都會仔仔細細去看的。有任何問題歡迎交流，我會盡我所能幫助大家的，共創CSDN美好環境。

---

0.引入

• 可靠數據傳輸的問題並不僅僅在運輸層出現,也會在鏈路層以及應用層出現,網絡中會出現很多"一般性問題",但可靠數據傳輸在其中尤爲重要。
• 可靠數據傳輸提供的服務：數據可以通過一條可靠的信道進行傳輸 。 藉助於可靠信道，傳輸數據比特就不會受到損壞(由 0 變爲 1 ，或者相反)或丟失，而且所有數據都是按照其發送順序迸行交付 。
• 接下來貫穿我們討論始終的一個假設是分組將以它們發送的次序進行交付，某些分組可能會丟失;這就是說，底層信道將不會對分組重排序 。
• 定義明晰：
  有限狀態機，(英語:Finite-state machine, FSM)，又稱有限狀態自動機，簡稱狀態機，是表示有限個狀態以及在這些狀態之間的轉移和動作等行爲的數學模型。接下來我們會不斷討論實現可靠數據傳輸的發送方和接收方的有限狀態機。

1. 經完全可靠信道的可靠數據傳輸: rdt 1.0

1.1) rdt1.0中的假設與兩個有限狀態機的圖例

首先假設底層信道是完全可靠的,這種情況下的協議是非常簡單的,直接上圖

• 上圖顯示了 rdt 1. 0 發送方和接收方的有限狀態機( Finile- State Machine , FSM) 的定義 。
• rdt 的發送端只通過 rdt_send ( data) 事件接受來自較高層的數據，產生一個包含該數據的分組(經由 make_pkt( data) 動作) ，並將分組發送到信道中 。
• 在接收端， rdt通過 rdt_rcv( packet) 事件從底層信道接收一個分組，從分組中取出數據(經由 extract ( packet , data) 動作) ，並將數據上傳給較高層(通過 deliver_data( data) 動作) 。

1.2) 總結

在這個簡單的協議中，一個單元數據與一個分組沒差別 。 而且，所有分組是從發送方流向接收方;有了完全可靠的信道，接收端就不需要提供任何反饋信息給發送方，因爲不必擔心出現差錯!注意到我們也已經假定了接收方接收數據的速率能夠與發送方發送數據的速率一樣’快。因此，接收方沒有必要請求發送方慢一點!

2. 經具有比特差錯信道的可靠數據傳輸: rdt 2.0

2.1) rdt2.0中的假設

在rdt 2.0中，我們假設分組中的比特可能受損（這很正常，並且通常出現在網絡的物理部件中），我們繼續假定所有發送的分組（雖然可能受損）仍按其順序被接收。

所以對於受損的分組，我們需要重傳，這就是一個計算機網絡環境中很重要的協議-自動重傳請求（Automatic Repeal reQuest , ARQ）協議（基於重傳機制的可靠數據傳輸協議）

與ARQ相配合一起處理比特差錯我們還需要另外三種協議功能:

• 1. 差錯檢測
     - 使接收方可以檢測並可能糾正分組中的比特差錯 。
     - 典型的差錯檢測和糾錯技術有UDP的檢驗和。關於檢驗和部分可以在我另一篇博客的結尾處找到，介紹了計算方式以及出現的原因。
• 2. 接收方反饋
     • 我們的rdt 2.0 協議將從接收方向發送方回送 ACK 與 NAK 分組 。 並且理論上這些分組只需要一個比特長；如用0表示 NAK ，用 l 表示 ACK。
• 3. 重傳
     • 接收方收到有差錯的分組時，發送方將重傳該分組文 。

rdt2.0中的兩個有限狀態機

發送端具有兩個狀態

• 左邊：當產生 rdt_send (data) 事件時，發送方將產生一個包含待發送數據的分組 (sndpkt) ,帶有檢驗和，然後經由 udt_send( sndpkt) 操作發送該分組 。

• 右邊：發送方協議等待來自接收方的 ACK 或AK 分組 。

  • 如果收到一個 ACK 分組(圖 中符號 rdt_rcv( rcvpkt) && IsACK( rcvpkt) 對應該事件) ，則發送方知道最近發送的分組已被正確接收，因此協議返回到等待來向上層的數據的狀態 。
  • 如果收到一個 NAK 分組，該協議重傳最後一個分組並等待戰收方爲響應重傳分組而回送的 ACK 和 NAK 。

• 我們需要注意到：發送端在等待ACK或者NAK回覆分組時不能從上層獲得更多的數據

接收端仍只具有一個狀態

• 當分組到達時，接收方要麼回答一個 ACK ，要麼回答一個 NAK ，這取決於收到的分組是再受損

  • 這會導致一個致命的缺陷- ACK或者NAK分組丟失！

• ACK或者NAK分組丟失處理的方法

  • 可能的解決辦法

    • 發送方發報詢問

      • 又要一種新的分組

    • 增加足夠的檢驗和比特，使發送方不僅可以檢測差錯，還可恢復差錯 。

      • 對於會產生差錯但不丟失分組的信道，這就可以直接解決問題 。

    • 在未接受或者ACK/NAK分組比特丟失的情況下,發送方直接重傳當前數據分組

      • 造成冗餘分組( duplicate packet)
      • 接收方不知道它上次所發送的 ACK 或 NAK是否被髮送方正確地收到。因 此它無法事先知道接收到的分組是新的還是一次重傳 !

  • 實際的解決辦法

    • 爲確認(ACK/NAK)分組中添加新的字段,對其進行編號,發送方(接收ACK/NAK)對序號進行檢查即可
    • 因此我們就有了修訂版的rdt2.1

rdt2.1中的兩個有限狀態機

發送方

• 其狀態數是2.0的兩倍

  • 因爲其需要反映出目前(由發送方)正發送的分組或(在接收方)希望接收的分組的序號是0還是1
  • 發送或期望接收 0 號分組的狀態中的動作與發送或期望接收 l 號分組的狀態中的動作是相似的;唯一的不同是序號處理的方法不同 。

• 使用的是從接收方到發送方的肯定確認和否定確認

  • 對應序號的發送NAK或者以前序號的ACK(冗餘ACK)能起到一樣的作用

• 與2.0的細微區別

  • 接收方必須包括由一個 ACK 報文所確認的分組序號(這可以通過在接收方 FSM 中，在 make_pkt()中包括參數 ACK 0 或 ACK 1來實現)
  • 發送方必須檢查接收到的 ACK 報文中被確認的分組序號(這可通過在發送方 FSM 中，在 isACKO 中包括參數 0 或 1 來實現)。

• rdt2.2發送方圖例
  

3 . 經具有比特差錯的丟包信道的可靠數據傳輸: rdt 3. 0(比特交替協議)

rdt3.0中的假設

在3.0中我們不僅假設比特會受損,並且假設底層信道也會丟包(這很正常),所以3.0中我們必須解決檢測以及處理丟包的情況
對於丟包情況的檢測以及丟包後的動作我們做如下考慮:

• 方法1: 等待一定時間未收到應收到的響應則重傳該分組

  • 確實有效

  • 應該等待的時間應該至少是發送方與接收方之間的一個往返時延(可能會包括在中間路由器的緩衝時延)加上接收方處理一個分組所需的時間 。

  • 但這種等待一定時間就重傳也可能發生問題:

    • 1.最壞情況下的最大時延是很難確定的,確定的因素很少
    • 2.可能需要等一段較長的時間
    • 3.產生冗餘數據分組( duplicate data packeL)- 我們之前提到的的序號可以處理這一問題

• 方法2:倒計數定時器(countdown timer)

  • 在一個給定的時間量過期後，可中斷髮送方 。
  • 因此，發送方需要能做到:
    • ①每次發送一個分組(包括第一次分組和重傳分組)時，便啓動一個定時器。
    • ②響應定時器中斷(採取適當的動作) 。
    • ③終止定時器
  • 這也是rdt3.0中實際採用的"檢測"丟包的方式,而我們處理丟包情況的措施,很明顯就是重傳。

rdt3.0中有限狀態機的圖例

rdt3.0中存在的問題

我們現在討論的rdt協議仍然存在一個比較嚴重的問題，效率不夠，即我們需要等到前一個報傳完並且回覆完狀態確認接收才能傳送下一個分組，這會造成很大的浪費，解決方法就是流水線！在這種模式中我們將會一次發送多個分組，在多個分組都被確認的情況下再發送接下來幾個分組，具體細節敬請期待。

4.有關文章推薦:

沒搞清運輸層的UDP協議? -哎呀, 咋來這看就好了啊

一文帶你看懂多路複用與多路分

---

都看到這裏了，各位哥哥姐姐叔叔阿姨給小王點個贊 關個注 留個言吧，和小王一起成長吧，你們的關注是對我最大的支持。
有事沒事進來看看吧 : 小王的博客目錄索引

---

如果以上內容有任何不準確或遺漏之處，或者你有更好的意見，就在下面留個言讓我知道吧-我會盡我所能來回答。