Configura el comportamiento del almacenamiento en caché

Media CDN entrega contenido lo más cerca posible de los usuarios mediante la infraestructura de almacenamiento en caché perimetral global de Google para almacenar contenido en caché y reducir la carga en la infraestructura de origen.

Puedes controlar cómo se almacena en caché el contenido para cada ruta. Esto te permite optimizar el comportamiento según el tipo de contenido, los atributos de la solicitud del cliente y tus requisitos de actualización.

Capacidad de almacenamiento en caché

En las siguientes secciones, se describe qué respuestas almacena en caché Media CDN y cómo mejorar la descarga de caché.

Comportamiento de almacenamiento en caché predeterminado

De forma predeterminada, la siguiente configuración relacionada con la caché se aplica a cada servicio de almacenamiento en caché perimetral:

• Modo de almacenamiento en caché predeterminado de CACHE_ALL_STATIC:

  • Respeta las directivas de almacenamiento en caché del origen, como Cache-Control o Expires, hasta un TTL máximo configurable.
  • Almacena en caché tipos de medios estáticos automáticamente con un TTL predeterminado de 3,600s, si no hay directivas de caché de origen.
  • Almacena en caché los códigos de estado HTTP 200 y 206 (no se habilitó el almacenamiento en caché negativo).

• No almacena en caché las respuestas que tienen directivas de control de caché no-store o private, o que de otro modo no se pueden almacenar en caché.

Las respuestas que no son contenido estático o que no tienen directivas de caché válidas no se almacenan en caché, a menos que el almacenamiento en caché esté configurado de forma explícita. Para aprender a anular el comportamiento predeterminado, consulta la documentación sobre modos de almacenamiento en caché.

El comportamiento predeterminado es equivalente al siguiente cdnPolicy. Las rutas sin un cdnPolicy explícito configurado se comportan como si tuvieran la siguiente configuración:

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 3600s
  cacheKeyPolicy:
    includeProtocol: false
    excludeHost: false
    excludeQueryString: false
  signedRequestMode: DISABLED
  negativeCaching: false

Respuestas que se pueden almacenar en caché

Una respuesta almacenable en caché es una respuesta HTTP que Media CDN puede almacenar y recuperar rápido, lo que permite tiempos de carga más rápidos. No todas las respuestas HTTP pueden almacenarse en caché.

Puedes configurar los modos de almacenamiento en caché para cada ruta a fin de anular este comportamiento (por ejemplo, usar el modo de almacenamiento en caché CACHE_ALL_STATIC a fin de almacenar en caché tipos de medios comunes), incluso si el origen no está configurado. Una directiva de control de caché en la respuesta.

Las solicitudes y respuestas que cumplen con los criterios definidos en las respuestas que no se pueden almacenar en caché sustituyen la capacidad de almacenamiento en caché.

En la siguiente tabla, se describen los requisitos para almacenar en caché respuestas HTTP específicas. Las respuestas de GET y HEAD deben cumplir con estos requisitos.

El encabezado HTTP Age se establece en función de cuándo la Media CDN obtuvo por primera vez la respuesta y, por lo general, representa los segundos desde que el objeto se almacenó en caché en un ubicación de protección contra el origen. Si tu origen genera un encabezado de respuesta de Age, usa el modo de caché FORCE_CACHE_ALL para evitar las revalidaciones cuando Age exceda el TTL de la caché.

Para obtener más información sobre cómo Media CDN interpreta las directivas de almacenamiento en caché HTTP, consulta Directivas de control de caché.

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.

Respuestas que no se pueden almacenar en caché

En la siguiente tabla, se detallan los atributos de solicitud y respuesta que impiden que una respuesta se almacene en caché. Las respuestas que pueden almacenarse en caché, pero que coinciden con un criterio “no almacenable en caché”, no se almacenan en caché.

Estas reglas se aplican además del modo de almacenamiento en caché configurado. En particular, haz lo siguiente:

