https://www.zhihu.com/question/32255109
TCP協議的滑動視窗具體是怎樣控制流量的？
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協議堆疊在下個段發送時包含新的視窗大小通知給對端，對端按通知的視窗來改變發送視窗，以此達到級訓發送速率的目的，
============================
https://juejin.im/post/6844903809995505671
https://zhuanlan.zhihu.com/p/60893857
在上一篇文章通過“表白”方式，讓我們快速了解網路七層協議 了解了網路七層協議， 接下來我們要把重心放在網路傳輸的可靠性上面，一起來看TCP協議，它是如何解決網路傳輸不可靠的問題，這其中有個很關鍵的部分，就是我們的滑動視窗協議，
從工程學角度上，我們來看一看滑動視窗協議，它到底解決了一個怎樣的問題？
滑動視窗協議：
- TCP協議的使用
- 維持發送方/接收方緩沖區 緩沖區是 用來解決網路之間資料不可靠的問題，例如丟包，重復包，出錯，亂序
在TCP協議中，發送方和接受方通過各自維護自己的緩沖區，通過商定包的重傳機制等一系列操作，來解決不可靠的問題，
問題一：如何保證次序？
提出問題：在我們滑動視窗協議之前，我們如何來保證發送方與接收方之間，每個包都能被收到，并且是按次序的呢？
問題二：如何提高吞吐量？
提出問題：那么我們就不能先連發幾個包等他一起確認嗎？這樣的話，我們的速度會不會更快，吞吐量更高些呢？
問題三：如何實作最優解？
問題：我們每次需要發多少個包過去呢？發送多少包是最優解呢？
我們能不能把第一個和第二個包發過去后，收到第一個確認包就把第三個包發過去呢？而不是去等到第二個包的確認包才去發第三個包，這樣就很自然的產生了我們"滑動視窗"的實作，
正常情況
丟包情況
有可能我們包發過去，對方的Ack丟了，也有可能我們的包并沒有發送過去，從發送方角度看就是我們沒有收到Ack，
如果我們這個Ack始終不來怎么辦呢？
超時重發
這時候我們有個解決方法：超時重傳 這里有一點要說明：這個Ack是要按順序的，必須要等到5的Ack收到，才會把6-11的Ack發送過去，這樣就保證了滑動視窗的一個順序，
文末
從我們為了增加網路的吞吐量，想講資料包一起發送過去，這時候便產生了“滑動視窗”這種協議，有了“滑動視窗”這個概念，我們又解決了其中出現的一些問題，例如丟包，我們又通過重發的機制去解決了，以上來自ccmouse老師教學視頻，作為學習記錄整理，
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/209542.html
標籤：其他