Cache de proxy

O cache de proxy funciona armazenando cópias de recursos web solicitados com frequência em um servidor proxy, permitindo que as solicitações seguintes do mesmo conteúdo sejam atendidas diretamente pelo cache, em vez de buscá-lo novamente no servidor de origem.

Visão geral do cache de proxy

Um servidor proxy atua como intermediário entre um cliente e um servidor de origem. Quando configurado para cache, ele intercepta as solicitações do cliente por conteúdo web (como páginas HTML, imagens, folhas de estilo ou scripts). Se o recurso solicitado for encontrado no armazenamento local do proxy e for considerado fresco, o proxy o entrega imediatamente. Caso contrário, o proxy encaminha a solicitação ao servidor de origem, obtém o recurso, entrega-o ao cliente e, ao mesmo tempo, armazena uma cópia em seu cache para uso futuro.

Benefícios do cache de proxy

Implementar o cache de proxy traz várias vantagens operacionais:

• Menor latência: Conteúdo entregue por um cache de proxy geograficamente mais próximo chega ao cliente mais rápido do que conteúdo buscado em um servidor de origem distante, melhorando o desempenho percebido da aplicação.
• Menor consumo de banda: Ao entregar conteúdo em cache, o proxy reduz a necessidade de baixar repetidamente os mesmos dados por links de rede externos, economizando banda, especialmente para recursos acessados com frequência.
• Menor carga nos servidores de origem: O cache retira uma parcela significativa das solicitações dos servidores de origem, permitindo que eles atendam mais solicitações únicas ou operem com menos esforço, o que pode evitar sobrecargas e melhorar sua capacidade de resposta.
• Melhor experiência do usuário: Tempos de carregamento menores e entrega de conteúdo mais consistente contribuem diretamente para uma experiência melhor para o usuário final.

Como funciona o cache de proxy: o fluxo da solicitação

O processo de cache envolve uma série de etapas:

1. Solicitação do cliente: Um cliente (por exemplo, um navegador) envia uma solicitação HTTP de um recurso ao servidor proxy.
2. Consulta ao cache: O servidor proxy recebe a solicitação e verifica em seu cache local se há uma cópia armazenada do recurso solicitado. A chave de cache normalmente deriva da URL e, possivelmente, de outros cabeçalhos da solicitação.
3. Cache hit (fresco): Se uma cópia válida e fresca do recurso for encontrada no cache, o proxy entrega imediatamente essa cópia ao cliente. Esse é o caminho mais rápido.
4. Cache hit (obsoleto/exige validação): Se uma cópia for encontrada, mas for considerada obsoleta (seu tempo de frescor expirou), o proxy inicia uma solicitação condicional ao servidor de origem. Essa solicitação inclui cabeçalhos de validação como If-Modified-Since ou If-None-Match.
   • Se o servidor de origem responder com 304 Not Modified, a cópia em cache ainda é válida, e o proxy a entrega ao cliente, atualizando suas informações de frescor.
   • Se o servidor de origem responder com uma nova versão do recurso (200 OK), o proxy atualiza seu cache com o novo conteúdo, entrega-o ao cliente e atualiza as informações de frescor.
5. Cache miss: Se nenhuma cópia do recurso for encontrada no cache, ou se o servidor de origem indicar que a cópia em cache não é mais válida e enviar conteúdo novo, o proxy encaminha a solicitação original do cliente ao servidor de origem.
6. Resposta do servidor de origem: O servidor de origem processa a solicitação e envia o recurso de volta ao proxy.
7. Cache e entrega: O proxy recebe o recurso do servidor de origem, armazena uma cópia em seu cache (se for elegível para cache) e então encaminha o recurso ao cliente.

Invalidação de cache e frescor

Manter o frescor do cache é essencial para garantir que os clientes recebam conteúdo atualizado. Os mecanismos de cache do HTTP dependem principalmente dos cabeçalhos de resposta fornecidos pelo servidor de origem.

Cabeçalhos HTTP de cache

Os servidores de origem usam cabeçalhos de resposta HTTP específicos para instruir proxies (e navegadores clientes) sobre como armazenar o conteúdo em cache:

