滑動視窗協定
滑動視窗協定（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協定的兩端分别為發送者A和接收者B，由于是全雙工協定，是以A和B應該分别維護着一個獨立的發送緩沖區和接收緩沖區，由于對等性（A發B收和B發A收），我們以A發送B接收的情況作為例子；
- 發送視窗是發送緩存中的一部分，是可以被TCP協定發送的那部分，其實應用層需要發送的所有資料都被放進了發送者的發送緩沖區；
- 發送視窗中相關的有四個概念：已發送并收到确認的資料（不再發送視窗和發送緩沖區之内）、已發送但未收到确認的資料（位于發送視窗之中）、允許發送但尚未發送的資料以及發送視窗外發送緩沖區内暫時不允許發送的資料
- 每次成功發送資料之後，發送視窗就會在發送緩沖區中按順序移動，将新的資料包含到視窗中準備發送；
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)