CloudFront中的TTL 0有什么用？ [英] What is a TTL 0 in CloudFront useful for?
问题描述
几周前，亚马逊宣布降低了内容的有效期：
Some weeks ago Amazon announced that they have lowered the content expiration period:
太多了，您现在实际上可以将CloudFront中的TTL设置为0。所以我的问题是，为什么将TTL设置为0的CloudFront分配很有用。对我而言，这意味着根本不进行缓存，因此每个请求都到达
So much that you can actually set now TTL in CloudFront to 0. So my question is, why could it be useful to have a CloudFront distribution with TTL set to 0. To me this means no caching at all so every request that gets to CloudFront will end up hitting the origin.
我缺少什么？
推荐答案
Amazon CloudFront 的新功能实际上在许多用例中非常有用，因为相反，击中原点的工作方式与乍一看有点不同，并且不一定是问题。虽然此功能已经在较早的版本中发布，但所有这些都与 Amazon CloudFront-支持动态内容，例如针对当前问题：
This new feature of Amazon CloudFront is actually extremely useful for many use cases, because hitting the origin works a bit different than it looks at first sight and is not necessarily a problem, to the contrary; while this feature has been released earlier already, it all comes together with the recent release of Amazon CloudFront - Support for Dynamic Content, e.g. for the question at hand:
可变生存时间（TTL）-在许多情况下，动态内容是
不可缓存的，或者是在很短的时间内不可缓存的，也许
只是几秒钟。过去，CloudFront的最小TTL为60
分钟，因为所有内容均被视为静态内容。新的最小TTL
值为0秒。 如果您将特定来源的TTL设置为0，则
CloudFront仍会缓存该来源的内容。 然后
会发出带有If-Modified-Since标头的GET请求，从而使
的原点有机会信号通知CloudFront可以继续使用
缓存的内容在原始位置未更改。 [强调矿井]
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将缓存控制到源的权限，即源服务器决定是否以及CloudFront将对象缓存多长时间；请特别注意，带有If-Modified-Since标头的 GET请求不一定意味着对象本身是从原点检索的，而是原点可以（并且应该）返回 HTTP状态代码304-未修改（如果适用）：
In other words, using a TTL of 0 primarily means, that CloudFront delegates the authority for cache control to the origin, i.e. the origin server decides whether or not, and if for how long CloudFront caches the objects; please note specifically, that a GET request with an If-Modified-Since header doesn't necessarily mean that the object itself is retrieved from the origin, rather the origin can (and should) return the HTTP status code 304 - Not Modified where applicable:
表示自上次请求以来未修改资源。 [...]
使用此功能可节省带宽和在服务器和
客户端上进行重新处理，因为仅标头数据必须发送和接收
服务器将重新处理整个页面，然后使用服务器和客户端的更多带宽再次发送该页面。 [强调我的]
请参阅Mark Nottingham出色的缓存教程，详细了解HTTP缓存控制的机制和好处，HTTP缓存控制是HTTP体系结构中非常重要和有效的一部分。
See Mark Nottingham's excellent Caching Tutorial for details on the mechanics and benefits of HTTP cache control, a really important and effective part of the HTTP architecture.
要理解所有这些部分如何协同工作确实有些困难，因此，指定
Understanding how all these parts work together can be a bit difficult indeed, accordingly the table in section Specifying the Minimum Time that CloudFront Caches Objects for Download Distributions within Specifying How Long Objects Stay in a CloudFront Edge Cache (Object Expiration) attempts to summarize the effects when applied in the context of CloudFront with or without TTL = 0 specifically.
这篇关于CloudFront中的TTL 0有什么用？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
