TCP協議的滑動窗口具體是怎樣控制流量的？

12-28

TCP 協議通過滑動窗口來實現流量的控制，那具體是怎麼來實現流量控制的呢？

首先明確：
1)TCP滑動窗口分為接受窗口，發送窗口
滑動窗口協議是傳輸層進行流控的一種措施，接收方通過通告發送方自己的窗口大小，從而控制發送方的發送速度，從而達到防止發送方發送速度過快而導致自己被淹沒的目的。

對ACK的再認識，ack通常被理解為收到數據後給出的一個確認ACK，ACK包含兩個非常重要的信息：
一是期望接收到的下一位元組的序號n，該n代表接收方已經接收到了前n-1位元組數據，此時如果接收方收到第n+1位元組數據而不是第n位元組數據，接收方是不會發送序號為n+2的ACK的。舉個例子，假如接收端收到1-1024位元組，它會發送一個確認號為1025的ACK,但是接下來收到的是2049-3072，它是不會發送確認號為3072的ACK,而依舊發送1025的ACK。

二是當前的窗口大小m，如此發送方在接收到ACK包含的這兩個數據後就可以計算出還可以發送多少位元組的數據給對方，假定當前發送方已發送到第x位元組，則可以發送的位元組數就是y=m-(x-n).這就是滑動窗口控制流量的基本原理

重點：發送方根據收到ACK當中的期望收到的下一個位元組的序號n以及窗口m，還有當前已經發送的位元組序號x，算出還可以發送的位元組數。

發送端窗口的第一個位元組序號一定是ACK中期望收到的下一個位元組序號，比如下圖：

上圖52 53 54 55 位元組都是可以新發送的位元組序

接受端窗口的第一個位元組序之前一定是已經完全接收的，後面窗口裡面的數據都是希望接受的，窗口後面的數據都是不希望接受的。

http://blog.chinaunix.net/uid-20778955-id-539945.html

http://www.netis.com.cn/flows/2012/08/tcp-%E6%BB%91%E 5%8A%A8%E7%AA%97%E5%8F%A3%E7%9A%84%E7%AE%80%E4%BB%8B/

TCP的滑動窗口分為接收窗口和發送窗口
不分析這兩種窗口就討論是不妥當的。

TCP的滑動窗口主要有兩個作用，一是提供TCP的可靠性，二是提供TCP的流控特性。同時滑動窗口機制還體現了TCP面向位元組流的設計思路。TCP 段中窗口的相關欄位。

TCP的Window是一個16bit位欄位，它代表的是窗口的位元組容量，也就是TCP的標準窗口最大為2^16-1=65535個位元組。

另外在TCP的選項欄位中還包含了一個TCP窗口擴大因子，option-kind為3，option-length為3個位元組，option-data取值範圍0-14。窗口擴大因子用來擴大TCP窗口，可把原來16bit的窗口，擴大為31bit。

滑動窗口基本原理

1）對於TCP會話的發送方，任何時候在其發送緩存內的數據都可以分為4類，「已經發送並得到對端ACK的」，「已經發送但還未收到對端ACK的」，「未發送但對端允許發送的」，「未發送且對端不允許發送」。「已經發送但還未收到對端ACK的」和「未發送但對端允許發送的」這兩部分數據稱之為發送窗口。

當收到接收方新的ACK對於發送窗口中後續位元組的確認是，窗口滑動，滑動原理如下圖。

當收到ACK=36時窗口滑動。

2）對於TCP的接收方，在某一時刻在它的接收緩存內存在3種。「已接收」，「未接收準備接收」，「未接收並未準備接收」（由於ACK直接由TCP協議棧回復，默認無應用延遲，不存在「已接收未回復ACK」）。其中「未接收準備接收」稱之為接收窗口。

發送窗口與接收窗口關係

TCP是雙工的協議，會話的雙方都可以同時接收、發送數據。TCP會話的雙方都各自維護一個「發送窗口」和一個「接收窗口」。其中各自的「接收窗口」大小取決於應用、系統、硬體的限制（TCP傳輸速率不能大於應用的數據處理速率）。各自的「發送窗口」則要求取決於對端通告的「接收窗口」，要求相同。

滑動窗口實現面向流的可靠性

1）最基本的傳輸可靠性來源於「確認重傳」機制。

2）TCP的滑動窗口的可靠性也是建立在「確認重傳」基礎上的。

3）發送窗口只有收到對端對於本段發送窗口內位元組的ACK確認，才會移動發送窗口的左邊界。

4）接收窗口只有在前面所有的段都確認的情況下才會移動左邊界。當在前面還有位元組未接收但收到後面位元組的情況下，窗口不會移動，並不對後續位元組確認。以此確保對端會對這些數據重傳。

滑動窗口的流控特性

TCP的滑動窗口是動態的，我們可以想像成小學常見的一個數學題，一個水池，體積V，每小時進水量V1，出水量V2。當水池滿了就不允許再注入了，如果有個液壓系統控制水池大小，那麼就可以控制水的注入速率和量。這樣的水池就類似TCP的窗口。應用根據自身的處理能力變化，通過本端TCP接收窗口大小控制來對對對端的發送窗口流量限制。

