2026 年 Cloudflare 全球网络和骨干网。
Cloudflare 网络最近达到了一个重要里程碑：外部容量突破了每秒 500 太比特 (Tbps)。
此处的 500 Tbps 是指总配置的外部互连容量：也就是覆盖 330 多个城市的面向上游网络服务提供商、专用对等互联合作伙伴、互联网交换中心或 Cloudflare Network Interconnect (CNI) 端口的所有端口容量总和。这不是峰值流量。在任何一天，Cloudflare 峰值利用率远低于这个数字。（其余的预算是指 DDoS 防护流量。）
与最初的起点相比，我们已经取得了很大进展。2010 年，我们在帕洛阿尔托市一家美甲店楼上的小办公室开始了创业之路，当时采用单个上游网络服务提供商，以及只需修改两个名称服务器即可设置的反向代理。
我们的首个上游网络服务提供商是 nLayer Communications，也就是现在大多数人熟知的 GTT。nLayer 为我们提供了最初的处理容量，让我们首次实际参与了对等互连关系的建立与管理，并切身体会了在成本与性能之间做出精细权衡。
从那以后，我们逐个城市扩张：芝加哥、阿什本、圣何塞、阿姆斯特丹、东京。每新建一个数据中心，就意味着洽谈主机托管合同、铺设光纤、安装服务器机架，以及通过互联网交换中心建立对等互联。当然，互联网实际上并不是“云”环境。它由许多布满线缆的特定机房组成，我们花费数年时间才了解每个机房的细微差别。
并不是每个城市的部署都一帆风顺，还必须解决硬件缺失、海关罢工，甚至牙线也可能成为问题。2018 年的某个月，24 天时间内我们在 31 个城市开设了数据中心：从加德满都和巴格达，到雷克雅未克和基希讷乌。当 Cloudflare 在澳门开设第 127 个数据中心时，我们保护着七百万份互联网资产。如今，Cloudflare 凭借遍布全球 330 多个城市的数据中心，保护着 20% 以上的 Web 流量。
随着我们业务规模的不断扩大，客户的需求不再只是网站缓存而已。他们需要保护员工安全、替换老旧的多协议标签交换 (MPLS) 线路，以及保护整个企业网络安全。我们没有采用传统设备，而是构建了系统来建立通往专用子网的安全隧道，并通过 BGP 协议直接从 Cloudflare 全球网络公布企业 IP 地址空间。
威胁规模也同步扩大。2025 年，我们成功缓解了一次持续 35 秒、峰值流量高达 31.4 Tbps 的 DDoS 攻击。攻击来源是 Aisuru-Kimwolf 僵尸网络，其中包含大量已受感染的 Android 电视。当天我们拦截了 5000 多次攻击，这次攻击只是其中之一。我们没有呼叫任何工程师来处理。
十年前，这种规模的攻击需要国家级资源才能应对。如今，Cloudflare 网络无需人工干预即可在数秒内处理。这就是 500 Tbps 规模网络运行的必要条件：将威胁情报部署到网络中的每一台服务器上，从而实现网络的自我防御。
以下是 Cloudflare 网络遭受攻击时实际发生的情况。数据包到达网络接口卡 (NIC) 并立即进入由 xdpd 管理的 eXpress Data Path (XDP) 程序链，该程序链以驱动程序模式运行。该程序链中的第一个程序是 l4drop，它会根据 extended Berkeley Packet Filter (eBPF) 中的缓解规则评估每个数据包。这些规则由 Cloudflare 拒绝服务守护进程 dosd 生成，该进程运行在我们集群中的每台服务器上。每个 dosd 实例会对传入流量进行采样，构建一个表来记录其检测到的最严重攻击，并将该表广播给机房中所有其他实例。最终形成共享的全机房流量视图，而且由于每台服务器都利用相同的数据开展工作，因此，它们会做出相同的缓解决策。
如果 dosd 检测到攻击模式，它会通过 l4drop 在本地应用生成的规则，并通过 Cloudflare 分布式键值 (KV) 存储系统 Quicksilver 在全球范围内传播，从而在几秒钟内到达每个数据中心的每台服务器。数据包只有在经过 l4drop 过滤后才能到达 Unimog，也就是 Cloudflare 第 4 层 (L4) 负载均衡器，它会将数据包分发至数据中心内正常运行的服务器。对于通过 Cloudflare 边缘来路由企业网络流量的 Magic Transit 客户，flowtrackd 增加了一层有状态的 TCP 检测，用于跟踪连接状态并丢弃不属于合法流量的数据包。
我们缓解的 31.4 Tbps 攻击恰好遵循了这一路径。未将流量回传到集中式清洗中心。整个过程也没有任何人为干预。目标数据中心内的每台服务器各自独立识别了攻击，并在恶意数据包进入主 CPU 处理流程消耗计算资源前以线速将其丢弃，使恶意流量无法到达应用层。软件只是成功的一半：如果端口根本无法接收流量，则这一切都无济于事。
在 Cloudflare 网络中的每台服务器上运行代码，这是掌控整个技术栈的自然而然的结果。既然我们已经在每台机器上运行 eBPF 程序来丢弃攻击流量，那么我们也可以在机器上运行客户应用程序代码。该见解催生了 Workers，后来又发展为 KV 和 Durable Objects。
Cloudflare 开发人员平台运行在我们运营数据中心的每个城市，而不是仅限于少数几个云区域。2025 年，我们将 Containers 添加到 Workers，从而也能在边缘运行更繁重的工作负载。V8 Isolates 和自定义文件系统层可最大限度地减少冷启动。代码在用户所在地的服务器上运行，这些服务器通过 l4drop 以线速丢弃攻击流量。攻击流量在到达网络栈之前已被丢弃。因此，应用永远不会看到这些攻击流量。
Cloudflare 是 IPv6 和资源公钥基础设施 (RPKI) 的早期采用者。BGP 劫持会导致真正的服务中断和安全漏洞。RPKI 支持我们丢弃来自对等网络的无效路由，确保流量流向正确的目的地。我们为前缀签署路由源授权 (ROA)，并对入站流量强制执行路由源验证。我们拒绝 RPKI 无效路由，即使这偶尔会导致与配置错误的 ROA 网络之间的连接中断。
接着是自治系统提供商授权 (ASPA)。RPKI 验证前缀的所有者。ASPA 验证到达当前位置所经过的路径。RPKI 就像是在目的地进行护照检查，确认前缀的真正所有者，而 ASPA 则像是航班舱单核对：它验证流量经过的每一个网络。路由泄漏就像是乘客在错误的城市登机；RPKI 无法检测到，但 ASPA 可以。
目前 ASPA 的生态系统采用情况与 2015 年 RPKI 的采用情况类似。Cloudflare 网络是最早大规模部署 RPKI 的网络之一，如今，全球路由表中 867000 个前缀拥有有效的 RPKI 证书；而在 10 年前，这个数字几乎为零。鉴于 Cloudflare 网络的规模，我们选择的协议可能会对更广泛的互联网产生切实的影响。我们力求尽早采用，因为等待越久，遭受网络劫持和数据泄漏的风险就越大。
AI 改变了网络影响力的意义。在互联网发展的大部分阶段，流量都是由真人用户产生，即：由人们在浏览器中点击链接而生成。如今，AI 爬网程序、模型训练管道以及自动化智能体占据网络中 HTML 请求的比例已超过 4%，与 Googlebot 本身相当。“用户操作”抓取（即：AI 在收到用户提问后访问页面）仅在 2025 年就增长了 15 倍以上。
AI 爬网程序在基础设施层面的行为表现与浏览器截然不同。浏览器加载页面后便会停止。而爬网程序则会以最大吞吐量抓取所有已链接资源，请求之间没有停顿。鉴于 Cloudflare 网络的规模，区分合法 AI 爬网程序与实际攻击流量是真正的工程难题。我们的检测系统综合利用经过验证的机器人 IP 地址范围、TLS 指纹、行为分析和 robots.txt 合规信号，以进行此类区分，并为网站所有者提供所需数据，助其做出允许哪些爬网程序访问网站的决策。
例如，在 TLS 层，合法的浏览器会发送一则 ClientHello 消息，其中包含与其声明的 User-Agent 匹配且可预测的密码套件、扩展和顺序。而伪造 User-Agent 但使用精简版 TLS 库的爬网程序则会发送不同的指纹，这种不匹配正是 Cloudflare 系统用于对流量进行分类的信号之一，防止请求到达源服务器。
助力 Cloudflare 构建下一个 500 Tbps
最初，Cloudflare 在帕洛阿尔托市一家美甲店楼上开始创业，如今已发展成为覆盖全球超过 125 个国家/地区 330 多个城市的 500 Tbps 网络，其中的每台服务器都运行着我们的开发人员平台和安全服务，不仅仅只是缓存。这不仅凝聚了 Cloudflare 过去十六年的架构决策演变及发展成果，而且也离不开与我们对等互联的 13,000 多个网络和合作伙伴的支持。但我们的征程尚未结束。
如果您是网络运营商，欢迎与我们建立对等互连。如需了解 Cloudflare 对等互连政策以及互连详情，请查看 PeeringDB。如有兴趣将 Cloudflare 基础设施直接嵌入您的网络，请联系我们的团队 [email protected]，加入边缘合作伙伴计划。