本文來自數字音樂服務商Spotify的科技博客，文章闡述了通過BBR為用戶提供了更大的下載帶寬，BBR是由Google開發的TCP擁塞控制算法，它旨在加快互聯網數據傳輸速度。LiveVideoStack對原文進行了摘譯。

Spotify如何播放音樂

Spotify的數據流的基本原理很簡單。我們將每個編碼的音樂曲目存儲為文件，復制到世界各地的HTTP服務器上。當用戶播放歌曲時，Spotify應用程序將從附近具有HTTP GET范圍請求的服務器以塊的形式獲取文件。其中，典型的塊大小為512kB。

我們希望我們的音頻播放能夠達到即時，且順滑流暢。為了保持這種效果，我們跟蹤兩個主要指標：

1，播放延遲，從點擊到音樂響起的時間。

2，Stutter，播放期間跳過/暫停的次數。

Stutter的發生主要是由于下載帶寬較低時音頻緩沖區欠載。因此，我們的指標與連接時間和傳輸帶寬密切相關。這些都是一些經典的參數。

那么，BBR是如何改善我們的流媒體的？

TCP擁塞什么？

我們細看一下從服務器到客戶端的文件傳輸過程。服務器以TCP數據包發送數據。客戶通過返回ACK確認交付。根據硬件和網絡條件，連接的容量就有限。如果服務器過快地發送太多數據包，它們就會被丟棄。服務器將其記錄為丟失的ACK。擁塞控制算法的作用是審視發送+ ACK的流程并確定發送速率。

許多熱門的改進方法，如CUBIC，都專注于數據包丟失。只要沒有數據包丟失，它們就會增加發送速率；當數據包開始消失時，它們會減小速率大小。這種方法的一個問題是對少量隨機分組丟失會出現反應過度的傾向，并將其解釋為擁塞。

另一方面，BBR查看數據包的往返時間和到達率，以建立連接容量的內部模型。一旦它測量了當前帶寬，它就會使得發送的速率保持在該對應水平，即使存在一些丟包形式的噪聲。

BBR遠不止這些，但我們對吞吐量的提高非常感興趣。

實驗

許多網絡協議更改是需要對客戶端和服務器進行協調更新的（注意你的電腦，IPv6！）。而BBR是不同的，它僅需要在發送方一側啟用。它甚至可以在套接字（socket）打開后啟用！

在本次實驗中，我們設置了一個隨機的用戶子集，在音頻請求主機名中包含“bbr”作為標志，并在服務器配置中添加幾行：

if(req.http.x-original-host=="audio-fa-bbr.spotify.com"&&client.requests==1){setclient.socket.congestion_algorithm="bbr";}

其他請求使用默認的CUBIC服務。

我們現在有A / B測試的處理組和對照組。對于每組我們測量：

1、播放延遲（中位數，p90，p99）

2、Stutter（每首歌的平均數）

3、帶寬，歌曲下載的平均值（中位數，p10，p01）

結果

按日平均值計算，BBR組stutter指標減少6-10％。較慢的下載隊列的帶寬增加了10-15％，中位數的帶寬增加了5-7％。兩組之間的延遲沒有差異。

地理區域的差異顯著

我們看到了亞太地區和拉丁美洲情況的大部分改善，stutter次數分別減少了17％和12％。較慢的下載隊列的帶寬增加15-25％，中位數增加約10％。

相比之下，歐洲和北美的stutter次數改善了3-5％，帶寬提高了約5％。

意外收獲：上游擁堵事件

在我們的實驗中，我們遇到了與南美上游提供商的網絡擁堵事件。這是BBR真正發光的地方！

在秘魯，非BBR組的stutter次數增加了400-500％。而在BBR組中，stutter次數僅增加30-50％。

在這種情況下，BBR組有4倍的帶寬用于較慢的下載（第10個百分點），2倍的中值帶寬，以及5倍少的stutter次數！

這情況就是我們的用戶幾乎沒有注意到和讓播放問題嚴重到要聯系客戶支持的區別。

討論

我們得到的結果與GCP，YouTube和Dropbox流量的報告一致。數據包丟失增加后的性能也與早期Google實驗的結果一致。

已經有實驗證明BBR可能會擠出CUBIC流量，以及引出其他問題。到目前為止，在我們自己的流量范圍內，我們還沒有看到有任何問題的跡象。例如，我們使用幾個不同的CDN合作伙伴進行音頻傳輸，但我們只在其中一個上運行了BBR實驗。與其他CDN相比，非BBR組并沒有顯示出任何明顯的性能下降。當然，我們將持續密切關注這一點。

到目前為止，我們對BBR的表現非常滿意。往正確的方向上移動我們的播放質量指標是非常困難的，并且通常涉及到權衡，例如，stutter次數與音頻比特率。 但是自有了BBR，我們已經看到了指標的顯著改善，且沒有伴隨明顯的成本。