這篇文章的寫作動機來源于知乎上的一個問題，有人問既然Bufferbloat是個問題，為什么路由器的緩存還要設計那么大。起初，我也是覺得緩存越大越好，這個就像人們拼命比拼誰的電腦內存大一樣，因為在一般人眼里，內存越大就越快！然而對于網絡而言，恰好相反，內存越大，越讓人不想歸家。
??????? 酒店舒適，但只是路過，沒人會把家裝修成酒店的樣子，家才是越大越好。
??????? 路由器設計成攜帶大緩存的設備，這是一個錯誤！路由器不該有那么大的緩存，然而TCP大牛當年的一個“AIMD錯誤決定”讓路由器的緩存越來越大，最終引發了Bufferbloat！事情還要從安迪-比爾定律說起。

網絡上的“安迪-比爾定律”

先解釋一下安迪-比爾定律，即“比爾.蓋茨拿走了安迪.格魯夫所給的”。狹義的講就是無論Intel的芯片快到多么牛逼的地步，微軟的下一個Windows版本總是能把芯片的性能榨干，然而廣義的講，安迪-比爾定律連同摩爾定律一起事實上構成了信息產業的一臺泵，典型的一個正反饋系統，這是決定互聯網產業大爆發的本質原因，這個系統如下：
摩爾定律->硬件性能提升->軟件填補硬件提升的空間
我們可以理解為，摩爾定律和安迪-比爾定律驅動了信息革命的車輪不斷滾動從而碾壓一切！
----------------------------
可以把路由器的越來越大的Buffer以及TCP貪婪地占據這些路由器Buffer兩者看作是另一個“安迪-比爾定律”。因為BBR之前的TCP擁塞算法都是盲目且貪婪的，路由器加大的Buffer總是能被TCP的AI(加性增窗)過程快速榨干，反過來大緩存延遲了TCP的丟包，同時增加了丟包的成本，這要求路由器提供更多的緩存。
??????? 具體來講就是，如果路由器Buffer過小，基于丟包的擁塞算法固有的全局同步現象將會使得帶寬的利用率極低，所以必須增加Buffer來彌補。這就是一個正反饋循環，肇事者可以說是基于丟包的TCP算法，它驅動了路由器Buffer越來越大，當Buffer越來越大，TCP又會瞬間用完，永遠喂不飽，直到永遠。
??????? 好在有摩爾定律和TCP的MD(乘性減窗)過程二者從中協調，如果同時失去了二者，TCP早晚會全局崩潰！
??????? 我們假設硬件已經逼近了熱密度的極限，摩爾定律失效了，此時不會再增加Buffer的大小了，會發生什么呢？
??????? 只要有TCP的MD過程在，互聯網就不會崩潰，所以說，TCP的AI過程保障了其效率，而MD過程則保證了收斂。
??????? Google的新擁塞控制框架來了以后，MD過程便不被保證了，任何人都可以寫一個永不降窗的算法，如果把主動的MD過程看作道德的話，那么路由器的AQM就是法律了。這就是TCP/IP的幾乎全部內容了，我們可以看到，它極其復雜。
??????? 值得注意的是，TCP/IP的安迪-比爾定律展現的這種復雜性，其促進因素不是摩爾定律，而是“人們對帶寬的高利用率的追求”，因此便有了以下的關系：
提高帶寬利用率->路由器加大Buffer->TCP的AIMD填補加大的Buffer
其實，這完全是錯覺，TCP/IP的框架不該這么復雜的。或許，AIMD根本就不需要，事實上，是路由器不斷加大的Buffer和AIMD一起縱容了壞事的頻繁發生。這一點正如人們不斷買新電腦，不斷買新手機，然而過不了多久，你依然會發現不管再新的機器都卡的要死一樣的道理，只不過，人們買的電腦也好，手機也好，它們的更新換代是摩爾定律驅動的，機器完全是個人所有的，你隨時可以跟著摩爾定律的節奏更新換代，然而對于網絡設備卻不是這樣。
??????? 網絡設備，比如路由器，交換機之類，它們只是整個TCP/IP系統的一個環節而已，機房里面的設備是不可能頻繁更新換代的，摩爾定律幾乎被它們所無視。雖然摩爾定律依舊影響著設備的實際制造和升級，但由于這種周期相對較長，也就是可以忽略的了。但這里面有一個不變的定論，那就是TCP幾乎全部都是以AIMD原則來運作的，UDP則是無限貪婪的。TCP的AI會造成主動丟包，這也是基于丟包的擁塞控制算法的核心，而MD會造成全局同步，這兩點無疑造成了帶寬利用率的低下，這是TCP的硬傷，不得不靠不斷加大的路由器Buffer來彌補，至少是延遲了悲劇的發生，在延遲悲劇的這段時間內，路由器當然希望端系統可以意識到事情正在悄悄起變化并采取一些措施。
......
AIMD，正如以太網的CSMA/CD一樣，并不完美，但是可用。現在的人們在千兆以太網出現之前，曾經推導出一個結論，那就是依靠CSMA/CD是不可能達到千兆bps的，然而如今已經是萬兆甚至4萬兆了...如果說以太網的載波監聽，沖突檢測是不必要且可被替換的，那么TCP的AIMD也是不必要且可被替換的，二者簡直太像了！

