大型CDN的BBR评估

图1. 显示常见物体大小的热图.

热图使我们能够理解不同的请求模式. 一般来说，越爬越高 吞吐量是性能增益的最佳指示器. 然而，吞吐量作为一种度量可能非常 噪声，特别是在对象大小很小(小于几mb)的情况下. 因此，基于分离 评估哪些大小可以提供最可靠的吞吐量评估, 我们只使用对象大小 大于3MB用于吞吐量评估. 对于对象大小小于3MB，跟踪流完成 时间是一个更好的衡量标准.

作为评估的第一步，我们在洛杉矶和洛杉矶的一个PoP的几台服务器上启用了BBR 监控所有TCP流的吞吐量和流完成时间. 下面的结果检查a 很少有互联网服务提供商的具体案例研究.

大型无线供应商

图2显示了打开BBR后的差异.

图2. 开启BBR时对大型无线提供商客户端的吞吐量影响(测试) 与立方流量相比(控制). 左:两天内的吞吐量测量. 垂直的蓝线 表示BBR何时被激活. 在这里，我们看到BBR的总体改善约为6-8%. 正确的: A 提供 吞吐量的第5个百分位数. BBR流量有显著改善.

对于这个无线提供商，一旦启用BBR，我们平均看到6-8%的吞吐量 改进. 总的来说，我们也看到了更低的TCP流完成时间. 这一发现与 其他报告 Spotify, Dropbox, YouTube，其中在无线中可以看到吞吐量的明显增加 丢包很常见的网络，但这并不一定是拥塞的标志.

大型有线电视供应商

接下来，我们考察了一家大型有线运营商的性能. 在这里我们也看到了吞吐量 大对象)和流完成时间(如图3所示).)使用BBR进行改进.

图3. 大型有线运营商完成一个流程所需的平均时间. BBR(测试)流程显示 更少的抖动和花费更少的时间来完成数据传输. 对于较大的对象，这些好处更有影响力. We 但是，对于Cubic和BBR的大文件大小，是否看到类似的抖动.

从这些测试中报告的收益显示了客户端流量的非常有希望的结果.

因为这些收益是汇总的, 我们决定再深入一点，检查是否所有TCP流都在 the PoP saw the benefit of using BBR; or if some TCP 流 suffered, which ones?

在CDN边缘，我们执行四种不同类型的TCP会话:

• 弹出到客户机(如上所示)

• PoP-to-PoP(数据中心之间)

• PoP内部通信(同一PoP的缓存之间)

• PoP到原点(PoP到客户原点数据中心)

对于这项研究, 我们考虑了PoP-to-Client, PoP-PoP, 和pop内部流，因为边缘到原点不是 和其他三个一样大.

PoP-to-PoP和pop内流量

评估对这些TCP流的影响也很重要，因为在许多情况下，这些流是 客户端传递的拦截器，例如动态内容.

对于PoP-to-PoP和intra-PoP流量吞吐量，我们看到性能有很大的下降. 图4 显示同一时间段内pop内流量和pop间流量的影响情况:

图4. 开启BBR时，对内部pop和pop到pop流量的吞吐量影响(测试) 与立方流量相比(控制). 两天内的吞吐量测量. 垂直的蓝线 表示BBR何时被激活. 使用BBR后，吞吐量下降了大约一半.

在流向最终用户的流和数据中心之间没有如此明显的性能差异 以前的研究报告. We need to evaluate why these particular TCP 流 suffered; if this is an artifact of hardware or configurations on our CDN; and if so, what tunings would need to be changed.

通过使用web服务器访问日志和服务器端套接字数据的评估进行进一步调查, it 在高RTT流和低RTT流都存在的情况下，RTT非常低的TCP流 遭受使用BBR的痛苦. 我们进一步评估了小于0的情况.传输了5KB的数据 发现在大多数情况下，BBR的表现与Cubic相似.

基于这些发现, 我们的结论是，我们的交通模式, 最好使用Cubic进行intra-PoP 和PoP-to-PoP通信，其中rtt和损耗较低. 对于客户端流量，值得使用 BBR.

全PoP测试

大规模评价BBR的性能效益, 我们在里约热内卢的一家PoP店做了全面的PoP测试 从我们的网络在那个PoP的所有面向客户的流量. 这个PoP是一个有趣的案例研究 由于该区域的位置和对等约束导致经历更高的中位数rtt 客户比其他地区多.

图5. 为显示高重传(ASN1)的客户端AS使用BBR提高吞吐量.

我们部署了拥塞控制算法的变化，并监控了性能. 的提供 使用BBR vs .观察吞吐量. 图中显示了里约前两个as(自治系统)的立方. 如图5所示，总体而言，一个As看到了BBR的好处，而另一个则没有.

调查背后的原因, 我们寻找在测试期间收集的其他TCP指标 党卫军效用. 在这两种ase之间的重传速率中可以看到明显的区别. 即使是ase 更高的rtt, BBR仅在重传次数较多的情况下才表现良好, 换句话说, 对于损失较小的ase, Cubic没有理由退缩，并且比BBR表现得更好. 然而，它是， 值得注意的是，TCP Cubic的许多参数已经在我们的CDN上进行了仔细的调整.