• Cache-Control: O principal e mais poderoso cabeçalho de diretivas de cache.

  • max-age=<seconds>: Especifica o tempo máximo durante o qual um recurso é considerado fresco.
  • no-cache: Obriga o proxy a revalidar a cópia em cache com o servidor de origem antes de usá-la, mesmo que a entrada de cache não esteja obsoleta. Não significa "não armazenar em cache".
  • no-store: Impede que o proxy armazene qualquer parte da solicitação ou da resposta em qualquer cache.
  • public: Indica que o recurso pode ser armazenado por qualquer cache, incluindo caches de proxy compartilhados.
  • private: Indica que o recurso é destinado a um único usuário e só pode ser armazenado no cache privado do navegador, não em caches de proxy compartilhados.
  • must-revalidate: Obriga a revalidação com o servidor de origem quando a entrada de cache fica obsoleta.
  • proxy-revalidate: Semelhante a must-revalidate, mas se aplica apenas a caches de proxy compartilhados.

  http Cache-Control: public, max-age=3600 Cache-Control: no-cache Cache-Control: no-store

• Expires: Um cabeçalho mais antigo, do HTTP/1.0, que especifica a data/hora após a qual a resposta é considerada obsoleta. Cache-Control: max-age tem precedência se ambos estiverem presentes.

  http Expires: Thu, 01 Dec 1994 16:00:00 GMT

• ETag (Entity Tag): Um identificador opaco atribuído pelo servidor de origem a uma versão específica de um recurso. Se o recurso mudar, um novo ETag é gerado. Os proxies usam o ETag em solicitações condicionais.

  http ETag: "67ab3246a-543-12345678"

• Last-Modified: Um carimbo de data/hora indicando quando o recurso foi modificado pela última vez no servidor de origem. Os proxies usam isso em solicitações condicionais.

  http Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

Solicitações condicionais

Quando o tempo de frescor de um recurso em cache expira, o proxy envia uma solicitação condicional ao servidor de origem para verificar se o recurso mudou.

• If-None-Match: Enviado com o ETag da resposta em cache. Se o ETag no servidor de origem corresponder, o servidor responde com 304 Not Modified.

  http GET /images/logo.png HTTP/1.1 Host: example.com If-None-Match: "67ab3246a-543-12345678"

• If-Modified-Since: Enviado com a data Last-Modified da resposta em cache. Se o recurso não tiver sido modificado desde essa data, o servidor responde com 304 Not Modified.

  http GET /styles/main.css HTTP/1.1 Host: example.com If-Modified-Since: Tue, 15 Nov 1994 12:45:26 GMT

Desafios de coerência de cache

Manter uma coerência de cache perfeita (garantir que todos os clientes sempre recebam a versão absolutamente mais recente de um recurso) pode ser complexo. As estratégias incluem:
* TTLs curtos: Sacrificar parte da eficiência do cache em troca de mais frescor.
* APIs de invalidação de cache: O servidor de origem notifica explicitamente os proxies para expurgar itens específicos do cache.
* Cache busting: Acrescentar parâmetros de consulta únicos (por exemplo, ?v=123) às URLs de recursos que mudam com frequência, forçando os proxies a buscar novas versões.

Tipos de cache de proxy

Os caches de proxy podem ser classificados conforme sua implantação e finalidade:

Cache de proxy direto (forward)

Um cache de proxy direto fica entre os clientes e a internet. Os clientes são explicitamente configurados para usar o proxy. Esse tipo de cache é comum em redes corporativas para reduzir a banda de saída e melhorar a velocidade de acesso dos usuários internos. Ele atua em nome de um grupo de clientes.

Cache de proxy reverso

Um cache de proxy reverso fica na frente de um ou mais servidores de origem. Os clientes se conectam ao proxy reverso, que então encaminha as solicitações ao servidor de origem apropriado. O proxy reverso pode armazenar em cache as respostas dos servidores de origem, aliviando-os e melhorando o desempenho para clientes externos. Isso costuma ser usado para balanceamento de carga, terminação SSL e entrega de conteúdo.

Cache de proxy transparente

