Descripción general de los orígenes

Media CDN te permite recuperar contenido de tu origen infraestructura, ya sea que el contenido esté alojado en Google Cloud, en otro en la nube o de forma local.

Cada configuración puede tener uno o más orígenes asociados a ella. La configuración de origen le indica a Media CDN cómo conectarse a la infraestructura, cuándo y cómo realizar la conmutación por error, el reintento y el tiempo de espera, y qué protocolo usar cuando se conecte.

Los orígenes tienen los siguientes atributos:

  • Los orígenes pueden definirse por host y por ruta, lo que permite que un único Recurso EdgeCacheService para asignar a varios orígenes que contengan, por ejemplo, manifiestos, segmentos de video y otras imágenes contenido.
  • Se puede acceder a los orígenes mediante HTTP/2, HTTPS y HTTP/1.1 sin encriptar.
  • Los reintentos y comportamientos de conmutación por error se configuran por origen y pueden permitir que el servicio realice una conmutación por error ante errores graves (como una falla de conectividad) o que vuelva a intentarlo según las respuestas HTTP 404 Not Found o HTTP 429 Too Many Requests.
  • Se puede acceder a los recursos privados dentro de Google Cloud o locales configurando un balanceador de cargas de aplicaciones externo de origen detrás de Media CDN.
  • El siguiente comportamiento de redireccionamiento se configura por origen. Puedes habilitar Media CDN para seguir los redireccionamientos a otros servidores de origen.

Requisitos de origen

Permitir que Media CDN almacene en caché respuestas de origen de más de 1 MiB, el origen debe incluir lo siguiente en los encabezados de respuesta para solicitudes HEAD y GET, a menos que se especifique lo contrario:

  • Un encabezado de respuesta HTTP Last-Modified o ETag (un validador)
  • Un encabezado HTTP Date válido.
  • Un encabezado Content-Length válido.
  • El encabezado de respuesta Content-Range, en respuesta a una solicitud Range GET El encabezado Content-Range debe tener un valor válido con el formato bytes x-y/z (en el que z es el tamaño del objeto).

El protocolo de origen predeterminado es HTTP/2. Si tus orígenes solo admiten HTTP/1.1, puedes configurar el campo del protocolo de forma explícita para cada origen.

Protección del origen

Media CDN proporciona una infraestructura de perímetro con muchos niveles diseñada para minimizar el llenado de caché de forma activa siempre que sea posible.

Hay tres capas principales de infraestructura de almacenamiento en caché:

  1. Cachés perimetrales profundas, que entregan la mayor parte del tráfico y la descarga dentro de una red de proveedores de servicios.
  2. El perímetro de intercambio de tráfico de Google, que está conectado a miles de ISP y actúa como la caché de nivel medio para las cachés perimetrales y, en los casos en que no están presentes dentro de un ISP determinado, la caché orientada al usuario.
  3. Cachés de cola larga dentro de la red de Google que otras cachés descendentes llenan anteriores al origen. Estas cachés admiten una fan-in significativa, tienen una capacidad sustancial de almacenamiento en caché y actuar como un escudo de origen.

A continuación, se muestra una descripción general de esta topología:

Descripción general de la topología.
Descripción general de la topología (haz clic para ampliar).

Todas las capas de almacenamiento en caché admiten solicitudes que se contraen (o se combinan) para continuar y reducir la carga de origen. Según las cargas de trabajo reales observadas a gran escala:

  • > El 95% del llenado de caché usa un nodo de caché de cola larga dedicado la región para reducir los costos de llenado de caché y la latencia.
  • El llenado de caché entre el origen y la propia infraestructura perimetral de Google se basa completamente en la red troncal privada y global de Google, lo que reduce la latencia de llenado de caché y mejora la confiabilidad. Ambos son beneficios activos para las cargas de trabajo de transmisión en vivo.
  • Las memorias caché se llenan entre sí cuando es beneficioso para hacerlo, lo que reduce aún más las tasas de llenado de caché.
  • Media CDN tiene una capacidad de almacenamiento significativa en en cachés, lo que minimiza las tasas de expulsión, incluso para solicitudes contenido.

Es posible que los clientes vean diferentes tasas de descarga en función de su caché configuración, carga de usuarios, cargas de trabajo (como transmisiones en vivo frente a a pedido), cargas de trabajo distribución y cuánto contenido de cola larga (tamaño total del corpus) al que usuarios de todas las regiones.

Contraer la solicitud

