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.

Modos de cache

Com os modos de cache, é possível controlar os fatores que determinam se o Cloud CDN armazena seu conteúdo.

O Cloud CDN oferece três modos de cache, que definem como as respostas serão armazenadas em cache, se o Cloud CDN vai respeitar as diretivas de cache enviadas pela origem e como os TTLs do cache serão aplicados.

Os modos de cache disponíveis são mostrados na tabela a seguir:

As respostas de erro podem ser armazenadas em cache, mesmo na ausência de diretivas de cache válidas.

Antes de definir o modo de cache como FORCE_CACHE_ALL, considere os seguintes comportamentos:

• Em URLs assinados ou cookies assinados, FORCE_CACHE_ALL substitui a idade máxima especificada usando a configuração de idade máxima da entrada de cache no console do Google Cloud ou na opção gcloud --signed-url-cache-max-age.

• O FORCE_CACHE_ALL muda o time to live (TTL) de qualquer conteúdo armazenado em cache anteriormente. Essa alteração pode fazer com que algumas entradas que foram consideradas atualizadas anteriormente (devido ao uso de TTLs mais longos nos cabeçalhos de origem) sejam consideradas desatualizadas e fazer com que algumas entradas que foram consideradas desatualizadas anteriormente sejam consideradas atualizadas.

• O FORCE_CACHE_ALL substitui as diretivas de cache (Cache-Control e Expires), mas não substitui outros cabeçalhos de resposta de origem. Em particular, um cabeçalho Vary pode suprimir o armazenamento em cache, mesmo que o modo de cache seja FORCE_CACHE_ALL. Para mais informações, consulte Cabeçalhos Vary.

Para instruções de configuração, consulte Como definir o modo de cache.

Conteúdo estático

O conteúdo estático é sempre igual, mesmo quando acessado por usuários diferentes. O CSS usado para customizar o site e o JavaScript que fornece conteúdo de interatividade, de vídeo e de imagem normalmente não mudam para cada usuário em um determinado URL (chave de cache) e, portanto, se beneficiam do armazenamento em cache na rede de borda global do Cloud CDN.

Quando o modo de cache é definido como CACHE_ALL_STATIC e uma resposta não tem diretivas de armazenamento em cache explícitas no cabeçalho Cache-Control ou Expires, o Cloud CDN armazena automaticamente essa resposta em cache para o seguinte:

• Recursos da Web, incluindo CSS (text/css), JavaScript (application/javascript) e todas as fontes da Web, inclusive WOFF2 (font/woff2)
• Imagens, incluindo JPEG (image/jpg) e PNG (image/png)
• Vídeos, incluindo H.264, H.265 e MP4 (video/mp4)
• Arquivos de áudio, incluindo MP3 (audio/mpeg) e MP4 (audio/mp4)
• Documentos formatados, incluindo PDF (application/pdf)

Veja um resumo na tabela a seguir.

O Cloud CDN inspeciona o cabeçalho de resposta HTTP Content-Type, que reflete o tipo MIME do conteúdo exibido.

Observe o seguinte:

• O software servidor da Web de origem precisa definir o Content-Type de cada resposta. Muitos servidores da Web definem automaticamente o cabeçalho Content-Type, incluindo NGINX, Varnish e Apache.

• O Cloud Storage define o cabeçalho Content-Type automaticamente quando é usado o console do Google Cloud ou a CLI do Google Cloud para fazer upload de conteúdo.

• O Cloud Storage sempre fornece um cabeçalho Cache-Control para o Cloud CDN. Se nenhum valor for escolhido de maneira explícita, ele enviará um valor padrão. Como resultado, todas as respostas do Cloud Storage são armazenadas em cache de acordo com os valores padrão do Cloud Storage, a menos que você ajuste explicitamente os metadados de controle de cache para objetos no Cloud Storage ou use o modo FORCE_CACHE_ALL para substituir os valores enviados pelo Cloud Storage.

• Se você quiser armazenar em cache os tipos de conteúdo text/html e application/json, defina cabeçalhos Cache-Control explícitos na resposta. Tenha cuidado para não armazenar em cache, por engano, os dados de um usuário e disponibilizá-los para todos os usuários.

