一、滑動視窗協議
為了解決停等操作的效能問題（發了乙個分組之後一直等到確認了這個分組才發下乙個），推出了流水線機制，提供資源利用率。就是允許傳送方在收到對方的ack前，傳送多個分組
其中視窗是乙個範圍管理發出去還沒確認的分組，隨著不斷傳輸，這個視窗不斷滑動，名稱的由來。視窗左端的序號收到了ack，就可以往右滑動了。
滑動視窗協議有gbn、sr
二、滑動視窗協議的實現：gbn
1.分組頭部包含序列號
2.視窗如下，大小為n，最多允許n個分組未確認
3.ack(n),則表示確認從開始到n（包含n）的序列號全部正確接收
4.會空中在傳的分組設定乙個timer計時器，處理超時，如果收到了timeout(n)事件，那麼會重傳的是n以及n以後的所有分組（儘管後面的可能已經收到了，這就是回退，回退到n開始傳，gbn）
5.接收方會有乙個期望序列號，如果收到的不是期望的分組，直接丟棄
三、滑動視窗協議的實現：sr（選擇重傳）
gbn缺陷，累積確認機制導致回退到n，重複傳了很多。解決這個。
1.對每個分組分別確認，不再只接收期望的，接到不期望的，就先快取（設定快取機制），接到期望的才交付上層
2.傳送方只需要重傳那些沒收到ack的分組了
3.產生了接收方視窗（gbn只有傳送方視窗），用來快取，現在有兩視窗了
4.序列號的位數是k的話，那麼得滿足 接收方視窗大小n+傳送方n<= 2的k次方，防止因為接收方ack丟失導致傳送重發k號分組，而此時接收方滑到了新視窗，新視窗有新的k號分組（不是原來的，共用序號產生的），導致出錯
流水線暫停機制的設計
這是未新增流水線暫停的系統機構框圖，電腦繪圖的話有時候新增輸入輸出就要進行大改動，我就手畫了 在openmips流水線cpu設計中，乘累加 乘類減指令在流水線的執行階段占用多個時鐘週期，因此需要暫停流水線，等待這些多週期指令執行完成。實現流水線的暫停 只需要保持取指令位址pc的值不變。同一時候保持流...
計算機網路 傳輸層（2）流水線協議和滑動視窗協議
流水線技術允許傳送方在收到ack之前連續傳送多個分組 1 必須增加序號範圍，因為每個輸送中的分組 不計算重傳的 必須有乙個唯一的序號，而且也許有多個在輸送中未確認的報文。2 協議的傳送方和接收方要能快取多個分組。傳送方至少要能快取那些已傳送但沒有確認的分組，接收方可能要快取那些已正確接收的分組。3 ...
運輸層 流水線可靠資料傳輸協議
禁止碼迷，布布扣，豌豆 碼農教程，愛碼網等第三方爬蟲 爬取！目錄選擇重傳 參考資料 我們來考慮位元交替協議，會發現由於協議需要等待 ack，中間的等待時間內傳送端和接收端都是無所事事的。根據分析，我們可以計算出位元交替協議的通道利用率，我們會發現這個量級是十分可憐的。而且我們還忽略了傳送方和接收方的...