Property Finder Group 拥有多元化客户群，遍布中东和北非（Middle East and North Africa，简称 MENA）的 7 个国家。作为首席软件架构师，我一直在努力寻找新方法来提高客户满意度并优化他们的用户体验，而且往往是性能方面的用户体验。就个人而言，我相信Kaizen方法：通过小而积极的改变来创造持续改进，并且随着时间的推移会触发雪球效应。作为在 Property Finder 中应用该流程的一部分，我们希望不断优化性能，降低我们网站上和应用程序中资源的终端用户延迟。

和很多其他公司一样，我们利用内容交付网络（content delivery network，简称 CDN）为我们的静态资源提供服务。借助 CDN，我们可以卸载从源服务器（在我们的示例中是 AWS S3）加载的静态资源，并尽可能地接近终端用户来提供这些资源。凭借我们遍布全球的入网点（points of presence，简称 PoP），我们的 CDN 有助于从终端用户所在的城市或国家的服务器为他们提供内容，而不是从那些可能更远的原始位置下载内容再交付给终端用户。

我们一直是 Akamai 的长期客户，Akamai 是市场上出现最早的 CDN 之一，在全球很多城市都有很高的覆盖性和可用性。但是，几个月前，我们和我们的 CTO 进行了讨论，准备测试我们的 CDN 性能和评估我们目前在用的方案，并确定我们是否需要改变我们的 CDN 策略，如果有意义的话，就多用几个 CDN，或者全盘变更我们的供应商。

当涉及如此广泛的主题时，有不同的方法来评估和衡量我们的选择。理想情况下，所有这些方法都必须得到一些分析的支持，这些分析有关当前的状态、我们在不同运营地区的竞争对手，以及从不同 ISP 角度观察到的性能数据。不同浏览器和操作系统之间存在微不足道的差异，因为这些差异在统计上无关紧要，我们把它们排除在外，只将网络性能和终端用户延迟作为 CDN 的一个度量指标。

“我们无法改善我们无法测量的东西。”

在评估了一些不同的方法后，我意识到，有一个工具，它完全满足我们的需求，它可以检索来自全球多个入网点的科学结果和实际测量值，有助于我们清楚地看到每个国家或地区性能最好的 CDN。

我们对最快 CDN 的需求超出了最初的想法，结果成了一项大型研究。最终得到了很多色彩斑斓的地图，其中包括一个交互式地图，可以用来查看我们所在的国家/地区中性能最好的 CDN。

RIPE Atlas

进入RIPE Atlas：这是一个开放的分布式全球探测器网络，用来测量互联网的连接性和可访问性。这些探测器本身是通过RIPE网络协调中心（RIPE Network Coordination Centre）分发的，RIPE 网络协调中心是区域互联网注册机构（Regional Internet Registry）之一。它是有史以来最大的互联网测量网络！

给大家增加一些历史参考，我们要记得，自 1835 年以来，人们用电报来播报天气预报。而在这之前，最早的气象站于1781年开始收集气象数据。在互联网数字化的 21 世纪世界中，我们仍然在使用遍布全球的数十万个气象站，以便在我们智能手机上快速查看当前的天气状况，并决定晚上出门要穿的衣服。

RIPE Atlas 探测器地理分布图

互联的世界需要相当于这些气象站数量的互联网站点，以便不断地监控互联网本身。因此，这是与 RIPE Atlas 项目完美契合的地方：它给每个人一种能力，可以从这么多不同探测器测量连接到互联网（仅通过一个公共路由的 IP 地址）的任何设备的连接性。

简而言之，RIPE Atlas 使每个人都能在全球范围内使用数量超过 1 万个的探测器，这种探测器目前几乎在全球所有的国家中都有分布，这归功于数百名托管它们的志愿者。

简而言之，RIPE Atlas 探测器是小型的树莓派单片机（Raspberry PI board），上面有以太网插头以及内置特别软件的微型 USB 电源。最新的型号运行于 NanoPi NEO Plus2 之上，配置了 512MB RAM。

在 2017 年，RIPE Atlas 连接的探测器达到 1 万个

需要注意的是，RIPE Atlas 是基于信用额度的系统：我们可以通过使探测器上线而获得正常运行时间信用额度；在探测器为其他人的测量提供结果时，我们也可以得到信用额度。

我们可以在 RIPE 会议上获得一些免费的信用额度以开始工作；我们也可以发送信用额度给其他 RIPE Atlas 成员或从他们那里获得信用额度。

