订阅以接收新文章的通知:

衡量网络质量,更好地了解最终用户体验

2023-04-18

13 分钟阅读时间
这篇博文也有 EnglishFrançaisDeutsch日本語한국어Español繁體中文版本。

您在假期探亲时连接了 Wi-Fi,然后发现 Netflix 的加载速度没有平时快。您转至 speed.cloudflare.com、fast.com、speedtest.net,或在 Google Chrome 浏览器中输入“速度测试”,查看互联网连接是否有问题,得到的结果如下:

如果您想了解自己的情况,请点击此处尝试一下。但这些数字意味着什么?这些数字与 Netflix 是否无法加载或其他常见使用情况(如玩游戏或与亲友进行语音/视频聊天)有什么关系?即使是网络工程师也发现,速度测试很难与使用互联网的用户体验联系起来。

令人惊讶的是,尽管我们使用互联网的方式发生了很大变化,但近二十年来速度测试几乎没有变化。随着越来越多的人使用互联网,速度测试与用户对网络质量的体验之间的差距也越来越大。这个问题如此重要,以至于互联网标准组织也开始重视起来了。

从高层次来看,有三大网络测试挑战:

  1. 找到高效、准确地衡量网络质量的方法,并向最终用户说明网络质量是否以及如何影响他们的体验。

  2. 当发现问题时,找出问题所在,无论是无线连接,还是构成互联网的众多电缆和机器。

  3. 将单个用户的测试结果与其邻居的环境结合起来理解,或将结果存档,比如说以便与邻居比较或了解网络是变好了还是变差了。

Cloudflare 很高兴地宣布一项新的聚合互联网测量 (AIM) 计划,以帮助解决所有这三个挑战。AIM 是一种全新的开放格式,用于以一种对互联网最终用户有意义的方式显示互联网质量,围绕要求特定类型互联网性能的使用案例,同时保留工程师排除互联网问题所需的所有网络数据。我们很高兴能与 Measurement Lab 合作开展这个项目,并将所有这些数据存储在一个公开可用的存储库中,您可以访问该存储库来分析您在速度测试页面上看到的分数背后的数据(该速度测试页面的源代码现在是开源,含有 AIM 分数计算功能)。

什么是速度测试?

速度测试是对互联网连接的时间点测量。当您连接到任何速度测试时,它通常会尝试获取大文件(对视频流很重要)、执行丢包率测试(对游戏很重要)、测量抖动(对视频/VoIP 通话很重要)和延迟(对所有互联网使用情况都很重要)。该测试的目的是衡量互联网连接执行基本任务的能力。

这种方法面临着一些挑战,首先是一个简单的观察结果:在四处移动数据和数据包的互联网的网络层,有且只有三种措施可以直接观察到。它们是:

  • 可用_带宽_,有时称为“吞吐量”;

  • 丢包_率_,整个互联网在稳定状态下的丢包率极低_;_以及

  • 延迟,通常称为往返时间 (RTT)

这三个属性紧密交织在一起。特别是,用户实际获得的可用带宽部分(吞吐量)直接受丢包率和延迟影响。您的计算机会使用丢包率和延迟来决定何时发送或不发送数据包。一些丢包率和延迟在预料之中,甚至是必需的!如果两者都太多,带宽就会开始下降。

这些都是简单的数字,但它们之间的关系却远非如此简单。想一想把两个数相加_等于_一百的所有方法,即 x + y ≤ 100。如果 x 和 y 刚好合适,那么它们加起来就是一百。然而,x 和 y 的组合有很多种。更糟糕的是,如果 x 或 y 或两者都有点错误,那么它们加起来不到一百。在这个例子中,x 和 y 是丢包率和延迟,100 是可用带宽。

还有其他因素也会起作用,这些数字并不能说明全部问题。但只有这些数字是可以直接观测到的。它们的意义以及对诊断有重要影响的原因都很重要,因此让我们按顺序逐一讨论,以及聚合互联网测量是如何试图解决这些问题的。