Bufferbloat問題

我不想說TCP的AI/MD(加性增和乘性減)是錯誤的，我也不敢給出如此決絕的否定，然而，至少我想表達的是，在“安迪-比爾定律”的作用下，AI/MD是有問題的！什么問題呢？Bufferbloat問題！
??????? 再次重申，路由器攜帶很大的Buffer，是錯誤的！路由器Buffer在夠用前提下越小越好，沒有Buffer，自然就不會bloat，本來無一物，何處惹塵埃？！但是不能沒有Buffer...Buffer到底是用來干什么的？到底多少合適？
??????? Buffer其實就比較類似我們吃的食物，曾經，在物資貧乏的年代，大家都在追求要多吃，現在營養過剩了，則反過來了，要少吃，實際上，人體根本不需要太多的食物，夠用即可，人體大部分的精力要用來做更有意義的事情。同樣基于存儲/轉發TCP/IP網絡上的路由器其根本任務不是做存儲，而是做轉發，存儲只是在理論上不得已的一個手段。我來解釋下是為什么。
??????? 路由器的入口和出口分別接收到達的數據包和轉發數據包，一臺路由器上往往有多個接口同時全雙工地進行接收/轉發，數據包的到達頻率是統計意義上的，符合泊松分布，然而數據包的發送則是固有的接口速率，這是分組交換網的核心根基！路由器扮演什么角色？它是一個典型的多服務臺排隊系統！所以路由器必須攜帶一個Buffer用來平滑泊松分布的包到達和固定速率的包發送之間的關系。
??????? 那么，設計多大的Buffer合適呢？按照排隊理論的現成公式計算，夠用即可！
??????? 我們考慮極端一點的情況，如果我們把存儲隊列的Buffer設計成無窮大，從而轉發延遲也將是無窮大(因為排隊延遲會趨向無窮大)，會發生什么？無疑，這臺路由器將會變成一個超級存儲器，它將會擁有全世界所有的信息！
??????? 爆炸！轉發設備變成了存儲設備！這就是Bufferbloat。注意，Bufferbloat的惡劣影響并不是會造成丟包，而是會無端增加無辜連接的延遲。這里有個認識上的誤區，這種認識在中國人的思維中特別明顯。很多人會覺得Bufferbloat會造成“丟包反饋延遲增加”，其實丟不丟包是你自己的事，如果你通過RTT梯度檢測到了Bufferbloat，你依舊繼續猛發，結果被AQM給丟了，那完全是你自己全責，事實上，這個時候大家都應該全局MD才對。
??????? 真正的危害在于，由于Bufferbloat造成了整個大Buffer被填充，所有的數據包都將等待一個固有的排隊延遲，這會嚴重影響任意經過的實時類應用！千萬別扯什么QoS，區分服務，綜合服務，流量工程什么的，這些要真有用，120救護車就不會被堵在路上了，請注意，事在人為，事在人不為。
----------------------------
我最喜歡的其實不是TCP/IP網絡什么的，而是城市規劃，道路規劃以及機械設計(2002年我的專業就是機械工程)，我只是在2004年的時候初識了路由器，交換機之類的東西，發現自己竟然可以不用挖地鏟土澆筑建橋就可以完成一條自己想象中的道路，并且還有那么多的現實場景，這不禁可以讓人隨時進入禪境...實際上，關于城市規劃，道路規劃以及機械設計也有很多電腦上的模擬器，但問題是它們畢竟只是模擬，是不真實的，而路由器，交換機是真實的，它們就擺在那，登錄設備打開Monitor，我看到的是真實的東西，這與模擬器有大不同。
??????? 在后來的學習中，我發現路由器交換機之上有個TCP/IP，折騰起來一點也不比挖地鏟土澆筑建橋來的輕松，但至少除了搬機器，上架，插線之外，沒有什么體力活了，也還好。
----------------------------
路由器Buffer是什么？以高架路為例，它相當于上匝道前面的位置：