接下来，我们调查了图5中所示的来自ASN1的所有连接是否都显示了改进 吞吐量. 图6是BBR和Cubic所花费的时间图(越低意味着吞吐量越好) 不同对象大小的连接. 这里我们看到BBR只是开始显示出明显的好处 更大的物体，大约mb. 我们确实看到了一个使用BBR的异常实例，但无法归因于 它与任何特定的拥塞控制协议相关的问题.

图6. 对于显示出改进的ase, BBR的好处可以用于长时间运行的流 文件.

为什么会发生这种情况??

这些结果有两个维度——立方vs. BBR和BBR vs. BBR.

立方vs. BBR

当BBR估计瓶颈带宽时，它对缓冲区大小和RTT非常敏感. 在…的情况下 在大的缓冲区中，中间盒可能会建立一个队列，BBR的估计RTT会增加. 既然有 没有数据包丢失，Cubic在这种情况下不会退缩，换句话说，就是PoP-to-PoP风格的流量 因此Cubic实现了更高的吞吐量. 对于较小的缓冲区，例如无线客户机，则 缓冲区填充迅速并导致损失-因此立方流返回，BBR流表现更好.

BBR vs. BBR

在这种情况下，当出现损失时，没有流回. 但是，当两个流具有不同的rtt时 竞争带宽份额，具有较高RTT的流也具有较大的最小RTT和 因此更高 带宽延迟产品. 因此，这种流动以更快的速度增加飞行数据 比RTT更低的流. 这将导致按降序将带宽重新分配给流 和具有较高rtt的流比具有较小rtt的流更快地填充缓冲区.

在实验室环境中重现结果

进一步了解流之间的相互作用, 我们创建了一个测试平台环境 捕获我们在生产环境中看到的行为的虚拟机. 我们确定了模拟不同的方法 边缘服务器的流量分类如下:

客户端流量延迟设置为~50ms，损失范围为0.001 to 0.1，瓶颈带宽为 50 mbps. 同样，对于PoP-to-PoP，仅将损耗和延迟设置为~15ms和0.0001 to 0.01. 为内部 PoP流量，我们让虚拟机最大限度地利用可用容量. 最后，利用不同的对象进行了仿真 大小以捕获流量的多租户特性. 我们用an并行运行这三种交通模式 流的指数到达捕获a poisson-style 气流到达分布. 图7显示了测试平台 设置.

这个测试的目标是重现我们在生产测试中看到的问题, 特别是下降 小RTT流的吞吐量，如pop内流量和pop到pop.

图7. 使用KVM、iperf、netem和etc工具进行实验室设置.

使用这个设置, 我们用模拟的背景流量进行了数百次模拟, 两个立方 和BBR，并测量完成流程所需的时间. 后台流量的目标是 模拟类似生产的环境. 许多现有的研究都集中在运行几个Cubic流上 BBR和评估他们的行为. 虽然在这些情况下，理解每个流的行为是有用的， 它不能很好地表示大型、高容量CDN的复杂性. 我们使用客户端流完成时间 作为一个可靠的指标，因为对于小文件大小的吞吐量可能是嘈杂的.

图8. 时间被水流带走. 左:客户端流程. 右:PoP-to-PoP流. 对象大小:3MB. BBR 在模拟客户端流方面的性能优于Cubic.

我们看到该模式也在我们的测试台上重新出现. 在图8中，我们显示了BBR所用时间的提供 和Cubic iperf有两种场景:客户端流量和3MB(中等大小)文件的PoP-to-PoP流量. 在低损耗高带宽设置中，BBR流无法赶上Cubic. 客户端流量(低带宽)得到了改善.e.在美国，BBR流动所需的时间更短. 然而, 对于小文件的改进是微不足道的. 在测试环境中重现这些行为给了我们 相信它们是不同流类型之间相互作用的结果. 因此，任何 在CDN上部署BBR必须意识到它可能对流类型的混合产生更广泛的影响.

结论

从我们的评估中，我们观察到BBR流并不是在所有情况下都表现良好. 具体来说,交通 数据中心/存在点(PoP)内以及数据中心之间的流量(PoP-to-PoP)受到影响 使用BBR时. 在某些极端情况下，吞吐量会减少一半. 然而，我们确实看到了6-8%的增长 改进Pop-to-Client流量吞吐量.

在这篇文章中，我们概述了在CDN的背景下BBR(版本1)的评估. 我们从a开始 对单个PoP中的几个服务器进行了小测试，并评估了我们感兴趣的不同变量 大型内容提供商. 在大规模的全PoP测试中，我们注意到BBR在以下情况下最有效 重传率高的情况下，建议对大文件使用BBR.

我们从这里往哪里走?

如果我们在系统级别(所有流)启用BBR，我们将面临pop内部和pop到pop流量受到影响的风险 吞吐量降低.

然而，BBR已经显示出潜力，并且在客户端流量方面表现良好. 这确实激励着我们 选择性地为客户启用BBR，可能从无线提供商开始. 此外，这些路径 有浅缓冲和无线损失, 这是BBR比其他Cubic表现更好的理想情况 流.

我们希望这篇概述能给大型内容提供商及其应用中BBR的使用带来一些清晰的信息 对可能共享瓶颈的不同类型流量的影响. 的alpha版本 BBRv2 现在是 可用，它应该可以解决其中一些问题. 我们计划继续评估更新版本的 BBR和使用智能传输控制器选择正确的拥塞控制为正确的类型 流. 我们将在未来分享更多细节.

感谢组织中各个团队的贡献，使这一分析成为可能!