Configura el comportamiento del almacenamiento en caché

Media CDN entrega contenido lo más cerca posible de los usuarios usando 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 según el tipo de contenido, los atributos de la solicitud del cliente y tu actualización de software.

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é de origen, como Cache-Control o Expires, hasta un TTL máximo configurable.
    • Almacena en caché tipos de medios estáticos automáticamente con una TTL predeterminado de 3,600 s, si no hay directivas de caché de origen.
    • 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 que tienen control de caché no-store o private o que 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 a la siguiente cdnPolicy. Rutas sin una cdnPolicy explícita configurada se comporta como si tuviera actual:

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

La siguiente tabla describe los requisitos para almacenar en caché una HTTP específica de respuestas ante incidentes. Las respuestas GET y HEAD deben cumplir con estos requisitos.

Atributo HTTP Requisitos
Código de estado El código de estado de la respuesta debe ser 200, 203, 206, 300, 301, 302. 307, 308, 400, 403, 404, 405, 410, 451, 500, 501, 502, 503 o 504.
Métodos HTTP GET y HEAD
Encabezados de solicitud La mayoría de las directivas de solicitud de almacenamiento en caché se ignoran. Para obtener más información, consulta Directivas de control de caché.
Encabezados de respuesta

Contiene un almacenamiento en caché HTTP válido directiva, 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 futura.
Tamaño de la respuesta Hasta 100 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 el origen genera un encabezado de respuesta Edad, usa el modo de almacenamiento en caché FORCE_CACHE_ALL para y evitar revalidaciones cuando la Edad supere el TTL de 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

Permitir que Media CDN almacene en caché respuestas de origen de más de 1 MiB, el origen debe incluir lo siguiente en los encabezados de respuesta para solicitudes HEAD y GET, a menos que se especifique lo contrario:

  • Un encabezado de respuesta HTTP Last-Modified o ETag (un validador)
  • Un encabezado HTTP Date válido.
  • Un encabezado Content-Length válido.
  • 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 para que no se almacene una respuesta en caché. Respuestas que se pueden almacenar en caché, pero que coinciden "no se puede almacenar en caché" los criterios 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 401 HTTP 412 o HTTP 505.

Por lo general, estos códigos de estado representan los problemas que tiene el cliente y no el estado de origen. Si esas respuestas se almacenan en caché, se puede almacenar envenenamiento" situaciones en las que un error "mala" activado por el usuario respuesta se almacena en caché por para todos los usuarios.
Encabezados de solicitud

Para solicitudes con una solicitud Authorization encabezado, las respuestas deben incluir un control de caché public que se almacene en caché.

Una directiva no-store en la solicitud provoca la que no se almacene en caché. Para obtener más información, consulta Directivas de control de caché.
Encabezados de respuesta

Tienen un encabezado Set-Cookie.

Tiene un encabezado Vary distinto de Accept, Accept-Encoding, Origin X-Origin, X-Goog-Allowed-Resources, Sec-Fetch-Dest, Sec-Fetch-Mode o Sec-Fetch-Site.

En CACHE_ALL_STATIC o El modo USE_ORIGIN_HEADERS tiene un no-store o la directiva de control de caché private.
Tamaño de la respuesta Más de 100 GiB.

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 contenido estático o 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 capacidad de almacenamiento en caché mencionados anteriormente.
  • El modo de almacenamiento en caché USE_ORIGIN_HEADERS requiere que se configuren respuestas directivas de caché válidas en sus encabezados de respuesta en además de ser un código de estado que se puede almacenar en caché.

Notas:

  • Las respuestas que no se almacenan en caché no tienen sus directivas de control de caché o otros encabezados cambiaron y se envían mediante proxy tal como están.
  • Se pueden contraer los encabezados Cache-Control y Expires de las respuestas. 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.
  • No se cuentan las respuestas que no se pueden almacenar en caché (es decir, las que nunca se almacenarían en caché). como Cache Egress desde una perspectiva de facturación.

Usa modos de almacenamiento en caché

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

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 automáticamente en caché los tipos de medios estáticos comunes por 1 hora (3,600 segundos), al tiempo que prioriza las directivas de caché especificadas por el origen para las respuestas que se pueden almacenar en caché.
  • Puedes aumentar o disminuir el TTL de caché que se aplica a las respuestas sin un establecido el TTL de caché explícito (una directiva max-age o s-maxage) estableciendo cdnPolicy.defaultTtl en una ruta.
  • Para evitar almacenar en caché respuestas no exitosas por 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 el TTL predeterminado se aplicó.

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

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. Para ver una lista completa de los requisitos, consulta Respuestas que se pueden almacenar en caché.
CACHE_ALL_STATIC

Almacena automáticamente en caché las respuestas correctas con contenido estático, a menos que tengan no-store o private directiva. Se priorizan las directivas de almacenamiento en caché válidas del origen.

