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

缓存工作原理

项目
11/04/2024

重要

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

Edgio 的 Azure CDN 将于 2025 年 11 月 4 日停用。为了避免服务中断，必须在此日期之前将工作负载迁移到 Azure Front Door。有关详细信息，请参阅 Edgio 的 Azure CDN 停用常见问题解答。

本文概述了一般缓存概念以及 Azure 内容分发网络如何使用缓存来提高性能。如果想了解如何在内容分发网络终结点上自定义缓存行为，请参阅使用缓存规则控制 Azure 内容分发网络缓存行为和使用查询字符串控制 Azure 内容分发网络缓存行为。

缓存简介

缓存即在本地存储数据的过程，以便将来可以更快地访问数据请求。 Web 浏览器缓存是最常见的缓存类型中，在此类缓存中，Web 浏览器将静态数据的副本本地存储在本地硬盘上。通过使用缓存，Web 浏览器可避免多次往返服务器，而只需在本地访问相同的数据，从而节省时间和资源。缓存非常适合用于在本地管理小型静态数据，如静态图像、CSS 文件和 JavaScript 文件。

同样，内容分发网络在靠近用户的边缘服务器上使用缓存，以避免请求返回源服务器，从而减少用户延迟。与仅适用于单个用户的 Web 浏览器缓存不同，内容分发网络具有共享缓存。在内容分发网络共享缓存中，一个用户可以使用其他用户请求的文件，大大减少了向源服务器请求的次数。

无法缓存频繁更改或单个用户的唯一动态资源。不过，这些类型的资源可利用 Azure 内容分发网络上的动态站点加速 (DSA) 优化来提高性能。

可在源服务器和最终用户之间的多个级别上进行缓存：

Web 服务器：使用共享缓存（适用于多个用户）。
内容分发网络：使用共享缓存（适用于多个用户）。
Internet 服务提供商 (ISP)：使用共享缓存（适用于多个用户）。
Web 浏览器：使用专用缓存（适用于一个用户）。

通常，每个缓存管理自己的资源刷新，并在文件过期时执行验证。此行为在 HTTP 缓存规范 RFC 7234 中定义。

资源刷新

由于缓存资源可能会过期或过时（与源服务器上的相应资源相比），因此对任何缓存机制而言，控制刷新内容的时间都至关重要。为了节省时间和降低带宽消耗，不会在每次访问缓存资源时都将其与源服务器上的版本进行比较。相反，只要认为缓存资源是最新的，就会假定其为最新版本，并将其直接发送到客户端。如果缓存资源的寿命小于缓存设置定义的寿命或期限，则认为其是最新缓存资源。例如，当浏览器重载网页时，它会验证硬盘上的每个缓存资源是否为最新并加载它。如果资源不是最新的（过时），则从服务器加载最新副本。

验证

如果认为资源已过时，则要求源服务器对其进行验证，以确定缓存中的数据是否仍与源服务器上的数据相匹配。如果已在源服务器上修改了文件，缓存会更新其资源的版本。否则，如果资源为最新，将直接从缓存中传递数据，而无需首先对其进行验证。

内容分发网络缓存

缓存是内容分发网络运行方式不可或缺的一部分，用于加速传递和减少静态资产（如图像、字体和视频）的源加载。在内容分发网络缓存中，选择性地将静态资源存储在策略性服务器上，该服务器对用户而言更本地化，并具有以下优势：

由于大多数 Web 流量是静态的（例如图像、字体和视频）内容分发网络缓存通过将内容移近用户来减少数据传输的距离，从而减少网络延迟。
通过将工作卸载到内容分发网络，缓存可减少网络流量和源服务器上的加载。这样做可降低应用程序的成本和资源需求，即使在有大量用户的情况下也是如此。

与缓存在 Web 浏览器中的执行方式类似，可通过发送缓存指令标头来控制缓存在内容分发网络中的执行方式。缓存指令标头即 HTTP 标头，通常由源服务器添加。尽管大部分标头最初都旨在解决客户端浏览器中的缓存问题，但现在所有中间缓存（如内容分发网络）也会使用这些标头。

可使用两个标头来定义缓存刷新：Cache-Control 和 Expires。如果两者都存在，则 Cache-Control 为最新且优先于 Expires。还有两种用于验证的标头类型（称为验证程序）：ETag 和 Last-Modified。如果两者均已定义，则 ETag 为最新且优先于 Last-Modified。

缓存指令标头

重要

默认情况下，针对 DSA 进行了优化的 Azure 内容分发网络终结点将忽略缓存指令标头，绕过缓存。对于“Edgio 提供的标准 Azure CDN”配置文件，可以使用内容分发网络缓存规则启用缓存，以调整 Azure 内容分发网络终结点处理这些标头的方式。仅对于“Edgio 提供的 Azure CDN 高级版”配置文件，可以使用规则引擎来启用缓存。

Azure 内容分发网络支持以下 HTTP 缓存指令标头，它们定义了缓存持续时间和缓存共享。

Cache-Control：

在 HTTP 1.1 中引入，用于为 Web 发布者提供对其内容的更多控制权，并解决 Expires 标头的局限性。
如果同时定义了 Expires 和 Cache-Control 标头，则将替代前一个标头。
在从客户端发往内容分发网络 POP 的 HTTP 请求中使用时，Cache-Control 会被所有 Azure 内容分发网络配置文件默认忽略。
当用于从源服务器到内容分发网络 POP 的 HTTP 响应时：
- Edgio 提供的 Azure CDN 标准版/高级版和 Microsoft 提供的 Azure CDN 标准版支持所有 Cache-Control 指令。
- Edgio 提供的 Azure CDN 标准版/高级版和 Microsoft 提供的 Azure CDN 标准版遵循 RFC 7234 - 超文本传输协议 (HTTP/1.1)：缓存 (ietf.org) 中 Cache-Control 指令的缓存行为。

