Configura el comportamiento del almacenamiento en caché

Media CDN entrega contenido lo más cerca posible de los usuarios con 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 de cada ruta. Esto te permite optimizar el comportamiento en función del 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 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, 600 s si no hay directivas de caché de origen.
  • Almacena en caché los códigos de estado HTTP 200, 204 y 206 (el almacenamiento en caché negativo no está habilitado).

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

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 configurado de forma explícita 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 una ubicación de protección contra el origen. Si tu origen genera un encabezado de respuesta Age, usa el modo de almacenamiento en caché FORCE_CACHE_ALL para evitar las revalidaciones cuando la antigüedad supere 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 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 indicaron 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 contraídos 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ía 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é las respuestas no exitosas durante más tiempo del previsto, los códigos de estado que no son 2xx (no exitosos) no se almacenan en caché según su Content-Type (tipo de MIME) y no tienen aplicado el TTL predeterminado.

Los modos de almacenamiento en caché disponibles, que se configuran 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 medio, 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 un valor de forma explícita, se envía un valor predeterminado. Como resultado, todas las respuestas exitosas 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 medios, 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 Media CDN. 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 por anulaciones o con una directiva de caché, son optimistas. El contenido al que se accede con poca frecuencia o que es poco popular puede expulsarse 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 se establece cualquier valor de TTL en cero (0 segundos), se revalidará cada solicitud con el origen antes de que se entregue una respuesta y se aumentará la carga en el origen si se establece de forma demasiado amplia.

Cuando el modo de caché se establece en Use Origin Headers, no se pueden configurar los parámetros de configuración del TTL porque Media CDN depende del origen para controlar el comportamiento.

Notas:

• El valor del TTL máximo siempre debe ser mayor (o igual) que el valor del TTL predeterminado.
• El valor del TTL del cliente siempre debe ser menor que (o igual a) 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é las respuestas de error, como los redireccionamientos (HTTP 301 y 308) y las respuestas no encontradas (HTTP 404) más cerca de los usuarios, así como reducir la carga del origen de forma más amplia si es poco probable que la respuesta 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 para cada código de estado cuando el almacenamiento en caché negativo está habilitado 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 la contaminación de la caché.
• Se admite el código HTTP 451 (No disponible por motivos legales) para el almacenamiento en caché, como se describe en el 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 la contaminación de la caché, no recomendamos habilitar el almacenamiento en caché para los códigos de estado 400 (solicitud incorrecta) ni 403 (prohibido). Asegúrate de que tu servidor de origen devuelva uno 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 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 aptos para el almacenamiento en caché se siguen almacenando 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 explícitamente 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 1,800 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é se configura como FORCE_CACHE_ALL, las directivas de origen se ignoran en todos los casos.

Directivas de control de caché

Aquí se define el comportamiento de Media CDN con respecto a las directivas Cache-Control.

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

Siempre que sea posible, Media CDN cumple con la RFC (RFC 7234 de HTTP), pero prioriza la optimización para la descarga de caché y minimiza el impacto que los clientes pueden tener en el índice de hits y la carga de origen 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 la configuración de un origen (o reemplazarlo por completo) sin riesgo de "vaciar" la caché (por ejemplo, cuando migras 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. Borrar un EdgeCacheService invalida de manera efectiva todos los objetos almacenados en caché para 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 y 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

Puedes incluir o excluir parámetros de consulta específicos de una clave de caché agregando 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 búsqueda contentID y country, y omitir todos los demás de la clave de caché, haz lo siguiente:

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 o cualquier otro parámetro que solo sea único para el cliente. Incluir más parámetros de búsqueda de los necesarios puede reducir 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 la clave de caché. Por ejemplo, para excluir el ID de reproducción específico del cliente y la información de la marca de tiempo 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 uno de los valores 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 como true, de la siguiente manera:

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

Si la opción Signed requests está habilitada 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 búsqueda (cadenas de consulta) se ordenan de forma predeterminada para mejorar las tasas de acierto de caché, ya que los clientes pueden reordenar o solicitar el mismo objeto almacenado en caché con un orden diferente de los parámetros de búsqueda.

Por ejemplo, los parámetros de búsqueda 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 derivar 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 de este).

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.