Se uma resposta puder ser armazenada em cache com base no tipo MIME, mas tiver um cabeçalho de resposta Cache-Control de private ou no-store, ou um cabeçalho Set-Cookie, ela não será armazenada em cache. Para saber mais, consulte regras de capacidade de armazenamento em cache.

Outros tipos de conteúdo, como HTML (text/html) e JSON (application/json), não são armazenados em cache por padrão nas respostas. Esses tipos de respostas normalmente são dinâmicos (por usuário). Os exemplos incluem carrinhos de compras, páginas de produtos com personalização do usuário e respostas da API autenticadas. Entretanto, o armazenamento em cache negativo, se ativado, ainda pode fazer com que eles sejam armazenados em cache para determinados códigos de status.

O Cloud CDN não usa extensões de arquivo no caminho do URL para determinar se uma resposta é armazenável em cache porque muitas respostas armazenáveis em cache válidas não são refletidas nos URLs.

Conteúdo armazenável em cache

O Cloud CDN armazena em cache as respostas que atendem a todos os requisitos desta seção. Alguns desses requisitos são especificados no documento RFC 7234 e outros são específicos para o Cloud CDN.

O Cloud CDN pode alterar periodicamente o conjunto exato de condições em que ele armazena conteúdo em cache. Se você quiser impedir explicitamente que o Cloud CDN armazene em cache o conteúdo, siga as diretrizes no documento RFC 7234 para determinar como especificar uma resposta garantida não armazenável em cache. Consulte também a seção conteúdo não armazenável em cache baseado em cabeçalhos de origem.

O Cloud CDN armazenará as respostas em cache se todas as condições a seguir forem verdadeiras.

Em buckets de back-end do Cloud Storage, siga estas sugestões adicionais:

• Torne seu bucket acessível publicamente. Essa é a abordagem recomendada para conteúdo público. Com essa configuração, qualquer pessoa na Internet pode visualizar e listar seus objetos e metadados, exceto ACLs. A prática recomendada é dedicar buckets específicos para objetos públicos.

• Use pastas gerenciadas para tornar uma parte do bucket acessível publicamente.

• Torne objetos individuais acessíveis publicamente. Não recomendamos essa abordagem porque ela usa um sistema de permissões legado específico do Cloud Storage.

• Não armazene o objeto em um bucket com o recurso Pagamentos do requerente ativado ou que esteja em um perímetro de serviço de Nuvem Privada Virtual.

• Não criptografe o objeto usando chaves de criptografia gerenciadas pelo cliente ou chaves de criptografia fornecidas pelo cliente.

Por padrão, quando um objeto é público e não especifica metadados Cache-Control, o Cloud Storage atribui um cabeçalho Cache-Control: public, max-age=3600 ao objeto. É possível definir valores diferentes usando metadados Cache-Control.

Para ver um exemplo de como configurar um balanceador de carga de aplicativo 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.

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 com base em cabeçalhos de origem

Existem verificações que bloqueiam o armazenamento em cache das respostas. O Cloud CDN pode alterar periodicamente o conjunto exato de condições em que ele armazena conteúdo em cache. Portanto, se você quiser impedir explicitamente que o Cloud CDN armazene seu conteúdo em cache, siga as diretrizes da norma (RFC 7234) para determinar como especificar uma resposta não garantida armazenável em cache.

O Cloud CDN não armazenará em cache uma resposta se ela não atender aos requisitos de Conteúdo armazenável em cache ou se qualquer uma das seguintes condições for verdadeira.

Se Cache-Control: no-store ou private está presente, mas o conteúdo ainda está sendo armazenado em cache, isso ocorre por um dos seguintes motivos:

• A assinatura de URL está configurada.
• O modo de cache do Cloud CDN está definido para forçar o armazenamento de todas as respostas.

Evitar o armazenamento em cache

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

1. Verifique se o modo de cache do Cloud CDN não está definido como FORCE_CACHE_ALL, que armazena todas as respostas incondicionalmente.
2. 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 cache algum, nem mesmo no cache de um navegador da Web.
3. 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, independentemente de quaisquer diretivas Cache-Control na resposta.
4. Em solicitações de origem (preenchimento de cache) que incluem o cabeçalho da solicitação Authorization, o Cloud CDN armazena em cache somente as respostas que incluem as diretivas de controle de cache public, must-revalidate ou s-maxage quando o modo de cache é definido como USE_ORIGIN_HEADERS ou CACHE_ALL_STATIC. Isso impede o armazenamento em cache acidental de conteúdo por usuário e de conteúdo que exija autenticação. O modo de cache FORCE_CACHE_ALL não tem essa restrição.

