来源概览

借助媒体 CDN,您可以从源站基础架构提取内容,无论内容是托管在 Google Cloud 中、其他云平台中还是本地。

每个配置都可以有一个或多个相关联的来源。源站配置会告知媒体 CDN 如何连接到您的基础架构、何时以及如何进行故障转移、重试和超时,以及连接时要使用哪种协议。

起源具有以下特点:

  • 您可以为每个主机和每个路线定义来源,这样一来,单个 EdgeCacheService 资源就可以映射到包含清单、视频片段和其他静态内容等内容的多个来源。
  • 可以通过 HTTP/2、HTTPS 和未加密的 HTTP/1.1 访问来源。
  • 重试和故障切换行为是按来源配置的,可允许服务在发生严重错误(例如连接失败)时进行故障切换,或根据 HTTP 404 Not Found 或 HTTP 429 Too Many Requests 响应进行重试。
  • 通过在媒体 CDN 后面将外部应用负载平衡器配置为来源,您可以访问 Google Cloud 或本地内的私有资源。
  • 重定向跟随行为是按来源配置的。您可以启用 Media CDN 以跟随重定向到其他源服务器的请求。

来源要求

如需允许媒体 CDN 缓存大于 1 MiB 的源站响应,源站必须在 HEADGET 请求的响应标头中包含以下内容,除非另有说明:

  • 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 提供了深度分层的边缘基础架构,旨在尽可能主动减少缓存填充。

缓存基础架构有三个主要层:

  1. 深度边缘缓存,用于处理大部分流量并在服务提供商网络中分流。
  2. Google 的对等边缘,它连接到数千家 ISP,并充当边缘缓存的中间层缓存,在给定 ISP 中不存在这些缓存的情况下,还充当面向用户的缓存。
  3. Google 网络中的长尾缓存,其他下游缓存会在源之前从中填充内容。这些缓存支持大量扇入,具有充足的缓存存储容量,并可用作源站屏蔽层

此拓扑的概览如下所示:

拓扑概览。
拓扑概览(点击可放大)。

所有缓存层都支持请求折叠(或合并),以进一步减少源站负载。根据观察到的大规模真实工作负载:

  • >95% 的缓存填充会使用该区域内的专用长尾缓存节点,以降低缓存填充费用和延迟时间。
  • 来源与 Google 自有边缘基础架构之间的缓存填充完全通过 Google 的全球专用骨干网进行,这有助于缩短缓存填充延迟时间并提高可靠性,这对直播工作负载而言都是实实在在的好处。
  • 在有益的情况下,缓存会相互交叉填充,从而进一步降低缓存填充率。
  • 媒体 CDN 在缓存中具有巨大的存储容量,即使对于长尾、不太受欢迎的内容,也能最大限度地降低驱逐率。

客户看到的转移率可能会有所不同,具体取决于其缓存配置、用户负载、工作负载(例如直播与点播)、用户分布情况,以及他们向各个区域的用户提供的长尾内容(总语料库大小)量。

请求折叠

请求折叠会针对每个边缘节点,将针对同一缓存键的多个用户发起的缓存填充请求主动折叠为单个源站请求。

源站防护结合使用,可进一步减少源站负载和出站带宽需求,是媒体 CDN 的默认行为。

折叠的请求会记录面向客户端的请求和(折叠的)缓存填充请求。折叠会话的标头用于发出源站填充请求,这意味着源站只会看到该客户端的标头(包括 User-Agent)。

不共享相同缓存键的请求无法合并。

来源连接

以下部分介绍了 Media CDN 如何连接到源、如何发出 HTTP 请求,以及如何对请求进行身份验证。

支持的来源和协议

Media CDN 直接支持将任何可公开访问的 HTTP 端点用作来源,包括:

  • 通过 Identity and Access Management 服务账号访问的 Cloud Storage 存储分区,包括私有存储分区
  • 外部应用负载平衡器
  • 与 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 配置为源协议时,Media CDN 不会协商备用协议(例如 HTTP/2)。同样,在配置 HTTP/2 时,连接不会回退为 HTTP/1.1,以明确说明来源连接行为。
  • Media CDN 会根据协议自动使用正确的端口:HTTP 使用端口 80,HTTPS 和 HTTP/2 使用端口 443

源请求标头

连接到源时,Media 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 根据存储桶名称自动设置

如果主来源和任何故障切换来源共享相同的 routeRulehostRewrite 配置,则它们会看到相同的主机标头。

使用 Cloud Storage 存储桶作为源时,系统会忽略所有 hostRewrite 设置,因为 Cloud Storage 存储桶不支持其他主机标头值。系统会根据存储桶名称自动设置主机标头。

请求(对于 HTTP/3、HTTP/2 和 HTTPS 请求)中的 TLS SNI(服务器名称指示)值设置为与发送到源的主机标头相同的值。

如需了解如何为每个路由配置重写主机标头,请参阅配置服务路由。如需了解如何设置每个源替换操作,请参阅不跟随重定向的源故障切换

故障切换和超时

以下部分介绍了这些配置选项:

  • 超时:确定媒体 CDN 等待连接到您的来源或等待响应请求的时长。
  • 重试:确定 Media CDN 是否会重试对您的源站发出的 HTTP 请求,以及在什么条件下重试。
  • 故障切换:确定在第一个源不可用或返回特定状态代码时,Media CDN 是否会尝试连接到故障切换源。

来源超时

