Melyik Squid bájtszámlálót használja a forgalmi kvóta?
Döntse el, hogy a proxy kvóta a válaszokat, a kéréseket, a felsőbb szintű törzseket vagy az elérési hivatkozás forgalmát méri-e, mielőtt a Squid naplómezőit összeadja.
„Adj minden felhasználónak tíz gigabájtot” pontosnak hangzik, amíg két jelentés nem ellentmond egymásnak. Az egyik a klienseknek küldött válaszokat összegezte; a másik a felsőbb szintről lekért bájtokat számolta. Lehet, hogy mindkettő helyesen jelenti a saját választott mezőjét.
A Squid naplóformátumában külön számlálók vannak:
| Mező | Dokumentált mérés |
|---|---|
%<st | A kliensnek elküldött teljes válaszforgalom, az adaptáció után |
%>st | A kliensről fogadott teljes kérésméret, a chunked kódolás bájtjai nélkül |
%<bs | A következő ugrástól fogadott, HTTP-vel egyenértékű üzenettörzs-bájtok, a dokumentált kivételekkel |
A natív Squid napló bájtoszlopa a kliensválasz-számlálót használja. Ez nem ígéret arra, hogy az érték megegyezik a mentett fájl hosszával, és nem méri az ISP által elszámolt összes Ethernet- vagy IP-bájtot sem.
A gyorsítótár-találatok szemléltetik a különbséget: a Squid úgy is küldhet választ, hogy nem kér le frisset a felsőbb szintről. A feltöltésigényes munka másra mutat: ha csak a válaszokat számoljuk, a kérés iránya kimarad a keretből.
CONNECT esetén a proxy elszámolhatja a továbbított forgalmat anélkül, hogy ismerné az alagúton belüli egyes titkosított fájlokat vagy oldalakat. Nem tudja az alagút bájtösszegét a letöltött alkalmazásobjektumok pontos leltárává alakítani.
Írja a kvótaszerződést a számláló mellé: irány, megfigyelési pont, elszámolási időszak és azonosság. Majd őrizze meg a naplóformátum verzióját a jelentésekkel együtt. Azt, hogy mit jelent egy bájt, nem szabad úgy „javítani”, hogy minden értéket egy találgatott korrekciós tényezővel megszorzunk. Kikényszerítéshez a befejezett tranzakciók összegei elmaradhatnak az élő használattól.