BBR如何讓Spotify流媒體更流暢？

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

Spotify如何播放音樂

Spotify的數(shù)據(jù)流的基本原理很簡單。我們將每個(gè)編碼的音樂曲目存儲為文件，復(fù)制到世界各地的HTTP服務(wù)器上。當(dāng)用戶播放歌曲時(shí)，Spotify應(yīng)用程序?qū)母浇哂蠬TTP GET范圍請求的服務(wù)器以塊的形式獲取文件。其中，典型的塊大小為512kB。

我們希望我們的音頻播放能夠達(dá)到即時(shí)，且順滑流暢。為了保持這種效果，我們跟蹤兩個(gè)主要指標(biāo)：

1，播放延遲，從點(diǎn)擊到音樂響起的時(shí)間。

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

Stutter的發(fā)生主要是由于下載帶寬較低時(shí)音頻緩沖區(qū)欠載。因此，我們的指標(biāo)與連接時(shí)間和傳輸帶寬密切相關(guān)。這些都是一些經(jīng)典的參數(shù)。

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

TCP擁塞什么？

我們細(xì)看一下從服務(wù)器到客戶端的文件傳輸過程。服務(wù)器以TCP數(shù)據(jù)包發(fā)送數(shù)據(jù)?？蛻敉ㄟ^返回ACK確認(rèn)交付。根據(jù)硬件和網(wǎng)絡(luò)條件，連接的容量就有限。如果服務(wù)器過快地發(fā)送太多數(shù)據(jù)包，它們就會被丟棄。服務(wù)器將其記錄為丟失的ACK。擁塞控制算法的作用是審視發(fā)送+ ACK的流程并確定發(fā)送速率。

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

另一方面，BBR查看數(shù)據(jù)包的往返時(shí)間和到達(dá)率，以建立連接容量的內(nèi)部模型。一旦它測量了當(dāng)前帶寬，它就會使得發(fā)送的速率保持在該對應(yīng)水平，即使存在一些丟包形式的噪聲。

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

實(shí)驗(yàn)

許多網(wǎng)絡(luò)協(xié)議更改是需要對客戶端和服務(wù)器進(jìn)行協(xié)調(diào)更新的（注意你的電腦，IPv6?。?。而BBR是不同的，它僅需要在發(fā)送方一側(cè)啟用。它甚至可以在套接字（socket）打開后啟用！

在本次實(shí)驗(yàn)中，我們設(shè)置了一個(gè)隨機(jī)的用戶子集，在音頻請求主機(jī)名中包含“bbr”作為標(biāo)志，并在服務(wù)器配置中添加幾行：

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

其他請求使用默認(rèn)的CUBIC服務(wù)。

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

1、播放延遲（中位數(shù)，p90，p99）

2、Stutter（每首歌的平均數(shù)）

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

結(jié)果

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

地理區(qū)域的差異顯著

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

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

意外收獲：上游擁堵事件

在我們的實(shí)驗(yàn)中，我們遇到了與南美上游提供商的網(wǎng)絡(luò)擁堵事件。這是BBR真正發(fā)光的地方！

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

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

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

討論

我們得到的結(jié)果與GCP，YouTube和Dropbox流量的報(bào)告一致。數(shù)據(jù)包丟失增加后的性能也與早期Google實(shí)驗(yàn)的結(jié)果一致。

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

到目前為止，我們對BBR的表現(xiàn)非常滿意。往正確的方向上移動(dòng)我們的播放質(zhì)量指標(biāo)是非常困難的，并且通常涉及到權(quán)衡，例如，stutter次數(shù)與音頻比特率。 但是自有了BBR，我們已經(jīng)看到了指標(biāo)的顯著改善，且沒有伴隨明顯的成本。