Web3 底层基建？简析 CloudFlare 服务中断的原因

撰文：阿法兔

本篇文章，会讲一下什么是CloudFlare，到底是个什么公司，CloudFlare和Web3的缘起，以及从技术上解释一下本次故障的原因。

事件背景

6 月 21 日（周二）发生了一件事，就是因为 Cloudflare 的服务暂时中断，影响了大量的服务和平台正常运营。包括 FTX，Discord，Omegle，DoorDash，Crunchyroll，NordVPN 和 Feedly 等等、还有 Zeroda，Medium.com，新闻媒体 Register，Groww，Buffer，iSpirt，Upstox 和 Social Blade 的，用户无法访问这些网站，甚至 Coinbase，Shopify 和英雄联盟也受到了部分影响。

本篇文章，会讲一下什么是 CloudFlare，到底是个什么公司，CloudFlare 和 Web3 的缘起，以及从技术上解释一下本次故障的原因。

什么是 CDN（内容分发网络）

在讲 Cloudflare 之前，我们先普及一个概念（CDN）

什么是 CDN？

CDN，全称为 Content Distribute Network (内容分发网络) 或者 Content Delivery Network；那么，什么是内容分发网络呢？是可以通过互联网互相连接的电脑网络系统，利用最近每位用户的服务器，更快、更可靠地将音乐、图片、视频、应用程序及其他文件发送给用户，来提供高性能、可扩展性及低成本的网络内容传递给用户。

形象的说，CDN 有点类似于京东物流模式，通过在全国各地建立物流点 (缓存服务器)，当有人从京东购买货物时 (用户资源请求)，京东上次可以根据用户的收货地址 (CDN 进行用户域名解析) 找最近的或者最快的一个物流点进行派送 (将访问用户连接到最近的缓存服务器进行资源传输)。

CDN 服务可用于确保快速可靠地分发静态内容，这些内容可以缓存，最适合在网速庞大的网络中存储和分发，这样就能把主干网络通道空出来给必须实时传输的动态内容，比如网络直播，降低时延。

我们举个例子，比如有一家英国公司，主要客户也在英国，如果给这家公司建立网站，那么，通常会把网站服务器放在英国。但是，会存在延迟这样的情况，影响用户们的网站访问体验，不过，如果延迟是由于网络阻塞导致的，那么这种延迟是可以改善的。具体怎么改善呢？

主要是通过提高点到点之间的带宽、优化网络路由来解决这些问题。举个例子，比如从伦敦到牛津，增加这两地之间光纤的数量，就是最容易的提高带宽方法。

注意，这里光纤数量主要是我们建设基础设施如海底光缆、铁路和高速公路的时候，同时铺设的。因此，这些年我们用的带宽一直在增加，你可以把增加网络贷款理解为拓宽交通公路，就是个花钱铺设的事情。

路由

我们前面提到过网络路由，路由是啥呢？其实路由解决的主要问题，就是两点之间的通信，究竟走什么线路的问题。举个例子，一旦伦敦到牛津的出现网络堵塞，系统还可以选择其他路由。有点像智慧交通，互联网的路由优化也类似。所以这些年，尽管流量越来越大，但是网络性能也是一直在改善的。

通俗一点讲，就是给网站加速，部分网站由于原因使得打开变得极为缓慢，这就需要用 CDN 来进行加速。

CDN 也是一类较为先进网络技术，解决内容在互联网上的分发问题。什么是内容分发网络呢？这与交通网络类似，也就是说，再快的飞机，也是有速度上限的，距离越远，延迟越长。网络也一样，如果距离远，就会出现网络延迟的情况。

所以如果某个欧洲用户想要访问美国网站的内容，CDN 就是在欧洲建立一个服务器，把美国的内容翻译到这个服务器。当欧洲用户进入域名访问时，由于 CDN 运营商知道这个用户访问来自欧洲系统，就把欧洲服务器的 IP 地址给这个用户，用户自然就访问到欧洲的服务器了。

CDN 公司通常都是安全公司？

属于 CDN 一个重要特点，是 CDN 天生具备安全属性，因为 cdn 对哪些人在访问用户的网络非常清楚，因此，可以帮助客户阻挡网站攻击。网络安全是 cdn 公司的一项增值服务，尽管 cdn 的出现，远远早于云计算，但是目前大家已经把 cdn 归类成云计算，原因是用户通常会根据使用量，来对 cdn 服务进行按月付费和按照流量付费，这其实属于典型的云计算订阅模式，同时 cdn 的服务器也不一定就是传统的物理服务器，这些服务器可能也是来自公有云运营商的虚拟机，所以现在你完全可以把 CDN 看成一个云计算的 IaaS 服务。