Cabeçalhos de resposta personalizados

Com cabeçalhos de resposta personalizados, é possível especificar cabeçalhos que o balanceador de carga de aplicativo clássico adiciona a respostas encaminhadas por proxy. Cabeçalhos de resposta personalizados permitem refletir o status de cache para os clientes, os dados geográficos dos clientes e os seus próprios cabeçalhos de resposta estática.

Para instruções, consulte Configurar cabeçalhos de resposta personalizados.

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.

Nos buckets de back-end, o padrão é que a chave de cache consista no URI sem o protocolo ou o host. Por padrão, somente parâmetros de consulta conhecidos no Cloud Storage são incluídos como parte da chave de cache (por exemplo, "generation").

Assim, em um determinado bucket de back-end, os seguintes URIs são resolvidos para o mesmo objeto armazenado 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

É possível alterar quais partes do URI são usadas na chave do cache. Embora o nome de 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 a chave de cache. A seção Como usar as chaves de cache mostra como personalizá-las.

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

Lista de inclusão da string de consulta

É possível 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, é preciso 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 inclusão da string de consulta para chaves de cache do Cloud Storage

A inclusão de parâmetros de consulta de URL em chaves de cache para buckets do Cloud Storage ajuda no suporte a cache busting. O cache busting permite que um usuário recupere uma nova versão do arquivo que foi enviado, mesmo que a versão anterior ainda esteja armazenada em cache de maneira válida com base na configuração do TTL.

É possível usar uma lista de inclusão com parâmetros de string de consulta na chave de cache usada para disponibilizar respostas de um bucket de back-end. O Cloud Storage não disponibiliza conteúdos ou rotas diferentes com base nos parâmetros de consulta, mas é possível incluir parâmetros que permitam aplicar cache busting ao conteúdo estático armazenado em buckets do Cloud Storage.

Por exemplo, é possível anexar um parâmetro de consulta ?version=VERSION ou ?hash=HASH com base no conteúdo subjacente. Isso limita a necessidade de invalidar proativamente o conteúdo e se alinha com fluxos de trabalho de desenvolvimento moderno da Web, em que frameworks e URLs da Web usam um hash do conteúdo para evitar a disponibilização de objetos desatualizados nas implantações.

Como a inclusão de parâmetros de consulta na chave de cache é apenas para permissão, o Cloud CDN não é compatível com a exclusão de parâmetros de consulta para um bucket de back-end.

Lista de exclusões da string de consulta

Para controlar, de maneira seletiva, os parâmetros de string de consulta que o Cloud CDN ignora, use uma lista de exclusão. Por exemplo, se for criada 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.

Ordem do parâmetro de consulta

A chave de cache gerada não depende da ordem dos parâmetros de consulta.

Por exemplo, os seguintes parâmetros de consulta geram a mesma chave de cache:

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

Configurações de cabeçalhos HTTP e cookies HTTP

É possível melhorar as taxas de ocorrência em cache e o descarregamento de origem com as seguintes configurações de chave de cache:

• Para serviços e buckets de back-end: use cabeçalhos HTTP como parte das chaves de cache ao incluir cabeçalhos nomeados na configuração da chave de cache.
• Somente para serviços de back-end: use cookies HTTP nomeados como chaves de cache, por exemplo, para testes A/B (multivariáveis), canários e cenários semelhantes.

As solicitações de cache que incluem cabeçalhos ou cookies HTTP adicionais na solicitação são armazenadas em cache na terceira solicitação em um local de cache dessa chave de cache. Isso reduz o impacto dos altos valores de cabeçalhos ou cookies de cardinalidade nas taxas de remoção de cache. Em circunstâncias e condições de tráfego do usuário normais, isso pode não ser perceptível e ajuda a garantir que o conteúdo em alta permaneça armazenado em cache.

Incluir cabeçalhos da solicitação

Para armazenar em cache mais variações de uma resposta, é possível incluir outros cabeçalhos de solicitação na chave de cache.