由于以志愿者为基础，随着时间的推移，有超过 50%的探测器被遗弃了

要了解更多关于 RIPE Atlas 本身的信息，我建议看看入门视频以及浏览其官网。

内容交付网络（Content Delivery Networks）

对 CDN 入网点（points of presence，简称 POPs）的地理分布如何帮助从更接近终端用户的源服务器获取内容的高级概览。（图像来自 Cloudflare）

我不会介绍如何实施 CDN 以及它们的运行原理。我在这里仅仅介绍下它可以提供的重要好处：

• 由于延迟减少，资源的加载速度更快。资源（图像、Javascript、CSS 文档等等）从源服务器获取一次，之后，从最接近用户的服务器提供内容。这有助于优化终端用户体验，让我们的客户满意，并且，由于更快的页面加载速度，可以提高 SEO 排名。

• 削减流量成本。通常，通过从常用的云存储（如 AWS S3 和谷歌云存储）给我们的用户提供我们的静态内容服务，我们要为每次下载中产生的互联网流量付费。CDN 就像一个帮助我们的中间人：它只需从源服务器那里获取所要求的内容一次，并存储起来，之后就可以从缓存中提供它。对于我们来说，这经济很多，因为我们的源服务器输出流量变小了。

• 缓存。使用 CDN 允许我们指定不同的动态缓存策略，并提高缓存命中率。如果从 CDN 的服务器缓存中提供内容，那么就不必从我们的源服务器获取内容。静态内容请求的缓存命中率通常可以达到 90%甚至更高，实际上，这意味着削减了我们数据中心 90%的流量成本。

• 确保做好准备以在流量突然增加时可以应对流量高峰。CDN 已经在开发大型基础设施上投入了大量时间和精力，这些基础设施都可以很好的应对流量扩展需求，无论是 Reddit 和 Hacker News 的专题报道，还是UEFA冠军联赛决赛的现场直播。

就 Property Finder 和类似的资源密集型网站而言，我们的主要目标是，用尽可能最快的方式把我们所有以 TB 计算的资源提供给客户。

为了确保所有这些以及最佳最有效的缓存策略，除了使用可靠和分布良好的 CDN，我们尽我们最大的努力使用正确的缓存控制头部，这些缓存控制头部对不同的内容类型有适当的有效期；忽略查询字符串以避免缓存崩溃，使用不可变标志等等。

谁在用 CDN？

大家都在用！

如今，大部分的互联网流量都流经互联网交换点（Internet Exchange Points），这是流量可以免费或支付很少费用就进行交换的地方。在那里，大型的内容供应商（如 Netflix、脸书、谷歌/油管）和 ISP 尽可能以最低的延迟和最高的吞吐量连接和交换流量。

在 Medium.com 上读这篇博文的时候，我们已经不知不觉地访问了 Cloudflare，它是最受欢迎的 CDN 之一。另外，当我们在 Spotify 上播放我们喜欢的歌曲时，我们的设备可能已经和 Fastly 的服务器建立了连接。

AWS Cloudfront、谷歌云或其他 CDN 为我们喜欢的博客和新闻门户网站提供服务。就像大多数互联网用户一样，我们也通过访问脸书、Instagram、https://peering.google.com/ \l /">油管、Netflix等为私有 CDN 带来了一些流量。

我们也许认为，只有那些大公司才用 CDN，那我们就错了。如今，创建网站、应用程序或在线服务而不考虑为流量提供最优服务几乎是无法想象的。使用 CDN 的前期规划很有意义。

想象一个常见的创业公司场景：我们有了一个创业想法，我们认为在用户方面增长很快、规模扩展很快以及有很多流量（以及突然发生的流量峰值）。

我们应该从第一天开始就考虑 CDN 吗？绝对应该！

我们希望预先优化成本，而同时达到最佳性能。要做到这一点，我们可以凭直觉、朋友的推荐、谷歌搜索……或是，我们可以使用具有实际数字的科学统计数据而不只是猜测。如果你还感兴趣，请继续阅读。我们的研究从这里开始了！

创建测量

为了创建我们首个使用 RIPE Atlas 的测试，我们可以使用 web UI 或一个好用的 JSON API。

使用 RIPE Atlas Web Wizard 非常简单；只需要几次点击就可以，我们可以利用相关的参数来创建一个测量 。

