談起網絡擁塞控制，大家可能很熟悉八股文中的“加法增大“、”乘法減小“、”慢開始“、“擁塞避免”、“快重傳”、“快恢復”等概念。沒錯，這是一種經典網絡擁塞控制算法的基礎理論，但在實際的實現時不同的擁塞控制算法，有很大差別。本文從Linux內核源碼中學習網絡擁塞控制算法的具體實現框架。從當前網絡擁塞控制算法的發展歷程上看，網絡擁塞控制算法的類型主要有以下四種：

基于丟包的擁塞控制算法，這類算法將丟包視為發生了網絡擁塞。采取緩慢的探測方式，逐漸增大擁塞窗口，當出現丟包時，將擁塞窗口減少，代表的算法有Tahoe、Reno、NewReno、BIC、Cubic等。

基于延時的擁塞控制算法，這類算法將延時增大視為發生了網絡擁塞，延時增大時減少擁塞窗口，延時減少時增大擁塞窗口，代表的算法有Vegas、Westwood等。

基于鏈路容量的擁塞控制算法，代表算法是BBR，其采用了另類的方式，不再使用丟包、延時等信號去衡量擁塞是否發生，而是直接對網絡建模來避免以及應對真實的網絡擁塞。

基于學習的擁塞控制算法，這類算法也沒有特定的擁塞信號，一般是基于訓練數據、評價函數，通過機器學習生成網絡擁塞控制策略模型，代表算法有Remy、PCC、Aurora、DRL-CC、Orca等。

由于每類擁塞控制算法的核心理念有很大差別，關于每種算法的實現與原理在后續的文章中進行呈現。

本次文章先對Linux內核中網絡擁塞控制實現細節、大致框架，進行分析和大概學習。在進行正式的分析前先簡單梳理一下常識與概念：

什么是網絡擁塞：網絡擁塞是指在網絡中傳輸的數據量超過網絡鏈路或節點的處理能力，導致網絡延遲增加、丟包率升高和帶寬利用率下降的現象。

窗口（Window）：如下圖的TCP協議頭中占據16位，用于接收端告訴發送端還有多少緩沖區可以接收數據。

滑動窗口、發送窗口：下圖所示黑色方框代表發送窗口。滑動窗口只是一種形象的稱呼，即發送窗口一直移動從而達到發送新的數據的目的，如下圖當接收到接收端發來的ACK數據包后發送窗口向右移動。圖中灰色的方框代表已經發送且確認的數據，紅色代表已發送且剛剛確認的數據，正是因為剛剛確認了5byte的數據，才驅動發送窗口可以向右移動5個單位，使得序號52~56的數據（綠色方框，代表允許發送的待發送數據）可以發送，當37 ~51區間的數據（藍色方框，代表發送但未確認的數據包）能夠被確認時，發送窗口才能向右滑動。發送窗口前方的數據（黃色方框，不允許發送的待發送數據）只能等待發送窗窗口區間內才能發送。TCP的滑動窗口是動態的，我們可以想象成小學常見的一個數學題，一個水池，體積V，每小時進水量V1，出水量V2。當水池滿了就不允許再注入了，如果有個液壓系統控制水池大小，那么就可以控制水的注入速率和量。這樣的水池就類似TCP的窗口。應用根據自身的處理能力變化，通過本端TCP接收窗口大小控制來對對對端的發送窗口流量限制。

擁塞窗口：上面介紹了發送窗口的概念，在TCP協議中有一個反映網絡傳輸能力的變量，叫做擁塞窗口（congestion
window），記作cwnd。發送端實際的發送窗口大小實際是為 接收端通告窗口 rwnd 與 擁塞窗口 cwnd 較小的那個值。

W=min（cwnd，rwnd）