Visão geral do armazenamento em cache

Uma resposta armazenável em cache é uma resposta HTTP que o Cloud CDN pode armazenar e recuperar rapidamente, possibilitando tempos de carregamento mais rápidos. Nem todas as respostas HTTP são armazenáveis em cache.

Conteúdo armazenável em cache

O Cloud CDN armazena em cache somente as respostas que atendem todos os requisitos desta seção. Alguns desses requisitos são especificados no documento RFC 7234 (em inglês), enquanto outros são específicos para o Cloud CDN.

Uma resposta poderá ser armazenada em cache somente se todas estas condições forem verdadeiras:

Atributo Requisito
Exibido por Serviço de back-end, bucket de back-end ou uma origem personalizada com o Cloud CDN ativado
Em resposta a Solicitação GET:
Código de status 200, 203, 206, 300, 301, 302, 307 ou 410
Diretiva de cache Tem um cabeçalho Cache-Control com uma diretiva public
Atualização Tem um cabeçalho Cache-Control com uma diretiva max-age ou s-maxage ou um cabeçalho Expires com um carimbo de data/hora no futuro
Conteúdo

Contém um cabeçalho Content-Length, Content-Range ou Transfer-Encoding válido

Por exemplo, um cabeçalho Content-Length que corresponde corretamente ao tamanho da resposta.

Size Menor ou igual ao tamanho máximo

Para buckets de back-end do Cloud Storage, existem várias maneiras de atender a esses requisitos:

Por padrão, ao tornar todo o bucket ou os objetos individuais públicos sem que esses objetos especifiquem metadados de controle de cache, o Cloud Storage atribui a eles um cabeçalho Cache-Control: public, max-age=3600. É possível definir valores diferentes usando metadados de controle de cache.

Para um exemplo de como configurar um balanceador de carga HTTP(S) externo com um bucket de back-end, consulte Como configurar o Cloud CDN com um bucket de back-end.

Tamanho máximo

O Cloud CDN aplica um tamanho máximo para cada resposta. Qualquer resposta com um corpo maior que o tamanho máximo não é armazenada em cache, mas ainda é entregue ao cliente.

O tamanho máximo varia dependendo se o servidor de origem é compatível com solicitações de intervalo de bytes.

O servidor de origem é compatível com solicitações de intervalo de bytes O servidor de origem não é compatível com solicitações de intervalo de bytes
5 TB (5.497.558.138.880 bytes) 10 MB (10.485.760 bytes)

Quase todos os servidores da Web modernos (incluindo NGINX, Apache e Varnish) são compatíveis com solicitações de intervalo de bytes.

Conteúdo não armazenável em cache

Há verificações que bloqueiam o armazenamento em cache das respostas.

Uma resposta não será armazenada em cache se não atender aos requisitos de Conteúdo armazenável em cache ou se qualquer uma das seguintes condições for verdadeira.

Atributo Requisito
Exibido por Serviço de back-end, bucket de back-end ou uma origem personalizada que não tem o Cloud CDN ativado
Cookie Tem um cabeçalho Set-Cookie
Diretiva de resposta A resposta tem um cabeçalho Cache-Control com a diretiva no-store, no-cache ou private
Diretiva de solicitação A solicitação tem um cabeçalho Cache-Control: no-store
Tamanho Maior que o tamanho máximo

Esses requisitos podem ser atenuados no futuro, permitindo que o Cloud CDN armazene mais respostas em cache.

Se Cache-Control: no-store, no-cache ou private estiver presente, mas o conteúdo ainda estiver sendo armazenado em cache, isso acontece porque a assinatura de URL está configurada. A próxima seção fornece informações sobre como evitar que as respostas sejam armazenadas em cache.

Como evitar o armazenamento em cache

Para evitar que informações particulares sejam armazenadas nos caches do Cloud CDN, faça o seguinte:

  1. Inclua um cabeçalho Cache-Control: private em respostas que não podem ser armazenadas em caches do Cloud CDN ou um cabeçalho Cache-Control: no-store em respostas que não podem ser armazenadas em nenhum cache, nem mesmo no de um navegador da Web.
  2. Não assine URLs que forneçam acesso a informações particulares. Quando o conteúdo é acessado usando um URL assinado, ele é potencialmente qualificado para armazenamento em cache, independente de quaisquer diretivas Cache-Control na resposta.

Chaves de cache