La solicitud de contraer contrae de forma activa varias solicitudes de llenado de caché generadas por el usuario para la misma clave de caché en una sola solicitud de origen por nodo perimetral.

En combinación con la protección de origen, esto reduce aún más las necesidades de carga de origen y ancho de banda de salida, y es el comportamiento predeterminado para Media CDN.

Las solicitudes contraídas tienen registrada la solicitud orientada al cliente y la solicitud de llenado de caché (contraída). El líder de la sesión contraída es que se usa para hacer la solicitud de relleno de origen, lo que significa que el origen ve encabezados (incluido el usuario-agente) solo de ese cliente.

Las solicitudes que no comparten la misma clave de caché no se pueden contraer.

Conectividad de origen

En las siguientes secciones, se describe cómo se conecta Media CDN a los orígenes, cómo se realizan las solicitudes HTTP y cómo puedes autenticar las solicitudes.

Protocolos y orígenes compatibles

Media CDN admite de forma directa cualquier extremo HTTP accesible de forma pública como origen, incluidos los siguientes:

  • Buckets de Cloud Storage, incluidos los buckets privados a través de cuentas de servicio de Identity and Access Management.
  • Balanceadores de cargas de aplicaciones externos
  • buckets compatibles con Amazon S3, que incluyen buckets privados que usan Firma de AWS versión 4
  • Otro almacenamiento de objetos disponibles de forma pública, como Azure Blob Storage
  • Servidores web disponibles de forma pública, como VM públicas o hosts locales

La conectividad a los orígenes se realiza mediante túneles seguros y la red troncal global de Google.

En la siguiente tabla, se detallan los protocolos de origen compatibles.

Protocolo Admitido SSL (TLS) obligatorio
HTTP/2 Sí (valor predeterminado) Sí
HTTPS (HTTP/1.1 mediante TLS) Sí Sí
HTTP/1.1 Sí No

Media CDN usa HTTP/2 (h2) para conectarse a un origen de forma predeterminada. HTTP/2 y HTTPS requieren un certificado TLS (SSL) válido y de confianza pública. Un certificado válido es uno que no está vencido, firmado por una autoridad certificada pública y tiene un nombre alternativo del sujeto que coincide con el nombre de host enviado al origen.

Notas:

  • Si tu origen no admite HTTP/2, puedes configurar de forma explícita el protocolo (por origen) en HTTP (HTTP/1.1) o HTTPS (HTTP/1.1 a través de TLS).
  • Cuando se configura HTTPS o HTTP/1.1 como protocolo de origen, Media CDN no negocia un protocolo alternativo (como HTTP/2). Del mismo modo, cuando configuras HTTP/2, la conexión no recurrir a HTTP/1.1 para ser explícito en cuanto a la conectividad de origen de tu modelo.
  • Media CDN usa automáticamente el puerto correcto basado en el protocolo: puerto 80 para HTTP o puerto 443 para HTTPS y HTTP/2.

Encabezados de la solicitud de origen

Cuando te conectas a un origen, Media CDN usa el encabezado Host. de la solicitud del cliente de forma predeterminada.

En la siguiente tabla, se documenta lo que ve el origen en la solicitud entrante en diferentes situaciones de configuración:

Solicitud del cliente EdgeCacheService.hostRewrite EdgeCacheOrigin.hostRewrite originAddress Encabezado del host /
SNI de TLS en el origen
media.example.com Ninguna Ninguna backend.example.com media.example.com
media.example.com service.example.com Ninguna backend.example.com service.example.com
media.example.com Ninguna 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 se establece automáticamente en función del nombre del bucket

El origen principal y cualquier origen de conmutación por error ven el mismo encabezado de host si comparten la misma configuración de routeRule o hostRewrite.

Cualquier configuración de hostRewrite se ignora cuando se usa un bucket de Cloud Storage como origen, ya que los valores de encabezado del host alternativos no son compatibles con los buckets de Cloud Storage. El encabezado del host se configura de forma automática en función del nombre del bucket.

El valor de SNI de TLS (indicación de nombre del servidor) en la solicitud (para HTTP/3, HTTP/2 y solicitudes HTTPS) se establece en el mismo valor que el encabezado del host que se envía al origen.

Si deseas obtener información sobre cómo reescribir los encabezados del host para la configuración por ruta, consulta Configura las rutas de servicio. Para obtener información sobre la configuración sobre las acciones de anulación por origen, consulta Siguiente sobre la conmutación por error de origen sin redireccionamiento.

Conmutación por error y tiempos de espera

