从全球 40% 到 60%：Cloudflare 是怎么在三个月里跑赢的
互联网的性能竞争，从来不是一场宣传战，而是一场持续的测量和追赶。 2025 年生日周，Cloudflare 公布了一个数字：在全球前 1000 大网络中，他们是最快的网络服务商的比例是 40%。同期博客里还附带了一句注脚——竞争对手在很多网络里差距其实很小，但 40% 这个数字，他们自己也不满意。 到 2025 年 12 月，这个数字变成了 60%。 三个月，从 40% 到 60%，他们做了什么？ 原文链接：https://blog.cloudflare.com/network-performance-agents-week/ 数字的可信度，取决于测量方法是否经得起推敲。Cloudflare 的方法论有几个值得单独说清楚的细节。 数据来源：全球前 1000 大网络 排名基于 APNIC（亚太互联网络信息中心）的数据，按估算用户规模选取全球前 1000 个网络。这些网络覆盖了几乎所有地理区域的真实用户，不是实验室环境，也不是特定运营商的定向测试。 指标选择：连接时间，而非带宽 很多网络测速工具喜欢用带宽作为核心指标，但带宽峰值往往和用户的实际感知相关性不高。Cloudflare 选择的是连接时间——用户设备完成握手所需的时间。 这个指标的好处是：它不够抽象（不会忽略真实的拥塞和距离因素），但又足够精确（能反映出影响用户体验的关键瓶颈）。对于大多数互联网应用来说，连接建立得越快，用户感知到的"网速越快"。 统计方法：trimean（三均值）过滤噪声 原始测量数据里会有各种噪声和异常值，直接取平均容易被极端情况带偏。Cloudflare 使用的是 trimean——对 P25（第25百分位）、P50（中位数）、P75（第75百分位）三个值做加权平均。这个方法能在过滤极端值的同时，保留对普通用户真实体验的代表性。 数据采集：真实用户测量（RUM） 性能数据不是在测试机房里跑出来的，而是从真实用户的浏览器里采集的。当用户遇到 Cloudflare 品牌的错误页面时，浏览器会静默地在后台跑一个小型速度测试：分别向 Cloudflare、Amazon CloudFront、Google、Fastly、Akamai 等多家服务商请求小文件，记录每次交换耗时。 这和"在赛道上测试赛车最高时速"与"观察真实路况下司机怎么开车"的区别一样——RUM 拿到的是高速公路上的真实驾驶数据，而不是跑道上的实验室数据。 从 40% 到 60%，背后的工作分为两个方向，一个是硬件层面的，一个是软件层面的。 光在真空中的传播速度是有上限的，网络延迟在物理层面受制于距离。离用户越近，延迟越低，这个逻辑没有捷径。 这段时间 Cloudflare 新部署了几个节点，其中有几个数据值得看一下： 波兰弗罗茨瓦夫（Wroclaw）：节点上线后，当地免费用户的平均 RTT 从 19ms 降至 12ms，降幅 40%。这不是统计意义上的微小改善，是用户能实际感受到的差距。 印度尼西亚玛琅（Malang）：企业客户流量的平均 RTT 从 39ms 降至 37ms，改善约 5%。绝对数字看起来不大，但在已有较好基础的情况下，每一毫秒的改善都需要付出相应的代价。 同期还有阿尔及利亚的君士坦丁（Constantine）等新节点上线。 硬件层面的投入效果是直观的，但 Cloudflare 也坦承：单纯靠新开节点，无法解释从 40% 到 60% 的全部提升。 更大的贡献来自软件层面的改进。Cloudflare 在博客里打了一个比方，很好理解： 软件层面的改进主要集中在几个方向： HTTP/3 的深度利用与拥塞窗口调整：HTTP/3 基于 QUIC 协议，天然对弱网和高丢包环境更友好，拥塞窗口的调整则直接影响在网络状况不理想时的传输速率。 连接建立效率：SSL/TLS 握手、流量管理、核心代理层的 CPU 和内存使用效率——这些是每一个请求都要经过的基础路径。在这里省下的毫秒，会乘以每天数百亿次的请求量，放大成可以被测量到的全局提升。 FL2 的持续推进：博客里虽然没有单独展开，但结合同期的 Gen 13 文章可以看到，Cloudflare 用 Rust 重写的新一代请求处理层（FL2）带来了显著的 CPU 和内存效率改善，这些改善直接反映在连接处理的速度上。 到 2025 年 12 月，对比 9 月的基准，Cloudflare 在以下维度实现了增长： 12 月全月数据显示，Cloudflare 的连接时间平均比第二名快 6ms。这个数字听起来不大，但在互联网性能的衡量维度里，稳定领先 6ms 已经是相当显著的差距。 Cloudflare 在文章最后说得很直接：60% 不是终点。 全球前 1000 个网络里，还有 40% 的网络他们不是第一。其中有一些差距很小，有时候可能就是几毫秒。这些差距在数据看板上是清晰可见的，每一个都是待完成的工作。 这篇文章背后有一个更值得关注的逻辑：网络性能的竞争，本质上是一场持续的工程投入，而不是一次性的技术优势建立。 Cloudflare 每隔几个月公布一次这样的测量结果，不只是为了展示进展，也是在用公开的数据给自己施加压力——上一次说了 40%，下一次就得拿出更好的数字来。 这种机制本身，就是一种驱动持续改进的方式。先说他们怎么量
两条提速路径
路径一：新建节点，缩短物理距离
路径二：软件优化，让每个连接更高效
想象收费站。排队变长，要么是收费窗口不够，要么是每个窗口处理得太慢。我们一直在同时做两件事：增加窗口（新节点），以及让每个窗口处理更快（软件优化）。
结果数据
60% 之后