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

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

BBR Summary