在 TCP 中，擁塞窗口和接收窗口的最小值，是任意時刻內發送方確定能被髮送出去的字節數。
擁塞窗口受擁塞控制的影響，接收窗口受流量控制的影響，以下會分別介紹擁塞控制和流量控制。
擁塞控制與流量控制本質上來說，是生產者消費者的模型，如下圖所示：
擁塞控制
目的：通過減少發送方發送的數據量，起到阻止發送方到接收方之間的鏈路變得擁塞的目的。
實現：擁塞控制通過擁塞窗口實現，擁塞窗口由發送方維護，通過預估鏈路的擁塞程度實現。
好奇如我，如果看到上面的實現的定義，肯定會三連問，什麼叫預估鏈路的擁塞程度？用什麼標準判斷鏈路是否擁塞？擁塞發生了怎麼緩解擁塞？
別急，在思考上面的問題的時候，先思考個小問題，「你跟好朋友約飯，你怎麼預估她來的路上是否堵車呢？」
答：很弱智的問題是不是，2019 年了，各種地圖軟件打開看看就能猜到了，那讓我們在深入思考下，地圖軟件怎麼評估哪個路段是否是堵車呢？
車輛有個天然的屬性就是速度，取出歷史和當前同一時刻數據，判斷當前數據 - 歷史數據的差值，若爲整數，則下一時刻堵車的概率低；若爲負數，則下一時刻堵車的概率高
讓我們回到問題的主線上：
-
什麼叫預估鏈路的擁塞程度？
基於歷史數據判斷未來鏈路發生擁塞的可能性稱之爲「預估鏈路的擁塞程度」
-
用什麼標準判斷鏈路是否擁塞？
- 基於丟包的：如 Reno、Cubic
- 基於時延的：如 Vegas、FastTCP (tcp 單邊加速)
- 基於鏈路容量的：如 BBR
- 基於學習的：如 Remy
注：各種擁塞算法的實現，有興趣請自行 google ，或者看下參考資料 （ps 主要是我自己也看的一頭霧水，而照抄別人的感覺沒啥意義
-
擁塞發生了怎麼緩解擁塞？
送分題，減少發送的數據被，但是難點在於按照什麼策略減少，是直接減少到 0 ，什麼都不發了，還是按照某種策略減少發送的數據。
就好像沒有一個東西能夠滿足所有場景一樣，各種擁塞控制算法只是在側重點上有所不同，並無好壞之分。不過有是否過時之分，畢竟互聯網誕生之初，並沒有這麼高的帶寬。
改進擁塞控制算法我目前理解就是兩點：
- 如何快速的讓擁塞窗口達到最大值
- 發什麼擁塞的時候，如何儘可能少的減少擁塞窗口的值
本質上還是如何充分的利用帶寬，不過還有一個 tcp 公平性的問題，在設計擁塞算法的時候需要考慮，先在腦子裏留個概念吧，細節有空補補。
流量控制
目的：減少發送方發送的數據量，起到緩解接收方壓力的目的。
實現：接收方控制發送方發送的數據大小，每次應答的時候通知發送方自己還剩餘多少空間可以接受數據。
流量控制的實現是基於滑動窗口實現，具體細節如下：
- 接收方在 TCP 首部中的「窗口大小」字段寫入自己可接受的緩存區大小，通過 ACK 包發送給發送方
- 「窗口大小」是發送方最多可發送的不需要 ACK 的字節數
問：接收方發現自己的緩存區滿了要怎麼處理？
答：將 TCP 首部的「窗口大小」設置爲 0，此時發送方將不再發送數據，但需要定期發送一個窗口探測的數據包，是發送能夠在窗口有空餘的時候繼續發送數據。（ps 不過這裏爲什麼不是接收方主動通知呢？是因爲不知道要發什麼包嘛，還是主動推的話協議會複雜化，只是我也不知道……
寫在最後，最近拖延症晚期，先寫一點是一點吧……