前言：
來源於《計算機網絡自頂向下方法》，承接上回可靠數據傳輸的原理，rdt3.0是一個功能正確的協議，但是無論如何他都是一個停等協議，需要等待接收方迴應後，才能進行下一個分組的發送,所以它的性能不會特別的好。下面來介紹如何解決呢？
流水線可靠數據傳輸協議
這種特殊的性能問題的一個簡單解決方法是：不以停等方式運行，允許發送方發送多個分組而無需等待確認。此技術成爲流水線。
- 必須增加序號的範圍，因爲每個傳輸中的分組必須有一個唯一的序號，而且也許有多個在傳輸中的未確認報文。
- 協議的發送方和接收方雙端也不得不緩存多個分組。發送方最低限度應當緩存哪些已經發送但沒有確認的分組。接收方或許也需要緩存那些已正確接收的分組
- 所需序號範圍和對緩衝的要求取決於數據傳輸協議如何處理丟失、損壞及延時過大的分組。解決流水線的差錯恢復有兩種基本的方法：回退 N 步（Go-Back-N, GBN） 和 選擇重傳（Selective Repeat, SR）。
回退N步
在回退N步協議中，允許發送方發送多個分組，而不需要等待確認，但它受限於在流水線中未確認的分組書不能超過某個最大允許數n。
如圖所示，那些已經被髮送但還未被確認的分組的許可序號範圍可以被看成是一個在序號範圍內長度爲N的窗口，隨着協議的運行，該窗口在序號空間向前滑動。因此n常被成爲窗口長度，gbn協議也常被成爲滑動窗口協議
下圖是 GBN 協議 FSM 描述：
發送方必須響應三種類型的事件：
- 上層的調用。當上層調用 rdt_send() 時，發送方首先檢查發送窗口是否已滿，即是否有 N 個已發送但未被確認的分組。如果窗口未滿，則產生一個分組並將其發送，並相應地更新變量。如果窗口已滿，發送方只需將數據返回給上層，隱式地指示上層該窗口已滿。然後上層可能會過一會兒再試。在實際實現中，發送方更可能緩存這些數據，或者使用同步機制（如一個信號量或標誌）允許上層在僅當窗口不滿時才調用 rdt_send()。
- 收到一個ACK。在 GBN 協議中，對序號爲 n 的分組的確認採取累積確認（cumulative acknowledgment）的方式，表明接收方已正確接收到序號爲 n 的以前且包括 n 在內的所有分組。
- 超時事件。協議的名字“回退 N 步”來源於出現丟失和時延過長分組時發送方的行爲。就像在停等協議中那樣，定時器將再次用於恢復數據或確認分組的丟失。如果出現超時，發送方重傳所有已發送但未被確認過的分組。 上圖中發送方僅使用一個定時器，如果收到了一個 ACK，但仍有已發送但未被確認的分組，則定時器被重新啓動。如果沒有已發送但未被確認的分組，該定時器被終止。
接受方：
- 如果一個序號爲 n 的分組被正確接收到，並且按序（即上次交付給上層的數據是序號爲 n - 1 的分組），則接收方爲分組 n 發送一個 ACK，並將該分組中的數據部分交付到上層。
- 在所有其他情況下，接收方將丟棄該分組，併爲最近按序接收的分組重新發送 ACK。
- 注意到因爲一次交付給上層一個分組，如果分組 k 爲已接受並交付，則所有序號比 k 小的分組也已經交付。因此，使用累積確認是 GBN 的一個自然的選擇。
雖然 GBN 協議看起來很浪費，因爲它會丟棄一個正確接收（但失序）的分組。但這樣做是有道理的。因爲接收方必須將數據按序交付給上層，假設現在期望接收分組 n，而分組 n + 1 卻到了，因爲數據必須按序交付，所以接收方可能緩存分組 n + 1，然後，在它收到並交付分組 n 後，再將該分組交付到上層。但是，如果分組 n 丟失，則該分組及分組 n + 1 最終將在發送方根據 GBN 重傳規則而被重傳，所以，接收方只需要直接丟棄分組 n + 1 即可。
這種方法的優點是接收方不需要緩存任何失序分組，唯一需要維護的信息就是下一個按序接收的分組的序號。缺點就是隨後對該分組的重傳也許會丟失或出錯，進而引發更多的重傳。
選擇重傳
SR 協議在 GBN 協議的基礎上進行了改進，它通過讓發送方僅重傳那些它懷疑在接收方出錯（即丟失或受損）的分組而避免了不必要的重傳。選擇重傳協議只重傳真正丟失的分組.
序號空間圖：
發送方的事件與動作：
- 從上層收到數據。當從上層接收到數據後，SR 發送方檢查下一個可用於該分組的序號。如果序號位於發送方的窗口內，則將數據打包併發送；否則就像在 GBN 中一樣，要麼將數據緩存，要麼將其返回給上層以便以後傳輸。
- 超時。定時器再次被用來防止丟失分組。然而，現在每個分組必須擁有其自己的邏輯定時器，因爲超時發生後只能發送一個分組。
- 收到ACK。如果收到 ACK，倘若該分組序號在窗口內，則 SR 發送方將那個被確認的分組標記爲已接收。若該分組的序號等於 send_base，則窗口基序號向前移動到具有最小序號的未確認分組處。如果窗口移動了並且有序號落在窗口內的未發送分組，則發送這些分組。
接收方的事件與動作：
接收方方的事件與動作：
- 序號在 [rcv_base, rcv_base+N-1] 內的分組被正確接收。在此情況下，收到的分組落在接收方的窗口內，一個選擇 ACK 被回送給發送方。如果該分組以前沒收到過，則緩存該分組。如果該分組的序號等於接收端的基序號（rcv_base），則該分組以及以前緩存的序號連續的（起始於 rcv_base 的）分組交付給上層。然後，接收窗口按向前移動分組的編號向上交付這些分組。
- 序號在 [rcv_base-N, rcv_base-1] 內的分組被正確收到。在此情況下，必須產生一個 ACK，即使該分組是接收方以前確認過的分組。
- 其他情況。忽略該分組。
總結可靠數據運輸機制：
- 驗證和：用於檢測在一個傳輸分組中的比特錯誤
- 定時器：用於超時/重傳一個分組，可能因爲這個分組在信道中丟失了，由於當一個分組延時但爲丟失，或者當一個分組已經被接收方收到但從接收方到發送方的ack丟失時，可能產生超時事件，所以接收方可能會收到一個分組的多個冗餘副本
- 序號：用於爲從發送方流向接收方的數據分組按順序編號，所接受分組的序號間的空襲可使接收方檢測出丟失的分組，擁有相同序號的分組可使接收方檢測出一個分組的多個冗餘副本
- 確認：接收方用於告訴發送方一個分組或者一組分組已經被正確的幾首，確認報文通常攜帶着被確認的分組或者多個分組序號，確認可以是逐個的或者積累的，這取決於協議。
- 否定確認：接收方用於告訴發送方某個分組未被正確的接受，否定報文通常攜帶着未被正常接受的分組序號
- 窗口、流水線：發送方也許被限制僅發送那些序號落在一個指定範圍內的分組，通過允許一次發送多個分組但未被確認，發送方的利用率可在停等操作模式的基礎上得到增加，窗口長度可以根據接收方接受和緩存報文的能力，網絡中的擁塞成都來設置。ß