注：本部分关于 CDN 的解释内容，部分来自于 Youtube 博主老科谈科技股

Cloudflare 是个什么公司？

2010 年，Cloudflare 正式创立，总部位于美国旧金山。是一家以其 CDN 和安全服务为主营业务的公司，Cloudflare 公司的主营业务是向客户提供基于反向代理的内容分发网络及分布式域名解析服务（Distributed Domain Name Server）。从 2009 年开始，该公司由 Union Square Ventures 等风险投资参投，百度也参与了 Cloudflare 的 D 轮融资， 2019 年 8 月 15 日，Cloudflare 正式 IPO。

除此之外，Cloudflare 收购了一系列网络服务和安全公司，2014 年收购 StopTheHacker 、CryptoSeal；2016 年收购 Eager Platform Co.；17 年及以后收购 Neumob、S2 Systems、Linc、Zaraz；今年收购了 Vectrix 和 Area 1 Security.

Cloudflare 和 Web3 的缘起

Cloudflare 是比较早就开始支持 Web3 开发的 CDN 公司，它的官网是这么说的：Cloudflare 是用户通往 Web3 的门户，通过 Cloudflare，可以轻松访问 IPFS 和 Ethereum 网络。并且，官网提到，Web 1.0 让世界有了快速传播信息的能力，而 Web 2.0 则让这些信息具有互动性。Web 3.0，或 Web3，被认为是互联网的下一次迭代，建立在 IPFS 和以太坊等去中心化的技术之上。

图片来自 Cloudflare 官网

Cloudflare 具备 IPFS Gateway，客户可以在继续使用 HTTP 协议的时候，同时享受 IPFS 的好处。

Cloudflare 以太坊网关允许客户使用自己的域，可以通过 HTTP 的 JSON RPC 查询发送到自定义域名。Cloudflare 可以管理、维护和监控 Web3 基础设施，构建者可以专注于重要的事情：构建 Dapp。Cloudflare 可以通过行业内领先的全球网络，创建基于 Web3 技术的安全、可靠和快速服务。

Cloudflare 为什么会发生服务中断？

2022 年 6 月 21 日的 Cloudflare 服务中断事件的官方解释：

2022 年 6 月 21 日，Cloudflare 服务中断，影响了 19 个数据中心的正常运行，而不幸的是，这 19 个地点处理了 Cloudflare 很大一部分全球数据。这次服务中断是由一个长期运行项目出现的问题引起的，这个项目主要是想提高最繁忙数据中心的弹性而发起的。是因为，更改了部分位置的网络配置，而导致服务中断，中断的具体时间是从 UTC 时间 06：27 开始，到了 06：58 UTC，第一个数据中心重新开始工作，到 07：42 UTC，所有数据中心都可以正常工作。根据用户在世界上的不同位置，可能无法访问依赖 Cloudflare 为基础设施的网站和服务，不过在其他没有受影响的地点，Cloudflare 继续正常运行。

对此次中断，Cloudflare 深表歉意，这是 Cloudflare 的错误，而不是因为攻击或其他恶意活动的。

本次架构转型的背景

在过去 18 个月，Cloudflare 一直致力于将所有最繁忙的数据中心的架构转型，让它们更为灵活、且更具弹性。目前，已经有 19 个数据中心，成功转换为此架构，Cloudflare 内部称其为 Multi-Colo PoP（MCP）; 这 19 个数据中心分别位于：阿姆斯特丹，亚特兰大，阿什本，芝加哥，法兰克福，伦敦，洛杉矶，马德里，曼彻斯特，迈阿密，米兰，孟买，纽瓦克，大阪，圣保罗，圣何塞，新加坡，悉尼和东京。

这个新架构被设计成 Clos 网络，它的一个关键部分是增加了一个额外的路由层（见下图），创造了一个网状的连接。这个网状结构使我们能够轻松地禁用和启用数据中心的部分内部网络，以便进行维护或处理问题。这一层由下图中标识为的 Spine 部分表示。

注：Clos network 是一种多级交换网络，由 Charles Clos 于 1953 年首次正式使用该术语，它代表了实际多级电话交换系统的理想化表示。当物理电路交换的需求超过了单 crossbar switch 的最大可实现容量的时候需要使用 Clos network。Clos network 的主要优势点在于：所需的交叉点数量远小于整个交换系统使用一个大的 Crossbar Switch 来实现所需的交叉点数量。

这种新的架构显著改善了 Cloudflare 的可靠性，可以使 Cloudflare 能够在这些地方进行维护，并且不中断客户流量。不过，由于这些地点同时也承载着 Cloudflare 流量的很大部分，任何这里的问题都会产生非常广泛的影响，不幸的是，这就是 6 月 21 日 Cloudflare 服务终端的原因所在。

