女主宣言

本文出自於ADDOPS團隊，該文章是一篇興趣觸發的探索性文章，作者是一名剛畢業的小鮮肉，買新系統，去自己探索bbr演算法，難能可貴，並且給出了詳細的部署步驟，也能讓大家在興趣之餘跟著步驟試一把，並且簡單描述了該演算法的使用場景和基本原理。bbr在劣質網路下能充分利用頻寬，並且也已經併入了新版本的核心，以後肯定有很大的使用場景。希望本文能給大家帶來一些啟發。

PS：豐富的一線技術、多元化的表現形式，盡在“HULK一線技術雜談”，點關注哦！

前言

Kernel 4.9 正式版本的釋出帶來了一些令人激動的特性以及一些驅動的更新。 其中來自 Google 的 TCP BBR (Bottleneck Bandwidth and RTT) 擁塞控制演算法也在這個版本併入了主線。

背景

幾個月前就在Github上fork了Google開源的神器BBR演算法，但是一直都沒有深入去分析研究。最近看Kubernetes相關的文件突然想起了這個神器，於是我大晚上的搭了一臺測試機對TCP BBR進行了測試。

根據以往的傳統，G家總是先在自家的生產環境上線運用後，才會將程式碼開源，此次也不例外。我在一臺代理伺服器節點上部署了TCP BBR 擁塞控制演算法。從電信出口到日本Vultr的實測下載速度從381KB/s提高到了4.26MB/s.

“

引用：補充測試環境說明：是在日本的Vultr伺服器上配置了 BBR，日本的伺服器是資料的傳送方。這個伺服器是訪問牆外資源的 HTTP 代理。我本地的電信出口到代理伺服器之間不是dedicated專線，走的是公網，電信出口這邊是 10Mbps 無限速（但是要跟其他人share），代理伺服器實測是限速1Mbps。RTT 是 96 ms。實測結果這麼好，也是因為大多數人用的是 TCP Cubic (Linux) / Compound TCP (Windows)，在有一定丟包率的情況下，TCP BBR 更加激進，搶佔了更多的公網頻寬。因此也是有些不道德的感覺。

對比分析

人類的公式都太依賴時間t了，人們總是希望在我們生存的三維空間裡儘量壓縮時間來提高效率。談到效率，那麼決定效率的一定是分母時間t嗎？不然，這個哲學問題有太多其他的答案了。

而之前的Reno/CUBIC之所以矇蔽了人類這麼久，正是因為程式設計師和CS科學家都是一群事件驅動的群體。他們在為TCP建立效能模型的時候，總是希望通過用Time-series/RTT-series analysis來查到一個連線最快能跑多少資料。

但是這些都是錯的，我們奉為神明的時間t的產物時間軸，具有滯後性這一致命的缺點。自從1973年TCP/IP被Prof. Vinton G. Cerf提出之後，諸如Reno/CUBIC等經典TCP擁塞演算法的目標都是收斂於一個邏輯滯後的收斂點，不斷地增加資料的傳輸，試圖填滿整個網路以及網路上的所有快取，以為這樣就會達到比較高的頻寬利用率，直到發現丟包，然後迅速降低資料傳送量，之後重新向那個錯誤的收斂點前進，如此反覆。這就是鋸齒的根源。而BBR則在一個不隨時間滑動的大概10秒的時間視窗中採集最小RTT，如果有更多的頻寬，那麼就利用它，如果沒有，就退回到之前的狀態。

以上就是Reno/CUBIC和BBR的區別，它們同樣完成了"To find current bandwidth", "To avoid congestion", "To probe more bandwidth"的邏輯，只是一個是事件驅動的被動實現，一個是反饋驅動的主動實現。

關於TCP BBR演算法分析，MSRA的李博傑博士在知乎上給出了這樣的解釋：

“

引用：TCP BBR 致力於解決兩個問題：

在有一定丟包率的網路鏈路上充分利用頻寬。

降低網路鏈路上的 buffer佔用率，從而降低延遲。

快速上手

如果你也想感受神器的強大，首先需要一臺linux 4.9核心版本以上的機器（現在居然已經出到4.10了，不過gregkh已經宣佈4.9將是LTS版本），為了不影響線上機器的正常執行，我在Vultr上買了一臺新的CentOS來測試=. =

要在 CentOS 上安裝最新的核心版本，我們需要增加一個 ELRepo 源。首先，讓我們新增 ELRepo GPG key：

rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org

之後新增 CentOS-7的 源：

rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm

安裝fastestmirror （Vultr的映象已經自帶了，保險起見，可以確定一下）

yum install yum-plugin-fastestmirror

最後，安裝 kernel 主線版本

yum --enablerepo=elrepo-kernel install kernel-ml

當然，將 kernel-ml 選為第一啟動

grub2-set-default 0

重啟後，通過 uname -a 檢視核心是否已經切換到最新版

$ uname -a

在確定安裝好了4.9以上版本核心之後，我們就可以開啟TCP BBR了。

sudo echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
sudo echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf

重啟後，首先 uname -a 看下核心是否切換，然後執行下面明亮檢視核心是否開啟 TCP BBR

sudo sysctl net.ipv4.tcp_available_congestion_control

sudo sysctl net.ipv4.tcp_congestion_control

檢視 tcp_bbr 模組是否載入

lsmod | grep tcp_bbr

如果已經載入成功，就可以愉快地開始測試了。

總結

最後需要提示一點，TCP 擁塞控制演算法是資料的傳送端決定傳送視窗，因此在哪邊部署，就對哪邊發出的資料有效。如果是下載，就應在server部署；如果是上傳，就應在client部署。

關於TCP BBR與標準TCP的公平性問題，我的觀點是如果伺服器都採用BBR，實際效果就歸於平均了，但總體資源利用率會有所提升，好在Google把BBR演算法併入核心mainline了。

如果你想用更加優雅的姿勢升級Kernel，請移步如何優雅的升級核心。