• Con el modo de almacenamiento en caché CACHE_ALL_STATIC configurado, solo las respuestas que se consideran contenido estático o las respuestas con directivas de caché válidas en sus encabezados de respuesta se almacenan en caché. Las demás respuestas se envían mediante proxy tal como están.
• El modo de almacenamiento en caché FORCE_CACHE_ALL almacena en caché todas las respuestas de forma incondicional, sujeto a los requisitos de no almacenamiento en caché que se mencionaron anteriormente.
• El modo de almacenamiento en caché USE_ORIGIN_HEADERS requiere respuestas para establecer directivas de caché válidas en sus encabezados de respuesta, además de ser un código de estado que puede almacenarse en caché.

Notas:

• Las respuestas que no se almacenan en caché no tienen sus directivas de control de caché ni otros encabezados modificados y se envían mediante proxy tal como están.
• Las respuestas pueden tener sus encabezados Cache-Control y Expires colapsados en un solo campo Cache-Control. Por ejemplo, una respuesta con Cache-Control: public y Cache-Control: max-age=100 en líneas separadas se contraerá como Cache-Control: public,max-age=100.
• Las respuestas que no pueden almacenarse en caché (respuestas que nunca se almacenarían en caché) no se cuentan como Cache Egress desde la perspectiva de facturación.

Usa modos de almacenamiento en caché

Los modos de almacenamiento en caché te permiten configurar cuándo Media CDN debe respetar las directivas de caché de origen, almacenar en caché tipos de medios estáticos y almacenar en caché todas las respuestas del origen, sin importar las directivas configuradas.

Los modos de almacenamiento en caché se configuran a nivel de ruta y, junto con las anulaciones de TTL, te permiten configurar el comportamiento de la caché por host, ruta de acceso, parámetros de consulta y encabezados (cualquier parámetro de solicitud que coincida).

• De forma predeterminada, Media CDN usa el modo de almacenamiento en caché CACHE_ALL_STATIC, que almacena en caché automáticamente los tipos de medios estáticos comunes durante 1 hora (3,600 segundos), a la vez que prioriza las directivas de caché que especifica el origen para las respuestas almacenables en caché.
• Puedes aumentar o disminuir el TTL de caché aplicado a las respuestas sin un TTL de caché explícito establecido (una directiva max-age o s-maxage) configurando el campo cdnPolicy.defaultTtl en una ruta.
• Para evitar que se almacenen en caché respuestas que no son correctas durante más tiempo del previsto, los códigos de estado que no son 2xx (no correctos) no se almacenan en caché según su Content-Type (tipo de MIME) y no se aplica el TTL predeterminado.

Los modos de almacenamiento en caché disponibles, que se establecen en el cdnPolicy.cacheMode de cada ruta, se muestran en la siguiente tabla.

Tipos de MIME de contenido estático

El modo de almacenamiento en caché CACHE_ALL_STATIC permite que Media CDN almacene en caché automáticamente el contenido estático común, como videos, imágenes y elementos web comunes, según el tipo de MIME que se muestra en el encabezado de respuesta HTTP Content-Type. Sin embargo, independientemente del tipo de contenido multimedia, Media CDN prioriza cualquier encabezado Cache-Control o Expires explícito en la respuesta del origen.

En la siguiente tabla, se enumeran los tipos de MIME que se pueden almacenar en caché automáticamente con el modo de almacenamiento en caché CACHE_ALL_STATIC.

Las respuestas no se almacenan en caché automáticamente si no tienen un encabezado de respuesta Content-Type con un valor que coincida con los siguientes valores. Debes asegurarte de que la respuesta establezca una directiva de caché válida o usar el modo de almacenamiento en caché FORCE_CACHE_ALL para almacenar respuestas en caché de forma incondicional.

Ten en cuenta lo siguiente:

• El software del servidor web de origen debe configurar el Content-Type para cada respuesta. Muchos servidores web configuran el encabezado Content-Type automáticamente, incluidos NGINX, Varnish y Apache.
• Cloud Storage configura el encabezado Content-Type automáticamente en la carga cuando usas la consola de Google Cloud o gcloud CLI para subir contenido.
• Cloud Storage siempre proporciona un encabezado Cache-Control a Media CDN. Si no se elige ningún valor de forma explícita, se envía un valor predeterminado. Como resultado, todas las respuestas correctas de Cloud Storage se almacenan en caché según los valores predeterminados de Cloud Storage, a menos que ajustes de forma explícita los metadatos de control de caché para los objetos en Cloud Storage o uses el modo FORCE_CACHE_ALL para anular los valores que envía Cloud Storage.

