Detalles de almacenamiento en caché

Capacidad de almacenamiento en caché

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

Puede almacenarse una respuesta en las memorias caché de Cloud CDN solo si se cumplen todas las condiciones que figuran a continuación:

  • Un servicio de backend o un depósito de backend con Cloud CDN habilitado entregó la respuesta.
  • Es la respuesta a una solicitud GET.
  • Su código de estado es 200, 203, 206, 300, 301, 302, 307 o 410.
  • Tiene un encabezado Cache-Control: public.
  • Tiene un encabezado Cache-Control: s-maxage, Cache-Control: max-age o Expires.
  • Tiene un encabezado Content-Length, Content-Range o Transfer-Encoding.
  • Su tamaño es menor o igual que el tamaño máximo.

En el caso de los depósitos de backend, puedes especificar estos requisitos; para ello, marca el objeto de Cloud Storage para que tenga acceso público de lectura. Si haces público el depósito en lugar de marcar los objetos individuales para que tengan acceso público de lectura, además debes agregar los encabezados Cache-Control obligatorios a los metadatos de cada objeto.

También hay controles que bloquean el almacenamiento en caché de las respuestas. Una respuesta no se almacena en caché si se cumple alguna de las condiciones que se indican a continuación:

  • Tiene un encabezado Set-Cookie.
  • Tiene un encabezado Vary con un valor distinto de Accept, Accept-Encoding o, además, Origin.
  • Tiene una directiva Cache-Control: no-store, no-cache o private.
  • La solicitud correspondiente tenía una directiva Cache-Control: no-store.

Es posible que estos requisitos sean flexibles en el futuro, lo que permitiría a Cloud CDN almacenar en caché respuestas adicionales. Para evitar que una respuesta se almacene en una memoria caché, incorpora un encabezado Cache-Control: no-store si la respuesta no debe almacenarse en ninguna caché, incluso la caché de un navegador web, o un encabezado Cache-Control: private si tal respuesta no debe almacenarse en las memorias caché de Cloud CDN.

Tamaño máximo

Cloud CDN impone un tamaño máximo que varía según si el servidor de origen admite solicitudes de rango de bytes:

  • 5 TB (5,497,558,138,880 bytes) si el servidor de origen admite solicitudes de rango de bytes.
  • 10 MB (10,485,760 bytes) si el servidor de origen no admite solicitudes de rango de bytes.

Toda respuesta que tenga un cuerpo mayor que el tamaño máximo no se almacenará en la memoria caché.

Entradas de caché

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, a continuación, la compara con las claves de las entradas almacenadas en caché. Si encuentra una coincidencia, la caché muestra el objeto asociado con esa clave.

Según la configuración predeterminada, Cloud CDN utiliza el URI de solicitud completo como clave de caché. 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 utiliza como la clave de caché predeterminada. Únicamente las solicitudes con esta string exacta son las que coinciden. Las solicitudes para http://example.com/images/cat.jpg o https://example.com/images/cat.jpg?user=user1 no coinciden.

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

  • Protocolo: puedes omitir el protocolo de la clave. Si omites el protocolo, una solicitud para https://example.com/images/cat.jpg recibe una clave de caché de example.com/images/cat.jpg. Después de eso, las solicitudes para https://example.com/images/cat.jpg y http://example.com/images/cat.jpg cuentan como coincidencias para esa entrada de caché.
  • Host: puedes omitir el host de la clave. Si omites el host, las solicitudes para example.com y example2.com pueden coincidir con la misma entrada de caché. Una solicitud para https://example.com/images/cat.jpg seguida de una solicitud para https://example2.com/images/cat.jpg genera un acierto de caché para la segunda solicitud.
  • Cadena de consulta: puedes omitir la cadena de consulta de la clave de caché. Si omites la cadena de consulta, una solicitud para https://example.com/images/cat.jpg?user=user1 recibe la clave de caché de https://example.com/images/cat.jpg; por lo tanto, https://example.com/images/cat.jpg?user=user1 y https://example.com/images/cat.jpg?user=user2 pueden coincidir con la misma entrada. También puedes omitir o incluir partes de la cadena de consulta de forma selectiva.

Además de omitir o incluir toda la cadena de consulta, también tienes la opción de utilizar partes de la cadena de consulta a través de listas blancas y listas negras.

En el caso de los depósitos de backend, no puedes personalizar las claves de caché.

Lista blanca de la cadena de consulta

Puedes controlar de manera selectiva qué parámetros de la cadena de consulta se incorporan a las claves de caché de Cloud CDN. Por ejemplo, si creas una lista blanca 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 utilizar esta opción, debes incluir la cadena de consulta, especificar una lista blanca que no esté vacía y no especificar una lista negra.

Lista negra de la cadena de consulta

Puedes controla de manera selectiva qué parámetros de cadena de consulta se ignoran en Cloud CDN a través de una lista negra. Por ejemplo, si creas una lista negra de user, entonces todos los parámetros de cadena de consulta, excepto user, se utilizan en la clave de caché.

Con la lista negra que se mencionó con anterioridad 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 utilizar esta opción, debes incluir la cadena de consulta, especificar una lista negra que no esté vacía y no especificar una lista blanca.

Encabezados Vary

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

