Cache de ACL externas do Squid: por que o helper não é chamado sempre

Um helper que registra uma requisição e depois silencia pode ser normal. O Squid pode avaliar uma regra usando um resultado de ACL externa em cache sem enviar outra consulta ao helper.

Primeiro defina a decisão reutilizável. «Esta conta pode usar o proxy?» exige entradas diferentes de «Esta conta pode alcançar este destino?» O formato estendido de ACL externa forma a chave de cache. Se o helper decide por nome de usuário e destino mas a chave contém apenas o nome de usuário, uma aprovação em cache pode aplicar-se de forma mais ampla que o pretendido. Inclua toda entrada que altere a resposta e evite detalhes que apenas fragmentem decisões equivalentes.

Depois escolha a atualidade. ttl e negative_ttl positivos regem resultados correspondentes e não correspondentes; grace pode iniciar uma atualização antes de uma entrada expirar. Decida por quanto tempo a aprovação em cache de uma conta revogada pode afetar decisões posteriores. Nenhuma dessas configurações reautoriza um túnel CONNECT estabelecido para cada byte ou requisição HTTPS interna. Se o helper impõe uma cota de tráfego, transferências admitidas podem continuar após a mudança do saldo.

O helper é um participante persistente do protocolo, não necessariamente um novo processo de script para cada requisição. Mantenha-o pronto para linhas de consulta sucessivas e envie cada resposta sem demora. Coloque o diagnóstico em outro canal. Com a concorrência ativada, retorne o identificador de canal fornecido correspondente.

Por fim, defina os resultados lento, indisponível e erro interno, e faça a ordem de ACL ao redor produzi-los. O design está completo quando tanto a especificidade quanto a idade permitida de uma resposta reutilizável correspondem ao requisito de acesso.