Si una respuesta se puede almacenar en caché según su tipo de MIME, pero tiene una directiva de respuesta Cache-Control de private o no-store o un encabezado Set-Cookie, no se almacena en caché.

Otros tipos de contenido multimedia, como HTML (text/html) y JSON (application/json), no se almacenan en caché de forma predeterminada. Estos tipos de respuestas suelen ser dinámicas (por usuario) y tampoco son adecuadas para la arquitectura de la CDN de Media. Recomendamos usar Cloud CDN para entregar elementos web y almacenar en caché respuestas de la API.

Configura los TTL para el almacenamiento en caché

Las anulaciones de tiempo de actividad (TTL) te permiten establecer valores de TTL predeterminados para el contenido almacenado en caché y anular los valores de TTL configurados en las directivas max-age y s-maxage de control de caché (o encabezados Expires). según tus orígenes.

Los TTL, ya sea que se establezcan mediante anulaciones o mediante una directiva de caché, son optimistas. Es posible que el contenido al que se accede con poca frecuencia o que no es popular se expulse de la caché antes de que se alcance el TTL.

En la siguiente tabla, se muestran tres parámetros de configuración de TTL.

Si estableces cualquier valor de TTL en cero (0 segundos), se volverá a validar cada solicitud con el origen antes de que se entregue una respuesta y se aumentará la carga al origen si se establece de forma demasiado amplia.

Cuando el modo de almacenamiento en caché se establece en Use Origin Headers, no se puede configurar la configuración de TTL porque Media CDN depende del origen para dirigir el comportamiento.

Notas:

• El valor de TTL máximo siempre debe ser mayor (o igual) que el valor de TTL predeterminado.
• El valor del TTL del cliente siempre debe ser menor (o igual) que el valor del TTL máximo.
• Cuando Media CDN anula un valor de TTL de origen, el encabezado Cache-Control para el cliente también refleja ese valor.
• Si el origen establece un encabezado Expires y Media CDN anula el TTL efectivo (según la marca de tiempo), el encabezado Expires se reemplaza por un encabezado Cache-Control en la respuesta descendente al cliente.

Almacenamiento en caché negativo

El almacenamiento en caché negativo define cómo los códigos de estado HTTP no exitosos (que no son 2xx) se almacenan en caché por Media CDN.

Esto te permite almacenar en caché respuestas de error, como redireccionamientos (HTTP 301 y 308) y respuestas de no encontrado (HTTP 404) más cerca de los usuarios, así como reducir la carga del origen de forma más amplia si es probable que la respuesta no cambie y se pueda almacenar en caché.

De forma predeterminada, el almacenamiento en caché negativo está inhabilitado. En la siguiente tabla, se muestran los valores predeterminados de cada código de estado cuando la caché negativa está habilitada y no se usa negativeCachingPolicy.

El conjunto predeterminado de códigos de almacenamiento en caché negativo coincide con los códigos de estado que se pueden almacenar en caché de forma heurística descritos en HTTP RFC 9110, con las siguientes excepciones:

• El código HTTP 414 (URI demasiado largo) no se admite para el almacenamiento en caché, a fin de evitar el envenenamiento de la caché.
• El código HTTP 451 (No disponible por motivos legales) es compatible con el almacenamiento en caché, como se describe en la RFC 7725 de HTTP.

Si necesitas configurar tus propios TTL por código de estado y anular el comportamiento predeterminado, puedes configurar un cdnPolicy.negativeCachingPolicy. Esto te permite establecer el TTL para cualquiera de los códigos de estado permitidos por Media CDN: 300, 301, 302, 307, 308, 400, 403, 404, 405, 410, 451, 500, 501, 502, 503 y 504.

Por ejemplo, a fin de establecer un TTL corto de 5 segundos para las respuestas HTTP 404 (no encontrado) y un TTL de 10 segundos para las respuestas HTTP 405 (método no permitido), usa la siguiente definición YAML en cada una ruta aplicable:

