Compartilhar via

Como funciona o cache

  • Artigo

Importante

A CDN do Azure Standard (clássica) será desativada em 30 de setembro de 2027. Para evitar qualquer interrupção de serviço, é importante migrar seus perfis da CDN do Azure Standard (clássica) para a camada Azure Front Door Standard ou Premium até 30 de setembro de 2027. Para obter mais informações, confira CDN do Azure Standard (clássica).

O CDN do Azure da Edgio será desativado em 4 de novembro de 2025. Você deve migrar sua carga de trabalho para o Azure Front Door antes desta data para evitar interrupção do serviço.. Para obter mais informações, veja Perguntas frequentes sobre a aposentadoria do CDN do Azure da Edgeo.

Este artigo fornece uma visão geral dos conceitos gerais de cache e como a Rede de Distribuição de Conteúdo do Azure usa o cache para melhorar o desempenho. Se deseja saber como personalizar o comportamento de cache no ponto de extremidade da rede de distribuição de conteúdo, consulte Controlar o comportamento de cache da Rede de Distribuição de Conteúdo do Azure com regras de cache e Controlar o comportamento de cache da Rede de Distribuição de Conteúdo do Azure com cadeias de caracteres de consulta.

Introdução ao cache

O cache é o processo de armazenamento de dados localmente para que as solicitações futuras desses dados possam ser acessadas com maior rapidez. No tipo de cache mais comum, o cache do navegador da Web, um navegador da Web armazena cópias de dados estáticos localmente em um disco rígido local. Ao usar o cache, o navegador da Web pode evitar fazer várias viagens de ida e volta ao servidor e, em vez disso, acessar os mesmos dados localmente, economizando tempo e recursos. O cache é adequado para gerenciar localmente pequenos dados estáticos, como imagens estáticas, arquivos CSS e arquivos JavaScript.

Do mesmo modo, o cache é utilizado por uma rede de distribuição de conteúdo em servidores de borda próximos ao usuário para evitar solicitações viajando de volta para a origem e reduzir latência do usuário final. Ao contrário de um cache do navegador da Web, que é usado apenas para um usuário único, a rede de distribuição de conteúdo possui um cache compartilhado. Em um cache compartilhado da rede de distribuição de conteúdo, uma solicitação de arquivo feita por um usuário pode ser usada por outro usuário, o que diminui consideravelmente o número de solicitações para o servidor de origem.

Os recursos dinâmicos que sofrem alterações com frequência ou são exclusivos de um usuário individual não podem ser armazenados em cache. No entanto, esses tipos de recursos pode aproveitar a otimização de DSA (aceleração de site dinâmico) na rede de distribuição de conteúdo do Azure para aprimoramento de desempenho.

O cache pode ocorrer em vários níveis entre o servidor de origem e o usuário final:

  • Servidor Web: usa um cache compartilhado (para vários usuários).
  • Rede de distribuição de conteúdo: usa um cache compartilhado (para vários usuários).
  • ISP (Provedor de Serviços de Internet): usa um cache compartilhado (para vários usuários).
  • Navegador da Web: usa um cache privado (para um usuário).

Cada cache normalmente gerencia sua própria atualização de recurso e executa a validação quando um arquivo está obsoleto. Esse comportamento é definido na especificação de cache HTTP, RFC 7234.

Atualização de recurso

Como um recurso em cache pode estar potencialmente desatualizado ou obsoleto (em comparação com o recurso correspondente no servidor de origem), é importante que o mecanismo de cache controle quando o conteúdo é atualizado. Para poupar tempo e consumo de largura de banda, um recurso armazenado em cache não é comparado à versão no servidor de origem toda vez que é acessado. Em vez disso, desde que um recurso armazenado em cache seja considerado atualizado, ele é considerado a versão mais atualizada e enviado diretamente ao cliente. Um recurso armazenado em cache é considerado como atualizado quando o tempo decorrido for menor do que ao tempo decorrido ou o período definido por uma configuração de cache. Por exemplo, quando um navegador recarrega uma página da Web, ele verifica se cada recurso armazenado em cache no disco rígido está atualizado e o carrega. Se o recurso não estiver atualizado (obsoleto), uma cópia atualizada é carregada a partir do servidor.

Validação

Se um recurso for considerado obsoleto, o servidor de origem será solicitado a validá-lo para determinar se os dados no cache ainda correspondem ao que está no servidor de origem. Se o arquivo foi modificado no servidor de origem, o cache atualiza sua versão do recurso. Caso contrário, se o recurso estiver atualizado, os dados são distribuídos diretamente do cache sem validá-lo primeiro.

Cache de rede de distribuição de conteúdo

