Como o Squid sabe se é cache é validado

Question

No modo de proxy reverso, o Squid pode armazenar em cache o conteúdo de sites acessados anteriormente por dispositivos dentro da rede.

O que acontece se o conteúdo do site remoto mudar de alguma forma, talvez por um push de código? Como o Squid sabe que precisa ir ao site original para obter uma nova versão do recurso, em vez de seu cache?

Isso é mais um problema agora com sites dinâmicos baseados em javascript (página única)?

Uma pergunta a parte: "proxy reverso" é essencialmente a mesma coisa que "modo acelerador" para o Squid?

    

Answer 1

Sim, o Squid armazenará em cache as respostas do (s) servidor (es) de backend usando o método convencional de interpretar os cabeçalhos que o servidor de backend envia com cada resposta.

Uma resposta típica para conteúdo dinâmico que não deve ser armazenado em cache é algo como:

Expires: Fri Jul 25 10:19:36 CEST 2014 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache

Tecnicamente, cada um desses cabeçalhos, por si só, já é suficiente para declarar o conteúdo da resposta dinâmica, mas a sabedoria convencional parece ainda usá-los todos. Programação de culto de carga ou compatibilidade com versões anteriores?

Cache-Control é o cabeçalho com o qual você deve se preocupar mais. Estas são as instruções de armazenamento em cache para o seu proxy reverso do Squid, bem como quaisquer servidores proxy de armazenamento em cache intermediários até e incluindo o navegador real. As opções são:

• private ou public ; uma resposta privada é específica para um usuário e não deve ser armazenada em cache, uma resposta pública pode ser armazenada em cache.
• no-cache faz basicamente o que parece e é uma instrução para revalidar o recurso para cada solicitação subsequente. Embora, após a validação, o recurso ainda seja válido, uma resposta armazenada em cache ainda pode ser atendida.
• no-store uma instrução clara de que a resposta deve ser tratada como confidencial e não armazenada, um pouco mais strong que a opção no-cache acima.
• max-age em segundos substitui o cabeçalho Expires e instrui quando um ativo está vencido e deve ser limpo do cache.
  • s-maxage em segundos é o mesmo que acima, mas para caches compartilhados como redes de entrega de conteúdo.

Expira é a maneira clássica de configurar a instrução de cache, com um registro de data e hora simples no máximo em 1 ano.

Pragma é um cabeçalho realmente antigo, configurá-lo como no-cache será interpretado por qualquer navegador recente como Cache-Control: no-cache e acho que não está mais presente no protocolo HTTP mais recente especificações embora ainda honrado para compatibilidade histórica de back-ward.

Os cabeçalhos definidos para mais conteúdo estático devem instruir o Squid (assim como os navegadores de seus visitantes) que essas respostas podem ser armazenadas em cache.

Cache-Control: no-transform,public,max-age=300,s-maxage=900
Content-Type: text/html; charset=UTF-8
Date: Fri Jul 25 10:19:36 CEST 2014 GMT
Expires: Sat Jul 26 10:19:36 CEST 2014 GMT

O problema é que, a menos que você libere manualmente o conteúdo do cache do Squid, os objetos serão armazenados pela duração de seus cabeçalhos de controle de cache. O Squid não tem provisões como você encontra no Varnish ou o uso do CDN do software para honrar as requisições PURGE para invalidar objetos específicos em cache.

A alternativa é fazer com que sua solução de gerenciamento de conteúdo garanta que as atualizações do conteúdo estático sejam fornecidas com novos nomes de arquivos, em vez de sobrescrever os arquivos existentes.

É claro que a sua configuração local pode substituir as instruções definidas em os cabeçalhos.

E, sim, no contexto do Squid, um proxy reverso e um acelerador da Web são a mesma coisa .