Vilken Squid-byträknare bör en trafikkvot använda?
Avgör om en proxykvot mäter svar, förfrågningar, uppströmskroppar eller trafik på åtkomstlinjen innan du summerar Squid-loggfält.
”Ge varje användare tio gigabyte” låter exakt ända tills två rapporter inte stämmer. Den ena summerade svar som skickades till klienterna; den andra räknade byte som hämtades uppströms. Båda kan rapportera sitt valda fält korrekt.
Squid-loggformatet har separata räknare:
| Fält | Dokumenterad mätning |
|---|---|
%<st | Total svartrafik som skickas till klienten, efter anpassning |
%>st | Total förfrågningsstorlek som tas emot från klienten, exklusive byte för chunked-kodning |
%<bs | HTTP-ekvivalenta meddelandekroppsbyte som tas emot från nästa hopp, med dokumenterade undantag |
Bytes-kolumnen i Squids inbyggda logg använder räknaren för klientsvar. Det är inget löfte om att värdet motsvarar längden på den sparade filen, och inte heller en mätning av varje Ethernet- eller IP-byte som en operatör debiterar.
Cacheträffar illustrerar skillnaden: Squid kan skicka ett svar utan att hämta något nytt uppströms. Uppladdningstungt arbete illustrerar en annan: att bara räkna svar lämnar förfrågningsriktningen utanför budgeten.
För CONNECT kan proxyn redovisa vidarebefordrad trafik utan att förstå varje krypterad fil eller sida i tunneln. Den kan inte göra tunnelns bytestotal till en exakt förteckning över nedladdade applikationsobjekt.
Skriv kvotavtalet bredvid räknaren: riktning, observationspunkt, redovisningsperiod och identitet. Behåll sedan loggformatversionen tillsammans med rapporterna. Oenighet om vad en byte betyder bör inte ”fixas” genom att multiplicera varje värde med en gissad korrektionsfaktor. För efterlevnad kan summor för slutförda transaktioner släpa efter faktisk användning.