TCP 滑動視窗協議

什麼是滑動視窗協議？

一圖勝千言，看下面的圖。簡單解釋下，傳送和接受方都會維護乙個資料幀的序列，這個序列被稱作視窗。傳送方的視窗大小由接受方確定，目的在於控制傳送速度，以免接受方的快取不夠大，而導致溢位，同時控制流量也可以避免網路擁塞。下面圖中的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號幀。此時接收視窗狀態仍不變。

1位元滑動視窗協議?

上面說的只是滑動視窗協議的理論，實際應用中又有不同。首先就是停等協議(stop－and－wait)，這時接受方的視窗和傳送方的視窗大小都是1，1個位元就夠表示了，所以也叫1位元滑動視窗協議。傳送方這時自然傳送每次只能傳送乙個，並且必須等待這個資料報的ack，才能傳送下乙個。雖然在效率上比較低，頻寬利用率明顯較低，不過在網路環境較差，或是頻寬本身很低的情況下，還是適用的。看下面的流程圖：

後退n協議?

停等協議雖然實現簡單，也能較好的適用惡劣的網路環境，但是顯然效率太低。所以有了後退n協議，這也是滑動視窗協議真正的用處，這裡傳送的視窗大小為n，接受方的視窗仍然為1。具體看下面的圖，這裡假設n=9：

首先傳送方一口氣傳送10個資料幀，前面兩個幀正確返回了，資料幀2出現了錯誤，這時傳送方被迫重新傳送2-8這7個幀，接受方也必須丟棄之前接受的3-8這幾個幀。

後退n協議的好處無疑是提高了效率，但是一旦網路情況糟糕，則會導致大量資料重發，反而不如上面的停等協議，實際上這是很常見的，具體可以參考tcp擁塞控制。

選擇重傳協議？

後退n協議的另外乙個問題是，當有錯誤幀出現後，總是要重發該幀之後的所有幀，毫無疑問在網路不是很好的情況下會進一步惡化網路狀況，重傳協議便是用來解決這個問題。原理也很簡單，接收端總會快取所有收到的幀，當某個幀出現錯誤時，只會要求重傳這乙個幀，只有當某個序號後的所有幀都正確收到後，才會一起提交給高層應用。重傳協議的缺點在於接受端需要更多的快取。

TCP 滑動視窗協議

TCP 滑動視窗協議

TCP 滑動視窗協議

TCP 滑動視窗協議

相關推薦