文档

配置缓存过期时间

更新时间:

缓存过期时间指源站资源在CDN节点缓存的时长,达到预设时间,资源将会被CDN节点标记为失效资源。如果客户端向CDN节点请求的资源已经失效,CDN会回源站获取最新资源并缓存到CDN节点。您可以根据业务需求,按目录或文件后缀名配置静态资源的缓存过期时间。

注意事项

  • 您成功添加域名后,可以修改缓存时间。设置的缓存时间长短会导致回源流量不一样,费用也有所不同,建议根据不同的业务需求设置缓存时长。缓存过期时间会影响回源频率,建议根据实际业务需求设置资源缓存时长。

    缓存过期时间过短,会导致CDN频繁回源,增加源站的流量消耗;缓存过期时间过长,会带来数据更新时间慢的问题。

  • 缓存在CDN节点上的资源,如果该资源的访问热度较低(同一个CDN节点上的同一个资源被客户端访问的频次较低),那么很可能会在缓存过期之前被CDN节点上其他访问热度较高的资源覆盖

  • CDN节点在收到源站响应的静态文件资源的时候,默认会按照阿里云CDN默认缓存规则及优先级来执行。

  • 建议您源站的内容不使用同名更新,而是采用版本号的方式同步。

    为了能准确找到更新前和更新后的源站内容,建议您源站的内容以版本号的方式同步,即更新源站内容时采用不同的名称。例如,采用img-v1.0.jpgimg-v2.1.jpg的方式命名。

操作步骤

  1. 登录CDN控制台

  2. 在左侧导航栏,单击域名管理

  3. 域名管理页面,找到目标域名,单击操作列的管理

  4. 在指定域名的左侧导航栏,单击缓存配置

  5. 缓存过期时间页签下,单击添加

  6. 添加缓存过期时间对话框,配置缓存规则。

    缓存过期时间

    参数

    说明

    类型

    支持按目录文件后缀名指定资源范围。

    • 目录:为某一路径下所有资源设置相同缓存规则。

    • 文件后缀名:为某一文件类型资源的设置相同缓存规则。

    地址

    指定待配置资源的目录或文件后缀名。

    • 类型选择目录时,填写规则如下:

      • 每次只能添加单条目录,可以用正斜线(/)匹配所有目录。

      • 支持输入目录的完整路径,须以正斜线(/)开头,例如/directory/aaa

    • 类型选择文件后缀名时,填写规则如下:

      • 支持输入一个或多个文件后缀名,多个文件后缀名用半角逗号(,)分隔,例如jpg,txt

      • 大小写敏感,注意区分大小写。

      • 不支持用星号(*)匹配所有的文件类型。

    过期时间

    资源在CDN节点的缓存时间,最长可以设置3年。建议参考如下规则配置:

    • 不常更新的静态文件(例如,图片类型、应用下载类型等),建议设置1个月以上。

    • 频繁更新的静态文件(例如,JS、CSS等),根据实际业务情况设置。

    • 动态文件(例如,PHP、JSP、ASP等),建议设置为0s,即不缓存。

    权重

    权重即缓存规则的优先级。取值为1~99,数值越大优先级越高,对应规则优先生效。

    说明
    • 有多条缓存规则的情况下,建议每条缓存规则都设置不同的权重,通过权重来控制规则执行优先级。

    • 权重相同的规则生效优先级:先创建的>后创建的,与规则类型无关。

    • 如果配置了多条缓存策略,其中一条缓存策略生效后将不再继续匹配其他的缓存策略。

    规则条件

    规则条件能够对用户请求中携带的各种参数信息进行识别,以此来决定某个配置是否对该请求生效。

    • 不使用:不使用规则条件。

    • 选择已配置的规则引擎,新增或修改规则引擎请参见规则引擎

  7. 单击确定,完成配置。

    您可以在缓存过期时间列表中,根据所需修改删除配置。

阿里云CDN默认缓存规则及优先级

CDN节点在收到源站响应的静态文件资源的时候,会按照以下的缓存规则来执行(数值越小,优先级越高):缓存优先级

  1. 源站响应pragma:no-cachecache-control:no-cache(或者no-store,或者max-age=0)时,不缓存。

  2. CDN控制台设置的缓存过期时间或者状态码过期时间。

    说明

    CDN请求同时命中多条规则,有且仅有一条规则会生效,优先级为:权重>规则创建时间。

    • 有多条缓存规则的情况下,建议每条缓存规则都设置不同的权重(权重越大优先级越高),通过权重来控制规则执行优先级。

    • 权重相同的规则生效优先级:先创建的>后创建的,与规则类型无关。

  3. 源站配置其他缓存规则,优先级由高至低为:cache-control>expires>last-modified>ETag

    1. 源站响应中使用cache-control设置过期时间,取值为max-ages-maxage,并且max-ages-maxage的值大于0,例如:cache-control:max-age=3600。如果同时存在max-ages-maxage,则以s-maxage的值为准。

    2. 源站响应中使用expires设置过期时间,例如:expires:Tue, 25 Nov 2031 17:25:43 GMT。

    3. 源站响应中携带了ETaglast-modified,则使用以下规则来计算缓存时间:

      1. last-modified,使用公式(当前时间-last-modified)* 0.1,计算结果在10秒~3600秒及之间的,取计算结果时间;小于10秒的,按照10秒处理;大于3600秒的,按照3600秒处理。

      2. 只有ETag,缓存10秒。

  4. 源站返回的数据中ETaglast-modifiedcache-controlexpires这些缓存相关的响应头都没有携带,则默认不缓存。

