Quel compteur d'octets de Squid une quota de trafic doit-il utiliser ?
Décidez si une quota de proxy mesure les réponses, les requêtes, les corps amont ou le trafic du lien d'accès avant d'additionner les champs du journal de Squid.
« Donner dix gigaoctets à chaque utilisateur » semble précis jusqu'à ce que deux rapports divergent. L'un additionnait les réponses envoyées aux clients ; l'autre comptait les octets récupérés en amont. Les deux peuvent rendre correctement compte du champ qu'ils ont choisi.
Le format de journal de Squid comporte des compteurs distincts :
| Champ | Mesure documentée |
|---|---|
%<st | Trafic total des réponses envoyées au client, après adaptation |
%>st | Taille totale de la requête reçue du client, hors octets d'encodage par blocs |
%<bs | Octets du corps du message équivalents HTTP reçus du saut suivant, avec les exclusions documentées |
La colonne des octets du journal natif de Squid utilise le compteur de réponses au client. Elle ne promet pas que la valeur égale la longueur du fichier enregistré, ni ne mesure chaque octet Ethernet ou IP facturé par un fournisseur d'accès.
Les succès de cache illustrent la différence : Squid peut envoyer une réponse sans nouvelle récupération en amont. Un travail à forte composante d'envoi en illustre une autre : ne compter que les réponses laisse la direction des requêtes hors du budget.
Pour CONNECT, le proxy peut comptabiliser le trafic relayé sans comprendre chaque fichier ou page chiffrés à l'intérieur du tunnel. Il ne peut pas transformer le total d'octets d'un tunnel en inventaire exact des objets applicatifs téléchargés.
Écrivez le contrat de la quota à côté du compteur : direction, point d'observation, période comptable et identité. Conservez ensuite la version du format de journal avec les rapports. Un désaccord sur ce que signifie un octet ne devrait pas être « corrigé » en multipliant chaque valeur par un facteur de correction supposé. Pour l'application, les totaux des transactions terminées peuvent retarder sur l'usage en direct.