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 Standard do Azure da Microsoft (clássico) 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).

A CDN do Azure do Edgio foi desativada em 15 de janeiro de 2025. 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

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 o POP da CND (rede de distribuição de conteúdo), Cache-Control é respeitado por todos os perfis da Rede de Distribuição de Conteúdo do Microsoft Azure por padrão. A CDN do Azure também respeita os comportamentos de cache para diretivas Cache-Control no RFC 7234 - protocolo HTTP (HTTP/1.1): Caching (ietf.org).

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. CDN do Azure Standard dos perfis da Microsoft dá suporte apenas a Last-Modified.

Observação

A CDN do Azure da Microsoft (clássica) não dá suporte a ETag.

Last-Modified:

  • 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.

Condições Valor
Códigos de status HTTP 200, 203, 206, 300, 301, 410, 416
Métodos HTTP OBTER, PRINCIPAL
Limites de tamanho de arquivo 300 GB

Para que o cache funcione em um recurso, o servidor de origem deve oferecer suporte as solicitações HEAD e HTTP GET, e os valores de tamanho do conteúdo (content-length) devem ser o mesmo para todas as respostas de HEAD 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

O comportamento de cache padrão da CDN do Azure é Respeitar a origem e armazenar conteúdo em cache por dois dias.

Respeitar a origem: essa configuração especifica se os cabeçalhos de diretiva de cache (Cache-Control ou Expires) devem ser respeitados se estiverem presentes na resposta HTTP do servidor de origem.

Duração do cache da CDN: essa configuração especifica o tempo pelo qual um recurso é armazenado em cache na CDN do Azure. Se a opção Respeitar a origem estiver habilitada e a resposta HTTP do servidor de origem incluir o cabeçalho Cache-Control: max-age ou Expires, a CDN do Azure usará a duração especificada por esses cabeçalhos em vez do período padrão de dois dias.

Observação

O CDN 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