共用方式為

Azure Front Door 的缓存

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

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

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

Warning

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

请求方法

只有使用 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 不会缓存响应，而且你可能会看到不一致的行为。

    Tip

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

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

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

文件压缩

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

查询字符串行为

借助 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 中的缓存清除，了解如何配置缓存清除。

缓存过期

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

  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 天的缓存持续时间。

Note

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

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

请求标头

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

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

Note

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

响应标头

如果源响应是可缓存的，则会在将响应发送到客户端之前移除 Set-Cookie 标头。 如果源响应不可缓存，则 Front Door 不会删除标头。 例如，如果源响应包含具有 Cache-Control 值的 max-age 标头，则系统会向 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：无法缓存请求，因为 Cache-Control 响应标头设置为 专用 或 无存储。
  • CONFIG_NOCACHE：将请求配置为不在 Front Door 配置文件中缓存。

Note

启用缓存时，Azure Front Door 会去掉空文件的头部。 若要继续将此标头发送到客户端，请使用 Azure Front Door 规则引擎（操作 - 修改响应标头，操作员 - 覆盖，标头名称 - Content-Type）手动覆盖此类文件。 还可以禁用空文件的缓存，但不建议使用此方法，因为它会增加源上的负载，并可能会影响性能。

缓存行为和持续时间

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

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

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

    • 尊重源：Azure Front Door 始终遵循源响应头指令。 如果缺少源指令，Azure Front Door 会在任何位置缓存内容 1 到 3 天。
    • 始终覆盖：Azure Front Door 始终以缓存持续时间覆盖，即缓存内容的时间持续为缓存持续时间，忽略来自源响应指令的值。 仅当响应可缓存时才会应用此行为。
    • 缺少源时替代：如果源未返回缓存 TTL 值，Azure Front Door 会使用指定的缓存持续时间。 仅当响应可缓存时才会应用此行为。

Note

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

后续步骤