Armazenamento em cache com o Azure Front Door

  • Artigo

Importante

O Azure Front Door (clássico) será desativado em 31 de março de 2027. Para evitar qualquer interrupção do serviço, é importante migrar seus perfis do Azure Front Door (clássico) para a camada Azure Front Door Standard ou Premium até março de 2027. Para obter mais informações, consulte Aposentadoria (clássica) do Azure Front Door.

O Azure Front Door é uma rede de entrega de conteúdo (CDN) moderna, com aceleração dinâmica de site e recursos de balanceamento de carga. Quando o cache é configurado em sua rota, o site de borda que recebe cada solicitação verifica seu cache em busca de uma resposta válida. O cache ajuda a reduzir a quantidade de tráfego enviado para o servidor de origem. Se nenhuma resposta em cache estiver disponível, a solicitação será encaminhada para a origem.

Cada site de borda da Front Door gerencia seu próprio cache, e as solicitações podem ser atendidas por diferentes sites de borda. Como resultado, você ainda pode ver algum tráfego chegar à sua origem, mesmo se você serviu respostas em cache.

O cache pode diminuir significativamente a latência e reduzir a carga nos servidores de origem. No entanto, nem todos os tipos de tráfego podem se beneficiar do cache. Ativos estáticos, como imagens, CSS e arquivos JavaScript, são ideais para armazenamento em cache. Embora os ativos dinâmicos, como pontos de extremidade de API autenticados, não devam ser armazenados em cache para evitar o vazamento de informações pessoais. Recomenda-se ter rotas separadas para ativos estáticos e dinâmicos, com cache desativado para o último.

Aviso

Antes de habilitar o cache, revise cuidadosamente a documentação pública e teste todos os cenários possíveis antes de habilitar o cache. Como observado anteriormente, com a configuração incorreta, você pode armazenar inadvertidamente em cache dados específicos do usuário que podem ser compartilhados por vários usuários, resultando em incidentes de privacidade.

Métodos de solicitação

Somente as solicitações que usam o GET método request podem ser armazenadas em cache. Todos os outros métodos de solicitação são sempre intermediados por proxy através da rede.

Entrega de ficheiros grandes

O Azure Front Door fornece arquivos grandes sem um limite no tamanho do arquivo. Se o cache estiver habilitado, o Front Door usará uma técnica chamada fragmentação de objetos. Quando um arquivo grande é solicitado, o Front Door recupera partes menores do arquivo da origem. Depois que o Front Door recebe uma solicitação de arquivo completo ou uma solicitação de arquivo de intervalo de bytes, o ambiente Front Door solicita o arquivo da origem em blocos de 8 MB.

Depois que o bloco chega ao ambiente do Azure Front Door, ele é armazenado em cache e imediatamente servido ao usuário. Front Door então pré-busca o próximo pedaço em paralelo. Essa pré-busca garante que o conteúdo fique um pedaço à frente do usuário, o que reduz a latência. Esse processo continua até que todo o arquivo seja baixado (se solicitado) ou o cliente feche a conexão. Para obter mais informações sobre a solicitação de intervalo de bytes, leia RFC 7233.

O Front Door armazena em cache todos os blocos à medida que são recebidos, para que o arquivo inteiro não precise ser armazenado em cache no cache do Front Door. As solicitações subsequentes para os intervalos de arquivos ou bytes são atendidas a partir do cache. Se os blocos não estiverem todos armazenados em cache, a pré-busca será usada para solicitar blocos da origem.

Essa otimização depende da capacidade da origem de suportar solicitações de intervalo de bytes. Se a origem não suportar solicitações de intervalo de bytes ou se não manipular solicitações de intervalo corretamente, essa otimização não será eficaz.

Quando sua origem responde a uma solicitação com um Range cabeçalho, ela deve responder de uma das seguintes maneiras:

  • Retorne uma resposta variada. A resposta deve usar o código de status HTTP 206. Além disso, o cabeçalho da Content-Range resposta deve estar presente e corresponder ao comprimento real do conteúdo retornado pela sua origem. Se sua origem não enviar os cabeçalhos de resposta corretos com valores válidos, o Azure Front Door não armazenará a resposta em cache e você poderá ver um comportamento inconsistente.

    Gorjeta

    Se sua origem compactar a resposta, verifique se o valor do Content-Range cabeçalho corresponde ao comprimento real da resposta compactada.

  • Retornar uma resposta sem intervalo. Se sua origem não puder lidar com solicitações de intervalo, ela poderá ignorar o Range cabeçalho e retornar uma resposta sem intervalo. Certifique-se de que a origem retorna um código de status de resposta diferente de 206. Por exemplo, a origem pode retornar uma resposta 200 OK.

