媒体 CDN 可让您从源站提取内容 无论内容托管在 Google Cloud 中,还是托管在 还是在本地部署
每项配置都可以有一个或多个与之关联的源。出发地 配置告诉媒体 CDN 如何连接到您的 故障切换、重试和超时的时间和方法, 使用。
源站具有以下特征:
- 可以按主机和路由定义来源,这样,
要映射到多个源站的
EdgeCacheService
资源 例如,包含清单、视频片段和其他静态 内容。 - 可通过 HTTP/2、HTTPS 和未加密的 HTTP/1.1 访问源站。
- 重试和故障切换行为是按源站配置的,
让服务在出现硬错误(如连接失败)时进行故障切换或重试
基于 HTTP
404 Not Found
或 HTTP429 Too Many Requests
响应。 - 可以访问 Google Cloud 内部或本地的专用资源 方法是将外部应用负载平衡器配置为 origin 位于媒体 CDN 之后。
- 重定向跟踪行为是按源站配置的。您可以启用 媒体 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 内,即面向用户的缓存。
- Google 网络中的长尾缓存,其他下游缓存将会填充 返回该位置。这些缓存支持大量扇入, 大量缓存存储容量,并充当源站护盾。
此拓扑的概览如下所示:
所有层的缓存都支持通过折叠(或合并)请求进一步合并 降低源站负载基于观察到的大规模真实工作负载:
- >95% 的缓存填充会使用 区域,以减少缓存填充费用和延迟。
- 源站和 Google 自己的边缘基础架构之间的缓存填充流量 完全依靠 Google 的全球专用骨干网,减少缓存 填充延迟时间和提高可靠性,这都是直播的积极优势 流式传输工作负载
- 在有利的情况下,彼此进行交叉填充,进一步 从而降低缓存填充率
- 媒体 CDN 在 Google Cloud 上 这样可以最大限度地降低逐出率,即使是对于不太热门的长尾 内容。
客户可能会看到不同的分流速率,具体取决于他们的缓存 配置、用户负载、工作负载(如实时与按需)、用户 以及它们分配到了多少长尾内容(语料库总大小) 各个区域的用户。
请求收起
请求收起会主动收起多个用户驱动的 将同一缓存键的填充请求缓存为单个源请求,每个 边缘节点
与源站防护结合使用,可进一步降低 是源站负载和出站流量的带宽需求, 媒体 CDN。
折叠的请求会同时记录面向客户端的请求和 已记录(收起)缓存填充请求。收起的会话的主是 来发出来源填充请求,这表示来源会看到 标头(包括用户代理)。
无法收起没有共享相同缓存键的请求。
来源连接
以下部分介绍了媒体 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,以明确来源连接 行为
- 媒体 CDN 会根据
协议:端口
80
(对于 HTTP)或端口443
(对于 HTTPS 和 HTTP/2)。
源请求标头
连接到源站时,媒体 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 等待连接的时间 或让它响应请求。
- 重试:确定媒体 CDN 是否重试源 HTTP 以及在什么条件下向来源发送请求
- 故障切换:确定媒体 CDN 是否尝试连接 如果第一个实例不可用或返回特定状态,则将数据发送到故障切换来源 代码。
源超时
通过超时,您可以配置何时执行源站重试和故障切换行为 以及何时可以触发后续客户端故障切换。
下面介绍了媒体 CDN 支持的可配置超时 支持:
connectTimeout
和maxAttemptsTimeout
限制了媒体 CDN 的时长 找到可用响应所需的全部步骤两个超时时间均包括源站返回标头和 确定是使用故障切换还是重定向。
connectTimeout
适用 每次尝试都发送单独的请求,而maxAttemptsTimeout
包含 跨所有源尝试进行连接所需的时间,包括 包括故障切换和重定向跟踪重定向会计为额外 尝试连接到源站,并计入maxAttempts
集内 。当媒体 CDN 遇到非重定向响应(例如 来自重定向或故障切换源站的
readTimeout
和responseTimeout
值适用。重定向的来源使用connectTimeout
、readTimeout
、 和responseTimeout
的值EdgeCacheOrigin
遇到重定向。responseTimeout
和readTimeout
用于控制流式传输响应的时长 。在媒体 CDN 确定将使用 上游响应,既不是connectTimeout
,也不是maxAttemptsTimeout
至关重要。此时,readTimeout
和responseTimeout
生效。
媒体 CDN 最多会在所有源站尝试四次源站,
而不会考虑每个 EdgeCacheOrigin
设置的 maxAttempts
。
媒体 CDN 使用主 CDN 的 maxAttemptsTimeout
值
EdgeCacheOrigin
。每次尝试的超时值 (connectTimeout
、
readTimeout
和 responseTimeout
)已针对 EdgeCacheOrigin
配置
。
下表介绍了超时字段:
字段 | 默认 | 说明 |
---|---|---|
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 |
媒体 CDN 尝试同时连接到您的主 CDN 故障切换来源,但未收到 HTTP 状态代码。 | 是 | HTTP 502 Bad Gateway |
如果媒体 CDN 收到与任何已配置
retryConditions
(例如 HTTP 404 Not Found
或 HTTP 429 Too Many
Requests
错误),而后续的重试和故障切换源请求将继续
失败,系统会在源之后向客户端返回 HTTP 502 Bad Gateway
错误
就已用尽。
源站故障切换最佳做法
在为故障切换或负载均衡配置多个源站时,请确保
您的媒体内容以及 Vary
、ETag
和 Last-Modified
标头行为
确保源站之间的一致性
最佳做法是仅为信任的来源配置来源重定向
和控制。请确保您信任重定向链中的每个源站,因为
每个来源都会生成由您的 EdgeCacheService
传送的内容。