這篇文章的寫作動(dòng)機(jī)來源于知乎上的一個(gè)問題，有人問既然Bufferbloat是個(gè)問題，為什么路由器的緩存還要設(shè)計(jì)那么大。起初，我也是覺得緩存越大越好，這個(gè)就像人們拼命比拼誰的電腦內(nèi)存大一樣，因?yàn)樵谝话闳搜劾?#xff0c;內(nèi)存越大就越快！然而對(duì)于網(wǎng)絡(luò)而言，恰好相反，內(nèi)存越大，越讓人不想歸家。
??????? 酒店舒適，但只是路過，沒人會(huì)把家裝修成酒店的樣子，家才是越大越好。
??????? 路由器設(shè)計(jì)成攜帶大緩存的設(shè)備，這是一個(gè)錯(cuò)誤！路由器不該有那么大的緩存，然而TCP大牛當(dāng)年的一個(gè)“AIMD錯(cuò)誤決定”讓路由器的緩存越來越大，最終引發(fā)了Bufferbloat！事情還要從安迪-比爾定律說起。

網(wǎng)絡(luò)上的“安迪-比爾定律”

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

Bufferbloat問題

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

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

劣幣驅(qū)良幣

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

BBR開始為網(wǎng)絡(luò)添堵

永遠(yuǎn)不要欺負(fù)老實(shí)人，BBR開始做損人不利己的事了。在中國，所有的TCP擁塞控制算法都無法被公正評(píng)估，請(qǐng)注意，這個(gè)修改的意義在于，BBR對(duì)于自身的性能沒有任何提升，只是為了損人而已。我跑得慢，我踹你一腳把你整瘸了，你會(huì)更慢，這樣我就第一了，競(jìng)速，競(jìng)速而已！
??????? 那么，這件壞事如何來做呢？
??????? 我的第一個(gè)版本不公開，事實(shí)證明它更有效，起碼上了我的版本，別的就沒的跑了，但問題是上兩個(gè)我的版本，他倆雙胞胎也會(huì)打架打得頭破血流...本著和諧共存的原則，我從不教人學(xué)壞，所以我會(huì)刪除并忘掉代碼，再不提起。我這里給出稍微溫和點(diǎn)的版本，兄弟倆打架的情況依然存在，但不嚴(yán)重，問題是，如何區(qū)別對(duì)方是否是自家人...難！
??????? BBR計(jì)算總的最大發(fā)送量的時(shí)候，不是按照max-Bandwidth和min-RTT的乘積計(jì)算的嗎？我這里維護(hù)了一個(gè)最小RTT窗口內(nèi)的max-RTT，只要在一個(gè)最小RTT窗口內(nèi)的實(shí)際RTT不大于上一次的max-RTT，我就讓BBR使用這個(gè)實(shí)際的RTT而不是什么最小的RTT。這里的原則在于，BBR會(huì)嘗試在排隊(duì)不丟包的情況下也去主動(dòng)排隊(duì)，入鄉(xiāng)隨俗。
??????? 代碼非常簡(jiǎn)單，先為BBR增加一個(gè)字段，即max_rtt_us，與min_rtt_us相對(duì)，然后修改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之差就是排隊(duì)延遲，充分利用這個(gè)排隊(duì)延遲去添堵是一件簡(jiǎn)單的好事，但是如何去對(duì)抗AQM則是一件非常復(fù)雜的事，因?yàn)槟悴⒉恢繟QM的行為。以上的討論均建立在尾部丟包的基礎(chǔ)之上，然而現(xiàn)實(shí)情況則要面臨復(fù)雜的AQM，在文章《 Linux Kernel 4.9中TCP BBR算法的科普解釋》的“君莫舞，君不見玉環(huán)飛燕皆塵土”以及“BBR的優(yōu)勢(shì)之-與AQM的關(guān)系”兩節(jié)中，我有闡述BBR如何樂觀地等待CUBIC之流被懲罰以及如何愉快地上位，然而在“廣中路上匝道”情形中，CUBIC并不會(huì)被懲罰，BBR自然也就不會(huì)上位，那怎么辦，只能添堵，至于AQM怎么處理，一視同仁吧。換句話說，BBR在CUBIC以及任意所謂“TCP加速者”面前，不必客氣，他們抽煙，你就放火。

快遞或者網(wǎng)絡(luò)可靠嗎

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

新的Bloat版本的BBR算法

周日早晨，我登錄到了溫州老板提供的位于國外的VPS機(jī)器上，演繹了一個(gè)新版的BBR。也是添堵版的，在我的WIFI環(huán)境下碾壓了標(biāo)準(zhǔn)的BBR，這就好像魔人布?xì)W的分身一樣，一個(gè)是好人的時(shí)候，另一個(gè)必須是惡棍。
非常簡(jiǎn)單：

1.為bbr增加一個(gè)minmax類型的max_rtt字段

2.修改bbr_update_min_rtt函數(shù)

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與當(dāng)前RTT取其小！是不是拿最大RTT和最小RTT求個(gè)"平均"什么的更合理呢？ // 反正我是占點(diǎn)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連接早日崩潰，我祝愿互聯(lián)網(wǎng)越來越擁堵，最終不可用。

為什么BBR是合理的

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。