一圖勝千言，看下面的圖。簡單解釋下，傳送和接受方都會維護乙個資料幀的序列，這個序列被稱作視窗。傳送方的視窗大小由接受方確定，目的在於控制傳送速度，以免接受方的快取不夠大，而導致溢位，同時控制流量也可以避免網路擁塞。下面圖中的4,5,6號資料幀已經被傳送出去，但是未收到關聯的ack，7,8,9幀則是等待傳送。可以看出傳送端的視窗大小為6，這是由接受端告知的（事實上必須考慮擁塞視窗cwnd，這裡暫且考慮cwnd>rwnd）。此時如果傳送端收到4號ack，則視窗的左邊緣向右收縮，視窗的右邊緣則向右擴充套件，此時視窗就向前「滑動了」，即資料幀10也可以被傳送。下面就滑動視窗協議做出更詳細的說明，這裡為了簡單起見設定傳送方視窗大小為2，接受方大小為1。看下面圖：
一：初始態，傳送方沒有幀發出，傳送視窗前後沿相重合。接收方0號視窗開啟，等待接收0號幀；
二：傳送方開啟0號視窗，表示已發出0幀但尚確認返回資訊。 此時接收視窗狀態不變；
三：傳送方開啟0、1號視窗，表示0、1號幀均在等待確認之列。至此，傳送方開啟的視窗數已達規定限度，在未收到新的確認返回幀之 前，傳送方將暫停傳送新的資料幀。接收視窗此時狀態仍未變；
四：接收方已收到0號幀，0號視窗關閉，1號視窗開啟，表示準備接收1號幀。此時傳送視窗狀態不 變；
五：傳送方收到接收方發來的0號幀確認返回資訊，關閉0號視窗，表示從重發表中刪除0號幀。此時接收視窗狀態仍不變
六：傳送方繼續傳送2號幀，2號視窗 開啟，表示2號幀也納入待確認之列。至此，傳送方開啟的視窗又已達規定限度，在未收到新的確認返回幀之前，傳送方將暫停傳送新的資料幀，此時接收視窗狀態 仍不變；
七：接收方已收到1號幀，1號視窗關閉，2號視窗開啟，表示準備接收2號幀。此時傳送視窗狀態不變；
八：傳送方收到接收方發來的1號幀收畢的確認信 息，關閉1號視窗，表示從重發表中刪除1號幀。此時接收視窗狀態仍不變。
上面說的只是滑動視窗協議的理論，實際應用中又有不同。首先就是停等協議(stop－and－wait)，這時接受方的視窗和傳送方的視窗大小都是1，1個位元就夠表示了，所以也叫1位元滑動視窗協議。傳送方這時自然傳送每次只能傳送乙個，並且必須等待這個資料報的ack，才能傳送下乙個。雖然在效率上比較低，頻寬利用率明顯較低，不過在網路環境較差，或是頻寬本身很低的情況下，還是適用的。看下面的流程圖：停等協議雖然實現簡單，也能較好的適用惡劣的網路環境，但是顯然效率太低。所以有了後退n協議，這也是滑動視窗協議真正的用處，這裡傳送的視窗大小為n，接受方的視窗仍然為1。具體看下面的圖，這裡假設n=9：首先傳送方一口氣傳送10個資料幀，前面兩個幀正確返回了，資料幀2出現了錯誤，這時傳送方被迫重新傳送2-8這7個幀，接受方也必須丟棄之前接受的3-8這幾個幀。
後退n協議的好處無疑是提高了效率，但是一旦網路情況糟糕，則會導致大量資料重發，反而不如上面的停等協議，實際上這是很常見的，具體可以參考tcp擁塞控制。
後退n協議的另外乙個問題是，當有錯誤幀出現後，總是要重發該幀之後的所有幀，毫無疑問在網路不是很好的情況下會進一步惡化網路狀況，重傳協議便是用來解決這個問題。原理也很簡單，接收端總會快取所有收到的幀，當某個幀出現錯誤時，只會要求重傳這乙個幀，只有當某個序號後的所有幀都正確收到後，才會一起提交給高層應用。重傳協議的缺點在於接受端需要更多的快取。3 4 4 多幀滑動視窗與選擇重傳協議（SR）
為了進一步提高通道的利用率，可設法只重傳出現差錯的資料幀或者是計數器超時的資料幀。但此時必須加大接受視窗，以便先收下傳送序號不連續但仍處在接受視窗中的那些資料幀。等到所缺序號的資料幀收到後再一併送交主機。這就是選擇重傳arq協議。在選擇重傳協議中，每乙個傳送緩衝區對應乙個計時器，當計時器超時時，緩衝...
3 4 3 多幀滑動視窗和後退N幀協議（GBN）
在後退n幀式arq中，傳送方不需要在收到上一幀的ack後才能開始傳送下一幀，而是可以連續傳送幀。當接受方檢測出失序的資訊幀後，要求傳送方重發最後乙個正確接受的資訊幀之後的所有未確認的幀 或者當傳送方傳送了n個幀後，若發現該n個幀的前乙個幀在計時器超時後仍未返回其確認資訊，則該幀被判為出錯或丟失，此時...
TCP協議滑動視窗與確認重傳機制？
位元組流傳輸狀態分類與滑動視窗的概念 tcp協議使用以位元組為單位的滑動視窗協議，來控制位元組流的傳送 接收 確認與重傳過程。接收視窗的大小由接收端根據快取剩餘空間的大小，以及應用程序讀取資料的速度來決定。傳送視窗的大小取決於接收視窗的大小。傳送視窗和接收視窗 傳送視窗等於第二類和第三類的位元組數之...