Se a origem usar a Codificação de Transferência Chunked (CTE) para enviar dados para o POP da Porta da Frente do Azure, não há suporte para tamanhos de resposta superiores a 8 MB.

Compressão de ficheiros

Consulte para melhorar o desempenho compactando arquivos no Azure Front Door.

O Azure Front Door (clássico) pode compactar dinamicamente o conteúdo na borda, resultando em um tempo de resposta menor e mais rápido para seus clientes. Para que um arquivo seja elegível para compactação, o cache deve ser habilitado e o arquivo deve ser de um tipo MIME para ser elegível para compactação. Atualmente, o Front Door (clássico) não permite que esta lista seja alterada. A lista atual é:

  • "Aplicação/EOT"
  • "aplicação/tipo de letra"
  • "aplicação/font-sfnt"
  • "aplicação/javascript"
  • "Aplicação/JSON"
  • "Aplicação/OpenType"
  • "Aplicação/OTF"
  • "Aplicação/PKCS7-MIME"
  • "aplicação/truetype"
  • "Aplicação/TTF",
  • "aplicativo/vnd.ms-fontobject"
  • "aplicativo/xhtml+xml"
  • "aplicativo/xml"
  • "Aplicação/XML+RSS"
  • "aplicação/x-font-opentype"
  • "aplicativo/x-font-truetype"
  • "aplicação/x-font-ttf"
  • "aplicação/x-httpd-cgi"
  • "aplicação/x-mpegurl"
  • "aplicação/x-opentype"
  • "Aplicação/X-OTF"
  • "Aplicação/X-Perl"
  • "aplicação/x-ttf"
  • "aplicação/x-javascript"
  • "fonte/eot"
  • "fonte/ttf"
  • "fonte/otf"
  • "fonte/opentype"
  • "imagem/svg+xml"
  • "texto/css"
  • "texto/csv"
  • "texto/html"
  • "texto/javascript"
  • "texto/js", "texto/simples"
  • "texto/richtext"
  • "valores separados por tabulação/texto"
  • "texto/xml"
  • "texto/x-script"
  • "texto/componente x"
  • "texto/x-java-source"

Além disso, o arquivo também deve ter entre 1 KB e 8 MB de tamanho, inclusive.

Esses perfis suportam as seguintes codificações de compactação:

Se uma solicitação suportar compressão gzip e Brotli, a compactação Brotli terá precedência.

Quando uma solicitação para um ativo especifica compactação e a solicitação resulta em uma falha de cache, o Azure Front Door (clássico) faz a compactação do ativo diretamente no servidor POP. Depois, o arquivo compactado é servido a partir do cache. O item resultante é retornado com um cabeçalho de Transfer-Encoding: chunked resposta.

Se a origem usar a Codificação de Transferência Chunked (CTE) para enviar dados para o POP da Porta da Frente do Azure, a compactação não será suportada.

Nota

As solicitações de intervalo podem ser compactadas em tamanhos diferentes. O Azure Front Door exige que os valores de comprimento de conteúdo sejam os mesmos para qualquer solicitação HTTP GET. Se os clientes enviarem solicitações de intervalo de bytes com o Accept-Encoding cabeçalho que leva o Origin a responder com diferentes comprimentos de conteúdo, o Azure Front Door retornará um erro 503. Você pode desabilitar a compactação na origem ou criar uma regra do mecanismo de regras para remover o Accept-Encoding cabeçalho da solicitação de solicitações de intervalo de bytes.

Comportamento da cadeia de caracteres de consulta

Com o Azure Front Door, você pode controlar como os arquivos são armazenados em cache para uma solicitação da Web que contém uma cadeia de caracteres de consulta.

