amazon-web-services - Cloudfront 最小 TTL 有什么用？

Question

我试图理解Minimum TTL，Maximum TTL并Default TTL与这个文件。

据我了解，Maximum TTL当HTTP cache header出现在响应中以限制最大缓存时间 Default TTL时使用，并且在没有HTTP cache header用作默认缓存时间时使用。

但是，对于Maximum TTL，没有具体提及。

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

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

重要的

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

标签： amazon-web-servicesamazon-cloudfront

Answer 1

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

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

• no-cache
• no-store
• private

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:

• 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.

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

Otherwise, using the value discovered in the previous step:

• 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.

See https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html.

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.

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.

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 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.

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

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.

---

¹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.