Кэшаванне знешніх ACL Squid: чаму памочнік выклікаецца не кожны раз
Праектуйце знешнія ACL-памочнікі Squid вакол пастаянных працэсаў, ключоў кэша рашэнняў і патрабавання свежасці аўтарызацыі.
Памочнік, які запісвае адзін запыт і потым змаўкае, можа быць нармальным. Squid можа ацаніць правіла з дапамогай закэшаванага выніку знешняга ACL, не адпраўляючы памочніку новы запыт.
Спачатку вызначце рашэнне, якое можна паўторна выкарыстоўваць. «Ці можа гэты ўліковы запіс выкарыстоўваць проксі?» патрабуе іншых уваходаў, чым «Ці можа гэты ўліковы запіс дасягнуць гэтага прызначэння?» Пашыраны фармат знешняга ACL утварае ключ кэша. Калі памочнік вырашае па імені карыстальніка і прызначэнні, а ключ змяшчае толькі імя, закэшаваны дазвол можа прымяняцца шырэй, чым меркавалася. Уключыце ўсе ўваходы, якія змяняюць адказ, і пазбягайце дэталяў, якія толькі драбняць эквівалентныя рашэнні.
Затым выберыце свежасць. Дадатныя ttl і negative_ttl кіруюць супадаючымі і несупадаючымі вынікамі; grace можа пачаць абнаўленне да сканчэння тэрміну запісу. Вызначце, як доўга закэшаваны дазвол адкліканага ўліковага запісу можа ўплываць на наступныя рашэнні. Ніводная з гэтых налад не аўтарызуе існуючы тунель CONNECT для кожнага байта ці ўнутранага HTTPS-запыту. Калі памочнік прытрымліваецца квоты трафіку, дапушчаныя перадачы могуць працягвацца пасля змены балансу.
Памочнік — пастаянны ўдзельнік пратаколу, а не абавязкова новы працэс скрыпта для кожнага запыту. Трымайце яго гатовым да чарговых радкоў запытаў і неадкладна адпраўляйце кожны адказ. Дыягностыку выводзьце на іншы канал. Пры ўключанай канкурэнтнасці вяртайце адпаведны перададзены ідэнтыфікатар канала.
Нарэшце, вызначце вынікі «павольна», «недаступна» і «ўнутраная памылка» і забяспечце, каб парадак навакольных ACL іх ствараў. Дызайн завершаны, калі і дакладнасць, і дапушчальны ўзрост паўторна выкарыстоўванага адказу адпавядаюць патрабаванню доступу.