[轉]TCP 滑動窗口協議/1比特滑動窗口協議/后退n協議/選擇重傳協議
2014-1-5閱讀884 評論0
本文轉自 http://www.cnblogs.com/ulihj/archive/2011/01/06/1927613.html
滑動窗口協議
一圖勝千言，看下面的圖，簡單解釋下：
發送和接受方都會維護一個數據幀的序列，這個序列被稱作窗口。發送方的窗口大小由接受方確定，目的在於控制發送速度，以免接受方的緩存不夠大，而導致溢出，同時控制流量也可以避免網絡擁塞。下面圖中的4,5,6號數據幀已經被發送出去，但是未收到關聯的ACK，7,8,9幀則是等待發送。可以看出發送端的窗口大小為6，這是由接受端告知的（事實上必須考慮擁塞窗口cwnd，這里暫且考慮cwnd>rwnd）。此時如果發送端收到4號ACK，則窗口的左邊緣向右收縮，窗口的右邊緣則向右擴展，此時窗口就向前“滑動了”，即數據幀10也可以被發送。
下面就滑動窗口協議做出更詳細的說明，這里為了簡單起見設定發送方窗口大小為2，接受方大小為1。看下面圖：
1：初始態，發送方沒有幀發出，發送窗口前后沿相重合。接收方0號窗口打開，等待接收0號幀； 2：發送方打開0號窗口，表示已發出0幀但尚確認返回信息。 此時接收窗口狀態不變； 3：發送方打開0、1號窗口，表示0、1號幀均在等待確認之列。至此，發送方打開的窗口數已達規定限度，在未收到新的確認返回幀之 前，發送方將暫停發送新的數據幀。接收窗口此時狀態仍未變； 4：接收方已收到0號幀，0號窗口關閉，1號窗口打開，表示准備接收1號幀。此時發送窗口狀態不 變； 5：發送方收到接收方發來的0號幀確認返回信息，關閉0號窗口，表示從重發表中刪除0號幀。此時接收窗口狀態仍不變 6：發送方繼續發送2號幀，2號窗口 打開，表示2號幀也納入待確認之列。至此，發送方打開的窗口又已達規定限度，在未收到新的確認返回幀之前，發送方將暫停發送新的數據幀，此時接收窗口狀態 仍不變； 7：接收方已收到1號幀，1號窗口關閉，2號窗口打開，表示准備接收2號幀。此時發送窗口狀態不變； 8：發送方收到接收方發來的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協議的另外一個問題是，當有錯誤幀出現后，總是要重發該幀之后的所有幀，毫無疑問在網絡不是很好的情況下會進一步惡化網絡狀況。
重傳協議便是用來解決這個問題。原理也很簡單，接收端總會緩存所有收到的幀，當某個幀出現錯誤時，只會要求重傳這一個幀，只有當某個序號后的所有幀都正確收到后，才會一起提交給高層應用。重傳協議的缺點在於接受端需要更多的緩存。