Кеширање на надворешни ACL во Squid: зошто помошникот не се повикува секој пат
Дизајнирајте Squid помошници за надворешни ACL околу постојани процеси, клучеви за кеш на одлуки и јасно барање за свежина на авторизацијата.
Помошник што ќе евидентира едно барање и потоа ќе замолчи може да биде нормално. Squid може да го оцени правилото со кеширан резултат од надворешен ACL без да му испрати ново прашање на помошникот.
Прво дефинирајте ја одлуката што може повторно да се користи. „Смее ли оваа сметка да го користи проксито?“ бара различни влезови од „Смее ли оваа сметка да стигне до оваа дестинација?“ Проширениот формат на надворешен ACL го формира клучот за кеш. Ако помошникот одлучува по корисничко име и дестинација, но клучот содржи само корисничко име, кешираното одобрување може да се примени пошироко од предвиденото. Вклучете секој влез што го менува одговорот и избегнувајте детали што само ги фрагментираат еквивалентните одлуки.
Потоа изберете свежина. Позитивните ttl и negative_ttl управуваат со совпаѓачки и несовпаѓачки резултати; grace може да започне освежување пред да истече записот. Одлучете колку долго кешираното одобрување на отповикана сметка смее да влијае на подоцнежните одлуки. Ниту едно од овие поставки не го авторизира повторно воспоставениот CONNECT тунел за секој бајт или внатрешно HTTPS барање. Ако помошникот спроведува квота за сообраќај, дозволените преноси може да продолжат откако ќе се промени салдото.
Помошникот е постојан учесник во протоколот, а не нужно нов скриптен процес за секое барање. Држете го подготвен за последователни линии на прашања и испраќајте го секој одговор веднаш. Ставете ја дијагностиката на друг канал. Кога паралелизмот е овозможен, вратете го соодветниот доставен идентификатор на каналот.
На крајот, дефинирајте ги бавниот, недостапниот и излезот од внатрешна грешка и направете околниот редослед на ACL да ги создаде. Дизајнот е завршен кога и специфичноста и дозволената возраст на одговорот што може повторно да се користи одговараат на барањето за пристап.