服务中断的时间线和影响

Cloudflare 应用了名为 BGP 的协议 (边界网关协议，Border Gateway Protocol，是运行于 TCP 上的一种自治系统的路由协议 )。该协议的由运营商定义政策，决定有哪些前缀（相邻 IP 地址的集合）会被广播给对等的节点（他们连接的其他网络）。这些策略有单独的组成部分，按顺序进行评估。最终的结果是，任何给定的前缀要么被广播，要么不被广播。政策的变化可能意味着以前会广播的前缀不再被广播，被称为 「撤销」，这些 IP 地址将不再能在互联网上正常运行。

运营商制定了某种策略，决定某些路由前缀可以被广播（这里的广播指的是，路由可以被其他边缘 bgp 路由器学习到，进而其他的 bgp 网络知道这些路由变化，前缀就是 prefix，是用来唯一地标识着连入 Internet 的一个网络号）

前缀通告策略更改时，术语的重新编排，导致 Cloudflare 必须撤回前缀的关键子集。

政策的变化可能意味着以前会广播的前缀不再被广播，Cloudflare 工程师在受影响的数据中心，对有问题部分进行恢复时，就遇到了额外困难，不过 Cloudflare 有处理此类问题的备份程序。

• 03：56 UTC：Cloudflare 将更改部署到第一个（数据中心）位置，所有位置都没有受到此次更改的影响，因为这些位置使用的旧的架构。06：17：部署更改到 Cloudflare 最繁忙的地点，但是没有部署到具备 MCP（Multi-Colo PoP） 体系结构的位置。
• 06：27：部署到达了启用 MCP （Multi-Colo PoP）的位置，并且更改已部署到关键部位。这是服务中断事件开始的时候，这个时候，19 个数据中心迅速离线。
• 06：32：Cloudflare 内部宣布本次服务中断事件。
• 06：51：在路由器上进行的首次更改，以验证根本原因。
• 06：58：排查故障，找出根本原因，还原出现问题的部分
• 07：42：最后一次还原已完成，网络工程师开始检查对方的更改，还原状态，此时问题偶尔重新出现，因此延迟了一点。
• 08：00：服务中断事件结束。

这些数据中心的重要性，可以从下图全球范围内处理的成功 HTTP 请求的数量中清楚地看出：

尽管这些出问题的数据中心，仅占 Cloudflare 总网络的 4%，但这次中断影响了总请求的 50%；

（本部分有小部分代码，此处略去，感兴趣的网络工程小伙伴可查看原文）

补救和后续步骤

本次服务终端事件造成了广泛且严重的影响，Cloudflare 一贯对可用性是非常重视，目前已经提出了 v 几个需要改进的领域，而后将继续努力，发现可能潜在导致服务终端的所有问题。

流程：虽然 MCP 计划旨在提高可用性，但我们在更新这些数据中心方面的程序性差距，导致造成了严重影响。虽然 Cloudflare 确实为设计了交错策略，但是它并不完美，部署过程和自动化中，需要包含 MCP 的测试和具体部署过程，以确保不会产生意外后果。

架构：路由器配置的错误会阻止正确的路由广播，从而阻止了正常流量和基础设施的运行。Cloudflare 将会重新设计路由广播的策略语句，防止排序的错误。

自动化：Cloudflare 自动化套件中有可以降低此事件负面影响的部分。Cloudflare 将专注于自动化改进，为网络配置的推出强制实施改进的交错策略，并提供自动 「提交 – 确认回滚」。前者将大大降低整体影响，后者将大幅度减少事件中的解决时间。

结论

尽管 Cloudflare 在 MCP 架构设计上投入了大量资金，提高服务可用性，但在本次服务中断事件中，让客户失望了。对于服务中断期间，无法访问互联网和数字资产的客户，以及所有用户，Cloudflare 深表歉意，已经开始着手进行所有的改进和优化，努力确保类似情况不会再次发生。

【参考文献】

CDN解释部分：Youtube-老科谈科技股-Cloudflare

企辰科技：云、CDN、IDC 三个概念的区别是什么？

Cloudflare outage hit crypto exchanges FTX, Bitfinex and more

https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/

Cloudflare fixes outage that knocked popular services offline

https://en.wikipedia.org/wiki/Cloudflare#cite_note-13

https://en.wikipedia.org/wiki/Cloudflare

https://baike.baidu.com/item/%E8%BE%B9%E7%95%8C%E7%BD%91%E5%85%B3%E5%8D%8F%E8%AE%AE/2987527?fromtitle=BGP%E5%8D%8F%E8%AE%AE&fromid=1989644&fr=aladdin

https://www.cloudflare.com/zh-cn/web3/