Alguns cabeçalhos não são permitidos em chaves de cache porque normalmente são de cardinalidade muito alta. Na maioria dos casos, os valores desses cabeçalhos são exclusivos por usuário (Cookie, Authorization) ou consistem em milhares de valores prováveis (Referer, User-Agent, Accept). Por exemplo, o cabeçalho User-Agent pode ter mais de 5.000 valores exclusivos, considerando a grande variedade de navegadores, dispositivos do usuário e sistemas operacionais. Esses tipos de cabeçalho teriam um impacto negativo grave nas taxas de ocorrência em cache.

Somente nomes de campo de cabeçalho HTTP válidos são aceitos de acordo com a norma RFC 7230. Os nomes dos campos de cabeçalho não diferenciam maiúsculas de minúsculas e cópias são rejeitadas.

Opcionalmente, é possível configurar o servidor de origem para incluir cabeçalhos da solicitação de chave de cache configurados na resposta Vary. Ele não é necessário para o Cloud CDN, mas pode ser útil para caches downstream. Para mais informações, consulte Cabeçalhos Vary.

O Cloud CDN não permite que os seguintes cabeçalhos sejam incluídos na lista de cabeçalhos:

• Accept
• Accept-Encoding
• Authority, porque é controlado pela configuração (cdnPolicy.includeHost)
• Authorization, normalmente por usuário, como em tokens Bearer do OAuth
• CDN-Loop
• Connection
• Content-MD5
• Content-Type
• Cookie
• Date
• Forwarded, geralmente por cliente ou por proxy
• From
• Host, porque é controlado pela configuração (cdnPolicy.includeHost)
• If-Match, If-Modified-Since ou If-None-Match
• Origin
• Proxy-Authorization
• Range
• Referer (ou Referrer)
• User-Agent
• Want-Digest
• X-CSRFToken e X-CSRF-Token, conforme usados pelo Django e pelo Ruby on Rails
• X-Forwarded-For, geralmente por cliente ou por proxy
• X-User-IP
• Qualquer cabeçalho que comece com o seguinte:
  • Access-Control-, como Access-Control-Request-Headers e Access-Control-Request-Method
  • Sec-Fetch-
  • Sec-GFE-
  • Sec-Google-
  • X-Amz-
  • X-GFE-
  • X-Goog-
  • X-Google-

Usar variáveis personalizadas com cabeçalhos da solicitação

As chaves de cache são úteis quando é necessário disponibilizar conteúdo de uma maneira diferente com base no dispositivo e no local de cada usuário. Por exemplo, você pode ativar um site responsivo para disponibilizar as imagens adequadas aos usuários que estão visualizando conteúdo com base no tipo de dispositivo ou definir um idioma padrão útil com base no local deles. É possível definir chaves de cache usando cabeçalhos da solicitação e variáveis personalizados.

Para usar variáveis personalizadas com cabeçalhos da solicitação, faça o seguinte:

1. Defina um cabeçalho da solicitação personalizado para o serviço de back-end. Inclua uma ou mais variáveis para o valor do cabeçalho da solicitação personalizado.
2. Atualize a chave de cache para usar o cabeçalho da solicitação personalizado.

Para o Cloud CDN, só é possível usar as variáveis a seguir na definição de cabeçalhos que sejam cabeçalhos da solicitação e cabeçalhos da chave de cache personalizados:

• device_request_type
• user_agent_family
• client_region
• client_region_subdivision

O Cloud CDN limita as variáveis para ajudar a manter o desempenho do cache. Isso é semelhante aos limites nos cabeçalhos que podem ser usados como chaves de cache.

Por exemplo, fosse possível especificar X-Lat-Long:{client_city_lat_long} como um cabeçalho da solicitação personalizado e adicionar X-Lat-Long ao conjunto de cabeçalhos de chave de cache, o Cloud CDN tentaria armazenar em cache uma cópia da resposta para cada valor de client_city_lat_long. Isso acabaria levando ao uso excessivo do cache, à transferência desnecessária de conteúdo e à redução da oportunidade de retorno de ocorrências de cache.

Por esses motivos, as variáveis com alta cardinalidade não são incluídas na lista de variáveis usadas para definir cabeçalhos da solicitação personalizados e, a seguir, chaves de cache.

Mesmos cabeçalhos com valores diferentes

