Compartilhar via

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 que você migre 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 Desativação do Azure Front Door (clássico).

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

Cada site de borda do Front Door gerencia seu próprio cache e as solicitações podem ser atendidas por sites de borda diferentes. Como resultado, você ainda poderá ver algum tráfego chegar à sua origem, mesmo que tenha servido respostas armazenadas 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 cache. Embora ativos dinâmicos, como pontos de extremidade de API autenticados, não devem ser armazenados em cache para evitar o vazamento de informações pessoais. É recomendável ter rotas separadas para ativos estáticos e dinâmicos, com o cache desabilitado para o último.

Aviso

Antes de habilitar o cache, examine detalhadamente a documentação pública e teste todos os cenários possíveis. Conforme observado anteriormente, com 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 método de solicitação GET são armazenáveis em cache. Todos os outros métodos de solicitação são sempre proxies através pela rede.

Entrega de arquivos grandes

O Azure Front Door entrega arquivos grandes sem um limite no tamanho do arquivo. Se o cache estiver habilitado, o Front Door usará uma técnica chamada agrupamento de objetos. Quando um arquivo grande é solicitado, o Front Door recupera partes menores do arquivo da origem. Após o Front Door receber uma solicitação de arquivo completo ou de intervalo de bytes, o ambiente do Front Door solicitará o arquivo da origem em partes de 8 MB.

Depois que a parte chega no ambiente do Azure Front Door, ela é armazenada em cache e imediatamente distribuída para o usuário. Em seguida, o Front Door executa uma pré-busca da próxima parte em paralelo. Essa pré-busca garante que o conteúdo permaneça uma parte à frente do usuário, o que reduz a latência. Esse processo continua até que todo o arquivo seja baixado (se solicitado) ou até que o cliente encerre 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 todas as partes conforme são recebidas e, portanto, o arquivo inteiro não precisa ser armazenado no cache do Front Door. As solicitações subsequentes para o arquivo ou intervalos de bytes são disponibilizadas pela cache. Se as partes não estiverem todas armazenadas em cache, a pré-busca será usada para solicitar as partes da origem.

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

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

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

    Dica

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

  • Retornar uma resposta sem intervalos. Se a origem não puder lidar com solicitações de intervalo, ela poderá ignorar o cabeçalho Range e retornar uma resposta sem intervalos. Verifique se 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 codificação de transferência em partes (CTE) para enviar dados para o POP do Azure Front Door, não há suporte para tamanhos de resposta maiores que 8 MB.

Compactação de arquivo

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

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

  • "application/eot"
  • "application/font"
  • "application/font-sfnt"
  • "application/javascript"
  • “application/json”
  • "application/opentype"
  • "application/otf"
  • "application/pkcs7-mime"
  • "application/truetype"
  • "application/ttf",
  • "application/vnd.ms-fontobject"
  • "application/xhtml+xml"
  • "application/xml"
  • "application/xml+rss"
  • "application/x-font-opentype"
  • "application/x-font-truetype"
  • "application/x-font-ttf"
  • "application/x-httpd-cgi"
  • "application/x-mpegurl"
  • "application/x-opentype"
  • "application/x-otf"
  • "application/x-perl"
  • "application/x-ttf"
  • "application/x-javascript"
  • "font/eot"
  • "font/ttf"
  • "font/otf"
  • "font/opentype"
  • "image/svg+xml"
  • "text/css"
  • "text/csv"
  • "text/html"
  • "text/javascript"
  • "text/js", "text/plain"
  • "text/richtext"
  • "text/tab-separated-values"
  • "text/xml"
  • "text/x-script"
  • "text/x-component"
  • "text/x-java-source"

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

Esses perfis dão suporte às seguintes codificações de compactação:

Se uma solicitação com suporte para gzip e compactação Brotli, a compactação Brotli terá precedência.

Quando uma solicitação de um ativo especificar a compactação e os resultados da solicitação em um cache forem perdidos, o Azure Front Door (clássico) realiza a compactação do ativo diretamente no servidor POP. Depois disso, o arquivo compactado será servido do cache. O item resultante é retornado com um cabeçalho de resposta Transfer-Encoding: chunked.

