Descripción general del almacenamiento en caché

Una respuesta almacenable en caché es una respuesta HTTP que Cloud 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é.

Modos de almacenamiento en caché

Con los modos de almacenamiento en caché, puedes controlar los factores que determinan si Cloud CDN almacena en caché tu contenido.

Cloud CDN ofrece tres modos de almacenamiento en caché, que definen cómo las respuestas se almacenan en caché, si Cloud CDN respeta las directivas de caché que envió el origen y cómo se aplican los TTL de caché.

Los modos de almacenamiento en caché disponibles se muestran en la siguiente tabla:

Modo de almacenamiento en caché Comportamiento
CACHE_ALL_STATIC Almacena en caché de forma automática las respuestas correctas con contenido estático que no se puede almacenar en caché. Las respuestas de origen que establecen directivas de almacenamiento en caché válidas también se almacenan en caché.

Este es el comportamiento predeterminado para los backends habilitados para Cloud CDN que se crean mediante Google Cloud CLI o la API de REST.
USE_ORIGIN_HEADERS Requiere respuestas de origen para establecer directivas de caché válidas y encabezados de almacenamiento en caché válidos. Las respuestas exitosas sin estas directivas se reenvían desde el origen.
FORCE_CACHE_ALL Se almacenan en caché las respuestas correctas de forma incondicional y se anulan las directivas de caché que estableció el origen. Este modo no es apropiado si el backend entrega contenido privado por usuario, como respuestas de la API o HTML dinámico.

Las respuestas de error pueden almacenarse en caché incluso si no hay directivas de caché válidas.

Antes de configurar el modo de almacenamiento en caché en FORCE_CACHE_ALL, considera los siguientes comportamientos:

  • Para las URL o cookies firmadas, FORCE_CACHE_ALL anula la antigüedad máxima especificada a través de la configuración antigüedad máxima de la entrada en la caché en la consola de Google Cloud o en la opción gcloud --signed-url-cache-max-age.

  • FORCE_CACHE_ALL cambia el tiempo de actividad (TTL) de cualquier contenido que se haya almacenado en caché con anterioridad. Este cambio puede hacer que algunas entradas que antes se consideraron actualizadas (debido a tener unos TTL más largos de los encabezados de origen) se consideren inactivas, y puede causar que algunas entradas que antes se consideraron inactivas se consideren actualizadas.

  • FORCE_CACHE_ALL anula las directivas de caché (Cache-Control y Expires), pero no anula otros encabezados de respuesta de origen. En particular, se sigue respetando un encabezado Vary y puede suprimir el almacenamiento en caché, incluso en la presencia de FORCE_CACHE_ALL. Para obtener más información, consulta Encabezados Vary.

Para obtener instrucciones de configuración, consulta Configura el modo de almacenamiento en caché.

Contenido estático

El contenido estático es siempre el mismo, incluso cuando acceden usuarios diferentes. El CSS que usas a fin de diseñar tu sitio y JavaScript, para proporcionar interactividad, video y contenido de imagen, no suelen cambiar para cada usuario de una URL determinada (clave de caché), de modo que se benefician de almacenarse en caché en la red perimetral global de Cloud CDN.

Cuando configuras el modo de almacenamiento en caché como CACHE_ALL_STATIC y una respuesta no tiene directivas de almacenamiento en caché explícitas en los encabezados Cache-Control o Expires, Cloud CDN almacena automáticamente esa respuesta para lo siguiente:

  • Elementos web, como CSS (text/css), JavaScript (application/javascript), y todas las fuentes web, incluido WOFF2 (font/woff2)
  • Imágenes, incluidos JPEG (image/jpg) y PNG (image/png)
  • Videos, como H.264, H.265 y MP4 (video/mp4)
  • Archivos de audio, incluidos MP3 (audio/mpeg) y MP4 (audio/mp4)
  • Documentos con formato, incluido PDF (application/pdf)

En la siguiente tabla, se proporciona un resumen.

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

Cloud CDN inspecciona el encabezado de respuesta HTTP Content-Type, que refleja el tipo de MIME del contenido que se entrega.

Ten en cuenta lo siguiente:

  • El software del servidor web de origen debe configurar el Content-Type para cada respuesta. Muchos servidores web configuran de forma automática el encabezado Content-Type, incluidos NGINX, Varnish y Apache.

  • Cloud Storage configura el encabezado Content-Type de forma automática en la carga cuando usas la consola de Google Cloud o Google Cloud CLI 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 o no-store, o un encabezado Set-Cookie (consulta la lista completa de reglas), no está almacenada en caché.

Cloud CDN no usa extensiones de archivo en la ruta de URL para determinar si una respuesta se puede almacenar en caché, ya que muchas respuestas válidas que se pueden almacenar en caché no se reflejan en las URL.

Si quieres almacenar en caché los tipos de contenido text/html y application/json, debes configurar encabezados Cache-Control explícitos en la respuesta tener cuidado de no almacenar en caché accidentalmente los datos de un usuario y entregarlos a todos.

Contenido que se puede almacenar en caché

Cloud CDN almacena en caché las respuestas que cumplen con todos los requisitos de esta sección. El RFC 7234 especifica algunos de estos requisitos, y otros son característicos de Cloud CDN.

Cloud CDN puede cambiar periódicamente el conjunto de condiciones exacto en el que se almacena en caché el contenido. Si deseas evitar de forma explícita que Cloud CDN almacene en caché tu contenido, sigue los lineamientos de RFC 7234 para determinar cómo especificar una respuesta garantizada no almacenable en caché. Consulta también la sección Contenido que no se puede almacenar en caché según los encabezados de origen.

Cloud CDN almacena las respuestas en caché si se cumplen todas las condiciones que figuran a continuación:

