TCP滑动窗口和拥塞控制机制
滑動窗口協議
滑動窗口協議（Sliding Window Protocol）屬于TCP協議的一種應用，用于網絡數據傳輸時的流量控制，以避免擁塞的發生。該協議允許發送方在停止并等待確認前發送多個數據分組。由于發送方不必每發一個分組就停下來等待確認，因此該協議可以加速數據的傳輸，提高網絡吞吐量。
TCP通過滑動窗口來進行流量控制。設想在發送端發送數據的速度很快而接收端接收速度卻很慢的情況下，為了保證數據不丟失，顯然需要進行流量控制， 協調好通信雙方的工作節奏。所謂滑動窗口，可以理解成接收端所能提供的緩沖區大小。TCP利用一個滑動的窗口來告訴發送端對它所發送的數據能提供多大的緩沖區。由于窗口由16位bit所定義，所以接收端TCP 能最大提供65535個字節的緩沖。由此，可以利用窗口大小和第一個數據的序列號計算出最大可接收的數據序列號。?
滑動窗口本質上是描述接受方的TCP數據報緩沖區大小的數據，發送方根據這個數據來計算自己最多能發送多長的數據。如果發送方收到接受方的窗口大小為0的TCP數據報，那么發送方將停止發送數據，等到接受方發送窗口大小不為0的數據報的到來。?
? ? ? ?窗口合攏：當窗口從左邊向右邊靠近的時候，這種現象發生在數據被發送和確認的時候。 ??
? ? ? ?窗口張開：當窗口的右邊沿向右邊移動的時候，這種現象發生在接受端處理了數據以后。 ??
? ? ? ?窗口收縮：當窗口的右邊沿向左邊移動的時候，這種現象不常發生。 ??
? ? ? ?TCP就是用這個窗口，慢慢的從數據的左邊移動到右邊，把處于窗口范圍內的數據發送出去（但不用發送所有，只是處于窗口內的數據可以發送。）。這就是窗口的意義。窗口的大小是可以通過socket來制定的，4096并不是最理想的窗口大小，而16384則可以使吞吐量大大的增加。
A————C————B
如上圖，A與B之間建立TCP連接，滑動窗口實現有兩個作用：?
由于對稱性，只考慮A端發送窗口和B端接收窗口，有如下兩個作用?
1、B端來不及處理接收數據（控制不同速率主機間的同步），這時，A通過B端通知的接收窗口而減緩數據的發送。??
2、B端來得及處理接收數據，但是在A與B之間某處如C，使得AB之間的整體帶寬性能較差，此時，A端根據擁塞處理策略（慢啟動，加倍遞減和緩慢增加）來更新窗口，以決定數據的發送。 ??
與固定大小的滑動窗口協議相比，TCP采用可變大小的滑動窗口協議是為了取得更好的性能。 ??
TCP是一個廣域網協議，而廣域網環境下的路由器和主機，各自有著不同的性能和處理能力，在這種情況下，采用固定窗口大小的滑動窗口協議會引起性能上的損失。TCP規定窗口的大小是由接收方通告的，通過采取慢啟動和擁塞避免算法等機制來使帶寬和性能取得最佳。
1. “窗口”對應的是一段可以被發送者發送的字節序列，其連續的范圍稱之為“窗口”；
2. “滑動”則是指這段“允許發送的范圍”是可以隨著發送的過程而變化的，方式就是按順序“滑動”。
TCP建立連接的初始，B會告訴A自己的接收窗口大小，比如為‘20’：字節31-50為發送窗口。
? ? ? ??
根據B給出窗口值，A構造自己的窗口
A發送11個字節后，發送窗口位置不變，B接收到了亂序的數據分組：
? ? ? ?
A發了11個字節數據
只有當A成功發送了數據，即發送的數據得到了B的確認之后，才會移動滑動窗口離開已發送的數據；同時B則確認連續的數據分組，對于亂序的分組則先接收下來，避免網絡重復傳遞：
? ? ? ??
A收到新的確認號，窗口向前滑動
? ? ? ??
發送窗口內的序號都屬于已發送但未被確認
所謂流量控制，主要是接收方傳遞信息給發送方，使其不要發送數據太快，是一種端到端的控制。主要的方式就是返回的ACK中會包含自己的接收窗口的大小，并且利用大小來控制發送方的數據發送：
? ? ? ??
這里面涉及到一種情況，如果B已經告訴A自己的緩沖區已滿，于是A停止發送數據；等待一段時間后，B的緩沖區出現了富余，于是給A發送報文告訴A我的rwnd大小為400，但是這個報文不幸丟失了，于是就出現A等待B的通知||B等待A發送數據的死鎖狀態。為了處理這種問題，TCP引入了持續計時器（Persistence timer），當A收到對方的零窗口通知時，就啟用該計時器，時間到則發送一個1字節的探測報文，對方會在此時回應自身的接收窗口大小，如果結果仍未0，則重設持續計時器，繼續等待。
擁塞控制產生的原因
∑對資源的需求>可用資源
注意
單純的增加網絡資源無法解決問題
例如：把結點的存儲空間擴大，更換更高速率的鏈路，提高結點處理機的運算速度，不僅不能解決問題，而且可能使網絡性能更壞。
原因：網絡擁塞是許多因素引起的，單純的解決一個可能會使上述情況得到一些緩解，但是會把擁塞轉移到其他地方。
擴大結點存儲空間——>由于輸出鏈路的容量和處理機的速度并未提高，增大排隊等待時間，超時重傳，浪費資源。
更換更高速率的鏈路——>可能會緩解，，有可能造成各部分不匹配。
擁塞控制的作用
注意
擁塞控制與流量控制的區別
擁塞控制是防止過多的數據注入到網絡中，可以使網絡中的路由器或鏈路不致過載，是一個全局性的過程。
流量控制是點對點通信量的控制，是一個端到端的問題，主要就是抑制發送端發送數據的速率，以便接收端來得及接收。
擁塞的標志
1.重傳計時器超時
2.接收到三個重復確認
擁塞控制的機制
慢開始與擁塞避免
慢開始
1.慢開始不是指cwnd的增長速度慢（指數增長），而是指TCP開始發送設置cwnd=1。
2.思路：不要一開始就發送大量的數據，先探測一下網絡的擁塞程度，也就是說由小到大逐漸增加擁塞窗口的大小。這里用報文段的個數的擁塞窗口大小舉例說明慢開始算法，實時擁塞窗口大小是以字節為單位的。如下圖：
3.為了防止cwnd增長過大引起網絡擁塞，設置一個慢開始門限（ssthresh狀態變量）
當cnwd＜ssthresh，使用慢開始算法
當cnwd=ssthresh，既可使用慢開始算法，也可以使用擁塞避免算法
當cnwd＞ssthresh，使用擁塞避免算法
擁塞避免（按線性規律增長）
1.擁塞避免并非完全能夠避免擁塞，是說在擁塞避免階段將擁塞窗口控制為按線性規律增長，使網絡比較不容易出現擁塞。
2.思路：讓擁塞窗口cwnd緩慢地增大，即每經過一個往返時間RTT就把發送方的擁塞控制窗口加一。
無論是在慢開始階段還是在擁塞避免階段，只要發送方判斷網絡出現擁塞（其根據就是沒有收到確認，雖然沒有收到確認可能是其他原因的分組丟失，但是因為無法判定，所以都當做擁塞來處理），就把慢開始門限設置為出現擁塞時的發送窗口大小的一半。然后把擁塞窗口設置為1，執行慢開始算法。
加法增大與乘法減小
乘法減小：無論是慢開始階段還是擁塞避免，只要出現了網絡擁塞（超時），就把慢開始門限值ssthresh減半
加法增大：執行擁塞避免算法后，擁塞窗口線性緩慢增大，防止網絡過早出現擁塞
快重傳與快恢復
快重傳
1.快重傳要求接收方在收到一個失序的報文段后就立即發出重復確認（為的是使發送方及早知道有報文段沒有到達對方）而不要等到自己發送數據時捎帶確認。快重傳算法規定，發送方只要一連收到三個重復確認就應當立即重傳對方尚未收到的報文段，而不必繼續等待設置的重傳計時器時間到期。
2.由于不需要等待設置的重傳計時器到期，能盡早重傳未被確認的報文段，能提高整個網絡的吞吐量。
快恢復（與快重傳配合使用）
1.采用快恢復算法時，慢開始只在TCP連接建立時和網絡出現超時時才使用。
2.當發送方連續收到三個重復確認時，就執行“乘法減小”算法，把ssthresh門限減半。但是接下去并不執行慢開始算法。
3.考慮到如果網絡出現擁塞的話就不會收到好幾個重復的確認，所以發送方現在認為網絡可能沒有出現擁塞。所以此時不執行慢開始算法，而是將cwnd設置為ssthresh的大小，然后執行擁塞避免算法。
注意
發送方窗口的上限值=Min（接受窗口rwnd，擁塞窗口cwnd）
rwnd＞cwnd 接收方的接收能力限制發送方窗口的最大值
rwnd＜cwnd 網絡的擁塞限制發送方窗口的最大值
?
騰訊面試題
TCP的擁塞控制機制是什么？請簡單說說。
答：我們知道TCP通過一個定時器（timer）采樣了RTT并計算RTO，但是，如果網絡上的延時突然增加，
那么，TCP對這個事做出的應對只有重傳數據，然而重傳會導致網絡的負擔更重，于是會導致更大的延遲以及更多的丟包，這就導致了惡性循環，最終形成“網絡風暴” —— TCP的擁塞控制機制就是用于應對這種情況。
首先需要了解一個概念，為了在發送端調節所要發送的數據量，定義了一個“擁塞窗口”（Congestion Window），在發送數據時，將擁塞窗口的大小與接收端ack的窗口大小做比較，取較小者作為發送數據量的上限。
擁塞控制主要是四個算法：
一.慢開始：
意思是剛剛加入網絡的連接，一點一點地提速，不要一上來就把路占滿。
1.慢開始不是指cwnd的增長速度慢（指數增長），而是指TCP開始發送設置cwnd=1。
2.思路：不要一開始就發送大量的數據，先探測一下網絡的擁塞程度，也就是說由小到大逐漸增加擁塞窗口的大小。
3.為了防止cwnd增長過大引起網絡擁塞，設置一個慢開始門限（ssthresh狀態變量）
當cnwd＜ssthresh，使用慢開始算法
當cnwd=ssthresh，既可使用慢開始算法，也可以使用擁塞避免算法
當cnwd＞ssthresh，使用擁塞避免算法
二.擁塞避免：
當擁塞窗口 cwnd 達到一個閾值時，窗口大小不再呈指數上升，而是以線性上升，避免增長過快導致網絡擁塞。
每當收到一個ACK，發送方的cwnd = cwnd + 1/cwnd
每當過了一個RTT，發送方的cwnd = cwnd + 1
擁塞發生：當發生丟包進行數據包重傳時，表示網絡已經擁塞。分兩種情況進行處理：
等到RTO超時，重傳數據包（沒有收到三個重復確認）
慢開始門限sshthresh = cwnd /2
cwnd 重置為 1，執行慢開始算法
三.進入慢啟動過程
在收到三個重復確認（duplicate ACK）時就開啟重傳，而不用等到RTO超時
sshthresh = cwnd = cwnd /2
進入快速恢復算法——Fast Recovery
四.快速恢復：至少收到了三個重復確認（duplicate ACK），說明網絡也不那么糟糕，可以快速恢復。
cwnd = sshthresh + 3 * MSS （3的意思是確認有3個數據包被收到了）
重傳duplicate ACK指定的數據包
如果再收到duplicate ACK，那么cwnd = cwnd +1
如果收到了新的Ack，那么，cwnd = sshthresh ，然后就進入了擁塞避免的算法了。
RTT和RTO概念(參考：https://blog.csdn.net/yizhiniu_xuyw/article/details/109643610)
TCP作為一個面向連接的、可靠的傳輸協議，內部實現了一個重傳計時器來保證數據能傳輸到對方。每發送一個數據包，就給這個數據設置一個重傳計時器。如果在計時器超時之前收到了針對這個數據包的ack，就取消這個計時器。如果沒有收到，則開始發起重傳。計時器超時的時間被稱為RTO，這個時間的確定取決于RTT。
關于兩者詳細的解釋：
- RTT(Round Trip Time)：一個連接的往返時間，即數據發送時刻到接收到確認的時刻的差值；
- RTO(Retransmission Time Out)：重傳超時時間，即從數據發送時刻算起，超過這個時間便執行重傳。
總結
以上是生活随笔為你收集整理的TCP滑动窗口和拥塞控制机制的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： TCP三次握手详解及释放连接过程
- 下一篇： TCP中的RTT和RTO