트래픽 쿼터는 Squid의 어떤 바이트 카운터를 써야 할까
Squid 로그 필드를 합산하기 전에 프록시 쿼터가 응답, 요청, 업스트림 본문, 액세스 회선 트래픽 중 무엇을 측정하는지 정합니다.
“사용자마다 10기가바이트”는 두 보고서가 어긋나기 전까지는 정확해 보인다. 하나는 클라이언트로 보낸 응답을 합산했고, 다른 하나는 업스트림에서 가져온 바이트를 셌다. 둘 다 각자 고른 필드를 올바르게 보고하고 있을 수 있다.
Squid 로그 형식에는 서로 다른 카운터가 있다:
| 필드 | 문서화된 측정 |
|---|---|
%<st | 적응(adaptation) 후 클라이언트로 보낸 총 응답 트래픽 |
%>st | 클라이언트에서 받은 총 요청 크기(청크 인코딩 바이트 제외) |
%<bs | 다음 홉에서 받은 HTTP 등가 메시지 본문 바이트(문서화된 제외 포함) |
Squid 기본 로그의 bytes 열은 클라이언트 응답 카운터를 쓴다. 그 값이 저장된 파일 길이와 같다는 약속도 아니고, ISP가 과금하는 모든 이더넷이나 IP 바이트를 측정한 것도 아니다.
캐시 적중이 차이를 보여준다. Squid는 업스트림에서 새로 가져오지 않고도 응답을 보낼 수 있다. 업로드가 많은 작업은 또 다른 차이를 보여준다. 응답만 세면 요청 방향이 예산에서 빠진다.
CONNECT의 경우 프록시는 터널 안의 암호화된 파일이나 페이지를 이해하지 않고도 중계 트래픽을 계산할 수 있다. 그러나 터널의 바이트 합계를 내려받은 애플리케이션 객체의 정확한 목록으로 바꿀 수는 없다.
쿼터 계약을 카운터 옆에 적어라. 방향, 관측 지점, 회계 기간, 식별자다. 그런 다음 로그 형식 버전을 보고서와 함께 보관하라. 바이트의 의미에 대한 불일치는 모든 값을 추정 보정 계수로 곱해 “고쳐서는” 안 된다. 강제 적용에서는 완료된 트랜잭션 합계가 실시간 사용량보다 뒤처질 수 있다.