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
USE_ORIGIN_HEADERS Requiere respuestas de origen para establecer directivas de caché válidas y encabezados de almacenamiento en caché válidos.
CACHE_ALL_STATIC Almacena en caché de forma automática el contenido estático que no tiene la directiva no-store, private o no-cache. Las respuestas de origen que establecen directivas de almacenamiento en caché válidas también se almacenan en caché.
FORCE_CACHE_ALL Se almacenan en caché las respuestas de forma incondicional y se anulan las directivas de caché que estableció el origen. Asegúrate de no almacenar en caché contenido privado por usuario (como HTML dinámico o respuestas de la API) si usas un backend compartido con este modo configurado.

Durante la versión beta de los modos de caché, cuando habilitas Cloud CDN en un backend (origen), puedes configurar de manera opcional el modo de almacenamiento en caché en CACHE_ALL_STATIC, pero el comportamiento predeterminado es que Google Cloud aún requiera respuestas de origen para establecer directivas de caché y encabezados de almacenamiento en caché válidos. Ahora se denomina modo de almacenamiento en caché USE_ORIGIN_HEADERS. Las respuestas sin estas directivas, y las respuestas que no pueden almacenarse en caché se completan desde el origen.

  • En la versión de DG de los modos de caché, Cloud CDN se establecerá de forma predeterminada en el modo de almacenamiento en caché CACHE_ALL_STATIC en lugar del modo de almacenamiento en caché USE_ORIGIN_HEADERS.

  • Para los orígenes existentes que ya tienen habilitado Cloud CDN, el comportamiento permanece sin cambios. Estos orígenes tienen su modo de almacenamiento en caché configurado en USE_ORIGIN_HEADERS, lo que refleja el comportamiento existente de Cloud CDN.

El comportamiento predeterminado de la versión beta y de DG se resume en la siguiente tabla.