圖中的匯入區就相當于路由器的Buffer，可以看出，如果匯入區過大的話，單位時間內就會有更多的車輛匯入主線，當這個量超過主線流量的時候，就會造成匯入區擁堵，同時大大降低主線的通行能力。這意味著，很多無辜的車輛被堵在了匯入區，主線上的車輛也會由于匯入去有大量車輛匯入而顯示擁堵跡象，我給出給具體的例子吧，那就是上海南北高架廣中路由南向北上匝道，那個匯入區太長了，足足200米+，結果造成那個位置幾乎持續擁堵，不光廣中路上匝道新上南北高架的車輛走不動，就連主路上的車輛也被擁堵，這是什么造成的？這是錯覺造成的！廣中路上匝道下面準備上高架的司機一看匝道是空的，唰唰全上去了，結果堵在匯入區了...
??????? 如果廣中路上匝道的匯入區修的短一些，那么擁堵只會體現在上匝道或者廣中路路口，這種擁堵反饋到準備上高架的司機那里，結果就是，要么等，要么繞，至少會阻止他們上主線匯入區去添堵，傷害無辜的流量。
??????? 好了，該回到TCP了。路由器Buffer減小有什么好處呢？好處在于，即使有連接拼命去AI添堵，那么丟包會很快到來，并且很快反饋給發送方，于是發送方會執行MD以表示懺悔，整個過程中，實時流量不會受到絲毫影響。

劣幣驅良幣

BBR是什么我就不解釋了，我寫了很多文章。這些文章中沒有提到的是，BBR屬于那種即便上匝道匯入區修的再長也不上去添堵的德國好司機。那么結果是什么？你以為這種行為會感動全中國嗎？
??????? 錯了，這正是中國人所期許的，你謙讓，我就流氓。你不去堵，我去堵。結果就是，BBR即便不去主動添堵，也會被其它人堵在路上，BBR只能說，這擁堵不是自己造成的，僅此而已。吃虧做好事又不被認可反被訛，這是我們這里常有的事，BBR到了中國應該入鄉隨俗，你堵，我也堵！

BBR開始為網絡添堵

