Descripción general de los orígenes

Media CDN te permite obtener contenido de tu infraestructura de origen, tanto si está alojado en Google Cloudcomo en otra nube o en un entorno on-premise.

Cada configuración puede tener uno o varios orígenes asociados. Las configuraciones de origen indican a Media CDN cómo conectarse a tu infraestructura, cuándo y cómo conmutar por error, reintentar y agotar el tiempo de espera, y qué protocolo usar al conectarse.

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 vídeo y otro contenido estático.
• Se puede acceder a los orígenes a través de HTTP/2, HTTPS y HTTP/1.1 sin cifrar.
• Puede configurar reglas de cortafuegos para permitir solo direcciones IP de Google específicas, de modo que solo Media CDN pueda acceder a sus 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 en caso de errores graves (como un fallo de conectividad) o que vuelva a intentar la conexión en función de las respuestas HTTP 404 Not Found o HTTP 429 Too Many Requests.
• Se puede acceder a los recursos privados que se encuentran en Google Cloud o en las instalaciones locales configurando un balanceador de carga de aplicación externo como origen detrás de Media CDN.
• El comportamiento de seguimiento de redirecciones se configura por origen. Puedes habilitar Media CDN para que siga las redirecciones a otros servidores de origen.

Requisitos de origen

Para permitir que Media CDN almacene en caché respuestas de origen de más de 1 MiB, un origen debe incluir lo siguiente en los encabezados de respuesta de las 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.
• 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 (donde 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 definir el campo de protocolo explícitamente para cada origen.

Protección de origen

Media CDN ofrece una infraestructura perimetral de niveles profundos diseñada para minimizar activamente el relleno de la caché siempre que sea posible.

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

1. Cachés de extremo profundo, que sirven la mayoría del tráfico y descargan dentro de la red de un proveedor de servicios.
2. El peering de Google, que está conectado a miles de proveedores de Internet y actúa como caché de nivel medio para las cachés de extremo y, en los casos en los que no están presentes en un proveedor de Internet determinado, como caché orientada al usuario.
3. Cachés de larga cola de la red de Google que rellenan otras cachés de nivel inferior antes del origen. Estas cachés admiten un gran número de solicitudes, tienen una capacidad de almacenamiento considerable y actúan como un escudo de origen.

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

Media CDN proporciona blindaje de origen de forma predeterminada mediante un conjunto limitado de ubicaciones globales clave. El escudo de origen predeterminado funciona en función de la ubicación del usuario final y no del origen. Esta opción funciona bien y ofrece grandes ventajas 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 están ubicados en varias regiones.

Apantallamiento flexible

En los casos en los que tu origen esté centralizado en una región, pero tus usuarios estén distribuidos por todo el mundo, el comportamiento predeterminado de protección del origen, que se basa en la ubicación del usuario, puede ser inadecuado por los siguientes motivos:

• Aumenta la latencia de los fallos de caché cuando la ubicación de protección predeterminada está geográficamente lejos de tu origen centralizado
• Se ha reducido la carga de origen dispersando las solicitudes de llenado de caché en varias ubicaciones de protección predeterminadas globales en lugar de concentrarlas.

El protección flexible te ayuda a superar estas limitaciones configurando una región geográfica única y específica para la protección del origen, que normalmente se selecciona para que esté cerca de tu origen centralizado. El cifrado flexible dirige todas las solicitudes de relleno de la caché a través de las cachés de protección ubicadas en la región configurada o cerca de ella. De esta forma, se consolida la carga en tu origen a través de esas cachés centradas 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 de contenido que no está en caché y que no se puede almacenar en caché
• Estabilidad del rendimiento

El blindaje flexible es compatible con cualquier tipo de origen configurado en Media CDN.

Solicitar que se contraiga

La solicitud de compresión comprime de forma activa varias solicitudes de relleno de caché controladas por el usuario para la misma clave de caché en una sola solicitud de origen por nodo de periferia.

Todas las capas de almacenamiento en caché admiten la combinación de solicitudes (o fusión) para reducir aún más la carga del origen. Basado en cargas de trabajo reales observadas a gran escala:

• Más del 95% de las entradas en caché utilizan un nodo de caché de larga cola específico en la región para reducir los costes y la latencia de las entradas en caché.
• El llenado de la caché entre el origen y la infraestructura perimetral de Google se realiza por completo a través de la red troncal privada global de Google, lo que reduce la latencia de llenado de la caché y mejora la fiabilidad. Ambas ventajas son muy útiles para las cargas de trabajo de streaming en directo.
• Las cachés se rellenan entre sí cuando es ventajoso hacerlo, lo que reduce aún más las tasas de relleno de la caché.
• Media CDN tiene una capacidad de almacenamiento significativa en todas las cachés, lo que minimiza las tasas de expulsión incluso en el caso del contenido menos popular y de larga duración.

Los clientes pueden ver diferentes tasas de descarga en función de la configuración de su caché, la carga de usuarios, las cargas de trabajo (como el contenido en directo frente al contenido bajo demanda), la distribución de los usuarios y la cantidad de contenido de larga duración (tamaño total del corpus) que sirven a los usuarios de diferentes regiones.

Si se combina con la protección de origen, la fusión de solicitudes reduce aún más la carga del origen y las necesidades de ancho de banda de salida, y es el comportamiento predeterminado de Media CDN.

Las solicitudes contraídas tienen registrada tanto la solicitud visible para el cliente como la solicitud de relleno de caché (contraída). El líder de la sesión contraída se usa para hacer la solicitud de relleno del origen, lo que significa que el origen ve los encabezados (incluido el User-Agent) 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 puede autenticar las solicitudes.

Orígenes y protocolos admitidos

Media CDN admite directamente cualquier endpoint HTTP accesible públicamente como origen, incluidos los siguientes:

• Segmentos de Cloud Storage, incluidos los segmentos privados, mediante cuentas de servicio de Gestión de Identidades y Accesos
• Balanceadores de carga de aplicación externos
• Segmentos compatibles con Amazon S3, incluidos los segmentos privados que usan la versión 4 de la firma de AWS
• Otro almacenamiento de objetos disponible públicamente, como Azure Blob Storage
• Servidores web disponibles públicamente, como máquinas virtuales públicas u hosts on-premise

La conectividad a los orígenes se realiza a través de túneles seguros y la red troncal mundial de Google.

En la siguiente tabla se detallan los protocolos de origen admitidos.

Media CDN usa HTTP/2 (h2) para conectarse a un origen de forma predeterminada. Tanto HTTP/2 como HTTPS requieren un certificado TLS (SSL) válido y de confianza pública. Un certificado válido es aquel que no ha caducado, que está firmado por una autoridad de certificación pública y que tiene un nombre alternativo de la entidad receptora que coincide con el nombre de host enviado al origen.

Notas:

• Si tu origen no admite HTTP/2, puedes definir explícitamente el protocolo (por origen) como 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, al configurar HTTP/2, la conexión no vuelve a HTTP/1.1 para ser explícita sobre el comportamiento de la conectividad de origen.
• Media CDN usa automáticamente el puerto correcto en función del protocolo: el puerto 80 para HTTP o el puerto 443 para HTTPS y HTTP/2.

Encabezados de solicitud de origen

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

En la siguiente tabla se indica 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.

Se ignorará cualquier ajuste de hostRewrite cuando se use un segmento de Cloud Storage como origen, ya que los segmentos de Cloud Storage no admiten valores de encabezado de host alternativos. La cabecera Host se define automáticamente en función del nombre del contenedor.

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

Para obtener información sobre cómo reescribir encabezados de host para la configuración por ruta, consulta Configurar rutas de servicio. Para obtener información sobre cómo definir acciones de anulación por origen, consulta Conmutación por error de origen sin seguimiento de redirección.

Permitir que el origen reciba tráfico de Media CDN

Para reducir el riesgo de que se acceda a tu contenido sin autorización, usa una lista de permitidas de IPs en el origen para bloquear el acceso a todas las direcciones IP, excepto a los intervalos de direcciones IP específicos que Google usa para enviar solicitudes a orígenes externos. De esta forma, solo Media CDN puede conectarse a tus servidores de origen.

En la siguiente tabla se resumen los intervalos de direcciones IP de origen necesarios para las reglas de cortafuegos:

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

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 para que responda 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 Media CDN intenta conectarse a un origen de conmutación por error si el primero no está disponible o devuelve un código de estado específico.

Tiempos de espera de origen

Los tiempos de espera te permiten configurar cuándo se activan los comportamientos de reintento y de conmutación por error del origen, así como 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 tarda Media CDN en encontrar una respuesta útil.

  Ambos tiempos de espera incluyen el tiempo que tarda el origen en devolver las cabeceras y en determinar si se debe usar una conmutación por error o una redirección. connectTimeout se aplica de forma independiente a 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 las redirecciones. Seguir una redirección cuenta como un intento adicional de conectarse al origen y se tiene en cuenta para el maxAttempts definido para el origen configurado.

  Cuando Media CDN recibe una respuesta que no es una redirección, como la de un origen de redirección o de failover, se aplican los valores readTimeout y responseTimeout. Los orígenes redirigidos usan los valores connectTimeout, readTimeout y responseTimeout configurados para el EdgeCacheOrigin que ha encontrado la redirección.

• responseTimeout y readTimeout controlan cuánto tiempo puede tardar una respuesta transmitida. Una vez que Media CDN determina que va a usar una respuesta upstream, ni connectTimeout ni maxAttemptsTimeout importan. En este punto, se aplican readTimeout y responseTimeout.

Media CDN hace como máximo cuatro intentos de origen en todos los orígenes, independientemente del maxAttempts definido por cada EdgeCacheOrigin. Media CDN usa el valor maxAttemptsTimeout del primario EdgeCacheOrigin. 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:

Ten en cuenta 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 de connectTimeout es el predeterminado: 5s. Si intentas conectarte a Origin A y la conexión falla en 1 segundo debido a un certificado TLS no válido, te quedarán unos 4 segundos para conectarte correctamente a Origin B.

• Origin C coincide con las solicitudes de "/manifests/*", tiene un valor maxAttemptsTimeout de 10s, un valor maxAttempts de 3 y failover_origin no está configurado. El valor de connectTimeout es el predeterminado, 5s. Media CDN intenta conectarse a Origin C hasta tres veces, con un máximo de 10 segundos (el límite de maxAttemptsTimeout) para establecer una conexión correcta.

Reintentar solicitudes de origen

Media CDN admite reintentos de origen, lo que permite volver a intentar las solicitudes al origen que no se hayan completado correctamente. Puedes especificar cuántas veces se puede volver a intentar la conexión con el origen actual antes de intentar conectarse a un origen de conmutación por error (si está configurado).

• Media CDN intenta acceder al origen principal hasta el valor maxAttempts configurado, que es 1 de forma predeterminada.
• Media CDN vuelve a intentar las conexiones de origen hasta un máximo de tres veces antes de fallar y devolver un error HTTP 502 Bad Gateway al usuario. Esto incluye las conexiones de origen de conmutación por error, que se tienen en cuenta para el límite de tres.
• Al configurar un recurso de origen, puede configurar un origen principal mediante el campo originAddress y, a continuación, un failoverOrigin opcional. El failoverOrigin apunta a otro recurso de origen.

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

Si necesitas comprobaciones de estado activas, round-robin o direccionamiento con reconocimiento de carga entre orígenes, puedes configurar un balanceador de carga de aplicación externo como origen principal.

Comportamiento de 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 alguno de los códigos retryConditions configurados, como un error HTTP 404 Not Found o HTTP 429 Too Many Requests, y las solicitudes posteriores de reintento y de conmutación por error del origen siguen fallando, se devuelve un error HTTP 502 Bad Gateway al cliente una vez que se han agotado los intentos de origen.

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

Cuando configure varios orígenes para la conmutación por error o el balanceo de carga, compruebe que el contenido multimedia y los comportamientos de los encabezados Vary, ETag y Last-Modified sean coherentes entre los orígenes.

Como práctica recomendada, configura la redirección de origen solo para los orígenes en los que confíes y que controles. Asegúrese de que confía en todos los orígenes de una cadena de redirección, ya que cada origen genera contenido que sirve su EdgeCacheService.

Siguientes pasos

• Configurar un origen
• Usar un segmento privado compatible con Amazon S3 como origen
• Configurar rutas de servicio