Detalhes de armazenamento em cache

Capacidade de armazenamento em cache

Nem todas as respostas HTTP são armazenáveis 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, 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:

  • A resposta foi veiculada por um serviço ou intervalo de back-end com o Cloud CDN ativado.
  • Foi uma resposta a uma solicitação de GET.
  • O código de status da resposta é 200, 203, 206, 300, 301, 302, 307 ou 410.
  • Ter um cabeçalho Cache-Control: public.
  • A resposta tem um cabeçalho Cache-Control: s-maxage, Cache-Control: max-age ou Expires.
  • A resposta tem um cabeçalho Content-Length, Content-Range ou Transfer-Encoding.
  • O tamanho da resposta é menor ou igual ao tamanho máximo.

Para atender a esses requisitos em intervalos de back-end, marque o objeto do Cloud Storage como acessível para leitura pública. Se você tornar o intervalo público em vez de marcar objetos individuais como acessíveis para leitura pública, será preciso adicionar os cabeçalhos Cache-Control necessários aos metadados de cada objeto.

Há também verificações que bloqueiam o armazenamento em cache das respostas. Uma resposta não será armazenada em cache se as seguintes informações forem verdadeiras:

  • Tem um cabeçalho Set-Cookie.
  • A resposta tem um cabeçalho Vary com um valor diferente de Accept, Accept-Encoding ou Origin.
  • A resposta tem uma diretiva Cache-Control: no-store, no-cache ou private.
  • A solicitação correspondente tinha uma diretiva Cache-Control: no-store.

Esses requisitos podem ser atenuados no futuro, permitindo que o Cloud CDN armazene mais respostas em cache. Para mais informações sobre como evitar que as respostas sejam armazenadas em cache, consulte a seção Como evitar armazenamento em cache.

Tamanho máximo

O Cloud CDN aplica um tamanho máximo que varia dependendo de o servidor de origem permitir ou não solicitações de intervalo de bytes:

  • 5 TB (5.497.558.138.880 bytes) se o servidor de origem permite solicitações de intervalo de bytes
  • 10 MB (10.485.760 bytes) se o servidor de origem não permite solicitações de intervalo de bytes

Respostas com um corpo maior que o tamanho máximo não serão armazenadas em cache.

Entradas de cache

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 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. O caminho e o nome do arquivo precisam fazer parte da chave, mas será possível incluir ou omitir qualquer combinação de protocolo, host ou string de consulta quando personalizar sua chave de cache. A seção Como usar as chaves de cache mostra como personalizar essas chaves.

  • Protocolo: você pode omitir o protocolo da chave. Se fizer isso, uma solicitação para https://example.com/images/cat.jpg receberá uma chave de cache de example.com/images/cat.jpg. Depois, as solicitações para https://example.com/images/cat.jpg e http://example.com/images/cat.jpg serão correspondentes a essa entrada de cache.
  • Host: você pode omitir o host da chave. Se fizer isso, as solicitações para example.com e example2.com corresponderão à mesma entrada de cache. Uma solicitação para https://example.com/images/cat.jpg seguida por uma solicitação para https://example2.com/images/cat.jpg resulta em uma ocorrência em cache para a segunda solicitação.
  • String de consulta: você pode omitir a string de consulta da chave de cache. Se você fizer isso, uma solicitação para https://example.com/images/cat.jpg?user=user1 receberá uma chave de cache de https://example.com/images/cat.jpg. Dessa maneira, https://example.com/images/cat.jpg?user=user1 e https://example.com/images/cat.jpg?user=user2 corresponderão à mesma entrada. Também é possível omitir ou incluir partes da string de consulta.

Além de incluir ou omitir toda a string de consulta, você também pode usar partes dela via listas de permissões e listas de proibições.

Em intervalos de back-end, a chave do cache consiste no URI sem a string de consulta. Assim https://example.com/images/cat.jpg, https://example.com/images/cat.jpg?user=user1, e https://example.com/images/cat.jpg?user=user2 são equivalentes.

Lista de permissõ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 permissões de user, https://example.com/images/cat.jpg?user=user1&color=blue cria 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, é preciso incluir a string de consulta, especificar uma lista de permissões que não esteja vazia e não especificar uma lista de proibições.

Lista negra da string de consulta

Você pode controlar quais são os parâmetros da string de consulta que o Cloud CDN ignora por meio de uma lista negra. Por exemplo, se você criar uma lista de proibições de user, todos os parâmetros da string de consulta, exceto user, serão usados na chave de cache.

Com a lista de proibições acima configurada e uma entrada de https://example.com/images/cat.jpg?user=user1&color=blue, o Cloud CDN criará 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 proibições que não esteja vazia e não especificar uma lista de permissões.

Cabeçalhos Vary