Los encabezados Vary a veces se utilizan cuando se entrega contenido comprimido. Cloud CDN no comprime ni descomprime las respuestas en sí, pero puede entregar respuestas que el servidor de origen haya comprimido. Si el servidor de origen elige si debe entregar contenido comprimido o descomprimido según el valor del encabezado de solicitud Accept-Encoding, asegúrate de que la respuesta especifique Vary: Accept-Encoding.

Las respuestas con encabezados Vary se almacenan en caché solo si el encabezado tiene uno de los valores que se enumeran en Capacidad de almacenamiento en caché.

Plazos de vencimiento y solicitudes de validación

Cada entrada de caché en una memoria 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. 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.

Cuando Cloud CDN recibe una solicitud, busca la entrada de caché correspondiente y verifica su antigüedad. Si la entrada de caché existe y es lo suficientemente reciente, la respuesta puede entregarse desde la memoria caché. Sin embargo, si el plazo de vencimiento ya pasó, Cloud CDN no puede entregar una respuesta sin contactar primero a uno de los backends.

Si la respuesta previamente almacenada en caché tiene los encabezados Last-Modified o ETag, Cloud CDN puede intentar usar la información en esos encabezados para validar la entrada de caché con el backend. Cloud CDN realiza esta validación de manera ligeramente diferente en función de si la respuesta se almacenó en caché con el uso de solicitudes de rango de bytes:

  • Si la respuesta se almacenó en caché con el uso de solicitudes de rango de bytes, Cloud CDN inicia una solicitud de validación por separado que incluye los encabezados If-Modified-Since o If-None-Match.
  • De lo contrario, Cloud CDN agrega los encabezados If-Modified-Since o If-None-Match a la solicitud de 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 encabezados de respuesta nuevos en la caché, actualiza el plazo de vencimiento, y entrega los encabezados de respuesta nuevos y el cuerpo de respuesta almacenado en caché al cliente.

Si la respuesta previamente almacenada en caché no tiene el encabezado Last-Modified ni el encabezado ETag, Cloud CDN ignora la entrada de caché caducada y reenvía la solicitud de cliente al backend sin modificar.

Ten en cuenta que el plazo de vencimiento de la entrada de caché es el límite superior en cuanto a la duración de la entrada de caché. No hay ninguna garantía de que una entrada de caché vaya a permanecer en la caché hasta que caduque. Las entradas de caché para el contenido poco popular pueden expulsarse a fin de dejar lugar para el contenido nuevo. Independientemente del plazo de vencimiento especificado, las entradas de caché a las que no se accede durante 30 días se quitan automáticamente.

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

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:

  • Su código de estado es 200 OK o 206 Partial Content.
  • Tiene un encabezado Accept-Ranges: bytes.
  • Tiene un encabezado Content-Length o Content-Range.
  • Tiene un encabezado ETag con un validador sólido o un encabezado Last-Modified.

Google 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 los metadatos Content-Encoding: gzip, a menos que la solicitud de cliente incluya un encabezado Accept-Encoding: gzip. Si tienes objetos de Cloud Storage de más de 10 MB de tamaño, asegúrate de que no tengan metadatos Content-Encoding: gzip. Consulta Ve y edita metadatos de objeto para obtener más información sobre cómo editar metadatos de objeto.

El software del servidor web popular también admite solicitudes de rango de bytes. Consulta la documentación sobre el software del servidor web para obtener más información acerca de 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) de tamaño.

Cuando esto sucede y la respuesta satisface los requisitos de capacidad de almacenamiento en caché normales, 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 memoria caché no reenviará la solicitud de cliente al balanceador de cargas HTTP(S). En su lugar, la memoria caché iniciará sus propias solicitudes de llenado de caché de rango de bytes para las partes que faltan 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 iniciará una solicitud de rango de bytes, a menos que haya registrado previamente que el servidor de origen admite solicitudes de rango de bytes para esa clave de caché, una memoria caché determinada no almacenará contenido que tenga más de 1 MB de tamaño hasta la segunda vez que se acceda al contenido.

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 de cliente. Como se describe a continuación, Cloud CDN puede iniciar dos tipos de solicitudes: solicitudes de validación y solicitudes de rango de bytes.

Si la respuesta que indica que el servidor de origen admite solicitudes de rango de bytes para una clave de caché específica ha caducado, Cloud CDN inicia una solicitud de validación a fin de confirmar que el contenido no ha cambiado y que el servidor de origen aún admite solicitudes de rango para el contenido. Si el servidor de origen responde con una respuesta 304 Not Modified, Cloud CDN procede a entregar el contenido con el uso de rangos de bytes. De lo contrario, Cloud CDN reenvía la respuesta del servidor de origen al cliente. Puedes controlar los plazos de vencimiento con 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 a la solicitud de cliente. Si algunos rangos del contenido que solicitó el cliente están presentes en la memoria caché y otros no lo están, 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 posible excepción del rango final, cada rango también tiene un tamaño de 2,097,136 bytes. Si el contenido no es un múltiplo de ese tamaño, el rango final será 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ó únicamente 3,000,000 bytes.

Cuando utilizas un depósito 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, esto incluye cualquier solicitud que inicie Cloud CDN. Cuando una respuesta se entrega completamente desde una caché de Cloud CDN, no se envía ninguna solicitud GET a Cloud Storage, y no se te cobrará 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 especificados por el cliente como Cookie o User-Agent.

Pasos siguientes

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Documentación de Cloud CDN