โควตาทราฟฟิกควรใช้ตัวนับไบต์ตัวใดของ Squid
ตัดสินใจว่าโควตาพร็อกซีวัดการตอบกลับ คำขอ เนื้อหาจากต้นทาง หรือทราฟฟิกของลิงก์เชื่อมต่อ ก่อนจะรวมฟิลด์บันทึกของ Squid
“ให้ผู้ใช้แต่ละคนสิบกิกะไบต์” ฟังดูแม่นยำจนกว่ารายงานสองฉบับจะขัดกัน ฉบับหนึ่งรวมการตอบกลับที่ส่งถึงไคลเอนต์ อีกฉบับนับไบต์ที่ดึงมาจากต้นทาง ทั้งสองอาจรายงานฟิลด์ที่เลือกไว้อย่างถูกต้อง
รูปแบบบันทึกของ Squid มีตัวนับแยกกัน:
| ฟิลด์ | การวัดที่บันทึกไว้ |
|---|---|
%<st | ทราฟฟิกการตอบกลับทั้งหมดที่ส่งถึงไคลเอนต์ หลังการปรับใช้ |
%>st | ขนาดคำขอทั้งหมดที่รับจากไคลเอนต์ ไม่รวมไบต์ของการเข้ารหัสแบบเป็นตอน |
%<bs | ไบต์เนื้อความข้อความเทียบเท่า HTTP ที่รับจากฮอปถัดไป พร้อมข้อยกเว้นที่บันทึกไว้ |
คอลัมน์ bytes ในบันทึกดั้งเดิมของ Squid ใช้ตัวนับการตอบกลับไปยังไคลเอนต์ ไม่ใช่คำมั่นว่าค่าจะเท่ากับความยาวของไฟล์ที่บันทึกไว้ และไม่ใช่การวัดทุกไบต์ของ Ethernet หรือ IP ที่ ISP เรียกเก็บ
แคชฮิตแสดงความต่าง: Squid สามารถส่งการตอบกลับโดยไม่ดึงของใหม่จากต้นทาง งานที่อัปโหลดหนักแสดงอีกอย่าง: การนับเฉพาะการตอบกลับทำให้ทิศทางคำขออยู่นอกงบ
สำหรับ CONNECT พร็อกซีสามารถคิดบัญชีทราฟฟิกที่ส่งต่อโดยไม่ต้องเข้าใจไฟล์หรือหน้าที่เข้ารหัสแต่ละรายการในอุโมงค์ แต่ไม่สามารถเปลี่ยนยอดรวมไบต์ของอุโมงค์ให้เป็นบัญชีที่แม่นยำของออบเจ็กต์แอปพลิเคชันที่ดาวน์โหลดได้
เขียนสัญญาโควตาข้างตัวนับ: ทิศทาง จุดสังเกต ช่วงเวลาบัญชี และตัวตน จากนั้นเก็บเวอร์ชันรูปแบบบันทึกไว้กับรายงาน ความไม่ลงรอยกันว่าไบต์หนึ่งหมายถึงอะไร ไม่ควรถูก “แก้” ด้วยการคูณทุกค่าด้วยตัวคูณแก้ไขที่เดาขึ้น สำหรับการบังคับใช้ ยอดรวมของธุรกรรมที่เสร็จแล้วอาจตามหลังการใช้งานจริง