永遠不要欺負老實人，BBR開始做損人不利己的事了。在中國，所有的TCP擁塞控制算法都無法被公正評估，請注意，這個修改的意義在于，BBR對于自身的性能沒有任何提升，只是為了損人而已。我跑得慢，我踹你一腳把你整瘸了，你會更慢，這樣我就第一了，競速，競速而已！
??????? 那么，這件壞事如何來做呢？
??????? 我的第一個版本不公開，事實證明它更有效，起碼上了我的版本，別的就沒的跑了，但問題是上兩個我的版本，他倆雙胞胎也會打架打得頭破血流...本著和諧共存的原則，我從不教人學壞，所以我會刪除并忘掉代碼，再不提起。我這里給出稍微溫和點的版本，兄弟倆打架的情況依然存在，但不嚴重，問題是，如何區別對方是否是自家人...難！
??????? BBR計算總的最大發送量的時候，不是按照max-Bandwidth和min-RTT的乘積計算的嗎？我這里維護了一個最小RTT窗口內的max-RTT，只要在一個最小RTT窗口內的實際RTT不大于上一次的max-RTT，我就讓BBR使用這個實際的RTT而不是什么最小的RTT。這里的原則在于，BBR會嘗試在排隊不丟包的情況下也去主動排隊，入鄉隨俗。
??????? 代碼非常簡單，先為BBR增加一個字段，即max_rtt_us，與min_rtt_us相對，然后修改update RTT和calc CWND的邏輯：

1.修改bbr_update_min_rtt

/* Track min RTT seen in the min_rtt_win_sec filter window: */ filter_expired = after(tcp_time_stamp,bbr->min_rtt_stamp + bbr_min_rtt_win_sec * HZ); if (rs->rtt_us >= 0 &&(rs->rtt_us <= bbr->min_rtt_us || filter_expired)) {bbr->min_rtt_us = rs->rtt_us;bbr->min_rtt_stamp = tcp_time_stamp;bbr->rtt_us = rs->rtt_us;if (filter_expired)bbr->max_rtt_us = rs->rtt_us; } bbr->rtt_us = bbr->min_rtt_us;if (!filter_expired && rs->rtt_us >= 0 && rs->rtt_us < bbr->max_rtt_us) {bbr->rtt_us = rs->rtt_us; }

2.修改bbr_target_cwnd

if (inet_csk(sk)->icsk_ca_state != TCP_CA_Open)w = (u64)bw * bbr->min_rtt_us; elsew = (u64)bw * bbr->rtt_us;
----------------------------
最大RTT和最小RTT之差就是排隊延遲，充分利用這個排隊延遲去添堵是一件簡單的好事，但是如何去對抗AQM則是一件非常復雜的事，因為你并不知道AQM的行為。以上的討論均建立在尾部丟包的基礎之上，然而現實情況則要面臨復雜的AQM，在文章《 Linux Kernel 4.9中TCP BBR算法的科普解釋》的“君莫舞，君不見玉環飛燕皆塵土”以及“BBR的優勢之-與AQM的關系”兩節中，我有闡述BBR如何樂觀地等待CUBIC之流被懲罰以及如何愉快地上位，然而在“廣中路上匝道”情形中，CUBIC并不會被懲罰，BBR自然也就不會上位，那怎么辦，只能添堵，至于AQM怎么處理，一視同仁吧。換句話說，BBR在CUBIC以及任意所謂“TCP加速者”面前，不必客氣，他們抽煙，你就放火。

快遞或者網絡可靠嗎