cdnPolicy:
  negativeCaching: true
  negativeCachingPolicy:
    "404": 5s
    "405": 10s
  # other status codes to apply TTLs for

Para evitar el envenenamiento de la caché, no recomendamos habilitar el almacenamiento en caché para el código de estado 400 (solicitud incorrecta) o 403 (prohibido). Asegúrate de que tu servidor de origen muestre cualquiera de los códigos como resultado de examinar solo los componentes de la solicitud que se incluyen en la clave de caché. El envenenamiento de la caché puede ocurrir, por ejemplo, cuando el servidor de origen responde con una respuesta de error 403 en ausencia de un encabezado Authorization correcto. En este caso, almacenar en caché la respuesta de error 403 hace que Media CDN entregue la respuesta de error 403 a todas las solicitudes posteriores hasta que caduque el TTL, incluso si las solicitudes tienen un encabezado Authorization correcto.

Para inhabilitar el almacenamiento en caché negativo, haz lo siguiente:

• Para inhabilitar el comportamiento de almacenamiento en caché negativo predeterminado, configura cdnPolicy.negativeCaching: false en una ruta. Ten en cuenta que las respuestas de origen con directivas de caché válidas y códigos de estado almacenables en caché aún se almacenan en caché.
• Para evitar el almacenamiento en caché negativo en un código de estado específico, pero respetar las directivas de caché de origen, omite el código de estado (cdnPolicy.negativeCachingPolicy[].code) en tu definición de negativeCachingPolicy.
• Para ignorar de forma explícita las directivas de caché de origen para un código de estado específico, establece cdnPolicy.negativeCachingPolicy[].ttl en 0 (cero) para ese código de estado.

Notas:

• Cuando negativeCaching está habilitado en una ruta y una respuesta define directivas de caché válidas, las directivas de caché en la respuesta tienen prioridad.
• Si configuras un negativeCachingPolicy explícito y hay un TTL definido para el código de estado determinado, siempre se usa el TTL definido en la política.
• El valor máximo para un TTL establecido por negativeCachingPolicy es de 1800 segundos (30 minutos), pero se respetan las directivas de caché de origen con un TTL más alto.
• Si el modo de almacenamiento en caché está configurado como FORCE_CACHE_ALL, se ignoran las directivas de origen en todos los casos.

Directivas de control de caché

Aquí se define el comportamiento de la CDN de medios con respecto a las direcciones Cache-Control.

Si la directiva no es aplicable a una solicitud o respuesta, como only-if-cached (una directiva solo para clientes), se marca "N/A" en esa columna.

Siempre que sea posible, Media CDN cumple con las RFC (HTTP RFC 7234), pero prioriza la optimización para la descarga de caché y minimiza el impacto que los clientes pueden tener en el índice de hits o en la carga de origen en general.

Para las respuestas que usan el encabezado Expires HTTP/1.1:

• El valor del encabezado Expires debe ser una fecha HTTP válida, como se define en RFC 7231.
• Un valor de fecha en el pasado, una fecha no válida o un valor de 0 indica que el contenido ya venció y requiere revalidación.
• Media CDN ignora el encabezado Expires si hay un encabezado Cache-Control en la respuesta.

El encabezado HTTP/1.0 Pragma, si está presente en una respuesta, se ignora y se pasa tal como está al cliente.

Claves de caché

Puedes reducir la cantidad de veces que Media CDN necesita comunicarse con el origen si consideras que identifica de manera inequívoca una solicitud y quita los componentes que a menudo pueden cambiar entre las solicitudes. A menudo, el conjunto de componentes de la solicitud se conoce como “clave de caché”.

En las siguientes secciones, se describe cómo configurar las claves de caché.

Componentes de la clave de caché

Una clave de caché es el conjunto de parámetros de solicitud (como el host, la ruta de acceso y los parámetros de consulta) a los que hace referencia un objeto almacenado en caché.

De forma predeterminada, las claves de caché para los servicios de almacenamiento en caché perimetral incluyen el host de solicitud, la ruta de acceso y los parámetros de consulta de la solicitud, y se limitan a un EdgeEdgeService específico.

