Cloudfront max-age 与 TTL 一起有用吗？

Question

对于图片库，我使用亚马逊cloudfront。

\n\n

我在原点设置了：

\n\n

Cache-Control:max-age=31536000 (1 Year)\n

\n\n

1 . 当我已经设置了 max-age 时，将 TTL 0（24 小时）设置为 1 年是否有用？

\n\n

2 . 当我将 max-age 设置为 1 年时，亚马逊会每 24 小时检查一次 TTL0 的文件吗？

\n\n

亚马逊是这样说的：

\n\n

Objects are cached for the greater of the value of the Cache-Control max-age directive or the value of the CloudFront Minimum TTL\n

\n\n

亚马逊还表示：

\n\n

If an object in an edge location isn't frequently requested, CloudFront might evict the object\xe2\x80\x94remove the object before its expiration date\xe2\x80\x94to make room for objects that are more popular.\n

\n\n

在这种情况下，我认为将 TTL 设置为年份很有用，因为图像肯定会保留而不是之前？请纠正我。

\n\n

感谢您的澄清。

\n

Answer 1

这个问题基本上在Cloudfront TTL not running的答案中得到了回答，尽管这个问题并不完全重复。

\n

不，如果您设置自己的标头，则最小 TTL 并不是特别有用Cache-Control:。

\n

不会，如果您的最小 TTL或Cache-Control:标头指定的期限超过 24 小时，Cloudfront 不会每 24 小时检查一次。如果 Cloudfront 要检查某个对象，则该对象需要过期。从像 Cloudfront 这样的缓存的角度来看，最大允许年龄的要点在于，在最大允许年龄到期之前，不需要检查，因为对象预计不会过时。

\n

生存时间 (TTL)（不是“最小 TTL”，只是作为一般概念的 TTL）是缓存（例如 Cloudfront）应该在不验证的情况下提供对象副本的最长时间，其中源服务器，它的对象副本不是陈旧的。生存时间是缓存可以保留对象而不验证其新鲜度的最大允许年龄。

\n

最小TTL并不是对象应缓存的最短时间。

\n

最小 TTL 是用于确定最大允许年龄的最小值。它是 TTL 的最小值，并且仅指定最大寿命的最小下限，这样Cache-Control:指定比最小 TTL更短的TTL 的冲突标头将被忽略、覆盖、向上增加，而使用最小 TTL代替（确定对象缓存中允许的最大年龄）。

\n

类似地，在没有任何其他指令的情况下，最小 TTL被用作缓存中对象的最大寿命的唯一决定因素。

\n

所以，不，将最小 TTL 和Cache-Control:标头设置为相对较大的值将不会产生任何效果，因为，正如您正确指出的那样：

\n

\n

对象将按照 Cache-Control max-age 指令的值或 CloudFront 最小 TTL 的值中的较大者进行缓存

\n

^{\xe2\x80\x94 http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html}

\n

\n

然而，阅读本声明时必须了解缓存的本质。缓存存储的内容（通常根据缓存的性质）是易失性和短暂的，可以随时被逐出。正如您还指出的：

\n

\n

如果不经常请求边缘站点中的对象，CloudFront 可能会逐出该对象\xe2\x80\x94在其过期日期之前删除该对象\xe2\x80\x94，以便为更受欢迎的对象腾出空间。

\n

\n

通过配置 Cloudfront 或源服务器无法避免这种情况。有时物体会被驱逐。只要最高年龄允许，他们就可能而且经常被关押，有时甚至更长。

\n

\n

通常，CloudFront 从边缘站点提供对象服务，直至该对象过期。过期后，下次边缘站点收到最终用户对该对象的请求时，CloudFront 会将请求转发到源服务器以验证缓存是否包含该对象的最新版本：

\n

如果 CloudFront 已具有最新版本，则源仅返回 304 状态代码（未修改）。

\n

\n

如果您不熟悉304 Not Modified，您可能希望研究它以及If-Modified-Since:通常从源服务器触发此响应的请求标头。（当然，在您缓存动态图像调整大小操作的结果的情况下，您的源将永远无法响应，304除非它保留了自己先前对请求的响应的本地副本。）

\n

同样重要但经常被忽视的事实是 Cloudfront 不是一个单一的实体。说特定对象在任何给定时刻“存储在”或“未存储在”Cloudfront 中是不准确的。截至撰写本文时，有超过 50 个边缘位置，并且对象可能存储在某些边缘位置中，而不存储在其他边缘位置中。它可能会被提前从一个边缘位置驱逐，但不会从其他位置驱逐。在从未请求过对象的边缘位置，它永远不会被存储，直到第一个请求发生导致它被获取为止。

\n