借助超时,您可以配置触发来源重试和故障切换行为的时间,以及可以触发后续客户端故障切换的时间。

以下介绍了 Media CDN 支持的可配置超时:

  • connectTimeoutmaxAttemptsTimeout 用于限制 Media CDN 查找可用响应所需的时间。

    这两种超时都包括源用来返回标头和确定是使用故障切换还是重定向的时间。connectTimeout 会针对每个来源尝试单独应用,而 maxAttemptsTimeout 包含在所有来源尝试(包括故障切换和重定向)中建立连接所需的时间。重定向后会计为尝试连接到源的额外尝试,并计入为配置的源设置的 maxAttempts

    当 Media CDN 遇到非重定向响应(例如来自重定向或故障切换源站的响应)时,系统会应用 readTimeoutresponseTimeout 值。重定向来源使用为遇到重定向的 EdgeCacheOrigin 配置的 connectTimeoutreadTimeoutresponseTimeout 值。

  • responseTimeoutreadTimeout 用于控制流式响应所需的时间。在 Media CDN 确定要使用上游响应后,connectTimeoutmaxAttemptsTimeout 就没有意义了。此时,readTimeoutresponseTimeout 会生效。

无论每个 EdgeCacheOrigin 设置了什么 maxAttempts,Media CDN 对所有来源最多只会尝试四次。Media CDN 使用主要 EdgeCacheOrigin 中的 maxAttemptsTimeout 值。系统会为每次尝试的 EdgeCacheOrigin 配置每次尝试的超时值 (connectTimeoutreadTimeoutresponseTimeout)。

下表介绍了超时字段:

字段 默认 说明
connectTimeout 5 秒

从 Media CDN 发起对源的请求到 Media CDN 确定响应是否可用所需的最长时间。实际上,connectTimeout 涵盖从创建请求、进行 DNS 查找、进行 TLS 握手、建立 TCP/QUIC 连接到获取包含 HTTP 状态代码的响应标头所用的时间。

超时值必须介于 1 秒到 15 秒之间。

maxAttemptsTimeout 15 秒

尝试连接到来源(包括故障切换来源)的最大总次数,达到此上限后,系统会向客户端返回错误。如果达到超时限制,系统会先返回 HTTP 504,然后再返回响应。

超时值必须介于 1 秒到 30 秒之间。

此设置用于定义所有来源连接尝试(包括故障切换来源)的时长,以限制客户端等待内容开始流式传输的总时间。系统只会使用第一个 maxAttemptsTimeout 值,其中“第一个”由为给定路线配置的起点定义。

readTimeout 15 秒

单个 HTTP 响应的读取之间等待的最大时长。 readTimeoutresponseTimeout 的限制。 所有 HTTP 响应读取都必须在 responseTimeout 设置的截止时间之前完成。超时值必须介于 1 秒到 30 秒之间。如果在响应完成之前达到此超时限制,系统会截断响应并记录日志。

responseTimeout 30 秒

允许响应完成的最长时长。

超时值必须介于 1 秒到 120 秒之间。

时长从收到第一个正文字节开始计算。如果在响应完成之前达到此超时限制,系统会截断响应并将其记录到日志中。

请参考以下示例:

  • Origin A 会匹配对“/segments/”的请求,其 maxAttemptsTimeout 值为 5smaxAttempts 值为 1failover_origin 值为 Origin BconnectTimeout 值为默认值 5s。如果您尝试连接到 Origin A,但由于 TLS 证书无效而导致连接在 1 秒内失败,则您还有大约 4 秒的时间来成功连接到 Origin B

  • Origin C 与对“/manifests/*”的请求匹配,maxAttemptsTimeout 值为 10smaxAttempts 值为 3failover_origin 未配置。connectTimeout 值为默认值 5s。Media CDN 最多会尝试 3 次连接到 Origin C,最多允许 10 秒(maxAttemptsTimeout 限制)的时间来成功建立连接。

重试来源请求

媒体 CDN 支持来源重试,允许对来源发出失败的请求进行重试。您可以指定在尝试故障切换源(如果已配置)之前,可以重试当前源的次数。

  • 媒体 CDN 会尝试访问主源站,直到达到配置的 maxAttempts 值(默认为 1)。
  • Media CDN 最多会重试三次来源连接,然后才会失败并向用户返回 HTTP 502 Bad Gateway 错误。这包括任何故障切换源连接,这些连接会计入三项限制。
  • 配置源资源时,您可以使用 originAddress 字段配置主源,然后再配置可选的 failoverOriginfailoverOrigin 指向其他源资源。

每个来源的 retryConditions 会指定哪些类型的失败会触发重试:

条件 默认 说明
CONNECT_FAILURE ✔️ 失败时重试,包括路由、DNS 和 TLS 握手错误以及 TCP/UDP 超时。
HTTP_5XX 针对任何 HTTP 5xx 状态代码重试。
GATEWAY_ERROR 5xx 类似,但仅适用于状态代码 502503504
RETRIABLE_4XX 针对可重试的 4xx 状态代码(包括 409429)进行重试。
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 错误。

源代码故障切换最佳实践

配置多个源站以实现故障切换或负载均衡时,请确保您的媒体内容以及 VaryETagLast-Modified 标头行为在各个源站之间保持一致。

最佳实践是仅为您信任且控制的来源配置来源重定向。请确保您信任重定向链中的每个来源,因为每个来源都会生成由 EdgeCacheService 提供的内容。

后续步骤