運輸層(二)可靠數據傳輸原理

前言：

來源於《計算機網絡自頂向下方法》，承接上回UDP協議，不可靠的數據傳輸協議，這回來到了可靠數據傳輸協議，意味着來到了衆所周知的TCP協議了，但是沒這麼快，先了解一下可靠數據傳輸原理。其實是因爲篇幅太長=。= 跟tcp分開兩篇寫了

可靠數據傳輸原理

經完全可靠信道的可靠數據傳輸：rdt1.0

它基於完全可信的信道來傳輸數據，傳輸的過程中不會出現比特錯誤或者丟包，在這個簡單的協議中，一個單元數據和一個分組沒差別，而且所有分組都是從發送方流向接收方，有了可靠通道，接收方不必提供任何反饋信息給發送方擔心出錯。
下圖表示了在底層信道完全可靠的情況下，分別對應於發送方和接收方的有限狀態機定義：

rdt 的發送端
只通過 rdt_send(data) 事件接收來自較高層的數據發送請求。在完成一次數據發送請求中需要兩個動作：

• 產生一個包含該數據的分組（經由 make_pkt(data) 產生）
• 然後將該分組通過 udt_send(packet) 發送到信道中

完成這兩個動作後，重新返回原始狀態，繼續等待來自較高層的數據發送請求。

接收端，rdt 通過 rdt_rcv(packet) 事件從底層信道接收一個分組。在一次數據接收過程中同樣需要兩個動作：

• 從分組中取出數據（經由 extract(packet, data) 產生）
• 然後將數據上傳給較高層（通過 deliver_data(data) 動作）

經具有比特差別信道的可靠數據傳輸：rdt2.0

由於具有比特差別，那麼我們需要解決的問題就是如何讓發送方知道哪些內容被正確接受，哪些內容接受有誤，並因此需要重複發送。利用口述報文協議使用肯定確認(ACK)與否定確認(NAK)來解決該問題，在計算機網絡中，基於這種重傳機制的可靠數據傳輸協議稱爲自動重傳請(Automatic Repeat Request, ARQ)協議
ARQ協議中還需要另外三種協議功能要處理存在比特差別的情況

• 差錯檢測
  需要一種機制以使接收方檢測到何時出現比特差別，如udp使用因特網檢驗和字段正是爲了這個目的，這些技術要求有額外的比特從發送方發送到接收方，而這些比特將存放在 rdt 2.0 數據分組的分組檢驗和字段中。
• 接收方反饋
  發送方要了解接受方情況，唯一途徑就是讓接收方提供明確的反饋信息給發送方，在口述報文情況下回答“肯定確認”（ACK）或者“否定確認”（NAK），類似的我們的rdt2.0需要從接收方向發送方會送ack與nak分組，理論上這些分組只需要一個bit長度，用0表示nak，1表示ack
• 重傳
  接受方收到有差別的分組時，發送方將重傳該分組文。

下圖爲rdt2，0分別對應於發送方和接收方的有限狀態機定義：
發送端(等待上層傳下來數據)：

• 當rdt_send(data)事件出現，發送方將產生一個包含待發送數據的分組，帶有檢驗和
• 經過udt_send(sndpkt)操作發送該分組。隨後進入等待接收方的ack/nak分組狀態

發送端(等待接收方的ack/nak分組狀態)

• 收到一個ack分組(rdt_rcv(rcvpkt)&&isACK(rcvpkt)),則發送方知道最近發送的分組已經被正確接受，因此協議返回等待上層傳下來數據狀態
• 收到一個nak分組，則該協議重傳上一個分組並等待接受ack/nak分組的狀態
  注意：當發送方處於等待接受ack或者nak的狀態時，它不能從上層獲取更多數據。即當前狀態不是等待上層傳下來數據狀態。
  因此，發送方將不會發送一塊新數據，除非發送方確信接收方已正確接收當前分組）由於這種行爲，rdt2.0這樣的協議被稱爲停等協議。
  但rdt2.0協議存在這一個致命的缺陷：忽略了ack或者nak分組受損的肯能行。
  rdt2.1協議對此的解決方案是在數據分組中新增一個新的字段，讓發送方對其數據分組編號。即將發送數據分組的序號放在該字段。接收方只需檢測需要即可確認收到的分組是否是一次重新傳送。(接收到的分組序號與最近收到的分組號是否相等，相等則是一次重傳)，**發送端知道所接收到的 ACK 和 NAK 分組（無論是否受損）都是爲響應其最近發送的數據分組而生成的。**所以ack和nak分組則不需要指明他們要確認的分組序號
  是 rdt 2.1 發送端的有限狀態機描述圖：
  
  現在的狀態數是以前的兩倍，是因爲協議的狀態必須反映出目前（由發送端）正發送的分組或（在接收端）希望接收的分組序號是 0 還是 1。
  總結 解決ack受損的場景：就是發送端有兩種序號0、1，接收端也是有兩種序號0、1，
• 一開始發送端0發送分組後，轉化爲等待序號爲0的ack，nak分組的狀態
• 接收端0收到分組後轉化爲接收端1，期待接受序號爲1的分組，會送了一個ack報文給發送端
• 此時ack報文受損，則發送端選擇了重新傳送一個序號爲0的分組
• 接收端此時期待接受的是序號爲1的分組，所以發送一個ack給發送端
• 發送端此時轉化爲需要爲1，發送下一個分組。

rdt2.2
但是如果不發送 NAK，而是對上次正確接收的分組發送一個 ACK，也能實現與發送 NAK 一樣的效果。發送端接收到對同一個分組的兩個 ACK（即接收冗餘ACK）後，就知道接收端沒有正確接收到跟在被確認兩次的分組後面的分組。這就是 rdt 2.2 可以取消 NAK 分組的原因。

經具有比特差錯的丟包信道的可靠數據傳輸：rdt3.0

有很多可能的方法用於解決丟包問題，在這裏，我們讓發送端負責檢測和恢復丟包工作。假定發送端傳輸一個數據分組，該分組或者接收端對該分組的 ACK 發生了丟失。在這兩種情況下，發送端都收不到應當到來的接收端的響應。所以，如果發送端願意等待足夠長的時間以確定該分組缺失已丟失，則它只需要重傳該數據分組即可。

上圖是 rdt3.0 發送方的 FSM 圖，就拿右上角的狀態舉例，此時發送端等待接收方返回的帶有“0”序號的 ACK ，它有三種行爲：
倒計時定時器：規定時間內，若無反饋，則重傳

• 第一種：過程中未丟包，但是數據比特出錯或者不符合序號，和我們討論過的 rdt2.2 差不多，但是此時無需做處理，只需要等到時間間隔一到，當做超時處理，重發數據
• 第二種：是真正的丟包了，所以時間一到，重新發送分組。
• 第三種最理想：啥事沒有，一切正常，跳到下一個狀態，等待發送下一個包

爲了實現基於時間的重傳機制，需要一個倒計時計時器，在一個給定的時間量過期後，中斷髮送端。因此發送端需要能做到：

• 每次發送一個分組（包括第一次分組和重傳分組）時，便啓動一個定時器
• 響應定時器中斷（採取適當的動作）
• 終止定時器

現在 rdt 3.0 已經是一個功能正確的協議，但因爲它的本質仍然是停等協議。

總結：

歸納一下可靠數據傳輸協議的要點：檢驗和、序號、定時器、肯定和否定確認分組。