Ten en cuenta lo siguiente:

• Las claves de caché no se adjuntan a un origen configurado, lo que te permite actualizar una configuración de origen (o reemplazar el origen por completo) sin riesgo de “borrar” la caché (por ejemplo, cuando se migra el almacenamiento de origen entre proveedores).
• Las claves de caché se limitan a un EdgeCacheService. Los diferentes EdgeCacheServices tienen diferentes espacios de nombres de caché, lo que evita que almacenes en caché objetos de manera accidental entre los entornos de producción, etapa de pruebas y otros entornos de prueba, incluso si el host, la ruta de acceso o algún otro componente de la clave de caché coincidieran. Si borras un EdgeCacheService, se invalidan de forma efectiva todos los objetos almacenados en caché de ese servicio.
• Las claves de caché no se limitan a una ruta individual. Varias rutas pueden hacer referencia a la misma clave de caché, en especial si esas rutas coinciden con componentes que no se incluyen en la clave de caché, como encabezados de solicitudes o parámetros excluidos. Esto puede ser útil si deseas que varias rutas compartan la misma caché, pero muestren diferentes encabezados de respuesta o configuración de CORS.
• Las claves de caché no incluyen la configuración de reescritura de URL. Por ejemplo, una clave de caché se basa en la solicitud para el usuario, no en la solicitud final “reescrita”.
• Cuando se configuran solicitudes firmadas en una ruta, los atributos firmados no se incluyen en la clave de caché. La solicitud se trata como si los parámetros de consulta o el componente de ruta (firmados) que comienzan con edge-cache-token y terminan en el siguiente separador de ruta (“/”) no son parte de la URL.

Incluir o excluir parámetros de consulta

Para incluir o excluir parámetros de consulta específicos de una clave de caché, agrega el nombre del parámetro a la configuración de la clave de caché includedQueryParameters o excludedQueryParameters en una ruta determinada.

Por ejemplo, para incluir los parámetros de consulta contentID y country, y Ignora todos los demás de la clave de caché:

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 86400s
  cacheKeyPolicy:
    includedQueryParameters: ["contentID", "country"]

Asegúrate de incluir los parámetros de consulta que identifican el contenido de manera inequívoca y excluye los que no lo hacen. Por ejemplo, excluye los parámetros de consulta de Analytics, los IDs de sesión de reproducción y otros parámetros que solo sean únicos para el cliente. Si incluyes más parámetros de consulta de los necesarios, es posible que disminuyan las tasas de acierto de caché.

Como alternativa, en lugar de especificar qué parámetros incluir en la clave de caché, puedes elegir qué parámetros excluir de ella. Por ejemplo, para excluir la información de ID de reproducción y marca de tiempo específica del cliente de la clave de caché, configura lo siguiente:

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 86400s
  cacheKeyPolicy:
    excludedQueryParameters: ["playback-id", "timestamp"]

Para una ruta determinada, puedes especificar una de includedQueryParameters o excludedQueryParameters.

Si los parámetros de consulta nunca se usan a fin de identificar de manera inequívoca el contenido entre las solicitudes, puedes quitar todos los parámetros de consulta de la clave de caché para una ruta. Para ello, configura excludeQueryString en true, como se indica a continuación:

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 3600s
  cacheKeyPolicy:
    excludeQueryString: true

Si las solicitudes firmadas están habilitadas en una ruta, los parámetros de consulta que se usan para la firma no se incluyen en la cadena de consulta y se ignoran si se incluyen. Incluir los parámetros firmados en la clave de caché hace que cada solicitud del usuario sea única y requiere que cada solicitud se entregue desde el origen.

Orden de parámetros de consulta

Los parámetros de consulta (cadenas de consulta) se ordenan de forma predeterminada para mejorar las tasas de acierto de caché, ya que los clientes pueden volver a ordenar o solicitar el mismo objeto almacenado en caché con un orden diferente de parámetros de consulta.

Por ejemplo, los parámetros de consulta b=world&a=hello&z=zulu&p=paris y p=paris&a=hello&z=zulu&b=world se ordenan como a=hello&b=world&p=paris&z=zulu antes de que se derive la clave de caché. Esto permite que ambas solicitudes se asignen al mismo objeto almacenado en caché, lo que evita una solicitud innecesaria al origen (y una respuesta del origen).