Atributo Requisito
Entregado por Servicio de backend, bucket de backend o un backend externo con Cloud CDN habilitado
En respuesta a Solicitud GET
Código de estado

200, 203, 204, 206, 300, 301, 302, 307, 308, 404, 405, 410, 421, 451 o 501.
Actualidad

La respuesta tiene un encabezado Cache-Control con una directiva max-age o s-maxage, o un encabezado Expires con una marca de tiempo en el futuro.

Para las respuestas que pueden almacenarse en caché sin una antigüedad (por ejemplo, con no-cache), se debe proporcionar la directiva public de forma explícita.

Con el modo de almacenamiento en caché CACHE_ALL_STATIC, y si no hay directivas de actualización, una respuesta correcta con tipo de contenido estático aún es apta para el almacenamiento en caché.

Con el modo de almacenamiento en caché FORCE_CACHE_ALL, cualquier respuesta correcta es apta para el almacenamiento en caché. Esto podría provocar que se almacene en caché el contenido privado por usuario (lo que permita identificarlo). Solo debes configurar FORCE_CACHE_ALL en backends que no entreguen contenido dinámico ni privado, como buckets de Cloud Storage.

Si el almacenamiento en caché negativo está habilitado y el código de estado coincide con uno para el que este almacenamiento especifica un TTL, la respuesta es apta para el almacenamiento en caché, incluso sin directivas de actualización explícitas.
Contenido

Para los orígenes HTTP/1, la respuesta debe contener un Content-Length, Content-Range o Encabezado Transfer-Encoding: chunked.

Para orígenes que usan versiones de protocolo HTTP más avanzadas (HTTP/2 y más adelante), la respuesta no necesita tener esos encabezados.
Tamaño Menor o igual que el tamaño máximo.

Para las respuestas con tamaños entre 10 MiB y 100 GiB, consulta las restricciones adicionales de capacidad de almacenamiento en caché que se describen en las solicitudes de rango de bytes.

Para los buckets de backend de Cloud Storage, se incluyen varias formas de satisfacer estos requisitos a continuación:

De forma predeterminada, cuando un objeto es público y no especifica Cache-Control metadatos, Cloud Storage asigna una Cache-Control: public, max-age=3600 encabezado al objeto. Puedes configurar diferentes valores mediante los metadatos Cache-Control.

Aquí puedes ver un ejemplo que muestra cómo configurar un balanceador de cargas de aplicaciones externo con un backend consulta Configura Cloud CDN con un backend bucket.

Tamaño máximo

Cloud CDN aplica un tamaño máximo para cada respuesta. Toda respuesta que tenga un cuerpo mayor que el tamaño máximo no se almacenará en la memoria caché, pero se entregará al cliente.

El tamaño máximo varía en función de si el servidor de origen admite solicitudes de rango de bytes.

El servidor de origen es compatible con solicitudes de rango de bytes El servidor de origen no es compatible con solicitudes de rango de bytes
100 GiB (107,374,182,400 bytes) 10 MiB (10,485,760 bytes)

Casi todos los servidores web modernos (incluidos NGINX, Apache y Varnish) admiten solicitudes de rango de bytes.

Contenido que no se puede almacenar en caché según los encabezados de origen

Hay controles que bloquean el almacenamiento en caché de las respuestas. Es posible que Cloud CDN cambie periódicamente el conjunto exacto de condiciones en las que almacena en caché el contenido, por lo que, si deseas evitar que Cloud CDN almacene de forma explícita el contenido en caché, sigue los lineamientos del estándar (RFC 7234) a fin de determinar cómo especificar una respuesta garantizada no almacenable en caché.

Cloud CDN no almacena en caché una respuesta si no cumple con los requisitos de Contenido que se puede almacenar en caché, o si se cumple alguna de las siguientes condiciones.

Atributo Requisito
Entregado por Servicio de backend o backend externo que no tiene habilitado Cloud CDN
Cookie Tiene un encabezado Set-Cookie
Encabezado Vary Tiene un valor distinto de Accept, Accept-Encoding, Access-Control-Request-Headers, Access-Control-Request-Method, Origin, Sec-Fetch-Dest, Sec-Fetch-Mode Sec-Fetch-Site, X-Goog-Allowed-Resources, X-Origin, o uno de los encabezados configurados para ser parte de la configuración de las claves de caché.
Directiva de respuesta La respuesta tiene un encabezado Cache-Control con la directiva no-store o private (a menos que se use el modo de almacenamiento en caché FORCE_CACHE_ALL, en cuyo caso se ignorará el encabezado Cache-Control).
Directiva de solicitud La solicitud tiene una directiva Cache-Control: no-store
Solicitar autorización La solicitud tiene un encabezado Authorization, a menos que la respuesta Cache-Control lo anule.
Tamaño Más grande que el tamaño máximo

Si Cache-Control: no-store o private están presentes, pero el contenido todavía se almacena en caché, se debe a uno de los siguientes motivos:

  • Se configuró la firma de URL.
  • El modo de almacenamiento en caché de Cloud CDN se configuró para forzar el almacenamiento en caché de todas las respuestas.

Evita almacenar en caché

Para evitar que la información privada se almacene en la memoria caché de Cloud CDN, haz lo que se detalla a continuación:

  1. Asegúrate de que el modo de almacenamiento en caché de Cloud CDN no esté configurado en el modo FORCE_CACHE_ALL, que almacena en caché todas las respuestas correctas sin excepción.
  2. Incluye un encabezado Cache-Control: private en las respuestas que no deben almacenarse en cachés de Cloud CDN o un encabezado Cache-Control: no-store en las respuestas que no deben almacenarse en ninguna caché, ni siquiera en la caché de un navegador web.
  3. No firmes URLs que proporcionen acceso a información privada. Cuando se accede al contenido mediante una URL firmada, puede ser apto para el almacenamiento en caché, sin importar las directivas Cache-Control en la respuesta.
  4. Para las solicitudes de origen (llenado de caché) que incluyen el encabezado de la solicitud Authorization, Cloud CDN solo almacena en caché las respuestas que incluyen la directiva de control de caché public, must-revalidate o s-maxage cuando el modo de caché está configurado en USE_ORIGIN_HEADERS o CACHE_ALL_STATIC. Esto evita el almacenamiento en caché accidental o el contenido por usuario que requiere autenticación. El modo de caché FORCE_CACHE_ALL no tiene esta restricción.