Suponha que o usuário envie vários cabeçalhos de mesmo nome com valores diferentes. Por exemplo:

My-Header: Value1
My-Header: Value2

Nesse caso, o Cloud CDN modifica a solicitação pressupondo que o cabeçalho precisa seguir a convenção padrão que permite que alguns cabeçalhos tenham vários valores. O Cloud CDN os reúne em uma lista separada por vírgulas para enviar ao back-end. Portanto, é como se o cliente enviasse o seguinte:

My-Header: Value1, Value2

Incluir cookies nomeados

Um cookie HTTP é um pareamento de name=value e uma solicitação pode incluir vários cookies HTTP, tanto separados por ponto e vírgula na mesma linha quanto como cabeçalhos da solicitação Cookie distintos com um cookie por cabeçalho.

É possível fornecer uma lista de até cinco nomes de cookies.

Os user agents, como navegadores da Web, geralmente limitam o número de cookies armazenados por domínio a 4 KB. Não envie muitos cookies nem cookies grandes, porque o user agent talvez não envie todos eles em uma solicitação. Devido a isso, é possível que um usuário receba uma resposta em cache específica.

Caso o conteúdo estático seja disponibilizado em um nome do host diferente do qual você emite cookies, verifique se o atributo Domain do cookie (e o Path) permite que o cookie seja enviado com solicitações de conteúdo estático.

Se uma solicitação incluir várias instâncias do mesmo nome de cookie, somente a primeira será atendida.

Diretivas de controle de cache

As diretivas de controle de cache HTTP afetam o comportamento do Cloud CDN, conforme descrito na tabela a seguir.

N/A significa que uma diretiva não é aplicável a uma solicitação ou resposta.

Sempre que possível, o Cloud CDN está em conformidade com a norma RFC (HTTP RFC 7234). No entanto, é preferível otimizá-lo para o descarregamento do cache para minimizar o impacto que os clientes têm na taxa de ocorrência e/ou na carga de origem geral.

Em respostas que usam o cabeçalho HTTP/1.1 Expires:

• O valor do cabeçalho Expires precisa ser uma data de HTTP válida, conforme definido na norma RFC 7231.
• Uma data no passado, uma data inválida ou um valor de 0 indica que o conteúdo já expirou e precisa de revalidação.
• Se um cabeçalho Cache-Control estiver presente na resposta, o Cloud CDN ignorará o cabeçalho Expires.

A presença de um cabeçalho Expires válido e futuro permite que a resposta seja armazenada em cache e não exige que outras diretivas de cache sejam especificadas.

O cabeçalho HTTP/1.0 Pragma, se presente em uma resposta, será ignorado e transmitido no estado em que se encontra para o cliente. As solicitações de clientes com esse cabeçalho são transmitidas para a origem e não afetam a maneira como uma resposta é disponibilizada pelo Cloud CDN.

Cabeçalhos Vary

