BBR如何让Spotify流媒体更流畅？

本文来自数字音乐服务商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，我们已经看到了指标的显着改善，且没有伴随明显的成本。