Hạn mức lưu lượng nên dùng bộ đếm byte nào của Squid?
Hãy quyết định xem hạn mức proxy đo phản hồi, yêu cầu, phần thân từ thượng nguồn hay lưu lượng của đường truy cập trước khi cộng các trường log của Squid.
“Cấp cho mỗi người dùng mười gigabyte” nghe có vẻ chính xác cho đến khi hai báo cáo không khớp nhau. Một báo cáo cộng các phản hồi gửi tới máy khách; báo cáo kia đếm số byte lấy từ thượng nguồn. Cả hai đều có thể đang báo cáo đúng trường mà mình chọn.
Định dạng log của Squid có các bộ đếm riêng:
| Trường | Phép đo được ghi nhận |
|---|---|
%<st | Tổng lưu lượng phản hồi gửi tới máy khách, sau khi thích ứng |
%>st | Tổng kích thước yêu cầu nhận từ máy khách, không gồm byte mã hóa theo khối |
%<bs | Byte phần thân thông điệp tương đương HTTP nhận từ chặng kế tiếp, với các loại trừ đã ghi nhận |
Cột bytes trong log gốc của Squid dùng bộ đếm phản hồi gửi cho máy khách. Đó không phải lời hứa rằng giá trị bằng độ dài tệp đã lưu, cũng không phải phép đo từng byte Ethernet hay IP mà nhà mạng tính phí.
Lần trúng bộ nhớ đệm cho thấy khác biệt: Squid có thể gửi phản hồi mà không lấy mới từ thượng nguồn. Công việc nhiều tải lên cho thấy điều khác: chỉ đếm phản hồi thì chiều yêu cầu nằm ngoài ngân sách.
Với CONNECT, proxy có thể hạch toán lưu lượng chuyển tiếp mà không cần hiểu từng tệp hay trang đã mã hóa bên trong đường hầm. Nó không thể biến tổng byte của đường hầm thành bản kiểm kê chính xác các đối tượng ứng dụng đã tải xuống.
Hãy viết hợp đồng hạn mức bên cạnh bộ đếm: hướng, điểm quan sát, kỳ hạch toán và danh tính. Sau đó giữ phiên bản định dạng log cùng với các báo cáo. Bất đồng về ý nghĩa của một byte không nên được “sửa” bằng cách nhân mọi giá trị với một hệ số hiệu chỉnh phỏng đoán. Để thực thi, tổng của các giao dịch đã hoàn tất có thể chậm hơn mức dùng thực tế.