Hvilken Squid-bytteller bør en trafikkvote bruke?
Avgjør om en proxykvote måler svar, forespørsler, oppstrøms brødtekster eller trafikk på aksesslinjen før du summerer Squid-loggfelt.
«Gi hver bruker ti gigabyte» høres presist ut helt til to rapporter er uenige. Den ene summerte svar sendt til klientene; den andre telte byte hentet oppstrøms. Begge kan rapportere feltet de valgte riktig.
Squid-loggformatet har egne tellere:
| Felt | Dokumentert måling |
|---|---|
%<st | Total svartrafikk sendt til klienten, etter tilpasning |
%>st | Total forespørselsstørrelse mottatt fra klienten, uten byte for chunked-koding |
%<bs | HTTP-ekvivalente meldingskroppsbyte mottatt fra neste hopp, med dokumenterte unntak |
Bytes-kolonnen i den innebygde Squid-loggen bruker telleren for klientsvar. Det er ikke et løfte om at verdien tilsvarer lengden på den lagrede filen, og heller ikke en måling av hver Ethernet- eller IP-byte en ISP fakturerer.
Cachetreff illustrerer forskjellen: Squid kan sende et svar uten å hente noe nytt oppstrøms. Opplastningstungt arbeid illustrerer en annen: å telle bare svar lar forespørselsretningen falle utenfor budsjettet.
For CONNECT kan proxyen regnskapsføre videreformidlet trafikk uten å forstå hver krypterte fil eller side inne i tunnelen. Den kan ikke gjøre tunnelens byttetotal om til en nøyaktig oversikt over nedlastede applikasjonsobjekter.
Skriv kvotekontrakten ved siden av telleren: retning, observasjonspunkt, regnskapsperiode og identitet. Ta så vare på loggformatversjonen sammen med rapportene. Uenighet om hva en byte betyr bør ikke «rettes» ved å gange hver verdi med en gjettet korreksjonsfaktor. For håndheving kan totaler for fullførte transaksjoner ligge bak faktisk bruk.