速度测试中的数字意味着什么?

大多数速度测试都会运行并生成您在上面看到的数字:带宽、延迟、抖动和丢包率。我们来逐一解释这些数字的含义:

带宽

带宽是通信链路的最大吞吐量/容量。用来定义带宽的常用比喻是,如果说互联网连接是一条高速公路,那么带宽就是这条高速公路有多少条车道,有多少汽车可以在上面行驶。带宽在过去通常被称为“速度”,因为互联网服务提供商 (ISP) 衡量速度的标准是下载大文件所需的时间,而连接带宽越大,下载速度就越快。

丢包

丢包率听起来是这样的:一些数据包从来源发送到目的地,但目的地没有收到这些数据包。这对许多应用都有很大影响,因为如果信息在传输到接收方的途中丢失,接收方就很难理解发送的内容。

延迟

延迟是指数据包/消息从 A 点传输到 B 点所需的时间。互联网的核心是计算机通过电缆向其他计算机发送电信号或光束形式的信号。延迟一般被定义为电信号通过电缆或光纤从一台计算机传输到另一台计算机所需的时间。因此,减少延迟的方法之一就是缩短信号到达目的地的距离。

延迟有空闲延迟和负载下延迟之分。这是因为路由器和交换机中存在队列,当数据包到达的速度比传输速度快时,队列就会存储数据包。按照设计,排队是正常的,可以保持数据正常流动。但是,如果队列太大,或者其他应用程序的行为与您的应用程序截然不同,连接速度就会感觉比实际慢。这种情况称为缓冲区膨胀

在 AIM 测试中,我们会查看空闲延迟,向您展示您的延迟_情况_,但我们也会收集负载延迟,它能更好地反映您在日常互联网体验中的延迟情况。

抖动

抖动是测量延迟的一种特殊方法。它是互联网连接延迟的差异。如果抖动较高,一些数据包可能需要更长的时间才能到达,这可能会影响需要实时传输内容的互联网场景,如语音通信。

抖动可以比喻成沿着某条路线或路径上下班的情况。单就延迟而言,问题是:“从时间方面看,我离目的地还有多远?”例如,火车的平均行程为 40 分钟。对于抖动,问题不是行程时间,而是“我的行程时间有多稳定?”考虑到通勤时间,如果抖动为零,则意味着火车总是需要 40 分钟。但是,如果抖动为 15,那么通勤就变得更具挑战性,因为可能需要 25 到 55 分钟。

但是,即使我们理解了这些数字,它们虽然可以告诉我们发生了_什么_,却无法告诉我们_在哪里_发生了什么。

是 Wi-Fi 还是互联网连接出了问题?

运行速度测试时,您不仅要连接到 ISP,还要连接到与 ISP 相连的本地网络。您的本地网络本身可能也有问题。进行丢包率和抖动较高的速度测试:这通常意味着网络上的某些设备可能会丢弃数据包。通常情况下,您会致电 ISP,他们通常会说“离您的 Wi-Fi 接入点近一些或使用扩展器”之类的话。

这一点很重要——Wi-Fi 使用无线电波来传输信息,而砖块、泥灰和混凝土等材料可能会干扰信号,使信号离接入点越远越弱。像 Nest Wi-Fi 和 Eero 这样的网状 Wi-Fi 设备会定期从主接入点进行速度测试,以帮助检测类似的问题。因此,针对高丢包率和抖动等问题提供了潜在的快速解决方案,并预先提供给用户,可以帮助用户更好地确定问题是否与其无线连接设置有关。

虽然我们在互联网上看到的大多数问题都是如此,但如果网络运营商能够对这些数据进行汇总,而不是简单地告诉用户要离接入点近一些,往往会有所帮助。如果您的速度测试被传送到网络运营商可以看到的地方以及您所在区域的其他地方,网络工程师就可以在用户报告之前主动发现问题。这不但能够帮助用户,而且能够帮助网络提供商,因为由于用户配置造成的问题接听电话并派遣技术人员不仅费时,而且成本高昂。

