คู่มือเกมแลค › ค้นหาตามอาการ
กรอเร็ว: 36 สาเหตุและทีมที่ต้องแก้
เรียกอีกอย่างว่า: รัว ๆ, เหมือนกดกรอ, ทุกอย่างมาพร้อมกัน
เปิดพจนานุกรมอาการในฉบับหลักที่มีภาพ →
หน้าจอที่หยุดไปกลับมาขยับอีกครั้ง แล้วการเคลื่อนไหว การโจมตี และดาเมจที่สะสมไว้ก็ผ่านไปอย่างรวดเร็วในทีเดียว
มอนสเตอร์และผู้เล่นขยับเร็วเหมือนกดกรอ ตัวเลขดาเมจและเอฟเฟกต์พรั่งพรูออกมาพร้อมกัน
แพ็กเก็ตไปกองรออยู่ที่ใดที่หนึ่ง แล้วถูกปล่อยออกมาพร้อมกัน ตัวอย่างที่พบบ่อยคือการรอส่งซ้ำของ TCP, เซิร์ฟเวอร์เร่งคำนวณให้ทัน และไคลเอนต์ประมวลผลไม่ทัน
สาเหตุที่ทำให้เกิดอาการนี้
L1 โปรเซสเกมฝั่งไคลเอนต์
L2 OS และอุปกรณ์ฝั่งไคลเอนต์
- โปรเซสเบื้องหลังแย่ง CPU: เมื่อการสแกนของแอนตี้ไวรัส, Windows Update, โปรแกรมสตรีม หรือวิดีโอในเบราว์เซอร์ยึดคอร์ไว้ เธรดเกมจะไม่ได้รับ CPU และต้องรอ (ภายนอก (ภายนอก))
- receive buffer ล้น: ถ้าเกมยุ่งจนดึงแพ็กเก็ตออกจากซ็อกเก็ต (อินเทอร์เฟซรับส่งข้อมูลเครือข่ายที่ OS จัดให้) ช้า บัฟเฟอร์ของ OS จะล้น (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))
- แอปอื่นในเครื่องเดียวกันแย่งแบนด์วิดท์: ถ้าการซิงก์ไฟล์ขึ้นคลาวด์, การดาวน์โหลดไฟล์ใหญ่ หรือแพตช์เกมกำลังทำงานบน PC เครื่องเดียวกัน แพ็กเก็ตเกมจะต้องรอในคิว (ภายนอก (ภายนอก))
- จำกัดการประมวลผลเมื่อย่อหรือสลับหน้าต่าง: เมื่อไปดูหน้าต่างอื่นหรือย่อเกม ตัวเกมและ Windows จะลดความเร็วการทำงานของเกมเพื่อประหยัดไฟ พอกลับมา แพ็กเก็ตที่กองรอจะทะลักเข้ามา หรือหลุดไปแล้ว (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))
L3 เครือข่ายในบ้าน
- bufferbloat (คิวในเราเตอร์): เมื่อมีคนในบ้านอัปโหลดวิดีโอหรือดาวน์โหลดไฟล์ใหญ่ แพ็กเก็ตจะกองอยู่ในคิวของเราเตอร์ยาวเป็นหลายร้อย ms และแพ็กเก็ตเกมก็ต้องรอต่อท้าย (ภายนอก (ภายนอก))
L6 การ์ดเครือข่ายของเซิร์ฟเวอร์
- การซ่อมบำรุงโฮสต์คลาวด์/live migration: เมื่อผู้ให้บริการคลาวด์ซ่อมบำรุงเครื่องจริง (โฮสต์) จะย้าย VM ไปโฮสต์อื่น (live migration) หรือหยุด VM ชั่วคราว ระหว่างนั้นทั้งเซิร์ฟเวอร์จะหยุด และถ้าหยุดนาน การเชื่อมต่อจะขาด (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
L7 OS ของเซิร์ฟเวอร์ (เคอร์เนล)
- บัฟเฟอร์ซ็อกเก็ตของเคอร์เนลไม่พอ: ถ้าบัฟเฟอร์ส่งและรับเล็ก เมื่อทราฟฟิกมาเป็น burst แพ็กเก็ตที่รับทาง UDP จะถูกทิ้ง ส่วนการส่งทาง TCP จะติดเพราะบัฟเฟอร์ไม่มีที่ว่าง (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
- นาฬิการะบบกระโดด (NTP step): ถ้านาฬิกาของเซิร์ฟเวอร์ถูกปรับไปข้างหน้าหรือถอยหลังหลายวินาทีในครั้งเดียว ตัวจับเวลาที่อิงนาฬิการะบบจะทำงานพร้อมกันรวดเดียวหรือหยุดไป (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
L8 ซ็อกเก็ตและโปรโตคอล
- TCP HOL blocking: เพื่อรักษาลำดับข้อมูล TCP จะไม่ส่งแพ็กเก็ตที่มาถึงทีหลังให้เกม จนกว่าจะได้รับแพ็กเก็ตที่หายไปหนึ่งตัวนั้นอีกครั้ง (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- การตั้งค่าการส่งซ้ำของ reliable UDP: ถ้ากฎการส่งซ้ำที่สร้างเองบน UDP ระมัดระวังเกินไป การกู้คืนจะช้า ถ้าดุดันเกินไปก็จะยิ่งทำให้เน็ตอุดตัน (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- อัตราการส่งดิ่งลงเพราะ congestion control: TCP มองว่าแพ็กเก็ตหายคือสัญญาณของความแออัด จึงลดอัตราการส่งลง 30–50% และตอบสนองแบบเดียวกันแม้แพ็กเก็ตหายเพราะ Wi-Fi (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
L9 โปรเซสเกมฝั่งเซิร์ฟเวอร์
- ปริมาณ broadcast พุ่ง: ถ้าส่งการเคลื่อนไหวของผู้เล่นหนึ่งคนไปให้ทุกคนที่มองเห็น จะเกิดอัปเดตที่ต้องส่งเท่ากับจำนวนคนที่รวมตัวยกกำลังสอง (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- การต่อสู้ที่รุมเป้าหมายเดียว (เวิลด์บอส): ถ้าคนหลายร้อยคนตีบอสตัวเดียวพร้อมกัน การคำนวณของบอสตัวนั้นจะกระจุกที่จุดเดียว และข้อมูลการโจมตีจะถูกส่งให้ทุกคนที่มองเห็น (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- spawn ทะลักเมื่อเข้าพื้นที่คนหนาแน่น: ถ้าเทเลพอร์ตเข้าเมืองที่คนแน่น เซิร์ฟเวอร์ต้องส่งรูปลักษณ์ อุปกรณ์ และสถานะของคนหลายร้อยคนที่เพิ่งมองเห็นไปพร้อมกันรวดเดียว (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
L10 หน่วยความจำ
- GC ของเซิร์ฟเวอร์หยุดทั้งระบบ: ระหว่างที่เซิร์ฟเวอร์ Java หรือ C# หยุดทุกเธรดเพื่อเก็บคืน garbage (stop-the-world) ทั้งเซิร์ฟเวอร์จะหยุดชะงักไปด้วย (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
การออกแบบการซิงก์
- เล่นทันทีที่มาถึงโดยไม่มี timestamp: ถ้าไม่ติดเวลาที่เกิดให้อีเวนต์จากเซิร์ฟเวอร์ แล้วเล่นทันทีที่ได้รับ จังหวะการแสดงผลจะไม่สม่ำเสมอตามจิตเตอร์ของเครือข่าย (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))
ปัญหาที่เกิดกับบางคนเท่านั้น
- คนเน็ตช้าขยับแบบกรอเร็วบนจอคนอื่น: อินพุตของคนที่เน็ตไม่ดีจะไปถึงเซิร์ฟเวอร์แบบไม่สม่ำเสมอและมาเป็นกลุ่ม ถ้าเซิร์ฟเวอร์ใช้คำสั่งตามที่ได้รับในแต่ละทิก คนอื่นจะเห็นตัวละครนั้นหยุดแวบแล้วเดินหลายก้าวในทีเดียว (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- อาการกรอเร็วจากเซิร์ฟเวอร์ที่ประมวลผลทันทีที่ได้รับ: บนเซิร์ฟเวอร์ที่ประมวลผลและแจ้งผลทันทีที่แพ็กเก็ตมาถึง การกระทำของคนที่ช้าซึ่งมาถึงเป็นกลุ่มจะถูกรันทันทีต่อเนื่องกัน (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- สิทธิ์ควบคุมมอนสเตอร์อยู่ที่ไคลเอนต์ที่ช้า: บางเกมให้ไคลเอนต์ของผู้เล่นคนหนึ่งที่อยู่ใกล้คำนวณการเคลื่อนที่ของมอนสเตอร์เพื่อลดโหลดเซิร์ฟเวอร์ ถ้าเน็ตของคนนั้นไม่ดี มอนสเตอร์ตัวนั้นจะขยับแปลก ๆ บนจอของทุกคน (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- จำกัดการประมวลผลของหน้าต่างเบื้องหลัง: สำหรับไคลเอนต์ที่เป็นหน้าต่างเบื้องหลัง ตัวเกม เอนจิน และ OS จะลดเฟรมและการประมวลผลลง แพ็กเก็ตที่ได้รับจึงประมวลผลไม่ทันจนกองรอหรือล้น (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))
ต้นเหตุของการส่งซ้ำใน TCP
- แพ็กเก็ตหายช่วงไร้สาย: Wi-Fi และเครือข่ายมือถือจะลองส่งซ้ำในช่วงไร้สายอยู่หลายครั้ง ถ้ายังไม่สำเร็จก็จะทิ้งแพ็กเก็ตนั้น แล้ว TCP จะส่งแพ็กเก็ตที่ถูกทิ้งใหม่หลังจากนั้นพักใหญ่ (ภายนอก (ภายนอก))
- คิวคอขวดล้น (แพ็กเก็ตหายจากความแออัด): จุดที่แคบที่สุดบนเส้นทาง เช่น เราเตอร์, ลิงก์เชื่อมระหว่าง ISP หรือลิงก์ของดาต้าเซ็นเตอร์ เมื่อคิวตรงนั้นเต็ม แพ็กเก็ตที่มาใหม่จะถูกทิ้ง (อินฟราเครือข่าย (ทีมอินฟรา))
- บัฟเฟอร์ตื้นล้นเพราะ burst จากฝั่งส่ง: ถ้าเซิร์ฟเวอร์ส่งอัปเดตของผู้เล่นหลายพันคนออกไปรวดเดียวในทุกทิก บัฟเฟอร์เล็ก ๆ ของสวิตช์หรือขีดจำกัดชั่วขณะของคลาวด์จะล้นภายในไม่ถึง 1 ms และแพ็กเก็ตบางส่วนถูกทิ้ง (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- policer ทิ้งส่วนที่เกิน: แพ็กเกจเน็ตของ ISP, ขีดจำกัดของอินสแตนซ์คลาวด์ และอุปกรณ์ป้องกัน DDoS บางครั้งจะทิ้งแพ็กเก็ตที่เกินความเร็วที่กำหนดทันทีโดยไม่เข้าคิว (อินฟราเครือข่าย (ทีมอินฟรา))
- ข้อผิดพลาดทางกายภาพ (สายเสีย/โมดูลออปติก/คอนเน็กเตอร์): สายที่ชำรุด, คอนเน็กเตอร์ไฟเบอร์ที่มีฝุ่น และโมดูลออปติกที่หมดอายุการใช้งาน ทำให้เกิด bit error และอุปกรณ์จะทิ้งแพ็กเก็ตที่เสียไปเงียบ ๆ (อินฟราเครือข่าย (ทีมอินฟรา))
- duplex ไม่ตรงกัน: ถ้าฝั่งหนึ่งใช้ auto-negotiation แต่อีกฝั่งล็อกความเร็วและ duplex ไว้ ฝั่งหนึ่งจะทำงานแบบ half duplex และทุกครั้งที่มีโหลดจะเกิด collision จนแพ็กเก็ตหาย (อินฟราเครือข่าย (ทีมอินฟรา))
- เครื่องเซิร์ฟเวอร์ฝั่งรับทิ้งแพ็กเก็ต: แพ็กเก็ตมาถึงเซิร์ฟเวอร์แล้ว แต่ถูกทิ้งเพราะ ring buffer ของ NIC (บัฟเฟอร์ที่พักแพ็กเก็ตที่มาถึงไว้ชั่วคราว) ล้น หรือคอร์ที่เคอร์เนลใช้ประมวลผลขาเข้าทำงานเต็ม (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
- อุปกรณ์กลางทางเกินขีดความสามารถ (ไฟร์วอลล์/IPS/ระบบป้องกัน DDoS): ไฟร์วอลล์, อุปกรณ์ป้องกันการบุกรุก (IPS) และอุปกรณ์ป้องกัน DDoS ตรวจแพ็กเก็ตที่ผ่านทีละตัว เมื่อเกินความสามารถในการตรวจ แพ็กเก็ตที่ประมวลผลไม่ทันจะถูกทิ้งตั้งแต่จังหวะนั้น (อินฟราเครือข่าย (ทีมอินฟรา))
- เส้นทางเปลี่ยน/เส้นทาง ECMP ที่เสีย: แพ็กเก็ตจะหายไปในช่วงไม่กี่วินาทีที่เส้นทางอินเทอร์เน็ตเปลี่ยน หรือในการเชื่อมต่อที่ถูกจัดให้วิ่งบนเส้นทางที่เสียจากหลายเส้นทาง ECMP (อินฟราเครือข่าย (ทีมอินฟรา))
- การส่งซ้ำโดยไม่จำเป็นเพราะความหน่วงพุ่ง: แพ็กเก็ตยังอยู่ครบและแค่มาถึงช้ามากชั่วครู่ แต่ถ้าความหน่วงนั้นนานกว่า RTO ฝั่งส่งจะตัดสินว่าหายแล้วส่งซ้ำ (ภายนอก (ภายนอก))
- ค่า RTO ไม่เหมาะกับสภาพแวดล้อม: ถ้าลดค่าต่ำสุดของ RTO มากเกินไป แค่ช้านิดเดียวก็เกิดการส่งซ้ำโดยไม่จำเป็น ส่วนค่าเริ่มต้น (200 ms) ก็นานเกินไปสำหรับเกม ทุกครั้งที่แพ็กเก็ตหายจึงหยุดนาน (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
- thin stream กู้คืนช้า: ถ้าส่งแพ็กเก็ตเล็ก ๆ ห่าง ๆ แบบเกม RTO จะมาถึงก่อนที่ “แพ็กเก็ตที่ตามมา 3 ตัว” จะครบ เมื่อหายเท่ากัน จึงหยุดนานกว่าการส่งข้อมูลปริมาณมากอยู่มาก (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- อุปกรณ์กลางทางตัด TCP option ทิ้ง: ถ้าไฟร์วอลล์หรืออุปกรณ์เร่งความเร็วบางตัวลบหรือแก้ TCP option เมื่อแพ็กเก็ตหายหลายตัว จะกู้คืนได้แค่ตัวเดียวต่อหนึ่งรอบไปกลับ หรือ window (ปริมาณที่ส่งได้ในครั้งเดียว) จะเล็กลงจนช้า (อินฟราเครือข่าย (ทีมอินฟรา))
- zero window (การหยุดที่ดูเหมือนการส่งซ้ำ): ถ้าโปรแกรมฝั่งรับอ่านซ็อกเก็ตไม่ทันจนบัฟเฟอร์เต็ม ฝั่งส่งจะหยุดส่งและส่งแค่ zero window probe ปัญหานี้ไม่ได้อยู่ที่เน็ต (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))
ดูพจนานุกรมอาการในฉบับหลักที่มีภาพ