媒体 CDN 可让您从源站提取内容 无论内容托管在 Google Cloud 还是 或本地环境
每个配置都可以有一个或多个相关联的来源。源站配置会告知媒体 CDN 如何连接到您的基础架构、何时以及如何进行故障转移、重试和超时,以及连接时要使用哪种协议。
源站具有以下特征:
- 可以按主机和路由定义来源,这样,
要映射到多个源站的
EdgeCacheService
资源 例如,包含清单、视频片段和其他静态 内容。 - 可以通过 HTTP/2、HTTPS 和未加密的 HTTP/1.1 访问源。
- 重试和故障切换行为是按源站配置的,
让服务在出现硬错误(如连接失败)时进行故障切换或重试
基于 HTTP
404 Not Found
或 HTTP429 Too Many Requests
响应。 - 可以访问 Google Cloud 内部或本地的专用资源 方法是将外部应用负载平衡器配置为 source。
- 重定向跟随行为是按来源配置的。您可以启用 媒体 CDN 可跟踪指向其他源服务器的重定向。
源要求
如需允许媒体 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,您可以为每个来源明确设置协议字段。
来源防护
媒体 CDN 提供了深度分层的边缘基础架构,旨在尽可能主动减少缓存填充。
缓存基础架构有三个主要层:
- 深边缘缓存,可在 内处理大部分流量并分流 服务提供商网络
- Google 的对等边缘,它连接到数千家 ISP,并充当边缘缓存的中间层缓存,在给定 ISP 中不存在这些缓存的情况下,还充当面向用户的缓存。
- Google 网络中的长尾缓存,其他下游缓存会在源之前从中填充内容。这些缓存支持大量扇入,具有充足的缓存存储容量,并可用作源站屏蔽层。
此拓扑的概览如下所示:
所有层的缓存都支持通过折叠(或合并)请求进一步合并 降低源站负载根据观察到的大规模真实工作负载:
- >95% 的缓存填充都使用了区域内的专用长尾缓存节点,以降低缓存填充费用和延迟时间。
- 源站和 Google 自己的边缘基础架构之间的缓存填充流量 完全依靠 Google 的全球专用骨干网,减少缓存 填充延迟时间和提高可靠性,这都是直播的积极优势 流式传输工作负载
- 在有益的情况下,缓存会相互交叉填充,从而进一步降低缓存填充率。
- 媒体 CDN 在 Google Cloud 上 这样可以最大限度地降低逐出率,即使是对于不太热门的长尾 内容。
客户可能会看到不同的分流速率,具体取决于他们的缓存 配置、用户负载、工作负载(如实时与按需)、用户 以及它们分配到了多少长尾内容(语料库总大小) 各个区域的用户。
请求折叠
请求折叠会将针对同一缓存键的多个用户发起的缓存填充请求主动折叠为每个边缘节点的一个源站请求。
与源站防护结合使用,可以进一步降低 是源站负载和出站流量的带宽需求, 媒体 CDN。
折叠的请求会记录面向客户端的请求和(折叠的)缓存填充请求。收起的会话的 leader 是 来发出源填充请求,这表示该来源会看到 标头(包括用户代理)。
无法收起没有共享相同缓存键的请求。
来源连接
以下部分介绍了媒体 CDN 如何连接到源站, HTTP 请求以及如何对请求进行身份验证。
支持的来源和协议
媒体 CDN 直接支持任何可公开访问的 HTTP 端点 作为来源,其中包括:
- Cloud Storage 存储桶,包括通过 Identity and Access Management 服务账号访问的私有存储桶
- 外部应用负载均衡器
- 与 Amazon S3 兼容的存储分区,包括 私有存储分区 AWS 签名版本 4
- 其他可公开访问的对象存储空间,例如 Azure Blob Storage
- 可公开访问的 Web 服务器,例如公共虚拟机或本地主机
与源的连接是通过安全隧道和 Google 的全球骨干网实现的。
下表详细说明了受支持的源协议。
协议 | 支持 | 需要使用 SSL (TLS) |
---|---|---|
HTTP/2 | 是(默认) | 是 |
HTTPS(基于 TLS 的 HTTP/1.1) | 是 | 是 |
HTTP/1.1 | 是 | 否 |
媒体 CDN 默认使用 HTTP/2 (h2) 连接到源站。 HTTP/2 和 HTTPS 都需要有效且受大众信任的 TLS (SSL) 证书。有效证书是指未过期的证书,由公共证书授权机构签发,并且主题备用名称与发送到源的网域名匹配。
注意:
- 如果您的源不支持 HTTP/2,您可以明确将协议(按源)设置为
HTTP
(HTTP/1.1) 或HTTPS
(通过 TLS 的 HTTP/1.1)。 - 将 HTTPS 或 HTTP/1.1 配置为源协议时, 媒体 CDN 不协商替代协议(如 HTTP/2)。同样,配置 HTTP/2 时,连接 回退到 HTTP/1.1,以明确来源连接 行为
- Media CDN 会根据协议自动使用正确的端口:HTTP 使用端口
80
,HTTPS 和 HTTP/2 使用端口443
。
源请求标头
连接到源站时,媒体 CDN 使用 Host
标头
从客户端请求调用。
下表记录了在不同配置场景下,源在传入请求中看到的内容:
客户端请求 | EdgeCacheService.hostRewrite |
EdgeCacheOrigin.hostRewrite |
originAddress | 主机标头 / 源的 TLS SNI |
---|---|---|---|---|
media.example.com | 无 | 无 | backend.example.com | media.example.com |
media.example.com | service.example.com | 无 | backend.example.com | service.example.com |
media.example.com | 无 | origin.example.com | backend.example.com | origin.example.com |
media.example.com | service.example.com | origin.example.com | backend.example.com | origin.example.com |
media.example.com | service.example.com | origin.example.com | gs://vod-content-bucket | 根据存储桶名称自动设置 |
如果主来源和任何故障切换来源共享相同的 routeRule
或 hostRewrite
配置,则它们会看到相同的主机标头。
使用 Cloud Storage 时,系统会忽略任何 hostRewrite
设置
存储桶作为来源,因为系统不支持备用主机标头值
Cloud Storage 数据主机标头会根据
存储桶名称
请求中的 TLS SNI(服务器名称指示)值(适用于 HTTP/3、HTTP/2、 和 HTTPS 请求)设置为与发送到 来源。
如需了解如何为每个路由配置重写主机标头,请参阅配置服务路由。如需了解如何设置每个源替换操作,请参阅不跟随重定向的源故障切换。
故障切换和超时
以下部分介绍了这些配置选项:
- 超时:确定媒体 CDN 等待连接的时间 或让它响应请求。
- 重试:确定 Media CDN 是否会重试对您的源站发出的 HTTP 请求,以及在什么条件下重试。
- 故障转移:确定在第一个源不可用或返回特定状态代码时,Media CDN 是否会尝试连接到故障转移源。
来源超时
借助超时,您可以配置何时触发来源重试和故障切换行为,以及何时可以触发后续客户端故障切换。
以下介绍了 Media CDN 支持的可配置超时:
connectTimeout
和maxAttemptsTimeout
用于限制 Media CDN 查找可用响应所需的时间。两个超时时间均包括源站返回标头和 确定是使用故障切换还是重定向。
connectTimeout
适用 每次尝试都发送单独的请求,而maxAttemptsTimeout
包含 跨所有源尝试进行连接所需的时间,包括 包括故障切换和重定向跟踪重定向会计为额外 尝试连接到源站,并计入maxAttempts
集内 。当 Media CDN 遇到非重定向响应(例如来自重定向或故障切换源站的响应)时,系统会应用
readTimeout
和responseTimeout
值。重定向来源使用为遇到重定向的EdgeCacheOrigin
配置的connectTimeout
、readTimeout
和responseTimeout
值。responseTimeout
和readTimeout
用于控制流式响应所需的时间。在 Media CDN 确定要使用上游响应后,connectTimeout
和maxAttemptsTimeout
就没有意义了。此时,readTimeout
和responseTimeout
生效。
无论每个 EdgeCacheOrigin
设置了什么 maxAttempts
,Media CDN 对所有来源最多只会尝试四次。媒体 CDN 使用主 CDN 的 maxAttemptsTimeout
值
EdgeCacheOrigin
。系统会为每次尝试的 EdgeCacheOrigin
配置每次尝试的超时值 (connectTimeout
、readTimeout
和 responseTimeout
)。
下表介绍了超时字段:
字段 | 默认值 | 说明 |
---|---|---|
connectTimeout | 5 秒 | 从媒体 CDN 发起对源的请求到媒体 CDN 确定响应是否可用所需的最长时间。实际上是 超时值必须介于 1 秒到 15 秒之间。 |
maxAttemptsTimeout | 15 秒 | 尝试连接到源站的最长时间,包括 故障切换来源,然后再向客户端返回错误。如果达到超时限制,系统会先返回 HTTP 504,然后再返回响应。 超时值必须介于 1 秒到 30 秒。 此设置用于定义所有来源连接尝试(包括故障切换来源)的总时长,以限制客户端等待内容开始流式传输的总时间。仅
使用 |
readTimeout | 15 秒 | 单个 HTTP 响应的读取之间等待的最大时长。
|
responseTimeout | 30 秒 | 允许响应完成的最长时长。 超时值必须介于 1 秒到 120 秒。 时长从收到第一个正文字节开始计算。如果在响应完成之前达到此超时时间, 响应会被截断并记录下来。 |
请参考以下示例:
Origin A
将请求与“/segments/”匹配且具有maxAttemptsTimeout
值为5s
、maxAttempts
值为1
,以及Origin B
的failover_origin
值。connectTimeout
值处于 默认值为5s
。如果您尝试连接到Origin A
,但在 1 天内连接失败 则您还有大约 4 秒的时间来 成功连接到Origin B
。Origin C
与对“/manifests/*”的请求匹配,maxAttemptsTimeout
值为10s
,maxAttempts
值为3
,failover_origin
未配置。connectTimeout
值为默认值5s
。媒体 CDN 最多尝试连接Origin C
三次,最多持续 10 秒 (maxAttemptsTimeout
限制)以建立连接。
重试来源请求
媒体 CDN 支持源站重试,允许源站重试失败 以便重试。您可以指定 可在故障切换源之前重试当前源(如果已配置) 错误。
- 媒体 CDN 尝试访问主源,直到
配置了
maxAttempts
值,默认值为1
。 - 媒体 CDN 最多重试三次源连接
次之后失败,并向服务器返回 HTTP
502 Bad Gateway
错误 用户。这包括任何故障切换源连接,这些连接会计入三项的限制。 - 配置源站资源时,您可以通过以下方式配置主要源站
使用
originAddress
字段,然后使用可选的failoverOrigin
。failoverOrigin
指向其他来源资源。
每个源站的 retryConditions
指定了故障类型
触发重试:
条件 | 默认 | 说明 |
---|---|---|
CONNECT_FAILURE | ✔️ | 失败时重试包括路由、DNS 和 TLS 握手错误,以及 TCP/UDP 超时。 |
HTTP_5XX | 遇到任何 HTTP 5xx 状态代码时重试。 |
|
GATEWAY_ERROR | 与 5xx 类似,但仅适用于状态代码 502 、503 或 504 。 |
|
RETRIABLE_4XX | 针对可重试的 4xx 状态代码重试,
包括409 和429 。 |
|
NOT_FOUND | 在收到 HTTP 404 状态代码时重试。 |
|
FORBIDDEN | 遇到 HTTP 403 状态代码时重试。 |
如果您需要主动健康检查、轮循或负载感知型导向 您可以 配置外部应用负载平衡器 作为主要来源
故障切换行为
下表介绍了故障切换的运行方式以及 会观察到:
场景 | 已配置故障切换 | 面向用户的状态 |
---|---|---|
媒体 CDN 尝试连接到您的源站,并且 两次尝试后将不会收到 HTTP 响应(默认)。 | 否 | HTTP 502 Bad Gateway |
媒体 CDN 会尝试连接到您的主要来源,
并且连接失败(TLS 握手错误)。系统尝试连接到您配置的故障切换来源,但该来源返回 HTTP 404 错误。
|
是 | HTTP 404 Not Found |
Media CDN 会尝试同时连接到您的主源站和后备源站,但未收到任何 HTTP 状态代码。 | 是 | HTTP 502 Bad Gateway |
如果 Media CDN 收到与任何已配置的 retryConditions
匹配的状态代码(例如 HTTP 404 Not Found
或 HTTP 429 Too Many
Requests
错误),并且后续的重试和故障切换源请求继续失败,则在源尝试次数耗尽后,系统会向客户端返回 HTTP 502 Bad Gateway
错误。
源代码故障切换最佳实践
配置多个源站以实现故障转移或负载均衡时,请确保您的媒体内容以及 Vary
、ETag
和 Last-Modified
标头行为在各个源站之间保持一致。
最佳做法是仅为信任的来源配置来源重定向
和控制。请确保您信任重定向链中的每个源站,因为
每个来源都会生成由您的 EdgeCacheService
传送的内容。