Si hay varias instancias de una clave de parámetro de consulta, cada una con valores distintos, los parámetros se ordenan según su valor completo (por ejemplo, a=hello se ordena antes de a=world). No se puede inhabilitar el orden.

Incluir encabezados

Los nombres de encabezado no distinguen mayúsculas de minúsculas, y la Media CDN los convierte en minúsculas.

No se pueden incluir los siguientes encabezados en la clave de caché:

• Cualquier encabezado que comience con access-control-
• Cualquier encabezado que comience con sec-fetch-
• Cualquier encabezado que comience con x-amz-
• Cualquier encabezado que comience con x-goog-
• Cualquier encabezado que comience con x-media-cdn-
• accept-encoding
• accept
• authorization
• cdn-loop
• connection
• content-md5
• content-type
• cookie
• date
• forwarded
• from
• host
• if-match
• if-modified-since
• if-none-match
• origin
• proxy-authorization
• range
• referer
• referrer
• user-agent
• want-digest
• x-csrf-token
• x-csrftoken
• x-forwarded-for

Para incluir el método HTTP en la clave de caché, usa el nombre de encabezado especial :method.

Incluir cookies

Los nombres de cookies distinguen mayúsculas de minúsculas.

No se pueden usar cookies que comiencen con edge-cache- en ninguna variación de letras mayúsculas o minúsculas en la clave de caché.

Revalidación, expulsión y vencimiento

Las redes de distribución de contenidos, incluida la Media CDN, operan mediante el almacenamiento en caché del contenido más popular lo más cerca posible de los usuarios.

El almacenamiento extenso de Media CDN, así como la protección de origen, limitan la necesidad de expulsar contenido incluso poco popular. Es posible que, con el tiempo, se expulse el contenido al que se accede una pequeña cantidad de veces por día.

• Es posible que las respuestas almacenadas en caché que alcancen su TTL configurado no se eliminen de inmediato. En el caso del contenido popular, Media CDN vuelve a validar que la respuesta almacenada en caché sea la versión más reciente mediante la emisión de una solicitud HEAD al origen para confirmar que los encabezados no hayan cambiado. En algunas circunstancias, Media CDN envía una solicitud al origen con uno o ambos de estos encabezados de solicitud: If-None-Match y If-Modified-Since. En este caso, los orígenes configurados de forma correcta deberían mostrar una respuesta HTTP 304 (sin modificar), sin los bytes del cuerpo, si el almacenamiento en caché tiene la copia “más reciente” de esa respuesta.
• Es posible que las respuestas que establezcan una directiva de caché max-age o s-maxage, o que usen una anulación de TTL para especificar un valor de TTL alto (por ejemplo, 30 días) no se almacenen en la caché durante el TTL completo. No se garantiza que un objeto se almacene en la caché todo el tiempo, en especial si se accede a él con poca frecuencia.

Si ves una tasa alta de expulsiones, debes asegurarte de haber configurado tus claves de caché para excluir parámetros que no identifiquen una respuesta de manera inequívoca.

Otras consideraciones

Es posible que también se apliquen las siguientes consideraciones con respecto al almacenamiento en caché.

Encabezados Vary

El encabezado Vary indica que la respuesta varía según los encabezados de la solicitud del cliente. Si hay un encabezado Vary presente en la respuesta, Media CDN no lo almacena en caché, a menos que el encabezado especifique uno de los encabezados que están configurados como un parámetro de configuración de clave de caché o uno de los siguientes valores:

• Accept: Se usa para indicar qué tipos de contenido multimedia acepta el cliente
• Accept-Encoding: se usa para indicar qué tipos de compresión acepta el cliente
• Available-Dictionary: Se usa para proporcionar el hash de un diccionario disponible para la compresión.
• Origin/X-Origin: Por lo general, se usa para uso compartido de recursos entre dominios
• X-Goog-Allowed-Resources: Admite la restricción de organizaciones de Google Cloud.
• Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site: Se usa para recuperar encabezados de solicitud de metadatos.

