什么是CloudFront中的TTL 0有用？
几个星期前亚马逊宣布他们已经降低了内容到期期限：
Amazon CloudFront降低最低内容有效期限
所以我现在的问题是，为什么将TTL设置为0的CloudFront分配是有用的。对我来说，这意味着不需要任何caching，因此每个到达CloudFront的请求将最终击中原点。
我错过了什么？
Amazon CloudFront的这个新function对于许多用例来说实际上是非常有用的，因为点击起源的作用有点不同于一见钟情，并不一定是问题，相反， 虽然此function早已经发布，但它与Amazon CloudFront的最新版本- dynamic内容支持 （例如，手头的问题）
可变的生存时间（TTL） – 在很多情况下，dynamic内容在很短的时间内（或许只有几秒钟）不可caching或可caching。 过去，CloudFront的最小TTL是60分钟，因为所有内容都被认为是静态的。 新的最小TTL值是0秒。 如果将特定来源的TTL设置为0，则CloudFront仍将caching来自该来源的内容 。 然后，它将通过If-Modified-Since标 头发 出GET请求 ，从而使原点有机会发出信号，表明CloudFront可以继续使用caching的内容（如果原始内容未更改） 。 [强调我的]
换句话说，使用0的TTL主要是指CloudFront将caching控制的权限委托给原始数据，即原始服务器决定是否以及多久CloudFrontcaching对象; 请特别注意， 具有If-Modified-Since标头的GET请求并不一定意味着对象本身是从原点检索的，而是原点可以（并且应该）返回HTTP状态码304-在适用的情况下：
表示自上次请求以来资源未被修改。 使用这个function可以节省服务器和客户端的带宽和重新处理，因为只有头部数据必须与服务器重新处理的整个页面进行比较，然后再使用更多的带宽的服务器和客户端。 [强调我的]
有关HTTPcaching控制的机制和优势的详细信息，请参阅Mark Nottingham的优秀caching教程 ，这是HTTP体系结构中非常重要和有效的一部分。
了解所有这些部分如何一起工作确实有点困难，因此，在指定CloudFront在下载分发中caching对象的最短时间（ 指定在CloudFront边缘caching（对象到期）中 保留 多长对象的 时间）一节中的表会尝试总结效果在具有或不具有TTL = 0的CloudFront环境中应用时。
请注意，亚马逊并不是说“TTL为0”，而是说“最小TTL为0”。 这是非常不同的。 上面的描述是非常可取的，但不能保证Cloudfront真正做到这一点。
在我现在的经验中，我可以看到caching的图像在边缘停留了几分钟，而原点已经改变了。
所以，我认为“最小TTL为0”可能更像是“亚马逊没有严格意图将其保存在caching中”，也许“并且会经常重新读取”。
对于像CMS这样的networking用户发布新内容的应用，我认为TTL-0还是不够的。 您仍然必须从CMS调用失效，或为不同的版本号使用不同的path。
