Який лічильник байтів Squid має використовувати квота трафіку?
Вирішіть, чи квота проксі вимірює відповіді, запити, тіла від вищого сервера або трафік лінії доступу, перш ніж підсумовувати поля журналу Squid.
«Дайте кожному користувачеві десять гігабайтів» звучить точно, доки два звіти не розійдуться. Один підсумовував відповіді, надіслані клієнтам; інший рахував байти, отримані від вищого сервера. Обидва можуть правильно повідомляти обране поле.
Формат журналу Squid має окремі лічильники:
| Поле | Документоване вимірювання |
|---|---|
%<st | Загальний трафік відповідей, надісланих клієнту, після адаптації |
%>st | Загальний розмір запиту, отриманого від клієнта, без байтів блокового кодування |
%<bs | Байти тіла повідомлення в еквіваленті HTTP, отримані від наступного вузла, з документованими винятками |
Стовпець bytes у власному журналі Squid використовує лічильник відповідей клієнту. Це не обіцянка, що значення дорівнює довжині збереженого файлу, і не вимірювання кожного байта Ethernet чи IP, за який стягує плату провайдер.
Попадання в кеш показують різницю: Squid може надіслати відповідь, не роблячи свіжого запиту до вищого сервера. Робота з великим вивантаженням показує інше: якщо рахувати лише відповіді, напрямок запитів залишається поза бюджетом.
Для CONNECT проксі може обліковувати переданий трафік, не розбираючи кожен зашифрований файл або сторінку в тунелі. Він не може перетворити сумарні байти тунелю на точний перелік завантажених об'єктів застосунку.
Запишіть контракт квоти поруч із лічильником: напрямок, точка спостереження, обліковий період і ідентичність. Потім зберігайте версію формату журналу разом зі звітами. Розбіжність щодо того, що означає байт, не слід «виправляти», множачи кожне значення на вгаданий поправковий коефіцієнт. Для застосування підсумки завершених транзакцій можуть відставати від поточного використання.