【Amazon 实验②】使用缓存策略及源请求策略,用于控制边缘缓存的行为及回源行为
接上一篇文章【Amazon 实验①】使用 Amazon CloudFront加速Web内容分发,我们现在了解和配置如何使用缓存策略及源请求策略,用于控制边缘缓存的行为及回源行为。
1. 了解缓存策略和源请求策略
基于步骤1中的CloudFront分配,了解和配置如何使用缓存策略及源请求策略,用于控制边缘缓存的行为及回源行为。
1.1 使用缓存键和缓存策略
CloudFront缓存策略
CloudFront缓存策略由缓存键值(Cache Key)和 TTL 构成。
CloudFront提供了多种预设的托管缓存策略 ,适配不同场景中的缓存行为控制,如我们在步骤1中使用的CachingOptimized、CachingDisabled等。
CloudFront可识别以下三种请求元素,进而将指定元素作为缓存键值进行缓存,分别为:请求头 / 查询字符串 / Cookie,合理地配置缓存键将提高对象在边缘站点上的缓存命中率。
如何控制缓存时间
可以通过2种方式控制缓存时间:
- 源站的缓存标头Cache-Control,如max-age、expires、no-cache、private等值
- CloudFront缓存策略中的TTL
当同时在源站指定Cache-Control标头并使用CloudFront缓存策略时,有关两者将如何影响CloudFront边缘缓存时间和客户端缓存时间。
实验:使用CloudFront缓存策略和缓存键控制缓存行为
在步骤1,我们为CloudFront的默认行为添加了S3桶源站,并分发了一张infra.png图片和index.html主页文件。
在该行为设置中,我们使用了托管的CachingOptimized缓存策略。该策略包含以下设置: 此策略包含以下设置:
- 最小 TTL:1 秒。
- 最大 TTL:31536000 秒(365 天)。
- 默认 TTL:86400 秒(24 小时)。
- 缓存键中包含的标头:未明确包含任何标头。包含标准化的 Accept-Encoding 标头,因为已启用缓存压缩对象设置
- 缓存键中包含的 Cookie:无。
- 缓存键中包含的查询字符串:无。
- 缓存压缩对象设置:已启用
在接下来的实验中,我们将在URL中使用查询字符串参数访问infra.png,如 https://d123abc.cloudfront.net/infra.png?version=v1 和 https://d123abc.cloudfront.net/infra.png?version=v2 ,验证当前CachingOptimized缓存策略对不同版本的infra.png的缓存效果,并新建基于querystring缓存的缓存策略。
在本实验中我们使用S3对象版本控制模拟需要查询字符串访问的环境。首先回到S3存储桶中,在属性中打开版本控制。
- 打开存储桶版本控制
- 更新S3存储桶策略,在Action处添加
s3:GetObjectVersion
上传另一张名为infra.png的图片至S3,在S3对象的版本处,能看到infra.png具有2个版本。
使用CloudFront分配url访问infra.png,并在url中添加?versionId=查询字符串,加入infra.png的版本号。可以看到CloudFront对于不同的URL返回了同样的缓存,这是因为在托管的CachingOptimized缓存策略中并未使用query string(versionId)作为缓存键,故提供先前已缓存在边缘节点的对象(即infra.png,不带其他cache key)
为了使得CloudFront能够根据查询字符串缓存结果,我们需要新建一个CloudFront分配行为和缓存策略。在行为路径中指定/*.png,在缓存策略处点击新建缓存策略,添加 versionId 作为需要缓存的查询字符串,其他TTL设置按需调整,如下图所示。保存缓存策略后,为该行为选择新建的缓存策略。
进入CloudFront失效标签,键入/infra.png使缓存失效。
再次访问两个包含query string的infra.png URL,将看到CloudFront已区分infra.png的查询字符串将versionId作为缓存键进行缓存。
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!