Cada entrada de cache do Cloud CDN é identificada por uma chave de cache. Quando uma solicitação chega ao cache, ele converte o URI da solicitação em uma chave de cache, depois compara com as chaves das entradas em cache. Se encontrar uma correspondência, o cache retornará o objeto associado a essa chave.

Em serviços de back-end, o padrão do Cloud CDN é usar o URI de solicitação completo como chave de cache. Por exemplo, https://example.com/images/cat.jpg é o URI completo de uma solicitação específica para o objeto cat.jpg. Essa string é usada como chave de cache padrão. Somente as solicitações com uma string idêntica a essa são correspondentes. As solicitações para http://example.com/images/cat.jpg ou https://example.com/images/cat.jpg?user=user1 não são correspondentes.

É possível alterar quais partes do URI são usadas na chave do cache. Embora o nome do arquivo e o caminho sempre façam parte da chave, é possível incluir ou omitir qualquer combinação de protocolo, host ou string de consulta ao personalizar sua chave de cache. A seção Como usar as chaves de cache mostra como personalizá-las.

Parte do URI Personalização URLs de exemplo que têm a mesma chave de cache
Protocolo Omita o protocolo da chave de cache.
  • https://example.com/images/cat.jpg
  • http://example.com/images/cat.jpg
Host Omita o host da chave de cache.
  • https://example.com/images/cat.jpg
  • https://example2.com/images/cat.jpg
String de consulta

Omita a string de consulta da chave de cache.

Omita ou inclua partes da string de consulta de forma seletiva.

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

Além de incluir ou omitir toda a string de consulta, é possível usar partes da string de consulta usando listas de inclusão e de exclusão.

Para buckets de back-end, a chave de cache consiste no URI sem o protocolo, o host ou a string de consulta.

Assim, para um determinado bucket de back-end, os seguintes URIs são resolvidos para o mesmo objeto em cache:

  • 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 inclusões da string de consulta

Você pode controlar quais são os parâmetros da string de consulta que o Cloud CDN incorpora às chaves de cache. Por exemplo, se você criar uma lista de inclusão de user, https://example.com/images/cat.jpg?user=user1&color=blue criará uma chave de cache de https://example.com/images/cat.jpg?user=user1 que também corresponde a https://example.com/images/cat.jpg?user=user1&color=red.

Para usar essa opção, você precisa incluir a string de consulta, especificar uma lista de inclusão não vazia e não especificar uma lista de exclusão.

Lista de exclusões da string de consulta

Para controlar, de forma seletiva, os parâmetros da string de consulta que o Cloud CDN ignora, use uma uma lista de exclusão. Por exemplo, se você criar uma lista de exclusão de user, todos os parâmetros de string de consulta, exceto user, serão usados na chave de cache.

Com a lista de exclusão configurada e uma entrada de https://example.com/images/cat.jpg?user=user1&color=blue, o Cloud CDN cria uma chave de cache de https://example.com/images/cat.jpg?color=blue que também corresponde a https://example.com/images/cat.jpg?user=user2&color=blue, mas não a https://example.com/images/cat.jpg?user=user1&color=red.

Para usar essa opção, é preciso incluir a string de consulta, especificar uma lista de exclusão não vazia e não especificar uma lista de inclusão.

Cabeçalhos Vary