Los siguientes encabezados no se pueden incluir en la clave de caché:

• Cualquier encabezado que comience con access-control-
• Cualquier encabezado que comience con sec-fetch-
• accept-encoding
• accept
• authorization
• 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.

Las cookies que comienzan con edge-cache- en cualquier variación de letras mayúsculas o minúsculas no se pueden usar 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 alcanzan su TTL configurado no se descarten de inmediato. En el caso del contenido popular, Media CDN revalida que la respuesta almacenada en caché sea la versión más reciente. Para ello, emite una solicitud HEAD al origen para confirmar que los encabezados no hayan cambiado.
• Es posible que las respuestas que establecen una directiva de caché max-age o s-maxage, o que usan una anulación del 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

Las siguientes consideraciones también se pueden aplicar con respecto al almacenamiento en caché.

Encabezados Vary

El encabezado Vary indica que la respuesta varía según los encabezados de 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 se configuran 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 medios 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 la organización de Google Cloud
• Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site: Se usan para recuperar encabezados de solicitudes 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 determinística.

Media CDN almacena en caché hasta 100 variantes para una clave de caché determinada y, más allá de ese límite, expulsa variantes de la caché de forma aleatoria. Cuando invalides explícitamente la caché para una URL o una etiqueta de caché determinadas, se invalidarán todas las variantes.

Omitir la caché

Puedes configurar el modo de caché BYPASS_CACHE en una ruta para omitir intencionalmente la caché en las solicitudes coincidentes. Esto puede ser útil si necesitas omitir la caché para una pequeña fracción del 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, tal como se definen en RFC 9110.

Además, Media CDN usa solicitudes de rango para recuperar respuestas más grandes del origen. Esto permite que Media CDN almacene en caché rangos de bytes individuales y no requiere que se recupere todo el objeto de una vez para almacenarlo en caché.

• Los objetos de más de 1 MiB se recuperan como solicitudes de rango de bytes 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 de más de 1 MiB no se entregan si no se admiten rangos de bytes en el origen.

La compatibilidad del 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 rango de bytes se registran como entradas de registro discretas y se asocian con su solicitud del cliente principal. Puedes agrupar estas solicitudes haciendo coincidir el valor de jsonPayload.cacheKeyFingerprint para cada una.

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

Solicitudes de rango multipartes

Media CDN admite solicitudes de rango multiparte, lo que permite a los usuarios solicitar varios segmentos no contiguos de un archivo en una sola solicitud HTTP, por ejemplo, Range: bytes=0-499, 1000-1499.

Para maximizar el rendimiento del cliente y la descarga del origen, Media CDN puede entregar los rangos de bytes individuales solicitados desde su caché y consolidarlos en una sola respuesta con un código de estado HTTP 206 Partial Response para el cliente con el Content-Type establecido en multipart/byteranges.

En el caso de las respuestas almacenables en caché, cuando un cliente solicita un rango de varias partes, Media CDN optimiza el proceso convirtiendo la solicitud en un conjunto de solicitudes de rango de una sola parte. Cada solicitud tiene un tamaño de 2 MB para cubrir todas las partes de los rangos de bytes solicitados por el cliente. Luego, Media CDN usa las respuestas para generar una sola respuesta de varias partes en el borde. Este enfoque permite un uso eficiente de la caché, reduce las recuperaciones redundantes del origen y admite casos de uso de gran volumen, como las descargas de la tienda de aplicaciones y las actualizaciones del SO.

En el caso del contenido que no se puede almacenar en caché, Media CDN reenvía la solicitud directamente al origen.

Solicitudes de rango abiertas

Media CDN admite solicitudes de 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.

Los clientes que solicitan segmentos de HLS de baja latencia de Apple suelen usar rangos de bytes abiertos: a medida que cada fragmento de CMAF se escribe en el cable, la CDN puede almacenarlo en caché y entregarlo 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 con el valor de configuración EdgeCacheOrigin.timeouts.readTimeout. Por lo general, este valor se debe configurar en un múltiplo (por ejemplo, 2 veces) 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.
• Para obtener más detalles sobre la configuración de recursos EdgeCacheService con Terraform, consulta la documentación del registro de Terraform.