可靠數據傳輸的原理

本文轉載自查看原文 2017-05-14 18:33 6015 計算機網絡

TCP是運輸層的協議，向上層（應用層）提供面向連接的可靠的服務。而TCP的下層是網絡層，網絡層提供的盡力而為的服務，也就是說不提供任何質量保證。
那么TCP是如何在不可信信道上為上層服務提供可靠的服務呢？這里的可靠包括兩方面：

傳輸的數據比特不會受到損壞或丟失。
所有數據都是按照其發送順序進行交付的。

一、可靠服務的模型

如上圖所示，運輸層向應用層提供可靠數據傳輸服務。
運輸層通過rdt_send()函數，調用數據傳輸協議，把數據交付給接收方的運輸層。發送方的運輸層調用udt_send()函數，將分組發送到不可靠的信道。
在接收端，當分組從信道的接收端到達時，將調用rdt_recv()。當rdt協議向較高層交付數據時，調用deliver_data()完成。

二、構造可靠的數據傳輸協議

我們將一步步地研究一系列協議，最后得到一個無錯、可靠的數據傳輸協議。

1 經過完全可靠信道的可靠數據傳輸： rdt 1.0

上圖是發送方和接收方的有限狀態機，底層信道是完全可靠的。發送方和接收方各只有一個狀態。
圖中的箭頭指示了協議從一個狀態變遷到另一個狀態。引起變遷的事件在橫線上方，事件發生時所采取的動作顯示在橫線下方。 FSM的初始狀態由斜線表示。

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

底層信道肯定不是完全可靠的，下面我們考慮分組中的比特可能受損，但仍假設所有發送的分組將按其發送的順序被接收。
接收方收到分組以后，可以向發送方發送肯定確認 (ACK) 或否定確認 (NAK) 。這些控制報文可以讓發送方知道哪些內容被正確接收，那些內容接收有誤並因此需要重復。這種基於重傳的可靠數據傳輸協議被稱為自動重傳請求 (Automatic Repeat reQuest, ARQ) 協議。
ARQ協議需要三個功能來處理分組出錯的情況：

差錯檢測
接收方需要檢測到何時出現了比特差錯。原理是通過增加發送方的冗余，如CRC校驗等。
接收方反饋
接收方可以發送“肯定確認”或“否定確認”。
重傳
接收方收到有差錯的分組時，重傳該報文。

如上圖所示，發送方有兩個狀態。
當處於左邊狀態時，發送方等待來自上層傳下來的數據。當上層調用rdt_send()函數時，發送方產生帶有校驗和的分組，然后經由udt_send()發送到到不可靠信道上。
在右邊狀態中，發送方等待接收方的ACK或NAK。如果收到ACK，那么發送方知道最近一個分組已經被正確接收，因此協議返回左邊狀態。如果收到NAK，那么發送方重傳最近一個分組並等待接收方的ACK或NAK分組。
在上述協議中，當發送方處於等待ACK或NAK狀態時，它不能從上層獲得更多數據。這樣子的協議被稱為停等協議 (stop-and-wait)。
rdt2.0協議有一個致命的弱點，即沒有考慮到ACK或NAK分組受損的可能性。
如果一個ACK或NAK受損，那么發送方無法判斷接收方是否正確接收了上一個發送的分組。
處理受損的ACK或NAK的三種方法：
1. 增加控制信令。
  即發送方請求接收方重復ACK或NAK分組。但新的控制信令也可能受損。
2. 增加足夠的校驗和比特
  使發送方不僅可以檢測差錯，還可以恢復差錯。對於會產生差錯卻不會丟失分組的信道，可以直接解決問題。
3. 重傳當前數據分組
  發送方收到損壞的ACK或NAK分組時，重傳當前數據分組。這種方法在信道中引入了冗余分組 (duplicate packet)。這導致接收方不知道接收到的分組是新數據分組的還是一次數據重傳。
  解決這個問題的方法是在所有數據分組中引入一個字段對數據分組編號，叫做序號 (sequence number) 。接收方只需要檢查序號即可確定收到的分組是否是數據重傳。對於停止等待這種情況，只需要 1 比特序號就夠了。
  我們把引入序號的協議稱為rdt 2.1，其發送方FSM圖如下。
協議rdt 2.1使用了肯定確認和否定確認。當接收到正確的分組時，接收方發送一個“肯定確認”，當接收到受損的分組時，發送一個“否定確認”。
如果不發送NAK，而是對上次正確接收的分組發送一個ACK，也可以實現一樣的效果。發送方如果接收到兩個一樣的ACK，就說明接收方沒有正確接收到跟在被確認兩次的分組后面的分組。
我們把只使用ACK的協議稱為rdt 2.2，其FSM圖如下。

3 經具有比特差錯的丟包信道的可靠數據傳輸： rdt 3.0

現在假定除了比特受損以外，底層信道還會丟包，這是一個常見的現象。
有很多可能的方法可以解決丟包問題，這里我們讓發送方負責檢測和恢復丟包工作。
假定發送方傳輸一個數據分組，該分組或者接收方對該分組的ACK發送了丟失。這兩種情況下，發送方都收不到應當到來的接收方的響應。如果接收方願意等待足夠長的時間以便確認分組丟失，那么只需要重傳該數據分組即可。
發送方需要等待多久來確認已經丟失了這個分組呢？很明顯發送方應該至少等待發送方和接收方之間的一個往返時延和接收方處理一個分組的時間。
從發送端的觀點來看，重傳是一個萬能靈葯。為了實現基於時間的重傳機制，需要一個倒數計時器 (countdown timer)，在一個給定的時間量過期之后，可中斷發送方。發送方需要做到：1）每次發送一個分組時，就啟動一個定時器；2）相應定時器中斷；3）終止定時器。
下圖是rdt 3.0的發送方FSM，該協議運行在可能發生出錯和丟失的信道上。