Kešovanie externých ACL v Squide: prečo sa pomocník nevolá zakaždým
Navrhnite externých ACL pomocníkov Squidu okolo trvalých procesov, kľúčov keše rozhodnutí a výslovnej požiadavky na čerstvosť autorizácie.
Pomocník, ktorý zaloguje jednu požiadavku a potom stíchne, môže byť normálny. Squid môže vyhodnotiť pravidlo pomocou kešovaného výsledku externej ACL bez odoslania ďalšej požiadavky pomocníkovi.
Najprv definujte opakovane použiteľné rozhodnutie. „Smie tento účet používať proxy?“ vyžaduje iné vstupy ako „Smie tento účet dosiahnuť tento cieľ?“ Rozšírený formát externej ACL tvorí kľúč keše. Ak pomocník rozhoduje podľa používateľského mena a cieľa, ale kľúč obsahuje len používateľské meno, kešované schválenie sa môže uplatniť širšie, než bolo zamýšľané. Zahrňte každý vstup, ktorý mení odpoveď, a vyhnite sa detailom, ktoré len drobia ekvivalentné rozhodnutia.
Potom zvoľte čerstvosť. Kladné ttl a negative_ttl riadia zhodné a nezhodné výsledky; grace môže spustiť obnovu pred vypršaním záznamu. Rozhodnite, ako dlho smie kešované schválenie odvolaného účtu ovplyvňovať neskoršie rozhodnutia. Žiadne z týchto nastavení znova neautorizuje zavedený tunel CONNECT pre každý bajt alebo vnútornú HTTPS požiadavku. Ak pomocník presadzuje kvótu prevádzky, povolené prenosy môžu pokračovať po zmene zostatku.
Pomocník je trvalý účastník protokolu, nie nevyhnutne nový skriptový proces pre každú požiadavku. Udržujte ho pripravený na ďalšie riadky dopytov a každú odpoveď odosielajte okamžite. Diagnostiku umiestnite na iný kanál. Pri zapnutej súbežnosti vráťte zodpovedajúci dodaný identifikátor kanála.
Napokon definujte výsledky pomalý, nedostupný a vnútorná chyba a zabezpečte, aby ich okolité poradie ACL vytváralo. Návrh je hotový, keď špecifickosť aj povolený vek opakovane použiteľnej odpovede zodpovedajú požiadavke na prístup.