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:
Modo cache | Comportamento |
---|---|
CACHE_ALL_STATIC |
Armazena automaticamente em cache respostas bem-sucedidas com
conteúdo estático que não são
caso contrário, não é possível armazená-lo em cache.
As respostas de origem que definem diretivas de armazenamento em cache válidas também são armazenadas em cache. Esse é o comportamento padrão para os back-ends compatíveis com o Cloud CDN criados usando a CLI do Google Cloud ou a API REST. |
USE_ORIGIN_HEADERS |
Requer respostas de origem bem-sucedidas para definir diretivas de cache e cabeçalhos de cache válidos. As respostas bem-sucedidas sem essas diretivas
são encaminhadas da origem. |
FORCE_CACHE_ALL |
Armazena incondicionalmente as respostas em cache, substituindo as diretivas de cache definidas pela origem. Esse modo não é apropriado se o back-end veicular conteúdo particular por usuário, como HTML dinâmico ou respostas da API. |
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:
Para URLs ou cookies assinados, o
FORCE_CACHE_ALL
substitui a idade máxima especificada por meio da configuração de idade máxima da entrada de cache no Console do Google Cloud ou na opçãogcloud --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 anteriormente atualizadas (devido ao uso de TTLs mais longos nos cabeçalhos de origem) sejam consideradas desatualizadas e fazer com que algumas entradas que antes eram consideradas desatualizadas sejam consideradas recentes. de dados.O
FORCE_CACHE_ALL
substitui as diretivas de cache (Cache-Control
eExpires
), mas não modifica outros cabeçalhos de resposta de origem. Em particular, um cabeçalhoVary
ainda é respeitado e pode suprimir o armazenamento em cache, mesmo na presença deFORCE_CACHE_ALL
. Para mais informações, consulte os 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 que você usa para customizar seu site e o JavaScript que fornece conteúdo interativo de vídeo e imagem normalmente não mudam a cada usuário para um determinado URL (chave de cache) e, portanto, se beneficiam do armazenamento em cache na rede de borda global do Cloud CDN.
Quando você define o modo de cache como CACHE_ALL_STATIC
e uma resposta
não tem diretivas de armazenamento em cache explícitas nos cabeçalhos Cache-Control
ou Expires
,
o Cloud CDN armazena automaticamente essa resposta em cache para os
seguintes itens:
- 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.
Categoria | Tipos MIME |
---|---|
Recursos da Web | text/css text/ecmascript text/javascript application/javascript |
Fontes | Qualquer Content-Type que corresponda a font/* |
Imagens | Qualquer Content-Type que corresponda a image/* |
Vídeos | Qualquer Content-Type que corresponda a video/* |
Áudio | Qualquer Content-Type que corresponda a audio/* |
Tipos de documento formatado | application/pdf e application/postscript |
O Cloud CDN inspeciona o cabeçalho de resposta HTTP Content-Type
, que
reflete o tipo de arquivo MIME
tipo
do conteúdo veiculado.
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çalhoContent-Type
, incluindo NGINX, Varnish e Apache.O Cloud Storage define o cabeçalho
Content-Type
automaticamente upload quando usar o o console ou a Google Cloud CLI para fazer upload de conteúdo.Se uma resposta puder ser armazenada em cache com base no tipo MIME, mas tiver um cabeçalho de resposta
Cache-Control
deprivate
ouno-store
, ou um cabeçalhoSet-Cookie
(veja a lista completa de regras), ela não será armazenada.
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 válidas armazenáveis não são refletidas nos URLs.
Se você quiser armazenar em cache os tipos de conteúdo text/html
e application/json
, será necessário
defina cabeçalhos Cache-Control
explícitos na resposta, sendo
cuidado para não armazenar acidentalmente os dados de um usuário em cache e exibi-los a todos os usuários.
Conteúdo armazenável em cache
O Cloud CDN armazena em cache 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.
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 seu conteúdo, siga as diretrizes na RFC 7234 para determinar como especificar uma resposta garantida sem cache. Consulte também a seção conteúdo não armazenável em cache com base nos cabeçalhos de origem.
O Cloud CDN armazenará as respostas em cache se todas as condições a seguir forem verdadeiras.
Atributo | Requisito |
---|---|
Exibido por | Serviço de back-end, bucket de back-end ou um back-end externo com o Cloud CDN ativado |
Em resposta a | Solicitação GET : |
Código de status |
|
Atualização | A resposta tem um cabeçalho Para respostas armazenáveis em cache sem uma idade (por exemplo, com
Com o modo de cache Com o modo de cache Se o armazenamento em cache negativo estiver ativado e o código de status corresponder a um para o qual o armazenamento em cache negativo especificar um TTL, a resposta será qualificada para o armazenamento em cache, mesmo sem uma diretiva de atualização explícita. |
Conteúdo | Para origens HTTP/1, a resposta deve conter um endereço
Para origens que usam versões mais avançadas do protocolo HTTP (HTTP/2 e mais tarde), a resposta não precisará ter esses cabeçalhos. |
Tamanho | Menor ou igual ao tamanho máximo.
Para respostas com tamanhos entre 10 MB e 100 GB, consulte as outras restrições de armazenamento em cache descritas em Solicitações de intervalo de bytes. |
Para buckets de back-end do Cloud Storage, existem várias maneiras de atender a esses requisitos:
Permita que o bucket seja legí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 seu bucket publicamente legível.
Permita a leitura pública de objetos individuais. Não recomendamos essa abordagem, porque ela usa uma arquitetura Sistema de permissões específico do Cloud Storage.
Por padrão, quando um objeto é público e não especifica Cache-Control
.
metadados, o Cloud Storage atribui um objeto 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.
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 |
---|---|
100 GB (107.374.182.400 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 com base em cabeçalhos de origem
Há 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. Assim, se você quiser impedir explicitamente que o Cloud CDN armazene seu conteúdo em cache, siga as diretrizes no padrão (RFC 7234) para determinar como especificar uma resposta sem cache garantido.
O Cloud CDN não armazenará em cache uma resposta 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 ou back-end externo que não tenha o Cloud CDN ativado |
Cookie | Tem um cabeçalho Set-Cookie |
Cabeçalho Vary |
Tem um valor diferente de Accept ,
Accept-Encoding ,
Access-Control-Request-Headers ,
Access-Control-Request-Method , Origin ,
Sec-Fetch-Dest , Sec-Fetch-Mode ,
Sec-Fetch-Site , X-Goog-Allowed-Resources ,
X-Origin , ou um dos cabeçalhos configurados para
fazer parte das configurações da chave de cache.
|
Diretiva de resposta | A resposta terá um cabeçalho Cache-Control com uma
diretiva no-store ou private ,
a menos que use o modo de armazenamento em cache FORCE_CACHE_ALL .
Nesse caso o cabeçalho Cache-Control será ignorado |
Diretiva de solicitação | A solicitação tem uma diretiva Cache-Control: no-store |
Solicitar autorização | A solicitação tem um cabeçalho Authorization , a menos que seja modificado pela resposta Cache-Control. |
tamanho; | Maior que o tamanho máximo |
Se Cache-Control: no-store
ou private
estiverem presentes, mas o
conteúdo ainda estiver sendo armazenado, isso se deverá a 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.
Como evitar o armazenamento em cache
Para evitar que informações particulares sejam armazenadas nos caches do Cloud CDN, faça o seguinte:
- Verifique se o modo de cache do Cloud CDN não está definido para
FORCE_CACHE_ALL
, que armazena todas as respostas incondicionalmente. - Incluir um cabeçalho
Cache-Control: private
nas respostas que não podem ser armazenadas em caches do Cloud CDN ou umCache-Control: no-store
em respostas que não devem ser armazenadas em cache, nem mesmo no cache do navegador. - Não assine URLs que forneçam acesso a
informações imprecisas ou inadequadas. Quando o conteúdo é acessado usando um URL assinado, ele é potencialmente qualificado para armazenamento em cache, independente de quaisquer diretivas
Cache-Control
na resposta. - Para 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 a diretiva de controle de cachepublic
,must-revalidate
es-maxage
quando o modo de cache é definido comoUSE_ORIGIN_HEADERS
ouCACHE_ALL_STATIC
. Isso evita armazenamento em cache acidental de conteúdo por usuário e que exija autenticação. O modo de cacheFORCE_CACHE_ALL
não tem essa restrição.
Como adicionar cabeçalhos de resposta personalizados
Com cabeçalhos de resposta personalizados, é possível especificar cabeçalhos que balanceador de carga de aplicativo clássico adiciona às respostas por proxy. Os cabeçalhos de resposta personalizados permitem refletir o status de cache dos seus clientes, dos dados geográficos deles e dos cabeçalhos de resposta estática que você tem.
Para ver a lista de cabeçalhos, consulte Variáveis que podem aparecer no valor do cabeçalho.
Para mais instruções, consulte Como trabalhar com 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. Solicitações de
http://example.com/images/cat.jpg
ou
https://example.com/images/cat.jpg?user=user1
não correspondem.
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, "geração").
Assim, em 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
É 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. |
|
Host | Omita o host da chave de cache. |
|
String de consulta | Omita a string de consulta da chave de cache. Omita ou inclua partes da string de consulta de maneira seletiva. |
|
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ões 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, 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.
A string de consulta inclui a lista de 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 ao bloqueio de cache. O impedimento de cache permite que um usuário recupere uma nova versão do arquivo que foi enviado, mesmo se a versão anterior ainda estiver válida em cache com base na configuração de TTL.
Inclua parâmetros de consulta específicos da lista na chave de cache usada para exibir respostas de um bucket de back-end. O Cloud Storage não veicula conteúdos ou rotas diferentes com base nos parâmetros de consulta, mas é possível incluir parâmetros que permitam bloquear o conteúdo estático armazenado em cache nos 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 o conteúdo proativamente 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 exibição de objetos desatualizados em 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 desses parâmetros para um bucket de back-end.
Lista de exclusões da string de consulta
Para controlar, de maneira seletiva, os parâmetros da string de consulta que o Cloud CDN
ignora, use 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.
Ordem do parâmetro de consulta
A chave de cache gerada não depende da ordem dos parâmetros de consulta.
Por exemplo, os parâmetros de consulta a seguir geram a mesma chave de cache:
info=123&variant=13e&geography=US
geography=US&variant=13e&info=123
Configurações de chaves de cache 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 buckets e serviços de back-end: use cabeçalhos HTTP como parte das chaves de cache incluindo 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 (multivariados), canário e cenários semelhantes.
As solicitações de cache que incluem cabeçalhos ou cookies HTTP extras 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 do cabeçalho de alta cardinalidade ou dos valores de cookies nos seus as taxas de remoção de cache. Em circunstâncias normais e nas condições de tráfego de usuários, Isso não deve ser perceptível e ajuda a garantir que o conteúdo em alta continue armazenadas em cache.
Como incluir cabeçalhos de 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 geralmente
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 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 RFC 7230. Os nomes dos campos de cabeçalho não diferenciam maiúsculas de minúsculas, e as cópias são rejeitadas.
Opcionalmente, é possível configurar o servidor de origem para incluir cabeçalhos de 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 os cabeçalhos
Vary.
O Cloud CDN não permite que os cabeçalhos a seguir 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 nos tokensBearer
do OAuthCDN-Loop
Connection
Content-MD5
Content-Type
Cookie
Date
Forwarded
, geralmente por cliente ou por proxyFrom
Host
, porque é controlado pela configuração (cdnPolicy.includeHost
)If-Match
,If-Modified-Since
ouIf-None-Match
Origin
Proxy-Authorization
Range
Referer
(ouReferrer
)User-Agent
Want-Digest
X-CSRFToken
eX-CSRF-Token
, conforme usados pelo Django e pelo Ruby no RailsX-Forwarded-For
, geralmente por cliente ou por proxyX-User-IP
- Qualquer cabeçalho que comece com o seguinte:
Access-Control-
, comoAccess-Control-Request-Headers
eAccess-Control-Request-Method
Sec-Fetch-
Sec-GFE-
Sec-Google-
X-Amz-
X-GFE-
X-Goog-
X-Google-
Mesmos cabeçalhos com valores diferentes
Suponha que o usuário envie vários cabeçalhos de mesmo nome com valores de cabeçalho 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 as reúne em uma lista separada por vírgulas para enviar ao back-end. Assim, é como se o cliente tivesse enviado o seguinte:
My-Header: Value1, Value2
Como incluir cookies nomeados
Um cookie HTTP é um pareamento de name=value
, e uma solicitação pode incluir
vários deles, tanto separados por ponto e vírgula na mesma linha quanto
como cabeçalhos de 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 pode não enviar todos eles em uma solicitação. Devido a isso, é possível que um usuário receba uma resposta em cache específica.
Caso você veicule o conteúdo estático de um nome de host diferente do qual você
emite cookies, verifique se o atributo Domain
do cookie
(e o Path
) permite que ele 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.
Diretiva | Solicitação | Resposta |
---|---|---|
no-store |
Quando presente em uma solicitação, o Cloud CDN respeita isso e não armazena a resposta no cache. |
Uma resposta com
Isso pode ser modificado por back-end com o
modo de cache |
no-cache |
A diretiva de solicitação no-cache é ignorada para evitar que os clientes iniciem ou forcem a revalidação para a origem.
|
Uma resposta com
Isso pode ser modificado por back-end com o
modo de cache |
public |
N/A |
Essa diretiva não é necessária para armazenamento em cache, mas é uma prática recomendada incluí-la para conteúdo que precisa ser armazenado em cache por proxies. |
private |
N/A |
Uma resposta com a diretiva
Isso pode ser modificado por back-end com o
modo de cache |
max-age=SECONDS
|
A diretiva de solicitação max-age é ignorada. Uma resposta em cache é retornada como se esse cabeçalho não estivesse incluído na solicitação.
|
Uma resposta com a diretiva max-age é armazenada em cache até o SECONDS definido.
|
s-maxage=SECONDS
|
N/A |
Uma resposta com a diretiva
Se As respostas com essa diretiva não são exibidas.
|
min-fresh=SECONDS
|
A diretiva de solicitação min-fresh é ignorada. Uma resposta em cache é retornada como se esse cabeçalho não estivesse incluído na solicitação.
|
N/A |
max-stale=SECONDS
|
A diretiva de solicitação O Cloud CDN respeitará isso e retornará uma resposta em cache desatualizada somente se a inatividade da resposta for menor que a diretiva |
N/A |
stale-while-revalidate=SECONDS
|
N/A |
Uma resposta com
Esse comportamento pode ser ativado para todas as respostas, definindo |
stale-if-error=SECONDS
|
A diretiva de solicitação stale-if-error é ignorada. Uma resposta em cache é retornada como se esse cabeçalho não estivesse incluído na solicitação.
|
Este cabeçalho de resposta não tem efeito. |
must-revalidate |
N/A |
Uma resposta com As respostas com essa diretiva não são exibidas. |
proxy-revalidate |
Uma resposta com As respostas com essa diretiva não são exibidas. |
|
immutable |
N/A | Nenhum efeito. Isso é passado ao cliente na resposta. |
no-transform |
N/A | Nenhuma transformação é aplicada pelo Cloud CDN. |
only-if-cached |
A diretiva de solicitação only-if-cached é ignorada. Uma resposta em cache é retornada como se esse cabeçalho não estivesse incluído na solicitação.
|
N/A |
Sempre que possível, o Cloud CDN se esforça para ser compatível com o RFC (HTTP RFC 7234), mas prefere a otimização do descarregamento de cache e a minimização do impacto que os clientes podem ter na taxa de hits e na carga geral da origem.
Para respostas que usam o cabeçalho Expires
HTTP/1.1:
- O valor do cabeçalho
Expires
precisa ser uma data de HTTP válida, conforme definido no RFC 7231. - Uma data no passado, uma data inválida ou um valor de
0
indica que o conteúdo já expirou e requer revalidação. - Se um cabeçalho
Cache-Control
estiver presente na resposta, o Cloud CDN ignorará o cabeçalhoExpires
.
A presença de um cabeçalho Expires
válido e futuro na resposta 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 como está para o cliente. As solicitações do cliente com esse cabeçalho são
passados para a origem e não afetam como uma resposta é veiculada pelo
do Cloud CDN.
Cabeçalhos Vary
O Vary
cabeçalho indica que a resposta varia de acordo com a solicitação
cabeçalhos de solicitação. 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 modifica 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
sejam armazenadas em cache.
Às vezes, os cabeçalhos Vary
são usados ao exibir conteúdo compactado.
O Cloud CDN não compacta nem descompacta as respostas (a menos que
compactação dinâmica é
ativado), mas pode veicular respostas que o servidor de origem compactou. 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
.
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 de solicitação especificados, semelhantes ao suporte de Vary
, mas sem o prefixo
necessita 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
.
Prazo 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 recente o bastante, a resposta poderá ser disponibilizada a partir do cache. Se o prazo de validade tiver passado, o Cloud CDN tentará revalidar a entrada de cache entrando em contato com um dos back-ends. Isso é feito antes da exibiçã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 modificações de TTL.
O modo de cache afeta a forma como a atualização é determinada.
Modo cache | Comportamento de validação |
---|---|
CACHE_ALL_STATIC |
Os cabeçalhos de origem (Cache-Control: s-maxage ,
Cache-Control: max-age ou Expires ) são
consultados para determinar a atualização. Para conteúdo estático, se os cabeçalhos de origem não estiverem presentes, o default_ttl configurado determinará a atualização. Depois que o conteúdo estático é mais antigo que o default_ttl , o Cloud CDN o revalida. |
USE_ORIGIN_HEADERS |
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 ou Expires de acordo com RFC 7234 (em inglês). |
FORCE_CACHE_ALL |
Em vez de cabeçalhos de origem, o default_ttl configurado
determina a atualização. Depois que o conteúdo tiver mais de default_ttl , o Cloud CDN o validará novamente. |
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 valor do prazo de validade excede 30 dias (2.592.000 segundos), o Cloud CDN trata o valor de expiração 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.
Remoção
Não há garantia de que uma entrada de cache lá permaneça 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
ouETag
. - A solicitação do cliente é uma solicitação
GET
que não contém cabeçalhosIf-Modified-Since
ouIf-None-Match
.
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
If-Modified-Since
eIf-None-Match
. - Caso contrário, o Cloud CDN adicionará
If-Modified-Since
eIf-None-Match
cabeçalhos para a solicitação do cliente e encaminha 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.
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
ou206 Partial Content
- Cabeçalho:
Accept-Ranges: bytes
- Cabeçalho:
Content-Length
eContent-Range
- Cabeçalho:
Last-Modified
eETag
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 Content-Encoding: gzip
metadados. 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 o do seu 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.
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 de aplicativo.
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.
Devido à natureza distribuída dele, às vezes o Cloud CDN pode buscar a parte final da origem mais de uma vez por local. Isso afeta somente as primeiras solicitações por chave de cache.
Solicitar o recolhimento (agrupamento)
O recolhimento de solicitações (ou agrupamento) 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 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
ouAccept-Encoding
, refletem somente o líder da sessão recolhida. - As solicitações que não têm a mesma chave de cache não podem ser recolhidas.
O diagrama a seguir mostra como as solicitações são agrupadas:
Por outro lado, com o recolhimento de solicitações desativado ou para 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 confidenciais de latência alta, como veiculação de anúncios, em que a carga de origem não é uma consideração.
A tabela a seguir resume o comportamento padrão e a configurabilidade para diferentes tipos de solicitação.
Tipo de solicitação | Comportamento padrão | Configurável | Benefícios do recolhimento |
---|---|---|---|
Solicitações de fragmentos | Ativada | Não | Pode reduzir significativamente a largura de banda de origem |
Solicitações de itens | Ativada | Sim | Pode reduzir o volume de solicitações de origem |
Para desativar o recolhimento de solicitações de itens usando a CLI do Google Cloud para um bucket de back-end que faz referência a um bucket do Cloud Storage, faça o seguinte:
gcloud
Use o comando gcloud compute backend-services
ou backend-buckets
:
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
Use o comando gcloud compute backend-buckets
:
gcloud compute backend-buckets update BACKEND_BUCKET_NAME \ --request-coalescing
Para ativar o recolhimento da solicitação de item usando a CLI do Google Cloud para um serviço de back-end, incluindo grupos de VM e back-ends externos, faça o seguinte:
gcloud
Use o comando gcloud compute backend-services
:
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 eliminação de cache permite que solicitações contendo cabeçalhos de solicitação específicos ignorem o cache, mesmo que o conteúdo tenha sido armazenado em cache anteriormente.
Nesta seção, é possível encontrar 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 os testes, configurar diretórios
de preparo ou scripts.
Se um cabeçalho especificado corresponder, o cache será ignorado para todas as configurações do
modo cache, mesmo FORCE_CACHE_ALL
. O cache ignora o 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
Como configurar a opção de ignorar cache
É possível especificar até cinco nomes de cabeçalho HTTP. Os valores são indiferentes a maiúsculas. O nome do cabeçalho precisa ser uma definição válida do campo de cabeçalho HTTP. Um nome de cabeçalho não pode aparecer mais de uma vez na lista de cabeçalhos adicionados. Para ver as regras sobre nomes de cabeçalho válidos, consulte Como funcionam os cabeçalhos personalizados.
Console
- No Console do Google Cloud, acesse a página Balanceamento de carga.
- Clique no nome do seu balanceador de carga de aplicativo externo.
- Clique em Editar .
- Em Configuração de back-end, selecione um back-end e clique em Editar .
- Verifique se a opção Ativar o Cloud CDN está selecionada.
- Na parte inferior da janela, clique em Configurações avançadas.
- Em Ignorar cache no cabeçalho da solicitação, clique em Adicionar cabeçalho.
- Digite um nome de cabeçalho, como
Pragma
ouAuthorization
. - Clique em Atualizar.
- Clique em Atualizar novamente.
gcloud
Nos buckets de back-end, use o comando gcloud compute backend-buckets
create ou
gcloud compute backend-buckets
update com
a sinalização --bypass-cache-on-request-headers
.
Nos serviços de back-end, use o comando gcloud compute backend-services
create ou
gcloud compute backend-services
update com
a sinalização --bypass-cache-on-request-headers
.
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
Exemplo:
gcloud compute backend-services update my-backend-service --bypass-cache-on-request-headers=Pragma --bypass-cache-on-request-headers=Authorization
api
Para buckets de back-end, use a chamada de API Method: backendBuckets.insert, Method: backendBuckets.update ou Method: backendBuckets.patch .
Para serviços de back-end, use a chamada de API Method: backendServices.insert, Method: backendServices.update ou Method: backendServices.patch .
Exemplo:
PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets
Adicione o seguinte snippet ao corpo da solicitação JSON:
"cdnPolicy": { "bypassCacheOnRequestHeaders": [ { "headerName": string } ] }
Como desativar a opção de ignorar cache
gcloud
Nos buckets de back-end, use o comando gcloud compute backend-buckets
create ou
gcloud compute backend-buckets
update com
a sinalização --no-bypass-cache-on-request-headers
.
Nos serviços de back-end, use o comando gcloud compute backend-services
create ou
gcloud compute backend-services
update com
a sinalização --no-bypass-cache-on-request-headers
.
gcloud compute backend-services (create | update) (BACKEND_SERVICE_NAME | BACKEND_BUCKET_NAME) --no-bypass-cache-on-request-headers
api
Nos buckets de back-end, use a chamada de API Method: backendBuckets.insert ou Method: backendBuckets.update.
Nos serviços de back-end, use a chamada de API Method: backendServices.insert ou Method: backendServices.update.
Use uma das seguintes chamadas de API:
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
Adicione o seguinte snippet ao corpo da solicitação JSON:
"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.