通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure Front Door 的缓存

  • 项目

重要

Azure Front Door（经典版）将于 2027 年 3 月 31 日停用。 为了避免任何服务中断，请务必在 2027 年 3 月之前将 Azure Front Door（经典版）配置文件迁移到 Azure Front Door 标准层或高级层。 有关详细信息，请参阅 Azure Front Door（经典版）停用。

Azure Front Door 是具有动态站点加速和负载均衡功能的新式内容分发网络 (CDN)。 在路由上配置高速缓存时，接收每个请求的边缘站点会检查其高速缓存以实现有效响应。 高速缓存有助于减少发送到源服务器的流量。 如果未提供缓存的响应，则会将请求转发到源。

每个 Front Door 边缘站点会管理自己的缓存，因此请求可能由不同的边缘站点提供服务。 因此，即使提供了缓存的响应，你仍可能会看到一些流量到达源。

缓存可以显著降低延迟并减少源服务器上的负载。 但是，并非所有类型的流量都可以从缓存中受益。 图像、CSS 和 JavaScript 文件等静态资产非常适合缓存。 而动态资产（如经过身份验证的 API 终结点）则不应缓存，以防止个人信息泄露。 建议为静态资产和动态资产设置单独的路由，并为后者禁用缓存。

警告

启用缓存之前，请全面查看公共文档，并在启用缓存之前测试所有可能的方案。 如前文所述，如果配置错误，则可能会无意中缓存可由多个用户共享的用户特定数据，从而导致隐私事件。

请求方法

只有使用 GET 请求方法的请求才是可以缓存的。 所有其他请求方法始终通过网络进行代理。

大型文件交付

Azure Front Door 服务可交付大型文件，不限制文件大小。 如果启用了高速缓存，则 Front Door 将使用名为对象区块的技术。 请求大型文件时，Front Door 会从源检索文件的较小部分。 当 Front Door 收到完整的文件请求或字节范围的文件请求后，Front Door 环境将以 8 MB 区块为单位从源请求文件。

区块到达 Azure Front Door 环境后，会将区块缓存并立即提供给用户。 Front Door 会并行预提取下一个区块。 此预提取可确保内容先于用户一个区块，这可以减少延迟。 该过程将一直持续到下载完整个文件（如果需要）或客户端关闭连接为止。 有关字节范围请求的详细信息，请阅读 RFC 7233。

Front Door 会在收到任何区块后将区块缓存，因此整个文件无需在 Front Door 缓存中进行缓存。 后续的文件或字节范围请求将从该缓存提供。 如果区块未全部缓存，将采用预提取从源请求区块。

这种优化依赖于源支持字节范围请求的能力。 如果源不支持字节范围请求，或者未正确处理范围请求，则此优化无效。

当源使用 Range 标头响应请求时，必须采用以下方式之一进行响应：

  • 返回有范围响应。 响应必须使用 HTTP 状态代码 206。 此外，Content-Range 响应标头必须存在，并且必须与源返回的内容实际长度相匹配。 如果源未发送包含有效值的正确响应标头，则 Azure Front Door 不会缓存响应，而且你可能会看到不一致的行为。

    提示

    如果源压缩响应，请确保 Content-Range 标头值与压缩响应的实际长度相匹配。

  • 返回非范围响应。 如果源无法处理范围请求，则可以忽略 Range 标头并返回非范围响应。 确保源返回除 206 以外的响应状态代码。 例如，源可能会返回 200 OK 响应。

如果源使用分块传输编码 (CTE) 将数据发送到 Azure Front Door POP，则不支持大于 8 MB 的响应大小。

文件压缩

请参阅通过在 Azure Front Door 中压缩文件来提高性能。

