Descripción general de los orígenes

Media CDN te permite recuperar contenido de la infraestructura de origen, ya sea que el contenido esté alojado en Google Cloud, en otra 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 las siguientes características:

  • Los orígenes se pueden definir por host y por ruta, lo que permite que un solo recurso EdgeCacheService se asigne a varios orígenes que contengan, por ejemplo, manifiestos, segmentos de video y otro contenido estático.
  • Se puede acceder a los orígenes mediante HTTP/2, HTTPS y HTTP/1.1 sin encriptar.
  • Los reintentos y los comportamientos de conmutación por error se configuran por origen y pueden permitir que el servicio realice una conmutación por error en errores graves (como errores de conectividad) o reintentar 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 si configuras un balanceador de cargas de aplicaciones externo como un 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

Para permitir que Media CDN almacene en caché las respuestas de origen de más de 1 MiB, un origen debe incluir lo siguiente en los encabezados de respuesta para las solicitudes de 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. Las cachés de cola larga se almacenan en caché dentro de la red de Google de las que otras cachés descendentes se llenan antes del origen. Estas memorias caché admiten fan-in significativa, tienen una capacidad de almacenamiento sustancial de caché y actúan 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 la reducción de las solicitudes (“fusionadas”) para reducir aún más la carga de origen. Según las cargas de trabajo reales observadas a gran escala:

  • Más del 95% del llenado de caché usa un nodo de caché de cola larga dedicado dentro de 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 todas las memorias caché, lo que minimiza las tasas de expulsión incluso para el contenido de cola larga y menos popular.

Los clientes pueden ver diferentes tasas de descarga en función de la configuración de la caché, la carga de usuarios, las cargas de trabajo (como en vivo o a pedido), la distribución de usuarios y la cantidad de contenido de cola larga (tamaño total del corpus) que entregan a los usuarios en 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 se usa para realizar la solicitud de llenado de origen, lo que significa que el origen ve los encabezados (incluido el usuario-agente) de solo 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, incluidos los buckets privados que usan la Firma versión 4 de AWS
  • 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 se configura HTTP/2, la conexión no "revierte" a HTTP/1.1 para ser explícito con el comportamiento de la conectividad de origen.
  • 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 se conecta 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 cómo configurar acciones de anulación por origen, consulta Conmutación por error del 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 se activan los comportamientos de reintento y conmutación por error del origen, y cuándo se puede activar la conmutación por error del cliente posterior.

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

  • 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 coincide con las solicitudes a "/segments/" y tiene un valor maxAttemptsTimeout de 5s, un valor maxAttempts de 1 y un valor failover_origin de Origin B. El valor predeterminado de connectTimeout es 5s. Si intentas conectarte a Origin A y falla en 1 segundo debido a un certificado TLS no válido, te quedan unos 4 segundos para realizar una conexión exitosa con Origin B.

  • Origin C hace coincidir las solicitudes con “/manifests/*” y tiene un valor maxAttemptsTimeout de 10s, un valor maxAttempts de 3 y failover_origin no configurado. El valor de connectTimeout está en su valor predeterminado de 5s. Media CDN intenta conectarse a Origin C hasta tres veces, lo que permite hasta 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 que se vuelvan a realizar solicitudes al origen que no se pudieron entregar. 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 alcanzar el origen principal hasta el valor maxAttempts configurado, 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 las conexiones de origen de la conmutación por error, que se consideran en 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 errores de enrutamiento, DNS y TLS, y tiempos de espera de TCP/UDP.
HTTP_5XX Vuelve a intentarlo en cualquier código de estado HTTP 5xx.
GATEWAY_ERROR Es similar a 5xx, pero solo se aplica a los códigos de estado 502, 503 o 504.
RETRIABLE_4XX Vuelve a intentarlo para los códigos de estado 4xx que se pueden reintentar, incluidos 409 y 429.
NOT_FOUND Vuelve a intentarlo en un código de estado HTTP 404.
FORBIDDEN Vuelve a intentarlo en un código de estado HTTP 403.

Si necesitas verificaciones de estado activas, round robin o dirección de reconocimiento de carga en los orígenes, puedes configurar un balanceador de cargas de aplicaciones externo como el origen principal.

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 en el origen de conmutación por error configurado, que muestra un error HTTP 404. 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 cualquier retryConditions configurado, 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 siguen fallando, se muestra un error HTTP 502 Bad Gateway al cliente después de que se agoten los intentos de origen.

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?