比威而鋼還威的 TCP BBR

前一陣子從 iThome 看到了 Google 要把 TCP BBR 應用在 Google Cloud Platform 的新聞， 才發現原來這東西這麼神，2700 倍的傳輸率，佇列延遲減少 25 倍，隨手翻了下網路上的部落格，沒想到有那麼浮誇的說法證明：下載從 84K/s 變成 3.9M/s，這立刻引起我的好奇心，找到了 Google 自己的部落格說明，原來是長久以來使用的 TCP 壅塞控制演算法有點笨，遇到有 packet loss 的狀況時，就會以比較保守的方式來傳遞接下來的封包，而新的 TCP BBR 則用了比較聰明的方法來處理 packet loss 的問題，整個示意圖就如下所示：

* Source

文中也特別拿了幾個國家為例子，說明在應用了 TCP BBR 之後，YouTube 的表現情形，不看還好，一看之下，沒想到 Google 也這麼浮誇寫實，YouTube 到 ID 的 Max Round-Trip time 竟然可以改善到 50% 以上，這讓我突然想到以前公司在進行某個網路直播專案時，那個爛 4G 網路讓我們驗收時吃了很多苦頭，所以我也來做個浮誇的測試好了。不過因為一來我很懶，二來也沒那個預算搭建回當初專案的原始架構，所以以下浮誇的測試只在我的本機上實驗。

• 實驗環境 (都在同一台機器裡)：

NB: OBS Studio 19.0.3 --> NB: clumsy-0.2 --> VM: SRS 2.0.242 + CentOS 6.9 --> NB: flv.js in Chrome

• 實驗方法：

1. 先以 Kernel 2.6.32-696.6.3 直接測試，擷取螢幕看直播視訊延遲
2. 以 clumsy 加上 inbound & outbound 各 50ms 的延遲，並隨機 drop 10% 的封包
3. 等個幾秒，擷取螢幕看直播視訊延遲
4. 停止 clumsy，等個幾秒，擷取螢幕看直播視訊延遲
5. 升級 Kernel 為 4.13.0-0.rc1，重複步驟 1~4
   * 我拿了一個 Firefox 開時鐘來讓 OBS 擷取螢幕畫面，所以測試畫面中會看到 Firefox

• 實驗結果：

1. 沒 TCP BBR，不啟用 clumsy，延遲大概 3 秒
   
2. 沒 TCP BBR，啟用 clumsy，稍等一下，延遲變為 13 秒，實測時這個延遲會迅速擴大，最差的狀況是影像會停掉
   
3. 沒 TCP BBR，把 clumsy 關掉，稍等一下，延遲回到 5 秒左右
   
4. 有 TCP BBR ，不啟用 clumsy，延遲大概 2-3 秒，其實和沒 BBR 時差不多，這畫面看起來延遲只有 2 秒應該只是個測試誤差
   
5. 有 TCP BBR，啟用 clumsy，稍等一下，延遲變為 4 秒
   
6. 不信邪，再等一等，有 TCP BBR，啟用 clumsy，延遲還是維持 4 秒左右
   
7. 恢復原狀，有 TCP BBR，不啟用 clumsy，延遲還是維持 4 秒不動
   

總結來看，這個 TCP BBR 還真的神，在高延遲且掉包的網路上，在我的測試環境 1 個 client 對 1 個 server 的情境下就能有這麼好的表現，安裝的方法我就不特別提了，網路上隨便 google 都一堆，不過還是要提醒大家一下，再好的東西還是得先測試才能上正式環境，免得哪個不小心你就踩了坑了都不知道。