Azure Front Door（经典版）可动态压缩边缘内容，从而更快响应客户端。 为了让文件符合压缩条件，必须启用缓存，并且文件必须是 MIME 类型才能压缩。 目前，Front Door（经典版）不允许更改此列表。 当前列表为：

  • "application/eot"
  • "application/font"
  • "application/font-sfnt"
  • "application/javascript"
  • "application/json"
  • "application/opentype"
  • "application/otf"
  • "application/pkcs7-mime"
  • "application/truetype"
  • "application/ttf",
  • "application/vnd.ms-fontobject"
  • "application/xhtml+xml"
  • "application/xml"
  • "application/xml+rss"
  • "application/x-font-opentype"
  • "application/x-font-truetype"
  • "application/x-font-ttf"
  • "application/x-httpd-cgi"
  • "application/x-mpegurl"
  • "application/x-opentype"
  • "application/x-otf"
  • "application/x-perl"
  • "application/x-ttf"
  • "application/x-javascript"
  • "font/eot"
  • "font/ttf"
  • "font/otf"
  • "font/opentype"
  • "image/svg+xml"
  • "text/css"
  • "text/csv"
  • "text/html"
  • "text/javascript"
  • "text/js", "text/plain"
  • "text/richtext"
  • "text/tab-separated-values"
  • "text/xml"
  • "text/x-script"
  • "text/x-component"
  • "text/x-java-source"

此外，文件大小必须介于 1 KB 与 8 MB 之间（不含首尾）。

这些配置文件支持以下压缩编码：

如果请求同时支持 gzip 和 Brotli 压缩，则 Brotli 压缩优先。

如果对资产的请求指定进行压缩，但该请求导致缓存缺失，则 Azure Front Door（经典版）将直接在 POP 服务器上压缩资产。 此后，将从缓存提供压缩的文件。 返回的结果项会带有 Transfer-Encoding: chunked 响应标头。

如果源使用分块传输编码 (CTE) 将数据发送到 Azure Front Door POP，则不支持压缩。

注意

范围请求可以压缩成不同的大小。 Azure Front Door 要求任何 GET HTTP 请求的 content-length 值都相同。 如果客户端发送带有 Accept-Encoding 标头的字节范围请求导致源以不同的内容长度响应，则 Azure Front Door 将返回 503 错误。 可以在源上禁用压缩，也可以创建规则引擎规则以从字节范围请求的请求中移除 Accept-Encoding 标头。

查询字符串行为

借助 Azure Front Door，可控制如何对包含查询字符串的 Web 请求缓存文件。

在包含查询字符串的 Web 请求中，查询字符串是问号 (?) 后出现的请求部分。 查询字符串可以包含一个或多个键值对，其中字段名称和其值由等号 (=) 分隔。 每个键值对由与号 (&) 分隔。

例如，URL http://www.contoso.com/content.mov?field1=value1&field2=value2 包含两个查询字符串：

  • field1，值为 value1。
  • field2，值为 value2。

如果请求的查询字符串中有多个键值对，其顺序并不重要。

配置高速缓存时，指定高速缓存应如何处理查询字符串。 支持以下行为：

  • 忽略查询字符串：在此模式下，Azure Front Door 将来自客户端的查询字符串传递到第一个请求上的源并缓存该资产。 针对从 Front Door 环境提供的资产的后续请求都将忽略查询字符串，直到所缓存的资产过期。

  • 使用查询字符串：在此模式下，包含唯一 URL 的每个请求（包括查询字符串）将视为具有其自己的缓存的唯一资产。 例如，源对 www.example.ashx?q=test1 的请求做出的响应将缓存在 Front Door 环境中，并为具有同一查询字符串的后续缓存返回该响应。 www.example.ashx?q=test2 的请求将作为具有其自己的生存时间设置的单独资产来缓存。

    查询字符串参数的顺序并不重要。 例如，如果 Azure Front Door 环境包含 URL www.example.ashx?q=test1&r=test2 的缓存响应，则也会从缓存中提供对 www.example.ashx?r=test2&q=test1 的请求。

  • 忽略指定的查询字符串和包含指定的查询字符串：在此模式下，可以将 Azure Front Door 配置为在生成缓存键时包括或排除指定的参数。

    例如，假设默认缓存键为 /foo/image/asset.html，并且向 URL https://contoso.com/foo/image/asset.html?language=EN&userid=100&sessionid=200 发出请求。 如果存在要排除 userid 查询字符串参数的规则引擎规则，则查询字符串缓存键将为 /foo/image/asset.html?language=EN&sessionid=200。

