源站概览

媒体 CDN 可让您从源站提取内容 无论内容托管在 Google Cloud 中,还是托管在 还是在本地部署

每项配置都可以有一个或多个与之关联的源。出发地 配置告诉媒体 CDN 如何连接到您的 故障切换、重试和超时的时间和方法, 使用。

源站具有以下特征:

  • 可以按主机和路由定义来源,这样, 要映射到多个源站的 EdgeCacheService 资源 例如,包含清单、视频片段和其他静态 内容。
  • 可通过 HTTP/2、HTTPS 和未加密的 HTTP/1.1 访问源站。
  • 重试和故障切换行为是按源站配置的, 让服务在出现硬错误(如连接失败)时进行故障切换或重试 基于 HTTP 404 Not Found 或 HTTP 429 Too Many Requests 响应。
  • 可以访问 Google Cloud 内部或本地的专用资源 方法是将外部应用负载平衡器配置为 origin 位于媒体 CDN 之后。
  • 重定向跟踪行为是按源站配置的。您可以启用 媒体 CDN 可跟踪指向其他源服务器的重定向。

源要求

要让媒体 CDN 能够缓存超过 1 MiB,则源必须在针对 HEADGET 请求(除非另有说明):

  • Last-ModifiedETag 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 内,即面向用户的缓存。
  3. Google 网络中的长尾缓存,其他下游缓存将会填充 返回该位置。这些缓存支持大量扇入, 大量缓存存储容量,并充当源站护盾

此拓扑的概览如下所示:

<ph type="x-smartling-placeholder">
</ph> 拓扑概览。
拓扑概览(点击可放大)。

所有层的缓存都支持通过折叠(或合并)请求进一步合并 降低源站负载基于观察到的大规模真实工作负载:

  • >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 根据存储桶名称自动设置

主要来源和任何故障切换来源都会看到相同的主机标头(如果它们) 使用相同的 routeRulehostRewrite 配置。

使用 Cloud Storage 时,系统会忽略任何 hostRewrite 设置 存储桶作为来源,因为系统不支持备用主机标头值 Cloud Storage 数据主机标头会根据 存储桶名称

请求中的 TLS SNI(服务器名称指示)值(适用于 HTTP/3、HTTP/2、 和 HTTPS 请求)设置为与发送到 来源。

如需了解如何为每条路由的配置重写主机标头,请参阅 配置服务路由。有关设置 各源站的替换操作,请参阅无重定向跟踪的源站故障切换

故障切换和超时

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

  • 超时:确定媒体 CDN 等待连接的时间 或让它响应请求。
  • 重试:确定媒体 CDN 是否重试源 HTTP 以及在什么条件下向来源发送请求
  • 故障切换:确定媒体 CDN 是否尝试连接 如果第一个实例不可用或返回特定状态,则将数据发送到故障切换来源 代码。

源超时

通过超时,您可以配置何时执行源站重试和故障切换行为 以及何时可以触发后续客户端故障切换。

下面介绍了媒体 CDN 支持的可配置超时 支持:

  • connectTimeoutmaxAttemptsTimeout 限制了媒体 CDN 的时长 找到可用响应所需的全部步骤

    两个超时时间均包括源站返回标头和 确定是使用故障切换还是重定向。connectTimeout适用 每次尝试都发送单独的请求,而 maxAttemptsTimeout 包含 跨所有源尝试进行连接所需的时间,包括 包括故障切换和重定向跟踪重定向会计为额外 尝试连接到源站,并计入 maxAttempts 集内 。

    当媒体 CDN 遇到非重定向响应(例如 来自重定向或故障切换源站的 readTimeoutresponseTimeout 值适用。重定向的来源使用 connectTimeoutreadTimeout、 和responseTimeout的值EdgeCacheOrigin 遇到重定向。

  • responseTimeoutreadTimeout 用于控制流式传输响应的时长 。在媒体 CDN 确定将使用 上游响应,既不是 connectTimeout,也不是 maxAttemptsTimeout 至关重要。此时,readTimeoutresponseTimeout 生效。

媒体 CDN 最多会在所有源站尝试四次源站, 而不会考虑每个 EdgeCacheOrigin 设置的 maxAttempts。 媒体 CDN 使用主 CDN 的 maxAttemptsTimeoutEdgeCacheOrigin.每次尝试的超时值 (connectTimeoutreadTimeoutresponseTimeout)已针对 EdgeCacheOrigin 配置 。

下表介绍了超时字段:

字段 默认 说明
connectTimeout 5 秒

媒体 CDN 可以花费的最长时间 开始向源站发送请求,直到媒体 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 值为 1,以及 Origin Bfailover_origin 值。connectTimeout 值处于 默认值为 5s。如果您尝试连接到 Origin A,但在 1 天内连接失败 则您还有大约 4 秒的时间来 成功连接到 Origin B

  • Origin C 将请求与“/manifests/*”匹配,值为 maxAttemptsTimeout10smaxAttempts 值为 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 类似,但仅适用于状态代码 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
媒体 CDN 尝试同时连接到您的主 CDN 故障切换来源,但未收到 HTTP 状态代码。 HTTP 502 Bad Gateway

如果媒体 CDN 收到与任何已配置 retryConditions(例如 HTTP 404 Not Found 或 HTTP 429 Too Many Requests 错误),而后续的重试和故障切换源请求将继续 失败,系统会在源之后向客户端返回 HTTP 502 Bad Gateway 错误 就已用尽。

源站故障切换最佳做法

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

最佳做法是仅为信任的来源配置来源重定向 和控制。请确保您信任重定向链中的每个源站,因为 每个来源都会生成由您的 EdgeCacheService 传送的内容。

后续步骤