O cabeçalho Vary indica que a resposta varia de acordo com os cabeçalhos de solicitação do cliente. Além do URI de solicitação, o Cloud CDN também respeita os cabeçalhos Vary que os servidores de origem incluem nas respostas. 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 as que especificam Accept: */*.

A tabela na seção Conteúdo não armazenável em cache lista os cabeçalhos Vary que permitem o armazenamento em cache. Outros valores de cabeçalho Vary impedem que o conteúdo seja armazenado em cache.

O modo de cache FORCE_CACHE_ALL não substitui esse comportamento. Os cabeçalhos Vary são importantes para evitar o envenenamento de cache entre várias respostas possíveis do servidor de origem. Seria perigoso para FORCE_CACHE_ALL fazer com que essas respostas fossem armazenadas em cache.

Às vezes, os cabeçalhos Vary são usados na disponibilização de conteúdo compactado. O Cloud CDN não compacta nem descompacta respostas, a menos que a compactação dinâmica esteja ativada. No entanto, ele pode disponibilizar respostas que foram compactadas pelo servidor de origem. Se o servidor de origem optar por disponibilizar 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.

Ao usar cabeçalhos HTTP na chave de cache, o Cloud CDN armazena em cache várias cópias da resposta com base nos valores dos cabeçalhos da solicitação especificados, semelhantes ao suporte de Vary, mas sem a necessidade de que o servidor de origem especifique explicitamente qualquer cabeçalho de resposta Vary. Se a origem especificar os cabeçalhos da chave de cache na resposta Vary, o Cloud CDN tratará a resposta corretamente, da mesma forma que se os cabeçalhos não fossem mencionados na resposta Vary.

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

O prazo de validade de uma entrada de cache define por quanto tempo uma entrada de cache permanece válida. O valor fornecido pelo valor s-maxage (max-age ou expires) permite a revalidação automática de conteúdo desatualizado armazenado em cache gerado pelo usuário.

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 bem recente, a resposta poderá ser disponibilizada no cache. Se o prazo de validade tiver terminado, o Cloud CDN tentará revalidar a entrada de cache ao entrar em contato com um dos back-ends. Isso é feito antes da disponibilização da resposta, a menos que você ative serve-while-stale. Nesse caso, a revalidação é executada de forma assíncrona.

Para alguns modos de cache, é possível definir valores de TTL. Para mais informações, consulte Como usar configurações e substituições de TTL.

O modo de cache afeta a forma como a atualização é determinada.

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.

Por padrão, quando o prazo de validade exceder 30 dias (2.592.000 segundos), o Cloud CDN tratará a data de expiração como se fosse 2.592.000 segundos. Os clientes downstream ainda veem os valores precisos de max-age e de s-maxage, mesmo que excedam 30 dias.

Remoção

Não há garantia de que uma entrada permaneça no cache até que ela expire, porque entradas incomuns podem ser removidas antes da expiração a qualquer momento para liberar espaço para novos conteúdos. Como limite superior, as entradas de cache que não são acessadas por 30 dias são removidas automaticamente.

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

Usar solicitações condicionais para validação

O Cloud CDN pode tentar usar as informações nos cabeçalhos de resposta armazenados em cache para validar a entrada do cache com o back-end. Isso acontece quando os dois itens a seguir são verdadeiros:

• A resposta armazenada em cache anteriormente tem um cabeçalho Last-Modified ou ETag.
• A solicitação do cliente é uma solicitação GET que não contém cabeçalhos If-Modified-Since ou If-None-Match.

O Cloud CDN realizará essa validação de maneira ligeiramente diferente com base no uso de solicitações de intervalo de bytes para o armazenamento da resposta em cache:

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

Se a cópia armazenada 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.

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, para uma resposta 206 Partial Content, um valor Content-Range que indica o comprimento total do objeto de origem. Por exemplo, Content-length: 0-100/999 pode ser armazenado em cache, mas Content-length: 0-100/* não.
• Cabeçalho: Last-Modified e ETag com um validador forte

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 servidor da Web mais conhecido também é compatível com solicitações de intervalo de bytes. Consulte a documentação do seu servidor da Web para saber como ativar o suporte. Para mais informações sobre solicitações de intervalo de bytes, consulte a especificação HTTP.

Quando um servidor de origem for compatível com solicitações de intervalo de bytes, um cache do Cloud CDN não armazenará uma resposta armazenável em cache na 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 intervalo 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 de aplicativo externo. Em vez disso, o cache iniciará suas próprias solicitações de preenchimento de cache de intervalo de bytes para as partes do conteúdo que estiverem faltando.

O servidor de origem retorna uma resposta 206 Partial Content quando o Cloud CDN inicia a própria solicitação de preenchimento de cache de intervalo de bytes. Para que uma resposta 206 Partial Content seja considerada durante o armazenamento em cache, ela precisa incluir um cabeçalho Content-Range com uma diretiva complete-length que não inclua asteriscos, por exemplo, 0-100/999. Em seguida, o Cloud CDN armazena em cache essa resposta 206 Partial Content retornada e a usa para responder a futuras solicitações do cliente para esse conteúdo.

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 oferece suporte a solicitações de intervalo de bytes para essa chave de cache, um determinado cache não armazena conteúdo maior que 1 MB até a segunda vez que o conteúdo é acessado.

Devido à sua natureza distribuída, o Cloud CDN às vezes pode buscar o bloco final na origem mais de uma vez por local. Isso só afeta as primeiras solicitações por cada chave de cache.

Recolhimento (agrupamento) de solicitações

O recolhimento (ou agrupamento) de solicitações recolhe ativamente várias solicitações de preenchimento de cache orientadas pelo usuário para a mesma chave em uma única solicitação de origem por nó de borda. Isso pode reduzir ativamente a carga na origem e se aplica às solicitações de itens (respostas buscadas diretamente) e de blocos, em que o Cloud CDN usa solicitações Range para buscar objetos maiores com mais eficiência.

O recolhimento de solicitações está ativado por padrão.

As solicitações recolhidas se comportam da seguinte maneira:

• As solicitações recolhidas registram a solicitação voltada para o cliente e a solicitação de preenchimento do cache (recolhida).
• O líder da sessão recolhida é usado para fazer a solicitação de preenchimento de origem.
• Atributos de solicitação que não fazem parte da chave de cache, como o cabeçalho User-Agent ou Accept-Encoding, só refletem o líder da sessão recolhida.
• Não é possível recolher as solicitações que não têm a mesma chave de cache.

O diagrama a seguir mostra como as solicitações são agrupadas:

Em comparação, com o recolhimento de solicitações desativado ou no caso de solicitações que não podem ser agrupadas, o número de solicitações de origem e respostas pode ser igual ao número de clientes que tentam recuperar um objeto que não está armazenado em cache.

Para todos os tipos de solicitações, o recolhimento é ativado por padrão. Para tipos de solicitação de item, é possível desativar o recolhimento. Recomendamos desativar o recolhimento de solicitações de item em cenários sensíveis de latência alta, como veiculação do anúncio, em que a carga de origem não é uma consideração.

A tabela a seguir resume o comportamento padrão e a capacidade de configuração para diferentes tipos de solicitação.

Para desativar o recolhimento de solicitações de itens usando a CLI do Google Cloud para um bucket de back-end que se refere a um bucket do Cloud Storage:

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

Para ativar o recolhimento de solicitações de itens em um bucket de back-end usando a CLI do Google Cloud:

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

Para ativar o recolhimento de solicitações de item usando a CLI do Google Cloud para um serviço de back-end, incluindo grupos de VM e back-ends externos:

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

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. Controle os prazos de validade usando 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, o Cloud CDN exibirá todo o conteúdo possível a partir do cache e enviará solicitações de intervalo de bytes somente 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.

No campo httpRequest.userAgent do Cloud Logging, Cloud-CDN-Google significa que o Cloud CDN iniciou a solicitação.

Ignorar o cache

A ação de ignorar o cache permite que solicitações contendo cabeçalhos da solicitação específicos ignorem o cache, mesmo que o conteúdo tenha sido armazenado em cache anteriormente.

Esta seção fornece informações sobre como ignorar o cache com cabeçalhos HTTP, como Pragma e Authorization. Esse recurso é útil quando você quer garantir que os usuários ou clientes sempre tenham o conteúdo mais recente atualizado do servidor de origem. Convém fazer isso para testes, configuração de diretórios de preparo ou scripts.

Se um cabeçalho especificado corresponder, o cache será ignorado para todas as configurações do modo de cache, até mesmo FORCE_CACHE_ALL. A ação de ignorar o cache resultará em um grande número de ausências no cache se os cabeçalhos especificados forem comuns a muitas solicitações.

Antes de começar

• Verifique se o Cloud CDN está ativado. Para instruções, consulte Como usar o Cloud CDN.

• Se necessário, atualize para a versão mais recente da CLI do Google Cloud:

  gcloud components update
  

Configurar a opção de ignorar cache

É possível especificar até cinco nomes de cabeçalho HTTP. Os valores não diferenciam maiúsculas de minúsculas. O nome do cabeçalho precisa ser um token de campo de cabeçalho HTTP válido. Um nome de cabeçalho não pode aparecer mais de uma vez na lista de cabeçalhos adicionados. Para conhecer as regras sobre nomes de cabeçalho válidos, consulte Como cabeçalhos personalizados funcionam.

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

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

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

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

Desativar a opção de ignorar cache

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

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

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

A seguir

• Para entender como os modos de cache facilitam o armazenamento em cache do conteúdo, consulte Como usar os modos de cache.
• Para ativar o Cloud CDN para instâncias HTTP(S) com carga balanceada e buckets de armazenamento, consulte Como usar o Cloud CDN.
• Para saber mais sobre a invalidação de caches, consulte Visão geral da invalidação de caches.
• Para encontrar pontos de presença do GFE, consulte Locais de cache.