คู่มือเกมแลค › ต้นเหตุของการส่งซ้ำใน TCP
ACK มาช้าหรือหาย (อัปโหลดเต็ม) ACK path congestion on asymmetric links
ID สาเหตุ rt-ack-path · ผู้รับผิดชอบหลัก ภายนอก (ภายนอก) · ร่วมกับ พัฒนาไคลเอนต์ (ทีมพัฒนาเกม)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
ข้อมูลมาถึงเรียบร้อย แต่ถ้า ACK ที่บอกว่า “ได้รับแล้ว” ไปติดอยู่ในคิวอัปโหลดที่เต็มจนช้าหรือหาย ฝั่งส่งจะตัดสินว่าหายแล้วส่งซ้ำ
ทำไม อัปโหลดเต็มเพราะมีคนในบ้านอัปโหลดวิดีโอหรือสำรองข้อมูลขึ้นคลาวด์ → ผลคือ ACK ติดอยู่ในคิวของเราเตอร์ช้าไปหลายร้อย ms หรือถูกทิ้งเพราะคิวล้น → บนหน้าจอ แพ็กเก็ตเกมที่เซิร์ฟเวอร์ส่งมาส่วนใหญ่มาตรงเวลา แต่อินพุตของเราที่กองอยู่ในคิวอัปโหลดเดียวกันไปช้า จึงเกิดอินพุตดีเลย์และดีดกลับ บางครั้งมีการส่งซ้ำโดยไม่จำเป็น
- อาการ
- อินพุตดีเลย์, ดีดกลับ
- ปัจจัย
- ความหน่วง, แพ็กเก็ตหาย
- ใครเจอ
- คนในบ้านเดียวกัน
- เกิดเมื่อไร
- สุ่มเป็นครั้งคราว, ช่วงพีคหัวค่ำ
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก ภายนอก (ภายนอก) · ร่วมกับ พัฒนาไคลเอนต์ (ทีมพัฒนาเกม)
- งานฝั่งทีมพัฒนาเกม
- แสดงสถานะเครือข่ายบนจอเมื่อปิงพุ่ง, ขึ้นคำแนะนำ “ตรวจโปรแกรมที่กำลังอัปโหลด”
- งานฝั่งภายนอก
- แนะนำให้ผู้เล่นใช้ SQM บนเราเตอร์เพื่อให้คิวอัปโหลดสั้น, ให้แพ็กเก็ตเล็ก (ACK) ไปก่อน, จำกัดความเร็วอัปโหลด (อัปโหลดวิดีโอ, สำรองข้อมูลขึ้นคลาวด์)
- ตัวเลขที่ควรรู้
- ACK ตัวหลังยืนยันแทนตัวก่อนหน้าได้ ACK หายไปไม่กี่ตัวจึงมักไม่เป็นไร ปัญหาอยู่ที่ ACK ที่ติดอยู่ในคิวจนช้า
- บนกราฟ
- สูงเฉพาะบางกลุ่ม · RTT (ปิง) ต่อการเชื่อมต่อ
- จุดที่ต้องดู
- ping ไปเซิร์ฟเวอร์เกมจาก PC ของผู้เล่น เทียบระหว่างตอนเปิดและปิดการอัปโหลด (อัปโหลดวิดีโอ, สำรองข้อมูลขึ้นคลาวด์) ฝั่งเซิร์ฟเวอร์ดู rtt ของการเชื่อมต่อผู้เล่นคนนั้นด้วย ss -ti
- สัญญาณว่าใช่
- ping ขึ้นเป็นหลายร้อย ms เฉพาะตอนอัปโหลด และเกิดอินพุตดีเลย์และดีดกลับ พอหยุดอัปโหลดก็กลับมาปกติในไม่ช้า ฝั่งเซิร์ฟเวอร์เห็น rtt ของการเชื่อมต่อนั้นขึ้นในช่วงเดียวกัน
- สัญญาณว่าไม่ใช่
- แพ็กเก็ตหายและความหน่วงเกิดโดยไม่เกี่ยวกับการอัปโหลด: น่าจะเป็น “แพ็กเก็ตหายช่วงไร้สาย” หรือสาเหตุฝั่งเส้นทาง ถ้าช้าเฉพาะทิศทางจากเซิร์ฟเวอร์ไปหาผู้เล่นและไม่เกี่ยวกับการอัปโหลด น่าจะเป็น “คิวคอขวดล้น”
- วิธีตรวจ
- ตรวจที่สภาพแวดล้อมฝั่งผู้เล่น
แหล่งอ้างอิง
- RFC 3449: TCP Performance Implications of Network Path Asymmetry IETF
บนเน็ตแบบอสมมาตรที่อัปโหลดแคบ ถ้า ACK ช้าหรือหาย ประสิทธิภาพ TCP จะลดลง, ACK เป็นการยืนยันแบบสะสม ถ้าบางตัวหาย ACK ตัวหลังก็ยืนยันแทนได้, มาตรการอย่างการจัดลำดับให้ ACK ไปก่อน - Smart Queue Management Bufferbloat.net
ใช้การจัดการคิวและ shaping ที่เราเตอร์เพื่อรักษาคิวให้สั้น - tc-cake(8) — Linux manual page iproute2
CAKE แยก flow และลดความหน่วงของ flow ที่ส่งห่าง ๆ (sparse flow) ให้ต่ำที่สุด - ss(8) — Linux manual page iproute2
rtt (เวลาไปกลับเฉลี่ย) และ rttvar (ส่วนเบี่ยงเบน) ใน ss -i
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: ต้นเหตุของการส่งซ้ำใน TCP
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (อินพุตดีเลย์)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง