計算機網絡學習（五）傳輸層 Ⅱ

正在學習計算機網絡課程，以下是學習《計算機網絡-自頂向下方法》的一些筆記，部分圖片來自mooc網 哈爾濱工業大學 計算機網絡課程：https://www.icourse163.org/course/HIT-154005。

1.可靠數據傳輸原理

1.1 可靠數據傳輸原理概述

• 何爲可靠？——不錯、不丟、不亂
• 可靠數據傳輸協議 （reliable data transfer protocol，rdt）
  • 框架：
    
  • 爲上層實體提供的服務抽象是（如圖a）：數據可以通過一條可靠的信道進行傳輸。 藉助於可靠信道，傳輸數據比特就不會受到損壞 (由 0 變爲 1 ，或者相反)或丟失，而且所有數據都是按照其發送順序迸行交付。 這恰好就是 TCP 向調用它的因特網應用所提供的服務模型。
  • 由於可靠數據傳輸協議的下層協議也許是不可靠的（如圖b），因此這是一項困難的任務。 例如， TCP 是 在不可靠的( IP) 端到端網絡層之上實現的可靠數據傳輸協議。
  • 可靠數據傳輸協議基本結構：接口
    • rdt_send()：被上層應用調用，將數據交給 rdt 以發送給對方
    • udt_send()：被 rdt 調用，在不可靠信道上向接收方傳輸數據
    • rdt_rcv()：當數據包到達接收方信道時被調用
    • deliver_data()：被 rdt 調用，向上層應用交付數據
  • 在本節中，我們僅考慮單向數據傳輸 ( unidirectional data transfer) 的情況，即數據傳 輸是從發送端到接收端的。 可靠的雙向數據傳輸 (bidirectional data transfer) (即全雙工數據傳輸)情況從概念上講不會更難，但解釋起來更爲單調乏味。

1.2 rdt 1.0：可靠信道的可靠數據傳輸

• 從最簡單的情況開始考慮，即底層信道是完全可靠的。 我們稱該協議爲 rdt1. 0
• 底層信道是完全可靠：
  • 不會發生錯誤
  • 不會丟棄分組
• 發送方和接收方的**有限狀態機( Finite-State Machine, FSM)**是獨立的：
  
• 在這個簡單的協議中，一個單元數據與一個分組沒差別。 而且，所有分組是從發送方流向接收方；有了完全可靠的信道，接收端就不需要提供任何反饋信息給發送方。

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

• 在分組的傳輸、傳播或緩存的過程中，這種比特差錯通常會出現在網絡的物理部件中
• 我們眼下還將繼續假定所有發送的分組(雖然有些比特可能受損)將按其發送的順序被接收
• 如何檢測錯誤？——利用校驗和檢測位錯誤
• 如何從錯誤中恢復？——基於重傳機制的可靠數據傳輸協議：自動重傳請求( Automatic Repeat reQuest, ARQ) 協議 ，具體的機制：
  • 確認機制（Acknowledgements，ACK）：接收方顯示地告訴發送方分組已經正確接收
  • NAK：接收方顯示地告訴發送方分組有錯誤
  • 發送方收到NAK後，重傳分組
• 發送方和接收方的FSM:
  
• 注意，發送方將不會發送一塊新數據除非發送方確信接收方已正確接收當前分組。像 rdt 2.0 這樣的協議被稱爲停—等( slop-and-waü) 協議。
• rdt 2.0 也並非完美，它存在一個致命的缺陷。 那就是 ACK 或 NAK 分組也可能受損！，怎麼解決？—— rdt 2.1

1.4 rdt 2.1：接收方，對應 ACK/NAK 受損

• 如果一個 ACK 或 NAK 分組受損，則發送方無法知道接收方是否正確接收了上一塊發送的數據，解決辦法？
  • 爲 ACK/NAK 增加校驗和，當發送方收到含糊不清的 ACK 或 NAK 分組時，只需重傳當前數據分組即可。
  • 然而，這種方法在發送方到接收方的信道中引人了冗餘分組問題。
  • 冗餘分組的根本困難在於接收方不知道它上次所發送的 ACK 或 NAK 是否被髮送方正確地收到。因此它無法事先知道接收到的分組是新的還是一次重傳 ! 解決辦法？—— 序列號
• 序列號（sequence number）：在數據分組中添加一新字段，讓發送方對其數據分組編號，即將發送數據分組的序號放在該字段。
  • 接收方只需要檢查序號即可確定收到的分組是再一次重傳
  • 幾乎所有現有的數據傳輸協議中，包括 TCP，都採用了這種方法
  • 對於停等協議這種簡單情況， 1 比特序號就足夠了：因爲它可讓接收方知道發送方是杏正在重傳前一個發送分組（接收到的分組序號與最近收到的分組序號相同），或是一個新分組（序號變化了，用模 2 運算"前向"移動）
  • 因爲目前我們假定信道不丟失分組。ACK 和 NAK 分組本身不需要指明它們要確認的分組序號。 發送方知道所接收到的 ACK 和 NAK 分組（無論是否是含糊不清的）是爲響應其最近發送的數據分組而生成的
• rdt 2.1 的發送方 FSM：
  
• rdt 2.1 的接收方 FSM：（corrupt：已變換的; 有缺陷的; 有錯誤的）
  

1.5 rdt 2.2：無 NAK 確認消息

• 真的需要兩種確認消息（ACK+NAK）嗎？—— rdt 2.2
  • 不發送 NAK ，而是對上次正確接收的分組發送一個 ACK（在 ACK 消息中顯示地加入被確認分組在序列號）
  • 發送方接收到對同一個分組的兩個 ACK ，就知道接收方沒有正確接收到跟在被確認兩次的分組後面的分組
  • 發送方收到重複的 ACK 後，同樣重傳當前分組
• rdt2. 1 和 rdt2.2 之間的細微變化在於，接收方此時必須包括由一個 ACK 報文所確認的分組序號，發送方和接收方的FSM片段如下：
  

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

現在假定除了比特受損外，底層信道還會丟包，這在今天的計算機網絡(包括因特 網)中並不罕見。那麼，怎樣檢測丟包以及發生丟包後該做些什麼？

• 在 rdt 2.2 中已經研發的技術，如使用檢驗和、序號、 ACK 分組和重傳等，使我們能給出後一個問題的答案，那麼如何檢測丟包呢？
• 讓發送方負責檢測和恢復丟包工作，當分組或者接收方對該分組的 ACK 發生了丟失時，發送方都收不到應當到來的接收方的響應。
• 發送方等待合理的時間（需要倒計時定時器，countdown timer），每發送一個分組(包括第一次分組和重傳分組)時，便啓動一個定時器。如果到時間了也沒收到 ACK，則重傳。
  • 注意，如果分組或 ACK 只是經過一個大的延遲而非丟失，發送方可能會重傳該分組， 這就在發送方到接收方的信道中引人了冗餘數據分組。幸運 的是，由 rdt 2.2 協議已經有足夠的功能(即序號)來處理冗餘分組情況。
• rdt 3.0 發送方的FSM（接收方略）：
  
• 因爲分組序號在 0 和 1 之間交替，因此 rdt 3.0 有時被稱爲比特交替協議（alternating- bit protocol） 。