一：摘要概述
TCP作爲一個可靠的傳輸層協議，其精髓就是一系列如滑動窗口、擁塞避免等手段控制流量。可以根據服務器處理速度以及網絡情況調整數據傳輸速率，當然整個過程對於開發人員來講是透明的。本文將從滑動窗口、擁塞控制兩個方面詳解TCP對流量控制做的操作
二：接收窗口
服務器處理數據的能力有限，不可能無限制的接收數據。在三次握手的過程中有一個字屬性專門用於標記接收窗口大小，三次握手過程告訴對方接收窗口只有這麼大，傳輸未確認的數據只能這麼多，超過就等等再操作
看下面截圖就是三次握手的SYN包示例圖，可以看到其中紅框部分就表示了接收窗口的大小。紅框中有三部分值，具體含義如下：
- Window size：接收窗口大小，只有16字節大小不夠表示窗口數值，引入縮放比例
- Calculated window：縮放計算後的接收窗口大小
- Window scale：縮放比例
Calculated window = Window size * Window scale
至於爲什麼我這裏的Wireshark抓包出來顯示的數值不對，這個還需要研究。應該是可以調試的，但是目前截圖的顯示確實都是已經計算好之後的數值
三：滑動窗口
有了接收窗口的限制以後自然數據傳輸就不會超過該數值，那麼滑動窗口的概念又是什麼情況呢？就好像遊標一樣滑動，其組成如下圖所示：
滑動窗口由四部分組成每個字節的數據都有唯一順序的編碼，隨着時間發展，未確認部分與可以發送數據包編碼部分向右移動，形式滑動窗口
- 綠色：發送成功並已經ACK確認的數據
- 黃色：發送成功等待ACK確認的數據(佔用滑動窗口大小)
- 紫色：滑動窗口剩餘大小可以發送的字節數量(滑動窗口可用大小)
- 灰色：後續數據編碼
接收窗口的大小就是滑動窗口的最大值，數據傳輸過程中滑動窗口的可用大小是動態變化的。但是還有這麼一點，滑動窗口的設計僅僅是考慮到了處理方的處理能力，但是沒有考慮到道路的通暢問題呀！！！就好像服務端可以處理100M數據，但是傳輸的數據99M都堵在路上了，這不就是導致道路阻塞了麼？後面就會繼續講解流量控制的另外一個設計擁塞避免
四：慢啓動
慢啓動的含義就是瘋狂試探，大概的過程如下圖所示：傳輸層將數據報文切割爲符合傳輸要求的N段數據後會先傳輸10段大小的數據，當正常ACK之後會傳輸20段大小數據，繼續正常ACK則會繼續翻倍。每次傳輸都可以理解爲網絡傳輸狀態檢測，檢測到傳輸網絡通信正常就會翻倍自己的傳輸數量，這個限制稱之爲擁塞窗口
五：慢啓動閾值
慢啓動無限制指數級別增長？想想一張紙摺疊珠穆朗瑪峯的高度，指數爆炸是十分恐怖的操作。所以爲了避免無限制的慢啓動指數增長，擁塞窗口還有一個限制就是慢啓動閾值，當擁塞窗口大小達到慢啓動閾值的時候就會將其指數增長的策略修改爲線性增長：RTT的含義就是一次請求到響應的完整過程，其中可能包括多次的數據包傳輸與確認
- 慢啓動：擁塞窗口小於慢啓動閾值，指數增長，每次RTT後都翻倍
- 擁塞避免：擁塞窗口大於慢啓動閾值，線性增長，每次RTT後加1