Um proxy transparente intercepta as solicitações do cliente sem qualquer configuração no lado do cliente. O roteamento da rede é configurado para redirecionar o tráfego pelo proxy. Os clientes não sabem que estão usando um proxy. Isso costuma ser usado por ISPs ou administradores de rede para melhorar o desempenho geral da rede para os usuários sem exigir configuração em cada dispositivo.

Geração da chave de cache

Para armazenar e recuperar recursos de forma eficiente, o proxy precisa gerar uma "chave de cache" única para cada recurso. Essa chave determina se uma solicitação seguinte corresponde a uma entrada em cache. Os principais componentes de uma chave de cache normalmente incluem:

• URL: O esquema, host, porta, caminho e parâmetros de consulta geralmente formam o núcleo da chave de cache.
• Método HTTP: Em geral, apenas solicitações GET e HEAD são armazenadas em cache.
• Cabeçalho Vary: Se um servidor de origem responder com um cabeçalho Vary (por exemplo, Vary: Accept-Encoding, User-Agent), o proxy deve incluir os valores dos cabeçalhos de solicitação indicados em sua chave de cache. Isso garante que representações diferentes de um recurso (por exemplo, com gzip vs. sem compressão, mobile vs. desktop) sejam armazenadas separadamente.

Mecanismos de armazenamento e políticas de remoção

Os caches de proxy utilizam diversos mecanismos e políticas de armazenamento:

• Armazenamento:

  • RAM (memória): Acesso mais rápido, usado para conteúdo muito quente ou metadados. Capacidade limitada.
  • Disco (SSD/HDD): Mais lento que a RAM, mas oferece capacidade muito maior. É o mais comum para grandes volumes de conteúdo.
  • Híbrido: Combina RAM para metadados e objetos pequenos acessados com frequência, e disco para conteúdo maior ou menos acessado.

• Políticas de remoção (eviction): Quando o limite de armazenamento do cache é atingido, o proxy precisa decidir quais itens remover para abrir espaço para novos. As políticas comuns incluem:

  • LRU (Least Recently Used): Remove o item que não é acessado há mais tempo.
  • LFU (Least Frequently Used): Remove o item que foi acessado menos vezes.
  • FIFO (First-In, First-Out): Remove o item mais antigo do cache.

Considerações de configuração

Um cache de proxy eficaz exige configuração cuidadosa:

• Tamanho do cache: Equilibrar o armazenamento disponível com o volume de conteúdo a ser armazenado. Pequeno demais, e a taxa de acerto cai; grande demais, e o I/O de disco pode virar gargalo.
• Padrões de Time-to-Live (TTL): Definir durações de frescor padrão para recursos que não trazem cabeçalhos de cache explícitos. É um recurso de contingência e pode afetar o frescor.
• Regras de bypass: Definir regras que impeçam o cache de URLs específicas, conteúdo sensível ou recursos dinâmicos que nunca devem ser armazenados (por exemplo, endpoints de API com dados personalizados, sessões autenticadas).
• Cache de HTTPS: Armazenar tráfego HTTPS em cache é mais complexo por causa da criptografia. O proxy muitas vezes precisa descriptografar o tráfego (exigindo seu próprio certificado e chave SSL) para inspecionar cabeçalhos e armazenar conteúdo, e depois recriptografá-lo. Isso normalmente é feito com proxies reversos ou proxies diretos explícitos, nos quais os clientes confiam no certificado do proxy. O cache HTTPS transparente sem descriptografia se limita a armazenar apenas respostas CONNECT, não o conteúdo subjacente.
• Logs e monitoramento: Essenciais para observar taxas de acerto do cache, identificar ineficiências e resolver problemas.

Softwares comuns de cache de proxy

Há várias soluções robustas para implementar cache de proxy:

• Squid: Um proxy direto e reverso de código aberto amplamente usado, com amplos recursos de cache.
• Varnish Cache: Um acelerador HTTP de alto desempenho (proxy reverso) projetado especificamente para armazenar conteúdo web em cache. Conhecido pela VCL (Varnish Configuration Language), que permite políticas de cache muito flexíveis.
• Nginx: Principalmente um servidor web e proxy reverso, o Nginx oferece recursos robustos de cache, especialmente quando configurado como proxy reverso.
• Apache HTTP Server: Pode ser configurado com módulos como mod_cache e mod_disk_cache para atuar como proxy de cache.