HTTP协议缓存控制机制说明

在HTTP协议中定义了三种不同类型的协议头部来实现缓存控制相关的机制:

  1. 过期时间校验机制

    客户端在向服务端请求资源的过程中,双方将为资源约定一个过期时间,在该过期时间之前,该资源(缓存副本)就是有效的,过了过期时间后,该资源(缓存副本)就会失效。

    在HTTP协议中,控制缓存过期时间的Header常见的有下面这些:

    头部名称

    协议版本

    作用

    示例值

    类型

    Pragma

    HTTP/1.0

    Pragma用于表示内容是否为不缓存,通常取值no-cache,表示文件不缓存,常被用来兼容只支持HTTP1.0 协议的Server。

    Pragma:no-cache

    请求/响应

    Expires

    HTTP/1.0

    Expires响应头包含日期/时间,表示在此时间之后,缓存内容将会过期。

    如果使用了无效的日期,比如0,则代表该资源已经过期。

    Expires: Wed, 21 Oct 2022 07:28:00 GMT

    响应

    Cache-Control

    HTTP/1.1

    Cache-Control响应头可以设置不同的指令来实现灵活的缓存控制,是目前主流客户端(如浏览器等)用于控制缓存的重要头部。

    以下三个示例表示文件不缓存:

    • Cache-Control:no-cache

    • Cache-Control:no-store

    • Cache-Control:max-age=0

    表示缓存有效期1小时的示例:Cache-Control:max-age=3600

    请求/响应

  2. 资源标签验证机制

    客户端在首次向服务端请求资源的过程中,服务端将在响应头中带上资源标签,资源标签可以作为客户端再次请求同一资源时的校验标识。客户端再次请求同一资源时,请求头中将会携带资源标签,若服务端校验后认为该资源没有更新,则响应HTTP状态码304,告诉客户端该资源没有更新,客户端可以继续使用本地缓存;若服务端校验后发现资源标签不匹配,则告诉客户端该资源已经被修改或者已经过期,客户端需要重新获取资源内容。

    在HTTP协议中,控制缓存版本的Header常见的有下面这些:

    头部名称

    协议版本

    作用

    示例值

    类型

    Last-Modified

    HTTP/1.0

    Last-Modified表示资源的最后修改时间。

    Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT

    响应

    ETag

    HTTP/1.1

    ETag表示当前资源特定版本的唯一标识符。

    对比ETag能判断资源是否变化,如果没有改变,源站服务器不需要发送完整的响应。

    ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

    响应

  3. 多副本协商机制

    缓存软件使用关键字索引在磁盘中缓存的对象,在HTTP/1.0中使用资源的URL作为关键字,但可能存在不同的资源基于同一个URL的情况,要区别它们还需要客户端提供更多的信息,例如:Accept-Language、Accept-Charset等头部,为了支持这种内容协商机制(content negotiation mechanism),HTTP/1.1在响应消息中引入了Vary头部,该头部列出了请求消息中需要包含哪些头部用于内容协商。

    多副本协商机制通常使用HTTP协议的Vary头部来区分不同的缓存副本,实现不同的客户端请求同一个资源的时候可以拿到不同缓存副本:

    头部名称

    协议版本

    说明

    示例值

    类型

    Vary

    HTTP/1.1

    常用示例:

    • 服务端指定Vary: Accept-Encoding,告知接收端(例如:CDN节点)对于该资源需缓存两个版本(压缩和未压缩)。客户端向CDN请求同一个资源时,老版本浏览器获取未压缩资源(避免兼容性问题),新版本浏览器获取压缩资源(减少数据传输流量)。

    • 服务端指定Vary: User-Agent,用来识别发送请求的浏览器类型,告知接收端(例如:CDN节点),根据不同的浏览器类型缓存对应版本的资源。

    Vary: Accept-Encoding

    Vary: Accept-Encoding,User-Agent

    响应

配置示例

示例一:需要对“.txt”格式的文件缓存7天,在CDN控制台增加一条文件名后缀为“txt”的缓存规则,缓存过期时间设置为“7天”。

image.png

示例二:为加速域名demo.aliyun.com配置以下缓存策略,CDN节点回源下载资源http://demo.aliyun.com/image/example.png,虽然以下两条规则都匹配到了,但是因为这两条规则的权重相同,因此要判断规则创建的时间,先创建的规则优先级高于后创建的,因为目录/image这条规则创建的时间更早,所以系统最终生效的是目录类型这条规则。image.png

相关API

BatchSetCdnDomainConfig

常见问题