Além do URI de solicitação, o Cloud CDN também respeita todo os cabeçalhos Vary que os servidores de origem incluírem nas respostas. O cabeçalho Vary indica que a resposta varia de acordo com os cabeçalhos da solicitação do cliente. Por exemplo: se uma resposta especificar Vary: Accept, o Cloud CDN usará uma entrada de cache para as solicitações que especificarem Accept: image/webp,image/*,*/*;q=0.8 e outra para as solicitações que especificarem Accept: */*.

Os cabeçalhos Vary algumas vezes são usados ao veicular conteúdo compactado. O Cloud CDN não compacta nem descompacta respostas, mas ele pode veicular respostas que foram compactadas pelo servidor de origem. Caso o servidor de origem escolha se precisa veicular conteúdo compactado ou descompactado com base no valor do cabeçalho da solicitação Accept-Encoding, certifique-se de que a resposta especifique Vary: Accept-Encoding.

As respostas com os cabeçalhos Vary são armazenadas em cache somente se o cabeçalho tiver um dos valores listados em Capacidade de armazenamento em cache.

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

Cada entrada de 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 o RFC 7234. j Se mais de um estiver presente, Cache-Control: s-maxage terá precedência sobre Cache-Control: max-age, e Cache-Control: max-age terá 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á veicular uma resposta sem antes estabelecer contato com um dos seus back-ends.

Se a resposta armazenada em cache anteriormente tiver cabeçalhos Last-Modified e/ou ETag, o Cloud CDN poderá tentar usar as informações desses 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 que inclui os cabeçalhos If-Modified-Since e/ou If-None-Match.
  • Caso contrário, o Cloud CDN adiciona os cabeçalhos If-Modified-Since e/ou If-None-Match à solicitação do cliente e encaminha a solicitação modificada para o back-end.

Se o conteúdo armazenado em cache ainda estiver atualizado, o back-end poderá validar a entrada de cache existente 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 veicula 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 expirada do cache e encaminhará a solicitação do cliente para o back-end sem alteraçõ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á garantias de que uma entrada de cache permanecerá no mesmo cache até expirar. As entradas de cache para conteúdos não comuns 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 ver 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 tem suporte para solicitações de intervalo de bytes:

  • O código de status é 200 OK ou 206 Partial Content.
  • Ela tem um cabeçalho Accept-Ranges: bytes.
  • Ela tem um cabeçalho Content-Length e/ou Content-Range.
  • Ela tem um cabeçalho ETag com um validador forte e/ou um cabeçalho Last-Modified.

O Google Cloud Storage é compatível com solicitações de intervalo de bytes na maioria dos objetos. No entanto, ele não é compatível com solicitações de intervalo de bytes em objetos com os 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, certifique-se de que eles não tenham os metadados Content-Encoding: gzip. Consulte Como visualizar e editar metadados de objetos para informações sobre como editar metadados de objetos.

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

Quando um servidor de origem oferecer suporte para solicitações de intervalo de bytes, o cache do Cloud CDN não armazenará uma resposta armazenável 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 falha de 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 tiverem suporte na 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 iniciará 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 ela é recebida como resultado de uma solicitação de intervalo de bytes iniciada pelo cache. Um cache não iniciará uma solicitação de intervalo de bytes, a menos que esteja registrado que o servidor de origem tem suporte para solicitações de intervalo de bytes nessa chave de cache. Por isso, um determinado cache não armazenará um conteúdo maior que 1 MB até que seja acessado pela segunda vez.

Solicitações iniciadas pelo Cloud CDN

Quando o servidor de origem tem suporte para solicitações de intervalo de bytes, o Cloud CDN pode enviar várias solicitações ao servidor de origem em resposta a uma única solicitação do cliente. Conforme descrito abaixo, o Cloud CDN pode iniciar dois tipos de solicitação: 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 inicia uma solicitação de validação para confirmar que o conteúdo não foi alterado e que o servidor de origem ainda tem suporte para as solicitações de intervalo do conteúdo. Se o servidor de origem retornar uma resposta 304 Not Modified, o Cloud CDN veiculará 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 "Cache-Control" e "Expires".

Em uma falha de 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 veicula todo o conteúdo possível a partir do cache e envia 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 que é um 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 de tamanho. Se o conteúdo não for um 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.

Quando você usa um intervalo 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 é veiculada 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.

Como evitar o armazenamento em cache

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

  1. Inclua um cabeçalho Cache-Control: private em respostas que não devem ser armazenadas em caches do Cloud CDN ou um cabeçalho Cache-Control: no-store em respostas que não devem 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 ao usar uma URL assinada, ele é potencialmente qualificado para armazenamento em cache, independentemente de qualquer diretiva Cache-Control na resposta.

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Cloud CDN