O cache é integral para a forma como uma rede de distribuição de conteúdo opera para acelerar a distribuição e reduzir a carga de origem para ativos estáticos, como imagens, fontes e vídeos. No cache de rede de distribuição de conteúdo, os recursos estáticos são armazenados seletivamente em servidores estrategicamente posicionados que são mais locais para um usuário e oferecem as seguintes vantagens:

  • Como a maior parte do tráfego da Web é estática (por exemplo, imagens, fontes e vídeos), o cache de rede de distribuição de conteúdo reduz a latência da rede ao mover o conteúdo mais próximo do usuário, reduzindo assim a distância de viagem dos dados.

  • Ao descarregar o trabalho para uma rede de distribuição de conteúdo, o cache pode reduzir o tráfego de rede e a carga no servidor de origem. Isso reduz os custos e os requisitos de recursos para o aplicativo, mesmo quando houver um grande número de usuários.

Semelhante ao modo como o cache é implementado em um navegador da Web, você pode controlar como o cache é executado em uma rede de distribuição de conteúdo enviando cabeçalhos de diretiva de cache. Os cabeçalhos de diretiva de cache são cabeçalhos HTTP, que normalmente são adicionados pelo servidor de origem. Embora a maioria desses cabeçalhos tenha sido originalmente projetada para lidar com o cache em navegadores cliente, eles também são utilizados por todos os caches intermediários, como redes de distribuição de conteúdo.

Dois cabeçalhos podem ser utilizados para definir a atualização de cache: Cache-Control e Expires. Cache-Control é o mais atual e tem precedência sobre Expires, se ambos existirem. Existem também dois tipos de cabeçalhos utilizados para validação (chamados de validadores): ETag e Last-Modified. ETag é mais atual e tem precedência sobre Last-Modified, se ambos estiverem definidos.

Cabeçalhos de diretiva de cache

Importante

Por padrão, um ponto de extremidade da Rede de Distribuição de Conteúdo do Azure otimizada para DSA ignora os cabeçalhos de diretiva de cache e ignora o cache. Para perfis CDN Standard do Azure do Edgio, é possível ajustar como um ponto de extremidade da Rede de Distribuição de Conteúdo do Azure trata esses cabeçalhos usando as regras de cache da rede de distribuição de conteúdo para habilitar cache. Somente para perfis CDN Premium do Azure do Edgio você usa o mecanismo de regras para habilitar cache.

A Rede de Distribuição de Conteúdo do Azure dá suporte aos seguintes cabeçalhos de diretiva de cache HTTP, que definem a duração do cache e o compartilhamento de cache.

Cache-Control:

  • Introduzido no HTTP 1.1 para dar aos editores da Web mais controle sobre seu conteúdo e tratar as limitações do cabeçalho Expires.
  • Substitui o cabeçalho Expires, se ele e Cache-Control estiverem definidos.
  • Quando usado em uma solicitação HTTP do cliente para POP da rede de distribuição de conteúdo, Cache-Control é ignorado por todos os perfis da Rede de Distribuição de Conteúdo do Azure, por padrão.
  • Quando usado em uma resposta HTTP do servidor de origem para POP da rede de distribuição de conteúdo:

Expires:

  • Cabeçalho herdado introduzido no HTTP 1.0; com suporte para compatibilidade com versões anteriores.
  • Usa um tempo de expiração baseado em data com segunda precisão.
  • Similar a Cache-Control: max-age.
  • Usado quando Cache-Control não existe.

Pragma:

  • Não é aceito pela Rede de Distribuição de Conteúdo do Azure, por padrão.
  • Cabeçalho herdado introduzido no HTTP 1.0; com suporte para compatibilidade com versões anteriores.
  • Usado como um cabeçalho de solicitação de cliente com a seguinte diretiva: no-cache. Essa diretiva instrui o servidor a entregar uma nova versão do recurso.
  • Pragma: no-cache é equivalente a Cache-Control: no-cache.

Validadores

Quando o cache está obsoleto, validadores de cache HTTP são usados para comparar a versão armazenada em cache de um arquivo com a versão no servidor de origem. A CDN Standard/Premium do Azure do Edgio dá suporte a validadores de ETag e Last-Modified por padrão, enquanto CDN Standard do Azure da Microsoft dá suporte apenas a Last-Modified.

