Які байтавы лічыльнік Squid павінна выкарыстоўваць квота трафіку?
Вызначце, ці квота проксі лічыць адказы, запыты, целы запытаў уверх або трафік спасылкі доступу, перш чым суміраваць поля журнала Squid.
«Дайце кожнаму карыстальніку дзесяць гігабайт» гучыць дакладна, пакуль дзве справаздачы не разыходзяцца. Адна сумавала адказы, дасланыя кліентам; другая лічыла байты, атрыманыя з верхняга вузла. Абедзве могуць правільна паказваць выбранае поле.
Фармат журнала Squid мае асобныя лічыльнікі:
| Поле | Задакументаванае вымярэнне |
|---|---|
%<st | Агульны трафік адказаў, дасланых кліенту, пасля адаптацыі |
%>st | Агульны памер запыту, атрыманага ад кліента, без байтаў chunked-кадавання |
%<bs | Байты цела паведамлення, эквівалентныя HTTP, атрыманыя ад наступнага вузла, з задакументаванымі выключэннямі |
Слупок байтаў уласнага журнала Squid выкарыстоўвае лічыльнік адказаў кліенту. Гэта не гарантыя, што значэнне роўнае даўжыні захаванага файла, і не вымярэнне кожнага байта Ethernet або IP, які бярэ пастаўшчык паслуг.
Пападанні ў кэш паказваюць розніцу: Squid можа даслаць адказ, не робячы новага запыту ўверх. Праца з вялікай доляй загрузкі паказвае іншае: калі лічыць толькі адказы, кірунак запыту застаецца па-за бюджэтам.
Для CONNECT проксі можа ўлічваць перададзены трафік, не разумеючы кожны зашыфраваны файл або старонку ў тунелі. Ён не можа пераўтварыць агульную колькасць байтаў тунеля ў дакладны пералік спампаваных аб'ектаў праграм.
Запішыце дамову квоты побач з лічыльнікам: кірунак, пункт назірання, разліковы перыяд і ідэнтычнасць. Затым захоўвайце версію фармату журнала разам са справаздачамі. Рознагалоссе пра сэнс байта не варта «выпраўляць», памнажаючы кожнае значэнне на меркаваны каэфіцыент. Для кантролю сумы завершаных транзакцый могуць адставаць ад бягучага выкарыстання.