Fase de lanzamiento Existente o nuevo Modo de almacenamiento en caché predeterminado
Beta Nuevo backend USE_ORIGIN_HEADERS (sin cambios)
Beta Backend existente USE_ORIGIN_HEADERS (sin cambios)
DG Nuevo backend CACHE_ALL_STATIC (opción predeterminada nueva)
DG Backend existente USE_ORIGIN_HEADERS (sin cambios)

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é para almacenar en caché todo el contenido estático, Cloud CDN almacena de forma automática las respuestas en caché 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 (image/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 Cloud Console o la herramienta de gsutil para subir contenido.

  • Si una respuesta se puede almacenar en caché según su tipo de MIME, pero tiene un encabezado de respuesta Cache-Control de private, no-store o no-cache, o un encabezado Set-Cookie (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 deseas almacenar en caché tipos de contenido text/html y application/json, debes configurar encabezados Cache-Control explícitos en la respuesta, con cuidado de no almacenar en caché los datos de un usuario y entregarlos a todos los usuarios de manera accidental.

Contenido que se puede almacenar 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.

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

Atributo Requisito
Entregado por Servicio de backend, bucket de backend o un origen personalizado 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
Directiva de caché

Con el modo de almacenamiento en caché USE_ORIGIN_HEADERS, la respuesta debe tener un encabezado Cache-Control con una directiva public.

Con el modo de almacenamiento en caché CACHE_ALL_STATIC, la respuesta debe tener un encabezado Cache-Control con una directiva public o debe tener un tipo de contenido estático.

Con el modo de almacenamiento en caché FORCE_CACHE_ALL, la respuesta siempre es apta para el almacenamiento en caché.

Actualidad

Con el modo de almacenamiento en caché USE_ORIGIN_HEADERS, 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.

Con el modo de almacenamiento en caché CACHE_ALL_STATIC, cualquier respuesta de backend que tenga contenido estático se considera actualizada. Para el contenido no estático, la actualidad se basa en los encabezados de origen.

Con el modo de almacenamiento en caché FORCE_CACHE_ALL, todas las respuestas de backend se consideran actualizadas.

Contenido

Contiene un encabezado Content-Length, Content-Range o Transfer-Encoding válido.

Por ejemplo, un encabezado Content-Length que coincida de forma correcta con el tamaño de la respuesta.

Tamaño Menor o igual que el tamaño máximo

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

De forma predeterminada, cuando todo el bucket es público, o los objetos individuales son públicos y no especifican metadatos Cache-Control, Cloud Storage asigna a los objetos un encabezado Cache-Control: public, max-age=3600. Puedes configurar diferentes valores mediante los metadatos Cache-Control.

Para ver un ejemplo que muestra cómo configurar un balanceador de cargas de HTTP(S) externo con un bucket de backend, consulta Configura Cloud CDN con un bucket de backend.

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
5 TB (5,497,558,138,880 bytes) 10 MB (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.

Una respuesta no se almacena en caché 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, bucket de backend o un origen personalizado que no tenga habilitado Cloud CDN
Cookie Tiene un encabezado Set-Cookie
Encabezado Vary Tiene un valor distinto de Accept, Accept-Encoding o Origin.
Directiva de respuesta La respuesta tiene un encabezado Cache-Control con la directiva no-store, no-cache 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 un encabezado Cache-Control: no-store
Tamaño Más grande que el tamaño máximo

Es posible que estos requisitos sean flexibles en el futuro, lo que permitiría a Cloud CDN almacenar en caché respuestas adicionales.

Si Cache-Control: no-store, no-cache 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 sin excepción.
  2. Incluye un encabezado Cache-Control: private en las respuestas que no deben almacenarse en memorias caché 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 URL 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.

Agrega encabezados de respuesta personalizados

Con los encabezados de respuesta personalizados, puedes especificar encabezados que el balanceador de cargas de HTTP(S) externo 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. Las solicitudes de http://example.com/images/cat.jpg o https://example.com/images/cat.jpg?user=user1 no coinciden.

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.

En los buckets de backend, la clave de caché consiste en el URI sin el protocolo, el host ni la string de consulta.

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

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

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

Los encabezados Vary a veces se usan cuando se entrega contenido comprimido. Cloud CDN no comprime ni descomprime las respuestas, pero puede entregar respuestas que comprima el servidor de origen. Si el servidor de origen elige entregar contenido comprimido o sin comprimir según el valor del encabezado de la solicitud Accept-Encoding, asegúrate de que la respuesta especifique Vary: Accept-Encoding.

Plazos de vencimiento y solicitudes de validación

Con el modo de almacenamiento en caché USE_ORIGIN_HEADERS, cada entrada de 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. 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.

Con el modo de almacenamiento en caché CACHE_ALL_STATIC, cualquier respuesta de backend que tenga contenido estático se considera actualizada. Para el contenido no estático, la actualidad se basa en los encabezados de origen.

Con el modo de almacenamiento en caché FORCE_CACHE_ALL, todas las respuestas de backend se consideran actualizadas.

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é. Sin embargo, si el tiempo de vencimiento ya pasó, Cloud CDN no puede entregar una respuesta sin antes comunicarse con uno de los backends.

Cloud CDN vuelve a validar los objetos almacenados en caché que tienen más de 30 días. Esto permite la invalidación y expulsión automáticas del contenido almacenado en caché generado por el usuario. Cuando un valor max-age o s-maxage supera los 30 días (2,592,000 segundos), Cloud CDN trata el valor 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.

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é mediante solicitudes de rango de bytes, Cloud CDN inicia una solicitud de validación separada que incluye 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 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-ModifiedETag, Cloud CDN ignora la entrada de caché vencida y reenvía la solicitud del cliente al backend sin modificar.

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 garantía de que una entrada de caché permanezca en la caché hasta que venza. 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.

Configuración y anulación de TTL

Puedes definir mejor el comportamiento de Cloud CDN en relación con el tiempo que Cloud CDN espera antes de volver a validar el contenido.

Para obtener más información, consulta Usa la configuración y la anulación de TTL.

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 o Content-Range
  • Encabezado: ETag con un validador sólido
  • Encabezado: Last-Modified

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 del software del 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 HTTP(S) 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.

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.

Próximos pasos