Em uma solicitação da Web com uma cadeia de caracteres de consulta, a cadeia de caracteres de consulta é a parte da solicitação que ocorre após um ponto de interrogação (?). Uma cadeia de caracteres de consulta pode conter um ou mais pares chave-valor, nos quais o nome do campo e seu valor são separados por um sinal de igual (=). Cada par chave-valor é separado por um e comercial (&).

Por exemplo, a URL http://www.contoso.com/content.mov?field1=value1&field2=value2 contém duas cadeias de caracteres de consulta:

  • field1, com um valor de value1.
  • field2, com um valor de value2.

Se houver mais de um par chave-valor em uma cadeia de caracteres de consulta de uma solicitação, sua ordem não importa.

Ao configurar o cache, você especifica como o cache deve lidar com cadeias de caracteres de consulta. Os seguintes comportamentos são suportados:

  • Ignorar Cadeia de Caracteres de Consulta: neste modo, o Azure Front Door passa as cadeias de caracteres de consulta do cliente para a origem na primeira solicitação e armazena em cache o ativo. Solicitações futuras para o ativo que são servidas a partir do ambiente Front Door ignoram as cadeias de caracteres de consulta até que o ativo armazenado em cache expire.

  • Usar Cadeia de Caracteres de Consulta: Neste modo, cada solicitação com uma URL exclusiva, incluindo a cadeia de caracteres de consulta, é tratada como um ativo exclusivo com seu próprio cache. Por exemplo, a resposta da origem de uma solicitação para www.example.ashx?q=test1 é armazenada em cache no ambiente Front Door e retornada para caches subsequentes com a mesma cadeia de caracteres de consulta. Uma solicitação para www.example.ashx?q=test2 é armazenada em cache como um ativo separado com sua própria configuração de tempo de vida.

    A ordem dos parâmetros da cadeia de caracteres de consulta não importa. Por exemplo, se o ambiente do Azure Front Door incluir uma resposta em cache para a URL www.example.ashx?q=test1&r=test2, uma solicitação para www.example.ashx?r=test2&q=test1 também será atendida a partir do cache.

  • Ignorar cadeias de caracteres de consulta especificadas e incluir cadeias de caracteres de consulta especificadas: neste modo, você pode configurar o Azure Front Door para incluir ou excluir parâmetros especificados quando a chave de cache for gerada.

    Por exemplo, suponha que a chave de cache padrão é /foo/image/asset.html, e uma solicitação é feita para a URL https://contoso.com/foo/image/asset.html?language=EN&userid=100&sessionid=200. Se houver uma regra de mecanismo de regras para excluir o userid parâmetro de cadeia de caracteres de consulta, a chave de cache da cadeia de caracteres de consulta será /foo/image/asset.html?language=EN&sessionid=200.

Configure o comportamento da cadeia de caracteres de consulta na rota Front Door.

Limpeza de cache

Consulte Limpeza de cache na Porta da Frente do Azure para saber como configurar a limpeza de cache.

O Azure Front Door armazena ativos em cache até que o tempo de vida útil (TTL) do ativo expire. Sempre que um cliente solicita um ativo com TTL expirado, o ambiente Front Door recupera uma nova cópia atualizada do ativo para atender à solicitação e, em seguida, armazena o cache atualizado.

A prática recomendada para garantir que os usuários sempre obtenham a cópia mais recente de seus ativos é fazer a versão de seus ativos para cada atualização e publicá-los como novas URLs. A Front Door recuperará imediatamente os novos ativos para as próximas solicitações do cliente. Às vezes, você pode querer limpar o conteúdo armazenado em cache de todos os nós de borda e forçá-los a recuperar novos ativos atualizados. O motivo pode ser devido a atualizações em seu aplicativo Web ou atualizar rapidamente ativos que contêm informações incorretas.

Captura de ecrã do botão e da página de limpeza da cache.

Selecione os ativos que deseja limpar dos nós de borda. Para limpar todos os ativos, selecione Limpar tudo. Caso contrário, em Caminho, insira o caminho de cada ativo que você deseja limpar.

