คู่มือเกมแลค › ค้นหาตามอาการ
ค้าง: 67 สาเหตุและทีมที่ต้องแก้
เรียกอีกอย่างว่า: ภาพนิ่ง, หยุดนิ่ง, ไม่ตอบสนอง
เปิดพจนานุกรมอาการในฉบับหลักที่มีภาพ →
ทุกอย่างบนจอหยุดไปชั่วครู่ (0.5 วินาทีถึงหลายวินาที) แล้วกลับมาขยับต่อ
ทุกคนหยุดนิ่ง มีแค่ตัวละครของเราที่ขยับได้นิดหน่อยตาม prediction หรือวิ่งอยู่กับที่ พอหายค้าง การเคลื่อนไหวที่สะสมไว้จะตามมาพร้อมกันเป็นอาการกรอเร็วหรือวาร์ป
เซิร์ฟเวอร์หยุดทั้งตัว (GC, เดดล็อก, synchronous call), เน็ตขาดไปชั่วครู่ หรือ PC ของเราหยุดทำงานชั่วขณะ
สาเหตุที่ทำให้เกิดอาการนี้
L1 โปรเซสเกมฝั่งไคลเอนต์
- เฟรมไทม์พุ่ง: เฟรมหนึ่งใช้เวลาคำนวณนานกว่าปกติหลายเท่า ภาพบนจอจึงหยุดไปครู่หนึ่ง (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))
- GC ฝั่งไคลเอนต์: ทั้งเกมหยุดระหว่างเก็บคืนหน่วยความจำที่ใช้แล้วทิ้ง (garbage) จุดสังเกตคือกระตุกเป็นจังหวะสม่ำเสมอ (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))
- โหลดแบบ synchronous และคอมไพล์ shader บนเมนเธรด: เกมหยุดเพราะต้องอ่านไฟล์และสร้าง shader ก่อนวาดพื้นที่, มอนสเตอร์ หรือเอฟเฟกต์ที่เพิ่งเห็นเป็นครั้งแรก (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))
- สตอเรจช้าจนสตรีมแอสเซ็ตไม่ทัน: บนสตอเรจช้าอย่าง HDD การอ่าน texture และโมเดลของโอเพนเวิลด์ตามการเคลื่อนที่ไม่ทัน เอนทิตีจึงโผล่ช้า หรือเกมกระตุกระหว่างรออ่านข้อมูล (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))
- การตรวจของโมดูลความปลอดภัยเกม (anti-cheat): โมดูลความปลอดภัยที่ทำงานคู่กับเกมเพื่อกันโปรโกงจะตรวจสอบเป็นระยะ ถ้าการตรวจหนัก หรือ heartbeat (สัญญาณยืนยันว่ายังทำงานอยู่ที่ส่งเป็นระยะ) ที่รับส่งกับเซิร์ฟเวอร์ความปลอดภัยมาช้า เกมจะกระตุกหรือหลุด (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))
L2 OS และอุปกรณ์ฝั่งไคลเอนต์
- สลับ Wi-Fi ↔ LTE/5G: เมื่อเดินออกจากบ้านแล้ว Wi-Fi หลุดและเปลี่ยนไปใช้ LTE หรือ 5G IP address ของเราจะเปลี่ยน การเชื่อมต่อเดิมจึงใช้ไม่ได้ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- หน่วยความจำฝั่งไคลเอนต์ไม่พอและ swap: ถ้าเปิดแท็บเบราว์เซอร์หลายสิบแท็บพร้อมกับเกม OS จะย้ายหน่วยความจำบางส่วนของเกมไปไว้บนดิสก์ (ภายนอก (ภายนอก))
- หน่วยความจำกราฟิก (VRAM) ไม่พอ: ถ้าหน่วยความจำที่ตัวเลือกกราฟิกต้องการมากกว่าหน่วยความจำของการ์ดจอ OS จะย้าย texture ไปไว้ในหน่วยความจำของ PC แล้วดึงกลับมาใหม่ ภาพจึงกระตุก (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))
- โหมดประหยัดพลังงานของ NIC และปัญหาไดรเวอร์: ถ้าการ์ด LAN หรือชิป Wi-Fi เข้าสู่โหมดประหยัดพลังงานระหว่างแพ็กเก็ต จะต้องใช้เวลากว่าจะกลับมาทำงาน (ภายนอก (ภายนอก))
- โปรแกรมโอเวอร์เลย์รบกวน: โปรแกรมแชต, launcher, โปรแกรมอัดจอ และโปรแกรมแสดง FPS จะแทรกเข้าไปในขั้นตอนการเรนเดอร์ของเกม (hooking) เพื่อวาด UI ของตัวเองทับบนจอเกม งานในแต่ละเฟรมจึงเพิ่มขึ้น และบางครั้งก็ชนกับเกมจนภาพหยุดแวบหรือเกมถูกบังคับปิด (ภายนอก (ภายนอก))
L3 เครือข่ายในบ้าน
L4 เส้นทางอินเทอร์เน็ต
- เส้นทาง BGP เปลี่ยนและ converge ใหม่: เมื่อข้อมูลเส้นทางของอินเทอร์เน็ตเปลี่ยน แพ็กเก็ตจะหายในช่วงไม่กี่วินาทีถึงหลายสิบวินาที (บางกรณีหลายนาที) ที่เส้นทางกำลัง converge ใหม่ (อินฟราเครือข่าย (ทีมอินฟรา))
- คุณภาพสายเน็ตแย่: ขั้วต่อหลวม สายเก่า หรือโมเด็มผิดปกติ ทำให้แพ็กเก็ตหายอย่างต่อเนื่องและเน็ตขาดเป็นระยะ (ภายนอก (ภายนอก))
L5 อุปกรณ์เครือข่ายในดาต้าเซ็นเตอร์
- การ failover ของอุปกรณ์เครือข่าย: ระหว่างไม่กี่วินาทีที่เราเตอร์หรือไฟร์วอลล์ตัวหนึ่งเสียแล้วสลับไปใช้อุปกรณ์สำรอง (failover) ทุกคนจะค้างพร้อมกัน (อินฟราเครือข่าย (ทีมอินฟรา))
- MTU ไม่ตรงกัน (เฉพาะแพ็กเก็ตใหญ่ที่หาย): ถ้า MTU (ขนาดที่ส่งได้ในครั้งเดียว) ของช่วงกลางทางลดลง แต่ข้อความแจ้งว่าขนาดเกินถูกบล็อก แพ็กเก็ตใหญ่จะหายไปเรื่อย ๆ (อินฟราเครือข่าย (ทีมอินฟรา))
L6 การ์ดเครือข่ายของเซิร์ฟเวอร์
- การซ่อมบำรุงโฮสต์คลาวด์/live migration: เมื่อผู้ให้บริการคลาวด์ซ่อมบำรุงเครื่องจริง (โฮสต์) จะย้าย VM ไปโฮสต์อื่น (live migration) หรือหยุด VM ชั่วคราว ระหว่างนั้นทั้งเซิร์ฟเวอร์จะหยุด และถ้าหยุดนาน การเชื่อมต่อจะขาด (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
- ปัญหาไดรเวอร์/เฟิร์มแวร์ของ NIC: ระหว่างที่การ์ดหยุดแล้วเริ่มใหม่เพราะบั๊กของไดรเวอร์หรือฟีเจอร์ทำงานผิดพลาด การรับส่งทั้งหมดจะขาด (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
L7 OS ของเซิร์ฟเวอร์ (เคอร์เนล)
- CPU steal (VM): ระหว่างที่เครื่องจริง (ไฮเปอร์ไวเซอร์) ยก CPU time ของ VM ไปให้ VM ตัวอื่นชั่วครู่ (CPU steal) เซิร์ฟเวอร์เกมจะหยุดชะงัก (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
- หยุดชะงักจาก memory reclaim และ compaction: โปรเซสจะหยุดชะงักระหว่างที่ OS ทำ compaction หน่วยความจำเพื่อสร้างเพจขนาดใหญ่ (huge page) หรือเรียกคืนหน่วยความจำให้ว่าง (reclaim) (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
L8 ซ็อกเก็ตและโปรโตคอล
- TCP HOL blocking: เพื่อรักษาลำดับข้อมูล TCP จะไม่ส่งแพ็กเก็ตที่มาถึงทีหลังให้เกม จนกว่าจะได้รับแพ็กเก็ตที่หายไปหนึ่งตัวนั้นอีกครั้ง (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- TCP RTO และ exponential backoff: ทุกครั้งที่การส่งซ้ำล้มเหลวอีก เวลารอจะเพิ่มเป็นสองเท่า การเชื่อมต่อที่ขาดไปแป๊บเดียวจึงกลายเป็นการหยุดยาว (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- การส่งแบบ blocking เพราะไคลเอนต์ช้า: ถ้า send buffer ของผู้เล่นคนหนึ่งที่เน็ตช้าเต็ม แล้วเซิร์ฟเวอร์ส่งแบบ blocking (การส่งที่ฟังก์ชันจะไม่คืนค่าจนกว่าบัฟเฟอร์จะมีที่ว่าง) เธรดของเซิร์ฟเวอร์จะต้องรอผู้เล่นคนนั้นคนเดียว (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- การกระจายของ SO_REUSEPORT ไม่สมดุล: เมื่อหลายโปรเซสแบ่งกันรับพอร์ตเดียวกัน เคอร์เนลจะกำหนดโปรเซสที่รับแต่ละการเชื่อมต่อด้วย hash ของที่อยู่ และไม่เปลี่ยนอีก ถ้าโปรเซสตัวใดหยุด เฉพาะคนที่ถูกจัดให้โปรเซสนั้นจะต้องรอ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- ข้อผิดพลาด WSAECONNRESET บนซ็อกเก็ต UDP ของ Windows: ถ้าเซิร์ฟเวอร์ Windows ส่ง UDP ไปหาไคลเอนต์ที่ออกไปแล้ว จะได้ข้อความแจ้ง “ไม่พบพอร์ต” (ICMP) กลับมา ข้อความนั้นทำให้การเรียกรับครั้งถัดไปจบด้วยข้อผิดพลาด และถ้าโค้ดเซิร์ฟเวอร์ถือว่าข้อผิดพลาดนี้คือซ็อกเก็ตเสีย ทุกคนที่ใช้ซ็อกเก็ตนั้นจะได้รับผลกระทบ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
L9 โปรเซสเกมฝั่งเซิร์ฟเวอร์
- การแย่งล็อก: ถ้าหลายเธรดรอล็อกตัวเดียวเพื่อเขียนข้อมูลเดียวกัน ต่อให้เพิ่มเธรด ก็ทำงานได้ทีละตัวเท่านั้น (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- เดดล็อก: ถ้าสองเธรดต่างรอล็อกที่อีกฝ่ายถืออยู่ ทั้งคู่จะหยุดไปตลอดกาล (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- synchronous call บนเธรดเกม: ถ้ารอการตอบกลับจาก DB หรือการเขียนไฟล์กลางทิก การดำเนินเกมทั้งหมดบนเซิร์ฟเวอร์จะหยุดไปเท่ากับเวลานั้น (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- ตัวจับเวลาทำงานพร้อมกันจำนวนมาก: ถ้าการรีสปอนของมอนสเตอร์ทั้งหมด การหมดอายุของบัฟทั้งหมด และของรางวัลตอนตรงชั่วโมงมารวมในทิกเดียวกัน ทิกนั้นจะหนักขึ้นหลายสิบเท่า (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- thread pool หมด: ถ้า worker thread ที่ประมวลผลงานติดอยู่กับงานช้าทั้งหมด คำขอใหม่จะต้องรอไปเรื่อย ๆ อย่างไม่มีกำหนด (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- ลูปไม่รู้จบ/ลอจิกทำงานไม่หยุด: ถ้าบั๊กทำให้ทิกหนึ่งไม่จบ เซิร์ฟเวอร์จะหยุด และ watchdog จะบังคับรีสตาร์ต (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- spawn ทะลักเมื่อเข้าพื้นที่คนหนาแน่น: ถ้าเทเลพอร์ตเข้าเมืองที่คนแน่น เซิร์ฟเวอร์ต้องส่งรูปลักษณ์ อุปกรณ์ และสถานะของคนหลายร้อยคนที่เพิ่งมองเห็นไปพร้อมกันรวดเดียว (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
L10 หน่วยความจำ
- GC ของเซิร์ฟเวอร์หยุดทั้งระบบ: ระหว่างที่เซิร์ฟเวอร์ Java หรือ C# หยุดทุกเธรดเพื่อเก็บคืน garbage (stop-the-world) ทั้งเซิร์ฟเวอร์จะหยุดชะงักไปด้วย (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- GC pause ของสคริปต์เอนจิน: แม้เซิร์ฟเวอร์จะเขียนด้วย C++ แต่ถ้ารันเควสต์, AI และสกิลด้วยสคริปต์อย่าง Lua ระหว่างที่ GC ของสคริปต์เอนจินทำงาน โซนนั้นจะหยุดชะงัก (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- การจัดสรรหน่วยความจำพุ่ง: ถ้าสร้างออบเจ็กต์ชั่วคราวจำนวนมากระหว่างอีเวนต์ GC จะทำงานบ่อยกว่าปกติมาก (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- หน่วยความจำรั่ว: หน่วยความจำที่ไม่ถูกคืนค่อย ๆ สะสม จนหลายวันต่อมานำไปสู่ GC ทำงานไม่หยุด, สวอป หรือโปรเซสถูกบังคับปิด (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- GC thrashing (heap เหลือที่ว่างไม่พอ): เมื่อข้อมูลที่ยังใช้อยู่ (live data) เข้าใกล้ขีดจำกัดของ heap แม้ GC ทำงานก็แทบไม่มีอะไรให้เก็บคืน GC จึงวนทำงานซ้ำไม่หยุด (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- สวอป: ถ้าหน่วยความจำไม่พอจน OS ย้ายบางส่วนไปไว้บนดิสก์ ทุกครั้งที่ใช้หน่วยความจำส่วนนั้นต้องรอดิสก์ที่ช้ากว่าเกิน 1,000 เท่า (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
L11 ดิสก์
- การเขียน log แบบ synchronous: ถ้าเธรดเกมต้องรอให้ดิสก์เขียนเสร็จทุกครั้งที่เขียน log หนึ่งบรรทัด พอดิสก์ยุ่ง เกมก็หยุดเดินไปด้วย (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- ขีดจำกัด IOPS/คิวดิสก์อิ่มตัว: ถ้าคำขอเกินจำนวนที่ดิสก์ประมวลผลได้ใน 1 วินาที คิวจะยาวขึ้นและดีเลย์พุ่งสูง (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
- lazy loading บนเซิร์ฟเวอร์: ถ้าเซิร์ฟเวอร์อ่านข้อมูลดันเจี้ยนหรือแมพจากดิสก์ตอนที่ถูกขอเป็นครั้งแรก ทุกคนจะหยุดไปตลอดทิกนั้น (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
L12 ฐานข้อมูล
- failover ของ DB: ระหว่างที่ DB หลักล่มและสลับไปใช้ DB สำรอง จะเขียนข้อมูลไม่ได้ และข้อมูลช่วงท้ายที่ยัง replicate ไม่ทันอาจหายไป (อินฟรา DB (ทีมอินฟรา))
- แคชสแตมปีด: ถ้าแคชของข้อมูลยอดนิยมหมดอายุพร้อมกัน คำขอหลายพันรายการจะแห่ไปที่ DB พร้อมกัน (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- คำสั่ง Redis ที่ช้า: Redis ประมวลผลคำสั่งทีละคำสั่ง คำสั่งที่ช้าเพียงคำสั่งเดียวจึงขวางทุกคำขอที่ตามมา (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
L13 สถาปัตยกรรมเซิร์ฟเวอร์และการดูแลระบบ
- ย้ายโซน (ส่งต่อตัวละครข้ามเซิร์ฟเวอร์): เมื่อเข้าพื้นที่หรือดันเจี้ยนอื่น ขั้นตอนส่งข้อมูลตัวละครไปยังเซิร์ฟเวอร์อื่นทำให้เกิดดีเลย์และความล้มเหลว (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- ความล้มเหลวแบบลูกโซ่: เมื่อเซอร์วิสหนึ่งช้าลง เซิร์ฟเวอร์ที่เรียกใช้เซอร์วิสนั้นจะติดอยู่กับการรอคำตอบ จนฟีเจอร์ที่ไม่เกี่ยวข้องก็หยุดทำงานไปด้วย (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- log และระบบมอนิเตอร์โหลดเกิน: เมื่อเกิดเหตุขัดข้อง log จะพุ่งขึ้นมาก และเซิร์ฟเวอร์ที่ส่ง log แบบ synchronous จะยิ่งช้าลงเพราะ log (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
การออกแบบการซิงก์
- lockstep ต้องรอผู้เล่นที่ช้าที่สุด: ในโครงสร้างที่ทุกคนคำนวณเทิร์นเดียวกันไปพร้อมกัน ถ้าอินพุตของคนหนึ่งช้า ทุกคนต้องรอ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- โครงสร้างแบบโฮสต์ (หัวห้อง): ถ้า PC ของผู้เล่นคนหนึ่งทำหน้าที่เป็นเซิร์ฟเวอร์ เน็ตและสเปก PC ของคนนั้นจะกำหนดฟีลการเล่นของทุกคน (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
ปัญหาที่เกิดกับบางคนเท่านั้น
- ข้อมูลของตัวละครบางตัวใหญ่เกินไป: ตัวละครที่มีไอเทมหรือจดหมายสะสมหลายพันชิ้น หรือมีรายชื่อเพื่อน รายชื่อบล็อก และบัฟมากผิดปกติ ต้องโหลดตอนเชื่อมต่อ บันทึก และแจ้งคนรอบข้างมากกว่าคนอื่นหลายเท่า จึงช้าเฉพาะตัวละครนั้นโดยไม่เกี่ยวกับเน็ต (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
ต้นเหตุของการส่งซ้ำใน TCP
- แพ็กเก็ตหายช่วงไร้สาย: Wi-Fi และเครือข่ายมือถือจะลองส่งซ้ำในช่วงไร้สายอยู่หลายครั้ง ถ้ายังไม่สำเร็จก็จะทิ้งแพ็กเก็ตนั้น แล้ว TCP จะส่งแพ็กเก็ตที่ถูกทิ้งใหม่หลังจากนั้นพักใหญ่ (ภายนอก (ภายนอก))
- คิวคอขวดล้น (แพ็กเก็ตหายจากความแออัด): จุดที่แคบที่สุดบนเส้นทาง เช่น เราเตอร์, ลิงก์เชื่อมระหว่าง ISP หรือลิงก์ของดาต้าเซ็นเตอร์ เมื่อคิวตรงนั้นเต็ม แพ็กเก็ตที่มาใหม่จะถูกทิ้ง (อินฟราเครือข่าย (ทีมอินฟรา))
- บัฟเฟอร์ตื้นล้นเพราะ burst จากฝั่งส่ง: ถ้าเซิร์ฟเวอร์ส่งอัปเดตของผู้เล่นหลายพันคนออกไปรวดเดียวในทุกทิก บัฟเฟอร์เล็ก ๆ ของสวิตช์หรือขีดจำกัดชั่วขณะของคลาวด์จะล้นภายในไม่ถึง 1 ms และแพ็กเก็ตบางส่วนถูกทิ้ง (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- policer ทิ้งส่วนที่เกิน: แพ็กเกจเน็ตของ ISP, ขีดจำกัดของอินสแตนซ์คลาวด์ และอุปกรณ์ป้องกัน DDoS บางครั้งจะทิ้งแพ็กเก็ตที่เกินความเร็วที่กำหนดทันทีโดยไม่เข้าคิว (อินฟราเครือข่าย (ทีมอินฟรา))
- ข้อผิดพลาดทางกายภาพ (สายเสีย/โมดูลออปติก/คอนเน็กเตอร์): สายที่ชำรุด, คอนเน็กเตอร์ไฟเบอร์ที่มีฝุ่น และโมดูลออปติกที่หมดอายุการใช้งาน ทำให้เกิด bit error และอุปกรณ์จะทิ้งแพ็กเก็ตที่เสียไปเงียบ ๆ (อินฟราเครือข่าย (ทีมอินฟรา))
- duplex ไม่ตรงกัน: ถ้าฝั่งหนึ่งใช้ auto-negotiation แต่อีกฝั่งล็อกความเร็วและ duplex ไว้ ฝั่งหนึ่งจะทำงานแบบ half duplex และทุกครั้งที่มีโหลดจะเกิด collision จนแพ็กเก็ตหาย (อินฟราเครือข่าย (ทีมอินฟรา))
- เครื่องเซิร์ฟเวอร์ฝั่งรับทิ้งแพ็กเก็ต: แพ็กเก็ตมาถึงเซิร์ฟเวอร์แล้ว แต่ถูกทิ้งเพราะ ring buffer ของ NIC (บัฟเฟอร์ที่พักแพ็กเก็ตที่มาถึงไว้ชั่วคราว) ล้น หรือคอร์ที่เคอร์เนลใช้ประมวลผลขาเข้าทำงานเต็ม (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
- ไฟร์วอลล์/connection tracking ทิ้งแพ็กเก็ต: ไฟร์วอลล์หรือ connection tracking ของ Linux (conntrack คือฟังก์ชันที่บันทึกการเชื่อมต่อที่ผ่านลงในตาราง) จะทิ้งแพ็กเก็ตเมื่อตารางเต็ม หรือเมื่อตัดสินว่าสถานะการเชื่อมต่อไม่ถูกต้อง (อินฟราเครือข่าย (ทีมอินฟรา))
- อุปกรณ์กลางทางเกินขีดความสามารถ (ไฟร์วอลล์/IPS/ระบบป้องกัน DDoS): ไฟร์วอลล์, อุปกรณ์ป้องกันการบุกรุก (IPS) และอุปกรณ์ป้องกัน DDoS ตรวจแพ็กเก็ตที่ผ่านทีละตัว เมื่อเกินความสามารถในการตรวจ แพ็กเก็ตที่ประมวลผลไม่ทันจะถูกทิ้งตั้งแต่จังหวะนั้น (อินฟราเครือข่าย (ทีมอินฟรา))
- MTU black hole (เฉพาะแพ็กเก็ตใหญ่ที่หายซ้ำแล้วซ้ำอีก): เมื่อขนาดที่ช่วงกลางทางรับได้เล็กลง แต่ข้อความแจ้งว่า “ใหญ่เกินไป” (ICMP) ถูกบล็อก แพ็กเก็ตใหญ่จะหายไปทุกครั้งไม่ว่าจะส่งซ้ำกี่รอบ (อินฟราเครือข่าย (ทีมอินฟรา))
- mapping ของ NAT/โหลดบาลานเซอร์หมดอายุกลางการเชื่อมต่อ: ถ้าอุปกรณ์กลางทางลบ mapping (รายการที่บันทึกว่าจะส่งต่อการเชื่อมต่อนี้ไปที่ไหน) ของการเชื่อมต่อที่ idle แพ็กเก็ตถัดไปที่ส่งจะไปไม่ถึง การเชื่อมต่อจะส่งซ้ำวนไปจนหลุด หรืออุปกรณ์ตอบกลับด้วยการปฏิเสธการเชื่อมต่อ (RST) แล้วหลุดทันที (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))
- เส้นทางเปลี่ยน/เส้นทาง ECMP ที่เสีย: แพ็กเก็ตจะหายไปในช่วงไม่กี่วินาทีที่เส้นทางอินเทอร์เน็ตเปลี่ยน หรือในการเชื่อมต่อที่ถูกจัดให้วิ่งบนเส้นทางที่เสียจากหลายเส้นทาง ECMP (อินฟราเครือข่าย (ทีมอินฟรา))
- การส่งซ้ำโดยไม่จำเป็นเพราะความหน่วงพุ่ง: แพ็กเก็ตยังอยู่ครบและแค่มาถึงช้ามากชั่วครู่ แต่ถ้าความหน่วงนั้นนานกว่า RTO ฝั่งส่งจะตัดสินว่าหายแล้วส่งซ้ำ (ภายนอก (ภายนอก))
- ค่า RTO ไม่เหมาะกับสภาพแวดล้อม: ถ้าลดค่าต่ำสุดของ RTO มากเกินไป แค่ช้านิดเดียวก็เกิดการส่งซ้ำโดยไม่จำเป็น ส่วนค่าเริ่มต้น (200 ms) ก็นานเกินไปสำหรับเกม ทุกครั้งที่แพ็กเก็ตหายจึงหยุดนาน (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
- thin stream กู้คืนช้า: ถ้าส่งแพ็กเก็ตเล็ก ๆ ห่าง ๆ แบบเกม RTO จะมาถึงก่อนที่ “แพ็กเก็ตที่ตามมา 3 ตัว” จะครบ เมื่อหายเท่ากัน จึงหยุดนานกว่าการส่งข้อมูลปริมาณมากอยู่มาก (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
- อุปกรณ์กลางทางตัด TCP option ทิ้ง: ถ้าไฟร์วอลล์หรืออุปกรณ์เร่งความเร็วบางตัวลบหรือแก้ TCP option เมื่อแพ็กเก็ตหายหลายตัว จะกู้คืนได้แค่ตัวเดียวต่อหนึ่งรอบไปกลับ หรือ window (ปริมาณที่ส่งได้ในครั้งเดียว) จะเล็กลงจนช้า (อินฟราเครือข่าย (ทีมอินฟรา))
- zero window (การหยุดที่ดูเหมือนการส่งซ้ำ): ถ้าโปรแกรมฝั่งรับอ่านซ็อกเก็ตไม่ทันจนบัฟเฟอร์เต็ม ฝั่งส่งจะหยุดส่งและส่งแค่ zero window probe ปัญหานี้ไม่ได้อยู่ที่เน็ต (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))
ดูพจนานุกรมอาการในฉบับหลักที่มีภาพ