概述

本文将介绍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 CloudFronticon-default.png?t=N7T8https://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesCacheBehavior自定义源的请求和响应行为 - Amazon CloudFronticon-default.png?t=N7T8https://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#request-custom-headers-behavior

Logo

亚马逊云科技开发者 Build On 是由亚马逊团队策划、开发者社区联合打造的动手实操系列活动。

更多推荐