Esses formatos são suportados nas listas de caminhos a serem limpos:

  • Limpeza de caminho único: Limpe ativos individuais especificando o caminho completo do ativo (sem o protocolo e o domínio), com a extensão de arquivo, por exemplo, /pictures/strasbourg.png;
  • Limpeza curinga: Asterisk (*) pode ser usado como curinga. Limpe todas as pastas, subpastas e arquivos em um ponto de extremidade com /* no caminho ou limpe todas as subpastas e arquivos em uma pasta específica especificando a pasta seguida por /*, por exemplo, /pictures/*.
  • Limpeza de domínio raiz: limpe a raiz do ponto de extremidade com "/" no caminho.

Nota

Limpeza de domínios curinga: a especificação de caminhos em cache para limpeza, conforme discutido nesta seção, não se aplica a nenhum domínio curinga associado à Porta Frontal. Atualmente, não suportamos a limpeza direta de domínios curinga. Você pode limpar caminhos de subdomínios específicos especificando esse subdomínio específico e o caminho de limpeza. Por exemplo, se minha porta da frente tiver *.contoso.com, posso limpar ativos do meu subdomínio foo.contoso.com digitando foo.contoso.com/path/*. Atualmente, a especificação de nomes de host no caminho de conteúdo de limpeza é limitada a subdomínios de domínios curinga, se aplicável.

Os expurgos de cache na porta frontal não diferenciam maiúsculas de minúsculas. Além disso, eles são agnósticos à cadeia de caracteres de consulta, o que significa que limpar uma URL limpa todas as variações de cadeia de caracteres de consulta dela.

Expiração do cache

A seguinte ordem de cabeçalhos é usada para determinar por quanto tempo um item fica armazenado em nosso cache:

  1. Cache-Control: s-maxage=<seconds>
  2. Cache-Control: max-age=<seconds>
  3. Expires: <http-date>

Alguns Cache-Control valores de cabeçalho de resposta indicam que a resposta não pode ser armazenada em cache. Esses valores incluem private, no-cachee no-store. O Front Door respeita esses valores de cabeçalho e não armazena as respostas em cache, mesmo que você substitua o comportamento de cache usando o mecanismo de regras.

Se o Cache-Control cabeçalho não estiver presente na resposta da origem, por padrão, o Front Door determina aleatoriamente uma duração de cache entre um e três dias.

Nota

A expiração do cache não pode ser superior a 366 dias.

Você pode ver REVALIDATED_HIT no cabeçalho da Cache-Control resposta. Isso indica que o conteúdo armazenado em cache no Azure Front Door foi revalidado com o servidor de origem antes de ser servido ao cliente. Isso pode acontecer quando o conteúdo armazenado em cache expirou, mas o servidor de origem indica que o conteúdo não foi alterado. Nesse caso, o conteúdo armazenado em cache é servido ao cliente e a expiração do cache é redefinida.

Cabeçalhos do pedido

Os cabeçalhos de solicitação a seguir não são encaminhados para a origem quando o cache está habilitado:

  • Content-Length
  • Transfer-Encoding
  • Accept
  • Accept-Charset
  • Accept-Language

Nota

As solicitações que incluem cabeçalho de autorização não serão armazenadas em cache, a menos que a resposta contenha uma diretiva Cache-Control que permita o armazenamento em cache. As seguintes diretivas Cache-Control têm esse efeito: must-revalidate, public e s-maxage.

Cabeçalhos de resposta

Se a resposta de origem for armazenável em cache, o Set-Cookie cabeçalho será removido antes que a resposta seja enviada ao cliente. Se uma resposta de origem não puder ser armazenada em cache, o Front Door não removerá o cabeçalho. Por exemplo, se a resposta de origem incluir um Cache-Control cabeçalho com um max-age valor indica para Front Door que a resposta é armazenável em cache e o Set-Cookie cabeçalho é removido.

Além disso, o Front Door anexa o X-Cache cabeçalho a todas as respostas. O X-Cache cabeçalho de resposta inclui um dos seguintes valores:

  • TCP_HIT ou TCP_REMOTE_HIT: A primeira parte de 8 MB da resposta é um acerto de cache e o conteúdo é servido a partir do cache da Front Door.
  • TCP_MISS: O primeiro bloco de 8 MB da resposta é uma falha de cache e o conteúdo é buscado na origem.
  • PRIVATE_NOSTORE: A solicitação não pode ser armazenada em cache porque o cabeçalho de resposta Cache-Control está definido como privado ou sem armazenamento.
  • CONFIG_NOCACHE: A solicitação está configurada para não armazenar em cache no perfil Front Door.

Logs e relatórios

O log de acesso inclui o status do cache para cada solicitação. Além disso, os relatórios incluem informações sobre como o cache do Azure Front Door é usado em seu aplicativo.

O log de acesso inclui o status do cache para cada solicitação.

Comportamento e duração do cache

O comportamento e a duração do cache podem ser configurados no Mecanismo de regras. A configuração de cache do mecanismo de regras sempre substitui a configuração de rota.

  • Quando o cache está desabilitado, o Azure Front Door não armazena em cache o conteúdo da resposta, independentemente das diretivas de resposta de origem.

  • Quando o cache está habilitado, o comportamento do cache é diferente dependendo do valor do comportamento do cache aplicado pelo mecanismo de regras:

    • Origem de honra: o Azure Front Door sempre respeita a diretiva de cabeçalho de resposta de origem. Se a diretiva de origem estiver ausente, o Azure Front Door armazenará em cache o conteúdo em qualquer lugar de um a três dias.
    • Substituir sempre: o Azure Front Door sempre substitui pela duração do cache, o que significa que ele armazena em cache o conteúdo para a duração do cache ignorando os valores das diretivas de resposta de origem. Esse comportamento só se aplica se a resposta for armazenável em cache.
    • Substituir se a origem estiver ausente: se a origem não retornar valores TTL de cache, o Azure Front Door usará a duração do cache especificada. Esse comportamento só se aplica se a resposta for armazenável em cache.

Nota

  • O Azure Front Door não garante a quantidade de tempo que o conteúdo é armazenado no cache. O conteúdo armazenado em cache pode ser removido do cache de borda antes da expiração do conteúdo se o conteúdo não for usado com freqüência. O Front Door pode ser capaz de fornecer dados do cache mesmo que os dados armazenados em cache tenham expirado. Esse comportamento pode ajudar seu site a permanecer parcialmente disponível quando suas origens estiverem offline.
  • As origens podem especificar não armazenar em cache respostas específicas usando o cabeçalho Cache-Control com um valor de no-cache, private ou no-store. Quando usado em uma resposta HTTP do servidor de origem para os POPs da Porta da Frente do Azure, o Azure Front Door oferece suporte a diretivas de controle de cache e honra comportamentos de cache para diretivas de Controle de Cache no RFC 7234 - Protocolo de Transferência de Hipertexto (HTTP/1.1): Cache (ietf.org).

O comportamento e a duração do cache podem ser configurados na regra de roteamento do designer Front Door e no mecanismo de regras. A configuração de cache do mecanismo de regras sempre substitui a configuração da regra de roteamento do designer da porta frontal.

  • Quando o cache está desabilitado, o Azure Front Door (clássico) não armazena em cache o conteúdo da resposta, independentemente das diretivas de resposta de origem.

  • Quando o cache está habilitado, o comportamento do cache é diferente para valores diferentes de Usar duração padrão do cache.

    • Quando Usar duração padrão do cache é definido como Sim, a Porta da Frente do Azure (clássica) sempre honra a diretiva de cabeçalho de resposta de origem. Se a diretiva de origem estiver ausente, o Front Door armazena em cache o conteúdo em qualquer lugar de um a três dias.
    • Quando Usar duração padrão do cache é definido como Não, a Porta da Frente do Azure (clássica) sempre substitui pela duração do cache (campos obrigatórios), o que significa que ele armazena em cache o conteúdo para a duração do cache ignorando os valores das diretivas de resposta de origem.

Nota

  • O Azure Front Door (clássico) não garante a quantidade de tempo que o conteúdo é armazenado no cache. O conteúdo armazenado em cache pode ser removido do cache de borda antes da expiração do conteúdo se o conteúdo não for usado com freqüência. O Azure Front Door (clássico) pode ser capaz de fornecer dados do cache mesmo que os dados armazenados em cache tenham expirado. Esse comportamento pode ajudar seu site a permanecer parcialmente disponível quando suas origens estiverem offline.
  • A duração do cache definida na regra de roteamento do designer Front Door é a duração mínima do cache. Essa substituição não funcionará se o cabeçalho do controle de cache da origem tiver um TTL maior do que o valor de substituição.

Próximos passos