คู่มือเกมแลค › L8 ซ็อกเก็ตและโปรโตคอล
อัตราการส่งดิ่งลงเพราะ congestion control Congestion control backoff
ID สาเหตุ sk-congestion · ผู้รับผิดชอบหลัก อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
TCP มองว่าแพ็กเก็ตหายคือสัญญาณของความแออัด จึงลดอัตราการส่งลง 30–50% และตอบสนองแบบเดียวกันแม้แพ็กเก็ตหายเพราะ Wi-Fi
ทำไม มีแพ็กเก็ตหายเล็กน้อยบน Wi-Fi หรือเน็ตตอนที่มีข้อมูลต้องส่งมาก → ผลคือ TCP ลดอัตราการส่งลงมากแล้วค่อย ๆ ฟื้นตัว (CUBIC ซึ่งเป็นค่าเริ่มต้นของ Linux และ Windows ลด 30%) → บนหน้าจอ ในที่ที่คนเยอะ อัปเดตตามไม่ทัน: กรอเร็ว, อินพุตดีเลย์
- อาการ
- กรอเร็ว, อินพุตดีเลย์
- ปัจจัย
- ความหน่วง, การหยุดชะงัก
- ใครเจอ
- เราคนเดียว
- เกิดเมื่อไร
- ตอนคนแห่มารวมกัน
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
- งานฝั่งทีมพัฒนาเกม
- ลดปริมาณที่ส่ง (AOI, ส่งเฉพาะส่วนที่เปลี่ยน), แบ่งส่งไม่ให้ออกไปรวดเดียว
- งานฝั่งทีมอินฟรา
- เปลี่ยนไปใช้ congestion control แบบอื่น เช่น BBR (tcp_congestion_control)
- บนกราฟ
- ค่อย ๆ ขึ้นแล้วดิ่งลง · congestion window (cwnd) และอัตราการส่งต่อการเชื่อมต่อ
- จุดที่ต้องดู
- ss -ti ของการเชื่อมต่อของผู้เล่นที่อัปเดตตามไม่ทัน เก็บหลาย ๆ ครั้งเพื่อดูการเปลี่ยนแปลงของ cwnd และ ssthresh และชื่อ congestion control (cubic, bbr) พร้อมดูว่า Send-Q กองสะสมหรือไม่
- สัญญาณว่าใช่
- หลังแพ็กเก็ตหาย cwnd ลดฮวบแล้วค่อย ๆ ขึ้นวนซ้ำ และระหว่างที่ลดอยู่ Send-Q กองสะสม ตรงกับเวลาที่มีผู้เล่นแจ้งอาการกรอเร็วและอินพุตดีเลย์
- สัญญาณว่าไม่ใช่
- cwnd เหลือเฟือแต่อัปเดตยังตามไม่ทัน: น่าจะเป็น window ฝั่งรับ (“zero window (การหยุดที่ดูเหมือนการส่งซ้ำ)”) หรือฝั่งการส่งของเซิร์ฟเวอร์
- วิธีตรวจ
- ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
แหล่งอ้างอิง
- RFC 9438: CUBIC for Fast and Long-Distance Networks IETF
เมื่อแพ็กเก็ตหาย CUBIC ลด window เหลือ 0.7 เท่า (ลด 30%) ส่วน Reno เหลือ 0.5 เท่า, CUBIC เป็นค่าเริ่มต้นของ Linux, Windows และ Apple - TCP BBR congestion control comes to GCP – your Internet just got faster Google Cloud
congestion control ที่อิงการหายของแพ็กเก็ตจะลดอัตราการส่งลงมาก แม้แพ็กเก็ตจะหายด้วยเหตุอื่นนอกจากความแออัด, BBR ตัดสินจากอัตราการส่งถึงปลายทาง (delivery rate) และ RTT - IP Sysctl Linux kernel
tcp_congestion_control ใช้เลือกอัลกอริทึม congestion control ของการเชื่อมต่อใหม่ - ss(8) — Linux manual page iproute2
cwnd, ssthresh และชื่ออัลกอริทึม congestion control ใน -i - net/ipv4/tcp_diag.c (Linux v6.12) Linux kernel
ค่า Recv-Q และ Send-Q ของ ss: ซ็อกเก็ตที่ listen อยู่คือจำนวนการเชื่อมต่อที่รอ accept และขีดจำกัด backlog, ซ็อกเก็ตที่เชื่อมต่อแล้วคือไบต์ที่แอปยังไม่ได้อ่าน และไบต์ที่ส่งไปแล้วแต่ยังไม่ได้รับ ACK
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: L8 ซ็อกเก็ตและโปรโตคอล
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (กรอเร็ว)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง