前兩篇文章分別解釋了可靠性傳輸要解決的兩件事情：
1：資料受損怎么辦
2：資料丟失怎么辦
可靠性傳輸核心解決辦法：
1：停等協議（等前一個徹底確認發送成功后再發送下一組資料）
2：重傳（如果傳輸受損，重傳；如果傳輸丟失，重傳）
通過以上兩個方法外加序列號，校驗等已經實作了可靠性傳輸，但是有性能問題
停等協議的弊端
信道利用率U=傳輸時間 /傳輸時間 + RTT，當RTT很大是，傳輸效率會非常低下，
把信道假設為一條高速公路，停等類似于前一輛車到達終點后下一輛車才能開始進入高速公路，效率可想而知，
引入流水線
不再以停等的形式進行發送，而是一次傳輸多個，下圖為例，一次性傳輸三組資料使得信道的利用率提高了三倍，
同樣用高速公路作為例子，車子一輛跟著一輛進入高速公路，
停等和流水線運行時狀態
流水線需要面對的問題
1. 更多的序號，停等0，1就夠了，
2.發送的程序中可能會亂序，發送方最低限度需要快取已經發送但是沒有確認的資料分組，接收方也許也要快取已經收到的資料，
滑動視窗基本模型
下圖為一個基本的滑動視窗在發送端的模型
說明
- 視窗大小為N（視窗的大小在TCP中是在握手的階段接收方告訴發送方的，后續隨著網路情況和接收方讀取的速度，會實時進行調整）
- Base下一個等待確認的序號，
- NextSeqNum為下一個即將要發送的序號，
行為
- 發送方快取了已經發送但是沒有確認的資料分組（因為如果超時沒有確認，需要重新傳遞這些資料）
- 當Base對應的序號確認后，視窗向右滑動一格，同時把序號為NextSeqNum對應的資料分組發送出去：Base=Base+1，NextSeqNum=NextSeqNum+1.
滑動視窗之回退N步-GNB（Go-Back-To-N）
- 累計確認：收到一個序號為n的ack，代表接收方已經收到了序號為n以及n以前的全部分組
- 超時，如果發生超時，發送方重新傳遞所有已經發送但是還未確認的分組
- 接收方丟棄所有失序的分組，如果接收方期待的是N，如果N+1到了，則直接丟棄，
示意圖
GBN的好處就是簡單，接收方只需要維護一個期待的序列號即可，
最大的問題是資源浪費，上圖可以看出即使分組3，4，5被正確接受了，但是因為分組2丟失了，導致2，3，4，5被全部重傳，
滑動視窗之選擇重傳-SR（Selective Repeat）
GBN中接收方直接丟棄失序分組，簡單但是資源浪費，SR協議就是為了解決浪費，
解決浪費的核心就是不丟棄失序分組，但是作為接收方，傳輸層要保證按序把資料傳輸給上層的應用層，所以相比GBN，SR最大的改造是在接受方增加和快取，作為發送方，SR在視窗內也有亂序的已經確認的資料分組，
接收方視窗
接收方快取了正確接收但是亂序的資料，當ReceiveBase(期望的正確分組）到達時，資料會被交付給上層應用，同時接受視窗會移動，Receivebase=ReceiveBase+1
發送方視窗
示意圖
以上，滑動視窗的基本原理已經介紹完畢，通過對比發現，不管時GNB還是SR，為了保證資料不會亂序，都有一個共同特點：
- 發送方，只有發送Base序號的資料確認后，視窗才會移動
- 接收方，只有接收Base序號的資料收到后，才會把資料交給上層（GNB中，非Base序號的會丟棄，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/197491.html
標籤：其他
上一篇：如何對Pandas DataFrame進行自定義排序
下一篇：Nginx實體