Squid keširanje vanjskog ACL-a: zašto se pomoćnik ne poziva svaki put
Dizajnirajte Squid pomoćnike vanjskog ACL-a oko trajnih procesa, ključeva keša odluka i izričitog zahtjeva za svježinom autorizacije.
Pomoćnik koji zabilježi jedan zahtjev i zatim ušuti može biti normalan. Squid može ocijeniti pravilo koristeći keširani rezultat vanjskog ACL-a, a da pomoćniku ne pošalje novi upit.
Prvo definirajte odluku koja se može ponovno koristiti. „Smije li ovaj račun koristiti proxy?“ zahtijeva drugačije ulaze od „Smije li ovaj račun dosegnuti ovo odredište?“ Prošireni format vanjskog ACL-a tvori ključ keša. Ako pomoćnik odlučuje po korisničkom imenu i odredištu, ali ključ sadrži samo korisničko ime, keširano odobrenje može se primijeniti šire od predviđenog. Uključite svaki ulaz koji mijenja odgovor i izbjegavajte detalje koji samo usitnjavaju ekvivalentne odluke.
Zatim odaberite svježinu. Pozitivni ttl i negative_ttl upravljaju podudarnim i nepodudarnim rezultatima; grace može pokrenuti osvježavanje prije isteka unosa. Odredite koliko dugo keširano odobrenje opozvanog računa smije utjecati na kasnije odluke. Nijedna od ovih postavki ne autorizira ponovno uspostavljeni CONNECT tunel za svaki bajt ili unutarnji HTTPS zahtjev. Ako pomoćnik provodi kvotu prometa, odobreni prijenosi mogu se nastaviti nakon promjene salda.
Pomoćnik je trajni sudionik protokola, a ne nužno novi skriptni proces za svaki zahtjev. Držite ga spremnim za uzastopne retke upita i odmah šaljite svaki odgovor. Dijagnostiku stavite na drugi kanal. Uz omogućenu paralelnost vratite odgovarajući dostavljeni identifikator kanala.
Naposljetku, definirajte ishode „sporo“, „nedostupno“ i „unutarnja pogreška“ i osigurajte da ih okolni redoslijed ACL-a proizvede. Dizajn je dovršen kada i specifičnost i dopuštena starost odgovora koji se može ponovno koristiti odgovaraju zahtjevu pristupa.