En las siguientes secciones, se describen estas opciones de configuración:

  • Tiempos de espera: determina cuánto tiempo espera Media CDN para conectarse a tu origen o responder a una solicitud.
  • Reintentos: Determina si Media CDN reintenta una solicitud HTTP de origen a tu origen y en qué condiciones.
  • Conmutación por error: determina si la CDN de medios intenta conectarse a un origen de conmutación por error si la primera no está disponible o muestra un código de estado específico.

Tiempo de espera de origen

Los tiempos de espera te permiten configurar cuándo los comportamientos de reintento y conmutación por error de origen y cuándo se puede activar una conmutación por error de cliente posterior.

A continuación, se describen los tiempos de espera configurables que Media CDN admite:

  • connectTimeout y maxAttemptsTimeout limitan el tiempo que lleva la CDN de medios para encontrar una respuesta que se puede usar.

    Ambos tiempos de espera incluyen el tiempo que tarda el origen en mostrar encabezados y determinar si se debe usar una conmutación por error o un redireccionamiento. connectTimeout se aplica de forma independiente para cada intento de origen, mientras que maxAttemptsTimeout incluye el tiempo necesario para conectarse en todos los intentos de origen, incluidas las conmutaciones por error y los redireccionamientos. Seguir un redireccionamiento cuenta como un intento adicional de conexión al origen y se considera dentro del conjunto maxAttempts para el origen configurado.

    Cuando Media CDN encuentra una respuesta que no es de redireccionamiento, como la de un origen de redireccionamiento o conmutación por error, se aplican los valores readTimeout y responseTimeout. Los orígenes redireccionados usan los valores connectTimeout, readTimeout y responseTimeout configurados para el EdgeCacheOrigin que encontró el redireccionamiento.

  • responseTimeout y readTimeout controlan cuánto tiempo puede tardar una respuesta transmitida. Después de que Media CDN determine que usará una respuesta ascendente, ni siquiera connectTimeout ni maxAttemptsTimeout son importantes. En este punto, readTimeout y responseTimeout entran en vigor.

Media CDN realiza como máximo cuatro intentos de origen en todos los orígenes, sin importar el maxAttempts establecido por cada EdgeCacheOrigin. Media CDN usa el valor maxAttemptsTimeout del EdgeCacheOrigin principal. Los valores de tiempo de espera por intento (connectTimeout, readTimeout y responseTimeout) se configuran para el EdgeCacheOrigin de cada intento.

En la siguiente tabla, se describen los campos de tiempo de espera:

Campo Predeterminado Descripción
connectTimeout 5 segundos

El tiempo máximo que puede tomar la CDN de Media desde el inicio de la solicitud hasta el origen hasta que se determine si la respuesta se puede usar. En la práctica, connectTimeout cubre el tiempo que comienza con la creación de la solicitud, la realización de búsquedas de DNS y la realización de protocolos de enlace TLS, el establecimiento de la conexión TCP/QUIC, mediante la obtención de los encabezados de respuesta que contienen el código de estado HTTP.

El tiempo de espera debe ser un valor entre 1 segundo y 15 segundos.
maxAttemptsTimeout 15 segundos

El tiempo máximo de todos los intentos de conexión al origen, incluidos los orígenes de conmutación por error, antes de mostrar un error al cliente. Se muestra un HTTP 504 si se alcanza el tiempo de espera antes de que se muestre una respuesta.

El tiempo de espera debe ser un valor entre 1 segundo y 30 segundos.

Esta configuración define la duración total de todos los intentos de conexión de origen, incluidos los orígenes de conmutación por error, para limitar el tiempo total que los clientes deben esperar para que se muestre el contenido. comenzar a transmitir. Solo se usa el primer valor maxAttemptsTimeout, en el que el primer se define por el origen configurado para la ruta determinada.
readTimeout 15 segundos

La duración máxima a esperar entre lecturas de una sola respuesta HTTP. El readTimeout está limitado por responseTimeout. Todas las lecturas de la respuesta HTTP deben completarse antes de la fecha límite establecida por el responseTimeout. El tiempo de espera debe ser un valor entre 1 segundo y 30 segundos. Si se alcanza este tiempo de espera antes de que se complete la respuesta, la respuesta se trunca y se registra.
responseTimeout 30 segundos

La duración máxima que permite que se complete una respuesta.

El tiempo de espera debe ser un valor entre 1 segundo y 120 segundos.