Agrega encabezados de respuesta personalizados

Con los encabezados de respuesta personalizados, puedes especificar encabezados que el balanceador de cargas de aplicaciones clásico agregue a respuestas que se envían mediante proxy. Los encabezados de respuesta personalizados te permiten reflejar el estado de la caché para tus clientes, los datos geográficos del cliente y tus propios encabezados de respuesta estática.

Para obtener la lista de encabezados, consulta Variables que pueden aparecer en el valor del encabezado.

Para obtener instrucciones, consulta Trabaja con encabezados de respuesta personalizados.

Claves de caché

Cada entrada de caché en una memoria caché de Cloud CDN se identifica a través de una clave de caché. Cuando una solicitud ingresa a la caché, la memoria caché convierte el URI de la solicitud en una clave de caché y, luego, la compara con las claves de las entradas almacenadas en caché. Si encuentra una coincidencia, la caché muestra el objeto asociado con esa clave.

De forma predeterminada, Cloud CDN usa el URI de solicitud completo como la clave de caché para los servicios de backend. Por ejemplo, https://example.com/images/cat.jpg es el URI completo de una solicitud específica para el objeto cat.jpg. Esta string se usa como la clave de caché predeterminada. Solo coinciden las solicitudes que poseen esta string exacta. Solicitudes de http://example.com/images/cat.jpg o https://example.com/images/cat.jpg?user=user1 no coinciden.

En los buckets de backend, el valor predeterminado de la clave de caché consiste en el URI sin el protocolo o el host. De forma predeterminada, solo los parámetros de consulta que se conocen en Cloud Storage se incluyen como parte de la clave de caché (por ejemplo, “generación”).

Por lo tanto, para un bucket de backend determinado, los siguientes URI se resuelven en el mismo objeto almacenado en caché:

  • http://example.com/images/cat.jpg
  • https://example.com/images/cat.jpg
  • https://example.com/images/cat.jpg?user=user1
  • http://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2
  • https://media.example.com/images/cat.jpg
  • https://www.example.com/images/cat.jpg

Puedes cambiar qué partes del URI se usan en la clave de caché. Si bien el nombre de archivo y la ruta de acceso siempre deben formar parte de la clave, puedes incluir, o bien omitir, cualquier combinación de protocolo, host o cadena de consulta cuando personalices la clave de caché. En Usa claves de caché se describe cómo personalizar las claves de caché.

Parte del URI Personalización URL de ejemplo que tienen la misma clave de caché
Protocolo Omite el protocolo desde la clave de caché.
  • https://example.com/images/cat.jpg
  • http://example.com/images/cat.jpg
Host Omite el host de la clave de caché.
  • https://example.com/images/cat.jpg
  • https://example2.com/images/cat.jpg
String de consulta

Omite la string de consulta en la clave de caché.

Omite o incluye partes de la string de consulta de manera selectiva.
  • https://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2

Además de omitir o incluir toda la string de consulta, puedes usar partes de esa string mediante el uso de listas de inclusiones y exclusiones.

Lista de inclusiones de la string de consulta

Puedes controlar de manera selectiva qué parámetros de la string de consulta se incorporan a las claves de caché de Cloud CDN. Por ejemplo, si creas una lista de inclusiones de user, entonces https://example.com/images/cat.jpg?user=user1&color=blue crea una clave de caché de https://example.com/images/cat.jpg?user=user1 que también coincide con https://example.com/images/cat.jpg?user=user1&color=red.

Para usar esta opción, debes incluir la string de consulta, especificar una lista de inclusiones que no esté vacía y no especificar una lista de exclusiones.

Lista de inclusiones de la string de consulta para las claves de caché de Cloud Storage

Incluir parámetros de búsqueda de URL en las claves de caché para los buckets de Cloud Storage ayuda a admitir la eliminación de caché. La prevención de almacenamiento en caché permite al usuario recuperar una versión nueva del archivo que se subió, incluso si la versión anterior sigue estando en caché según la configuración del TTL.

Puedes incluir parámetros de búsqueda específicos en la lista de claves de caché que se usa para entregar respuestas desde un bucket de backend. Aunque Cloud Storage no entrega contenido o rutas diferentes según los parámetros de búsqueda, puedes optar por incluir parámetros que te permitan almacenar en caché el contenido estático almacenado en buckets de Cloud Storage.

Por ejemplo, puedes agregar un parámetro de búsqueda ?version=VERSION o ?hash=HASH, que se base en el contenido subyacente. Esta acción limita la necesidad de invalidar el contenido de manera proactiva y se alinea con los flujos de trabajo modernos del desarrollo web, en los que los frameworks y las URL web usan un hash de contenido para evitar entregar objetos obsoletos mediante implementaciones.

Debido a que la inclusión de parámetros de consulta en la clave de caché es solo de participación, Cloud CDN no admite la exclusión de parámetros de consulta de una clave de caché a un bucket de backend.

Lista de exclusiones de la string de consulta

Puedes controlar de manera selectiva qué parámetros de string de consulta se ignoran en Cloud CDN mediante el uso de una lista de exclusiones. Por ejemplo, si creas una lista de exclusiones de user, todos los parámetros de la string de consulta excepto user se usan en la clave de caché.

