Кеширање спољашњих ACL-а у Squid-у: зашто се помоћник не позива сваки пут

Помоћник који забележи један захтев и затим утихне може бити нормалан. Squid може оценити правило користећи кеширани резултат спољашњег ACL-а, а да помоћнику не пошаље нови упит.

Прво дефинишите одлуку која се може поново користити. „Сме ли овај налог да користи прокси?“ захтева другачије улазе од „Сме ли овај налог да достигне ово одредиште?“ Проширени формат спољашњег ACL-а чини кључ кеша. Ако помоћник одлучује по корисничком имену и одредишту, али кључ садржи само корисничко име, кеширано одобрење може се применити шире од предвиђеног. Укључите сваки улаз који мења одговор и избегавајте детаље који само уситњавају еквивалентне одлуке.

Затим изаберите свежину. Позитивни ttl и negative_ttl управљају подударним и неподударним резултатима; grace може покренути освежавање пре истека уноса. Одредите колико дуго кеширано одобрење опозваног налога сме утицати на касније одлуке. Ниједна од ових поставки не ауторизује поново успостављени CONNECT тунел за сваки бајт или унутрашњи HTTPS захтев. Ако помоћник спроводи квоту саобраћаја, одобрени преноси могу се наставити након промене салда.

Помоћник је трајни учесник протокола, а не нужно нови скриптни процес за сваки захтев. Држите га спремним за узастопне редове упита и одмах шаљите сваки одговор. Дијагностику ставите на други канал. Уз омогућену паралелност вратите одговарајући достављени идентификатор канала.

На крају, дефинишите исходе „споро“, „недоступно“ и „унутрашња грешка“ и учините да их околни редослед ACL-а произведе. Дизајн је завршен када и специфичност и дозвољена старост одговора који се може поново користити одговарају захтеву за приступ.