滑動視窗協議是tcp使用的一種流量控制方法，該協議允許傳送方在停止並等待確認前可以連續傳送多個分組。tcp是如何通過滑動視窗協議實現流量控制的?本博文將為您詳細介紹該協議及其工作原理。
什麼是滑動視窗協議?
一圖勝千言，看下面的圖。簡單解釋下，傳送和接受方都會維護乙個資料幀的序列，這個序列被稱作視窗。傳送方的視窗大小由接受方確定，目的在於控制傳送速度，以免接受方的快取不夠大，而導致溢位，同時控制流量也可以避免網路擁塞。下面圖中的4,5,6號資料幀已經被傳送出去，但是未收到關聯的ack，7,8,9幀則是等待傳送。可以看出傳送端的視窗大小為6，這是由接受端告知的(事實上必須考慮擁塞視窗cwnd，這裡暫且考慮cwnd>rwnd)。此時如果傳送端收到4號ack，則視窗的左邊緣向右收縮，視窗的右邊緣則向右擴充套件，此時視窗就向前「滑動了」，即資料幀10也可以被傳送。
1.位元滑動視窗協議
上面說的只是滑動視窗協議的理論，實際應用中又有不同。首先就是停等協議(stop-and-wait)，這時接受方的視窗和傳送方的視窗大小都是1，1個位元就夠表示了，所以也叫1位元滑動視窗協議。傳送方這時自然傳送每次只能傳送乙個，並且必須等待這個資料報的ack，才能傳送下乙個。雖然在效率上比較低，頻寬利用率明顯較低，不過在網路環境較差，或是頻寬本身很低的情況下，還是適用的。看下面的流程圖：
2.後退n協議
停等協議雖然實現簡單，也能較好的適用惡劣的網路環境，但是顯然效率太低。所以有了後退n協議，這也是滑動視窗協議真正的用處，這裡傳送的視窗大小為n，接受方的視窗仍然為1。具體看下面的圖，這裡假設n=9：
首先傳送方一口氣傳送10個資料幀，前面兩個幀正確返回了，資料幀2出現了錯誤，這時傳送方被迫重新傳送2-8這7個幀，接受方也必須丟棄之前接受的3-8這幾個幀。
接收方一般採用累積確認的方式。即不必對收到的分組逐個傳送確認，而是對按序到達的最後乙個分組傳送確認，這樣就表示：到這個分組為止的所有分組都已正確收到了。累積確認有的優點是：容易實現，即使確認丟失也不必重傳。缺點是：不能向傳送方反映出接收方已經正確收到的所有分組的資訊。
3.選擇重傳協議
後退n協議的另外乙個問題是，當有錯誤幀出現後，總是要重發該幀之後的所有幀，毫無疑問在網路不是很好的情況下會進一步惡化網路狀況，重傳協議便是用來解決這個問題。原理也很簡單，接收端總會快取所有收到的幀，當某個幀出現錯誤時，只會要求重傳這乙個幀，只有當某個序號後的所有幀都正確收到後，才會一起提交給高層應用。重傳協議的缺點在於接受端需要更多的快取。
4.混合arq
在混合arq中，資料報文傳送到接收方之後，即使出錯也不會被丟棄。接收方指示傳送方重傳出錯報文的部分或者全部資訊，將再次收到的報文資訊與上次收到的報文資訊進行合併，以恢復報文資訊。
TCP滑動視窗
目前建立在tcp協議上的網路協議特別多，有telnet，ssh，有ftp，有http等等。這些協議又可以根據資料吞吐量來大致分成兩大類 1 互動資料型別，例如telet，ssh，這種型別的協議在大多數情況下只是做小流量的資料交換，比如說按一下鍵盤，回顯一些文字等等。2 資料成塊型別，例如ftp，這種...
TCP滑動視窗
假設a和b之間新建立了一條tcp連線。裝置a需要傳送一長串資料流，但裝置b無法一次全部接收，所以它限制裝置a每次傳送分段指定數量的位元組數，直到分段中已傳送的位元組數得到確認。之後，裝置a可以繼續傳送更多位元組。每乙個裝置都對傳送，接收及確認資料進行追蹤。tcpbuffer中資料可以分為以下四類 1...
TCP滑動視窗
tcp滑動視窗是用來控制流量的，避免擁塞的發生。滑動視窗又包括接收端滑動視窗和傳送端滑動視窗，下面我們簡單分析一下。上圖顯示的是接收緩衝區，其中接收視窗也在其中。接收視窗的大小是8，即4 12，此時由a可知，接收端下乙個預計接收序列號4，當接收端接收到4 7之後，滑動視窗就會右移，此時接收端預計接收...