Con la lista de exclusiones configurada y una entrada de https://example.com/images/cat.jpg?user=user1&color=blue, Cloud CDN crea una clave de caché de https://example.com/images/cat.jpg?color=blue que también coincide con https://example.com/images/cat.jpg?user=user2&color=blue, pero no con https://example.com/images/cat.jpg?user=user1&color=red.

Para usar esta opción, debes incluir la string de consulta, especificar una lista de exclusiones que no esté vacía y no especificar una lista de inclusiones.

Orden de los parámetros de consulta

La clave de caché generada no depende del orden de los parámetros de búsqueda.

Por ejemplo, los siguientes parámetros de búsqueda generan la misma clave de caché:

  • info=123&variant=13e&geography=US
  • geography=US&variant=13e&info=123

Configuración de la clave de caché de cookies HTTP y encabezados HTTP

Puedes mejorar las tasas de aciertos de caché y la descarga de origen mediante la siguiente configuración de la clave de caché.

  • Para buckets y servicios de backend: usa encabezados HTTP como parte de las claves de caché mediante la inclusión de encabezados con nombre en la configuración de la clave de caché.
  • Solo para servicios de backend: Usa cookies HTTP con nombre como claves de caché, como pruebas A/B (multivariable), versiones canary y situaciones similares.

Las solicitudes de caché que incluyen encabezados o cookies HTTP adicionales en la solicitud se almacenan en caché en la tercera solicitud en una ubicación para esa clave de caché. Esto reduce el impacto del encabezado de alta cardinalidad o los valores de cookies en tu las tasas de expulsión de caché. En circunstancias y condiciones de tráfico de usuarios normales, esto no debería notarse y ayuda a garantizar que el contenido popular permanezca almacenado en caché.

Incluye encabezados de la solicitud

Para almacenar en caché variaciones adicionales de una respuesta, puedes incluir encabezados de solicitud adicionales en la clave de caché.

Algunos encabezados no están permitidos en las claves de caché porque suelen tener una cardinalidad muy alta. En la mayoría de los casos, los valores de estos encabezados son únicos por usuario (Cookie,Authorization ) o tienen miles de valores posibles (Referer, User-Agent o Accept ). Por ejemplo, el encabezado User-Agent puede tener más de 5,000 valores únicos dada la gran variedad de navegadores, dispositivos de usuario y sistemas operativos. Estos tipos de encabezados tendrían un impacto negativo grave en las tasas de aciertos de caché.

Solo se aceptan nombres de campo de encabezado HTTP válidos según RFC 7230. Los nombres de campo de encabezado no distinguen entre mayúsculas y minúsculas, y los duplicados se rechazan.

De forma opcional, puedes configurar tu servidor de origen para que incluya encabezados de solicitud de clave de caché configurados en la respuesta Vary. No es obligatorio para Cloud CDN, pero puede ser útil para las cachés descendentes. Para ver más consulta Encabezados Vary.

Cloud CDN no permite que se incluyan los siguientes encabezados en la lista de encabezados:

  • Accept
  • Accept-Encoding
  • Authority, ya que se controla mediante la configuración (cdnPolicy.includeHost)
  • Authorization, por lo general, por usuario, como en los tokens de Bearer de OAuth
  • CDN-Loop
  • Connection
  • Content-MD5
  • Content-Type
  • Cookie
  • Date
  • Forwarded, a menudo por cliente o por proxy
  • From
  • Host, ya que se controla mediante la configuración (cdnPolicy.includeHost)
  • If-Match, If-Modified-Since o If-None-Match
  • Origin
  • Proxy-Authorization
  • Range
  • Referer (o Referrer)
  • User-Agent
  • Want-Digest
  • X-CSRFToken y X-CSRF-Token según lo que usan Django y Ruby on Rails
  • X-Forwarded-For, a menudo por cliente o por proxy
  • X-User-IP
  • Cualquier encabezado que comience con lo siguiente:
    • Access-Control-, como Access-Control-Request-Headers y Access-Control-Request-Method
    • Sec-Fetch-
    • Sec-GFE-
    • Sec-Google-
    • X-Amz-
    • X-GFE-
    • X-Goog-
    • X-Google-

Los mismos encabezados con valores diferentes

Supongamos que el usuario envía varios encabezados con el mismo nombre con valores de encabezado diferentes, por ejemplo:

My-Header: Value1
My-Header: Value2

En este caso, Cloud CDN modifica la solicitud mediante la suposición de que el encabezado debe seguir la convención estándar que permite que algunos encabezados tengan más de un valor. Cloud CDN las contrae en una lista separada por comas para enviar al backend, por lo que es como si el cliente enviara la siguiente información:

My-Header: Value1, Value2

Incluye cookies con nombre

Una cookie HTTP es una sincronización name=value, y una solicitud puede incluir varias cookies HTTP, ya sea separadas por un punto y coma en la misma línea o como encabezados de solicitud Cookie discretos con una cookie por encabezado.

Puedes proporcionar una lista de hasta cinco nombres de cookies.

Los usuarios-agentes (como los navegadores web) suelen limitar a 4 KB la cantidad de cookies almacenadas por dominio. Asegúrate de no enviar demasiadas cookies (o que sean muy grandes), ya que es posible que el usuario-agente no envíe todas las cookies de una solicitud. Esto puede generar un impacto si un usuario recibe una respuesta almacenada en caché específica.

Si entregas tu contenido estático desde un nombre de host diferente desde el que emites cookies, asegúrate de que el atributo Domain de la cookie (y el atributo Path) permita enviar la cookie con solicitudes de contenido estático.

Si una solicitud incluye más de una instancia con el mismo nombre de cookie, solo se respeta la primera.

Directivas de control de caché

Las directivas del control de caché HTTP afectan el comportamiento de Cloud CDN, como se describe en la siguiente tabla.

