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 otros contenidos estáticos.
• Se puede acceder a los orígenes mediante HTTP/2, HTTPS y HTTP/1.1 sin encriptar.
• Puedes configurar reglas de firewall para permitir solo direcciones IP específicas de Google, de modo que solo Media CDN pueda acceder a tus orígenes.
• Los reintentos y los comportamientos de conmutación por error se configuran por origen y pueden permitir que el servicio conmute por error graves (como errores de conectividad) o reintente 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 en las instalaciones 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 larga duración 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 significativo, 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:

De forma predeterminada, Media CDN proporciona protección de origen con un conjunto limitado de ubicaciones clave globales. El escudo de origen predeterminado funciona según la ubicación del usuario final y no la del origen. Esto funciona bien y proporciona grandes beneficios de descarga cuando los usuarios finales y los servidores de origen se encuentran en la misma región y cuando los servidores de origen globales se encuentran en varias regiones.

Protección flexible

En situaciones en las que tu origen se centraliza en una región, pero tus usuarios se distribuyen a nivel global, el comportamiento predeterminado de protección del origen, que se basa en la ubicación del usuario, podría ser subóptimo de las siguientes maneras:

• Aumenta la latencia de los errores de caché cuando la ubicación predeterminada del escudo está geográficamente lejos de tu origen centralizado.
• Se redujo la descarga del origen dispersando las solicitudes de llenado de caché en varias ubicaciones de protección predeterminadas globales en lugar de concentrarlas.

El blindaje flexible te ayuda a superar estas limitaciones, ya que te permite configurar una sola región geográfica específica para el blindaje de origen, que suele seleccionarse para que esté cerca de tu origen centralizado. Luego, la protección flexible enruta todas las solicitudes de llenado de caché a través de las cachés de protección ubicadas en la región configurada o cerca de ella. Esto consolida la carga en tu origen a través de esas cachés enfocadas en la región.

Si configuras una región de protección flexible en la misma región geográfica que tu origen centralizado, puedes optimizar lo siguiente:

• Tasa de aciertos de caché en la capa de protección
• Descarga de origen
• Latencia para errores de caché y contenido que no se puede almacenar en caché
• Estabilidad del rendimiento

La protección flexible es compatible con cualquier tipo de origen configurado en Media CDN.

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.

Todas las capas de almacenamiento en caché admiten la reducción de las solicitudes (o fusión) 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.

En combinación con la protección de origen, la reducción de solicitudes disminuye aún más la carga de origen y las necesidades de 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 relleno de origen, lo que significa que el origen ve los encabezados (incluido el usuario-agente) de ese cliente solamente.

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 versión 4 de la firma 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.

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ícita con el comportamiento de la conectividad de origen.
• Media CDN usa automáticamente el puerto correcto según 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:

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 rutas de servicio. Para obtener información sobre cómo configurar acciones de anulación por origen, consulta Conmutación por error de origen sin redireccionamiento.

Permite que el origen reciba tráfico de Media CDN

Para reducir el riesgo de acceso no autorizado a tu contenido, usa una lista de IP permitidas en el origen para bloquear el acceso a todas las direcciones IP, excepto los rangos de direcciones IP específicos que Google usa para enviar solicitudes a orígenes externos. De esta manera, solo Media CDN podrá conectarse a tus servidores de origen.

En la siguiente tabla, se resumen los rangos de direcciones IP de origen necesarios para las reglas de firewall:

Usa la siguiente URL para acceder al archivo JSON que contiene los rangos de direcciones IP actualizados asignados por Google.

https://www.gstatic.com/ipranges/mediacdn.json

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:

Considera los siguientes ejemplos:

• Origin A coincide con las solicitudes a “/segments/” y tiene un valor de maxAttemptsTimeout de 5s, un valor de maxAttempts de 1 y un valor de 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/*”, tiene un valor de maxAttemptsTimeout de 10s, un valor de maxAttempts de 3 y failover_origin no está configurado. El valor de connectTimeout se encuentra 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 completaron correctamente. 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 mostrar 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:

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:

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 posteriores de reintento y de origen de conmutación por error siguen fallando, se devuelve 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, verifica que el comportamiento del encabezado de contenido multimedia y 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?

• Configura un origen
• Usa un bucket privado compatible con Amazon S3 como origen
• Configura rutas de servicio