Media CDN almacena en caché las respuestas con un encabezado Vary en la respuesta usando el valor del encabezado como parte de la clave de caché. Si el encabezado Vary de la respuesta tiene varios valores, se ordenan lexicográficamente para garantizar que la clave de caché sea determinista.

Media CDN almacena en caché hasta 100 variantes para una clave de caché determinada y expulsa de forma aleatoria las variantes de la caché que superen ese límite. Cuando invalidas de forma explícita la caché de una URL o etiqueta de caché determinadas, se invalidan todas las variantes.

Omitir la caché

Puedes configurar el modo de caché BYPASS_CACHE en una ruta para omitir de forma intencional la caché en las solicitudes coincidentes. Esto puede ser útil si necesitas omitir la caché para una pequeña fracción de tráfico no crítico o depurar la conectividad del origen.

Para los casos en los que necesites entregar respuestas dinámicas, como los backends de API, te recomendamos configurar un balanceador de cargas de aplicaciones externo.

Por lo general, se recomienda limitar el uso a las situaciones de depuración para evitar la carga de origen involuntaria. El tráfico que sale cuando se omite la caché tiene un precio según las tarifas de salida de Internet.

Invalidación de caché

Consulta Invalidación de caché.

Solicitudes de rango de bytes

Media CDN admite solicitudes de rango HTTP de una sola parte, como se define en la RFC 7233.

Además, Media CDN también usa solicitudes de rango para recuperar respuestas más grandes del origen. Esto permite que Media CDN almacene en caché fragmentos de forma individual y no requiera que se recupere todo el objeto a la vez para almacenarlo en caché.

• Los objetos de más de 1 MiB se recuperan como solicitudes de rango de bytes (“fragmentos”) de hasta 2 MiB cada uno.
• Las respuestas de hasta 1 MiB se pueden recuperar sin compatibilidad con rangos de bytes en el origen.
• Las respuestas mayores que esta no se entregan si los rangos de bytes no son compatibles con el origen.

La compatibilidad de origen con las solicitudes de rango de bytes se determina de la siguiente manera:

• Un código de estado HTTP de 200 (OK) o 206 (contenido parcial).
• Un encabezado de respuesta Content-Length o Content-Range válido.
• Un validador de respuestas (ETag o Last-Modified)

Las solicitudes de llenado de origen individuales para cada "fragmento" (rango de bytes) se registran como entradas de registro discretas y se asocian con su solicitud de cliente superior. Puedes agrupar estas solicitudes haciendo coincidir las solicitudes en jsonPayload.cacheKeyFingerprint.

Para obtener más detalles sobre lo que se registra, consulta la documentación de Cloud Logging.

Solicitudes de rango abierto

Media CDN admite solicitudes Range “abiertas” (por ejemplo, una solicitud con Range: bytes=0-) que mantienen una solicitud abierta en el origen hasta que el origen cierra la respuesta (por ejemplo, el origen escribe todos los bytes al cable) o se agota el tiempo de espera.

Por lo general, los clientes que solicitan segmentos de HLS de baja latencia de Apple usan rangos de bytes abiertos: a medida que cada fragmento de CMAF se escribe en el cable, la CDN puede almacenar en caché y entregar ese fragmento a los clientes.

En otros casos, como cuando no se requiere interoperabilidad con DASH, la lista de reproducción de medios le indica al jugador qué bytes representan cada fragmento:

  #EXTINF:4.08,
  fs270.mp4
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=20000@0
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=23000@20000
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=18000@43000
  #EXT-X-PRELOAD-HINT:TYPE=PART,URI="fs271.mp4",BYTERANGE-START=61000

Puedes configurar cuánto tiempo debe esperar CDN Media entre lecturas mediante el valor de configuración EdgeCacheOrigin.timeouts.readTimeout. Por lo general, se debe configurar en un múltiplo (por ejemplo, el doble) de la duración objetivo.

¿Qué sigue?

• Revisa el enrutamiento avanzado.
• Obtén información para conectarte a diferentes orígenes.
• Configura certificados TLS (SSL) para tu servicio.
• Configura las solicitudes firmadas para autenticar el acceso al contenido.