RIPE Atlas Web UI

可供用户使用的探测器被托管在不同的地方：住宅区家中的本地路由器上、工作场所和办公室的机架上以及数据中心中。它们还可以通过移动 4G 连接或在非常遥远的地点通过卫星上行链路连接。只要有以太网连接，连接的来源则并不重要。

IPv4 和 IPv6 网络的覆盖范围基本相同：低于全球自治系统数量（autonomous system numbers，简称 ASNs）的 10%。

IPv4 ASNs 覆盖数 — 3602 (占 5.627%)

IPv6 ASNs 覆盖数 — 1446 (占 8.617%)

从全局来看，全球所有主要的消费者 ISP 和托管企业有足够数量的探测器托管给他们，并且，世界上几乎所有的国家都已连接在一起——182 个国家（占 92.857%）。

研究方法论

很全的 RIPE Atlas REST API

如上所述，在某些场景中，使用 web UI 有其缺点。

尤其是在我的例子中，因为我想逐一分析世界上所有的国家，选择探测器，然后通过不同的标签过滤，而对 182 个国家手动重复这一过程将无比麻烦。

幸运的是，所有这些都可以通过一个非常简单的 REST API 来完成。

首先，我们需要一个关键材料来进行这项研究：大量的 RIPE Atlas 信用额度。幸运的是，我有一个连接时间超过 5 年的探测器，它已经收集了差不多 6 千万信用额度，用来做十多次这样的研究也绰绰有余。我偶尔做一些用于私人目的的研究以及类似这个研究的调查。

其次，通过分析目前的 CDN 市场以及优选具有全球影响力而不只是区域可用性的公司来确定 CDN 供应商列表。

以下是为本次研究选取的 CDN 的供应商（一共有 7 个）：

1）Akamai：市场中的老牌玩家

2）AWS Cloudfront：全球玩家，拥有约 200 个 PoP，遍布 30 个国家/地区 。他们有区域边缘入网点，所有其他入网点连接到这些点作为预先优化步骤，以集中到区域边缘入网点。

3）微软Azure：有 130 多个入网点，以及具有不同层的超大网络。

4）Cloudflare：最受中小网站欢迎，拥有非常丰富或几乎无限的免费层。

5）谷歌云CDN：将谷歌的全球网络与云存储或计算引擎实例（Compute Engine instance）结合使用。

6）Fastly：受不同大规模项目（Github，Spotify 等）欢迎的 CDN。可在 30 个入网点中使用，并计划扩展到更多个入网点。

7）Cachefly：曾经是以美国为中心的 CDN，但是最近成长为全球玩家。

确定了 CDN 供应商列表后，由于 Go 编程语言有简单的并发原语，我就决定用它来写个简单的脚本。这个小脚本（不到 200 行）遍历各国的 ISO2（ISO 3166）代码，把它们和所有以前定义的 CDN 的可能组合结合在一起，并给 RIPE Atlas 的 API 发送一个三包的 ping 测量 API 请求。

Cloudflare 在 1.1.1.1 上有自己广受欢迎的 DNS 解析器。对于 Cloudfront 和谷歌云，我不得不创建我自己的分发，但是，借助一些公司公开使用它们（FIFA 等）的著名主机名，所有其他的都很容易进行测试。

选定的目标主机名

使用请求选项，我们最多选择 50 个探测器，并使用一些标签来过滤掉所有不可用或不稳定的探测器，因为这些探测器会给我们的结果带来不良影响。我使用的探测器选择标签是 system-ipv4-capable、system-ipv4-works 以及 system-resolves-a-correctly，以确保 DNS 解析正常工作。

解析测量结果

在创建了测量后，我们一收到 API 响应就把测量 ID 以 CSV 文件的格式存入结果数据库。这个数据库用于存储所有的测量 ID 及其国家/CDN 密钥对。我们需要等待一段时间，有时候可能需要 15 分钟时间，才去取测量结果 。此外，由于 RIPE Atlas API 方面的限制，API 调用必须定期暂停：最多允许 100 个并发测量及每天 1 百万信用额度。

由于并不是所有的国家/地区都有 RIPE Atlas，因此，有些请求失败了；这是预料中的事，这些响应被丢弃，因此，在结果图中出现了一些灰色区域。

以下是从 web UI 角度看单次测量结果的截图：

在 Web UI 上进行单次测量的结果