現在人們沒了互聯網就不能生活，這也是一種錯覺。
??????? 其實互聯網本身就是一種錯覺，它是一種不得已而為之的錯覺！
??????? 去年1月我去深圳萬象城(之所以說萬象城而不是人人樂，我是想說我買的東西有多么高大上，以至于我多么迫不及待地想擁有)買東西，無貨，咋辦？店主說次日可取，他們從廣州拿貨。現在問題來了，去一趟廣州難嗎？為什么我自己不直接去廣州買，還要深圳萬象城去廣州拿貨后再賣給我？因為我沒時間！如果我有大把的時間又那么喜歡那件物品，我肯定自己去廣州了，順帶旅游，然而我缺的正是時間。
??????? 快遞業務填補了人們的時間間隙。但是快遞業務真的可靠嗎？
??????? 如果我自己去廣州拿貨，假設高鐵不脫軌，汽車不翻車，自己不被人捅的情況下，一路上我愉快地去，拿到貨后愉快地歸來，一路上我親自護送貨品，我放心，我踏實。如果交由快遞，我不知道快遞車會不會翻車，會不會被人搶，里面會不會是假貨...一切我都不確定，在送到我手里前，我只能禱告~！但好處在于，這段送貨的時間，在我信任快遞公司的前提下，我可以做別的工作，如果我不信任快遞公司，我只能心急如焚。好在，現在的快遞公司，特別是順豐還算靠譜，你不需要心急如焚。
??????? 但是網絡，其可靠性完全是另一回事，幸虧人們用了TCP，不然就別玩了。字節的復制往往比絲帛的織造更加廉價，所以TCP有一個存儲重發的機制，發送信息前先存儲信息，一段時間沒有收到回應，就重發被存儲的信息，收到回應則將信息刪除，如果發了一批絲綢到遠方，一段時間沒有反饋，然后再去織一批新的，那代價可就大了去了...
----------------------------
我不親自去廣州而去委托快遞公司，正是因為我沒有時間，那么如果快遞公司的快遞過程“彌補”了我本應該節省的時間(比如快遞員懶惰)，我還不如自己去拿貨呢。
網絡也一樣，如果網絡的延遲太高，那還不如用U盤拷貝信息，用汽車運輸U盤，然后交付呢...網絡和快遞一樣，就是圖快，用專業的運輸代替你自己的自取。然而，如果網絡中有Bufferbloat，那么還不如去自取，甚至去用U盤拷貝。
??????? Bufferbloat讓網絡喪失了快速傳輸通道的名聲。

新的Bloat版本的BBR算法

周日早晨，我登錄到了溫州老板提供的位于國外的VPS機器上，演繹了一個新版的BBR。也是添堵版的，在我的WIFI環境下碾壓了標準的BBR，這就好像魔人布歐的分身一樣，一個是好人的時候，另一個必須是惡棍。
非常簡單：

1.為bbr增加一個minmax類型的max_rtt字段

2.修改bbr_update_min_rtt函數

filter_expired = after(tcp_time_stamp,bbr->min_rtt_stamp + bbr_min_rtt_win_sec * HZ); if (rs->rtt_us >= 0 &&(rs->rtt_us <= bbr->min_rtt_us || filter_expired)) {bbr->min_rtt_us = rs->rtt_us;bbr->min_rtt_stamp = tcp_time_stamp;bbr->rtt_us = rs->rtt_us; } bbr->rtt_us = rs->rtt_us; rtt_prior = minmax_get(&bbr->max_rtt); // 迄今為止最大的RTT與當前RTT取其小！是不是拿最大RTT和最小RTT求個"平均"什么的更合理呢？ // 反正我是占點Buffer空間 bbr->rtt_us = min(bbr->rtt_us, rtt_prior);minmax_running_max(&bbr->max_rtt, bbr_bw_rtts, bbr->rtt_cnt, rs->rtt_us);
我祝愿所有的TCP連接早日崩潰，我祝愿互聯網越來越擁堵，最終不可用。

為什么BBR是合理的

AIMD是基于丟包的擁塞控制算法的根基，這必然會Buffer bloat，解決之道就是不采用基于丟包的算法，而采用基于時延的算法，但是....
??????? 但是只要有一個基于丟包的算法還跑在互聯網上，那么所有基于時延的算法都會集體退讓...這是基于時延算法弊端，既然它基于時延而不是丟包，那么它就是注定要吃虧的。正確的做法是什么？
??????? BBR無視丟包(也并非絕對，BBR在處理非Open狀態時還是有措施的)，無視時延(也非絕對，BBR只是無視了RTT的瞬時變化值)，采用了實時采集并保留時間窗口的策略，這初看起來是吃虧的算法，與基于時延的算法無異，但是BBR擁有Probe More和Drain Less過程，這非常合理。

??????? 合理的并不意味著是可用的。我依然祝愿所有的TCP連接早日崩潰，我祝愿互聯網越來越擁堵，最終變得不可用。我有一個夢想，每個人掄起鐵錘去煉鋼，少說多做，最好不說。

總結

以上是生活随笔為你收集整理的深夜聊聊Bufferbloat以及TCP BBR的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。