既然 BBR 想要解決的是 bufferbloat 問題，那麼為什麼路由器 buffer 要做那麼多？

就是說，如果路由器 buffer 少一點，這樣就可以沒存儲幾個包就愉快得扔掉，不就沒有bufferbloat問題了咩？

當然我知道這樣會讓丟包率變大，對某些場合有很大影響，那麼有沒有比bbr更好的方法呢？

就是說，如果路由器buffer少一點，這樣就可以沒存儲幾個包就愉快得扔掉，不就沒有bufferbloat問題了咩？

首先，這個理解是對的！

早期的存儲晶元，尤其是高速存儲晶元價格非常昂貴，這也使得那時候的網路設備緩存足夠小。
同時，在那個時候tcp的擁塞控制走上基於丟包這條道路時並沒有顯現出多少問題，各項實測，比如延遲，吞吐，。。。，都表現良好，以至於後來基於丟包的擁塞控制廣泛鋪開，並且大家的研究都走在了這條路上（經歷了二三十年）。

後來，存儲價格下降，各大設備製造商為了突顯自己設備的高大上（根據大家對計算機設備的常理性認識，RAM要夠大），開始盲目加大緩存，以便做到儘可能少丟包，但實際上這種做法違背了IP網路的設計初衷（允許丟包，且該丟就毫不猶豫丟掉）。因此大緩存為Bufferbloat問題提供了基礎條件，再加上網路中TCP大量使用基於丟包的擁塞控制演算法（丟包才觸發速度下調，但是要丟包，緩存就得先被填滿，緩存都填滿，延遲最高），典型的先污染後治理策略，Bufferbloat問題越來越嚴重。

我理解起來，這算是一種誤入歧途。

另外，緩存增大也並非完全是壞事，在數據中心的傳輸中，涉及到TCPinCast問題，增大緩存則是緩解問題的策略之一。這裡不展開，感興趣的可以自己google.

關於bufferbloat問題的處理可以參考（Introduction - Bufferbloat.net）
我截取一部分，就不做翻譯了，我想關注這個問題的都有能力看懂。

There are three main tactics:

First, we can pay attention! Bufferbloat is easy to test for once you know how to spot it. Testing for bufferbloat and fixing it needs to be part of the normal duties of every device designer, software driver author, and every network administrator. Some fixes are easy enough for Aunt Tilly to install.

Second, we can decrease unmanaged buffer sizes. This cuts the delay due to buffering and decreases the clumping effect on the traffic. It can increase packet loss, but that problem is coped with pretty well by the Internet』s normal congestion-avoidance methods. As long as packet losses remain unusual events (below the levels produced by bufferbloat cascades), resends will happen as needed and the data will get through.

Third, we can use smarter rules than FIFO for when and by how much a buffer should try to empty itself. That is, we need buffer-management rules that we can expect to statistically smooth network traffic rather than clumpifying it. The reasons smarter rules have not been universally deployed already are mainly historical; now, this can and
should be fixed.

如果理解有誤，歡迎指正並補充！

------------------------------------- 補充一下（2016-12-16） -----------------------------------
我認為每一個網路相關的開發/測試/運維/管理/。。。/都應該了解Bufferbloat問題。
因為緩存滿的問題我們遇到後通常的簡單做法就是先調大緩存，殊不知這種不經意的「偷懶」的做法對於整個網路可能是一種「作惡」。
不僅僅是網路，我們程序中各種隊列也可能面臨這個問題，比如線程間的消息隊列，當隊列滿的時候，問題的根本可能不是隊列太小，而是生產線程產出的速度大於消費線程消費的速度，這時候應該（1）檢查消費線程的瓶頸；（2）反饋給生產線程，如果就是性能/資源達到上限，要從源頭慢下來；

--
XTao

手機碼字 簡單說說要點：

這個問題要從當初設備(router)為什麼引入Buffer說起了，TCP發包具有burst的行為，同時埠上還可能有Incast現象(DC中非常常見)，因而即使網路設備的轉發能力是夠的，但是瞬時擁塞仍然導致丟包很嚴重，而Reno、Cubic又是對丟包十分敏感的，可從throughput的計算公式：
throughput = min(BW, MSS/RTT*sqrt(p), CWND/RTT)得到。
所以為了提高吞吐率，就得減少丟包率，就得有Buffer來緩存了。之前的網路都是以吞吐率為第一目標，所以一般都會有rtt*C的 buffer大小 。