El contenido estático incluye videos, audios, imágenes y recursos web comunes, como definido por el tipo de MIME en la respuesta de Content-Type encabezado.
FORCE_CACHE_ALL

Almacena en caché las respuestas correctas de manera incondicional, lo que anula cualquier caché directivas establecidas por el origen.

Asegúrate de no publicar contenido privado por usuario (como HTML dinámico) o respuestas de la API) con este modo configurado.
BYPASS_CACHE

Cualquier solicitud que coincida con una ruta con este modo de almacenamiento en caché configurado la caché, incluso si hay un objeto en caché que coincide con esa clave.

Recomendamos usar esta opción solo para depuración, ya que Media CDN se diseñó como infraestructura de caché a escala mundial y no como un uso general proxy.

Tipos de MIME de contenido estático

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

En la siguiente tabla, se indican 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 Content-Type. con un valor que coincida con los siguientes valores. Debes asegurarte que la respuesta establezca una directiva de caché válida debes usar el modo de almacenamiento FORCE_CACHE_ALL en caché de forma incondicional de respuestas ante incidentes.

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 Directiva de respuesta Cache-Control de private o no-store o un encabezado Set-Cookie, no se almacena en caché.

Configura los TTL para el almacenamiento en caché

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

Los TTL, ya sea que se establezcan mediante anulaciones o a través de una directiva de caché, optimista. Es posible que se expulse el contenido al que se accede con muy poca frecuencia o que es poco popular a la caché antes de alcanzar el TTL.

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

Configuración Predeterminado Mínimo Máximo 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 configurará cuando el origen no haya especificado un max-age o un encabezado s-maxage.

Si el origen especifica un encabezado s-maxage, se usa en su lugar. del valor de TTL predeterminado.

Cuando usas FORCE_CACHE_ALL para almacenar en caché todo de forma incondicional respuestas, se usa el TTL predeterminado para configurar el TTL de caché. Todos los demás valores y directivas se ignoran.

CACHE_ALL_STATIC

FORCE_CACHE_ALL
Max TTL 1 día
(86,400 segundos)		 0 segundos 1 año
(31,536,000 segundos)		 Para respuestas que se pueden almacenar en caché, es el TTL máximo que se permite. Valores superiores a se limita al valor de maxTtl. CACHE_ALL_STATIC
Client TTL No establecido de forma predeterminada. 0 segundos 1 día
(86,400 segundos)		 Para las respuestas que se pueden almacenar en caché, es el TTL máximo que se permite en las fases (orientada al cliente) si debe ser diferente de otros TTL. de salida.

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 es demasiado amplio.

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

Notas:

  • El valor de TTL máximo siempre debe ser mayor (o igual) que el valor de el 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 Cache-Control al 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 (los que no 2xx) se almacenan en caché a través de Media CDN.

Esto te permite almacenar en caché respuestas de error, como redireccionamientos (HTTP 301 y 308) y no encontradas (HTTP 404) más cerca de los usuarios, además de reducir se cargan de forma más amplia si es probable que la respuesta no cambie y se puede almacenar en caché.

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

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 el que se puede almacenar de forma heurística en caché. los códigos de estado 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 la caché envenenamiento.
  • El código HTTP 451 (no disponible por motivos legales) es compatible con el almacenamiento en caché, como descritos en HTTP RFC 7725:

Si necesitas configurar tus propios TTL por código de estado y anular el puedes configurar un cdnPolicy.negativeCachingPolicy. Esto te permite Configura el TTL de cualquiera de los códigos de estado que permite 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 código de estado 400 (Solicitud incorrecta) o 403 (Prohibido). Asegúrate de que tu servidor de origen Devuelve cualquiera de los códigos como resultado de examinar solo los componentes de la solicitud. incluidas en la clave de caché. El envenenamiento de la caché puede ocurrir, por ejemplo, cuando el servidor de origen responde con un error 403 si no Encabezado Authorization. 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 estados que pueden almacenarse en caché los códigos 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 explícitamente las directivas de caché de origen para un estado específico code, 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 tendrán prioridad.
  • Si configuras un negativeCachingPolicy explícito y hay un TTL definido para el código de estado proporcionado, el TTL definido en la política siempre es que se usan.
  • El valor máximo para un TTL establecido por negativeCachingPolicy es 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é está configurado como FORCE_CACHE_ALL, origen directivas se ignoran en todos los casos.

Directivas de control de caché

El comportamiento de Media CDN con respecto Directivas Cache-Control se define aquí.

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

Directiva Solicitud Respuesta
no-cache La directiva de solicitud no-cache se ignora para evitar que los clientes inicien o forzar una revalidación al origen.

