คู่มือเกมแลค › ต้นเหตุของการส่งซ้ำใน TCP
แพ็กเก็ตหายช่วงไร้สาย Wi-Fi / cellular link loss
ID สาเหตุ rt-wireless · ผู้รับผิดชอบหลัก ภายนอก (ภายนอก) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา), พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม), พัฒนาไคลเอนต์ (ทีมพัฒนาเกม)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
Wi-Fi และเครือข่ายมือถือจะลองส่งซ้ำในช่วงไร้สายอยู่หลายครั้ง ถ้ายังไม่สำเร็จก็จะทิ้งแพ็กเก็ตนั้น แล้ว TCP จะส่งแพ็กเก็ตที่ถูกทิ้งใหม่หลังจากนั้นพักใหญ่
ทำไม สัญญาณอ่อนหรือถูกรบกวนหนัก การส่งในช่วงไร้สายจึงล้มเหลวติดต่อกัน → ผลคือ อุปกรณ์ไร้สายลองใหม่จนเกินขีดจำกัด (ปกติไม่กี่ครั้งถึงสิบกว่าครั้ง) แล้วทิ้งแพ็กเก็ต → บนหน้าจอ ค้างนานเท่ากับเวลาที่ TCP รอส่งซ้ำ แพ็กเก็ตที่ตามมารออยู่ใน receive buffer แล้วทะลักออกมาเป็นอาการกรอเร็ว
อาการ ค้าง , กรอเร็ว , วาร์ป ปัจจัย แพ็กเก็ตหาย, จิตเตอร์
ใครเจอ เราคนเดียว, คนในบ้านเดียวกัน
เกิดเมื่อไร สุ่มเป็นครั้งคราว, ระหว่างเดินทาง/ย้ายแมพ
ผู้รับผิดชอบ ผู้รับผิดชอบหลัก ภายนอก (ภายนอก) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา), พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม), พัฒนาไคลเอนต์ (ทีมพัฒนาเกม)
งานฝั่งทีมพัฒนาเกม เซิร์ฟเวอร์: เปิด TCP_NODELAY (ถ้าเปิด Nagle ไว้ จะไม่มีแพ็กเก็ตที่ตามมาให้ RACK ใช้ตัดสินว่าหาย), ระหว่างที่การส่งติดรอการส่งซ้ำ ให้ส่งเฉพาะอัปเดตสถานะล่าสุดโดยไม่สะสมอันเก่าไว้ (จำกัดปริมาณที่กองรอในเคอร์เนลด้วย TCP_NOTSENT_LOWAT) ไคลเอนต์: เปิด TCP_NODELAY (แพ็กเก็ตที่หายในทิศทางที่ส่งอินพุตของเรา OS ฝั่งไคลเอนต์เป็นผู้กู้คืน), แสดงสถานะเครือข่ายบนจอเมื่อแพ็กเก็ตหายติด ๆ กันหรือปิงพุ่ง
งานฝั่งทีมอินฟรา เร่งการกู้คืนแพ็กเก็ตหายด้วย RACK-TLP (เซิร์ฟเวอร์ป้องกันการหายในช่วงไร้สายไม่ได้ ทำได้แค่กู้คืนให้เร็วขึ้น), ตรวจว่าค่าเริ่มต้นของ Linux รุ่นใหม่ net.ipv4.tcp_recovery=1 (RACK) และ net.ipv4.tcp_early_retrans=3 (TLP) ไม่ถูกเปลี่ยน
งานฝั่งภายนอก แนะนำให้ผู้เล่นใช้สาย LAN, ใช้ 5 GHz หรือ 6 GHz, ย้ายตำแหน่งเราเตอร์หรือเปลี่ยนช่องสัญญาณ
ตัวเลขที่ควรรู้ ถ้าแพ็กเก็ตหายในช่วงไร้สาย 1% แพ็กเก็ตเกม 100 ตัวจะหายไป 1 ตัว ถ้ารับ 10 ตัวใน 1 วินาที ก็จะหยุดแวบราวทุก 10 วินาที ถ้าไม่มี RACK-TLP แต่ละครั้งจะหยุดนานเท่ากับ RTO (ปิง + 200 ms ขึ้นไป)
บนกราฟ จุดที่ต้องดู ping หลายร้อยครั้งจาก PC ของผู้เล่นไปยังเราเตอร์ (gateway) และไปยังเซิร์ฟเวอร์เกม เทียบแพ็กเก็ตหายและช่วงแกว่งของความหน่วง แล้ววัดใหม่หลังเปลี่ยนเป็นสาย LAN หรือเน็ตมือถือ ฝั่งเซิร์ฟเวอร์ดู retrans และ rtt (ค่าเฉลี่ย/ส่วนเบี่ยงเบน) ของการเชื่อมต่อผู้เล่นคนนั้นด้วย ss -ti สัญญาณว่าใช่ ping แค่ถึงเราเตอร์ก็เห็นแพ็กเก็ตหายหรือความหน่วงขึ้นลงไม่นิ่งแล้ว และปัญหาหายไปเมื่อเปลี่ยนเป็นสาย LAN ฝั่งเซิร์ฟเวอร์เห็น retrans และส่วนเบี่ยงเบนของ RTT สูงเฉพาะการเชื่อมต่อของผู้เล่นคนนั้น สัญญาณว่าไม่ใช่ ถึงเราเตอร์ยังปกติ แต่แพ็กเก็ตเริ่มหายหลังจากนั้น: น่าจะเป็นฝั่ง ISP หรือเส้นทาง (“คิวคอขวดล้น”, “เส้นทางเปลี่ยน/เส้นทาง ECMP ที่เสีย”) ถ้าผู้เล่น ISP เดียวกันหลายคนแย่ลงพร้อมกัน ให้เริ่มดูจากช่วงของ ISP วิธีตรวจ ตรวจที่สภาพแวดล้อมฝั่งผู้เล่น
รายละเอียดเพิ่มเติม การลองใหม่ของอุปกรณ์ไร้สายทำให้เกิดจิตเตอร์ (ครั้งละหลาย ms) และจะกลายเป็นแพ็กเก็ตหายก็ต่อเมื่อเกินขีดจำกัดการลองใหม่เท่านั้น ยิ่งคุณภาพสัญญาณไร้สายแย่ลง อาการจึงหนักขึ้นตามลำดับ “จิตเตอร์ → ค้างเป็นครั้งคราว → ค้างบ่อย” ตอนที่ย้ายจากเราเตอร์ (AP) ตัวหนึ่งไปอีกตัว (โรมมิ่ง) บางครั้งแพ็กเก็ตหายต่อเนื่องนานหลายสิบ ms ถึงหลายวินาที ส่วนเครือข่ายมือถือส่งซ้ำมากในช่วงระหว่างเครื่องกับเสาสัญญาณ จึงมักแสดงออกมาเป็นความหน่วงพุ่งหลายร้อย ms มากกว่าแพ็กเก็ตหาย
กรณีจริง Square Enix 2021: FINAL FANTASY XIV แออัดช่วงเปิดตัวภาคเสริม และ error ในคิวล็อกอิน
แหล่งอ้างอิง net/wireless/core.c Linux kernel ขีดจำกัดการลองใหม่เริ่มต้นของ wireless stack ใน Linux: เฟรมสั้น 7 ครั้ง, เฟรมยาว 4 ครั้ง (dot11ShortRetryLimit, dot11LongRetryLimit) RFC 3481: TCP over Second (2.5G) and Third (3G) Generation Wireless Networks IETF เครือข่ายมือถือมีการส่งซ้ำที่ชั้น link จึงมีแพ็กเก็ตหายระดับ IP น้อย แต่การกู้คืนนั้นแสดงออกมาเป็นจิตเตอร์และความหน่วงพุ่ง Wi-Fi roaming support in Apple devices Apple ตอนย้าย AP จะส่งข้อมูลไม่ได้จนกว่าการยืนยันตัวตนกับ AP ใหม่จะเสร็จ และในสภาพแวดล้อม 802.1X อาจใช้เวลาหลายวินาที RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP IETF นิยามของ RACK (ตัดสินการหายตามเวลา) และ TLP (ส่งแพ็กเก็ตท้ายสุดซ้ำ) IP Sysctl Linux kernel tcp_recovery ค่าเริ่มต้น 0x1 (RACK), tcp_early_retrans ค่าเริ่มต้น 3 (เปิด TLP), จำกัดปริมาณข้อมูลที่ยังไม่ได้ส่งด้วย TCP_NOTSENT_LOWAT และ tcp_notsent_lowat tcp(7) — Linux manual page Linux man-pages TCP_NODELAY ปิดอัลกอริทึม Nagle ข้อมูลเล็ก ๆ จึงถูกส่งทันที include/net/tcp.h Linux kernel ค่าต่ำสุดของ RTO คือ TCP_RTO_MIN = 200 ms misc/ss.c iproute2 ss -ti แสดง retrans:จำนวนที่กำลังส่งซ้ำอยู่ตอนนี้/จำนวนส่งซ้ำสะสม และ rtt:RTT/ส่วนเบี่ยงเบนของ RTT (rttvar) สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: ต้นเหตุของการส่งซ้ำใน TCP
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (ค้าง)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง