Configuración de caché

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

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

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:

  • Se respetan las directivas de caché de origen, como Cache-Control o Expires.
  • Almacena en caché tipos de contenido estático de automáticamente, con un TTL predeterminado de 3,600s.
  • Almacena en caché códigos de estado HTTP 200 y 206 (el almacenamiento en caché negativo no está habilitado).

• No almacena en caché las respuestas con las directivas no-cache o no-store, o que no pueden almacenarse 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:

Atributo HTTP	Requisitos
Código de estado	El código de estado de respuesta debe ser uno de los siguientes: 200, 203, 204, 206, 300, 301, 302, 307, 308, 400, 403, 404, 405, 410, 451 o 501
Métodos HTTP	GET, HEAD y OPCIONES
Encabezados de la solicitud	Los encabezados de solicitud no afectan si un elemento se debe almacenar en caché. Consulta las Directivas de control de caché para obtener más información.
Encabezados de respuesta	Contiene un encabezado Content-Length válido Contiene una directiva de almacenamiento en caché HTTP válida, como Cache-Control: max-age=3600, public. Tiene un modo de caché que almacena en caché ese contenido o tiene un encabezado Expires con una fecha en el futuro.
Tamaño de la respuesta	Hasta 50 GiB.

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 edad, usa el modo de almacenamiento en caché FORCE_CACHE_ALL para evitar las revalidaciones cuando Age 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 la Media CDN almacene las respuestas de origen en caché, 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 encabezado HTTP Date válido.
• Un encabezado Content-Length válido.
• El encabezado de respuesta Accept-Ranges: bytes.
• El encabezado de respuesta Content-Range, en respuesta a una solicitud GET Range. 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.

Nota: Las respuestas pequeñas (menos de 1 MiB) se almacenan en caché en su totalidad y no requieren compatibilidad con el encabezado Accept-Ranges o Content-Range.

Respuestas que no se pueden almacenar en caché

En la siguiente tabla, se detalla qué atributos de solicitud y respuesta 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é.

Atributo HTTP	Requisito
Código de estado	Un código de estado distinto de los definidos como almacenables en caché, como HTTP 400, HTTP 403 o HTTP 504. Estos códigos de estado suelen representar problemas para el cliente y no un estado de origen, y el almacenamiento en caché de esas respuestas puede generar situaciones de “envenenamiento de caché” en las que Una respuesta “incorrecta” activada por el usuario se almacena en caché para todos los usuarios.
Encabezados de la solicitud	Los encabezados de la solicitud no afectan si un elemento debe o no almacenarse en caché, a excepción del encabezado de la solicitud Authorization. Las respuestas deben incluir una directiva public de control de caché para almacenar en caché en este caso. Si deseas obtener más información, consulta Directivas de control de caché.
Encabezados de respuesta	Tienen un encabezado Set-Cookie. Tienen un encabezado Vary que no es Accept, Accept-Encoding ni Origin Tienen una directiva de control de caché no-store Tienen un encabezado Expires establecido en el pasado. Si el encabezado Cache-Control también se configura en la respuesta, se ignora el encabezado Expires.
Tamaño de la respuesta	Superior a 50 GiB.

Estas reglas se aplican además del modo de almacenamiento en caché. 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, siempre que la respuesta sea un código de estado que se puede almacenar en caché.
• 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 Cache-Control ni otros encabezados modificados y se envían mediante proxy “tal como están”.
• Las respuestas HTTP con varios campos de encabezado con el mismo nombre se contraen en un solo campo de encabezado, cuando corresponda. Por ejemplo, una respuesta con Cache-Control: no-cache y Cache-Control: no-store en líneas separadas se contraería como Cache-Control: no-cache, no-store.
• Las respuestas que no pueden almacenarse en caché (respuestas que nunca se almacenarían en caché) no se cuentan como salida de caché 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 contenido estático 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é de automáticamente los tipos de contenido estático comunes durante 1 hora (3,600 segundos), así como cualquierrespuesta almacenada en caché con directivas de caché válidas.
• Si deseas aumentar o disminuir el TTL de la caché aplicado a las respuestas sin un TTL de caché explícito (una directiva max-age o s-maxage), configura el campo cdnPolicy.defaultTtl en una ruta.
• Los códigos de estado que no son 2xx (no exitosos) no se almacenan en caché de acuerdo con su Content-Type (tipo de MIME) y no tienen aplicado el TTL predeterminado para evitar almacenar en caché respuestas que no sean exitosas por más tiempo del previsto.

