我们很高兴地宣布，我们现在支持所有HTTP缓存控制响应指令。这就把强大的控制权交给了你们，全世界运行源服务器的人。我们相信我们对互联网上任何大规模缓存的互联网标准缓存控制指令的支持是最强的。这里有关于缓存控制的文档。Cloudflare在我们全球分布的网络边缘运行一个内容分发网络（CDN）。我们的CDN工作原理是在全球119个数据中心缓存客户的web内容，并将这些内容提供给离我们每个网络位置最近的访问者。反过来，我们客户的网站和应用程序要快得多对最终用户更安全。CDN的基本工作原理很简单：将内容存储在需要的位置附近意味着它将更快地到达最终目的地。而且，从更多地方提供服务意味着它更可靠。用一个简单的香蕉比喻：假设你想要一个香蕉。你去你当地的水果摊买一堆来喂你内心的猴子。你希望商店里有香蕉，这样可以立即满足你的要求。但是，如果缺货怎么办？或者如果所有的香蕉都是陈腐的呢？然后，商店可能需要向香蕉仓库下订单。订单可能需要一段时间才能完成，你会花时间在店里等着香蕉送到。但你不会那么想要香蕉，你可能会走出去，想其他办法来解决你的热带问题。现在，如果我们在互联网请求的上下文中考虑相同的场景会怎么样？你对最新的香蕉迷因感兴趣，而不是香蕉。你去吧bananameme.com网站，它位于Cloudflare边缘网络的后面，您可以更快地获得meme服务！当然，有一个陷阱。服务器（内容的"来源"）和访问者（网络工程师俚语中的"眼球"）之间的CDN可能会缓存过期或不正确的内容。有两种方法可以进行管理：1） 源代码应该在何时将内容视为过时时给出最好的指示。2） 源服务器可以告诉边缘它何时对内容进行了更改，从而使内容过时。缓存控制头允许服务器和管理员向边缘提供有关如何处理内容的明确指示。储存短暂成分的挑战（或：没有陈香蕉）当在源服务器和访问者之间使用诸如Cloudflare之类的边缘缓存时，源服务器不再直接控制正在服务的缓存资产。互联网标准允许源代码对其服务的每个响应发出缓存控制头。这些头文件为中间缓存和浏览器缓存提供了关于如何缓存内容的细粒度指令。目前覆盖这些指令的RFC（以及一般的HTTP缓存）是rfc7234。如果你喜欢这种东西，那就值得浏览一下。关于响应缓存控制的相关章节在该文件的第5.2.2节中给出。此外，rfc5861中还定义了一些对核心指令的有趣扩展，包括当源无法访问或正在对其进行重新验证的过程中，缓存应该如何运行。用香蕉来说：乔治·迈克尔在一个小摊上卖香蕉。周一，他从安东尼的香蕉公司（ABC）收到一批要转售的香蕉。安东尼的香蕉公司是遍布全国的商店的香蕉产地。ABC对保护自己的品牌非常感兴趣；他们希望人们只把香蕉与最新鲜、完全成熟的香蕉联系在一起，而不会有变质或变质的水果。为了保证新鲜度，ABC向其香蕉的供应商和食客提供了明确的指示。香蕉在出售前不能超过3天，以防止过熟/陈化。过去三天，如果一个顾客想买香蕉，乔治·迈克尔必须打电话给ABC公司重新确认香蕉是新鲜的。如果找不到ABC，香蕉就不能卖了。用香蕉迷因SVG来解释：Kari使用Cloudflare在世界各地的边缘位置缓存香蕉meme svg，以减少访客延迟。香蕉模因最多只能缓存3天，以防止模因老化。过去3天，如果访客要求bananameme.com网站，Cloudflare必须向bananameme.com网站起源。如果对origin的请求失败，Cloudflare必须为访问者提供一个错误页面，而不是他们热情的meme。如果ABC和Kari对缓存控制响应头有强大的支持就好了！如果他们这样做了，他们可以用下面的标题为香蕉相关资产提供服务：缓存控制：public，max age=259200，proxy revalidatePublic表示允许从边缘缓存提供此香蕉。Max age=259200意味着它最多可以在缓存中保留3天（3天*24小时*60分钟*60秒=259200）。Proxy revalidate意味着边缘缓存必须在过期时间结束时使用源重新验证内容，没有例外。要获得支持的指令的完整列表和更多的示例（但没有更多的香蕉），请查看我们帮助中心的文档。