應用程序在需要（如內存不足）時，通過API通知TCP協議棧縮小TCP的接收窗口。然後TCP協議棧在下個段發送時包含新的窗口大小通知給對端，對端按通知的窗口來改變發送窗口，以此達到減緩發送速率的目的。

見這裡：
TCP 的那些事兒（下）
順便也推薦：
TCP 的那些事兒（上）

流量控制也要按照TCP的基本法，按照接收方ACK時提供的發送窗口大小，當然發送方擁塞窗口的決定權也是很重要的，實際窗口的大小取決於發送窗口和擁塞窗口這兩者的較小值。
你問的這個「滑動」啊，excited！
假設窗口從左往右滑。窗口外的左側是已被接收方確認（根據ACK的序號）的數據，右側是由於窗口大小制限還未發送的數據；
窗口內分左右兩部分，窗口內的左端是已發送但未接到接收方確認的數據，右端是空餘的窗口空間，存等待發送的數據。當收到新的ACK使得左端的數據被確認時，窗口的左端限界向右滑，當右端等待發送的數據被發出時，窗口的右端限界向右滑使得更多的待發送數據進入窗口。

接收方提供的發送窗口大小實際上就是接收方此時可接收的數據量（接收方應用程序可能還未來得及取走緩衝里的數據，導致接收緩衝小於最大值）
發送方擁塞窗口大小的確定稍微複雜，需要根據目前網路擁塞狀態使用慢啟動和擁塞控制演算法。

知乎上TCP好的人多的很吶
歡迎你來發

流量控制即是為了避免接收端因為發送端發送數據速率過快導致緩存溢出而設計出的一種機制。通過對發送端滑動窗口的控制可以很輕鬆的做到這一點~
滑動窗口的大小取決於接收窗口rwnd和擁塞窗口cwnd的最小值，擁塞窗口解決的是擁塞控制的問題，這裡暫且不提。
rwnd即是接收端緩存空閑空間的大小，由接收端將其指維護在TCP報文中並作為確認ACK發送給發送端。因為發送端一次發送報文段的總位元組數是不能超過滑動窗口大小的，所以一旦接收端緩存空間不足就可以減小rwnd的值，從而達到控制發送端發送速率的目的。
那麼當發送端發現rwnd=0時該怎麼辦呢？此時發送端會停止發送數據並會維護一個持續計時器，當計時器到期便會發送一個一位元組的試探報文段，以避免死鎖。

最近剛學完運輸層，來此一答，若有錯誤求輕噴 (≡ω≡．)

簡單來說所謂的流量控制就是讓發送方的發送速率不要太快，讓接收方來得及接收。

設從A向B發送數據，總長度400位元組，每個報文段長度是100:
1、連接建立時B告訴A,我的接收窗口rwnd=300

2、A向B發送一個報文段，序號為1到100，還能再發送200個位元組

3、A再向B發送一個報文段，序號為101到200，還能再發送100個位元組

4、A再向B發送一個報文段，序號為201到300，還能再發送0個位元組

5、B接收到了第1到第100以及第201到第300號位元組，中間一個報文段丟失。此時B向A發送一個報文段ack=101,rwnd=200（允許A發送序號為101到300的位元組）

6、A不發送新數據，等到超時重傳舊的數據（序號101到200）

7、B接受到前300個位元組，向A發送一個報文段ack=301,rwnd=100

8、A發送序號為301到400的位元組

簡單來說就是這樣的，至於傳輸效率和擁塞控制，那就是另外的事情了。找了張圖，意思差不多

Selective Repeat Protocol

擁塞滑動窗口的大小可以控制發送端發送窗口的大小，這樣就可以控制發送端的發送流量大小。

滑動窗口也稱通告窗口
滑動窗口協議是傳輸層進行流控的一種措施，接收方通過通告發送方自己的窗口大小，從而控制發送方的發送速度，從而達到防止發送方發送速度過快而導致自己被淹沒的目的。
TCP的滑動窗口解決了端到端的流量控制問題，允許接受方對傳輸進行限制，直到它擁有足夠的緩衝空間來容納更多的數據。

擁塞窗口
擁塞窗口也看做是發送端用來進行流量控制的窗口。
但是，實際上，TCP還必須應付互聯網中的擁塞現象。擁塞是指一個或者多個交換點的數據報超載而導致時延劇烈增加的現象。為了控制擁塞，
TCP使用了第二個窗口限制，即擁塞窗口限制。對於擁塞窗口大小的限制採用慢開始和乘法減小兩種技術。
乘法減小的擁塞避免策略：一旦發現報文段丟失，就把擁塞窗口的大小減半（直到減至最小的窗口，窗口中應至少包含一個報文段）。
慢開始恢復：擁塞窗口隨著一個確認的到達，擁塞窗口的大小每次增加一個報文段。

我是這麼理解的滑動窗口和擁塞窗口都控制了流量，只是發送方有慢啟動、快重傳、快恢復的方式來避免擁塞。