禁止碼迷，布布扣，豌豆**，碼農教程，愛碼網等第三方爬蟲**爬取！
目錄選擇重傳
參考資料
我們來考慮位元交替協議，會發現由於協議需要等待 ack，中間的等待時間內傳送端和接收端都是無所事事的。
根據分析，我們可以計算出位元交替協議的通道利用率，我們會發現這個量級是十分可憐的。而且我們還忽略了傳送方和接收方的底層協議的處理時延，還有傳送方和接收方之間任何一跳路由器的處理、排隊時延。也就是說位元交替協議雖然可以實現可靠傳輸，但是也限制了物理資源的應用。
對於這類效能問題，乙個簡單的想法是：不以停等的方式執行，允許傳送方傳送多個分組而無需等待確認。此時傳送方可連續傳送多個分組，不必每發完乙個分組就停頓下來等待對方的確認，這種手法被稱之為流水線傳輸。由於通道上一直有資料不間斷地傳送，這種傳輸方式可獲得很高的通道利用率。
引入流水線傳輸，會對已有的可靠傳輸帶來什麼影響呢？主要在於以下 3 個方面：
必須增加序號範圍，考慮到有多個正在傳輸的 ack，所以每個傳輸中的分組必須有唯一的序號；
協議的傳送方、接收方都需要快取多個分組，傳送發需要快取已傳送但是沒有收到 ack 的分組，接收方需要快取正確接收的分組(防止冗餘)，這意味著需要更大的快取空間；
流水線傳輸的差錯恢復更為複雜，2 種恢復差錯的方式為：回退 n 步、選擇重傳。
回退 n 步的手法是基於序號實現的，對於傳送方中的每個分組都會有不同的序號。流水線未確認分組的上限稱之為視窗長度(n)最早為確認分組的序號稱之為基序號(base)，最小未使用的序號稱之為下乙個序號(nextseqnum)。基於這 2 個序號就可以把分組切割為 4 個部分，[0,base-1]是已經傳送並被確認的分組，[base,nextseqnum - 1]是已經傳送但未被確認的分組，[nextseqnum ,base + n - 1]是分組可以利用的序號，base + n 以上的序號是不可用的。
已傳送但還未被確認的埠的序號範圍，可以被抽象為乙個長度為 n 的視窗，因此 gbn 協議也被稱之為滑動視窗協議。隨著協議的執行，視窗在序號空間內向前滑動。
對於 gbn 的傳送方而言，需要對以下 3 種情況做出相應。首先是需要傳送資料的時候，傳送方首先檢查傳送視窗是否已滿，若視窗未滿就產生乙個分組並傳送，然後自增變數。如果視窗已滿，則傳送方需要提示上層視窗已經滿了，請上層貴一會兒再嘗試。
接著是收到 ack的時候，gbn 協議對序號為 n 分組的確認方式是累積確認。因為傳送方收到的不一定是基序號對應的 ack，累積確認支援一次性確認序號 n 及 n 之前所有序號的分組，然後進行「視窗滑動」。
第三是遇到超時事件時，首先需要重啟定時器，然後傳送方要重傳所有已傳送但未確認的分組。這也是所謂的「回退 n 步」的具體實現，就是只要未確認就全部重傳。這種方式是否會帶來資源浪費的問題？
如果乙個序號為 n 的分組被正確接收，並且是按需接收的，則傳送方就對分組 n 傳送 ack，並且將該分組中的資料部分交付上層。對於其他情況都是直接丟包，並且為最近按序接收的分組重新傳送 ack。
為了保證資料按序交付，接收方需要丟棄所有的失序分組。這是因為對於傳送方而言，如果分組 n 丟包，則分組 n 及分組 n+1 之後的所有未確認分組都會被重傳。這種方式的優點在於接收方不需要快取任何失序分組，接收方需要維護的唯一資訊就是下乙個按序接收的分組序號。
gbn 協議最大的問題在於單個分組的查錯會引起 gbn 重傳大量分組，但是很多分組根本沒必要重傳，當通道的差錯率增加是流水線會充滿大量不必要分組。所謂選擇重傳(sr)協議通過讓傳送方僅重傳出錯的分組，避免不必要的重傳。
首先是從上層收到資料，此時 sr 檢查下乙個可用於該分組的序號，若序號位於傳送視窗內則打包資料並傳送。若序號不可用就暫時快取資料，或者返回給上層等待一段時間。
對於超時，sr 仍然使用定時器防止丟失分組，此時想在每個分組都需要有自己的邏輯計時器，因為超時事件發生時僅重傳乙個分組。
對於收到 ack時，若 ack 對應的分組序號在視窗內，則 sr 傳送方將被確認分組標記為已接收。如果 ack 對應的分組序號是基序號，則視窗基序號向前移動到未確認分組的最小序號。若視窗移動時有序號對應的分組沒傳送，就將這些分組發出去。
若收到的分組序號在接收方的視窗內，則向傳送方傳送 ack，若該分組是之前沒收到過的就快取。若該分組序號等於接收視窗的基序號，則該分組之前快取過的序號連續的分組都交付給上層。
若收到的分組序號在接收方的視窗外(已成功接收)，也向傳送方傳送 ack。接收方重新確認已收到過的序號小於基序號的分組是很重要的操作，如果基序號的 ack 沒有被傳送方接收到的話，傳送方將再次重傳。也就是說如果接收方不確認這類分組，傳送方視窗將永遠不向前滑動。
其他情況都直接忽略分組，不做任何事情。
對於哪些分組被正確接收，哪些分組沒有被接收，傳送方和接收方並不能同步地知道結果，這也說明 sr 協議中傳送方和接收方視窗並不總一致。接下來通過 2 個例子說明，sr 協議保證視窗同步的重要性。
首先看第乙個例子，該例子中 3 個分組的 ack 全部丟失，因此傳送方會重傳這些分組。但是接收方的視窗已經發生了滑動，此時即使接收方收到了期望序號的分組，但顯然接下來的分組會全部出錯。
在第二個例子中，接收方並不能同步得知傳送方的動作，因此無法區分分組是第 1 個分組的重傳，還是第 5 個分組的傳輸。
因此為了同步傳送方和接收方的視窗，對於視窗長度規模需要進行控制，視窗長度必須小於或等於序號空間大小的一半。
《計算機網路(第七版)》 謝希仁 著，電子工業出版社
《計算機網路 自頂向下方法》 [美] james f.kurose,keith w.ross 著，陳鳴 譯，機械工業出版社
可靠資料傳輸協議演變流程
可靠資料傳輸 傳輸資料位元不會損壞 丟失，有序傳送接收 可靠傳輸協議的發展 rdt1.0 rdt1.0是基於理想情況下的協議，假設所有通道都是可靠的，沒有位元位的翻轉，沒有資料報的丟失與超時，所以rdt1.0的傳輸功能就是 傳送方傳送資料，接收方接受資料。rdt2.0 在有位元差錯的情況下 進行可靠...
可靠資料傳輸原理
概述 可靠資料傳輸原理 tcp的可靠資料傳輸 tcp可靠資料傳輸的滑動視窗既不是純粹的gbn，也不是純粹的sr，在這兩個協議之外又引入了新的東西。資料傳輸發生錯誤怎麼辦？傳送方的有限狀態機 圓圈代表當前所處的狀態，帶箭頭的線代表狀態的轉換，橫線上方指示引起狀態變遷的事件，橫線下方指示狀態轉換中採取的...
求流水線吞吐率和最大資料傳輸率
近幾天在緊張地複習 計算機組成原理 計算題頗多，比較難理解的就如題目所說的這兩個 當然還有其他的 實際上簡單到非常。1s 1000ms 1000 000 s，1ghz 1000 mhz 1000 000 000 hz，1s 1 1hz 後面會用到。指令總數 流水線執行總時間 x100 例題 主頻為1...