amazon-web-services - CloudFront 中的 TTL 0 有什么用？

Question

几周前，亚马逊宣布他们降低了内容有效期:

Amazon CloudFront Lowers Minimum Content Expiration Period

现在您实际上可以将 CloudFront 中的 TTL 设置为 0。所以我的问题是，为什么将 TTL 设置为 0 的 CloudFront 发行版会有用。对我来说，这意味着根本没有缓存，因此每个请求到达 CloudFront 最终将到达原点。

我错过了什么？

Answer 1

Amazon CloudFront 的这个新功能实际上对于许多用例都非常有用，因为击中原点的工作方式与乍一看有点不同，而且不一定是问题，相反；虽然此功能已经较早发布，但它全部与最近发布的 Amazon CloudFront - Support for Dynamic Content 一起提供，例如对于手头的问题:

Variable Time-To-Live (TTL) - In many cases, dynamic content is either not cacheable or cacheable for a very short period of time, perhaps just a few seconds. In the past, CloudFront's minimum TTL was 60 minutes since all content was considered static. The new minimum TTL value is 0 seconds. If you set the TTL for a particular origin to 0, CloudFront will still cache the content from that origin. It will then make a GET request with an If-Modified-Since header, thereby giving the origin a chance to signal that CloudFront can continue to use the cached content if it hasn't changed at the origin. [emphasis mine]

换句话来说，使用 TTL 为 0 主要意味着 CloudFront 将缓存控制权委托(delegate)给源站，即源服务器决定 CloudFront 是否缓存对象以及缓存多长时间；请特别注意，带有 If-Modified-Since header 的 GET 请求并不一定意味着对象本身是从源检索的，而是源可以(并且应该)返回 HTTP status code 304 - Not Modified，其中适用:

Indicates the resource has not been modified since last requested. [...] Using this saves bandwidth and reprocessing on both the server and client, as only the header data must be sent and received in comparison to the entirety of the page being re-processed by the server, then sent again using more bandwidth of the server and client. [emphasis mine]

请参阅 Mark Nottingham 的优秀文章 Caching Tutorial，了解有关 HTTP 缓存控制的机制和优点的详细信息，HTTP 缓存控制是 HTTP 架构中非常重要且有效的部分。

理解所有这些部分如何协同工作确实有点困难，因此在 Specifying How Long Objects Stay in a CloudFront Edge Cache (Object Expiration) 内指定 CloudFront 缓存对象以进行下载分发的最短时间部分中的表尝试总结应用时的效果特别是具有或不具有 TTL = 0 的 CloudFront 上下文。