这也是 AIM 的目标之一:帮助解决问题,避免电话支持。最终用户可以获得一系列易于阅读的提示,帮助他们了解他们的互联网连接能做什么、不能做什么,以及如何改进它;网络运营商可以获得他们需要的所有数据,以便在客户打电话之前检测最后一英里问题,从而节省时间和金钱。让我们用一个真实的例子来谈谈如何做到这一点。

现实生活中的一个例子

当您获得速度测试结果时,得到的数字可能会让您感到困惑。这是因为您可能不了解这些数字如何影响您的互联网体验。让我们来谈谈一个真实的例子,以及它对您的影响。

假设您工作的大楼有四间办公室,主区域是这样的:

您必须整天与她的客户端进行视频通话,而您坐在离无线接入点最远的办公室里。您的电话经常掉线,体验非常糟糕。当您在她的办公室进行速度测试时,她会看到这样的结果:

.tg {border-collapse:collapse;border-color:#ccc;border-spacing:0;} .tg td{background-color:#fff;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{background-color:#f0f0f0;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-0lax{text-align:left;vertical-align:top}

Metric Far away from access point Close to access point
Download Bandwidth 21.8 Mbps 25.7 Mbps
Upload Bandwidth 5.66 Mbps 5.26 Mbps
Unloaded Latency 19.6 ms 19.5 ms
Jitter 61.4 ms 37.9 ms
Packet Loss 7.7% 0%

指标

远离接入点

靠近接入点

下载带宽

Metric 0 points 5 points 10 points 20 points 30 points 50 points
Loss Rate > 5% < 5% < 1%
Jitter > 20 ms < 20ms < 10ms
Unloaded latency > 100ms < 50ms < 20ms < 10ms
Download Throughput < 1Mbps < 10Mbps < 50Mbps < 100Mbps < 1000Mbps
Upload Throughput < 1Mbps < 10Mbps < 50Mbps < 100Mbps < 1000Mbps
Difference between loaded and unloaded latency > 50ms < 50ms < 20ms < 10ms

21.8 Mbps

25.7 Mbps

上传带宽

Metric Result
Streaming Score 25/70 pts (Average)
Gaming Score 15/40 pts (Poor)
RTC Score 15/50 pts (Average)

5.66 Mbps

Metric Result
Streaming Score 45/70 pts (Good)
Gaming Score 35/40 pts (Great)
RTC Score 35/50 pts (Great)

5.26 Mbps

空载延迟

19.6 毫秒

19.5 毫秒

抖动

61.4 毫秒

37.9 毫秒

丢包

7.7 %

0 %

如何理解这些内容?网络工程师看到高抖动和丢包率后会想:“这个用户可能需要离路由器更近一些,才能获得更好的信号”。但是,您可能看到这些结果一头雾水,不得不向网络工程师求助,这可能会导致您给 ISP 打电话,浪费大家的时间和金钱。但您不应该咨询网络工程师来确定是否需要移动 Wi-Fi 接入点,或者您的 ISP 是否没有给她带来良好的体验。

聚合互联网测量对速度测试中的数字进行定性评估,帮助您理解这些数字。我们创建了特定于场景的分数,这是一个在场景层面计算的单一定性值:我们根据您尝试执行的操作计算不同的质量分数。首先,我们创建了三个 AIM 分数:流媒体、游戏和微信/RTC。这些分数根据应用程序成功运行所需的互联网条件,对每个指标进行不同的权衡。

City Average Streaming Score Average Gaming Score Average RTC Score
Tokyo 31 13 16
New York 33 13 17
Mumbai 25 13 16
Dublin 32 14 18

AIM 评分标准根据测试结果为您的连接赋予分值。我们在发布 AIM 时采用了“加权评分”,即根据这些方案中最重要的指标来计算分值。这些分数并不是一成不变的,而是会根据应用程序开发人员、网络运营商和互联网社区对不同性能特征如何影响各种场景下的应用程序体验的发现而不断变化,这也是将数据发布到 M-Lab 的另一个原因,这样社区就能帮助设计和汇聚良好的评分机制。

以下是完整的评分标准以及与今天的指标关联的各项分值:

.tg {border-collapse:collapse;border-color:#ccc;border-spacing:0;} .tg td{background-color:#fff;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{background-color:#f0f0f0;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-d6mv{background-color:#666;color:#FFF;font-weight:bold;text-align:left;vertical-align:top} .tg .tg-kyaz{background-color:#D9D9D9;color:#172B4D;text-align:left;vertical-align:top} .tg .tg-0lax{text-align:left;vertical-align:top}

指标

0 分

5 分

10 分

20 分

30 分

50 分

丢包率

> 5%

< 5%

< 1%

抖动

> 20 毫秒

< 20 毫秒

< 10 毫秒

空载延迟

> 100 毫秒

< 50 毫秒

< 20 毫秒

< 10 毫秒

下载吞吐量

< 1 Mbps

< 10 Mbps

< 50 Mbps

< 100 Mbps

< 1000 Mbps

上传吞吐量

< 1 Mbps

< 10 Mbps

< 50 Mbps

< 100 Mbps

< 1000 Mbps

负载延迟和空载延迟之间的差值

> 50 毫秒

< 50 毫秒

< 20 毫秒

< 10 毫秒

下面简要介绍了哪些值很重要,以及我们如何计算每种场景的分数:

  • 流媒体:下载带宽 + 空载延迟 + 丢包率 + (负载延迟 - 空载延迟差值)

  • 游戏:丢包率 + 空载延迟 + (负载延迟 - 空载延迟差值)

  • RTC/视频:丢包率 + 抖动 + 空载延迟 + (负载延迟 - 空载延迟差值)

在计算每项分数时,我们会从您的速度测试中提取分值,并将其从该场景的总分中扣除。因此,根据结果,我们可以对您的互联网连接的每种场景做出判断:不良、较差、一般、良好和优秀。例如,对于视频通话来说,丢包率、抖动、空载延迟以及负载延迟和空载延迟之间的差值对于判断互联网的视频通话质量是否良好非常重要。我们将从您的速度测试值中得出的分值相加,得出一个分数,显示您的互联网质量离完美的视频通话体验还有多远。根据您的速度测试,以下是您在距离接入点较远的办公室的 AIM 分数:

.tg {border-collapse:collapse;border-color:#ccc;border-spacing:0;} .tg td{background-color:#fff;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{background-color:#f0f0f0;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-0lax{text-align:left;vertical-align:top}

指标

结果

流媒体分数

25/70 分(一般)

游戏分数

15/40 分(较差)

RTC 分数

15/50 分(一般)

因此,与其说“您的带宽是 X,抖动是 Y”,我们可以说“您的互联网对 Netflix 来说还可以,但对游戏来说较差,对 Zoom 来说只能算一般”。在这种情况下,将 Wi-Fi 接入点移到更集中的位置就成了解决办法,您的 AIM 分数就变成了这样:

.tg {border-collapse:collapse;border-color:#ccc;border-spacing:0;} .tg td{background-color:#fff;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{background-color:#f0f0f0;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-0lax{text-align:left;vertical-align:top}

指标

结果

流媒体分数

45/70 分(良好)

游戏分数

35/40 分(完美)

RTC 分数

35/50 分(完美)

今天,您甚至可以在 Cloudflare 速度测试中看到这些结果作为网络质量分数:

在这一特殊情况下,无需致电 ISP,也无需咨询网络工程师。只需将接入点移近办公室中间,就能改善每个人的体验,而且没有人需要打电话个支持人员,为每个人提供了更无缝的体验。

AIM 采用网络工程师关心的指标,并根据您尝试使用的应用程序将其转换为更易于理解的指标。汇总的数据是匿名的(符合我们的隐私政策),因此您的 ISP 可以实际查找您所在城市片区以及使用您的 ISP 进行的速度测试,并获得基础数据,以帮助将用户投诉转化为网络工程师可操作的事物。此外,政策制定者和研究人员可以检查汇总的数据,以更好地了解社区中用户的体验,从而帮助游说提高互联网质量。

工作条件

这里有一个有趣的问题:当您进行速度测试时,您要连接到哪里,连接的另一端是什么样的互联网?速度测试经常面临的挑战之一是,您进行测试的服务器与运行或保护您网站的服务器并不相同。正因如此,您的速度测试用于连接到另一端主机的网络路径可能大不相同,甚至可能经过优化,以便为尽可能多的速度测试提供服务。这意味着您的速度测试实际上并没有测试您的流量到达您通常使用的应用程序时使用的正常路径。您运行的测试测量的是一条网络路径,但它并不是您经常使用的网络路径。

速度测试应在真实的网络条件下进行,以反映人们使用互联网的方式,并有多个应用程序、浏览器标签页和设备全都在争用连接。使用面向应用程序的工具测量互联网连接,并尽可能在使用网络时进行测量,这一概念被称为工作条件下的测量。目前,当速度测试运行时,它们会与保留用于测试网络性能的网站建立全新的连接。遗憾的是,日常互联网使用并不是通过新连接来连接到专用速度测试网站来进行的。这实际上是许多互联网应用程序的设计使然,它们依赖于重复使用与网站的相同连接,通过消除因建立加密、交换证书等产生的昂贵延迟,为最终用户提供性能更佳的体验。

AIM 正在通过多种方式帮助解决这一问题。首先,我们以与应用程序相同的方式实施所有测试,并在工作条件下进行测量。我们测量负载延迟,向您展示您的互联网连接在实际使用时的表现。您可以在今天的速度测试中看到这一点:

其次,我们正在收集与您现在使用的端点相对应的速度测试结果。通过针对 Cloudflare 和其他网站的速度测试,我们可以根据您日常生活中经常使用的网络来显示最终用户的互联网质量,从而更好地了解实际工作情况。

AIM 数据库

我们很高兴地宣布,通过与 Measurement Lab (M-Lab) 的合作,AIM 数据今天正式发布,最终用户和网络工程师都可以通过各种网络解析网络质量数据。M-Lab 和 Cloudflare 都将计算从他们的速度测试中得出的 AIM 分数,并将其存入共享数据库,使得最终用户和网络运营商能够在多种不同的速度测试中从尽可能多的点看到互联网质量。

作为我们所看到的一个例子,让我们来看看我们使用这些数据绘制的 10 月第一周日本东京每个场景的 Cloudflare 数据的分数:

由此可以看出,在进行的 5,814 次速度测试中,50.7% 的用户流媒体质量良好,但 48.2% 的用户流媒体质量一般。游戏在东京似乎相对较难,因为有 39% 的用户游戏体验不佳,但大多数用户的 RTC 体验相当一般。让我们来看看这与我们看到的其他一些城市相比有何不同:

.tg {border-collapse:collapse;border-color:#ccc;border-spacing:0;} .tg td{background-color:#fff;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{background-color:#f0f0f0;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-0lax{text-align:left;vertical-align:top}

城市

平均流媒体分数

平均游戏分数

平均 RTC 分数

东京

31

13

16

纽约

33

13

17

孟买

25

13

16

都柏林

32

14

18

根据我们的数据,我们可以看出,除了孟买稍显落后外,大多数用户在视频流方面表现尚可。由于高延迟是游戏分数背后的主要驱动因素,用户的游戏体验普遍参差不齐,但他们的 RTC 应用程序表现稍好,在所有地区普遍处于一般水平。

与 M-Lab 协作

M-Lab 是一个开放的互联网测量资源库,其使命是测量互联网、保存数据,并使其普遍可用和有用。除了为网络运营商提供免费、开放的 AIM 数据访问权限外,M-Lab 还将为政策制定者、学术研究人员、记者、数字包容倡导者以及任何有兴趣的人提供数据访问权限,以便他们做出有助于改善互联网的重要决策。

M-Lab 不但在向政策制定者和学术界开放共享互联网质量数据方面享有盛誉,而且提供了一种名为网络诊断测试 (NDT) 的“速度”测试,也就是在 Google 中输入“速度测试”后运行的速度测试。通过与 M-Lab 合作,我们从更多用户那里获得了聚合互联网测量指标。我们还希望与其他速度测试机构合作,为尽可能多的用户提供全球互联网质量的全貌。如果您要衡量互联网性能,我们希望您加入我们的行列,帮助向用户展示他们的互联网在哪些方面表现出色。

速度测试,现在为开源

除了与 M-Lab 合作之外,我们还将我们的速度测试客户端设为开源。将速度测试设为开源是让应用程序通过 Cloudflare 获取速度测量结果的重要一步,也是开始为您的应用程序计算 AIM 分数的简单方法。我们的速度测试现在可以作为 JavaScript 应用程序嵌入,这样您就可以执行网络质量测试,而无需导航到浏览器。该应用程序不但为您提供我们今天的速度测试所使用的所有测量数据,而且以非公开方式将结果上传到 Cloudflare。该资源库还显示了我们计算 AIM 分数的方式,因此您可以看到为最终用户定义网络质量的内部工作原理,以及网络质量如何实时变化。要开始使用我们的开源速度测试进行开发,请查看开源链接

互联网质量的美好未来

我们很高兴能将这些数据汇总在一起,以显示各种测试和网络的互联网质量。我们将对这些数据进行分析,并改进我们的评分系统,而且我们已经将其设为开源,这样您就可以看到我们是如何使用速度测试测量结果对各种不同应用程序的互联网质量进行评分的,甚至可以自己实施 AIM。我们还将 AIM 分数与您今天看到的所有测试一起放入速度测试中,以便您最终能够更好地了解您的互联网在哪些方面表现出色。

如果您眼下正在运行速度测试,并且有兴趣与我们合作,帮助收集有关用户体验互联网质量的数据,请联系我们,让我们共同努力,让互联网变得更好。如果您正在运行应用程序并希望测量互联网质量,请查看我们的开源软件存储库,这样您就可以立即开始开发。

了解您的互联网在哪些方面表现出色并不需要您成为网络专家;这正是我们的意义所在。通过 AIM 和我们的 M-Lab 合作者地位,我们希望能够告诉您,您的互联网能做什么,并利用这些信息帮助大家更好地使用互联网。

我们保护整个企业网络,帮助客户高效构建互联网规模的应用程序,加速任何网站或互联网应用程序抵御 DDoS 攻击,防止黑客入侵,并能协助您实现 Zero Trust 的过程

从任何设备访问 1.1.1.1,以开始使用我们的免费应用程序,帮助您更快、更安全地访问互联网。要进一步了解我们帮助构建更美好互联网的使命,请从这里开始。如果您正在寻找新的职业方向,请查看我们的空缺职位
Network速度和可靠性产品新闻Internet Quality

在 X 上关注

David Tuber|@tubes__
Cloudflare|@cloudflare

相关帖子

2024年10月24日 13:00

Durable Objects aren't just durable, they're fast: a 10x speedup for Cloudflare Queues

Learn how we built Cloudflare Queues using our own Developer Platform and how it evolved to a geographically-distributed, horizontally-scalable architecture built on Durable Objects. Our new architecture supports over 10x more throughput and over 3x lower latency compared to the previous version....

2024年10月09日 13:00

Improving platform resilience at Cloudflare through automation

We realized that we need a way to automatically heal our platform from an operations perspective, and designed and built a workflow orchestration platform to provide these self-healing capabilities across our global network. We explore how this has helped us to reduce the impact on our customers due to operational issues, and the rich variety of similar problems it has empowered us to solve....