Nota: Para configurar cómo se almacenan en caché las respuestas que no son 2xx, como los redireccionamientos (3xx), consulta Almacenamiento en caché negativo.

Los modos de almacenamiento en caché disponibles, que se establecen en el cdnPolicy.cacheMode de cada ruta, son los siguientes:

Modo de almacenamiento en caché	Comportamiento
USE_ORIGIN_HEADERS	Requiere respuestas de origen para establecer directivas de caché válidas y encabezados de almacenamiento en caché válidos. Si deseas obtener una lista completa de los requisitos, consulta la documentación de respuestas que se pueden almacenar en caché.
CACHE_ALL_STATIC	Almacena en caché automáticamente el contenido estático que no tiene la directiva no-store, private o no-cache. Las respuestas de origen que establecen directivas de almacenamiento en caché válidas también se almacenan en caché. El contenido estático incluye videos, audio, imágenes y elementos web comunes, según lo define el tipo de MIME en el encabezado de respuesta Content-Type.
FORCE_CACHE_ALL	Se almacenan en caché las respuestas correctas de forma incondicional y se anulan las directivas de caché que estableció el origen. Asegúrate de no entregar contenido privado por usuario (como HTML dinámico o respuestas de la API) con este modo configurado.
BYPASS_CACHE	Todas las solicitudes que coinciden con una ruta que tiene configurado este modo de caché omiten la caché, incluso si hay un objeto almacenado en caché que coincida con esa clave de caché. Solo recomendamos usar esto para depurar, ya que Media CDN está diseñada como una infraestructura de caché a escala mundial y no un proxy de uso general.

Nota: La versión actual de Media CDN no admite el modo de almacenamiento en caché BYPASS_CACHE. Si necesitas evitar el almacenamiento en caché de un conjunto pequeño de respuestas, configura un Cache-Control: no-store para evitar que una caché lo almacene en caché.

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.

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

Las respuestas no se almacenan en caché automáticamente si les falta 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.

