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

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

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

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

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

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

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

什么是網(wǎng)絡擁塞：網(wǎng)絡擁塞是指在網(wǎng)絡中傳輸?shù)臄?shù)據(jù)量超過網(wǎng)絡鏈路或節(jié)點的處理能力，導致網(wǎng)絡延遲增加、丟包率升高和帶寬利用率下降的現(xiàn)象。

窗口（Window）：如下圖的TCP協(xié)議頭中占據(jù)16位，用于接收端告訴發(fā)送端還有多少緩沖區(qū)可以接收數(shù)據(jù)。

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

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

W=min（cwnd，rwnd）