N/A significa que una directiva no es aplicable a una solicitud o respuesta.

Directiva Solicitud Respuesta
no-store Cuando está presente en una solicitud, Cloud CDN lo respeta y no almacena la respuesta en la caché.

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

Se puede anular por backend con el modo de caché FORCE_CACHE_ALL.

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 se debe volver a validar con el origen antes de la entrega.

Se puede anular por backend con el modo de caché FORCE_CACHE_ALL.

public N/A

Esta directiva no es necesaria para la capacidad de almacenamiento en caché, pero se recomienda incluirla en el caso del contenido que los proxies deben almacenar en caché.

private N/A

Cloud CDN no almacena en caché una respuesta con la directiva private, incluso si la respuesta se considera almacenamiento en caché. Los clientes (como los navegadores) aún pueden almacenar en caché el resultado.

Se puede anular por backend con el modo de 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, Cloud CDN usa s‑maxage.

Las respuestas con esta directiva no se entregan inactivas.

s-max-age (dos guiones) no es válido para el almacenamiento en caché.

min-fresh=SECONDS Se ignora la directiva de solicitud min-fresh. Se muestra una respuesta en caché como si este encabezado no se incluyera en la solicitud. N/A
max-stale=SECONDS

La directiva de solicitud max-stale dicta la inactividad máxima (en segundos) que el cliente está dispuesto a aceptar.

Cloud CDN lo respeta y muestra una respuesta en caché inactiva solo si la inactividad de la respuesta es menor que la directiva max-stale. De lo contrario, se vuelve a validar antes de entregar la solicitud.

 N/A
stale-while-revalidate=SECONDS N/A

Una respuesta con stale-while-revalidate se entrega a un cliente hasta por SECONDS mientras se realiza la revalidación.

Este comportamiento se puede habilitar para todas las respuestas mediante la configuración de cdnPolicy.serveWhileStale en el backend.

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.

Este encabezado de respuesta no tiene efecto.

must-revalidate N/A

Una respuesta con must-revalidate se vuelve a validar con el servidor de origen después de su vencimiento.

Las respuestas con esta directiva no se entregan inactivas.

proxy-revalidate

Una respuesta con proxy-revalidate se vuelve a validar con el servidor de origen después de su vencimiento.

Las respuestas con esta directiva no se entregan inactivas.

immutable N/A Sin efecto. Esto se pasa al cliente en la respuesta.
no-transform N/A Cloud CDN no aplica ninguna transformación.
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, Cloud CDN se esfuerza por cumplir con los estándares RFC (HTTP RFC 7234), pero favorece la optimización para la descarga de caché y la minimización del impacto que que pueden tener los clientes 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 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.
  • Si hay un encabezado Cache-Control presente en la respuesta, Cloud CDN ignora el encabezado Expires.

La presencia de un encabezado Expires válido y futuro en la respuesta permite que la respuesta se almacene en caché y no requiere que se especifiquen otras directivas de caché.

El encabezado HTTP/1.0 Pragma, si está presente en una respuesta, se ignora y se pasa tal como está al cliente. Las solicitudes de cliente con este encabezado se pasan al origen y no afectan la forma en que Cloud CDN entrega una respuesta.

Encabezados Vary

