Kešování externích ACL v Squidu: proč se pomocník nevolá pokaždé
Navrhněte externí ACL pomocníky Squidu kolem trvalých procesů, klíčů keše rozhodnutí a výslovného požadavku na čerstvost autorizace.
Pomocník, který zaloguje jeden požadavek a pak ztichne, může být normální. Squid může vyhodnotit pravidlo pomocí kešovaného výsledku externí ACL, aniž by pomocníkovi poslal další dotaz.
Nejprve definujte opakovaně použitelné rozhodnutí. „Smí tento účet používat proxy?“ vyžaduje jiné vstupy než „Smí tento účet dosáhnout tohoto cíle?“ Rozšířený formát externí ACL tvoří klíč keše. Pokud pomocník rozhoduje podle uživatelského jména a cíle, ale klíč obsahuje jen uživatelské jméno, kešované schválení se může uplatnit šířeji, než bylo zamýšleno. Zahrňte každý vstup, který mění odpověď, a vyhněte se detailům, které jen drobí ekvivalentní rozhodnutí.
Dále zvolte čerstvost. Kladné ttl a negative_ttl řídí shodné a neshodné výsledky; grace může zahájit obnovu před vypršením záznamu. Rozhodněte, jak dlouho smí kešované schválení odvolaného účtu ovlivňovat pozdější rozhodnutí. Žádné z těchto nastavení znovu neautorizuje zavedený tunel CONNECT pro každý bajt nebo vnitřní požadavek HTTPS. Pokud pomocník vynucuje kvótu provozu, povolené přenosy mohou pokračovat po změně zůstatku.
Pomocník je trvalý účastník protokolu, ne nutně nový skriptový proces pro každý požadavek. Udržujte ho připravený na další řádky dotazů a každou odpověď odesílejte okamžitě. Diagnostiku umístěte na jiný kanál. Při zapnuté souběžnosti vracejte odpovídající dodaný identifikátor kanálu.
Nakonec definujte výsledky pomalý, nedostupný a vnitřní chyba a zajistěte, aby je okolní pořadí ACL vytvořilo. Návrh je hotový, když specificita i povolené stáří opakovaně použitelné odpovědi odpovídají požadavku na přístup.