CDN e cache: velocidade sem conteúdo desatualizado

Cache rápido é aquele que reutiliza somente a resposta certa. Antes de aumentar o TTL, é preciso classificar conteúdo, usuários e formas de invalidação.

Incidente hipotético: uma pessoa viu o nome de outra Uma aplicação possui uma página: Para melhorar a performance, uma regra da CDN foi criada: A primeira pessoa autenticada acessou a página. A CDN armazenou o HTML. A segunda pessoa recebeu a mesma resposta. A aplicação, o banco e a autenticação funcionaram como programados. O erro estava na camada intermediária, que reutilizou uma resposta personalizada como se fosse pública. Cache não é apenas uma otimização. É uma decisão sobre quando duas requisições podem receber a mesma resposta. A investigação começa pelos headers Resposta hipotética: O problema está explícito: autoriza armazenamento em cache compartilhado dentro das condições da política. A presença de Set Cookie não deve ser tratada como proteção universal. Provedores podem possuir regras próprias, e configurações de “cache everything” podem substituir comportamentos esperados. Respostas privadas precisam de política explícita e teste. As camadas de cache Uma mesma página pode atravessar: Cada camada possui: chave; tempo de retenção; forma de validação; regra de exclusão; mecanismo de invalidação. Apagar o cache do navegador não remove uma resposta armazenada na CDN. Executar purge na CDN não limpa um service worker. Cache privado e compartilhado A RFC 9111 distingue: Cache privado Dedicado a uma pessoa ou agente, como o cache do navegador. Cache compartilhado Reutiliza respostas entre vários usuários, como CDN e proxy. Essa diferença determina o risco. Uma página personalizada pode ser adequada para armazenamento no navegador e inadequada para CDN. A classificação vem antes do TTL Crie classes de conteúdo. Classe A — arquivos versionados e públicos Exemplos: A URL muda quando o conteúdo muda. Política: Como o nome inclui hash, uma nova versão gera nova URL. Essa é a situação mais segura para retenção longa. Classe B — HTML público que muda Exemplos: Política possível: Interpretação: navegador precisa validar; cache compartilhado pode manter por cinco minutos; uma resposta antiga pode ser servida por curto período durante revalidação, quando suportado. O valor precisa refletir a tolerância do conteúdo. Classe C — API pública Exemplo: Política possível: A API precisa produzir a mesma resposta para requisições equivalentes ou incluir as variações na chave. Classe D — conteúdo autenticado Exemplos: Base conservadora: Isso impede armazenamento intencional da resposta. Algumas aplicações podem permitir cache privado com revalidação, mas a decisão exige análise de dados, logout, dispositivo compartilhado e requisitos de privacidade. Classe E — respostas sensíveis Exemplos: recuperação de senha; token; documento pessoal; pagamento; autenticação; segredo. Use: Não dependa apenas da ausência de um header. O que as diretivas significam max age Tempo em segundos durante o qual a resposta pode ser considerada fresca. s maxage Tempo específico para caches compartilhados. O navegador recebe max age=0 ; a CDN pode usar cinco minutos. public Indica que a resposta pode ser armazenada por cache compartilhado, mesmo em situações que normalmente restringiriam o armazenamento conforme a semântica HTTP. Use somente quando a resposta for realmente compartilhável. private Restringe a resposta a cache privado. Não significa criptografia. no store Instrui caches a não armazenar a resposta. no cache O nome é enganoso. Permite armazenamento, mas exige validação antes da reutilização. must revalidate Depois que a resposta fica obsoleta, o cache precisa validá la antes de reutilizar, salvo regras específicas da especificação. immutable Sinaliza que a representação não mudará enquanto a URL permanecer igual. É apropriado para assets versionados, não para: se esse caminho recebe conteúdo diferente a cada deploy. Freshness e validação não são a mesma coisa Uma resposta fresca pode ser reutilizada sem consultar a origem. Uma resposta obsoleta pode ser validada. Fluxo com ETag: Exemplo: Resposta: O corpo não precisa ser transferido novamente. A MDN também documenta validação por Last Modified e If Modified Since . ETag tende a permitir identificação mais específica da representação. A chave define quem compartilha a resposta A RFC 9111 estabelece que a chave utiliza, no mínimo, método e URI, podendo considerar campos indicados por Vary . Exemplo: O cache separa versões comprimidas de acordo com o cabeçalho correspondente. Outro exemplo: Pode separar idiomas. O problema da chave incompleta A página muda conforme: Se a CDN usa somente a URL: duas organizações podem compartilhar uma entrada. Alternativas: não armazenar em cache compartilhado; incluir a dimensão autorizada na chave; usar URLs separadas; produzir conteúdo comum e buscar dados privadamente. Adicionar todo cookie à chave costuma destruir a eficiência e criar cardinalidade elevada. Para páginas autenticadas, bypass é geralmente mais seguro. Query strings precisam de política Estas URLs podem representar conteúdos diferentes: Uma CDN que ignora query strings pode misturá los. Outras queries apenas rastreiam campanha: Incluí las na chave pode criar milhares de cópias idênticas. Defina: parâmetros que alteram conteúdo; parâmetros ignorados; ordenação; normalização; limites. Não permita que qualquer parâmetro não validado fragmente indefinidamente o cache. Regras da CDN podem substituir a origem A documentação de Origin Cache Control da Cloudflare e de expiração do CloudFront mostra que o comportamento final depende de: headers da origem; política configurada na CDN; TTL mínimo; TTL máximo; modo de cache; status; cookies; autenticação; regras específicas. Não assuma que o provedor sempre obedecerá exatamente ao header se uma regra administrativa o substituir. Registre a fonte de verdade: Evite políticas conflitantes espalhadas em múltiplos painéis. Invalidação por versão é melhor que purge frequente Para assets: pode permanecer antigo depois do deploy. Com versionamento: O HTML novo referencia o arquivo novo. Vantagens: não depende de purge global; permite retenção longa; versões podem coexistir; rollback mantém assets anteriores; reduz corrida entre HTML e arquivos. Não remova imediatamente assets antigos. Navegadores podem possuir HTML anterior que ainda os referencia. Purge é ferramenta operacional, não estratégia principal Tipos: URL específica; prefixo; tag; host; cache completo. Purge total pode causar: pico na origem; latência; aumento de custo; sobrecarga; nova falha. Prefira invalidação seletiva. Antes: Conteúdo obsoleto pode ser útil durante falha Diretivas de extensão como: podem permitir uso temporário de conteúdo antigo. Isso é apropriado para: notícia pública; catálogo; documentação; página institucional. Pode ser inadequado para: saldo; estoque crítico; preço contratual; permissão; conta; estado de pagamento. “Servir algo antigo” precisa ser decisão do produto, não padrão global. Cache de erro também existe Respostas como 404 podem ser armazenadas em determinadas políticas. Cenário: 1. página ainda não existe; 2. CDN armazena 404 ; 3. página é publicada; 4. CDN continua entregando 404 . Defina TTL de respostas negativas e invalide quando o recurso for criado. Não aplique um ano de cache a todos os status. O risco de cache poisoning Um atacante tenta fazer o cache armazenar uma resposta manipulada que será entregue a outras pessoas. Vetores podem envolver: headers não incluídos na chave; host incorreto; parâmetros; normalização; redirects; resposta refletida; origem exposta. Controles: validar Host ; restringir headers aceitos; normalizar URLs; definir chave explicitamente; não refletir entrada em resposta cacheável sem análise; proteger a origem; testar variantes; acompanhar anomalias. A RFC 9111 inclui considerações específicas sobre cache poisoning e armazenamento de informação sensível. A origem não deveria estar pública sem necessidade Quando toda entrada passa pela CDN: Considere: firewall aceitando redes ou identidade da CDN; TLS entre borda e origem; autenticação de origem; rate limit; headers confiáveis; remoção de acesso direto; monitoramento. Não confie em um header que qualquer cliente possa enviar para provar que veio da CDN. O artigo sobre reverse proxy e HTTPS aprofunda essa fronteira. Como testar Primeira resposta Observe: Os nomes específicos variam por provedor. Segunda resposta Repita: O valor Age , quando presente, pode indicar tempo da entrada armazenada. Conteúdo privado Sem autenticação: Com sessão de teste controlada: Não coloque cookie real no histórico do shell. Verifique que a resposta privada: não possui public ; não é HIT compartilhado; não reutiliza corpo entre sessões; usa política coerente. Variações Teste: Confirme se conteúdo e Vary são coerentes. Matriz inicial de política Conteúdo Compartilhado Navegador Invalidação JS/CSS com hash 1 ano 1 ano nova URL Imagem versionada longo longo nova URL HTML público minutos revalidar purge seletivo Catálogo público curto curto tag ou URL Conta autenticada não não ou privado não aplicável Login e token não não não aplicável 404 curto curto purge ao publicar Os valores precisam ser ajustados ao produto. Observabilidade do cache Meça: hit ratio; miss ratio; bytes poupados; latência na borda; latência na origem; erros da origem; purges; objetos obsoletos; volume por status; variação por rota; bypasses. Hit ratio alto não é objetivo isolado. Uma resposta errada servida rapidamente continua errada. A melhoria deve aparecer em dados de performance web sem ampliar incidentes ou exposição. Runbook para conteúdo desatualizado 1. Identificar URL e usuário afetado. 2. Capturar headers. 3. Determinar a camada que respondeu. 4. Encontrar a chave. 5. Confirmar política da origem. 6. Confirmar regra da CDN. 7. Executar purge seletivo. 8. Corrigir a política. 9. Testar primeira e segunda requisição. 10. Observar capacidade da origem. 11. Registrar causa. 12. Criar teste de regressão. Não comece limpando todos os caches. Isso elimina parte da evidência. Runbook para possível vazamento privado 1. Tratar como incidente de segurança. 2. Desabilitar a regra de cache. 3. Purgar as respostas afetadas. 4. Preservar logs. 5. Identificar URLs, chaves e período. 6. Determinar usuários e dados envolvidos. 7. Corrigir headers e bypass. 8. Rotacionar sessões quando necessário. 9. Validar com contas de teste distintas. 10. Avaliar comunicação e obrigações aplicáveis. A segurança em camadas inclui detecção, resposta e recuperação, não apenas prevenção. Critério para aumentar o TTL Antes de ampliar a duração, confirme: URL é versionada ou conteúdo tolera atraso; resposta é pública; chave contém todas as variações; invalidação funciona; origem suporta cache miss; rollback preserva arquivos antigos; headers foram testados; dados sensíveis não aparecem; status de erro possui política; métricas estão disponíveis. Cache bem configurado reduz latência, banda e carga. Cache mal configurado preserva erros, mistura usuários e transforma uma correção de segundos em uma espera de horas. A pergunta correta não é: Por quanto tempo podemos guardar esta página? É: Quais requisições são realmente equivalentes, por quanto tempo a resposta continua correta e como removê la quando deixar de ser?