Кеширане на външни ACL в Squid: защо помощникът не се извиква всеки път

Помощник, който логва една заявка и след това млъква, може да е нормално. Squid може да оцени правило, използвайки кеширан резултат от външен ACL, без да изпраща нова заявка до помощника.

Първо дефинирайте многократно използваемото решение. „Може ли този акаунт да използва проксито?“ изисква различни входни данни от „Може ли този акаунт да достигне тази дестинация?“ Разширеният формат на външния ACL образува ключа на кеша. Ако помощникът решава по потребителско име и дестинация, но ключът съдържа само потребителско име, кеширано разрешение може да се приложи по-широко от предвиденото. Включете всяко входно условие, което променя отговора, и избягвайте детайли, които само раздробяват еквивалентни решения.

След това изберете актуалност. Положителните ttl и negative_ttl управляват съвпадащи и несъвпадащи резултати; grace може да започне обновяване преди изтичане на запис. Решете колко дълго кешираното разрешение на отнет акаунт може да влияе на по-късни решения. Никоя от тези настройки не разрешава наново установен CONNECT тунел за всеки байт или вътрешна HTTPS заявка. Ако помощникът налага квота за трафик, допуснатите трансфери може да продължат след промяна на баланса.

Помощникът е постоянен участник в протокола, не непременно нов скриптов процес за всяка заявка. Дръжте го готов за последователни редове със заявки и изпращайте всеки отговор незабавно. Извеждайте диагностиката на друг канал. При включена паралелност връщайте съответния предоставен идентификатор на канал.

Накрая дефинирайте изходите „бавно“, „недостъпно“ и „вътрешна грешка“ и накарайте околния ред на ACL да ги произведе. Дизайнът е завършен, когато както специфичността, така и допустимата възраст на многократно използвания отговор съответстват на изискването за достъп.