媒体 CDN 使用 Google 的全球边缘缓存基础架构来缓存内容并减少源基础架构的负载,在尽可能靠近用户的位置传送内容。
您可以控制每个路由的内容缓存方式。这样,您就可以根据内容类型、客户端请求属性和新鲜度要求来优化行为。
可缓存性
以下部分介绍了媒体 CDN 会缓存哪些响应以及如何改进缓存分流。
默认缓存行为
默认情况下,以下与缓存相关的设置适用于每个边缘缓存服务:
CACHE_ALL_STATIC
的默认缓存模式:- 遵循源缓存指令(例如
Cache-Control
或Expires
),前提是不超过可配置的最大 TTL。 - 如果不存在源站缓存指令,则以 3, 600 秒的默认 TTL 自动缓存静态媒体类型。
- 缓存 HTTP 200 和 206 状态代码(负缓存未启用)。
- 遵循源缓存指令(例如
不缓存具有
no-store
或private
缓存控制指令或者无法缓存的响应。
除非已明确配置缓存,否则非静态内容或缺少有效缓存指令的响应不会被缓存。如需了解如何替换默认行为,请参阅有关缓存模式的文档。
默认行为等效于以下 cdnPolicy
。未配置显式 cdnPolicy
的路由的行为类似于采用以下配置:
cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 3600s cacheKeyPolicy: includeProtocol: false excludeHost: false excludeQueryString: false signedRequestMode: DISABLED negativeCaching: false
可缓存的响应
可缓存的响应是指媒体 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、50 之一。 |
HTTP 方法 | GET 和 HEAD |
请求标头 | 系统会忽略大多数缓存请求指令。如需了解详情,请参阅缓存控制指令。 |
响应标头 | 包含有效的 HTTP 缓存指令,例如 具有缓存相应内容的缓存模式,或具有包含将来日期的 |
响应大小 | 最多 100 GiB。 |
HTTP Age
标头根据媒体 CDN 首次缓存响应的时间进行设置,通常表示自对象在源防护位置缓存以来经过的秒数。如果您的源站生成了 Age 响应标头,请使用 FORCE_CACHE_ALL
缓存模式以防止在存在时间超过缓存 TTL 时重新验证。
如需详细了解媒体 CDN 如何解读 HTTP 缓存指令,请参阅缓存控制指令。
源要求
若要允许媒体 CDN 缓存大于 1 MiB 的源站响应,除非另有指定,否则源站必须在 HEAD
和 GET
请求的响应标头中包含以下内容:
Last-Modified
或ETag
HTTP 响应标头(验证器)。- 有效的 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 小时(3,600 秒),同时优先处理由源站指定的任何缓存指令来处理可缓存的响应。 - 您可以通过在路由上设置
cdnPolicy.defaultTtl
字段来增加或减少应用于未设置显式缓存 TTL(max-age
或s-maxage
指令)的响应的缓存 TTL。 - 为防止将不成功响应缓存的时间超出预期,系统不会根据其
Content-Type
(MIME 类型)缓存非 2xx(不成功)状态代码,也不会应用默认 TTL。
下表显示了可用的缓存模式,这些模式设置在每个路由的 cdnPolicy.cacheMode
上。
缓存模式 | 行为 |
---|---|
USE_ORIGIN_HEADERS |
要求源站响应设置有效的缓存指令和有效的缓存标头。如需查看完整的要求列表,请参阅可缓存的响应。 |
CACHE_ALL_STATIC |
自动缓存包含静态内容的成功响应(除非响应具有 静态内容包括视频、音频、图片和常见 Web 资源(由 |
FORCE_CACHE_ALL |
无条件缓存成功的响应,替换由源站设置的任何缓存指令。 配置此模式后,请勿为每个用户投放非公开内容(例如动态 HTML 或 API 响应)。 |
BYPASS_CACHE | 与配置了此缓存模式的路由相匹配的任何请求都会绕过缓存,即使存在与该缓存键匹配的缓存对象也是如此。 我们建议仅将其用于调试,因为媒体 CDN 设计为全球级缓存基础架构,而不是通用代理。 |
静态内容 MIME 类型
CACHE_ALL_STATIC
缓存模式允许媒体 CDN 根据 Content-Type
HTTP 响应标头中返回的 MIME 类型自动缓存常见的静态内容,例如视频、音频、图片和常见 Web 资源。不过,无论媒体类型如何,媒体 CDN 都会优先考虑源站响应中任何显式 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
。许多 Web 服务器会自动设置Content-Type
标头,包括 NGINX、Varnish 和 Apache。 - 当您使用 Google Cloud 控制台或
gsutil
工具上传内容时,Cloud Storage 会在上传时自动设置Content-Type
标头。 - 如果响应可根据其 MIME 类型进行缓存,但其
Cache-Control
响应指令为private
、no-store
或Set-Cookie
标头,则该响应不会被缓存。
配置缓存 TTL
借助存留时间 (TTL) 替换项,您可以为缓存内容设置默认 TTL 值,并替换在由源站设置的 max-age
和 s-maxage
缓存控制指令(或 Expires
标头)中设置的 TTL 值。
无论是通过替换设置还是使用缓存指令设置 TTL,它们都是乐观的。很少访问或不受欢迎的内容可能会在达到 TTL 之前从缓存中逐出。
下表显示了三项 TTL 设置。
设置 | 默认 | 最小值 | 最大值 | 说明 | 适用的缓存模式 |
---|---|---|---|---|---|
Default TTL | 1 小时 (3600 秒) |
0 秒 | 1 年 (31536000 秒) |
当源站未指定 如果源站指定了 使用 |
|
Max TTL | 1 天 (86400 秒) |
0 秒 | 1 年 (31536000 秒) |
对于可缓存的响应,允许的最大 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
标头。
负缓存
负缓存定义了媒体 CDN 如何缓存不成功的 HTTP 状态代码(2xx 以外的状态代码)。
这样,您就可以在更靠近用户的位置缓存重定向(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 RFC 7725 中所述,缓存支持 HTTP 代码 451(法律原因不可用)。
如果您需要自行配置每个状态代码 TTL 并替换默认行为,则可以配置 cdnPolicy.negativeCachingPolicy
。这样,您就可以为媒体 CDN 允许的任何状态代码设置 TTL:300、301、302、307、308、400、403、404、405、410、451、500、501、502、503 和 5。
例如,如需为 HTTP 404(未找到)响应设置 5 秒的 TTL 和 10 秒的 HTTP 405(不允许的方法)响应,请对每个适用的路由使用以下 YAML 定义:
cdnPolicy: negativeCaching: true negativeCachingPolicy: "404": 5s "405": 10s # other status codes to apply TTLs for
为了防止缓存中毒,我们不建议为状态代码 400(错误请求)或 403(禁止)启用缓存。请确保您的源服务器在仅检查缓存键中包含的请求组成部分后返回任一代码。例如,当源服务器在缺少正确的 Authorization
标头的情况下返回 403 错误响应时,可能会发生缓存投毒。在这种情况下,缓存 403 错误响应会导致媒体 CDN 为所有后续请求提供 403 错误响应,直到 TTL 到期,即使这些请求具有正确的 Authorization
标头也是如此。
如需停用负缓存,请执行以下操作:
- 如需停用默认的负缓存行为,请为路由设置
cdnPolicy.negativeCaching: false
。请注意,包含有效缓存指令和可缓存状态代码的源站响应仍会被缓存。 - 如需防止针对特定状态代码进行负缓存,同时仍遵循源缓存指令,请在
negativeCachingPolicy
定义中省略状态代码 (cdnPolicy.negativeCachingPolicy[].code
)。 - 如需明确忽略特定状态代码的源缓存指令,请将相应状态代码的
cdnPolicy.negativeCachingPolicy[].ttl
设置为0
(零)。
备注:
- 如果在路由上启用了
negativeCaching
,并且响应定义了有效的缓存指令,则响应中的缓存指令优先。 - 如果您配置了显式
negativeCachingPolicy
,并且为给定的状态代码定义了 TTL,则始终使用政策中定义的 TTL。 negativeCachingPolicy
设置的 TTL 最大值为 1800 秒(30 分钟),但系统将遵循 TTL 较高的源缓存指令。- 如果缓存模式配置为
FORCE_CACHE_ALL
,则在任何情况下都会忽略源站指令。
缓存控制指令
此处定义了媒体 CDN 与 Cache-Control
指令相关的行为。
如果该指令不适用于请求或响应,例如 only-if-cached
(仅限客户端的指令),则会在该列中标记“N/A”。
指令 | 请求 | 响应 |
---|---|---|
no-cache |
no-cache 请求指令会被忽略,以防止客户端可能发起或强制对源站进行重新验证。 |
包含 可以使用 |
no-store |
使用 no-store 的请求不会缓存对请求的响应。 |
系统不会缓存包含 可以使用 |
public |
不适用 | 如果包含 使用 |
private |
不适用 | 媒体 CDN 不会缓存包含 可以使用 使用 |
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
标头,则该标头会被忽略,并按原样传递给客户端。
缓存键
您可以通过考虑请求的唯一标识并移除在各请求之间经常发生变化的组件,来减少媒体 CDN 需要联系您的源站的次数。请求组成部分集通常称为“缓存键”。
以下部分介绍了如何配置缓存键。
缓存键组成部分
缓存键是引用缓存对象的一组请求参数(例如主机、路径和查询参数)。
默认情况下,边缘缓存服务的缓存键包括请求中的请求主机、路径和查询参数,并且范围限定为特定的 EdgeCacheService。
组件 | 是否默认包含? | 详情 |
---|---|---|
协议 | 否 | 通过 HTTP 和 HTTPS 发送请求会引用同一个缓存对象。 如果要向 http: 和 https: 请求返回不同的响应,请在关联路由上将 |
主机 | 是 | 不同的主机不会引用相同的缓存对象。 如果您有多个主机名指向同一个 EdgeCacheService,并且它们提供相同的内容,请将 |
路径 | 是 | 始终包含在缓存键中,无法删除。路径是缓存中对象的最小表示法。 |
查询参数 | 是 | 如果查询参数无法区分不同的响应,请将 如果缓存键中应仅包含部分查询参数,请根据需要设置 |
标头 | 否 | 使用要包含在缓存键中的标头名称设置 指定同时具有大量值的多个标头(例如,合并的标头值可以识别单个用户)可显著降低缓存命中率,并可能导致更高的逐出率和性能降低。 |
Cookie | 否 | 使用要包含在缓存键中的 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-encoding
accept
authorization
cdn-loop
connection
content-md5
content-type
cookie
date
forwarded
from
host
if-match
if-modified-since
if-none-match
origin
proxy-authorization
range
referer
referrer
user-agent
want-digest
x-csrf-token
x-csrftoken
x-forwarded-for
如需在缓存键中包含 HTTP 方法,请使用特殊标头名称 :method
。
包含 Cookie
Cookie 名称区分大小写。
以 edge-cache-
开头且采用大小写字母的任意变体的 Cookie 不能在缓存键中使用。
重新验证、逐出和到期
内容分发网络(包括媒体 CDN)的运行方式是将最热门的内容缓存在尽可能靠近用户的位置。
媒体 CDN 的大量存储空间以及源站防护功能限制了逐出非热门内容的必要性。每天访问少量的内容最终可能会被逐出。
- 达到配置的 TTL 的缓存响应可能不会立即逐出。对于热门内容,媒体 CDN 会向源站发出
HEAD
请求以确认标头未更改,从而重新验证缓存的响应是否为最新版本。在某些情况下,媒体 CDN 会改用以下请求标头之一或同时使用这两个请求标头向源站发送请求: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 支持 RFC 7233 中定义的单部分 HTTP 范围请求。
此外,媒体 CDN 还使用范围请求从源站提取更大的响应。这样,媒体 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 段的客户端使用:当每个 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
配置值来配置媒体 CDN 在两次读取之间等待的时长。通常,此值应配置为目标时长的倍数(例如 2 倍)。
后续步骤
- 查看高级转送设置。
- 了解如何连接到不同的源站。
- 为您的服务设置 TLS (SSL) 证书。
- 配置签名请求以对内容访问进行身份验证。