Кешування зовнішніх ACL у Squid: чому помічник викликається не щоразу

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

Спершу визначте рішення, яке можна використовувати повторно. «Чи може цей обліковий запис користуватися проксі?» потребує інших вхідних даних, ніж «Чи може цей обліковий запис досягти цього призначення?» Розширений формат зовнішнього ACL утворює ключ кешу. Якщо помічник вирішує за іменем користувача та призначенням, але ключ містить лише ім'я користувача, кешований дозвіл може застосовуватися ширше, ніж задумано. Включайте кожен вхід, що змінює відповідь, і уникайте деталей, які лише дроблять еквівалентні рішення.

Далі виберіть свіжість. Позитивні ttl і negative_ttl керують збіжними та незбіжними результатами; grace може розпочати оновлення до завершення терміну запису. Вирішіть, скільки часу кешований дозвіл відкликаного облікового запису може впливати на пізніші рішення. Жодне з цих налаштувань не авторизує повторно встановлений тунель CONNECT для кожного байта чи внутрішнього HTTPS-запиту. Якщо помічник застосовує квоту трафіку, дозволені передавання можуть тривати після зміни балансу.

Помічник є постійним учасником протоколу, а не обов'язково новим процесом скрипту для кожного запиту. Тримайте його готовим до послідовних рядків запитів і надсилайте кожну відповідь негайно. Діагностику виводьте в інший канал. У разі ввімкненої паралельності повертайте відповідний наданий ідентифікатор каналу.

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