Otimizando o Desempenho com Regras de CDN

O mecanismo de regras do Azure Front Door (chamado de conjuntos de regras no Standard/Premium) permite interceptar e modificar solicitações e respostas HTTP no PoP de borda antes que elas sejam armazenadas em cache ou encaminhadas para a origem. Sem um mecanismo de regras, seria necessário tratar tarefas como redirecionamentos de HTTP para HTTPS, cabeçalhos de resposta de segurança e bloqueio geográfico no código da aplicação de origem — adicionando latência e acoplando questões de segurança à lógica de negócios. As regras na borda são executadas mais rapidamente e reduzem a carga da origem.

Um dos casos de uso mais comuns do mecanismo de regras é exigir HTTPS. Quando um cliente solicita seu site por HTTP, uma regra de redirecionamento na borda do Front Door retorna imediatamente uma resposta 301 Moved Permanently (ou 302 Found) apontando para a URL HTTPS — sem que a solicitação chegue à origem. Isso é mais rápido do que redirecionamentos no lado da origem e garante que todo o tráfego seja criptografado durante o trânsito. Configure essa ação de redirecionamento para solicitações cuja condição RequestScheme seja igual a HTTP.

Os navegadores modernos são compatíveis com cabeçalhos de segurança HTTP que impedem ataques comuns. É possível adicionar esses cabeçalhos a todas as respostas usando ações Append response header do mecanismo de regras, sem modificar o servidor de origem. Os principais cabeçalhos incluem: Strict-Transport-Security (força o uso de HTTPS por um período), X-Content-Type-Options: nosniff (impede a detecção automática de MIME), X-Frame-Options: DENY (impede o clickjacking) e Content-Security-Policy (restringe as fontes de conteúdo). Adicioná-los na borda garante uma aplicação consistente em todas as origens.

O mecanismo de regras permite substituir o TTL padrão do cache para padrões de URL específicos. Por exemplo, pode ser desejável armazenar /static/images/* em cache por 30 dias, mas armazenar as respostas de /api/* em cache por apenas 60 segundos. Use uma condição de correspondência em RequestUri e uma ação de substituição da configuração de Route que defina uma duração personalizada do cache. Isso permite um controle detalhado do comportamento do cache sem criar várias rotas separadas para cada tipo de conteúdo.

As ações de reescrita de URL modificam a URL da solicitação antes que ela seja encaminhada para a origem, sem alterar a URL exibida ao cliente. Isso é útil para enviar solicitações de uma estrutura de URL para um caminho diferente no back-end. Por exemplo, reescreva /products/item/{id} como /catalog/v2/products/{id} para acomodar uma alteração na API de back-end sem atualizar os links dos clientes. A reescrita de URL é uma ação do mecanismo de regras que modifica o caminho da URL usando substituição de cadeias ou grupos de captura.

A filtragem geográfica no nível do mecanismo de regras permite redirecionar ou bloquear usuários de países específicos com base na localização geográfica derivada do IP do cliente. Ao contrário da filtragem geográfica da CDN (que retorna 403), a filtragem geográfica do mecanismo de regras oferece mais flexibilidade — é possível redirecionar países bloqueados para uma página de destino que explique a disponibilidade regional ou encaminhar determinados países para grupos de origens específicos da região (por exemplo, usuários da EU para origens da EU, em conformidade com o GDPR). A correspondência geográfica de RemoteAddress usa o banco de dados de IP para país da MaxMind.

O mecanismo de regras pode adicionar, substituir ou excluir cabeçalhos de solicitação antes de encaminhá-la para a origem. Um uso comum é adicionar um X-Forwarded-For ou um cabeçalho personalizado como X-Front-Door-Id, para que a origem saiba que as solicitações passaram pelo Front Door e possa validá-las. Também é possível excluir o cabeçalho Host original e substituí-lo pelo nome do host da origem — algo importante quando a origem valida o cabeçalho Host. Isso oferece controle total sobre o que o servidor de origem vê.

As condições do mecanismo de regras podem fazer correspondência com valores de cabeçalhos de solicitação, permitindo uma lógica de roteamento sofisticada. Por exemplo, encaminhe solicitações que contenham o cabeçalho X-API-Version: 2 para um grupo de origens diferente que execute a API v2, enquanto as solicitações sem esse cabeçalho vão para a origem v1. Isso permite o versionamento blue-green de APIs na borda sem exigir nomes de host separados para cada versão da API. O roteamento baseado em cabeçalhos também é usado em testes A/B, roteando com base em um cookie personalizado de segmento de usuário.

A compactação de respostas no Front Door compacta respostas baseadas em texto (HTML, CSS, JavaScript, JSON) usando gzip ou Brotli antes de servi-las pelos PoPs. A compactação é mais eficaz para grandes pacotes de JS, reduzindo o tamanho da transferência em até 70%. Ative a compactação nas configurações da rota e especifique os tipos MIME a serem compactados. O conteúdo compactado é armazenado em cache no PoP em formato compactado — portanto, somente a primeira solicitação de cada recurso aciona a compactação; as solicitações seguintes fornecem instantaneamente o arquivo compactado armazenado em cache.

O Origin Shield é uma camada adicional opcional de cache que o Front Door posiciona entre os nós de borda do PoP e a origem. Quando ativada, em vez de cada um dos mais de 100 PoPs de borda solicitar conteúdo não armazenado em cache de forma independente à origem, todos encaminham as perdas de cache para um único PoP regional do Origin Shield — que então encaminha as solicitações para a origem. Isso reduz significativamente o número de solicitações que chegam à origem (chamado de taxa de descarregamento da origem), mantendo o fornecimento global de conteúdo pelos PoPs de borda.

Antes de implantar alterações do mecanismo de regras em produção, valide-as usando as ferramentas de diagnóstico e teste do portal. A lâmina Diagnostic settings, com os registros do WAF no modo de detecção, mostra quais regras coincidem. Para o mecanismo de regras, também é possível inspecionar os cabeçalhos reais de solicitação e resposta nas ferramentas de desenvolvedor do navegador depois de implantar em um ambiente de preparação, ou usar curl -v para enviar solicitações específicas e verificar se os cabeçalhos de resposta e o comportamento do redirecionamento estão conforme o esperado antes de mudar para produção.

Test sua compreensão dos conceitos do Microsoft Azure Fundamentos (AZ-900) apresentados nesta lição.

Nesta lição, você aprendeu que o mecanismo de regras do Front Door trata redirecionamentos de HTTP para HTTPS, cabeçalhos de resposta de segurança e substituições de TTL do cache na borda, sem alterações na origem; a reescrita de URL modifica silenciosamente os caminhos das solicitações encaminhadas para a origem, enquanto o redirecionamento de URL altera a URL exibida ao cliente; e o Origin Shield reduz a carga da origem consolidando as solicitações resultantes de perdas de cache por meio de um nó de proteção regional. A seguir, exploraremos os Azure AI Services para adicionar inteligência às suas aplicações.