我们可以看到所有涉及到的探测器，以及它们相关的 ASN、以百分比显示的丢包率和从探测器到目标主机的往返时间。（我们感兴趣的指标）当然，通过 API 使用这些结果更有意义，那将是我们重点关注的。

除了 avg 字段，该响应还包含 3 个 ping RTT

所有的结果按每个 CDN 被分到不同的目录中，在这些目录中，按每个国家/地区创建一个文件。

可以在 GitHub 存储库中获取结果集：https://github.com/emirb/ripe-atlas-cdn-analysis

从 RIPE Atlas API 收集了所有的测量值并存储之后，我最终得到了如下格式的组合：

iso2_code，cdn_name，rtt_ms

最终，整个研究消耗了大约 5 万信用额度。

结果

在大多数国家/地区中，速度最快的是 Cloudflare。

全球性能最好的是 Cloudflare，接下来是谷歌云、Akamai 和 Azure。

世界地图上，速度最快的 CDN 的分布情况

在世界地图上，情况丰富多彩，赢家遍布各地。

平均 CDN 延迟

每个国家的 ping 往返平均延迟大多在 50ms 以下。在欧洲，这个值通常是 10ms 左右。

欧洲性能最佳的 CDN

全球平均 CDN 延迟

备注：36ms 并不意味着这是平均值。如果整个研究再进行几次，总是会得到不同的结果，因为每次测量中包含的 50 个探测器是随机分配的。这种随机性在有大量探测器（500 个或更多）的国家会产生有偏差的结果。

另外，请记住，不是每个国家/地区中的所有 ASN 都安装了 RIPE Atlas 探测器。因此，有时候，可以人为地提高结果，因为在这个国家/地区中，那些探测器都属于同一个 ASN，并且该 ASN 跟目标主机的良好连接具有低延迟性；另一方面，如果一个国家/地区只有 2 个探测器，并且两者都对任何主机名执行不良（连接到任何地方的初始 ping 都要 100ms 以上）的话，那么，得到的结果会更糟。同样，对此的解决方案是，使每个国家的探测器多样化，并覆盖尽可能多的 ASN，每个 ASN 应该至少有一个探测器。

可以点击这里查看交互式地图。

结论

Cloudflare 具有最佳的地理分布，并且很显然，他们在不断地添加新的 PoP；他们已经拥有 180 多个 PoP。

在很长一段时间里，Akamai 曾经是最好的也是最贵的 CDN，几乎只有那些非常大的公司才会使用它。通过私有对等网络，他们与 ISP 签订了不同类型的协议，并且在很多IXP上建立了连接。在 MENA 地区，他们做得很不错。正如我在介绍中提到的，到目前为止，其表现令人满意。

考虑到谷歌网络的庞大规模，请注意，我们可以选择不同的网络层来使用谷歌云。选择 Premium 比选择 Standard 网络层的费用要多得多，但因为流量将以不同的方式路由，所以我们可以得到更好的性能和可靠性。

在使用谷歌云的 Premium 网络层时，流量应该流经谷歌内部质量更高的网络

Azure 也有点独特，可以根据网络选择产生不同的结果。在 Azure 上创建 CDN 分发时，我们可以在这三者中进行选择：Verizon、Akamai 和微软 CDN，这三个运行在不同的网络上。如果我们希望使用 Akamai，通过 Azure 使用它可能是最简单的方法；否则，我们必须联系 Akamai 销售部门并且要拥有相当高的流量。

在对这项研究的成果进行总结之后，我尝试看看是否有任何有效且被维护的工具来对 CDN 做近乎实时的分析。

其中一些被证明是非常好的，很有帮助！

比如，CloudHarmony也使用 RIPE Atlas 探测器，并提供一个漂亮的 web UI，并且带有过滤器和图表。

另一方面，CDNPerf使用专有数据进行 RUM 分析。其实只要可以，我更喜欢选择开源和公共数据。

没有 RIPE Atlas 项目，就没有这整个研究。如果你愿意参加，请点击这里申请托管一个物理探测器。

无论如何，可以确定的是选择一个恰当的 CDN 并不容易，并且也没有很多数据的支持。

注意：本博文是 2019 年 4 月举办的 RIPE SEE 8 大会上一场演讲的转录。视频链接地址在此：https://www.youtube.com/watch?v=zDm8uv8kER8

原文链接：

Need for Speed: Analysing global CDN performance