Além do URI de solicitação, o Cloud CDN respeita todos os cabeçalhos Vary (em inglês) que os servidores de origem incluem nas respostas. O cabeçalho Vary indica que a resposta varia de acordo com os cabeçalhos de solicitação do cliente. Por exemplo, se uma resposta especificar Vary: Accept, o Cloud CDN usará uma entrada de cache para solicitações que especificam Accept: image/webp,image/*,*/*;q=0.8 e outra para solicitações que especificam Accept: */*.

Às vezes, os cabeçalhos Vary são usados ao exibir conteúdo compactado. O Cloud CDN não compacta nem descompacta respostas, mas pode veicular respostas compactadas pelo servidor de origem. Se o servidor de origem escolher exibir conteúdo compactado ou descompactado com base no valor do cabeçalho da solicitação Accept-Encoding, verifique se a resposta especifica Vary: Accept-Encoding.

As respostas com cabeçalhos Vary só são armazenadas em cache se o cabeçalho tiver um dos valores listados em Conteúdo armazenável em cache.

Prazo de validade e solicitações de validação

Cada entrada em um cache do Cloud CDN tem um prazo de validade definido pelos cabeçalhos Cache-Control: s-maxage, Cache-Control: max-age e/ou Expires de acordo com RFC 7234 (em inglês). Se mais de um estiver presente, Cache-Control: s-maxage terá precedência sobre Cache-Control: max-age, e Cache-Control: max-age terá precedência sobre Expires.

Quando o Cloud CDN recebe uma solicitação, ele consulta a entrada de cache correspondente e verifica há quanto tempo ela existe. Se a entrada de cache existir e for recente o bastante, a resposta poderá ser disponibilizada a partir do cache. Entretanto, se o prazo de validade tiver passado, o Cloud CDN não poderá exibir uma resposta sem antes estabelecer contato com um dos seus back-ends.

O Cloud CDN revalida objetos em cache com mais de 30 dias. Isso permite a invalidação automática e a remoção de conteúdo desatualizado armazenado em cache gerado pelo usuário. Quando um valor max-age ou s-maxage excede 30 dias (2.592.000 segundos), o Cloud CDN trata o valor como se fosse 2.592.000 segundos. Os clientes downstream ainda veem os valores precisos de max-age e s- maxage, mesmo que excedam 30 dias.

Se a resposta armazenada em cache anteriormente tiver cabeçalhos Last-Modified e/ou ETag, o Cloud CDN tentará usar as informações nesses cabeçalhos para validar a entrada de cache com o back-end. O Cloud CDN realizará essa validação de maneira ligeiramente diferente com base no uso de solicitações de intervalo de byte para o armazenamento em cache:

  • Se a resposta foi armazenada em cache usando solicitações de intervalo de bytes, o Cloud CDN inicia uma solicitação de validação separada que inclui os cabeçalhos If-Modified-Since e/ou If-None-Match.
  • Caso contrário, o Cloud CDN irá adicionar os cabeçalhos If-Modified-Since e/ou If-None-Match à solicitação do cliente e encaminhar a solicitação modificada ao back-end.

Se a cópia em cache ainda estiver atualizada, o back-end poderá validar a entrada de cache atual enviando uma resposta 304 Not Modified. Nesse caso, o back-end envia somente os cabeçalhos da resposta, não o corpo. O Cloud CDN insere os novos cabeçalhos de resposta no cache, atualiza o prazo de validade e exibe os novos cabeçalhos de resposta e o corpo da resposta em cache para o cliente.

Se a resposta armazenada em cache anteriormente não tiver um cabeçalho Last-Modified ou ETag, o Cloud CDN ignorará a entrada de cache expirada e encaminhará a solicitação do cliente para o back-end sem modificações.

O prazo de validade de um cache indica o período máximo pelo qual uma entrada de cache permanece válida. Não há garantia de que uma entrada de cache lá permaneça até que ela expire. As entradas de cache para conteúdos incomuns podem ser excluídas para dar espaço a conteúdos novos. Seja qual for o prazo de validade especificado, as entradas de cache que não são acessadas por 30 dias são automaticamente removidas.

Para mais informações, consulte Remoção e expiração.

Suporte para solicitações de intervalo de bytes

Uma resposta que atende aos seguintes critérios indica que o servidor de origem é compatível com solicitações de intervalo de bytes:

  • Código de status: 200 OK ou 206 Partial Content
  • Cabeçalho: Accept-Ranges: bytes
  • Cabeçalho: Content-Length e/ou Content-Range
  • Cabeçalho: ETag com um validador forte
  • Cabeçalho: Last-Modified

O Cloud Storage é compatível com solicitações de intervalo de bytes na maioria dos objetos. No entanto, o Cloud Storage não é compatível com solicitações de intervalo de bytes para objetos com metadados Content-Encoding: gzip, a menos que a solicitação do cliente inclua um cabeçalho Accept- Encoding: gzip. Se você tiver objetos do Cloud Storage maiores que 10 MB, verifique se eles não têm metadados Content-Encoding: gzip. Para informações sobre como editar metadados de objetos, consulte Como visualizar e editar metadados de objetos.

O software de servidor da Web mais conhecido também é compatível com solicitações de intervalo de bytes. Consulte a documentação do software do servidor da Web para detalhes sobre como ativar o suporte. Para mais informações sobre solicitações de intervalo de bytes, consulte a especificação HTTP (em inglês).

Quando um servidor de origem for compatível com solicitações de intervalo de bytes, o cache do Cloud CDN não armazenará uma resposta armazenável em cache pela primeira vez que ela for solicitada caso alguma das afirmações abaixo seja verdadeira:

  • O corpo da resposta está incompleto porque o cliente solicitou apenas parte do conteúdo.
  • O corpo da resposta é maior que 1 MB (1.048.576 bytes).

Quando isso acontece e a resposta satisfaz aos requisitos de armazenamento em cache normais, o cache registra se o servidor de origem tem suporte para as solicitações de intervalo de bytes dessa chave do cache e encaminha a resposta do servidor de origem para o cliente.

Em uma ausência no cache, o cache verifica se o servidor de origem tem suporte para solicitações de intervalo de bytes. Se as solicitações de intervalos de bytes forem compatíveis com a chave do cache, o cache não encaminhará a solicitação do cliente para o balanceador de carga HTTP(S). Em vez disso, o cache inicia as próprias solicitações de preenchimento de cache de intervalo de bytes para as partes do conteúdo que estiverem faltando. Se o servidor de origem retornar o intervalo de bytes solicitado em uma resposta 206 Partial Content, o cache poderá armazenar esse intervalo para solicitações futuras.

Um cache armazena uma resposta 206 Partial Content somente quando é recebido em resposta a uma solicitação de intervalo de bytes iniciada pelo cache. Como um cache não inicia uma solicitação de intervalo de bytes, a menos que tenha registrado anteriormente que o servidor de origem aceita solicitações de intervalo de bytes para essa chave de cache, um determinado cache não armazena conteúdo maior que 1 MB até o segundo acesso.

Solicitações iniciadas pelo Cloud CDN

Quando o servidor de origem é compatível com solicitações de intervalo de bytes, o Cloud CDN pode enviar várias solicitações a esse servidor em resposta a apenas uma solicitação do cliente. Conforme descrito abaixo, o Cloud CDN pode iniciar dois tipos de solicitações: solicitações de validação e de intervalo de bytes.

Uma resposta indicou que o servidor de origem era compatível com as solicitações de intervalo de bytes de uma chave de cache específica. Se essa resposta tiver expirado, o Cloud CDN iniciará uma solicitação de validação para confirmar que o conteúdo não foi alterado e que o servidor de origem ainda é compatível com as solicitações de intervalo do conteúdo. Se o servidor de origem responder com uma resposta 304 Not Modified, o Cloud CDN continuará exibindo o conteúdo usando intervalos de bytes. Do contrário, o Cloud CDN encaminha a resposta do servidor de origem para o cliente. Para controlar os tempos de expiração, use os cabeçalhos de resposta "Cache-Control" e "Expires".

Em uma ausência no cache, o Cloud CDN inicia solicitações de preenchimento de cache para um conjunto de intervalos de bytes que se sobrepõem à solicitação do cliente. Se alguns intervalos do conteúdo solicitado pelo cliente estiverem presentes no cache e outros não, o Cloud CDN exibirá todo o conteúdo possível a partir do cache e enviará solicitações de intervalo de bytes apenas para os intervalos que não estiverem no servidor de origem.

Cada solicitação de intervalo de bytes iniciada pelo Cloud CDN especifica um intervalo que começa em um deslocamento múltiplo de 2.097.136 bytes. Com a possível exceção do intervalo final, cada intervalo também tem 2.097.136 bytes. Se o conteúdo não for múltiplo desse tamanho, o intervalo final será menor. O tamanho e os deslocamentos usados nas solicitações de intervalos de bytes poderão mudar no futuro.

Como exemplo, pense em uma solicitação do cliente dos bytes de 1.000.000 a 3.999.999 de conteúdo que não está presente no cache. Neste exemplo, o Cloud CDN poderia iniciar duas solicitações GET, uma para os primeiros 2.097.136 bytes do conteúdo e a outra para os próximos 2.097.136 bytes. Isso resulta em 4.194.272 bytes de preenchimento de cache, mesmo que o cliente tenha solicitado apenas 3.000.000 bytes.

Ao usar um bucket do Cloud Storage como origem, cada solicitação GET é faturada como uma operação de Classe B separada. Você é cobrado por todas as solicitações GET processadas pelo Cloud Storage, incluindo todas as solicitações iniciadas pelo Cloud CDN. Quando uma resposta é exibida inteiramente de um cache do Cloud CDN, nenhuma solicitação GET é enviada ao Cloud Storage e você não é cobrado por nenhuma operação do Cloud Storage.

Quando o Cloud CDN inicia uma solicitação de validação ou de intervalo de bytes, ele não inclui cabeçalhos específicos do cliente, como Cookie ou User-Agent.

A seguir