La duración se mide desde el momento en que se reciben los primeros bytes de cuerpo. Si se alcanza este tiempo de espera antes de que se complete la respuesta, la respuesta se trunca y se registra.

Considera los siguientes ejemplos:

  • Origin A hace coincidir las solicitudes con "/segments/" y tiene un valor maxAttemptsTimeout de 5s, un valor maxAttempts de 1 y un Un valor failover_origin de Origin B. El valor predeterminado de connectTimeout es 5s. Si intentas conectarte a Origin A, la operación falla en 1 por un certificado TLS no válido, tiene ~4 segundos para hacer una conexión exitosa a Origin B.

  • Origin C hace coincidir las solicitudes con "/manifests/* y tiene un valor maxAttemptsTimeout". de 10s, un valor de maxAttempts de 3, y failover_origin sin configurar. El El valor predeterminado de connectTimeout es 5s. Media CDN Intenta conectarse a Origin C hasta tres veces, lo que permite un máximo de 10 segundos (el límite de maxAttemptsTimeout) para establecer una conexión exitosa.

Reintenta las solicitudes de origen

Media CDN admite reintentos de origen, lo que permite solicitudes al origen para que se vuelvan a procesar. Puedes especificar cuántas veces se puede reintentar el origen actual antes de que se intente realizar un origen de conmutación por error (si está configurado).

  • Media CDN intenta llegar al origen principal hasta el configuró el valor maxAttempts, que se establece de forma predeterminada en 1.
  • Media CDN reintenta las conexiones de origen hasta un máximo de tres veces antes de fallar y muestra un error HTTP 502 Bad Gateway al usuario. Esto incluye cualquier conexión de origen de conmutación por error, que cuenta el límite de tres.
  • Cuando configuras un recurso de origen, puedes configurar un origen principal mediante el campo originAddress y, luego, un failoverOrigin opcional. El failoverOrigin apunta a otro recurso de origen.

El retryConditions para cada origen especifica qué tipos de fallas activan un reintento:

Condición Predeterminado Descripción
CONNECT_FAILURE ✔️ Los reintentos en caso de fallas incluyen enrutamiento, errores de protocolo de enlace TLS y DNS. Tiempos de espera de TCP/UDP.
HTTP_5XX Vuelve a intentarlo con cualquier código de estado HTTP 5xx.
GATEWAY_ERROR Similar a 5xx, pero solo se aplica a los códigos de estado 502, 503 o 504.
RETRIABLE_4XX Vuelve a intentarlo para 4xx códigos de estado que se pueden reintentar. incluidos 409 y 429.
NOT_FOUND Vuelve a intentarlo con un código de estado HTTP 404.
FORBIDDEN Vuelve a intentarlo con un código de estado HTTP 403.

Si necesitas verificación de estado activa, round robin o direccionamiento adaptado a la carga entre los orígenes, puedes configurar un balanceador de cargas de aplicaciones externo como origen primario.

Comportamiento de la conmutación por error

En la siguiente tabla, se describe cómo funciona la conmutación por error y qué respuesta observaría un cliente:

Situación Conmutación por error configurada Estado para el usuario
Media CDN intenta conectarse a tu origen y no recibe respuesta HTTP después de dos intentos (predeterminado). No HTTP 502 Bad Gateway
Media CDN intenta conectarse a tu origen principal y no puede conectarse (error de protocolo de enlace TLS). Se realiza un intento contra el origen de conmutación por error configurado, que muestra un 404 HTTP . Sí HTTP 404 Not Found
Media CDN intenta conectarse al origen principal y a la conmutación por error, pero no recibe código de estado HTTP. Sí HTTP 502 Bad Gateway

Si Media CDN recibe un código de estado que coincide con cualquiera retryConditions, como un error HTTP 404 Not Found o HTTP 429 Too Many Requests, y las solicitudes de origen de reintento y conmutación por error posteriores seguirán falla, se muestra un error 502 Bad Gateway de HTTP al cliente después del origen se agotan todos los intentos.

Prácticas recomendadas para la conmutación por error de origen

Cuando configures varios orígenes para la conmutación por error o el balanceo de cargas, asegúrate de que el comportamiento del encabezado de contenido multimedia Vary, ETag y Last-Modified sea coherente entre tus orígenes.

Como práctica recomendada, configura el redireccionamiento de origen solo para orígenes que confíes y controles. Asegúrate de confiar en cada origen en una cadena de redireccionamiento, ya que cada origen produce contenido que entrega tu EdgeCacheService.

¿Qué sigue?