Caching delle ACL esterne di Squid: perché l'helper non viene chiamato ogni volta

Un helper che registra una richiesta e poi tace può essere normale. Squid può valutare una regola usando un risultato ACL esterno in cache senza inviare un'altra query all'helper.

Definite prima la decisione riutilizzabile. «Questo account può usare il proxy?» richiede input diversi da «Questo account può raggiungere questa destinazione?» Il formato ACL esterno esteso forma la chiave di cache. Se l'helper decide per nome utente e destinazione ma la chiave contiene solo il nome utente, un'approvazione in cache può applicarsi più ampiamente del previsto. Includete ogni input che cambia la risposta ed evitate dettagli che frammentano solo decisioni equivalenti.

Poi scegliete la freschezza. I ttl e negative_ttl positivi governano i risultati corrispondenti e non corrispondenti; grace può avviare un aggiornamento prima che una voce scada. Decidete per quanto tempo l'approvazione in cache di un account revocato può influire sulle decisioni successive. Nessuna di queste impostazioni riautorizza un tunnel CONNECT stabilito per ogni byte o richiesta HTTPS interna. Se l'helper applica una quota di traffico, i trasferimenti ammessi possono continuare dopo il cambio del saldo.

L'helper è un partecipante persistente del protocollo, non necessariamente un nuovo processo di script per ogni richiesta. Tenetelo pronto per righe di query successive e inviate ogni risposta subito. Mettete la diagnostica su un altro canale. Con la concorrenza attiva, restituite l'identificatore di canale fornito corrispondente.

Infine, definite gli esiti lento, non disponibile ed errore interno, e fate sì che l'ordine ACL circostante li produca. Il progetto è completo quando sia la specificità sia l'età consentita di una risposta riutilizzabile corrispondono al requisito di accesso.