Cache-ul ACL externe în Squid: de ce helperul nu este apelat de fiecare dată
Proiectați helperi ACL externi Squid în jurul proceselor persistente, al cheilor de cache pentru decizii și al unei cerințe explicite de prospețime a autorizării.
Un helper care înregistrează o singură cerere și apoi tace poate fi normal. Squid poate evalua o regulă folosind un rezultat ACL extern din cache fără a trimite helperului o altă interogare.
Definiți mai întâi decizia reutilizabilă. „Poate acest cont să folosească proxy-ul?” necesită intrări diferite de „Poate acest cont să atingă această destinație?” Formatul extins ACL extern formează cheia de cache. Dacă helperul decide după numele de utilizator și destinație, dar cheia conține doar numele de utilizator, o aprobare din cache se poate aplica mai larg decât s-a intenționat. Includeți fiecare intrare care schimbă răspunsul și evitați detaliile care doar fragmentează decizii echivalente.
Apoi alegeți prospețimea. ttl și negative_ttl pozitive guvernează rezultatele potrivite și nepotrivite; grace poate iniția o reîmprospătare înainte ca o intrare să expire. Decideți cât timp aprobarea din cache a unui cont revocat poate afecta deciziile ulterioare. Niciuna dintre aceste setări nu reautorizează un tunel CONNECT stabilit pentru fiecare octet sau cerere HTTPS internă. Dacă helperul aplică o cotă de trafic, transferurile admise pot continua după ce soldul se schimbă.
Helperul este un participant persistent la protocol, nu neapărat un proces de script nou pentru fiecare cerere. Țineți-l pregătit pentru linii de interogare succesive și trimiteți fiecare răspuns imediat. Puneți diagnosticele pe alt canal. Cu concurența activată, returnați identificatorul de canal furnizat corespunzător.
În final, definiți rezultatele lent, indisponibil și eroare internă și faceți ca ordinea ACL din jur să le producă. Designul este complet atunci când atât specificitatea, cât și vechimea permisă a unui răspuns reutilizabil corespund cerinței de acces.