Кэширование внешних ACL в Squid: почему помощник вызывается не каждый раз

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

Сначала определите повторно используемое решение. «Может ли эта учётная запись пользоваться прокси?» требует иных входных данных, чем «Может ли эта учётная запись достичь этого назначения?» Расширенный формат внешнего ACL образует ключ кэша. Если помощник решает по имени пользователя и назначению, а ключ содержит только имя пользователя, кэшированное разрешение может применяться шире задуманного. Включайте каждый вход, меняющий ответ, и избегайте деталей, которые лишь дробят эквивалентные решения.

Затем выберите свежесть. Положительные ttl и negative_ttl управляют совпадающими и несовпадающими результатами; grace может запустить обновление до истечения записи. Решите, сколько времени кэшированное разрешение отозванной учётной записи может влиять на последующие решения. Ни одна из этих настроек не авторизует заново установленный туннель CONNECT для каждого байта или внутреннего HTTPS-запроса. Если помощник применяет квоту трафика, разрешённые передачи могут продолжаться после изменения баланса.

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

Наконец, определите исходы «медленно», «недоступно» и «внутренняя ошибка» и добейтесь, чтобы окружающий порядок ACL их создавал. Проект завершён, когда и специфичность, и допустимый возраст многоразового ответа соответствуют требованиям доступа.