Expires：

HTTP 1.0 中引入的旧标头支持后向兼容性。
使用基于日期的过期时间，精确到秒。
类似于 Cache-Control: max-age。
当 Cache-Control 不存在时使用。

Pragma：

默认情况下，Azure 内容分发网络不支持。
HTTP 1.0 中引入的旧标头支持后向兼容性。
用作具有以下指令的客户端请求标头：no-cache。此指令指示服务器提供新的资源版本。
Pragma: no-cache 等效于 Cache-Control: no-cache。

验证程序

当缓存过时时，使用 HTTP 缓存验证程序将文件的缓存版本与源服务器上的版本进行比较。 Edgio 提供的 Azure CDN 标准版/高级版默认支持 ETag 和 Last-Modified 验证程序，而 Microsoft 提供的 Azure CDN 标准版仅支持 Last-Modified。

ETag：

Edgio 提供的 Azure CDN 标准版/高级版默认支持 ETag，而 Microsoft 提供的 Azure CDN 标准版则不支持它。
ETag 为每个文件和文件版本定义唯一字符串。例如，ETag: "17f0ddd99ed5bbe4edffdd6496d7131f"。
在 HTTP 1.1 中引入，并且比 Last-Modified 更新。当很难确定上次修改日期时，会非常有用。
支持强验证和弱验证，不过，Azure 内容分发网络仅支持强验证。对于强验证，两种资源表示形式的每个字节都必须相同。
缓存通过在请求中发送带有一个或多个 ETag 验证程序的 If-None-Match 标头来验证使用 ETag 的文件。例如 If-None-Match: "17f0ddd99ed5bbe4edffdd6496d7131f"。如果服务器的版本与列表中的 ETag 验证程序相匹配，则在其响应中发送状态代码 304（未修改）。如果版本不同，则服务器响应状态代码 200（确定）和更新后的资源。

Last-Modified：

如果 ETag 不是 HTTP 响应的一部分，则使用 Last-Modified（仅限 Edgio 提供的 Azure CDN 标准版/高级版）。
指定源服务器已确定上次修改资源的日期和时间。例如 Last-Modified: Thu, 19 Oct 2017 09:28:00 GMT。
对于大于 8 MB 的内容，源后端服务器应为每个资产维护一致的 Last-Modified 时间戳。从后端服务器返回不一致的 Last-Modified 时间会导致验证器不匹配错误并导致 HTTP 5XX 失败。 Azure 存储可能不支持跨副本的一致 Last-Modified 时间戳，这可能会导致类似的验证器不匹配错误。
缓存通过在请求中发送带有日期和时间的 If-Modified-Since 标头来验证使用 Last-Modified 的文件。源服务器将该日期与最新资源的 Last-Modified 标头进行比较。如果自指定时间以来未修改该资源，则服务器在其响应中返回状态代码 304（未修改）。如果已修改该资源，则服务器返回状态代码 200（确定）和更新后的资源。

确定可以缓存哪些文件

并非所有资源均可缓存。下表根据 HTTP 响应的类型显示了可缓存的资源。无法缓存不满足所有条件的 HTTP 响应所提供的资源。可使用规则引擎自定义上述某些条件（仅限 Edgio 提供的 Azure CDN 高级版）。

	Microsoft 的 Azure 内容分发网络	Edgio 的 Azure 内容分发网络
HTTP 状态代码	200、203、206、300、301、410、416	200
HTTP 方法	GET、HEAD	GET
文件大小限制	300 GB	300 GB

若要在资源上使用 Microsoft 推出的 Azure CDN 标准版缓存，源服务器必须支持任何 HEAD 和 GET HTTP 请求，且资产的任何 HEAD 和 GET HTTP 响应的 content-length 值必须相同。对于 HEAD 请求，源服务器必须支持 HEAD 请求，且必须使用接收 GET 请求时所使用的标头进行响应。

注意

不会缓存包含授权标头的请求。

默认缓存行为

下表介绍了 Azure 内容分发网络产品的默认缓存行为及其优化。

	Microsoft：常规 Web 分发	Edgio：常规 Web 传送	Edgio：DSA
优先处理源	是	是	否
内容分发网络缓存持续时间	两天	七天	无

优先处理源：指定是否优先处理支持的缓存指令标头（如果它们存在于源服务器的 HTTP 响应中）。

CDN 缓存持续时间：指定在 Azure 内容分发网络上可缓存资源的时间。然而，如果“优先处理源”为“是”，并且源服务器的 HTTP 响应包括缓存指令标头 Expires 或 Cache-Control: max-age，则 Azure 内容分发网络将改用由标头指定的持续时间值。

注意

Azure 内容分发网络不保证对象在缓存中存储的最短时间。如果缓存内容的请求频率不高，则这些内容可能会在过期之前被逐出内容分发网络缓存，以便为请求频率更高的内容腾出空间。

后续步骤

若要了解如何通过缓存规则自定义和替代内容分发网络上的默认缓存行为，请参阅使用缓存规则控制 Azure 内容分发网络缓存行为。
若要了解如何使用查询字符串控制缓存行为，请参阅使用查询字符串控制 Azure 内容分发网络缓存行为。

通过