คู่มือเกมแลค › ต้นเหตุของการส่งซ้ำใน TCP
policer ทิ้งส่วนที่เกิน Traffic policing
ID สาเหตุ rt-policer · ผู้รับผิดชอบหลัก อินฟราเครือข่าย (ทีมอินฟรา) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา), พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
แพ็กเกจเน็ตของ ISP, ขีดจำกัดของอินสแตนซ์คลาวด์ และอุปกรณ์ป้องกัน DDoS บางครั้งจะทิ้งแพ็กเก็ตที่เกินความเร็วที่กำหนดทันทีโดยไม่เข้าคิว
ทำไม ปริมาณที่ส่งในชั่วขณะเกินความเร็วหรือ burst ที่อนุญาต → ผลคือ แพ็กเก็ตส่วนที่เกินถูกทิ้งทันทีโดยไม่เข้าคิว (policing) → บนหน้าจอ ทุกจังหวะที่ burst ใหญ่ แพ็กเก็ตหายหลายตัว จึงค้างแล้วตามด้วยอาการกรอเร็ว, ความเร็วเฉลี่ยดูต่ำกว่าขีดจำกัด
- อาการ
- ค้าง, กรอเร็ว, วาร์ป
- ปัจจัย
- แพ็กเก็ตหาย
- ใครเจอ
- ทั้งเซิร์ฟเวอร์, บางพื้นที่/บาง ISP, เราคนเดียว
- เกิดเมื่อไร
- ตอนคนแห่มารวมกัน, ช่วงพีคหัวค่ำ
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก อินฟราเครือข่าย (ทีมอินฟรา) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา), พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
- งานฝั่งทีมพัฒนาเกม
- กระจายปริมาณที่ส่งรวดเดียวในแต่ละทิกให้ทั่วช่วงทิก เพื่อลดปริมาณการส่งชั่วขณะให้ต่ำกว่า burst ที่อนุญาต, ถ้าติดขีดจำกัดจำนวนแพ็กเก็ตต่อวินาที ให้รวมข้อความของหนึ่งทิกไว้ในแพ็กเก็ตเดียว
- งานฝั่งทีมอินฟรา
- เครือข่าย: ตรวจตัวนับส่วนเกินของ policer บนอุปกรณ์, ใช้ shaper แทน policer, เพิ่ม burst ที่อนุญาต เครื่องเซิร์ฟเวอร์/OS: ตรวจเมตริกการเกินขีดจำกัดของคลาวด์ (AWS ดู bw_out_allowance_exceeded และ pps_allowance_exceeded จาก ethtool -S), อัปเกรดอินสแตนซ์, ทำ pacing ที่เซิร์ฟเวอร์ (คิว fq ของ Linux)
- ตัวเลขที่ควรรู้
- shaper (เข้าคิวเพื่อหน่วงไว้) ทำให้ความหน่วงเพิ่ม ส่วน policer (ทิ้งทันที) ทำให้แพ็กเก็ตหายเพิ่ม การเชื่อมต่อเกมแบบ TCP อาจหยุดหลายร้อย ms จากการหายเพียงครั้งเดียว ถ้าแค่เกินขีดจำกัดชั่วครู่ policer มักส่งผลหนักกว่า
- บนกราฟ
- ชนเพดานแล้วแบนราบ · ปริมาณการส่งที่วัดด้วยช่วงเวลาสั้น, ตัวนับส่วนเกินของ policer/allowance
- จุดที่ต้องดู
- ตัวนับ exceed และการทิ้งของอุปกรณ์ที่มี policer ถ้าเป็นคลาวด์ดู bw_out_allowance_exceeded และ pps_allowance_exceeded จาก ethtool -S การเชื่อมต่อที่แพ็กเก็ตหาย ดู RTT ก่อนหายจาก rtt ของ ss -ti หรือจาก packet capture
- สัญญาณว่าใช่
- ตัวนับส่วนเกินเพิ่มขึ้น และปริมาณการส่งที่วัดด้วยช่วงเวลาสั้นแบนราบเหมือนถูกตัดที่ค่าหนึ่ง RTT ไม่ขึ้นก่อนหาย และแพ็กเก็ตหลายตัวหายพร้อมกันเฉพาะจังหวะที่ burst ใหญ่
- สัญญาณว่าไม่ใช่
- RTT ขึ้นก่อนแพ็กเก็ตหาย: น่าจะเป็นคิวล้น (“คิวคอขวดล้น”, “บัฟเฟอร์ตื้นล้นเพราะ burst จากฝั่งส่ง”) ถ้าตัวนับส่วนเกินไม่ขยับ น่าจะเป็นสาเหตุอื่น
- วิธีตรวจ
- ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
แหล่งอ้างอิง
- RFC 2475: An Architecture for Differentiated Services IETF
นิยามว่า shaping หน่วงแพ็กเก็ตให้เข้ากับ traffic profile ส่วน policing ทิ้งแพ็กเก็ตที่เกิน profile - An Internet-Wide Analysis of Traffic Policing Google
การส่งที่โดน policing มีอัตราแพ็กเก็ตหายสูงกว่าเฉลี่ย 6 เท่า และใช้ pacing หรือ shaping ก็ได้ผลตามเป้าหมายเดียวกัน การแยกแยะว่า policing ทิ้งส่วนที่เกินโดยที่ RTT ไม่เพิ่ม ส่วนคิวล้นจะทำให้ RTT ขึ้นก่อนแพ็กเก็ตหาย (SIGCOMM 2016) - Monitor network performance for ENA settings on your EC2 instance AWS
bw_out_allowance_exceeded และ pps_allowance_exceeded ใน ethtool -S: จำนวนแพ็กเก็ตที่ถูกเข้าคิวหรือถูกทิ้งเพราะเกินขีดจำกัดของอินสแตนซ์ - tc-fq(8) — Linux manual page iproute2
pacing ต่อการเชื่อมต่อของคิว fq ใน Linux - ss(8) — Linux manual page iproute2
rtt (เวลาไปกลับเฉลี่ย) ใน ss -i
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: ต้นเหตุของการส่งซ้ำใน TCP
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (ค้าง)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง