Cloudflare 运营着全球速度最快的网络。我们今日发布了一则更新动态，介绍了我们如何全面升级加速整个服务器集群的软件技术，从而在全球范围内提升网络速度。
但这并非工作的终点。为了进一步提升速度，我们还必须确保我们的网络能够迅速应对每天遇到的互联网规模的拥堵，并将流量路由到我们现在速度更快的服务器上。
多年来，我们一直致力于拥塞控制技术的研发。今天，我们非常高兴地与大家分享：我们正充分发挥网络的独特优势——庞大的 Free 计划用户群体，来优化网络性能，并为全球所有客户探寻最佳的网络流量路由方案。
初步结果显示，性能提升幅度平均比之前的基准水平高出 10%。我们通过应用不同的算法，并根据每天观测到的互联网数据来提升性能，从而实现了这一成果。我们很高兴能够开始向所有客户推广这些改进。
互联网是由众多相互连接的网络组成的庞大集合，每个网络都包含许多机器（“节点”）。数据传输的方式是将其分割成小的数据包，然后通过“链路”从一台机器传递到另一台机器。每台机器都与其他许多机器相连，而每条链路的容量都是有限的。
当我们在互联网上发送数据包时，它会沿着从 A 到 B 的链路经过一系列“跃点”。在任何给定时间，总会有一条链路（即一个“跃点”）的可用容量最小。无论这个跃点位于连接中的哪个位置，它都会成为瓶颈。
但这里存在一个挑战——当您在互联网上发送数据时，您无法预知数据会走哪条路径。事实上，每个节点都会自行决定发送流量的路径，从 A 点到 B 点的不同数据包可能走完全不同的路径。正是这种动态和去中心化的特性造就了互联网的高效性，但也使得计算数据发送量变得异常困难。那么，发送方如何才能知道瓶颈在哪里，以及发送数据的速度如何呢？
在 Cloudflare 节点之间，我们的 Argo Smart Routing 产品利用我们对全球网络的可见性来加速通信。同样，当我们发起与客户源站的连接时，我们可以利用 Argo 和其他洞察来优化连接。但是，从您的手机或笔记本电脑（下文中的“客户端”）到最近的 Cloudflare 数据中心的连接速度将取决于从您到 Cloudflare 链路中的瓶颈节点的容量，而该节点位于我们的网络之外。
如果网络中某个节点在处理请求的过程中接收到过多数据，请求者就会因为网络拥塞而遇到延迟。数据要么会被暂时排队（这可能会导致缓冲区膨胀），要么部分数据会被直接丢弃。TCP 和 QUIC 等协议会通过重传数据来响应丢包，但这会引入延迟，甚至可能因为进一步占用有限的网络容量而使问题更加严重。
如果像 Cloudflare 这样的云基础设施提供商不能妥善管理网络拥塞，我们就有可能面临系统过载的风险，从而降低数据传输速度。这种情况在互联网早期就曾发生过。为了避免这种情况，互联网基础设施社区开发了拥塞控制系统，让每个用户轮流发送数据，而不会造成网络过载。随着网络变得越来越复杂，这方面的挑战也在不断演变，而实现拥塞控制的最佳方法也需要持续不断的探索。目前已经开发出许多不同的算法，它们利用不同的信息源和信号，采用特定的优化方法，并以不同的方式应对拥塞。
拥塞控制算法利用多种信号来估算发送流量的合适速率，而无需了解网络的具体配置。其中一个重要的信号是丢包。当接收到数据包时，接收方会发送一个“ACK”确认包，告知发送方数据包已成功传输。如果数据包在传输过程中丢失，发送方将无法收到确认包，并在超时后将该数据包视为已丢失。
更新的算法使用了更多数据。例如，我们一直用于处理大部分流量的一种名为 BBR（瓶颈带宽和往返传播时间）的流行算法，会在每次连接期间尝试构建一个模型，使用往返时间的估计值以及丢包信息，计算给定时间段内可以传输的最大数据量。
最佳算法的选择通常取决于工作负载。例如，对于视频通话等交互式流量，如果算法倾向于发送过多流量，则可能导致队列积压，从而造成高延迟和糟糕的视频体验。但如果仅仅针对此类用例进行优化，并通过减少流量来避免这种情况，则网络将无法为进行批量下载的客户端提供最佳连接。性能优化的结果会因多种因素而异。但是，我们能够了解到其中的许多因素！
BBR 是拥塞控制方法领域的一项重大进展，它从基于损耗的被动方法转向基于模型的主动优化，从而显著提升了现代网络的性能。我们的数据为我们提供了进一步探索的机会，可以应用不同的算法方法来提高性能。
现有的所有算法都只能利用当前连接生命周期内收集到的信息，这无疑是一种局限。不过值得庆幸的是，我们在任意时刻掌握的互联网信息量都远不止于此！凭借 Cloudflare 对网络流量的全局视角，我们能获取到的信息量，远超任何单一客户或互联网服务提供商在某一时刻所能掌握的。
我们每天都能看到来自全球几乎所有主要网络的流量。当请求进入我们的系统时，我们知道正在与哪个客户端设备通信，连接是由哪种类型的网络实现的，以及通信对象是消费者互联网服务提供商还是云基础设施提供商。
我们了解全球互联网的负载模式，以及我们认为系统过载的位置，无论是在我们的网络内部还是外部。我们了解哪些网络具有稳定的特性，哪些网络由于蜂窝数据连接而导致丢包率高，以及哪些网络通过低地球轨道卫星链路传输数据，并且每 15 秒就大幅改变路由。
我们一直在将网络技术栈迁移到一个基于 Rust 的新平台，该平台能够更灵活地调整用于处理拥塞控制的算法参数。然后，我们需要数据。
这些实验所依赖的数据需要反映我们试图优化的指标，也就是用户体验。仅仅将数据发送到全球几乎所有网络是不够的；我们必须能够了解客户的体验究竟如何。那么，我们该如何以如此庞大的规模做到这一点呢？
首先，我们有详细的“被动”日志，记录了数据从我们网络发送的速率以及目的地确认接收所需的时间。这涵盖了我们所有的流量，让我们大致了解客户端接收数据的速度，但并不能保证反映用户体验。
接下来，我们有一个系统用于收集真实用户测量 (RUM) 数据，该系统会记录受支持的网络浏览器中的页面加载时间 (PLT) 等指标信息。任何 Cloudflare 客户都可以启用此功能，并在其控制面板中查看详细的分析数据。此外，我们会汇总所有客户和网络中的这些元数据，以了解客户的真实体验。
然而，RUM 数据仅存在于我们网络中一小部分连接中。因此，我们一直在努力寻找一种方法，通过从被动日志中获取的数据进行外推来预测 RUM 指标。例如，以下是我们进行的一项实验的结果，该实验比较了两种不同的算法与立方基线算法。
现在，我们基于被动日志的预测数据，观察到了相同时间尺度下的情况。两条曲线非常相似，但更重要的是，两条曲线之间的比例也非常相似。这意义重大！我们可以使用相对较少的 RUM 数据来验证我们的发现，但通过使用完整的被动日志数据流，可以更精细地优化我们的网络。
过度推断会变得不可靠，因此我们也在与一些最大的客户合作，从他们的客户角度提升我们对网络行为的可见性，从而进一步扩展这一预测模型。作为回报，我们将能够以其他任何平台都无法提供的方式，为客户提供其客户的真实体验洞察。
我们目前正在所有免费计划的 QUIC 流量上运行拥塞控制实验和改进算法。随着我们不断积累经验，在更复杂的客户群体中进行验证，并扩展到 TCP 流量，我们将在 2026 年及以后逐步向所有客户的所有流量推出这项改进。结果表明，与基线相比，性能提升高达 10%！
我们正在与部分企业合作，通过提前体验计划测试这项功能。如果您有兴趣了解更多信息，请联系我们！