#195 – Saumya Majumder谈Cloudflare故障如何影响网络及WordPress性能解决方案
Nathan Wrigley： 欢迎来到WP Tavern的Jukebox播客。我是Nathan Wrigley。Jukebox是一个专注于WordPress一切的播客。包括人物、事件、插件、区块、主题，以及本期我们将讨论的Cloudflare故障如何影响网络，以及WordPress性能解决方案。
如果您想订阅本播客，可以在您选择的播客播放器中搜索WP Tavern，或访问wptavern.com/feed/podcast，并将该URL复制到大多数播客播放器中。
如果您有希望我们在播客中讨论的话题，我很乐意听取您的意见，并希望您或您的想法能在节目中亮相。请访问wptavern.com/contact/jukebox并使用那里的表格。
今天播客的嘉宾是Saumya Majumder。Saumya是BigScoots的首席软件工程师，深度专注于高性能WordPress工程和先进的CloudFlare驱动架构。在他的整个职业生涯中，Saumya构建了从自定义缓存引擎到迁移工具、基于Worker的自动化以及边缘计算解决方案的大规模系统。他在BigScoots发挥了关键作用，监督企业客户，并开发可扩展、对开发者友好的解决方案，以突破WordPress托管服务的界限。
我们首先及时讨论了一场最近在整个互联网产生连锁反应的重大Cloudflare故障。Saumya解释了幕后发生的事情、这类全球基础设施故障的性质，以及为什么即使拥有最强大的系统，一些停机时间也是不可避免的。他就BigScoots如何为客户缓解这些问题提供了宝贵的见解，甚至在故障期间自动化快速故障转移以保持网站在线。
然后，我们继续探讨了BigScoots团队一直在进行的一些创新。他们专注于站点速度和可靠性。这包括CDN级别的页面缓存，以及他们与Cloudflare Enterprise的紧密集成。Saumya详细解释了这种缓存与传统服务器端缓存的区别，以及它如何确保全球用户能够快速、本地地访问网站内容。
如果您对托管公司如何管理如此高级的缓存策略以及Cloudflare如何融入托管拼图感到好奇，本期节目适合您。
如果您有兴趣了解更多信息，可以前往wptavern.com/podcast查看节目说明中的所有链接，在那里您也可以找到所有其他节目。
事不宜迟，有请Saumya Majumder。
我邀请Saumya加入本期播客。你好，最近怎么样？
Saumya Majumder： 嘿，我很好。你呢？
Nathan Wrigley： 我也很好，谢谢。这将是一次有趣的对话。我是通过Tammy Lister与Saumya取得联系的，Tammy在过去一段时间里一直与Saumya沟通。我不确定具体多久。但我们的想法是，我们将讨论他们在BigScoots所做的事情以及他们取得的那些有趣的创新。
纯粹是巧合，在我们录制节目的前一天，Cloudflare遇到了问题，它给整个互联网带来的“乐趣”发生了。所以我想我们会在播客开始时稍微离题，也讨论一下这个问题，这是意料之外的。但考虑到您的工作严重依赖于Cloudflare，这将是一个有趣的讨论。
不过，您介意花点时间介绍一下自己吗？告诉我们您是谁，您在当前职位上做什么，诸如此类，然后我们将深入我们的对话。
Saumya Majumder： 我是Saumya。我在BigScoots担任首席软件工程师，专门从事高性能WordPress工程和先进的Cloudflare驱动架构。
我还构建从自定义缓存引擎到迁移工具、基于Worker的自动化、边缘计算等各种大规模系统。
我还负责照看我们的企业客户、我们所有内部的WordPress项目和插件以及知识产权。此外，我还为我们的客户构建可扩展、对开发者友好的解决方案，以确保他们获得最佳的服务产品。
Nathan Wrigley： 非常感谢。现在，我想稍微详细探讨一下。您提到的很多内容看起来非常技术性，但也感觉您很早就走上了非常特定的道路。
您是如何最终从事所有这些有趣但相当具体的工作的？是大学毕业后追求的方向还是类似情况？您是如何走上这条路的？
Saumya Majumder： 这其实是个有趣的问题。我记得，在大二的时候，我开始做一些课外项目。所以我很早就开始接触PHP，那是在WordPress的早期。我进入了WordPress世界，开始编程、修改东西、向核心提交代码、摆弄WordPress。那是在WordPress生态系统的早期。
从那时起，我开始涉足PHP和其他东西。那是我刚开始的时候，后来我慢慢地开始发现问题以及如何解决它们。例如，今天很多公司提供的CDN页面级缓存，在2025年的今天，这在全世界已经非常普遍。如果你使用任何高级托管或任何高级套餐，你大概都会期望拥有基于CDN的页面缓存。
但要知道，即使在几年前情况也并非如此。那时的页面缓存要么在服务器级别，要么在RAM级别，所有这些都在服务器上完成。我和一位在线因WordPress编程而认识的朋友，实际上发明了CDN级别的页面缓存。在此之前这并不存在。我们创建了一个名为“Super Page Cache for Cloudflare”的插件，后来被一家名为Optimal的不同公司收购。
在那个插件中，我们研究了当时所有的解决方案。如果你拆解请求是如何发生的或互联网如何工作，例如，你从世界任何地方发出请求，该请求通过光纤电缆等传输到ISP数据中心，然后从那里到达数据中心，最终到达服务器。如果没有缓存，服务器必须处理整个过程，获取响应，返回给你；如果有缓存，则从缓存中获取。
我们认为，这增加了大量的延迟，尤其是当服务器与你之间的距离较远时。当时有MaxCDN、KeyCDN等CDN提供商，他们专注于从CDN提供静态文件。
这已经是一个既定事物，但我们认为，如果静态文件来自CDN，这很好，但主要的飞跃是如果我们能迁移页面。也就是说，直接从CDN本身提供页面HTML。如果你在澳大利亚，请求不必到达美国；如果被缓存，它实际上是从你附近的位置提供的。
缓存一直是我非常喜欢解决的问题之一，因为它是计算机工程世界中那些无法解决的问题之一。我就是这样开始接触它的，然后开始了这段旅程。我搞砸了很多事情，又修复了它们，这是一个充满失败和少许成功的旅程。
Nathan Wrigley： 是的，我可以想象。您是否曾经感觉到自己正在接近终点，或者这整件事只是，我做完这个，然后我知道一周后还会有其他东西可以优化？是否有某个时刻您曾对自己说，好的，目前就这样了，我们解决了？还是总是觉得，不，还有别的？
Saumya Majumder： 这始终是一个过程，对吧？技术在不断发展。有更多、更深的东西可以挖掘。我们最近发布的功能之一是“最终数据库保护缓存”，我稍后会谈到它，还有“登录用户缓存”。这两件事都在我的待办清单上多年了，我做了大量的研究和开发，以找出具体的方法。所以，这仍然是一个过程，需要时间。
Nathan Wrigley： 是的，这很棒。正如您所说，我们稍后会讨论这些内容。但正如我在节目开头所说，纯属巧合，我们遇到了这个，我们姑且称之为Cloudflare为整个互联网提供的服务的真正崩溃。我想，取决于您所在的位置和您醒着的时间，对于欧洲人和您所在的世界部分地区来说，它正好在我们都醒着的时候发生。我想如果您在北美，尤其是西海岸，您可能错过了大部分情况。
但在我们这里的大半天里，Cloudflare上的一切都停止工作了。有趣的是它的影响有多深远。我们都听说过这个问题。我们看过用乐高积木搭建的巨大塔楼的小图，底部有一块小积木支撑着整个东西，它叫Cloudflare，或者叫AWS等等。
您能向我们解释一下昨天到底发生了什么吗？您现在理解了吗？
Saumya Majumder： 是的。互联网是件神奇的事情。它靠魔法运作。如果我解释它如何工作，那将是另一回事。但它的工作原理是，尤其是在Cloudflare的情况下，很多人认为Cloudflare是一个CDN提供商，像MaxCDN或Akamai或任何这些提供商。但CDN只是Cloudflare的一部分。Cloudflare是一个构建在其之上的如此巨大的服务。
因此，当您有这样一个大型系统协同工作时，会发生许多关键的依赖关系。您拥有所有这些“盒子”，但所有这些“盒子”都依赖于来自其下一层的某个配置文件或某个东西，对吧？
如果那个东西出了问题，顶层的那些东西运行正常，但它无法工作，因为其下方的那个东西失效了。
我还想说，在互联网世界里，没有什么是永远不坏的。一切在某个时间点都可能出故障。没有例外。无论是Google、Azure、AWS、Cloudflare，还是任何其他东西。即使您拥有自己的数据中心等等，就像我们一样，也没有办法保证万无一失，即使您已经准备好缓解所有这些问题，例如您有故障转移、故障转移的故障转移以及所有这些备份系统，事情仍然可能出错。也许那个没启动，也许那个没发生。
昨天我在Twitter上看到很多梗图，很多人发帖说，嘿，我刚加入互联网Cloudflare。我推送了一段代码，然后就发生了。我理解这很有趣，但当您深入思考时，实际上并不好笑。这真的像是一个“红色代码”场景。相信我，没有公司愿意陷入那种“红色代码”场景。因为您必须明白，所有这些公司也在与许多企业客户打交道，他们向这些客户承诺了100%或99.99%的服务水平协议（SLA）。当他们无法达到时，他们必须支付巨额赔款。
所以，这不仅仅是停机时间、声誉受损和市场营销等问题，公司还会因此损失真金白银。而且，所有这些系统都是如此。
但同时，技术工作的方式决定了事情可能会出错。您可以进行多层次的代码审查，仍然会遗漏某些边缘情况，这些情况只会在特定条件下发生。发生这种情况的概率可能是0.00001%。但这0.00001%不是零。它可能发生。
在工程领域，我们将某些事情称为超级低优先级，就像它永远不会发生一样。我并不是说它不可能发生，它可以发生，但在我们有更多关键事情要做的当下，将工程时间花在那上面的概率如此之低，所以没有处理，对吧？
但有时事情就是会发生。作为一名资深工程师，这种情况时有发生。就Cloudflare而言，由于这是一个如此庞大的系统，即使他们确定了根本原因，比方说工程师需要一些时间来弄清楚，然后他们推送修复。您必须明白，很多人正在发送请求，请求正在下降，他们找到了根本原因，推送了修复，然后海量的请求涌向Cloudflare。
所以一切稳定下来需要时间。这很糟糕，确实很糟糕。但任何认为Cloudflare不好，如果我从Cloudflare迁移到X、Y或Z或其他什么就不会发生这种情况的人，我还没有见过。我昨天看到一条推文，有人说，发送冷邮件给别人说，Cloudflare宕机了。但我们不使用Cloudflare，我们使用自己的VPS和专用服务器。我当时大笑起来。我想，我理解您的数据中心没有宕机，但这并不意味着它永远不会宕机。
Nathan Wrigley： 这几乎是必然的。我认为其中一个有趣的事情是，在Cloudflare创建的总结性文章中，有一整段关于这个意外文件的内容，它的体积翻倍了。它本应该是某个大小，但却翻倍了，然后被传播。然后在一段时间内，其连锁反应使它看起来像是DDoS攻击。有一段时间它看起来可能是恶意行为者所为。
因此，Cloudflare的工程师们，我想，结果证明，是朝着错误的方向去解决问题。他们朝着错误的方向寻找问题，这可能增加了数小时的缓解时间，然后才弄清楚发生了什么。然后，就像您说的，整个连锁反应是，这不像关掉电脑再打开，Cloudflare就恢复了。这是一个传播过程，您发现问题，修复问题，问题得到缓解，这大概需要数小时。然后您可以看到停机报告在整个互联网上缓慢修复。
Saumya Majumder： 而且您必须明白，正如我所说，人们认为Cloudflare是一家安全公司或CDN公司。但Cloudflare远不止于此。他们拥有的CDN骨干网络实际上是他们的支柱，是Cloudflare构建自己东西的强大基础。
因此，每当他们找到他们称之为“控制平面”的修复方法时，他们必须将修复推送到他们的控制平面，然后该修复必须传播到他们所有的边缘节点。Cloudflare拥有最多的CDN接入点（PoP）。所以修复必须推送到所有这些地方，重新启动，所有这些疯狂的事情必须发生，一切才能正常运行。然后还要处理涌入的大量流量。这非常疯狂。
但我喜欢Cloudflare的一点是，这不是Cloudflare第一次发生全球性中断。他们以前也发生过全球性中断。我真的很喜欢Cloudflare的两点。
第一是他们超级透明。每当出现问题时，他们总是会发布详细的博客文章，解释到底发生了什么，他们做了什么来修复，以及他们如何确保未来不再发生。并且未来确实不再发生。
所以，如果您看看他们之前发生的全球性中断，我想是在6月份，那次是因为一个叫做Cloudflare KV的东西对GCP有依赖。所以当GCP宕机时，KV就宕机了，结果系统就宕机了。从那时起，他们现在正在努力消除这种依赖，在内部构建东西以确保这种情况不会发生。
之前还有一次，我想是去年或前年，另一次全球性中断，当时整个主要数据中心宕机了。有多个故障转移，但发电机没有启动，这个没启动，那个没启动。导致了巨大的故障转移场景，如果您还记得的话，对吧？
从那时起，他们确保，好的，我们现在必须确保我们有多个……那种情况永远不会再发生。所以他们总是致力于确保已经发生的事情不会再发生第二次。他们也确实做到了。但归根结底，在技术世界里，事情可能会出错。这就是现实。
Nathan Wrigley： 但从最终用户的角度来看，这有点令人好奇，您稍后会向我们解释BigScoots内部工作的复杂性以及它如何与Cloudflare结合，这将非常有趣。但对于非技术用户来说，感觉就像天要塌下来了，因为互联网的很大一部分崩溃了，很多他们熟悉的东西都不可用。
举几个很多人都熟悉的例子。例如，如果您是社交网络X的用户，它完全失效了。它肯定在某个环节依赖Cloudflare。还有ChatGPT，它现在几乎成为每个人每天都会用到的东西，它也宕机了。
然后它还波及到许多其他事情。新闻机构宕机了。登录各种服务的能力也丧失了。所以可能您的平台本身是工作的，但您可能启用了Cloudflare运行的Turnstile验证系统，由于Cloudflare的这部分——Turnstile不工作，所以没人能登录到您拥有的专有平台等等。
所以它产生了巨大的影响。这带来的令人不安的效果是，人们然后错误地以某种方式将Cloudflare视为一个需要被约束的巨人。例如，我们绝不能再让这种情况发生，我们对这些少数大型组织的依赖太多等等。
但到了今天，所有人都忘记了这些，他们继续自己的生活，回到了周一的样子。所以这里面没有问题，但我想分享一些见解。
Saumya Majumder： 哦，是的，当然。这里有几个非常重要的事情需要理解，对吧？首先，正如您所说，在社交媒体上谈论这类事情的人，相信我，他们要么不是工程师或资深工程师，要么不理解问题所在。
所以这些人每次发生同样的事情时都会谈论这个——几周前AWS宕机了，几个月前GCP宕机了。然后他们会说，Facebook宕机了，他们每次有东西宕机时都用完全相同的词。但东西就是会宕机。您必须接受这一点并继续前进。
这就是为什么当您与这些大公司签订企业协议时，他们有这份SLA协议，就像我早些时候告诉您的那样，对吧？所有这些公司，GCP、AWS、Cloudflare，如果您是他们的企业客户，您会与他们签订SLA协议。协议中说，好的，我们保证为您提供100%的可用时间，或99.999999%的可用时间。每当他们未能达到这个标准时，他们必须向客户支付一大笔钱作为赔款，表示，好的，我们未能履行合同，所以这是赔给您的。
所以您必须明白，每当这种情况发生时，对公司来说不仅是市场营销方面的坏事，也是财务方面的坏事。因为您必须明白，所有这些大公司都有这些较小的客户，也有像与公司打交道的大型企业客户，那些公司真正担心的大型客户。对于这些大型客户，他们必须支付巨额赔款，因为系统没有在规定时间内恢复。所以他们并非不担心立即修复。他们确实在尽最大努力修复。
话虽如此，现在谈谈您提出的其他几点，Turnstile、WAF和其他东西，对吧？
正如我所说，Cloudflare不仅仅是一家安全公司。它是一个巨大的集合体。Cloudflare有一个叫做“开发者平台”的东西，您实际上可以在那里部署自己的API、AI工作负载、工作流、整个React或整个应用程序，这非常棒。我使用它，我喜欢那个平台。
这是使用Cloudflare的一个方面，还有另一个方面使用Cloudflare，例如使用BigScoots。假设您有一个托管在BigScoots的WordPress网站，但它通过Cloudflare代理，以利用他们的CDN、安全性和所有功能。
因此，在像WordPress网站这样的场景中，您没有将Cloudflare用作您的主机，Cloudflare只是作为一个代理存在，确保您的原始IP不暴露，您的站点受到超级保护，并且拥有性能和CDN等功能。在这种情况下，每当发生此类问题时，您可以在某种程度上，当这次中断发生时，API仍然有效，我们实际上为所有客户利用我们的API，确保任何请求不通过Cloudflare代理，而是直接转到我们的服务器，直到Cloudflare恢复。
Nathan Wrigley： 哦，所以您可以通过API关闭代理。
Saumya Majumder： 通过API，是的。
Nathan Wrigley： 好的。所以其他人因为Turnstile宕机而无法登录，无法通过网络验证进入Cloudflare网络。但API仍然可用，所以您可以为您的一系列客户以及他们的域名和网站关闭代理。
哦，这真的很有趣。所以他们只有几分钟的停机时间。好吧，这很吸引人。
Saumya Majumder： 所以当我们看到这次中断发生时，我们做了什么？每当有请求进来时，对我们来说也是一个“红色代码”场景。所有人手都投入进来。所以每当有请求进来，比如人们遇到问题时，我们立即开启代理API，确保这个站点启动并在线。
这样，请求就不再通过Cloudflare，而是直接来到我们这里，直到Cloudflare恢复正常。这帮助我们尽可能地为客户减少停机时间，即使Cloudflare在技术上宕机了。
但如果您将您的Nuxt、React或Next.js之类的应用程序托管在Cloudflare上，您使用Cloudflare Workers之类的东西作为您的主机，那么在那个场景中，您无法推送任何东西。
Nathan Wrigley： 是的，API帮不了您。
Saumya Majumder： 是的，是的。这很糟糕，但它会发生。它可能发生。
Nathan Wrigley： 是的，我想这就是关键信息，对吧？人类创造的任何东西都不是坚不可摧的。一切都有崩溃的时刻。但是，如果您回想一下周一，当时一切顺利，Cloudflare正常运行，那么每个人都非常满意。然后我们经历了这段时间，也许是8个小时，每个人都在挥舞双臂，抱怨那些仍在工作的社交网络。
但现在是周三，那件事早已过去。那艘船已经航行，不管怎样，继续前进。信心，我想基本上您说的是，您可以对Cloudflare有信心。他们会遇到问题，因为他们像任何其他公司一样，事情会出错。
Saumya Majumder： 任何东西都可能遇到问题。所以这不只是……您必须明白这一点，对吧？再次，我并不是说Cloudflare不好。我认为Cloudflare很棒，因为两点，他们超级透明，所以每当发生任何事情时，您所引用的博客文章，他们没有隐瞒任何事情，比如，哦，这不是我的问题，没有推卸责任。不，不，不。这是我们的问题。就是这个。
例如，在那篇博客文章中，他们完全可以不提DDoS的事情，对吧？他们本可以说，哦，这是配置文件问题。我们修复了，完成了。但不，他们实际上详细介绍了他们处理问题的具体过程，这真的很棒。然后他们确实从错误中吸取教训，确保特定的错误永远不会再发生，同时他们正在快速发展，疯狂地构建东西，推出新东西，这对我来说非常惊人。
Nathan Wrigley： 我想那篇文章甚至是以类似于“我们辜负了您”这样的话开头的，如果不是第一句话，也肯定在前几句里。完全是主动承担责任。所以为他们喝彩。
您是对的，其背后的复杂性，就像您之前说的，互联网，互联网上任何东西能工作，完全是工程奇迹，计算机工程奇迹。
您知道，我们在一个平台上互相看着对方。我能看到您的图像，您能看到我的图像，您能听到我的音频，我能听到您的音频。您在地球的另一边，但它就像您站在我旁边一样发生着。在这次对话过程中流动的数百万个信息包，这太疯狂了。Cloudflare在上面又增加了整整一层其他东西，这使它更加疯狂。
Saumya Majumder： 是的。您必须问这个问题，如果它这么糟糕，为什么所有这些大公司都在使用Cloudflare。因为他们正在做一些其他人甚至没有想过要以这种规模去做的事情。这令人难以置信地疯狂。太疯狂了。
Nathan Wrigley： 是的，是的，确实如此。所以这个话题我们改天再聊。但显然在BigScoots，您真的把您的“马车”挂在了Cloudflare上，可以这么说。当您同意来播客和我交谈时，我明显感觉到您的级别和我能跟上的级别非常不同。
所以我们将讨论您在BigScoots所做的工作。我会尽力跟上，但如果我误解了什么，或者不得不要求您重复什么，希望您不介意。但我很好奇，因为正如我在本期节目开头所说，Tammie Lister是我非常尊重其意见的人，她说您在BigScoots与Cloudflare的连接方面做了一些真正创新、有趣的事情。所以请介绍一下您一直在做的一些有趣的工程工作。我会尽力跟上。
Saumya Majumder： 首先，Tammie很棒，Tammie非常出色。但是的，我想BigScoots一直是托管领域最早利用Cloudflare Enterprise的公司之一。我知道我们没有像其他主机那样进行大规模的营销，但我们是第一个在我们的托管生态系统中利用Cloudflare Enterprise的。而且那是在非常早期，那时候所有这些市场都还不存在。所以我们在构建人们甚至没有测试过的东西。
正如我一开始所说，我和我的一位同事发明了CDN级别的页面缓存。这远在APU等等出现之前。实际上所有这些架构系统都建立在我们构建的基础上，包括APU和Workers等。
所以在BigScoots，Cloudflare，尤其是Cloudflare Enterprise，为我们打开了一扇全新的大门，因为它现在允许我们为每个用户提供CDN级别的页面缓存，并拥有超高的缓存命中率。我的意思是，每次您访问一个页面，从缓存中获取的几率要高得多，相比如果您使用免费计划或任何其他计划，对吧？
这就是开始。在此基础上，我们构建了自己的专有插件BigScoots Cache，它不仅允许您利用和发挥Cloudflare页面缓存的优势，还让您能够微调网页缓存的每个方面。
Nathan Wrigley： 我要在这里暂停您一下。首先，我确信几乎所有听众，因为是WordPress相关的，都会理解缓存是什么。他们会理解这个类似“记住某些东西以便下次需要时它已经准备好了”的过程。但他们可能不理解Cloudflare在其企业计划中是如何做到这一点的。
那么，有什么不同？因为我们可能熟悉，比如说，一个WordPress插件，我们知道服务器某个地方有缓存。它是一个文件，一个HTML文件之类的。您描述的是一些东西不在一个位置，而是真正全局分布，以便在离用户最近的地方随时可用。所以请多告诉我们一些。
Saumya Majumder： 让我用一个比喻来解释，好吗？在CDN级别页面缓存出现之前，我想几乎每个人都会记得，我们曾经有缓存插件。我不指名道姓，但确实有缓存插件。当您打开它们时，它们本质上做的是创建一个advanced-cache.php文件。您将这个文件放在您的WordPress安装目录中。
它的作用是，当您发送请求时，假设您在澳大利亚，服务器在美国，您想打开example.com，该请求通过海底传输到数据中心，再到服务器，服务器接收请求，开始处理，运行所有数据库查询等等，然后获取要显示给您的HTML。
在那时，advanced-cache.php会启动，它会创建HTML的副本，将其存储在服务器本地，这样下次如果有人请求该页面，就不必请求服务器说，嘿，请处理PHP和数据库等等，因为它需要的服务器资源要少得多，因为WordPress已经预热了。请求到达advanced-cache.php，然后它说，哦，我有那个缓存文件，将缓存响应发送回给您。
但即使在这种情况下，如果您从澳大利亚发出此请求而您的服务器在美国，您必须明白延迟非常高，因为请求必须从澳大利亚到美国，然后无论从那里得到什么响应，再从美国回到澳大利亚。所以传输时间相当长。
从那时起，我们考虑MaxCDN、KeyCDN等等，将静态文件放在CDN上，这样，是的，页面由服务器生成，但静态文件几乎就在您所在的位置提供。例如，如果您在澳大利亚悉尼，那么当您请求静态文件时，它可能来自悉尼的CDN接入点（PoP）。
这就是我们想到的，如果我们能把这个页面HTML放在CDN上，而不是放在服务器上呢？这有两个好处。第一，它快得惊人。因为如果这个页面HTML分布在世界各地，那么如果您在悉尼发出请求，请求是，哦，好的，我有这个页面缓存，给您，响应，您在不到100毫秒内得到，对吧？
对于坐在印度、德国和世界其他地方的某人来说，同样的事情也会发生，因为它被缓存到了全球各地。所以它不仅仅是来自一个地方。任何时候它没有被缓存，请求就会转到服务器，HTML被处理，当响应发出时，它就被缓存了。它被缓存到了全球各地。
现在，这是页面缓存的部分，对吧？还有其他东西，对象缓存和OPcache，那完全是另一个层次。但我不打算深入那个。我只谈这些，因为再深入就会变得太冗长。
这就是对象缓存和Cloudflare Enterprise发挥作用的地方，对吧？Cloudflare Enterprise使我们能够确保我们可以将这些页面缓存到全球，并拥有非常高的缓存命中率。缓存命中率意味着，当某些东西在某个地方被缓存，假设有人请求该文件并且该缓存已过期或不存在，那么请求必须再次到达源站，被处理，然后返回给您。
这在Cloudflare较低级别的计划中通常是这种情况。使用Cloudflare Enterprise，您可以获得非常高的缓存命中率。所以当它获得缓存时，缓存会保留很长时间。此外，我们还获得了分层缓存和区域分层缓存等强大的功能。
这意味着，我们拥有分层系统。所以当您发出请求时，请求首先被缓存在上层。当下层……让我怎么向您解释呢？假设您在凤凰城，好吗？凤凰城有一个数据中心，或者CDN术语中的接入点（PoP），但上层PoP在芝加哥。
假设有人从芝加哥发出请求，页面被缓存在芝加哥数据中心。现在，由于我们拥有这种分层缓存系统，当您从凤凰城发出请求时，该PoP不会直接将请求发送到源站，而是首先在Cloudflare的内联网（不是互联网）内部，询问上层是否有人缓存了这个页面？如果他们说有，他们会从上层获取，这非常快，因为这是Cloudflare的内部网络，没有外部流量。
如果没有，那么它将请求传递到上层，因为上层是唯一有权从源站拉取请求的层级。它到达上层，上层从源站拉取数据，创建副本，存放在上层，然后发送回下层。通过这种方式，在这种分层架构中，它确保缓存命中率高得惊人。
Nathan Wrigley： 让我复述一遍以确保我理解了。我想象的最简单的方式是一组同心圆。中心是我，我希望在，比方说，外层圆圈上找到某些东西。所以我首先要做的是去我的内圈，如果内圈没有，我们需要去下一个圈，再下一个圈，再下一个圈。
在旧世界里，或者非企业版的Cloudflare，我们必须在某个时刻去更远的圈才能找到我们要找的东西。但我想您说的是，在企业级别，那个外层圆圈正在不断将东西推向更本地的内圈。所以不必去一个圈，另一个圈，另一个圈，它可以只跳出一个圈，获取所需，然后立即跳回。换句话说，每样东西总是比任何其他设置中更近，地理上。
Saumya Majumder： 是的，除此之外，如果您看这种架构的对立面，对吧？想象您在凤凰城，凤凰城没有缓存。凤凰城发送一个请求到源站，现在有人从密西西比州发出请求，他们没有缓存，他们的PoP也发出请求……所有这些PoP都在向源站发出请求，因为它们自己没有本地缓存，这很糟糕，因为这将意味着对源站的请求会急剧增加，而这正是我们试图减少的。
但在这种情况下，我们有，想象一组固定的上层数据中心，然后我们有中层，然后是下层，对吧？所以如果下层没有，它会询问中层，中层检查世界各地的任何中层是否拥有它。如果有，立即发送。这发生在Cloudflare的内部网络中，而不是开放的互联网上，明白吗？快得惊人。
Nathan Wrigley： 对，好的。所以再次原谅我，我要凭直觉猜测一下，我可能理解错了。我猜在Cloudflare方面，他们有自己的专用硬件来路由所有这些东西。所以就像您说的，您描述为一种内部网，几乎是他们规模的内部网。但他们有自己的硬件，可能能够更快速地路由这些信息，并且延迟更少，比我或您可能拥有的要少。
Saumya Majumder： 是的，这是内部网，不是互联网。这是一个私有通道，对吧？除了Cloudflare，没有其他人在那里通信。最棒的部分是，假设您从密西西比州发出请求，而在印度孟买有一个上层数据中心，对吧？那么会发生什么？即使它在美国没有被缓存，它也会看到，好的，我在孟买有缓存，让我们从那里获取，而不是调用源站，减少了对源站的调用。
Nathan Wrigley： 好的，这部分我不明白。整个网络都知道最近的东西在哪里，甚至在需要之前就知道。我明白了。好的。这很吸引人。那他们拥有连接这些东西的电缆吗？Cloudflare拥有连接这些的电缆吗？
Saumya Majumder： 是的。是的，他们有自己的数据中心，自己的骨干网，所有这一切。除此之外，像在BigScoots，我们甚至与Cloudflare服务有直接的物理连接。这叫做CNI。那是下一步。所以让我再描述一下。这是作为用户的您，对吧？这是位于中间的Cloudflare，充当反向代理，这是源站。
它的工作方式是您发出请求，对吧？假设您，请求被这个反向代理Cloudflare接收。然后它处理那个东西，无论是必须向您显示WAF页面，还是其他逻辑，对吧？它有缓存吗？它被阻止或受到质询吗？我需要显示缓存吗？我有缓存吗？它在与内部网络通信，所有这些。这都发生在中间层，对吧？
这个中间层现在连接到他们整个Cloudflare链，对吧？所以如果，假设孟买有，它从孟买拉取，返回给您。所以请求从未到达源站，对吧？
现在，无论出于什么原因，您向Cloudflare发出请求，Cloudflare检查其内部网络，它自己没有，所以它必须向源站发出请求，对吧？
有趣的部分就在这里。您和Cloudflare之间的这段连接是通过开放的互联网发生的，对吧？因为您发出请求，请求通过开放的互联网到达Cloudflare，对吧？然后这是您的源站，所以从Cloudflare到源站，通常也是通过开放的互联网发生。Cloudflare然后发出请求，该请求通过互联网到达数据中心。
但这是我们完成的魔法部分。由于我们运营并拥有自己的数据中心，我们所做的是，我们实际上用一根物理电缆连接，一根具有超高带宽的光纤电缆，连接Cloudflare服务器和我们的服务器。所以发生的情况是，每当Cloudflare需要从我们的源站获取某些东西时，它不是通过开放的互联网发送该请求（这可能很慢，可能有拥堵等等），而是通过我们创建的私有网络、那根私有光纤电缆发送，直接到达我们的源站。比如，哦，这个托管在BigScoots上。我们需要与BigScoots通信。好的，通过这个通道发送，这不属于开放的互联网。然后砰的一声，它到达那里，返回，速度快得惊人。
Nathan Wrigley： 好的。这是怎么发生的？比如，这是您与Cloudflare直接达成的某种协议，所以您可以说，几乎是接入了他们的网络基础设施，成为一个第三方部分。
Saumya Majumder： 想象一下，Cloudflare就像一个庞大的网络，我们的系统也接入到他们的网络中，这样他们就可以使用内部网系统直接从我们这里获取数据，而不是使用开放的互联网，后者要慢得多，可能会有拥堵等等。使得代理和源站之间的请求变得瞬间快速。
Nathan Wrigley： 那么这整个事情是怎么发生的？您是如何达成这个协议的？因为我不知道许多其他组织是否这样做，在Web托管领域之外，也许这是典型的事情，您可以遵循另一家已经这样做的公司的路线图。我还没听说过这个，所以这有点意思。这种关系是如何建立起来的？
Saumya Majumder： 如果您不运营自己的数据中心，很难做到这一点。
Nathan Wrigley： 是的，我没有。
Saumya Majumder： 是的，因为您必须将您的服务器、路由器等实际连接到Cloudflare网络，明白吗？所以大多数托管公司实际上并不运营自己的数据中心在自己的地方。他们实际上从其他云提供商那里租赁硬件和服务。而我们运营我们自己的私有云，我们自己的系统，我们自己的数据中心。
所以例如，有些公司可能使用AWS或GCP或Azure，然后创建他们自己的风格，并通过它运行Cloudflare。所以他们实际上没有对这些数据中心的其他服务器的物理访问权限。而我们有。如果我们看到什么，我们实际上可以拔插驱动器，我们可以在数据中心做事，我们可以更换东西，我们可以物理连接那些东西，这在我所知的托管提供商中几乎没有。
Nathan Wrigley： 这太有趣了。说实话，我们可以就此谈上好几个小时。但基本上，归根结底是，您正在让电子以可能的最快速度运行。在一个分布式网络中，有些东西不知道其他东西，而另一些东西知道。这是一项旨在弄清楚如何让一切都知道一切的事业，让电子通过遍布世界的光纤电缆尽可能快地飞行。
Saumya Majumder： 我甚至还没描述服务器呢。
Nathan Wrigley： 我还远没有说完，因为我想了解使用WordPress的人是什么情况，我们是WordPress播客，所以我想在某个时候我们需要深入讨论一下。那么，所有这些您创建的聪明技术以及您在BigScoots与Cloudflare结合的技术，会给仅仅拥有一个WordPress网站的普通人带来什么好处？
Saumya Majumder： 它带来极快的速度。极快的速度，超级改善的核心网络指标，以及强大的DDoS防护等等。它带来了所有这些。我不想谈论这些听众可能不感兴趣的事情。我想谈谈用户可以使用的其他更有趣的事情。
我在谈论BigScoots Cache，这是我们自己的知识产权，对吧？我们创建了BigScoots Cache插件，以管理整个Cloudflare缓存系统。不仅如此，如果您是高级用户，它实际上让您能够微调和管理您想要的缓存系统的每个方面。
例如，我们默认将CDN缓存TTL设置为X，但您有一些页面希望TTL更短。有钩子可以实现。您可以使用那个。
或者也许，假设我们有智能缓存清除系统。每当您发布或更新文章时，当您按下“发布”或“更新”按钮时，在幕后，BigScoots Cache插件不仅会清除该特定页面的缓存，还会智能地清除所有其他相关页面的缓存，例如分类页面、存档页面以及链接到该文章的作者页面。
您也可以使用其他钩子。假设您有一些伪存档页面，我们见过很多这种情况。假设您使用一个主题，您在一个页面上显示文章列表，从技术上讲，这是一个您使用短代码的页面，而不是真正的存档页面。所以系统不会将其识别为存档页面，但您希望每当发布某个标签或分类的文章时，清除该页面的缓存。有钩子可以实现。您不必自己动手。如果您来找我们告诉我们，这是我们的问题，我们可以为您编写代码并处理。我们可以为您设置。我们提供完全托管的系统。
Nathan Wrigley： 所以我猜，要达到那种程度，您必须对缓存基础设施有相当深入的了解，还是您提供的功能，不一定非要部署，但任何人都能通过阅读您的文档理解，还是说这是相当专业的、极客级的东西？
Saumya Majumder： 我们为每个存在的钩子都有适当的文档。在最开始我们会说明，这适用于高级用户。如果您不知道什么是钩子等等，您可能很难理解发生了什么。但如果您熟悉操作和过滤器等等，对您来说就相当直接了。
所以这就是为什么我说，如果您不知道，但您有问题，这种情况经常发生，人们来找我们，我们实际上就是写一个代码片段并为他们实现。
所以您不必知道所有那些复杂的东西，明白吗？如果您是高级用户，文档在那里；如果您不是，它也在那里。此外，BigScoots Cache有自己的REST API，您可以使用它来清除缓存，比如您可以实际使用BigScoots Cache REST API来清除缓存。想象您构建了一个Laravel系统或某个后端系统，您正在向您的电子商务网站添加东西，并且您希望清除缓存。当发生这种情况时，您实际上可以利用BigScoots Cache REST API来实现。所以，这是关于BigScoots Cache的功能。然后是我们的BigScoots门户网站。
Nathan Wrigley： 啊，这实际上是我接下来想问的。请继续。
Saumya Majumder： 好的。我认为我们拥有业内无人能及的、最先进和最精细的Cloudflare Enterprise控制。我不知道您是否看过我们的企业设置页面。我们确实允许用户按照他们想要的方式精确地微调设置。例如，假设您想保护您的登录页面免受不良机器人和攻击者的攻击，这样他们无法进行DDoS攻击？有开关可以实现。打开它，就完成了。
您想启用我们