Qual contador de bytes do Squid um limite de tráfego deve usar?
Decida se a cota de um proxy mede respostas, pedidos, corpos do upstream ou o tráfego do link de acesso antes de somar os campos de log do Squid.
«Dê a cada usuário dez gigabytes» soa preciso até dois relatórios discordarem. Um somava as respostas enviadas aos clientes; outro contava os bytes buscados no upstream. Ambos podem estar relatando corretamente o campo escolhido.
O formato de log do Squid tem contadores distintos:
| Campo | Medição documentada |
|---|---|
%<st | Tráfego total de resposta enviado ao cliente, após a adaptação |
%>st | Tamanho total do pedido recebido do cliente, excluindo os bytes de codificação em partes |
%<bs | Bytes do corpo da mensagem equivalentes a HTTP recebidos do próximo salto, com exclusões documentadas |
A coluna bytes do log nativo do Squid usa o contador de respostas ao cliente. Não é uma promessa de que o valor seja igual ao comprimento do arquivo salvo, nem uma medição de cada byte Ethernet ou IP cobrado por um provedor.
Acertos no cache ilustram a diferença: o Squid pode enviar uma resposta sem buscar algo novo no upstream. Trabalho com muitos envios ilustra outra: contar apenas respostas deixa a direção dos pedidos fora do orçamento.
Para CONNECT, o proxy pode contabilizar o tráfego repassado sem entender cada arquivo ou página criptografada dentro do túnel. Ele não consegue transformar o total de bytes de um túnel num inventário exato dos objetos de aplicação baixados.
Escreva o contrato da cota ao lado do contador: direção, ponto de observação, período contábil e identidade. Depois guarde a versão do formato de log junto com os relatórios. Uma discordância sobre o que um byte significa não deve ser «corrigida» multiplicando cada valor por um fator de correção adivinhado. Para aplicação, os totais de transações concluídas podem ficar atrás do uso em tempo real.