¿Qué contador de bytes de Squid debe usar una cuota de tráfico?
Decida si una cuota de proxy mide respuestas, peticiones, cuerpos de origen o tráfico del enlace de acceso antes de sumar campos del registro de Squid.
«Dar a cada usuario diez gigabytes» suena preciso hasta que dos informes no coinciden. Uno sumaba las respuestas enviadas a los clientes; el otro contaba los bytes obtenidos del origen. Ambos pueden estar informando correctamente del campo que eligieron.
El formato de registro de Squid tiene contadores distintos:
| Campo | Medición documentada |
|---|---|
%<st | Tráfico total de respuesta enviado al cliente, tras la adaptación |
%>st | Tamaño total de la petición recibida del cliente, sin los bytes de codificación por trozos |
%<bs | Bytes del cuerpo del mensaje equivalentes a HTTP recibidos del siguiente salto, con las exclusiones documentadas |
La columna de bytes del registro nativo de Squid usa el contador de respuesta al cliente. No es una promesa de que el valor sea igual a la longitud del archivo guardado, ni una medición de cada byte Ethernet o IP que cobra un proveedor.
Los aciertos de caché ilustran la diferencia: Squid puede enviar una respuesta sin hacer una captura nueva en el origen. El trabajo con mucha subida ilustra otra: contar solo respuestas deja la dirección de la petición fuera del presupuesto.
Para CONNECT, el proxy puede contabilizar el tráfico retransmitido sin entender cada archivo o página cifrados dentro del túnel. No puede convertir el total de bytes de un túnel en un inventario exacto de los objetos de aplicación descargados.
Escriba el contrato de la cuota junto al contador: dirección, punto de observación, periodo contable e identidad. Luego conserve la versión del formato de registro con los informes. Una discrepancia sobre qué significa un byte no debería «corregirse» multiplicando cada valor por un factor de corrección supuesto. Para la aplicación, los totales de transacciones completadas pueden ir por detrás del uso en vivo.