Una respuesta con no-cache se almacena en caché, pero requiere la validación con el origen antes de que se pueda entregar.

Esto se puede anular por ruta con el Modo de almacenamiento en caché FORCE_CACHE_ALL.
no-store La respuesta a una solicitud con no-store no se almacena en caché.

Una respuesta con no-store no se almacena en caché.

Se puede anular por ruta con el modo de caché FORCE_CACHE_ALL.
public N/A

Una respuesta con la directiva public se almacena en caché si la respuesta se considera que puede almacenarse en caché en su totalidad y esta tiene una directiva max-age o s-maxage, como en la nube.

Cuando uses la caché CACHE_ALL_STATIC o FORCE_CACHE_ALL. Esto no es obligatorio.
private N/A

Una respuesta con la directiva private no se almacena en caché Media CDN, incluso si la respuesta se considera de otro modo almacenable en caché. Los clientes (como los navegadores) aún pueden almacenar en caché el resultado.

Esto se puede anular por ruta con el Modo de almacenamiento en caché FORCE_CACHE_ALL.

Usa no-store para evitar todo el almacenamiento en caché de las respuestas.
max-age=SECONDS Se ignora la directiva de solicitud max-age. Se muestra una respuesta en caché como si este encabezado no se incluyera en la solicitud. Una respuesta con la directiva max-age se almacena en caché hasta el SECONDS definido.
s-maxage=SECONDS N/A

Una respuesta con la directiva s-maxage se almacena en caché hasta el SECONDS definido.

Si max-age y s-maxage están presentes, El servidor usa s-maxage.

Ten en cuenta que s-max-age (dos guiones) no es válido para para almacenar datos en caché.
min-fresh=SECONDS Se ignora la directiva de solicitud min-fresh. Una respuesta almacenada en caché se muestra como si este encabezado no estuviera incluido en la solicitud. N/A
max-stale=SECONDS

Se ignora la directiva de solicitud max-stale.

Se muestra una respuesta almacenada en caché como si este encabezado no estuviera incluido en la solicitud.

 N/A
stale-while-revalidate=SECONDS N/A Sin efecto. Esto se pasa al cliente en la respuesta.
stale-if-error=SECONDS Se ignora la directiva de solicitud stale-if-error. Se muestra una respuesta en caché como si este encabezado no se incluyera en la solicitud. Sin efecto. Esto se pasa al cliente en la respuesta.
must-revalidate N/A

Una respuesta con must-revalidate se vuelve a validar con el servidor de origen después de que caduque.
proxy-revalidate N/A

Una respuesta con proxy-revalidate se vuelve a validar con el origen servidor una vez que caduque.
immutable N/A Sin efecto. Esto se pasa al cliente en la respuesta.
no-transform N/A Media CDN no aplica transformaciones.
only-if-cached Se ignora la directiva de solicitud only-if-cached. Se muestra una respuesta en caché como si este encabezado no se incluyera en la solicitud. N/A

Siempre que sea posible, Media CDN cumple con RFC (HTTP RFC 7234), pero favorece optimizar la descarga de la caché y minimizar el impacto que los clientes pueden tener en la tasa de aciertos 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 definida en la RFC 7231
  • Un valor de fecha pasada, una fecha no válida o un valor de 0 indica que si el contenido ya venció y es necesario volver a validarlo.
  • Media CDN ignora el encabezado Expires si se trata de un Cache-Control. que el encabezado esté presente en la respuesta.

El encabezado HTTP/1.0 Pragma, si está presente en una respuesta, se ignora y se pasa tal como está, para el 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.

Componente ¿Se incluye de forma predeterminada? Detalles
Protocolo No

Las solicitudes mediante HTTP y HTTPS hacen referencia al mismo objeto almacenado en caché.

Si deseas mostrar las diferentes respuestas a las solicitudes http: y https:, establece cacheKeyPolicy.includeProtocol como verdadero en los rutas.
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, establece 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.
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.

Ten en cuenta lo siguiente:

  • Las claves de caché no están vinculadas a un origen configurado, lo que te permite actualizar una configuración de origen (o reemplazar el origen por completo) sin riesgo de “vaciar” la caché (por ejemplo, cuando se migra el almacenamiento de origen entre proveedores).
  • Las claves de caché están restringidas a un EdgeCacheService. Los diferentes EdgeCacheServices tienen espacios de nombres en caché diferentes, lo que evita que almacenes accidentalmente entre los entornos de producción, etapa de pruebas y otros, incluso si el host, la ruta de acceso y otros componentes de la clave de caché coincidirían. Borrar un EdgeCacheService invalida de manera eficaz todos los objetos almacenados en caché para ese servicio.
  • Las claves de caché no tienen alcance en 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é, devolver encabezados de respuesta o configuraciones CORS diferentes.
  • Las claves de caché no incluyen la configuración de reescritura de URL. en la solicitud que ve el usuario y no en la versión final "reescrita" para cada solicitud.
  • Cuando las solicitudes firmadas se configuran en una ruta, los atributos firmados no incluida 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 includedQueryParameters o excludedQueryParameters de la clave de caché 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. excluir aquellos que no. Por ejemplo, excluir parámetros de consulta de estadísticas ID de sesión de reproducción u otros parámetros que son únicos para el cliente. Incluir más parámetros de consulta de los necesarios puede disminuir las tasas de acierto de caché.

