AWS-CloudFront-行为参数详解
概述本文将介绍CloudFront创建行为时的参数配置。CloudFront的多条行为会跟进由上至下的优先级进行匹配。创建行为路径模式路径模式-配置您希望该缓存行为所适用的请求。通俗点讲就是类似于nginx的location配置。路径模式可以以/开头,也可以不以/开头,这两者表示的意思是一样的。路径模式可以使用的通配符有:* 匹配0或多个字符? 精准匹配一个字符路径模式example:*.jpg/
概述
本文将介绍CloudFront创建行为时的参数配置。CloudFront的多条行为会跟进由上至下的优先级进行匹配。
创建行为
路径模式
路径模式-配置您希望该缓存行为所适用的请求。通俗点讲就是类似于nginx的location配置。
路径模式可以以/开头,也可以不以/开头,这两者表示的意思是一样的。
路径模式可以使用的通配符有:
- * 匹配0或多个字符
- ? 精准匹配一个字符
路径模式example:
*.jpg
/api/*
/api/example/create #完全匹配
源或源组
源或源组的创建在CloudFront的源选项中创建,这里只是选择已创建好的源或源组。
常见的源有:
- AWS S3桶
- AWS 负载均衡器
还可以配置一个可以被解析到的域名作为源。比如要把请求转发到某个其他站点,或者后端服务有个域名作为其负载均衡的接入点。
查看器协议策略
通俗点讲就是允许https还是http的请求来访问你
- HTTP 和 HTTPS:查看器可使用两种协议。
- Redirect HTTP to HTTPS (将 HTTP 重定向到 HTTPS):查看器可使用两种协议,但 HTTP 请求将自动重定向到 HTTP 请求。
- 仅 HTTPS:如果查看器使用了 HTTPS,则只能访问您的内容。
允许的HTTP方法
指定您希望 CloudFront 处理并转发到源的 HTTP 方法:
- GET、HEAD:您只能使用 CloudFront 获取您源中的对象或获取对象标头。
- GET、HEAD、OPTIONS:您只能使用 CloudFront 从源获取对象、获取对象标头或检索您的源服务器支持的选项列表。
- GET、HEAD、OPTIONS、PUT、POST、PATCH、DELETE:您可以使用 CloudFront 获取、添加、更新和删除对象以及获取对象标头。此外,您可以执行其他 POST 操作,例如从 Web 表格提交数据。
如果源是AWS S3桶托管的静态站点,一般可以选择“GET、HEAD”,因为基本只有GET请求。
如果源是负载均衡器反向代理的后端服务接口,一般选择“GET、HEAD、OPTIONS、PUT、POST、PATCH、DELETE”。
缓存键和请求源
在“Legacy cache settings”传统缓存设置中,有三项:标头、查询字符串、Cookie。意思是指,是否根据request header、url中的请求参数、Cookie的值的不同,进行缓存。
标头(request header)、查询字符串、Cookie三项都有三个选项:
- 无 – CloudFront 不根据标头、查询字符串、Cookie的值缓存您的对象。
- 白名单 – CloudFront 仅根据指定标头、查询字符串、Cookie的值缓存您的对象。使用白名单选择您希望 CloudFront 进行缓存所基于的标头、查询字符出啊、Cookie。
- 所有 – CloudFront 不缓存与该缓存行为关联的对象。相反,CloudFront 会将每个请求发送到源。(不建议用于 Amazon S3 源。)
打个比方,以标头为例:
- 如果选择[无],则CloudFront会根据你配置的TTL时间进行缓存。但是缓存不会因为某一request header的值不同,来进行区分缓存。也就是无论request header值是什么,缓存之后都只会返回第一次缓存下来的值。注意:选择[无]时还可以配置TTL时间,如果TTL时间都配置为0,则表示不缓存。
- 如果选择[白名单],比如白名单配置了“User-Agent”。则你第一次请求中“User-Agent”的值为mobile,得到的结果为“A”,则这次请求会将根据User-Agent=mobile,缓存结果A;后面有一次请求“User-Agent”的值为PC,得到结果为“B”,则会根据User-Agent=PC,缓存结果B。以后的请求,则会根据User-Agent的值查看是否命中缓存。
- 如果选择[全部],则这个最简单,不缓存,并且直接回源。
一个疑问?
选择[无] 并且TTL设置为0,那么就不缓存了;和选择[全部],不缓存直接回源。这两者有什么区别?
下面我将简单介绍3个使用场景,介绍一下区别。
场景一:转发至AWS S3桶托管的静态页面
一般这种场景你都是希望缓存前端的静态文件的,使得世界各地的用户享受到CloudFront所带来的静态文件加速。
那么在“缓存见和请求源”处可以这么选:
标题、查询字符串、Cookie都选择无,表示不管request header、查询字符产、Cookie的key、value有哪些,都只缓存一份请求,不区分混村。TTL时间根据实际情况进行调整。
场景二:转发至AWS 负载均衡器反向代理的后端服务
一般访问后端服务,你的查询等操作都是需要实时获取最新数据的,所以你希望数据有缓存。
那么在“缓存见和请求源”处可以这么选:
[全部]的意思就是:不缓存,并且会将请求直接发送给源站。此时所有的request header会不变地发给源站。
场景三:将请求转发到其他域名的后端接口(不缓存)
设想一下,如果要转发到的域名解析之后,是访问到你服务内部地网关服务器。
网关服务器(比如nginx组成的一个反向代理集群),其特点之一就是代理了非常多的域名转发配置。要根据request header中的Host的值,去区分这一次请求是对应哪个域名的转发配置。
但是,当我们通过CloudFront去转发时,我们可能是通过CloudFront的cname或者是其备用域名去访问,则Host将是CloudFront的域名。由于“缓存见和请求源”处选择[全部]直接回源时,request header也是全部不会修改,发送给源的;而且“源和源组”的配置中,自定义请求头也是不可以添加/修改HOST的值的(如下图)。这种情况下,Host的值为CloudFront的域名,而不是我们实际关联的源的域名。这样的请求到达我们源站(一个网关)时,会因为Host中的域名在网关上没有对映转发配置而产生问题。
那我们应该如何做,才能将请求“不缓存、直接回源”,并且将host修改为实际源站的域名呢?
可以使用如下配置:
根据标头缓存选择:[无]
且TTL缓存时间设置为:0
这两者配置可以实现“不缓存”(那为什么要实现“不缓存”,不直接选择[全部],直接回源呢?)
因为如果选择[无],不根据标头区分缓存。则可实现其“修改Host头为关联的源的域名”的特性。
- 通过根据标头缓存选择:[无] 实现修改Host为关联的源的域名
- 通过设置TTL为:0 实现不缓存的目的
参考文档
您创建或更新分配时指定的值 - Amazon CloudFronthttps://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesCacheBehavior自定义源的请求和响应行为 - Amazon CloudFronthttps://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#request-custom-headers-behavior
更多推荐
所有评论(0)