ETag:

  • A CDN Standard/Premium do Azure do Edgio dá suporte a ETag por padrão, enquanto isso não acontece com CDN Standard do Azure da Microsoft.
  • ETag define uma cadeia de caracteres que é exclusiva para cada arquivo e versão de um arquivo. Por exemplo, ETag: "17f0ddd99ed5bbe4edffdd6496d7131f".
  • Introduzido no HTTP 1.1 e é mais atual do que Last-Modified. Útil quando a última data de modificação for difícil de determinar.
  • Dá suporte à validação forte e à validação fraca. No entanto, a Rede de Distribuição de Conteúdo do Azure dá suporte apenas à validação forte. Para uma validação de alta segurança, as duas representações de recursos devem ser de byte a byte idênticos.
  • Um cache valida um arquivo que usa ETag enviando um cabeçalho If-None-Match com um ou mais validadores ETag na solicitação. Por exemplo, If-None-Match: "17f0ddd99ed5bbe4edffdd6496d7131f". Se a versão do servidor coincidir com um validador ETag na lista, ele enviará o código de status 304 (não modificado) em sua resposta. Se a versão for diferente, o servidor responderá com o código de status 200 (OK) e o recurso atualizado.

Last-Modified:

  • Somente para a CDN Standard/Premium do Azure do Edgio, Last-Modified será usado se ETag não for parte da resposta HTTP.
  • Especifica a data e a hora em que o servidor de origem determinou que o recurso foi modificado pela última vez. Por exemplo, Last-Modified: Thu, 19 Oct 2017 09:28:00 GMT.
  • Para conteúdo maior que 8 MB, os servidores back-end de origem devem manter carimbos de data/hora Last-Modified consistentes por ativo. Retornar tempos Last-Modified inconsistentes dos servidores back-end causará erros de incompatibilidade do validador e resultará em falhas HTTP 5XX. O Armazenamento do Azure pode não suportar carimbos de data/hora consistentes de Last-Modified nas réplicas, o que pode causar erros semelhantes de incompatibilidade do validador.
  • Um cache valida um arquivo utilizando Last-Modified enviando um cabeçalho If-Modified-Since com uma data e hora na solicitação. O servidor de origem compara essa data com o cabeçalho Last-Modified do recurso mais recente. Se o recurso não foi modificado depois da hora especificada, o servidor retornará o código de status 304 (Não Modificado) em sua resposta. Se o recurso foi modificado, o servidor retornará o código de status 200 (OK) e o recurso atualizado.

Determinar quais arquivos podem ser armazenados em cache

Nem todos os recursos podem ser armazenados em cache. A tabela a seguir mostra quais recursos podem ser armazenados em cache, com base no tipo de resposta HTTP. Os recursos entregues com respostas HTTP que não atendem a todas essas condições não podem ser armazenados em cache. Para a CDN Premium do Azure do Edgio é possível utilizar o mecanismo de regras para personalizar algumas dessas condições.

Rede de Distribuição de Conteúdo do Azure da Microsoft Rede de Distribuição de Conteúdo do Azure do Edgio
Códigos de status HTTP 200, 203, 206, 300, 301, 410, 416 200
Métodos HTTP OBTER, PRINCIPAL GET
Limites de tamanho de arquivo 300 GB 300 GB

Para a CDN do Azure Standard da Microsoft em cache para funcionar em um recurso, o servidor de origem deve oferecer suporte a qualquer CABEÇALHO e solicitações HTTP GET e os valores de comprimento de conteúdo devem ser o mesmo para todas as respostas de CABEÇALHO e HTTP GET para o ativo. Para uma solicitação HEAD, o servidor de origem deve oferecer suporte à solicitação HEAD e deve responder com os mesmos cabeçalhos como se tivesse recebido uma solicitação GET.

Observação

As solicitações que incluem o cabeçalho de autorização não serão armazenadas em cache.

Comportamento de cache padrão

A tabela a seguir descreve o comportamento de cache padrão para os produtos da Rede de Distribuição de Conteúdo do Azure e suas otimizações.

Microsoft: entrega web geral Edgio: distribuição na Web geral Edgio: DSA
Aceitar a origem Sim Sim Não
duração do cache da rede de distribuição de conteúdo Dois dias Sete dias Nenhum

Aceitar a origem: especifica se deve aceitar os cabeçalhos de diretiva de cache com suporte, se eles existirem na resposta HTTP do servidor de origem.

Duração do cache da CDN: especifica por quanto tempo um recurso é armazenado em cache na rede de distribuição de conteúdo do Azure. No entanto, se Aceitar a origem for Sim e a resposta HTTP do servidor de origem incluir o cabeçalho de diretiva de cache Expires ou Cache-Control: max-age, a Rede de Distribuição de Conteúdo do Azure usará o valor de duração especificado pelo cabeçalho.

Observação

A Rede de Distribuição de Conteúdo do Azure não garante a quantidade mínima de tempo que o objeto será armazenado no cache. O conteúdo armazenado em cache poderão ser removidos do cache da rede de distribuição de conteúdo antes de expirarem se o conteúdo não for solicitado com a mesma frequência para dar espaço para o conteúdo solicitado com mais frequência.

Próximas etapas