計算機網絡知識點總結1：可靠數據傳輸原理

1、首先，什麼是可靠的數據傳輸？

不錯（沒有比特差錯），不丟（丟包），不亂（按序到達）

2、而後一步步從0來構建這個可靠數據傳輸協議，看看他是怎麼造成的。

3、構建前的約定：

1.用rdt表示可靠數據傳輸協議。

2.由於這裏討論的理論適用於通常的計算機網絡，而不僅是傳輸層，因此採用名詞「分組」而不是傳輸層的「報文段」。

3.用「有限狀態機」（FSM）來描述接受方和發送方的圖。（有限狀態機：即表示有限個狀態以及在這些狀態之間的轉移和動做等行爲的數學模型，簡單理解爲一種畫圖方法）

4、開始構建

1.rdt1.0版本（假設底層信道是徹底可靠的，底層是不丟不錯不亂的）

這種狀況最簡單，也是最理想的。那麼直接拿着數據往下傳或者往上傳就好啦。有限狀態機描述以下：

原英文版：

中文版：

2.rdt2.0版本（底層信道再也不徹底可靠，出現比特差錯/受損）

*那麼對於受損的分組，將要進行重傳。基於這樣重傳機制的可靠數據傳輸協議稱爲自動重傳請求（ARQ）協 議。

*ARQ協議中還須要另外三種協議功能來處理比特差錯的狀況：

1.差錯檢測。簡單來講，就是須要一種機制使接收方能檢測到出現了差錯。相似UDP校驗和，這種機制 須要額外的比特，這些額外的比特放在rdt2.0數據分組的分組校驗和字段中。

2.接收方反饋。接收方得告訴發送方，他是否接受到了正確分組。rdt2.0中接受到正確的就發ACK分組， 錯誤的就發NAK分組，理論上只須要一個比特1表示ACK，0表示NAK.

3.重傳。接到NAK重傳該分組。

*有限狀態機(FSM)以下（英文不明白能夠對比rdt1.0中英文）：

*像這種接收到ACK才能發生事件。rdt.0這樣的協議也稱爲停等協議。

3.rdt2.1(rdt2.0中存在問題，若是ACK/NAK分組損壞了怎麼辦？)

*解決方法是收到損壞的ACK/NAK分組那麼進行重傳。

*可是！不能簡單重傳，那會形成冗餘分組，接受方將不知道這究竟是新發的仍是上一個的重傳！

*那麼怎麼解決這個問題？

一個簡單方法（幾乎全部現有的數據傳輸協議中，包括TCP都採用的這個）是在分組中添加一新字段， 讓發送對分組編號。接受方根據編號就知道這是新分組仍是重傳了。

rdt2.1這種停等協議，加入0，1便可。一次髮帶0的一次髮帶1，以此往復，以此區分上一次和這一次。

*有限狀態機（FSM）以下：

4.rdt2.2(無NAK消息協議)

*咱們真的須要ACK和NAK兩種消息嗎？

不須要。ACK一種就夠了。

*如何作到？

在ACK消息中加入最後一次正確接收的序列號。

*原理

由於正常狀況此次的發送分組序號和上次相反，上次是0此次則會是1.

若是接受成功，那麼發送方接收到的ACK將與上一次序號不一樣。

若是接收失敗，那麼發送方接收到的ACK將會和上次序號同樣。這樣就觸發重傳。

*FSM（有限狀態機）以下

5.rdt3.0(底層是 有比特差錯  而且 會丟包 的信道)

rdt2.2基礎上已經解決比特差錯，實際也能夠解決發生丟包後如何處理。那麼問題的關鍵就是如何檢查丟包。

方法: 發送方等待」合理」的時間內，用倒計時定時器，

若是沒收到ACK,重傳

若是分組或ACK只是延遲而不是丟了那麼 重傳會產生重複,序號機制能處理(rdt2.2已解決)

FSM（有限狀態機）：

*由於分組序號在0 1 之間交替，所以rdt3.0有時也被稱爲比特交替協議。

*至此，咱們獲得了一個可靠數據傳輸協議！

5、後續

1.rdt3.0是一個功能正確的協議，可是由於它是一個停等協議，性能很是糟糕。

2.解決辦法是打破停等協議。不使用停等方式運行，運行發送方發送多個分組而無需等待確認

許多發送的分組能夠被當作填充到一條流水線中，故這種技術被稱爲流水線機制。

3.流水線技術對可靠數據傳輸協議可帶來以下影響：

--更大的序列號範圍

--發送方和接收方須要更大空間緩存分組

--解決流水線的差錯恢復有兩種基本方法：回退N步（GBN，滑動窗口協議的一種實現）和選擇重傳（SR）

4.滑動窗口協議

窗口:

• 容許使用的序列號範圍

• 窗口尺寸爲N:最多有N個等待確認的消息 
  滑動窗口

• 隨着協議的運行,窗口在序列號空間內向前滑動 
  滑動窗口協議有GBN和SR

4.GBN（回退N步協議），發送方看到的序號（注意！這是一次性發送的窗口狀況，全結束後，下一波繼續會有一張從新的窗口狀況，好比下面這個代表一次性最多發56個）：

*採用的累積確認的機制，若是收到的是ACK（N），表示確認到N的序列號分組均已被正確接收

*爲空中的分組設置計時器（丟包問題）

*超時Timeout(N)事件：重傳序列號大於等於N，還未收到ACK的全部分組。（這裏潛在有資源浪費問題）