How caching works (Como funciona a colocação em cache)

  • Artigo

Este artigo fornece uma visão geral dos conceitos gerais de cache e como a Rede de Entrega de Conteúdo do Azure usa o cache para melhorar o desempenho. Se você quiser saber mais sobre como personalizar o comportamento de cache em seu ponto de extremidade de rede de entrega de conteúdo, consulte Controlar o comportamento de cache da Rede de Entrega de Conteúdo do Azure com regras de cache e Controlar o comportamento de cache da Rede de Entrega de Conteúdo do Azure com cadeias de caracteres de consulta.

Introdução ao cache

O cache é o processo de armazenar dados localmente para que solicitações futuras para esses dados possam ser acessadas mais rapidamente. No tipo mais comum de cache, 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.

Da mesma forma, o cache é usado por uma rede de entrega de conteúdo em servidores de borda próximos ao usuário para evitar que as solicitações voltem para a origem e reduzam a latência do usuário final. Ao contrário de um cache do navegador da Web, que é usado apenas para um único usuário, a rede de entrega de conteúdo tem um cache compartilhado. Em um cache compartilhado de rede de entrega de conteúdo, uma solicitação de arquivo por um usuário pode ser usada por outro usuário, o que diminui muito o número de solicitações para o servidor de origem.

Os recursos dinâmicos que mudam com frequência ou são exclusivos de um usuário individual não podem ser armazenados em cache. Esses tipos de recursos, no entanto, podem aproveitar a otimização de aceleração dinâmica de site (DSA) na rede de entrega de conteúdo do Azure para melhorias 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).
  • Provedor de serviços de Internet (ISP): 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 recursos e executa a validação quando um arquivo está obsoleto. Esse comportamento é definido na especificação de cache HTTP, RFC 7234.

Frescura dos recursos

Como um recurso armazenado em cache pode estar desatualizado ou obsoleto (em comparação com o recurso correspondente no servidor de origem), é importante que qualquer mecanismo de cache controle quando o conteúdo recebe uma atualização. Para economizar 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 novo, ele é assumido como a versão mais atual e é enviado diretamente para o cliente. Um recurso armazenado em cache é considerado novo quando sua idade é menor do que a idade 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 novo (obsoleto), uma cópia atualizada será carregada 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 tiver sido modificado no servidor de origem, o cache atualizará sua versão do recurso. Caso contrário, se o recurso estiver atualizado, os dados serão entregues diretamente do cache sem validá-los primeiro.

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

O cache é parte integrante da maneira como uma rede de entrega de conteúdo opera para acelerar a entrega e reduzir a carga de origem de ativos estáticos, como imagens, fontes e vídeos. No cache de rede de entrega 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 da rede de entrega de conteúdo reduz a latência da rede movendo o conteúdo para mais perto do usuário, reduzindo assim a distância percorrida pelos 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 há um grande número de usuários.

Semelhante à forma 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 endereçar o cache em navegadores cliente, agora eles também são usados por todos os caches intermediários, como redes de entrega de conteúdo.

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

Cabeçalhos de diretiva de cache

Importante

Por padrão, um ponto de extremidade da Rede de Entrega de Conteúdo do Azure otimizado para DSA ignora cabeçalhos de diretiva de cache e ignora o cache. Para o Azure CDN Standard a partir de perfis Edgio , você pode ajustar como um ponto de extremidade da Rede de Entrega de Conteúdo do Azure trata esses cabeçalhos usando regras de cache de rede de entrega de conteúdo para habilitar o cache. Somente para perfis do Azure CDN Premium do Edgio, você usa o mecanismo de regras para habilitar o cache.

A Rede de Entrega 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 para resolver as limitações do Expires cabeçalho.
  • Substitui o Expires cabeçalho, se ambos estiverem Cache-Control definidos.
  • Quando usado em uma solicitação HTTP do cliente para o POP da rede de entrega de conteúdo, Cache-Control é ignorado por todos os perfis da Rede de Entrega de Conteúdo do Azure, por padrão.
  • Quando usado em uma resposta HTTP do servidor de origem para a rede de distribuição de conteúdo POP:

Caduca:

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

Pragma:

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

Validadores

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

ETag:

  • O Azure CDN Standard/Premium da Edgio suporta ETag por predefinição, enquanto o Azure CDN Standard da Microsoft não.
  • 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-Modifiedo . Útil quando a data da última modificação é difícil de determinar.
  • Suporta validação forte e validação fraca; no entanto, a Rede de Entrega de Conteúdo do Azure dá suporte apenas à validação forte. Para uma validação forte, as duas representações de recurso devem ser idênticas byte por byte.
  • Um cache valida um arquivo que usa ETag enviando um If-None-Match cabeçalho com um ou mais ETag validadores na solicitação. Por exemplo, If-None-Match: "17f0ddd99ed5bbe4edffdd6496d7131f". Se a versão do servidor corresponder a um ETag validador na lista, ele enviará o código de status 304 (Não modificado) em sua resposta. Se a versão for diferente, o servidor responde com o código de status 200 (OK) e o recurso atualizado.

Última modificação:

  • Para CDN do Azure Standard/Premium somente do Edgio , Last-Modified é usado se ETag não fizer 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.
  • Um cache valida um arquivo usando Last-Modified enviando um If-Modified-Since cabeçalho com uma data e hora na solicitação. O servidor de origem compara essa data com o Last-Modified cabeçalho do recurso mais recente. Se o recurso não tiver sido modificado desde a hora especificada, o servidor retornará o código de status 304 (Não modificado) em sua resposta. Se o recurso tiver sido modificado, o servidor retornará o código de status 200 (OK) e o recurso atualizado.

Determinando 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. Somente para a CDN Premium do Azure do Edgio , você pode usar o mecanismo de regras para personalizar algumas dessas condições.

Azure Content Delivery Network da Microsoft Rede de Entrega de Conteúdo do Azure da Edgio
Códigos de estado HTTP 200, 203, 206, 300, 301, 410, 416 200
Métodos HTTP OBTER, CABEÇA GET
Limites de tamanho de ficheiro 300 GB 300 GB

Para que o Azure CDN Standard do cache da Microsoft funcione em um recurso, o servidor de origem deve dar suporte a quaisquer solicitações HTTP HEAD e GET e os valores de comprimento de conteúdo devem ser os mesmos para qualquer resposta HTTP HEAD e GET para o ativo. Para uma solicitação HEAD, o servidor de origem deve suportar a solicitação HEAD e deve responder com os mesmos cabeçalhos como se recebesse uma solicitação GET.

Comportamento de cache padrão

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

Microsoft: Entrega geral na Web Edgio: Entrega geral na web Edgio: DSA
Origem da honra Sim Sim No
Duração do cache da rede de entrega de conteúdo Dois dias Sete dias Nenhuma

Origem de honra: especifica se os cabeçalhos de diretiva de cache suportados devem ser honrados se eles existirem na resposta HTTP do servidor de origem.

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

Nota

A Rede de Entrega de Conteúdo do Azure não garante sobre a quantidade mínima de tempo que o objeto será armazenado no cache. O conteúdo armazenado em cache pode ser removido do cache da rede de entrega de conteúdo antes de expirar se o conteúdo não for solicitado com tanta frequência para abrir espaço para o conteúdo solicitado com mais frequência.

Próximos passos