然而隨後問題來了，即bufferbloat，tcp是貪婪的上探的，沒有丟包的話，一直增加窗口，所以 排隊時延就被無情的增加了。
隨著DC 以及公網上 時延敏感業務的出現，如何降低時延成為更加重要的問題。

所以又有了一門新興的學科，即 AQM
BBR類似的擁塞控制演算法就是為了解決這個問題，因為第二BDP並不能提高總體帶寬，所以存在也就沒必要了。

按照經典的拇指法則或者說經驗法則，路由器需要給每個埠配置的
buffer=埠速率×250ms
早期的路由器設計基本也都遵循這個原則，當然250ms也許會調整為200ms，這個250ms基本上也就是跨越半個星球的最大RTT 時間了

這個法則源於1994年時對於high perfomance tcp的研究，當時的測試表明大的buffer有助於提高路由器的tcp吞吐

2004年以後，斯坦福大學的一些研究者提出其實路由器不需要那麼大的buffer, 因為94年的測試只測了少量的tcp flow,而對於核心路由器來說實際承載的tcp flow數量非常大，而且大量的非tcp以及短tcp連接其實對buffer並沒有要求，而需要buffer來保證的tcp長連接 flow的吞吐曲線也並不會同時增長和降低，也就是非同步狀態，所以其實路由器每個埠的buffer只需要=(埠速率×RTT )÷sqrt(flow數量)
也就是說tcp的flow數量越大，需要的buffer其實是越小的
這種理論在實際測試中也得到了證實，所以後來的路由器設計已經不再嚴格遵循250ms buffer的經驗法則，但因為實際網路環境里的數據流非常複雜，高端路由器還是會採用比較大的buffer,一般給每個埠配置幾十ms的buffer就夠

另外更激進的一種提法是只需要給每個埠配置少於100個packet的極小buffer就可以了，測試表明這樣的buffer同樣也能達到較高的帶寬利用率，問題是會造成丟包率上升，因為傳統的tcp擁塞控制演算法非常依賴丟包率，因為丟包造成的等待和重傳會造成tcp的有效吞吐隨著丟包率上升而下降，所以這種tiny buffer的設計只適合輕載和rtt很小的網路環境，比如數據中心內部，所以現在許多數據中心交換機的埠buffer配置也非常小了，就只緩存幾個ms的buffer

另外buffer的容量其實也受限於高性能內存技術的發展，普通內存並不能滿足路由器的要求，所以路由器器需要配置sram,rldram ,gddr,hma,hbm這些高性能內存，其成本，容量以及功耗也都會限制路由器上大容量緩存的採用

AQM現在很大一部分工作都是為了解決bufferbloat的問題，現有的fq-codel就是一個很好的解決方案，但是主要是丟包對TCP協議性能不太好，可能是解決思路不一樣吧，感覺BBR想從TCP協議本身來需求突破，AQM相對來說更友好些，在中間節點，路由轉發上做，適用性更強些，針對全部的數據包類型不單單是TCP，不過根據最近的時延，BBR好像在無線環境下的效果還有待提高或者說不太適應無線環境場景下。

首先明確一點，路由器設計成很大的緩存，是錯誤的！

我覺得路由器的buffer是用來平滑泊松分布的包到達和固定速率的包發送之間的關係的，這也是分組存儲轉發的根本。所以轉發節點一定要有buffer。至於路由器上的buffer為什麼要那麼大，我覺得這是一個錯誤的設計，不應該那麼大的。

可以把路由器的越來越大的buffer以及TCP兩者看作是另一個「安迪-比爾定律」。因為BBR之前的TCP擁塞演算法都是盲目且貪婪的，路由器加大的buffer總是能被TCP快速拿走，反過來大緩存延遲了TCP的丟包，同時增加了丟包的成本，這要求路由器增加更多的緩存。具體來講就是，如果路由器緩存過小，基於丟包的擁塞演算法固有的全局同步現象將會使得帶寬的利用率極低，所以比如增加緩存來彌補。這就是一個循環，肇事者可以說是基於丟包的TCP演算法，它促進緩存越來越大，當緩存越來越大，TCP又會瞬間用完，永遠喂不飽，直到永遠。