概述

本文将介绍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中的域名在网关上没有对映转发配置而产生问题。