Que contador de bytes de Squid debería usar unha cota de tráfico?
Decida se unha cota de proxy mide respostas, peticións, corpos de orixe ou tráfico da ligazón de acceso antes de sumar campos do rexistro de Squid.
«Darlle a cada usuario dez gigabytes» soa preciso ata que dous informes non coinciden. Un sumaba as respostas enviadas aos clientes; o outro contaba os bytes obtidos da orixe. Ambos poden estar informando correctamente do campo que elixiron.
O formato de rexistro de Squid ten contadores distintos:
| Campo | Medición documentada |
|---|---|
%<st | Tráfico total de resposta enviado ao cliente, tras a adaptación |
%>st | Tamaño total da petición recibida do cliente, sen os bytes de codificación por anacos |
%<bs | Bytes do corpo da mensaxe equivalentes a HTTP recibidos do seguinte salto, coas exclusións documentadas |
A columna de bytes do rexistro nativo de Squid usa o contador de resposta ao cliente. Non promete que o valor sexa igual á lonxitude do ficheiro gardado, nin mide cada byte Ethernet ou IP que cobra un provedor.
Os acertos de caché ilustran a diferenza: Squid pode enviar unha resposta sen facer unha nova captura na orixe. O traballo con moita subida ilustra outra: contar só respostas deixa a dirección da petición fóra do orzamento.
Para CONNECT, o proxy pode contabilizar o tráfico retransmitido sen entender cada ficheiro ou páxina cifrados dentro do túnel. Non pode converter o total de bytes dun túnel nun inventario exacto dos obxectos de aplicación descargados.
Escriba o contrato da cota xunto ao contador: dirección, punto de observación, período contable e identidade. Despois conserve a versión do formato de rexistro cos informes. Unha discrepancia sobre que significa un byte non debería «corrixirse» multiplicando cada valor por un factor de corrección suposto. Para a aplicación, os totais de transaccións completadas poden quedar por detrás do uso en directo.