强制CloudFront传递S3中的最新HTML文件


13

背景

我在S3上托管一个静态站点,而CloudFront位于顶部。我的问题是我的HTML文件。

根据CloudFront的常见问题解答

Amazon CloudFront使用这些缓存控制标头来确定它需要多久检查一次该文件的更新版本的来源

到目前为止我做了什么

考虑到这一点,我在S3存储桶中设置了HTML文件,以添加以下标头:

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Expires: Fri, 01 Jan 1990 00:00:00 GMT

在第一次致电my时samplefile.htm,我看到以下响应标头(Content-Type为了明确说明起见,我已经排除了明显的标头(例如):

Cache-Control:no-cache, no-store, max-age=0, must-revalidate
Date:Sat, 10 Dec 2011 14:16:51 GMT
ETag:"a5890ace30a3e84d9118196c161aeec2"
Expires:Fri, 01 Jan 1990 00:00:00 GMT
Last-Modified:Sat, 10 Dec 2011 14:16:43 GMT
Server:AmazonS3
X-Cache:Miss from cloudfront

如您所见,我的Cache-Control标题位于其中。问题是,如果我更新此文件并刷新,则会得到缓存的内容(而不是最新的文件),并且通过查看响应头可以看到CloudFront正在提供其缓存的版本:

X-Cache:Hit from cloudfront

摘要/问题

考虑到上述问题,使用CloudFront时如何实现自动检索最新的HTML?

根据其常见问题解答,我应该可以使用Cache-Control标头来执行此操作,但似乎无法正常工作。

遵循以下答案

最后,我决定将www CNAME更改为直接指向我的S3存储桶。然后添加了一个名为“ static”的新CNAME,它指向CloudFront。

这意味着HTML直接来自S3,然后S3的所有CSS / JS / IMG引用均指向static.mydomain.com

Answers:


6

首先,Cloudfront的重点是提供缓存的内容-如果您尝试从Cloudfront提供未缓存的内容,则比在大多数情况下直接从S3提供内容要慢(在某些情况下,例如流内容除外)。考虑一下,从Cloudfront提供内容需要发生什么-需要将其从原始服务器检索到地理位置上与用户接近的位置-这意味着对于Cloudfront必须从原始服务器检索内容的请求,则会在请求中增加额外的延迟,并且用户接收内容的速度会变慢。仅当内容在边缘位置可用时,后续请求才会更快。

解决此问题的最佳方法是在更新页面时更改文件名-这将迫使Cloudfront检索新内容。同样,请记住,Cloudfront通常用于媒体文件(包括图像)和样式/ javascript,而不是用于html。本质上,您将在S3上使用HTML,在Cloudfront上使用您的图像-进行任何更改后,您都可以在Cloudfront上更改文件的名称(例如file-v1.jpg,file-v2.jpg等)。另一种常见的方式是包括带有版本信息的查询字符串。

另外,请记住,Cloudfront不会提供压缩的内容-这可能导致响应速度比常规服务器慢(尽管在您的情况下,S3也无法识别支持gzip的浏览器)。

最后,如果需要,您可以使用失效来强制Cloudfront放弃其现有副本并从原始服务器获取一个新副本。但是请注意,Cloudfront每月仅为您提供1000次免费失效,其后的费用为每失效$ 0.005。

Cloudfront保留内容的最短时间为1hr,但是默认值为24hr。因此,我尝试将max-age至少设置为3600。还要考虑s-maxage标头(用于共享-即代理内容)。亚马逊推荐缓存教程。

最近有一个问题,几天前已解决


之所以在S3坚持CF是由沃纳·博赫尔斯提到它自己在他的博客 allthingsdistributed.com/2011/02/website_amazon_s3.html。如您所说,我可能会考虑直接从s3路由html。一个小注意事项:在文件末尾添加查询字符串以进行缓存清除不是一个好主意,因为它可能导致某些代理永不缓存。
isNaN1247 2011年

这个家伙似乎在每次上载时都使用了无效操作,似乎过分了jmlacroix.com
isNaN1247

1
查询字符串无法与Cloudfront一起使用-它不会缓存文件,但是如果您直接提供内容,它们将是有效的。S3的HTML是最好的选择。您当然不希望使每次上载的所有内容无效,但是在某些情况下使已更改的文件无效并非没有道理。Cloudfront的优点仅在流量大的站点上才真正重要-对于您的普通站点,S3甚至可以提供更好的性能(两者都尝试一下-尤其是对于小型对象,Cloudfront可能很慢)。
cyberx86

2
Cloudfront现在支持Gzip压缩。这里的公告
格雷格·萨德斯基2013年

如今@ cyberx86的限制有所不同:The minimum expiration time CloudFront supports is 0 seconds for web distributions and 3600 seconds for RTMP distributions. docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/…–
xvga

20

我相信到目前为止的答案虽然当时是正确的,但现在已经过时了,因为Cloudfront现在支持最小TTL为0,并且OP最初使用cache-age = 0的原始尝试现在应该可以工作。

您可能要研究是否使用其他缓存控制标头,以了解它们是否会产生您想要的结果-您可能只需要max-age。您可能想要的是让Cloudfront检查S3以查看HTML文件是否已更改。如果有,Cloudfront可以获取并返回新文件。如果没有,它可以从其现有缓存中为客户端提供服务(节省S3带宽,并更快,更本地地为客户端提供服务)。

是的,Cloudfront的重点是提供缓存的内容,但是现在包括的内容有时会更改,但是如果内容没有更改,则可以缓存。

Ps查询字符串现在也可以与Cloudfront一起使用(如果您为相关来源配置“行为”,这是另一个新功能),但是某些代理可能仍然无法缓存带有查询字符串的任何文件。

Amazon开发人员指南:到期1


By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.