Cache ACL externe de Squid : pourquoi le helper n'est pas appelé à chaque fois

Un helper qui journalise une requête puis se tait peut être normal. Squid peut évaluer une règle à l'aide d'un résultat ACL externe mis en cache sans envoyer une autre requête au helper.

Définissez d'abord la décision réutilisable. « Ce compte peut-il utiliser le proxy ? » exige des entrées différentes de « Ce compte peut-il atteindre cette destination ? » Le format ACL externe étendu forme la clé de cache. Si le helper décide par nom d'utilisateur et destination mais que la clé ne contient que le nom d'utilisateur, une approbation mise en cache peut s'appliquer plus largement que prévu. Incluez chaque entrée qui change la réponse et évitez les détails qui ne font que fragmenter des décisions équivalentes.

Choisissez ensuite la fraîcheur. Les ttl et negative_ttl positifs régissent les résultats concordants et non concordants ; grace peut lancer un rafraîchissement avant l'expiration d'une entrée. Décidez combien de temps l'approbation mise en cache d'un compte révoqué peut influencer les décisions ultérieures. Aucun de ces réglages ne réautorise un tunnel CONNECT établi pour chaque octet ou requête HTTPS interne. Si le helper applique un quota de trafic, les transferts admis peuvent continuer après le changement du solde.

Le helper est un participant persistant au protocole, pas nécessairement un nouveau processus de script pour chaque requête. Gardez-le prêt pour des lignes de requête successives et envoyez chaque réponse sans délai. Placez les diagnostics sur un autre canal. Avec la concurrence activée, renvoyez l'identifiant de canal fourni correspondant.

Enfin, définissez les issues lente, indisponible et erreur interne, et faites en sorte que l'ordre ACL environnant les produise. La conception est complète lorsque la spécificité et l'âge autorisé d'une réponse réutilisable correspondent à l'exigence d'accès.