Categoría	Tipos de MIME
Elementos web	text/css text/ecmascript text/javascript application/javascript
Fuentes	Cualquier tipo de contenido que coincida con font/*
Imágenes	Cualquier tipo de contenido que coincida con image/*
Videos	Cualquier tipo de contenido que coincida con video/*
Audio	Cualquier tipo de contenido que coincida con audio/*
Tipos de documentos con formato	application/pdf and application/postscript

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 la herramienta de gsutil para subir contenido.
• Si una respuesta se puede almacenar en caché según su tipo de MIME, pero tiene un encabezado de respuesta Cache-Control de private, no-store o no-cache, o un encabezado Set-Cookie, no se almacena en caché.

Importante: Otros tipos de contenido, 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 no son adecuadas para la arquitectura de Media CDN. Recomendamos usar Cloud CDN a fin de 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.

Ten en cuenta que los TTL, ya sean establecidos mediante anulaciones o a través de 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.

Existen tres opciones de configuración de TTL:

Parámetro de configuración	Predeterminado	Mín.	Máx	Descripción	Modos de almacenamiento en caché aplicables
Default TTL	1 hora (3,600 segundos)	0 segundos	1 año (31,536,000 segundos)	El TTL que se debe establecer cuando el origen no especificó un max-age o s-maxage. Si el origen especifica el encabezado s-maxage, se usa en lugar del valor de TTL predeterminado aquí. Cuando se usa FORCE_CACHE_ALL para almacenar en caché de forma incondicional todas las respuestas, se usa el TTL predeterminado a fin de establecer el TTL de la caché. Se ignoran todos los demás valores y directivas.	CACHE_ALL_STATIC FORCE_CACHE_ALL
Max TTL	1 día (86,400 segundos)	0 segundos	1 año (31,536,000 segundos)	El TTL máximo que se permite. Los valores superiores se limitan al valor de maxTtl.	CACHE_ALL_STATIC
Client TTL	No se establece de forma predeterminada.	0 segundos	1 mes (2,592,000 segundos)	El TTL que se debe establecer en la respuesta descendente (orientada al cliente) si esto debe ser diferente de otros valores de TTL. Esto solo se aplica a las respuestas exitosas (2xx).	CACHE_ALL_STATIC FORCE_CACHE_ALL

Establecer cualquier valor de TTL en cero (0 segundos) hace que cada solicitud se vuelva a validar con el origen antes de que se entregue una respuesta y aumenta la carga al origen si se configura de forma demasiado amplia.

Cuando el modo de caché está configurado en Usar encabezados de origen, no se puede establecer la configuración de TTL, ya que Media CDN se basa en el origen para impulsar el comportamiento.

Notas:

• El valor del TTL máximo siempre debe ser mayor o igual que el valor de TTL predeterminado.
• El valor del TTL de cliente siempre debe ser menor que (o igual que) el valor de TTL máximo.
• Cuando Media CDN de medios 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 no respuestas (HTTP 404) más cercanas a los usuarios, así como reducir la carga de origen de forma más amplia si es poco probable que la respuesta cambie y se puede almacenar en caché.

Nota: Para configurar cómo se almacenan en caché las respuestas correctas (códigos de estado 2xx), consulta modos de almacenamiento en caché y anulaciones de TTL.

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 negativeCachingPolicy no se usa.

Códigos de estado	Reason-phrase	TTL
HTTP 300	Opciones múltiples	10 minutos
HTTP 301 y HTTP 308	Redireccionamiento permanente	10 minutos
HTTP 404	No se encontró el elemento	120 segundos
HTTP 405	No se encontró el método	60 segundos
HTTP 410	No disponible	120 segundos
HTTP 451	No disponible por motivos legales	120 segundos
HTTP 501	No se implementó	60 segundos

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 es compatible con el almacenamiento en caché para 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 HTTP RFC 7725.

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 y 501.

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

Importante: Cuando configures un negativeCachingPolicy, especifica todos los códigos de estado (y sus TTL) que deseas almacenar en caché. Los TTL predeterminados (descritos en esta página) no se aplican cuando existe una política.

A fin de evitar el envenenamiento de caché, no recomendamos habilitar el almacenamiento en caché para el código de estado 400 (solicitud incorrecta) o el 403 (prohibido). Asegúrate de que el 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 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 que pueden almacenarse 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.
• A fin de ignorar directivamente las directivas de caché de origen para un código de estado específico, configura cdnPolicy.negativeCachingPolicy[].ttl como 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 de 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.

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.

Componente	¿Se incluye de forma predeterminada?	Detalles
Protocolo	No	Las solicitudes a través de HTTP y HTTPS hacen referencia al mismo objeto almacenado en caché. Si deseas mostrar las diferentes respuestas a las solicitudes http: y https:, configura cacheKeyPolicy.includeProtocol como verdadero en las rutas asociadas.
Host	Sí	Los hosts diferentes no hacen referencia a los mismos objetos almacenados en caché. Si tienes varios nombres de host dirigidos al mismo EdgeCacheService y entregan el mismo contenido, configura cdnPolicy.excludeHost como verdadero.
Ruta de acceso	Sí	Siempre se incluye en la clave de caché y no se puede quitar. La ruta de acceso es la representación mínima de un objeto en caché.
Parámetros de consulta	Sí	Si los parámetros de consulta no distinguen entre diferentes respuestas, configura cacheKeyPolicy.excludeQueryString como verdadero. Si solo algunos parámetros de consulta se deben incluir en una clave de caché, configura includedQueryParameters o excludedQueryParameters, según corresponda.
Encabezados	No	Configura cacheKeyPolicy.includedHeaderNames con los nombres de los encabezados que se incluirán en la clave de caché. Especifica varios encabezados que se combinan para tener un gran rango de valores (por ejemplo, los valores de encabezado combinados identifican a un solo usuario), reduce la tasa de aciertos de caché y puede generar una tasa de expulsión más alta y una reducción rendimiento. Si deseas obtener más detalles para incluir encabezados, consulta Incluye encabezados.
Cookies	No	Configura cacheKeyPolicy.includedCookieNames con los nombres de las cookies que se incluirán en la clave de caché. Especifica varias cookies que se combinan para tener un gran rango de valores (por ejemplo, los valores de cookie combinados identifican a un solo usuario), reduce la tasa de aciertos de caché de forma significativa y puede provocar una tasa de expulsión más alta y una reducción rendimiento. Si deseas obtener más detalles para incluir cookies, consulta Incluye cookies.

Ten en cuenta que las claves de caché tienen las siguientes características:

1. No se conecta a un origen configurado, lo que te permite actualizar una configuración de origen (o reemplazar el origen por completo) sin riesgo de “limpiar” la caché (por ejemplo, cuando migras almacenamiento de origen entre proveedores).
2. Limitado 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.
3. Si borras un EdgeCacheService, se invalidarán de forma efectiva todos los objetos almacenados en caché para ese servicio.
4. No tiene alcance de 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.
5. No incluyas 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”).
6. Cuando las solicitudes firmadas se configuran 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é si agregas el nombre del parámetro a la configuración de clave de caché includedQueryParameters o excludedQueryParameters en una ruta determinada.

Por ejemplo, para incluir los parámetros de consulta contentID y country y, también, ignorar 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 estadísticas, los ID de sesión de reproducción o cualquier otro parámetro que solo sea único para el cliente. Incluir más parámetros de consulta de los necesarios puede disminuir las tasas de aciertos 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 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 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, establece excludeQueryString en true de la siguiente manera:

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 firmar no se incluyen en la string 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 (strings de consulta) se ordenan de forma predeterminada para mejorar las tasas de aciertos 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 (y una respuesta desde) de 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.

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-
• 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.

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. El contenido al que se accede una pequeña cantidad de veces al día puede expulsarse.

• Es posible que las respuestas almacenadas en caché que alcanzan el TTL configurado no se expulsen de inmediato. Para el contenido popular, Media CDN valida que la respuesta almacenada en caché sea la versión más reciente mediante la emisión de una solicitud al origen con un encabezado de solicitud If-None-Match o If-Modified-Since.
• Los orígenes configurados de forma correcta muestran 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.
• Respuestas que configuran una directiva de caché max-age o s-maxage o que usan una anulación de TTL para especificar un valor de TTL alto (por ejemplo, 30 días) puede que no se almacene en caché para 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

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, debe especificar uno de los siguientes valores, o Media CDN no lo almacena en caché:

• Accept: Se usa para indicar qué tipos de contenido acepta el cliente
• Accept-Encoding: se usa para indicar qué tipos de compresión acepta el cliente
• Origin: Por lo general, se usa para uso compartido de recursos entre dominios

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

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

Omitir la caché

Puedes configurar el modo de almacenamiento en 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 la conectividad de origen de depuración.

Para los casos en los que necesites entregar respuestas dinámicas, como los backends de API, te recomendamos configurar un balanceador de cargas de HTTP(S) 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, como se define en RFC 7233, incluidas las solicitudes de rango de una sola parte y varios rangos de bytes.

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

• Los objetos de más de 2 MB se recuperan como solicitudes de rango de bytes (“fragmentos”).
• La respuesta hasta 2 MB de bytes se pueden recuperar sin compatibilidad con rangos de bytes en el origen.
• Las respuestas más grandes no se entregan si los rangos de bytes no son compatibles con el origen.

La compatibilidad de origen para solicitudes de rango de bytes se determina mediante lo siguiente:

• Un código de estado HTTP de 200 (OK) o 206 (contenido parcial).
• Encabezado de respuesta Accept-Ranges: bytes.
• Un encabezado de respuesta Content-Length o Content-Range válido.

Las solicitudes de relleno de origen individuales para cada “fragmento” (rango de bytes) se registran como entradas de registro discretas y se asocian con la solicitud del cliente superior. Puedes agrupar estas solicitudes si haces coincidir las solicitudes en el jsonPayload.cacheKeyFingerprint.

Consulta la documentación de Cloud Logging para obtener más detalles sobre lo que se registra.

Solicitudes de rango abierto

Nota: La infraestructura de origen debe admitir solicitudes Range de código abierto para satisfacer esta totalidad. Algunos orígenes, como Cloud Storage y Amazon S3, admiten solicitudes de rango abierto, pero no admiten objetos de transmisión hasta que se hayan escrito por completo.

Media CDN admite solicitudes de rango “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 usan los rangos de bytes abiertos son los que solicitan los segmentos de HLS de baja latencia de Apple. A medida que cada fragmento de CMAF se escribe en la línea, la CDN puede almacenar en caché y entregar y fragmentar 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, esto debe configurarse en un múltiplo (por ejemplo, 2 veces) de la duración objetivo.

Rangos de bytes multiparte

En particular, las solicitudes de rango de varias partes (por ejemplo, bytes=0-300,1200-2000) deben cumplir con los siguientes requisitos:

• Debe cumplir con RFC 7233 de HTTP.
• Los rangos deben estar solo en orden ascendente.
• Se pueden especificar un máximo de dos rangos en una sola solicitud.

La mayoría de los almacenes de objetos, incluidos Cloud Storage y Amazon S3, no admiten directamente solicitudes de rango de varias partes y muestran un error o muestran el objeto completo de forma implícita. Muchos proxies inversos y de almacenamiento en caché populares, incluido Varnish, tampoco admiten solicitudes de rango multiparte.

¿Qué sigue?

• Revisa 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.