Se a origem usa CTE (Transferência de Codificação em Partes) para enviar dados para o POP do Azure Front Door, então não há suporte para compactação.

Observação

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 byte com o cabeçalho Accept-Encoding que leva à Origem respondendo com comprimentos de conteúdo diferentes, o Azure Front Door retornará um erro 503. Você pode desabilitar a compactação na origem ou criar uma regra de Mecanismo de Regras para remover o cabeçalho Accept-Encoding das solicitações de intervalo de bytes.

Comportamento da cadeia de caracteres de consulta

Com o Azure Front Door, é possível controlar como os arquivos são armazenados em cache para uma solicitação da Web que contenha 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 é aquela 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 de chave-valor, no qual 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, a ordem não importa.

Ao configurar o cache, você especifica como o cache deve lidar com cadeias de caracteres de consulta. Há suporte para os seguintes comportamentos:

  • Ignorar Cadeias 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 esse ativo que forem atendidas pelo ambiente do Front Door ignoram a cadeia de caracteres de consulta até que o ativo em cache expire.

  • Usar Cadeia de Caracteres: Nesse modo, cada solicitação com um 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 para uma solicitação de 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 www.example.ashx?q=test2 é armazenada em cache como um ativo separado com sua própria configuração de vida útil.

    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 armazenada em cache para a URL www.example.ashx?q=test1&r=test2, uma solicitação www.example.ashx?r=test2&q=test1 também será atendida do cache.

  • Ignorar cadeias de caracteres de consulta especificadas e incluir cadeias de caracteres de consulta especificadas: Nesse 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 seja /foo/image/asset.html e uma solicitação seja 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 parâmetro de cadeia de caracteres de consulta userid, 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 do Front Door.

Limpeza do cache

Confira Limpeza de cache no Azure Front Door para saber como configurar a limpeza do cache.

O Azure Front Door armazena em cache os ativos até a TTL (vida útil) do ativo expirar. Sempre que um cliente solicita um ativo com TTL expirado, o ambiente de 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 é verter os ativos para cada atualização e publicá-los como novas URLs. O Front Door recuperará imediatamente os novos ativos para as próximas solicitações do cliente. Às vezes, convém limpar o conteúdo em cache de todos os nós de borda e forçá-los a recuperar novos ativos atualizados. Isso pode ocorrer devido a atualizações do aplicativo Web ou para atualizar rapidamente ativos que contenham informações incorretas.

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

