流水線可靠數據傳輸協議
如上篇文章所述所述的rdt3.0協議是一個功能正確的協議，但是因為它是停止等待協議，所以它的的性能並不高。它對信道的利用率十分低，為解決這個問題的簡單方法便是：不使用停等方式運行，允許發送方發送多個分組而無需等待確認。
采用流水線技術對可靠數據傳輸也產生了一些影響：
- 必須增加序號范圍，因為每個輸送中的分組（不計重傳的）必須有一個唯一的序號，而且也許有多個在輸送中未被確認的報文。
- 協議的發送方和接收方兩端也許必須緩存多個分組。
- 所需序號范圍和對緩沖的要求取決於數據傳輸協議如何處理丟失、損壞及延時過大的分組。解決流水線差錯恢復的兩種基本辦法是：回退N步（Go-Back-N,GBN）和 選擇重傳（Selective Repeat,SR）。
回退N步（GBN）
在GBN協議中，允許發送發發送多個分組（當有多個分組可用時）而不需要等待確認，但是它受限於流水線中為確認分組數不能超過某個最大允許數N。可操作此處的GBN Java小程序查看GBN運作過程。
下圖（來自《計算機網絡 自定向下方法》）顯示了發送方看到的GBN協議的序號范圍。
base代表最早的未確認的分組，nextseqnum代表最小的未使用的序號（即下一個待發分組序號）。
序號范圍可以分成四段，[0,base-1]段內的序號對應於已經發送並被確認的分組，[base,nextseqnum-1]代表已被發送但未被確認的分組，[nextseqnum,base+N-1]段內的序號能用於那些即將要被發送的分組，最后大於等於base+N的序號是不能被使用的
那些已被發送但還未被確認的分組的許可序號范圍可以被看成是一個在序號范圍長度為N的窗口。
隨着協議的進行，搞窗口序號空間向前滑動。因此，N常被稱為窗口長度（window size）,GBN協議也被稱為滑動窗口協議（sliding-window protocol）。
在此我們限定的窗口長度N，而不是讓分組數為無限大是有兩個原因①流量控制②TCP擁塞控制
如果分組序號字段的比特數為k,那么序號范圍就是[0,2^k-1],在一個有限的序號范圍內，所有涉及序號的運算必須使用模2^k運算。
GBN發送方必須響應三種類型的事件：
-
上層的調用
當上層調用分組發送時，發送方首先檢查發送窗口是否已滿，即是否含有N個已發送但是未被確認的分組。如果窗口未滿，則產生一個分組並將其發送，並更新相應變量。如果窗口已滿，發送方只需將數據返回給上層，隱式指示上層該窗口已滿。然后上層可能過一會兒在試試。在實際實現中，發送方可能會緩存這些數據，或者使用同步機制允許上層在僅當窗口不滿是才調用分組發送。 -
收到一個ACK
在GBN協議中，對序號為n的分組采用累積確認(cumulative acknowledgment)方式，表明接收方已正確接收到序號為n的以前且包括n在內的所有分組。 -
超時事件
協議的名字“回退N步”源於出現丟失和時延過長的分組時發送方的行為。
發送方采用一個定時器，可作為最早發送但未被確認的分組的定時器。如果收到一個ACK，但是仍有已發送但是未被確認的分組，定時器被重新啟動。如果沒有已發送但是未被確認的分組，該定時器被終止。
GBN的接收方
如果一個序號為n的分組被正確接收並且是按序的，接收方為分組n發送一個ACK，並將該分組的數據部分交給上層。其他情況，發送方丟棄該分組，並未最近按序接收的分組重新發送ACK。
接收方丟棄所有失序分組。分組n丟失，發送發會重傳分組n以及分組n后面的分組，接收方不必緩存失序分組后面的分組。接收方需要維護下一個按序接收的分組序號。
下圖為窗口長度為4的GBN協議運行情況。
在GBN協議綜合了TCP可靠數據傳輸構件時遇到的所有技術，包括使用序號、累積確認、檢驗和以及超時重傳操作。
選擇重傳
GBN也存在着一些性能問題，單個的分組出現差錯就會引起GBN重傳大量不必要重傳的分組。在信道差錯率很高時，流水線可能會被不必要重傳的分組所充斥。可操作此處SR Java小程序查看SR運作流程。
SR協議通過讓發送方僅重傳那些它懷疑在接受方出錯（丟失或受損）的分組而避免不必要的重傳。
下圖（來自《計算機網絡 自定向下方法》）顯示了SR協議中發送方和接收方的序號范圍。
在SR協議中發送方和接收方所采取得動作可見下文描述。
SR發送方的事件與動作
-
從上層接收到數據
從上層接收到數據后，SR發送方檢查下一個可用於該分組的序號。如果該序號位於發送方的窗口內，則將數據打包並發送；否則就像再GBN中一樣，要么將數據換粗，要么返回給上層以便以后傳輸。 -
超時
定時器在此用來防止丟失分組。但是，SR中每個分組都要有自己的邏輯定時器。 -
收到ACK
如果收到ACK,倘若該分組序號在窗口內，SR發送方就將那個被確認的分組標記為已接收。
如果該分組的序號等於send_base，則窗口基序號向前移動到具有最小序號的未被確認分組處。
如果窗口移動了並且有序號落在窗口內的未發送分組，則發送這些分組。
SR接收方的事件與動作
SR接收方將確認一個正確接收的分組而不管其是否按序。失序的分組將被緩存，知道所有丟失分組皆被收到為止，這時才將一批分組按序交付給上層。
-
序號在[rcv_base,rcv_base+N-1]內的分組被正確接收
在此情況下，收到的分組落在接收方的窗口內，一個選擇ACK被回送給發送方。
如果該分組以前沒有被接收到過在，則緩存該分組。
如果該分組的序號等於基序號，則該分組以及以前緩存的序號連續的分組交付給上層。
然后，接收窗口按向前移動分組的編號向上交付這些分組。 -
序號在[rcv_base-N,rcv_base-1]內的分組被正確收到
在此情況下，必須產生一個ACK,即使該分組時接收方以前已確認的分組。
要意識到這是非常重要的，假設接收方以前就接收了send_base分組，現在接收到重傳的不回送ACK，那么發送方窗口就永遠也不會向前滑動！ -
其他情況，忽略該分組
SR協議中發送方窗口和接收方窗口並不總是一致的。這會引出關於序號范圍的一個問題。
在有限的序號范圍的實現里，如果SR接收方窗口太大並且發送方和接收方窗口間的不同步，便會造成發送方這邊新分組序號與舊分組序號重復使用。導致無法辨析該序號代表的是一個新分組還是舊分組。
SR的窗口長度應限制在小於等於序號空間大小的一半。
小結一下可靠數據傳輸機制中使用到的技術:
檢驗和、定時器、序號、確認、否定確認、窗口/流水線
此文為《計算機網絡 自頂向下方法》學習筆記2