几周前,亚马逊宣布他们已经降低了内容的有效期:
Amazon CloudFront Lowers Minimum Content Expiration Period
实际上,你现在可以将CloudFront中的TTL设置为0.所以我的问题是,为什么将TTL设置为0的CloudFront分配有用呢。对我而言,这意味着根本没有缓存,所以每个请求都是到达CloudFront将最终击中原点。
我错过了什么?
答案 0 :(得分:144)
Amazon CloudFront的这个新功能实际上对许多用例非常有用,因为命中原点的工作方式与第一眼看上去有点不同,并不一定是个问题,相反的;虽然此功能已经在早些时候发布,但它与最新版本的Amazon CloudFront - Support for Dynamic Content一起发布,例如对于手头的问题:
可变生存时间(TTL) - 在许多情况下,动态内容也是如此 也许,在很短的时间内无法缓存或缓存 只需几秒钟。过去,CloudFront的最低TTL为60 因为所有内容都被认为是静态的。新的最小TTL 值为0秒。 如果将特定原点的TTL设置为0, CloudFront仍将缓存来自该来源的内容。 然后会 使用If-Modified-Since标头发出GET请求,从而给出 起源有机会表明CloudFront可以继续使用 如果内容未在原点更改,则缓存内容。 [强调我的]
换句话说,使用0的TTL主要意味着,CloudFront将缓存控制的权限委托给源,即源服务器决定是否以及CloudFront缓存对象的时间长短;请特别注意,带有If-Modified-Since标头的 GET请求并不一定意味着从原点检索对象本身,而是原点可以(并且应该)返回{{ 3}}适用的地方:
表示自上次请求后资源未被修改。 [...] 使用它可以在服务器和服务器上节省带宽和重新处理 客户端,因为只有标题数据必须发送和接收 与被重新处理的整个页面进行比较 服务器,然后使用更多带宽的服务器和客户端再次发送。 [强调我的]
有关HTTP缓存控制的机制和优势的详细信息,请参阅Mark Nottingham的优秀HTTP status code 304 - Not Modified,这是HTTP架构中非常重要且有效的部分。
了解所有这些部分如何协同工作确实有点困难,因此在Caching Tutorial中指定CloudFront为下载分发缓存对象的最短时间部分中的表格尝试总结在具有或不具有TTL = 0的CloudFront上下文中应用时的效果。
答案 1 :(得分:3)
请注意,亚马逊并未说“TTL为0”,而是说“最小TTL为0”。那是非常不同的。上面的描述是非常理想的,但不能保证Cloudfront实际上是这样做的。
根据我的经验,我可以看到缓存的图像在边缘停留几分钟,而我的原点已经改变了。
因此,我认为“最小TTL为0”可能更像是“亚马逊没有严格意图将其保留在缓存中”,也许“并且它会经常重新获取”。
对于像CMS这样的应用程序,Web用户发布新内容,我认为TTL-0仍然不够。您仍然必须从CMS调用失效或为不同的版本号使用不同的路径。
答案 2 :(得分:0)
CloudFront可与证书管理器结合使用,为S3网站添加HTTPS支持。你可能想要这个,但零缓存。
答案 3 :(得分:0)
这的另一个用例是:如果要使用lambda edge https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-at-the-edge.html处理对不可缓存内容的请求的标头。示例x-api-key
。