Selecione os ativos que você 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 têm suporte nas listas de caminhos a limpar:

  • 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 de caractere curinga: o asterisco (*) pode ser usado como um caractere 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 determinada pasta, especificando a pasta seguida por /*, por exemplo, /pictures/*.
  • Limpeza do domínio raiz: limpe a raiz do ponto de extremidade com "/" no caminho.

Observação

Limpeza de domínios curinga: a especificação de caminhos armazenados em cache para limpeza, conforme discutido nesta seção, não se aplica a domínios curinga que estejam associados ao Front Door. No momento, não há suporte para 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 meu Front Door tiver *.contoso.com, posso limpar os 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 limita-se a subdomínios de domínios curinga, se aplicável.

As limpezas de cache do Front Door diferenciam maiúsculas de minúsculas. Além disso, eles são independentes da cadeia de caracteres de consulta, o que significa que a limpeza de uma URL limpa todas as variações de cadeia de caracteres de consulta dela.

Expiração do cache

A ordem de cabeçalhos a seguir é 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 valores de cabeçalho de resposta Cache-Control indicam que a resposta não é armazenável em cache. Esses valores são private, no-cache, e no-store. O Front Door respeita esses valores de cabeçalho e não armazena em cache as respostas, mesmo que você substitua o comportamento de cache usando o Mecanismo de Regras.

Se o cabeçalho Cache-Control 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.

Observação

A expiração do cache não pode ser maior que 366 dias.

Você pode ver REVALIDATED_HIT no cabeçalho de resposta Cache-Control. Isso indica que o conteúdo armazenado em cache no Azure Front Door foi revalidado com o servidor de origem antes de ser fornecido 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 é fornecido ao cliente e a expiração do cache é redefinida.

Cabeçalhos da solicitação

Os cabeçalhos de solicitação a seguir não é encaminhado para a origem quando o cache estiver habilitado:

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

Observação

As solicitações que incluem o cabeçalho de autorização não serão armazenadas em cache, a menos que a resposta contenha uma diretiva de Controle de Cache que permita o cache. As seguintes diretivas de Controle de Cache 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 cabeçalho Set-Cookie será removido antes que a resposta seja enviada ao cliente. Se uma resposta de origem não for armazenável em cache, o Front Door não removerá o cabeçalho. Por exemplo, se a resposta de origem incluir um cabeçalho Cache-Control com um valor max-age, isso indica ao Front Door que a resposta é armazenável em cache e o cabeçalho Set-Cookie será removido.

Além disso, o Front Door anexa o cabeçalho X-Cache a todas as respostas. O cabeçalho de resposta X-Cache 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 é fornecido do cache do Front Door.
  • TCP_MISS: a primeira parte de 8 MB da resposta é uma perda de cache e o conteúdo é buscado da origem.
  • PRIVATE_NOSTORE: não foi possível armazenar a solicitação em cache porque o cabeçalho de resposta de Controle de Cache está definido como particular ou não armazenar em cache.
  • CONFIG_NOCACHE: a solicitação está configurada para não armazenar cache no perfil do 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 do cache do Mecanismo de Regras sempre substituirá a configuração da rota.

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

  • Quando o cache se encontra habilitado, o comportamento do cache difere com base no valor de comportamento do cache aplicado pelo Mecanismo de Regras:

    • Obedecer à origem: o Azure Front Door sempre obedece à diretiva do cabeçalho de resposta de origem. Se a diretiva de origem estiver ausente, o Azure Front Door armazena em cache o conteúdo de um a três dias.
    • Sempre substituir: o Azure Front Door sempre a substitui pela duração do cache, o que significa que ele armazena em cache o conteúdo pelo tempo de duração do cache ignorando os valores das diretivas da resposta de origem. Esse comportamento só é aplicado se a resposta for armazenável em cache.
    • Substituir se a origem estiver ausente: se a origem não retornar os valores de TTL de cache, o Azure Front Door usa a duração do cache especificada. Esse comportamento só é aplicado se a resposta for armazenável em cache.

Observação

  • O Azure Front Door não garante a quantidade de tempo em que o conteúdo é armazenado no cache. O conteúdo 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 frequência. O Front Door pode ser capaz de servir 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 estão offline.
  • As origens podem ser especificadas para 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 do Azure Front Door, o Azure Front Door dá suporte a diretivas de controle de cache e honra comportamentos de cache para diretivas de Cache-Control 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 do Azure Front Door e no Mecanismo de Regras. A configuração do cache do Mecanismo de Regras sempre substitui a configuração da regra de roteamento do designer do Azure Front Door.

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

  • Quando o cache estiver habilitado, o comportamento dele será diferente para valores distintos de Usar duração padrão do cache.

    • Quando Usar duração padrão do cache for definido como Sim, o Azure Front Door (clássico) sempre segue a diretiva do cabeçalho da resposta de origem. Se a diretiva de origem estiver ausente, o Front Door armazenará em cache o conteúdo de um a três dias.
    • Quando Usar duração padrão do cache for definida como Não, o Azure Front Door (clássico) sempre a substitui pela duração do cache (campos obrigatórios), o que significa que ele armazena em cache o conteúdo pelo tempo de duração do cache ignorando os valores das diretivas da resposta de origem.

Observação

  • O Azure Front Door (clássico) não garante a quantidade de tempo em que o conteúdo é armazenado no cache. O conteúdo 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 frequência. O Azure Front Door (clássico) pode ser capaz de servir 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 estão offline.
  • A duração do cache definida na regra de roteamento do Designer do Azure Front Door é a duração mínima do cache. Essa substituição não funcionará se o cabeçalho de controle de cache da origem tiver uma TTL maior do que o valor de substituição.

Próximas etapas