El encabezado Vary indica que la respuesta varía según los encabezados de la solicitud del cliente. Además del URI de solicitud, Cloud CDN respeta los encabezados Vary que los servidores de origen incluyen en las respuestas. Por ejemplo, si una respuesta especifica Vary: Accept, Cloud CDN usa una entrada de caché para las solicitudes que especifican Accept: image/webp,image/*,*/*;q=0.8 y otra destinada a las solicitudes que especifican Accept: */*.

En la tabla de la sección Contenido que no se puede almacenar en caché, se enumeran los encabezados Vary que permiten que el contenido se almacene en caché. Otros valores de encabezado Vary impiden que el contenido se almacene en caché.

El modo de caché FORCE_CACHE_ALL no anula este comportamiento. Los encabezados Vary son importantes para evitar el envenenamiento de caché entre varias respuestas posibles del servidor de origen. Sería peligroso que FORCE_CACHE_ALL provoque que esas respuestas se almacenen en caché.

Los encabezados Vary a veces se usan cuando se entrega contenido comprimido. Cloud CDN no comprime ni descomprime las respuestas (a menos que esté habilitada la compresión dinámica), pero puede entregar respuestas que comprima el servidor de origen. Si el el servidor de origen elige si entregar contenido comprimido o sin comprimir según en el valor del encabezado de la solicitud Accept-Encoding, asegúrate de que el especifica Vary: Accept-Encoding.

Cuando uses encabezados HTTP en la clave de caché, Cloud CDN almacena en caché varias copias de la respuesta según los valores. de los encabezados de solicitud especificados, similar a la compatibilidad con Vary, pero sin los necesidad de que el servidor de origen especifique explícitamente cualquier encabezado de respuesta Vary. Si el origen especifica los encabezados de clave de caché en la respuesta Vary, Cloud CDN trata la respuesta correctamente, al igual que si los encabezados no se mencionaran en la respuesta Vary.

Plazos de vencimiento y solicitudes de validación

El plazo de vencimiento de la entrada de caché define por cuánto tiempo sigue siendo válida. El valor que proporciona el valor s-maxage (o max-age, o expires) permite la revalidación automática del contenido almacenado en caché inactivo y generado por el usuario.

Cuando Cloud CDN recibe una solicitud, busca la entrada de caché correspondiente y verifica su antigüedad. Si la entrada de caché existe y está lo suficientemente actualizada, la respuesta se puede entregar desde la caché. Si el plazo de vencimiento ya pasó, Cloud CDN intenta revalidar la entrada de caché mediante el contacto con uno de tus backends. Esto se realiza antes de entregar la respuesta, a menos que habilites serve-while-stal, en cuyo caso la revalidación se realiza de forma asíncrona.

Para algunos modos de almacenamiento en caché, puedes establecer valores de TTL. Para obtener más información, consulta Usa la configuración y las anulaciones de TTL.

El modo de almacenamiento en caché afecta la forma en que se determina la actualidad.

Modo de almacenamiento en caché Comportamiento de la validación
CACHE_ALL_STATIC Se consultan los encabezados de origen (Cache-Control: s-maxage, Cache-Control: max-age o Expires) para determinar la actualización. En el caso del contenido estático, si no hay encabezados de origen, el default_ttl configurado determina la actualidad. Una vez que el contenido estático tiene más de default_ttl, Cloud CDN lo vuelve a validar.
USE_ORIGIN_HEADERS Cada entrada de caché en una caché de Cloud CDN tiene un plazo de vencimiento que definen los encabezados Cache-Control: s-maxage, Cache-Control: max-age o Expires de acuerdo con RFC 7234.
FORCE_CACHE_ALL En lugar de los encabezados de origen, el default_ttl configurado determina la actualidad. Una vez que el contenido es más antiguo que default_ttl, Cloud CDN lo vuelve a validar.

Si hay más de uno, Cache-Control: s-maxage tiene prioridad sobre Cache-Control: max-age, y Cache-Control: max-age tiene prioridad sobre Expires.

De forma predeterminada, cuando el valor de vencimiento supera los 30 días (2,592,000 segundos), Cloud CDN trata el valor de vencimiento como si fueran 2,592,000 segundos. Los clientes finales aún ven los valores exactos de max-age y s-maxage, incluso si superan los 30 días.

Expulsión

No hay garantía de que una entrada de caché permanezca ahí hasta que venza, ya que las entradas poco populares se pueden expulsar antes de que esto suceda en cualquier momento a fin de dejar lugar para el contenido nuevo. Como límite superior, las entradas de caché a las que no se accede durante 30 días se expulsan de forma automática.

Para obtener más información, consulta Expulsión y vencimiento.

Usa solicitudes condicionales para la validación

Cloud CDN puede intentar usar la información en los encabezados de respuesta almacenados en caché para validar la entrada de caché con el backend. Esto sucede cuando se cumple lo siguiente:

  • La respuesta almacenada en caché anterior tiene un encabezado Last-Modified o ETag.
  • La solicitud del cliente es una solicitud GET que no contiene encabezados If-Modified-Since o If-None-Match.

Cloud CDN realiza esta validación de una manera un poco diferente en función de si la respuesta se almacenó en caché mediante solicitudes de rango de bytes:

  • Si la respuesta se almacenó en caché con solicitudes de rango de bytes, Cloud CDN inicia una solicitud de validación separada que incluye If-Modified-Since y If-None-Match.
  • De lo contrario, Cloud CDN agregará If-Modified-Since y Encabezados If-None-Match a la solicitud del cliente y reenvía la solicitud modificada al backend.

Si la copia almacenada en caché todavía está actualizada, el backend puede validar la entrada de caché existente mediante el envío de una respuesta 304 Not Modified. En este caso, el backend solo envía los encabezados de respuesta, no el cuerpo de la respuesta. Cloud CDN inserta los nuevos encabezados de respuesta en la caché, actualiza el plazo de vencimiento y entrega los nuevos encabezados de respuesta y el cuerpo de respuesta almacenado en caché al cliente.

Si la respuesta en caché anterior no tiene un encabezado Last-Modified o ETag, Cloud CDN ignora la entrada de caché vencida y reenvía la solicitud del cliente al backend sin modificar.

Compatibilidad con solicitudes de rango de bytes

Una respuesta que cumple con los siguientes criterios indica que el servidor de origen admite solicitudes de rango de bytes:

  • Código de estado: 200 OK o 206 Partial Content
  • Encabezado: Accept-Ranges: bytes
  • Encabezado: Content-Length, y para una respuesta 206 Partial Content, una Es un valor Content-Range que indica la longitud completa del objeto de origen. Por ejemplo, Content-length: 0-100/999 se puede almacenar en caché, mientras que Content-length: 0-100/* no lo es.
  • Encabezado: Last-Modified y ETag con un validador sólido

Cloud Storage admite solicitudes de rango de bytes para la mayoría de los objetos. Sin embargo, Cloud Storage no admite solicitudes de rango de bytes para objetos con metadatos Content-Encoding: gzip, a menos que la solicitud del cliente incluya un encabezado Accept- Encoding: gzip. Si tienes objetos de Cloud Storage de más de 10 MB, asegúrate de que no tengan metadatos Content-Encoding: gzip. Para obtener información sobre cómo editar metadatos de objetos, consulta Visualiza y edita metadatos de objetos.

El popular software del servidor web también admite solicitudes de rango de bytes. Consulta la documentación de tu servidor web para obtener detalles sobre cómo habilitar la compatibilidad. Para obtener más información sobre las solicitudes de rango de bytes, consulta la especificación HTTP.

Cuando un servidor de origen admite solicitudes de rango de bytes, una caché de Cloud CDN se niega a almacenar una respuesta que puede almacenarse en caché la primera vez que realiza la solicitud si se cumple alguna de las siguientes condiciones:

  • El cuerpo de la respuesta está incompleto porque el cliente solicitó solo una parte del contenido.
  • El cuerpo de la respuesta es más grande que 1 MB (1,048,576 bytes).

Cuando esto sucede y la respuesta satisface los requisitos normales de capacidad de almacenamiento en caché, la caché registra que el servidor de origen admite solicitudes de rango de bytes para esa clave de caché y reenvía la respuesta del servidor de origen al cliente.

En un error de caché, la memoria caché verifica si se sabe que el servidor de origen admite solicitudes de rango de bytes. Si se sabe que las solicitudes de rango de bytes son compatibles con la clave de caché, la caché no reenvía la solicitud del cliente al balanceador de cargas de aplicaciones externo. En su lugar, la caché inicia sus propias solicitudes de relleno de caché de rango de bytes para las partes faltantes del contenido. Si el servidor de origen muestra el rango de bytes solicitado en una respuesta 206 Partial Content, la caché puede almacenar ese rango para solicitudes futuras.

Una caché almacena una respuesta 206 Partial Content solo cuando se recibe en respuesta a una solicitud de rango de bytes que inició la caché. Debido a que una caché no inicia una solicitud de rango de bytes a menos que haya registrado de forma previa que el servidor de origen admite solicitudes de rango de bytes, una caché determinada no almacena contenido de más de 1 MB hasta la segunda vez que se accede al contenido.

Debido a su naturaleza distribuida, es posible que Cloud CDN pueda recuperar veces el fragmento final del origen más de una vez por ubicación. Esto solo afecta las primeras solicitudes por clave de caché.

Solicitud de contraer (fusión)

La solicitud de contraer (o fusión) contrae de forma activa varias solicitudes de llenado de caché generadas por el usuario para la misma clave de caché en una sola solicitud de origen por nodo perimetral. Esto puede reducir de forma activa la carga en el origen y se aplica a las solicitudes de item (respuestas obtenidas directamente) y chunk, en la que Cloud CDN usa solicitudes Range para recuperar objetos de mayor tamaño de manera más eficiente.

La selección de solicitudes está habilitada de forma predeterminada.

Las solicitudes contraídas se comportan de la siguiente manera:

  • Las solicitudes contraídas registran la solicitud orientada al cliente y la solicitud de llenado de caché (contraída).
  • El líder de la sesión contraída se usa para realizar la solicitud de relleno de origen.
  • Los atributos de solicitud que no forman parte de la clave de caché, como el encabezado User-Agent o Accept-Encoding, solo reflejan el líder de la sesión contraída.
  • Las solicitudes que no tienen la misma clave de caché no se pueden contraer.

En el siguiente diagrama, se muestra cómo se fusionan las solicitudes:

Cloud CDN con fusión de solicitudes habilitada
Cloud CDN con fusión de solicitudes habilitada (haz clic para agrandar).

En cambio, con la contracción de solicitudes habilitada o para solicitudes que no se pueden combinadas, la cantidad de solicitudes de origen y respuestas puede ser igual a la la cantidad de clientes que intentan recuperar un objeto que no está almacenado en caché.

Cloud CDN sin habilitación de solicitudes fusionadas
Cloud CDN sin fusión de solicitudes habilitada (haz clic para agrandar).

Para todos los tipos de solicitudes, esta opción está habilitada de forma predeterminada. Para los tipos de solicitud de elemento, puedes inhabilitar la contracción. Recomendamos inhabilitar la contracción de solicitudes de elementos en situaciones muy sensibles, como en la entrega de anuncios, en la que la carga de origen no es una consideración.

En la siguiente tabla, se resume el comportamiento y la configuración predeterminados para diferentes tipos de solicitudes.

Tipo de solicitud Comportamiento predeterminado Configurable Beneficios de la contracción
Solicitudes de fragmento Habilitado No Puede reducir significativamente el ancho de banda de origen.
Solicitudes de elementos Habilitado Sí Puede reducir el volumen de solicitudes de origen.

A fin de inhabilitar la fusión de solicitudes de elementos con Google Cloud CLI en un bucket de backend que hace referencia a un bucket de Cloud Storage, sigue estos pasos:

gcloud

Usa el comando gcloud compute backend-services o backend-buckets:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --no-request-coalescing

Para habilitar la fusión de solicitudes de elementos en un bucket de backend mediante Google Cloud CLI, haz lo siguiente:

gcloud

Usa el comando gcloud compute backend-buckets:

gcloud compute backend-buckets update BACKEND_BUCKET_NAME \
    --request-coalescing

Si quieres habilitar la fusión de solicitudes de elementos con Google Cloud CLI para un servicio de backend, incluidos los grupos de VM y los backends externos, haz lo siguiente:

gcloud

Usa el comando gcloud compute backend-services:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --request-coalescing

Solicitudes que inicia Cloud CDN

Cuando el servidor de origen admite solicitudes de rango de bytes, Cloud CDN puede enviar varias solicitudes al servidor de origen en respuesta a una sola solicitud del cliente. Cloud CDN puede iniciar dos tipos de solicitudes: solicitudes de validación y solicitudes de rango de bytes.

Si la respuesta que indicó que el servidor de origen admite solicitudes de rango de bytes para una clave de caché específica caducó, Cloud CDN inicia una solicitud de validación a fin de confirmar que el contenido no cambió y que el servidor de origen aún admite solicitudes de rango en el contenido. Si el servidor de origen responde con una respuesta 304 Not Modified, Cloud CDN procede a entregar el contenido mediante rangos de bytes. De lo contrario, Cloud CDN reenvía la respuesta del servidor de origen al cliente. Puedes controlar los plazos de vencimiento mediante los encabezados de respuesta Cache-Control y Expires.

En un error de caché, Cloud CDN inicia las solicitudes de llenado de caché para un conjunto de rangos de bytes que se superponen sobre la solicitud de cliente. Si algunos rangos del contenido que solicitó el cliente están presentes en la memoria caché, Cloud CDN entrega lo que puede desde la memoria caché y envía solicitudes de rango de bytes para los rangos faltantes al servidor de origen.

En cada solicitud de rango de bytes que inicia Cloud CDN, se especifica un rango que comienza en un desplazamiento que es múltiplo de 2,097,136 bytes. Con la excepción posible del rango final, cada rango también es de 2,097,136 bytes. Si el contenido no es un múltiplo de ese tamaño, el rango final es más pequeño. Es posible que el tamaño y los desplazamientos en las solicitudes de rango de bytes cambien en el futuro.

Por ejemplo, considera una solicitud de cliente para los bytes 1,000,000 a 3,999,999 de contenido que no esté presente en la caché. En este ejemplo, Cloud CDN podría iniciar dos solicitudes GET, una para los primeros 2,097,136 bytes de contenido y otra para los segundos 2,097,136 bytes. Esto se traduce en 4,194,272 bytes de llenado de caché, aunque el cliente solicitó solo 3,000,000 bytes.

Cuando usas un bucket de Cloud Storage como origen, cada solicitud GET se factura como una operación Clase B independiente. Se te cobrará por todas las solicitudes GET que procesa Cloud Storage, lo que incluye cualquier solicitud que inicie Cloud CDN. Cuando una respuesta se entrega por completo desde una caché de Cloud CDN, no se envían solicitudes GET a Cloud Storage y no se cobra por ninguna operación de Cloud Storage.

Cuando Cloud CDN inicia una solicitud de validación o una solicitud de rango de bytes, no incluye encabezados específicos del cliente, como Cookie o User-Agent.

En el campo httpRequest.userAgent de Cloud Logging, Cloud-CDN-Google significa que Cloud CDN inició la solicitud.

Omite la caché

La omisión de la caché permite que las solicitudes que contengan encabezados de la solicitud específicos omitan la caché, incluso si el contenido se almacenó en caché con anterioridad.

En esta sección, se proporciona información para omitir la caché con encabezados HTTP, como Pragma y Authorization. Esta función es útil cuando deseas asegurarte de que tus usuarios o clientes siempre tengan el contenido más reciente recuperado del servidor de origen. Se recomienda usar esta información para hacer pruebas, configurar directorios de etapa de pruebas o secuencias de comandos.

Si un encabezado especificado coincide, la caché se omite para todas las opciones de configuración del modo de caché, incluso FORCE_CACHE_ALL. La caché omite los resultados en una gran cantidad de errores de caché si los encabezados especificados son comunes a muchas solicitudes.

Antes de comenzar

  • Asegúrate de que Cloud CDN esté habilitado. Para obtener instrucciones, consulta Usa Cloud CDN.

  • Si es necesario, actualiza a la última versión de Google Cloud CLI:

    gcloud components update

Configura la omisión de la caché

Puedes especificar hasta cinco nombres de encabezado HTTP. Los valores no distinguen entre mayúsculas y minúsculas. El nombre del encabezado debe ser un token de campo de encabezado HTTP válido. Un nombre de encabezado no debe aparecer más de una vez en la lista de encabezados agregados. Para conocer las reglas acerca de los nombres de encabezado válidos, consulta Cómo funcionan los encabezados personalizados.

Console

  1. En la consola de Google Cloud, ve a la página Balanceo de cargas.

    Ir a la página Balanceo de cargas

  2. Haz clic en el nombre de tu balanceador de cargas de aplicaciones externo.
  3. Haz clic en Editar .
  4. En Configuración de backend, selecciona un backend y haz clic en Editar .
  5. Asegúrate de que la opción Habilitar Cloud CDN esté seleccionada.
  6. En la parte inferior de la ventana, haz clic en Configuración avanzada.
  7. En Omitir la caché en el encabezado de la solicitud, haz clic en Agregar encabezado.
  8. Escribe un nombre de encabezado, como Pragma o Authorization.
  9. Haz clic en Actualizar.
  10. Vuelve a hacer clic en Actualizar.

gcloud

En los buckets de backend, usa el comando gcloud compute backend-buckets create o gcloud compute backend-buckets update con la marca --bypass-cache-on-request-headers.

En los servicios de backend, usa el comando gcloud compute backend-services create o gcloud compute backend-services update con la marca --bypass-cache-on-request-headers.

gcloud compute backend-buckets (create | update) BACKEND_BUCKET_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER

gcloud compute backend-services (create | update) BACKEND_SERVICE_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER

Por ejemplo:

gcloud compute backend-services update my-backend-service
    --bypass-cache-on-request-headers=Pragma
    --bypass-cache-on-request-headers=Authorization

api

Para los buckets de backend, usa la llamada a la API Method: backendBuckets.insert, Method: backendBuckets.update o Method: backendBuckets.patch..

Para los servicios de backend, usa la llamada a la API método: backendServices.insert, Method: backendServices.update o Method: backendServices.patch.

Por ejemplo:

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets

Agrega el siguiente fragmento al cuerpo de solicitud JSON:

"cdnPolicy": {
  "bypassCacheOnRequestHeaders": [
    {
      "headerName": string
    }
  ]
}

Inhabilita la omisión de la caché

gcloud

En los buckets de backend, usa el comando gcloud compute backend-buckets create o gcloud compute backend-buckets update con la marca --no-bypass-cache-on-request-headers.

En los servicios de backend, usa el comando gcloud compute backend-services create o gcloud compute backend-services update con la marca --no-bypass-cache-on-request-headers.

gcloud compute backend-services (create | update) (BACKEND_SERVICE_NAME | BACKEND_BUCKET_NAME)
    --no-bypass-cache-on-request-headers

api

En los buckets de backend, usa la llamada a la API Method: backendBuckets.insert o Method: backendBuckets.update.

En los servicios de backend, usa la llamada a la API Method: backendServices.insert o Method: backendServices.update.

Usa una de las siguientes llamadas a la API:

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE

Agrega el siguiente fragmento al cuerpo de solicitud JSON:

"cdnPolicy": {
  "fields": "bypassCacheOnRequestHeaders"
}

¿Qué sigue?