构建网速测试服务fast.com

Netflix 体系结构 设计

摘要：

为了帮助所有网民，无论是否Netflix会员，通过一种简单快速的网络测速方法，Netflix提供了在线测速服务fast.com。该服务上线后全球数百万网民已经用它测试过自己的网速。这个服务本身以及具体的工作原理吸引了很多人关注。本文将从较高层面介绍Netflix是如何解决衡量网速过程中所固有的挑战，以及fast.com网站背后采用的技术。

正文：

在今年五月发布的博客文章中，我们介绍了新上线的网络测速网站fast.com。提供fast.com这个服务的目的在于为所有网民，无论是否Netflix会员，提供一种简单快速的网络测速方法。自从fast.com上线后，全球数百万网民已经用它测试过自己的网速。这个服务本身以及具体的工作原理吸引了很多人关注。本文将从较高层面介绍我们是如何解决衡量网速过程中所固有的挑战，以及fast.com网站背后采用的技术。

但首先有个消息要公布：我们很荣幸向你推荐面向Android和Apple移动平台的FAST移动应用。这些应用可免费从Apple App Store或Google Play安装。

设计目标

在为fast.com应用设计用户体验时，我们考虑了几个重要的目标：

• 提供能反映用户实际互联网使用情况，精确一致的结果
• 加载和运行速度必须尽可能快
• 提供易于理解的简单结果
• 无须安装额外的应用，可支持在大部分设备上通过浏览器使用

我们希望确保fast.com能被大部分对计算机网络、命令行等技术没有任何经验的网民轻松使用和理解。

技术目标

衡量互联网速的方法有很多，而很多因素会对衡量结果产生影响，其中一些因素甚至不在我们控制之下。例如用户本地或家庭网络的配置、设备或路由器性能、网络中的其他用户、设备的TCP或网络配置等。然而我们对能够被自己控制的变量进行了慎重考虑，希望借此能实现我们的最终目标：提供简单但实用的测试结果。

可由我们控制，并会对测试结果产生影响的变量包括：

• 服务器位置
• 服务器负载
• 所用TCP连接数量
• 测试过程中所下载内容的大小和类型
• 对衡量结果进行汇总的方法

Open Connect CDN是我们最大的优势之一，这是一个遍布全球的服务网络（Open Connect Appliance，即OCA），其中存储并提供了全球会员欣赏的Netflix内容。在全球某些地区，这样的网络承载了高达35%的“最后一英里”互联网峰值流量。通过使用自己的生产服务器测试网速，可确保测试结果能够精确反映用户现实生活中所体验到的实际网络性能。

为了追求足够简洁的设计目标，我们刻意选择仅测试下载速度，这个速度反映了当用户执行网页浏览或在线流媒体播放等活动时，数据从服务器到达用户设备所能实现的速度。下载是互联网上大部分普通消费者最主要的行为。

同时我们还决定采用下列这些高层次的技术实现：

• 在测试中打开多个连接，数量多少取决于网络情况
• 在尽可能广泛的Netflix生产用OCA中进行测试，但只使用有足够容量可以处理测试流量的服务器，通过可接受的参数确保这些服务器能同时为会员提供最优化的视频质量
• 衡量较长时间段内的运行结果，从结果中剔除连接发起阶段和热身阶段的结果以及短期波动
• 为了快速、稳定地提供精确结果，需要动态决定何时结束测试
• 使用HTTPS进行测试，同时支持IPv4和IPv6

体系结构

如上所述，fast.com会从我们的Open Connect Appliance（OCA）分布式网络下载测试文件。每台OCA服务器提供了一个包含一个25MB视频文件的端点。该端点可支持range参数，这样即可针对从1字节到25MB大小之间任何尺寸的内容块发出请求。

为了将用户定向至某台OCA服务器，fast.com提供了一个端点，该端点可返回最适合测试使用的多个不同OCA的URL所组成的清单。为了确定清单内容，端点使用了与netflix.com视频交付时为确定重定向位置所用的相同逻辑。具体返回哪些OCA主要取决于：

• 网络距离
• 每个OCA的流量负载，这一指标也对应着服务器的整体运行状况
• 网络结构 – 清单中的每个OCA必须属于不同的集群

当fast.com客户端收到URL后，即可开始测试。

估算网络速度

测试引擎会使用探索式方法：

• 剔除在连接建立和热身阶段收集到的衡量值
• 将收集到的其他衡量值汇总在一起
• 确定测试过程中要使用的并发连接数量
• 尝试将处理相关任务时的开销从网络时间的影响中剥离 – 因为fast.com是在浏览器内运行的，针对DNS解析时间等网络事件缺乏足够能见度，在客户端处理这些数据包可能会造成访问测试服务器时的延迟
• 确定客户端何时收到为了估算能完全反映最终网速所需的足够数量的衡量值

虽然排除了初始状态下连接热身阶段的衡量值，但我们也考虑了测试过程中的性能突降等情况。网络性能的突降可能意味着网络损耗、链路拥堵，或路由器故障，但这些情况并不能正确反映用户通过互联网消耗内容时的实际体验问题，因此将其排除。

连接数量

取决于网络吞吐率，fast.com客户端会通过可变数量的并发连接进行测试。对于低吞吐率网络，运行多个连接可能导致多个连接争用本就有限的带宽，进而导致出现更多超时问题，并导致测试过程延长，结果精确度降低。

然而带宽足够高时，运行多个并发连接有助于更快速让网络链路达到饱和并减少测试所需时间。对于非常高吞吐率的连接，尤其是延迟较高时，一个连接以及一个25MB的文件可能不足以测出最高速度，有必要使用多个连接。

待下载文件的大小

对于每个连接，fast.com客户端会从25MB的文件中选择一块特定大小的文件块来下载。如果网络层支持Periodical progress事件，更合理的做法是请求整个文件并使用下载进度计数器估算网速。如果下载进度事件不可用，客户端会在测试过程中逐渐增大载荷大小，以便执行多个下载并获得足够数量的样本。

结果的计算

收集到下载速度衡量值后，客户端会将所有连接下载的内容结合在一起并记录快照速度。

随后会将“瞬时”网速结果传递到结果汇总模块。汇总模块会确保：

• 排除初始连接热身阶段的结果
• 采用其他结果并计算出其他结果的移动平均数（Rolling average）

对于fast.com客户端来说，最大的挑战之一在于决定估算的网速什么时候可以作为最终结果显示出来。由于用户在使用fast.com测速时位于不同环境或条件下，因此需要酌情调整测试所需的时间。

对于稳定的低延迟连接，可以看到结果很快将能反映实际最高网速：

高延迟连接需要用比较长的时间热身才能反映出实际最高网速：

有损耗或拥堵的连接所显示的瞬时速度有较大波动，但随着时间延长，这些瞬时速度也将趋于平滑。但同时也更难准确确定连接在哪一刻完成了热身已经可以实现最高速度。

在任何情况下，当初始热身衡量值被排除在外后，“停止”检测模块会监控汇总后网速的变化情况，并确定何时可以得出较为稳定的估算值，或是否需要用更长时间进行测试。获得稳定结果后，会将其作为最终速度呈现给用户。

结论和后续工作

我们会持续监控、测试并完善fast.com，目标在于为用户提供最简单但同时最精确的网速测试工具。我们计划未来继续通过博客文章向大家介绍这一工具的最新变化和更多详情。

作者：Sergey Fedorov、Ellen Livengood，阅读英文原文：Building fast.com