tcp 為了防止傳送方無腦的傳送資料，導致接收方緩衝區被填滿，所以就有了滑動視窗的機制，它可利用接收方的接收視窗來控制傳送方要傳送的資料量，也就是流量控制。
接收視窗是由接收方指定的值，儲存在 tcp 頭部中，它可以告訴傳送方自己的 tcp 緩衝空間區大小，這個緩衝區是給應用程式讀取資料的空間：
接收視窗的大小，是在 tcp 三次握手中協商好的，後續資料傳輸時，接收方傳送確認應答 ack 報文時，會攜帶當前的接收視窗的大小，以此來告知傳送方。
假設接收方接收到資料後，應用層能很快的從緩衝區裡讀取資料，那麼視窗大小會一直保持不變，過程如下：
理想狀態下的視窗變化
但是現實中伺服器會出現繁忙的情況，當應用程式讀取速度慢，那麼快取空間會慢慢被佔滿，於是為了保證傳送方傳送的資料不會超過緩衝區大小，則伺服器會調整視窗大小的值，接著通過 ack 報文通知給對方，告知現在的接收視窗大小，從而控制傳送方傳送的資料大小。
服務端繁忙狀態下的視窗變化
零視窗通知與視窗探測
假設接收方處理資料的速度跟不上接收資料的速度，快取就會被佔滿，從而導致接收視窗為 0，當傳送方接收到零視窗通知時，就會停止傳送資料。
如下圖，可以接收方的視窗大小在不斷的收縮至 0：
視窗大小在收縮
接著，傳送方會定時傳送視窗大小探測報文，以便及時知道接收方視窗大小的變化。
以下圖 wireshark 分析圖作為例子說明：
零視窗 與 視窗探測
可以發現，這些視窗探測報文以 3.4s、6.5s、13.5s 的間隔出現，說明超時時間會翻倍遞增。
這連線暫停了 25s，想象一下你在打王者的時候，25s 的延遲你還能上王者嗎？
傳送視窗的分析
在 wireshark 看到的 windows size 也就是 " win = "，這個值表示傳送視窗嗎？這不是傳送視窗，而是在向對方宣告自己的接收視窗。
你可能會好奇，抓包檔案裡有「window size scaling factor」，它其實是算出實際視窗大小的乘法因子，「windos size value」實際上並不是真實的視窗大小，真實視窗大小的計算公式如下：
「windos size value」 * 「window size scaling factor」 = 「caculated window size 」
對應的下圖案例，也就是 32 * 2048 = 65536。
實際上是 caculated window size 的值是 wireshark 工具幫我們算好的，window size scaling factor 和 windos size value 的值是在 tcp 頭部中，其中 window size scaling factor 是在三次握手過程中確定的，如果你抓包的資料沒有 tcp 三次握手，那可能就無法算出真實的視窗大小的值，如下圖：
如何在包裡看出傳送視窗的大小？很遺憾，沒有簡單的辦法，傳送視窗雖然是由接收視窗決定，但是它又可以被網路因素影響，也就是擁塞視窗，實際上傳送視窗是值是 min(擁塞視窗，接收視窗)。
傳送視窗和 mss 有什麼關係？傳送視窗決定了一口氣能發多少位元組，而 mss 決定了這些位元組要分多少包才能發完。
舉個例子，如果傳送視窗為 16000 位元組的情況下，如果 mss 是 1000 位元組，那就需要傳送 1600/1000 = 16 個包。
傳送方在乙個視窗發出 n 個包，是不是需要 n 個 ack 確認報文？不一定，因為 tcp 有累計確認機制，所以當收到多個資料報時，只需要應答最後乙個資料報的 ack 報文就可以了。
TCP流量控制
一般來說，我們總是希望資料傳輸的更快一些，但如果傳送方把資料傳送的很快，而接收方來不及接收，這就可能造成資料的丟失。流量控制就是讓傳送方的傳送速率不要太快，讓接收方來得及接收。對於成塊資料流，tcp利用滑動視窗機制來實現流量的控制，對於互動資料流，tcp利用捎帶ack和nagle演算法來實現流量的控...
TCP流量控制
如果傳送端傳送的速度較快，接收端接收到資料後處理的速度較慢，而接收緩衝區的大小是固定的，就會丟失資料。tcp協議通過 滑動視窗 sliding window 機制解決這一問題。滑動視窗 傳送端發起連線，宣告最大段尺寸是1460，初始序號是0，視窗大小是4k，表示 我的接收緩衝區還有4k位元組空閒，你...
TCP流量控制
流量控制 一般來說，我們總是希望資料傳輸的更快一些，但如果傳送方把資料傳送的很快，而接收方來不及接收，這就可能造成資料的丟失。流量控制就是讓傳送方的傳送速率不要太快，讓接收方來得及接收。對於成塊資料流，tcp利用滑動視窗機制來實現流量的控制，對於互動資料流，tcp利用捎帶ack和nagle演算法 來...