媒体 CDN 使用 Google 的全球边缘缓存基础架构，可缓存内容并减少 源基础架构
您可以控制为每个路由缓存内容的方式。这样，您就可以根据内容类型、客户端请求属性和新鲜度要求优化行为。
可缓存性
以下部分介绍了媒体 CDN 缓存的响应 以及如何改进缓存分流。
默认缓存行为
默认情况下，以下与缓存相关的设置适用于每个边缘缓存服务：
CACHE_ALL_STATIC的默认缓存模式：- 遵循来源缓存指令（例如
Cache-Control或Expires），但不超过可配置的最大 TTL。 - 如果没有源缓存指令，则自动缓存静态媒体类型，默认 TTL 为 3600 秒。
- 缓存 HTTP 200 和 206 状态代码（未启用否定缓存）。
- 遵循来源缓存指令（例如
不缓存具有
no-store或privatecache-control 的响应 指令或无法缓存的内容。
除非明确配置缓存，否则系统不会缓存非静态内容或缺少有效缓存指令的响应。如需了解如何替换 请参阅有关缓存模式的文档。
默认行为等效于以下 cdnPolicy。如果未配置显式 cdnPolicy，路由的行为就像具有以下配置一样：
cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 3600s cacheKeyPolicy: includeProtocol: false excludeHost: false excludeQueryString: false signedRequestMode: DISABLED negativeCaching: false
可缓存的响应
可缓存响应是一种可供 Media CDN 存储并快速检索，因而有助于缩短加载时间的 HTTP 响应。并非所有 HTTP 请求 可缓存的响应。
您可以为每个路由配置缓存模式以替换此行为（例如，使用 CACHE_ALL_STATIC 缓存模式缓存常见的媒体类型），即使源站未在响应中设置缓存控制指令也是如此。
符合不可缓存的响应中定义的条件的请求和响应会取代可缓存性。
下表介绍了缓存特定 HTTP 响应的要求。GET 和 HEAD 响应都必须遵循这些要求。
| HTTP 属性 | 使用要求 |
|---|---|
| 状态代码 | 响应状态代码必须是 200、203、206、300、301、302、 307、308、400、403、404、405、410、451、500、501、502、503 或 504。 |
| HTTP 方法 | “GET”和“HEAD” |
| 请求标头 | 系统会忽略大多数缓存请求指令。如需了解详情，请参阅缓存控制指令。 |
| 响应标头 | 包含有效的 HTTP 缓存
指令，例如 具有缓存该内容的缓存模式，或者具有日期为未来的 |
| 响应大小 | 最多 100 GiB。 |
HTTP Age 标头已设置
基于媒体 CDN 首次缓存响应的时间，
表示自对象以
源屏蔽位置。如果您的源生成 Age 响应标头，请使用 FORCE_CACHE_ALL 缓存模式，以防止在 Age 超出缓存 TTL 时重新验证。
如需详细了解媒体 CDN 如何解读 HTTP 缓存 指令，请参阅缓存控制指令。
源要求
如需允许媒体 CDN 缓存大于 1 MiB 的源站响应，源站必须在 HEAD 和 GET 请求的响应标头中包含以下内容，除非另有说明：
Last-Modified或ETagHTTP 响应标头（验证器）。- 有效的 HTTP
Date标头。 - 有效的
Content-Length标头。 Content-Range响应标头，用于响应Range GET请求。Content-Range标头必须具有采用bytes x-y/z格式的有效值（其中z是对象大小）。
默认的来源协议为 HTTP/2。如果您的源仅支持 HTTP/1.1 则可以为每个源明确设置协议字段。
无法缓存的响应
下表详细说明了阻止 响应的缓存。可缓存但与“不可缓存”条件匹配的响应不会被缓存。
| HTTP 属性 | 要求 |
|---|---|
| 状态代码 | 除定义为可缓存的状态代码之外的状态代码，例如 HTTP 401、HTTP 412 或 HTTP 505。 这些状态代码通常代表面向客户的问题，而非来源状态。缓存这些响应可能会导致“缓存中毒”情形，即为所有用户缓存用户触发的“错误”响应。 |
| 请求标头 | 对于包含 请求中的 |
| 响应标头 | 具有 具有 在 |
| 响应大小 | 大于 100 GiB。 |
这些规则除了已配置的缓存模式之外，还适用。 具体而言：
- 配置
CACHE_ALL_STATIC缓存模式后，系统只会缓存被视为静态内容的响应，或响应标头中包含有效缓存指令的响应。其他响应会按原样代理。 FORCE_CACHE_ALL缓存模式会无条件缓存所有响应，但须遵守前面所述的不可缓存性要求。USE_ORIGIN_HEADERS缓存模式要求响应不仅具有可缓存的状态代码，还必须在响应标头中设置有效的缓存指令。
注意：
- 未缓存的响应没有其缓存控制指令，或者 其他标头会发生更改，并按原样代理。
- 响应的
Cache-Control和Expires标头可以合并到单个Cache-Control字段中。例如，如果响应中Cache-Control: public和Cache-Control: max-age=100分别位于不同行，则会合并为Cache-Control: public,max-age=100。 - 从结算角度来看，不可缓存的响应（永远不会缓存的响应）不会计为
Cache Egress。
使用缓存模式
通过缓存模式，您可以配置媒体 CDN 在什么情况下应遵守 源缓存指令、缓存静态媒体类型以及缓存所有响应 而不会考虑是否设置了任何指令
缓存模式在路由级别配置，与 TTL 替换项结合使用。 您可以按主机、路径、查询参数和 标头（任何可匹配的请求参数）。
- 默认情况下，媒体 CDN 使用
CACHE_ALL_STATIC缓存模式， ，它会将常见静态媒体类型自动缓存 1 小时（3600 秒），同时优先处理由源站指定的所有缓存指令 （针对可缓存的响应）。 - 您可以通过在路由上设置
cdnPolicy.defaultTtl字段，来增加或减少应用于未设置显式缓存 TTL（max-age或s-maxage指令）的响应的缓存 TTL。 - 为防止将非成功响应缓存的时间超出预期，系统不会根据其
Content-Type（MIME 类型）缓存非 2xx（非成功）状态代码，也不会应用默认的 TTL。
可用的缓存模式，在各模式的 cdnPolicy.cacheMode 上设置
如下表所示。
| 缓存模式 | 行为 |
|---|---|
USE_ORIGIN_HEADERS |
要求源站响应设置有效的缓存指令和有效的缓存标头。如需查看完整的要求列表，请参阅可缓存的响应。 |
CACHE_ALL_STATIC |
自动缓存包含静态内容的成功响应，除非它们包含 静态内容包括视频、音频、图片和常见的网络资产，
由 |
FORCE_CACHE_ALL |
无条件缓存成功响应，并跳过源站设置的任何缓存指令。 请确保在配置了此模式的情况下，不要为每个用户提供专用内容（例如动态 HTML 或 API 响应）。 |
| BYPASS_CACHE | 与配置了此缓存模式的路由匹配的任何请求都会绕过 即使存在与该缓存键匹配的已缓存对象也是如此。 由于媒体 CDN 支持媒体 CDN，因此我们建议仅将其用于调试 设计为全球级缓存基础设施，而非通用 代理 |
静态内容 MIME 类型
借助 CACHE_ALL_STATIC 缓存模式，Media CDN 可以根据 Content-Type HTTP 响应标头中返回的 MIME 类型，自动缓存视频、音频、图片和常见 Web 资源等常见静态内容。不过，无论媒体类型如何
会优先处理源站中的任何显式 Cache-Control 或 Expires 标头
响应。
下表列出了可使用 CACHE_ALL_STATIC 缓存模式自动缓存的 MIME 类型。
如果响应没有 Content-Type，则系统不会自动缓存响应
具有与以下值匹配的值的响应标头。您必须确保
该响应设置了有效的缓存指令，或者
您必须使用 FORCE_CACHE_ALL 缓存模式无条件缓存
响应。
| 类别 | MIME 类型 |
|---|---|
| Web 资源 | text/css text/ecmascript text/javascript application/javascript |
| 字体 | 任何与“font/*”匹配的内容类型 |
| 图片 | 任何与“image/*”匹配的内容类型 |
| 视频 | 任何与“video/*”匹配的内容类型 |
| 音频 | 任何与“audio/*”匹配的内容类型 |
| 格式化文档类型 | application/pdf and application/postscript |
请注意以下几点：
- 源站的 Web 服务器软件必须为以下项设置
Content-Type： 。许多网络服务器会自动设置Content-Type标头，包括 NGINX、Varnish 和 Apache。 - Cloud Storage 设置
Content-Type标头 上传时自动使用 Google Cloud 控制台或 gcloud CLI 来上传内容。 - 如果响应可根据其 MIME 类型缓存，但
Cache-Control响应指令为private或no-store，或标头为Set-Cookie，则不会缓存该响应。
配置缓存 TTL
借助存留时间 (TTL) 覆盖，您可以为缓存内容设置默认 TTL 值
并替换 max-age 和 s-maxage 缓存控件中设置的 TTL 值
指令（或 Expires 标头）。
TTL（无论是通过替换项还是通过缓存指令设置的）都是乐观的。不常访问或不受欢迎的内容可能会在达到 TTL 之前从缓存中逐出。
下表显示了三种 TTL 设置。
| 设置 | 默认 | 下限 | 最大值 | 说明 | 适用的缓存模式 |
|---|---|---|---|---|---|
| Default TTL | 1 小时 （3600 秒） |
0 秒 | 1 年 （31,536,000 秒） |
当源站未指定 如果源站指定了 使用 |
|
| Max TTL | 1 天 （86400 秒） |
0 秒 | 1 年 （31,536,000 秒） |
对于可缓存的响应，允许的最大 TTL。大于此值的值将限制为 maxTtl 的值。
|
CACHE_ALL_STATIC |
| Client TTL | 默认情况下未设置。 | 0 秒 | 1 天 （86400 秒） |
对于可缓存的响应，下游（面向客户端）响应中允许的最大 TTL（如果此值需要与其他 TTL 值不同）。 |
|
如果将任何 TTL 值设置为零 (0 秒)，系统会在提供响应之前对每个请求与源站重新进行验证，如果设置过宽，则会增加源站的负载。
当缓存模式设为 Use Origin Headers 时，无法设置 TTL 设置
配置，因为媒体 CDN 依赖源站来驱动
行为
注意：
- 最大 TTL 的值必须始终大于（或等于） 默认 TTL。
- 客户端 TTL 的值始终必须小于（或等于）最大 TTL 的值。
- 当媒体 CDN 替换源 TTL 值时，
Cache-Control标头也会反映该值。 - 如果源站设置了
Expires标头和媒体 CDN 会替换有效 TTL（基于时间戳）、Expires标头 在下游响应中被替换为Cache-Control标头， 客户端。
负缓存
负缓存定义了非成功 HTTP 状态代码（ 由媒体 CDN 缓存。
这样，您就可以将重定向 (HTTP 301 和 308) 和未找到 (HTTP 404) 等错误响应缓存在离用户更近的位置，并在响应不太可能发生变化且可以缓存的情况下更广泛地减少源端负载。
默认情况下，负缓存处于停用状态。下表显示了启用否定缓存且未使用 negativeCachingPolicy 时，每种状态代码的默认值。
| 状态代码 | 原因短语 | TTL |
|---|---|---|
| HTTP 300 | Multiple Choices | 10 分钟 |
| HTTP 301 和 HTTP 308 | Permanent Redirect | 10 分钟 |
| HTTP 404 | 未找到 | 120 秒 |
| HTTP 405 | 找不到方法 | 60 秒 |
| HTTP 410 | Gone | 120 秒 |
| HTTP 451 | 由于法律原因而无法使用 | 120 秒 |
| HTTP 501 | Not Implemented | 60 秒 |
默认的负缓存代码集与启发式可缓存的 请参阅 HTTP RFC 9110、 但以下情况除外：
- 不支持使用 HTTP 代码 414（URI 过长）进行缓存，以避免缓存 投毒
- 缓存支持使用 HTTP 代码 451（法律原因不可用），因为 具体说明 HTTP RFC 7725。
如果您需要自行为每个状态代码配置 TTL，并覆盖默认值
您可以配置一个 cdnPolicy.negativeCachingPolicy。这样，您就可以
为媒体 CDN 允许的任何状态代码设置 TTL：
300、301、302、307、308、400、403、404、405、410、451、500、501、502、503 和
504。
例如，要为 HTTP 404（未找到）响应设置 5 秒的较短 TTL，请执行以下操作： 并将 HTTP 405（不允许方法）响应的 TTL 设置为 10 秒，请使用 并遵循 YAML 定义：
cdnPolicy: negativeCaching: true negativeCachingPolicy: "404": 5s "405": 10s # other status codes to apply TTLs for
为防止缓存中毒，我们不建议为状态代码 400（请求错误）或 403（禁止）启用缓存。请确保您的源服务器
通过仅检查请求的组成部分返回任一代码
包含在缓存键中。例如，如果源服务器在缺少正确的 Authorization 标头的情况下返回 403 错误响应，就可能会发生缓存中毒。在这种情况下，缓存 403 错误响应会导致 Media CDN 向所有后续请求提供 403 错误响应，直到 TTL 到期为止，即使请求包含正确的 Authorization 标头也是如此。
如需停用负缓存，请执行以下操作：
- 如需停用默认的负缓存行为，请对路线设置
cdnPolicy.negativeCaching: false。请注意，源响应 具有有效缓存指令和可缓存状态 代码仍将缓存。 - 可以防止对特定状态代码进行负缓存，同时仍然遵循
源缓存指令，请忽略状态代码
（
cdnPolicy.negativeCachingPolicy[].code）位于您的“negativeCachingPolicy”中 定义。 - 若要针对特定状态明确忽略源缓存指令
代码，如果是这样，请将
cdnPolicy.negativeCachingPolicy[].ttl设置为0（零） 状态代码。
注意：
- 如果对路线启用了
negativeCaching，并且响应定义了 有效缓存指令、 响应。 - 如果您配置了显式
negativeCachingPolicy，并且存在 TTL 则政策中定义的 TTL 始终为 。 - 由
negativeCachingPolicy设置的 TTL 最大值为 1800 秒 （30 分钟），但系统将遵循 TTL 较高的源缓存指令。 - 如果缓存模式配置为
FORCE_CACHE_ALL，源站 指令在所有情况下都会被忽略。
缓存控制指令
媒体 CDN 的行为：
Cache-Control 指令
此处定义了
如果指令不适用于请求或响应（例如 only-if-cached，这是一个仅限客户端的指令），则该列中会标记“不适用”。
| 指令 | 请求 | 响应 |
|---|---|---|
no-cache |
系统会忽略 no-cache 请求指令，以防止客户端可能向来源发起或强制重新验证。 |
包含 您可以根据路由将此设置替换为 |
no-store |
使用 no-store 的请求不会缓存对请求的响应。 |
系统不会缓存包含 您可以根据路由将此设置替换为 |
public |
不适用 | 如果使用了 使用 |
private |
不适用 | 具有 您可以根据路由将此设置替换为 使用 |
max-age=SECONDS |
max-age 请求指令会被忽略。缓存的响应是指 就返回了此标头，就像请求中未包含此标头一样。 | 具有 max-age 指令的响应缓存时间长达定义的 SECONDS。 |
s-maxage=SECONDS |
不适用 | 具有 如果同时存在 请注意， |
min-fresh=SECONDS |
系统会忽略 min-fresh 请求指令。返回缓存的响应就像此标头未包含在请求中一样。 |
不适用 |
max-stale=SECONDS |
系统会返回缓存的响应，就好像此标头未包含在 请求。 |
不适用 |
stale-while-revalidate=SECONDS |
不适用 | 无影响。此响应会传递给客户端。 |
stale-if-error=SECONDS |
系统会忽略 stale-if-error 请求指令。缓存的
则会返回此标头，就像请求中未包含此标头一样。 |
无影响。此响应会传递给客户端。 |
must-revalidate |
不适用 | 使用 |
proxy-revalidate |
不适用 | 具有 |
immutable |
不适用 | 无影响。此响应会传递给客户端。 |
no-transform |
不适用 | 媒体 CDN 不会应用任何转换。 |
only-if-cached |
系统会忽略 only-if-cached 请求指令。缓存的
则会返回此标头，就像请求中未包含此标头一样。 |
不适用 |
如果可能，媒体 CDN 符合 RFC 规范（HTTP RFC 7234），但偏向于 优化缓存分流，并最大限度地减少客户端可能对 命中率和总体来源负载
对于使用 HTTP/1.1 Expires 标头的响应：
Expires标头的值必须是 RFC 7231 中定义的有效 HTTP 日期- 过去的日期值、无效日期或值
0表示 该内容已过期，需要重新验证。 - 如果
Cache-Control，媒体 CDN 会忽略Expires标头 标头。
如果响应中存在 HTTP/1.0 Pragma 标头，则 Cloud CDN 会忽略该标头，并按原样将其传递给客户端。
缓存键
您可以考虑请求的唯一标识符，并移除请求之间可能经常更改的组件，从而减少 Media CDN 需要与您的源站联系的次数。这组请求组件通常称为“缓存键”。
以下部分介绍了如何配置缓存键。
缓存键组成部分
缓存键是缓存对象引用的一组请求参数（例如主机、路径和查询参数）。
默认情况下，边缘缓存服务的缓存键包括请求主机、路径 和查询参数，并且限定为 EdgeCacheService.
| 组件 | 是否默认包含？ | 详细信息 |
|---|---|---|
| 协议 | 否 | 通过 HTTP 和 HTTPS 发送请求会引用同一个缓存对象。 如果您想针对 http: 和 https: 请求返回不同的响应，请在关联的路线上将 |
| 主机 | 是 | 不同的主机不会引用相同的缓存对象。 如果您有多个主机名指向同一个 EdgeCacheService，并且
投放相同的内容
|
| 路径 | 是 | 始终包含在缓存键中，无法删除。路径是 缓存中对象的最小表示法。 |
| 查询参数 | 是 | 如果查询参数无法区分不同的响应，
将 如果缓存键中只能包含一些查询参数，则将
|
| 标题 | 否 | 将 指定多个标头，这些标头可以组合成 值（例如，组合的标头值用于标识单个用户） 显著降低缓存命中率 可能会导致逐出率提高并性能降低。 |
| Cookie | 否 | 使用名称设置 指定多个 Cookie，它们的 值（例如，组合的 Cookie 值用于标识单个用户） 显著降低缓存命中率 可能会导致逐出率提高并性能降低。 |
请注意以下几点：
- 缓存键不会附加到已配置的来源，因此您可以更新来源配置（或完全替换来源），而无需担心“刷新”缓存（例如，在提供商之间迁移来源存储空间时）。
- 缓存键受 EdgeCacheService 的限制。不同的 EdgeCacheService 设置不同的缓存命名空间，从而防止您不小心缓存了 测试对象之间 主机、路径或其他缓存关键组件将匹配。删除 EdgeCacheService 会有效地使该服务的所有缓存对象失效。
- 缓存键的范围不限定为单个路由。多个路由可能引用相同的缓存键，尤其是当这些路由在缓存键中不包含的组件（例如请求标头或排除的参数）上匹配时。如果您希望多个路由共享相同的缓存，但返回不同的响应标头或 CORS 配置，这会非常有用。
- 缓存键不包含网址重写配置。例如，缓存键基于 而不是在最终的“重写”后请求。
- 在路由上配置已签名请求时，缓存键中不会包含已签名属性。该请求将按照（已签名）
查询参数或路径组成部分，以
edge-cache-token开头和 结尾的网址不属于网址的一部分。
包含或排除查询参数
您可以通过将参数名称添加到给定路线上的 includedQueryParameters 或 excludedQueryParameters 缓存键配置中，从缓存键中包含或排除特定查询参数。
例如，若要添加 contentID 和 country 查询参数并
忽略缓存键中的其他所有值：
cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 86400s cacheKeyPolicy: includedQueryParameters: ["contentID", "country"]
请务必加入唯一标识内容的查询参数，并 排除那些没有效果的关键字例如，排除分析查询参数 播放会话 ID 或仅对客户端独有的其他参数。 添加不必要的查询参数可能会降低缓存命中率。
或者，您也可以选择要从缓存键中排除哪些参数，而不是指定要将哪些参数包含在缓存键中。例如，如需从缓存键中排除特定于客户端的播放 ID 和时间戳信息，请配置以下内容：
cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 86400s cacheKeyPolicy: excludedQueryParameters: ["playback-id", "timestamp"]
对于给定路线，您可以指定 includedQueryParameters 或 excludedQueryParameters 中的一个。
如果从不使用查询参数来跨请求唯一标识内容，
您可以从路线的缓存键中删除所有查询参数。为此，请将 excludeQueryString 设置为 true，如下所示：
cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 3600s cacheKeyPolicy: excludeQueryString: true
如果路由上启用了签名请求， 用于签名的查询参数不包含在查询字符串中， 如果包含，则会忽略。在缓存键中包含签名参数 有效使每个用户请求具有唯一性，并要求每个请求 从源站传送的内容。
查询参数排序
默认情况下，系统会对查询参数（查询字符串）进行排序，以减少缓存命中 因为客户端可能会重新排序或以其他方式请求相同的缓存费率 对象具有不同的查询参数顺序。
例如，查询参数 b=world&a=hello&z=zulu&p=paris 和
“p=paris&a=hello&z=zulu&b=world”已按“a=hello&b=world&p=paris&z=zulu”排序
在派生缓存键之前。这样，这两个请求就可以映射到同一缓存对象，从而避免对源的多余请求（以及源的多余响应）。
如果某个查询参数键有多个实例，且每个实例的值各不相同，则系统会按参数的完整值对其进行排序（例如，a=hello 在 a=world 之前排序）。无法停用排序。
添加标头
标头名称不区分大小写，并且按照 媒体 CDN。
缓存键中不能包含以下标头：
- 以
access-control-开头的任何标头 - 以
sec-fetch-开头的任何标头 - 以
x-amz-开头的任何标头 - 以
x-goog-开头的任何标头 - 以
x-media-cdn-开头的任何标头 accept-encodingacceptauthorizationcdn-loopconnectioncontent-md5content-typecookiedateforwardedfromhostif-matchif-modified-sinceif-none-matchoriginproxy-authorizationrangerefererreferreruser-agentwant-digestx-csrf-tokenx-csrftokenx-forwarded-for
如需在缓存键中添加 HTTP 方法，请使用特殊的标头名称 :method。
包含 Cookie
Cookie 名称区分大小写。
缓存键中不能使用以大写或小写字母 edge-cache- 开头的 Cookie。
重新验证、逐出和到期
内容分发网络（包括媒体 CDN）的运作方式是将最热门的内容缓存在尽可能靠近用户的位置。
媒体 CDN 的大量存储空间以及源站防护功能可减少甚至无需驱逐不受欢迎的内容。每天被访问次数较少的内容最终可能会被逐出。
- 达到配置的 TTL 的缓存响应可能
会立即被逐出对于热门内容，媒体 CDN
通过发出一个
向源发出
HEAD请求以确认标头是否已 未更改。在某些情况下， 使用以下任一或全部请求标头向源发送请求：If-None-Match和If-Modified-Since。在此示例中 配置正确的源应返回 HTTP 304（未修改） 响应，不包含正文字节（如果缓存的副本 该响应。 - 设置
max-age或s-maxage缓存的响应 指令或使用TTL 替换，以指定较高的 TTL 值（例如 30 天）可能不会被存储在缓存中以完成 TTL。不保证 对象在缓存中可在整个有效期内存储。 特别是在访问频率较低的情况下。
如果您发现驱逐率很高，则应确保已配置缓存键以排除无法唯一标识响应的参数。
其他注意事项
以下注意事项可能也适用于缓存。
Vary 标头
Vary 标头表明响应会根据客户端的
请求标头。如果响应中存在 Vary 标头，
媒体 CDN 不会对其进行缓存，除非标头指定
其中一个标头被配置为
缓存键设置或下列值之一：
- Accept：用于指示客户端接受的媒体类型
- Accept-Encoding：用于指示客户端的压缩类型 接受
- Available-Dictionary：用于提供可用字典的哈希以进行压缩
- Origin/X-Origin：通常用于跨域资源共享
- X-Goog-Allowed-Resources：支持 Google Cloud 组织限制
- Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site:：用于提取元数据请求 标头
媒体 CDN 会通过以下方式缓存响应中具有 Vary 标头的响应：
使用标头的值作为缓存键的一部分。如果响应中的 Vary 标头包含多个值，则会按字典顺序对这些值进行排序，以确保缓存键是确定性的。
媒体 CDN 可针对给定缓存键随机缓存多达 100 个变体 从缓存中逐出超出该限制的变体。如果您明确指定 使指定网址的缓存失效，或 则所有变体都会失效。
绕过缓存
您可以刻意在路由上配置 BYPASS_CACHE 缓存模式，
在匹配请求时绕过缓存如果您需要绕过
缓存一小部分非关键流量，或调试源站
连接。
如果您需要提供动态响应（例如 API 后端），我们建议您配置外部应用负载均衡器。
建议您通常仅将它用于调试场景， 以免发生意外的来源加载。绕过缓存时出站流量为 按互联网出站费率计费。
缓存失效操作
请参阅缓存失效。
字节范围请求
媒体 CDN 支持单部分 HTTP 范围请求 如 RFC 7233。
此外，Media CDN 还使用范围请求从源站提取较大的响应。这样，Media CDN 就可以单独缓存分块，而无需一次提取整个对象进行缓存。
- 大于 1 MiB 的对象以字节范围请求（“块”）的形式进行提取，每个不超过 2 MiB。
- 在不支持字节的情况下，可以提取不超过 1 MiB 的响应 范围。
- 如果以下元素中不支持此字节范围，则系统不会提供大于此值的响应 来源。
源对字节范围请求的支持取决于以下因素：
- HTTP 状态代码 200（成功）或 206（部分内容）。
- 有效的
Content-Length或Content-Range响应标头。 - 响应验证器 (
ETag或Last-Modified)。
针对每个“分块”发出单独的来源填充请求（字节范围）记录为
多个互不关联的日志条目，并与其父级客户端请求相关联。您可以按 jsonPayload.cacheKeyFingerprint 上的匹配请求对这些请求进行分组。
有关所记录内容的详情，请参阅 Cloud Logging 文档。
开放式范围请求
媒体 CDN 支持“开放式”Range 请求（例如，
带有 Range: bytes=0- 的请求），使请求保持针对源的开放状态
直到响应被源站关闭（例如，源站会写入所有
字节）或超时。
请求 Apple 低延迟 HLS 片段的客户端通常使用开头为 0 的字节范围：随着每个 CMAF 分块写入线路上，CDN 可以将该分块缓存并传送给客户端。
在其他情况下（例如，不需要与 DASH 实现互操作性时），媒体播放列表会向播放器指明哪些字节代表每个分块：
#EXTINF:4.08, fs270.mp4 #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=20000@0 #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=23000@20000 #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=18000@43000 #EXT-X-PRELOAD-HINT:TYPE=PART,URI="fs271.mp4",BYTERANGE-START=61000
您可以使用
EdgeCacheOrigin.timeouts.readTimeout 配置值。通常，此值应配置为目标时长的倍数（例如 2 倍）。
后续步骤
- 查看高级路由。
- 了解如何连接到不同的源站。
- 为您的服务设置 TLS (SSL) 证书。
- 配置已签名请求，以对内容访问权限进行身份验证。