在 Front Door 路由上配置查询字符串行为。

缓存清除

请参阅 Azure Front Door 中的缓存清除，了解如何配置缓存清除。

直到资产的生存时间 (TTL) 到期之前，Azure Front Door 将一直对资产进行缓存。 每当客户端请求的资产的 TTL 已过期时，Front Door 环境会检索新的更新后资产副本以提供请求，然后存储已刷新的缓存。

确保用户始终获取资产的最新副本的最佳做法是针对每次更新将资产版本化，并将其发布为新 URL。 Front Door 将立即检索用于下一个客户端请求的新资产。 有时候可能希望从所有边缘节点清除缓存的内容，并强制其全部检索新的已更新资产。 原因可能是 Web 应用程序的更新，也可能是快速更新包含错误信息的资产。

缓存清除按钮和页面的屏幕截图。

选择要从边缘节点清除的资产。 要清除所有资产，请选择“全部清除”。 否则，在“路径”中，输入要清除的每个资产的路径。

要清除的路径列表中支持以下格式：

  • 单一路径清除：通过指定资产的完整路径（不带协议和域）并包含文件扩展名（例如 /pictures/strasbourg.png）来清除单个资产；
  • 通配符清除：星号 (*) 可用作通配符。 清除路径中带有 /* 的终结点下的所有文件夹、子文件夹和文件，或者通过指定后跟 /* 的文件夹（例如 /pictures/*），清除特定文件夹下的所有子文件夹和文件。
  • 根域清除：清除路径中具有“/”的终结点的根。

注意

清除通配符域：按照本部分中所述指定用于清除的缓存路径并不适用于与 Front Door 关联的任何通配符域。 目前，我们不支持直接清除通配符域。 可以通过指定特定子域和清除路径来清除特定子域中的路径。 例如，如果我的 Front Door 有 *.contoso.com，我可以输入 foo.contoso.com/path/* 来清除子域 foo.contoso.com 的资产。 目前，在清除内容路径中指定主机名时仅限于通配符域的子域（如果适用）。

Front Door 的缓存清除不区分大小写。 此外，它们不区分查询字符串，这意味着清除 URL 时将一并清除其查询字符串的所有变体。

缓存到期

按下列标题顺序来确定项目在缓存中的存储时间：

  1. Cache-Control: s-maxage=<seconds>
  2. Cache-Control: max-age=<seconds>
  3. Expires: <http-date>

一些 Cache-Control 响应标头值指示了响应不可缓存。 这些值包括 private、no-cache 和 no-store。 Front Door 遵循这些标头值，并且不会缓存响应，即使你使用规则引擎替代缓存行为也是如此。

如果来自源的响应中不存在 Cache-Control 标头，则默认情况下，Front Door 会随机确定 1 到 3 天的缓存持续时间。

注意

缓存过期时间不能超过 366 天。

你可能会在 Cache-Control 响应头中看到 REVALIDATED_HIT。 这表示 Azure Front Door 中的缓存内容在提供给客户端之前已通过源服务器重新验证。 当缓存的内容已过期，但源服务器指示内容尚未更改时，可能会发生这种情况。 在这种情况下，缓存的内容将提供给客户端，并且缓存过期时间将被重置。

请求标头

启用高速缓存后，以下请求标头将不会转发到源：

  • Content-Length
  • Transfer-Encoding
  • Accept
  • Accept-Charset
  • Accept-Language

注意

除非响应包含允许缓存的 Cache-Control 指令，否则不会缓存包含授权标头的请求。 以下 Cache-Control 指令具有这样的效果：must-revalidate、public 和 s-maxage。

响应头

如果源响应是可缓存的，则会在将响应发送到客户端之前移除 Set-Cookie 标头。 如果源响应不可缓存，则 Front Door 不会删除标头。 例如，如果源响应包含具有 max-age 值的 Cache-Control 标头，则系统会向 Front Door 指示响应是可缓存的，并将删除 Set-Cookie 标头。

此外，Front Door 会将 X-Cache 标头附加到所有响应。 响应 X-Cache 标头包含以下值之一：

  • TCP_HIT 或 TCP_REMOTE_HIT：响应的前 8 MB 区块是缓存命中，并且内容由 Front Door 缓存提供。
  • TCP_MISS：响应的前 8 MB 区块是缓存失误，并且内容是从源提取的。
  • PRIVATE_NOSTORE：无法缓存请求，因为缓存控制响应头已设置为“专用”或“无存储”。
  • CONFIG_NOCACHE：将请求配置为不在 Front Door 配置文件中缓存。

日志和报告

访问日志包含每个请求的缓存状态。 此外，报表还包含有关如何在应用程序中使用 Azure Front Door 缓存的信息。

访问日志包含每个请求的缓存状态。

缓存行为和持续时间

可在“规则引擎”中配置缓存行为和持续时间。 规则引擎高速缓存配置始终替代路由配置。

  • 禁用高速缓存后，无论源响应指令是什么，Azure Front Door 都不会缓存响应内容。

  • 启用缓存后，缓存行为因规则引擎应用的缓存行为值而异：

    • 遵从源：Azure Front Door 始终遵从源响应头指令。 如果缺少源指令，Azure Front Door 会在任何位置缓存内容 1 到 3 天。
    • 始终替代：Azure Front Door 会始终替代缓存持续时间，这意味着它将缓存缓存持续时间的内容，而忽略源响应指令中的值。 仅当响应可缓存时才会应用此行为。
    • 缺少源时替代：如果源未返回缓存 TTL 值，Azure Front Door 会使用指定的缓存持续时间。 仅当响应可缓存时才会应用此行为。

注意

  • Azure Front Door 不保证内容在缓存中存储的时间。 如果缓存内容的使用频繁不高，则可能会在该内容过期之前从边缘缓存中删除它。 即使缓存数据已过期，Front Door 仍可以从缓存中提供数据。 此行为可以让站点在源脱机时保持部分可用。
  • 源可以指定使用值为“不缓存”、“专用”或“不存储”的缓存控制标头，从而不缓存特定的响应。 在从源服务器到 Azure Front Door POP 的 HTTP 响应中使用时，Azure Front Door 支持 Cache-control 指令，并遵循 RFC 7234 - 超文本传输协议 (HTTP/1.1)：缓存 (ietf.org) 中 Cache-Control 指令的缓存行为。

可以在 Front Door 设计器传递规则和规则引擎中配置缓存行为和持续时间。 规则引擎缓存配置将始终替代 Front Door 设计器传递规则配置。

  • 禁用高速缓存后，无论源响应指令是什么，Azure Front Door（经典）都不会高速缓存响应内容。

  • 启用高速缓存后，对于“使用缓存默认持续时间”的不同值，缓存行为会有所不同。

    • 当“使用缓存默认持续时间”设置为“是”时，Azure Front Door（经典版）始终遵从源响应头指令。 如果缺少源指令，Front Door 会在任何位置缓存内容 1 到 3 天。
    • 当“使用缓存默认持续时间”设置为“否”时，Azure Front Door（经典版）将始终替代“缓存持续时间”（必填字段），这意味着它将缓存缓存持续时间的内容，而忽略源响应指令中的值。

注意

  • Azure Front Door（经典版）不保证内容在缓存中存储的时间。 如果缓存内容的使用频繁不高，则可能会在该内容过期之前从边缘缓存中删除它。 即使缓存数据已过期，Azure Front Door（经典版）仍可以从缓存中提供数据。 此行为可以让站点在源脱机时保持部分可用。
  • 在 Front Door 设计器传递规则中设置的“缓存持续时间”是“最小缓存持续时间”。 如果源的缓存控制标头的 TTL 大于替代值，则此替代将不起作用。

后续步骤