Como alternativa, en lugar de especificar qué parámetros incluir en la caché puedes elegir qué parámetros excluir de ella. Por ejemplo: para excluir de la caché el ID de reproducción específico del cliente y la información de la marca de tiempo. 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. Hazlo antes del Configurando excludeQueryString como 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 utilizados para firmar no se incluyen en la cadena de consulta y se 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 el acierto de caché ya que los clientes podrían volver a pedir o solicitar el mismo objeto 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 derivar la clave de caché. Esto permite que ambas solicitudes se asignen a la misma objeto almacenado en caché, lo que evita solicitudes innecesarias (y respuestas de) al 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 pueden incluirse 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.

Cookies que comienzan con edge-cache- en cualquier variación de 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 el contenido al que se accede una pequeña cantidad de veces por día expulsarse en el futuro.

  • Es posible que las respuestas almacenadas en caché que alcanzan el TTL configurado no se den expulsarse de inmediato. Para contenido popular, Media CDN vuelve a validar que la respuesta almacenada en caché sea la versión más reciente emitiendo un HEAD al origen para confirmar que los encabezados tienen que no se modificó. En algunos casos, se puede usar Media CDN en lugar de 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 correctamente deberían mostrar un error HTTP 304 (no modificado) sin los bytes del cuerpo, si la caché tiene el valor copia de esa respuesta.
  • Respuestas que configuran una caché max-age o s-maxage directiva o que usen un TTL anulación para especificar un valor de TTL alto (por ejemplo, 30 días) no se almacenen en la caché durante todo el TTL. 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 observas una tasa alta de expulsiones, debes asegurarte de haber configuraste tus claves de caché para excluir los parámetros que no identifican de manera inequívoca un respuesta.

Otras consideraciones

Las siguientes consideraciones también pueden ser aplicables 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 la respuesta contiene un encabezado Vary, Media CDN no lo almacena en caché, a menos que el encabezado especifique lo siguiente: uno de los encabezados que están configurados como configuración de la 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 elemento diccionario para compresión
  • Origen/origen X: Por lo general, se usa para uso compartido de recursos entre dominios
  • X-Goog-Allowed-Resources: Admite la organización de Google Cloud. restricción
  • Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site: se usa para obtener la solicitud de metadatos. headers

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 en la respuesta tiene varios valores y se ordenan de manera lexicográfica para garantizar que la clave de caché es determinista.

Media CDN almacena en caché hasta 100 variantes de una clave de caché determinada de forma aleatoria expulsa las variantes de la caché más allá de ese límite. Cuando se especifica de forma explícita invalidar la caché de una URL determinada etiqueta de caché, se invalidan todas las variantes.

Omitir la caché

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

Para los casos en los que necesitas entregar respuestas dinámicas, como backends de API, 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 RFC 7233

Media CDN también usa solicitudes por rango para recuperar respuestas más grandes desde el origen. Esto permite que Media CDN fragmentos de caché de manera individual y no requiere que se recupere todo el objeto a la vez para almacenarlos 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 bytes en el origen.
  • Las respuestas más grandes que este no se entregan si no se admiten los rangos de bytes. el origen.

La compatibilidad de origen para 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)

Solicitudes de relleno de origen individual para cada "fragmento" (rango de bytes) se registran como entradas de registro discretas y asociadas a su solicitud de cliente principal. Puedes agrupar estas solicitudes por coincidencia de solicitudes jsonPayload.cacheKeyFingerprint.

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

Solicitudes de rango abierto

Media CDN admite el modelo “abierto”. Solicitudes Range (por ejemplo, un solicitud con Range: bytes=0-) que mantienen una solicitud abierta en el origen hasta que el origen cierre la respuesta (por ejemplo, el origen escribe bytes al cable) o se agota el tiempo de espera.

Por lo general, los clientes que solicitan HLS de baja latencia a medida que se escribe cada fragmento de CMAF en la conexión, la CDN puede almacenar entregar ese bloque 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

Para configurar cuánto tiempo espera Media CDN entre lecturas, puedes usar el valor de configuración EdgeCacheOrigin.timeouts.readTimeout Esto debería suelen configurarse en un múltiplo (por ejemplo, 2x) de la duración objetivo.

¿Qué sigue?