Cloudfront Minimum TTL有什么用？ [英] What is Cloudfront Minimum TTL for?

问题描述

我试图了解最小TTL ，最大TTL 和默认TTL 和此文档。

据我了解，当 HTTP缓存使用最大TTL 标头出现在响应中，以限制最大缓存时间，并且当没有 HTTP缓存标头默认TTL c $ c>用作默认缓存时间。

As my understanding, Maximum TTL is used when HTTP cache header appears in respons to limit maximum cache time and Default TTL is used when there is no HTTP cache header to use as default cache time.

但是，对于最大TTL ，没有具体提及

However, for Maximum TTL, there is no specific mention.

此外，它还提到了与转发头的关系。这是否意味着如果我将任何HTTP标头设置为转发到源并且最小TTL 不为0，则不会缓存任何内容？

In addition, It mentions the relation with forwarding head. Does it mean that if I set any HTTP header to forward to an origin and Minimum TTL is not 0, it doesn't cache anything?

最小TTL
指定希望对象停留在CloudFront缓存中的最短时间（以秒为单位），然后CloudFront将另一个请求转发到源，以确定是否该对象已更新。最小TTL的默认值为0秒。

Minimum TTL Specify the minimum amount of time, in seconds, that you want objects to stay in CloudFront caches before CloudFront forwards another request to your origin to determine whether the object has been updated. The default value for Minimum TTL is 0 seconds.

。如果您将CloudFront配置为将所有标头转发到源头以进行缓存行为，则CloudFront永远不会缓存关联的对象。相反，CloudFront将对这些对象的所有请求转发到源。在该配置中，最小TTL的值必须为0。

. If you configure CloudFront to forward all headers to your origin for a cache behavior, CloudFront never caches the associated objects. Instead, CloudFront forwards all requests for those objects to the origin. In that configuration, the value of Minimum TTL must be 0.

推荐答案

对于将对象缓存多长时间，CloudFront使用以下逻辑：

When deciding whether and for how long to cache an object, CloudFront uses the following logic:

检查是否有任何 Cache-Control 响应标头具有以下值：

Check for any Cache-Control response header with these values:

• 无缓存


• 无商店


• 私有

• no-cache
• no-store
• private

如果遇到任何一个，停止并设置对象的TTL¹。设置为最小TTL 。非零值表示CloudFront会缓存原本不会缓存的对象。

If any of these is encountered, stop, and set the object's TTL¹ to the configured value of Minimum TTL. A non-zero value means CloudFront will cache objects that it would not otherwise cache.

否则，找到原始对象的指令可将对象缓存多长时间。 依次，找到以下响应标头之一：

Otherwise, find the origin's directive for how long the object may be cached. In order, find one of these response headers:

• 缓存控制：s -maxage = x


• 缓存控制：max-age = x


• 过期

• Cache-Control: s-maxage=x
• Cache-Control: max-age=x
• Expires

使用此方法遇到的第一个值排序，然后继续下一步。

Stop on the first value encountered using this ordering, then continue to the next step.

如果未找到任何值，请使用默认TTL 。停止。

If no value was found, use Default TTL. Stop.

否则，使用上一步中发现的值：

Otherwise, using the value discovered in the previous step:

• 如果小于 Minimum TTL （最小TTL），则将对象的TTL设置为Minimum TTL。否则，


• 如果大于最大TTL ，则将对象的TTL设置为最大TTL；否则，


• 使用上一步中找到的值作为对象的TTL。

• If smaller than Minimum TTL, then set the object's TTL to Minimum TTL; otherwise,
• If larger than Maximum TTL, then set the object's TTL to Maximum TTL; otherwise,
• Use the value found in the previous step as the object's TTL.

请参见 https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide /Expiration.html 。

请务必注意，TTL确定允许缓存响应的时间。它没有不指示需要多长时间才能缓存响应。如果对象很少被访问，则CloudFront可以在TTL过期之前从缓存中逐出对象。

It's important to note that the TTL determines how long CloudFront is allowed to cache the response. It does not dictate how long CloudFront is required to cache the response. CloudFront can evict objects from cache before TTL expires, if the object is rarely accessed.

将 some （但不是全部）标头列入白名单以转发到

Whitelisting some (but not all) headers for forwarding to the origin does not change any of the above logic.

它所做的更改是如何对对象求值以确定缓存的响应是否可用。

What it does change is how objects are evaluated to determine whether a cached response is available.

例如，如果将 Origin 标头转发到原点，则 Origin的每个唯一值头创建另一个缓存条目。然后将两个相同的请求（它们的 Origin 标头除外）视为不同的对象...因此， Origin的缓存响应：https：//如果以后对同一资源的请求包含来源：https：//two.example.com ，则不会使用one.example.com 。两者都将被发送到源，并且都将被独立缓存，以用于使用与之匹配的请求标头相同的将来的请求。

For example, if you forward the Origin header to the origin, then each unique value for an Origin header creates a different cache entry. Two requests that are identical, except for their Origin header, are then considered different objects... so a cached response for Origin: https://one.example.com would not be used if a later request for the same resource included Origin: https://two.example.com. Both would be sent to the origin, and both would be cached independently, for use in serving future requests with same the matching request header.

CloudFront这样做是因为如果您需要将标头转发到原点，这意味着原点对白名单标头的不同值可能会有不同的反应……因此它们被分别缓存。

CloudFront does this because if you need to forward headers to the origin, then this implies that the origin will potentially react differently to different values for the whitelisted headers... so they are cached separately.

转发标头这样会不必要地降低缓存的命中率。

Forwarding headers unnecessarily will thus reduce your cache hit rate unnecessarily.

基于头文件的不同，对于CloudFront可以缓存的同一资源的不同副本的数量没有记录的限制。

There is no documented limit to the number of different copies of the same resource that CloudFront can cache, based on varying headers.

但是将 all 标头转发到源头会将将来的请求真正相同的机会降低到几乎为零。这可能会消耗大量的缓存存储空间，从而存储了永远不会再使用的对象，因此CloudFront将其视为特殊情况，并且在这种情况下不允许进行任何缓存。因此，必须将最小TTL设置为0，以保持一致性。

But forwarding all headers to the origin reduces to almost zero the chance of any future request being truly identical. This would potentially consume a lot of cache storage, storing objects that would never again be reused, so CloudFront treats this as a special case, and does not allow any caching under this condition. As a result, you are required to set Minimum TTL to 0 for consistency.

¹ 对象的TTL此处使用的指每个缓存对象的CloudFront内部计时器，该计时器跟踪允许多长时间继续为该缓存对象提供服务而无需向后查询原点。 CloudFront内部仅对象知道该对象的TTL，因此该值不会影响浏览器缓存。

¹the object's TTL as used here refers to CloudFront's internal timer for each cached object that tracks how long it is allowed to continue to serve the cached object without checking back with the origin. The object's TTL inside CloudFront is known only to CloudFront, so this value does not impact browser caching.

这篇关于Cloudfront Minimum TTL有什么用？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！