คู่มือเกมแลค › ต้นเหตุของการส่งซ้ำใน TCP
เส้นทางเปลี่ยน/เส้นทาง ECMP ที่เสีย Route change / bad ECMP member
ID สาเหตุ rt-path · ผู้รับผิดชอบหลัก อินฟราเครือข่าย (ทีมอินฟรา) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม), ภายนอก (ภายนอก)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
แพ็กเก็ตจะหายไปในช่วงไม่กี่วินาทีที่เส้นทางอินเทอร์เน็ตเปลี่ยน หรือในการเชื่อมต่อที่ถูกจัดให้วิ่งบนเส้นทางที่เสียจากหลายเส้นทาง ECMP
ทำไม BGP คำนวณเส้นทางใหม่ หรืออุปกรณ์/ลิงก์ของเส้นทางหนึ่งในหลายเส้นทาง (ECMP, LAG) เสีย → ผลคือ แพ็กเก็ตหายชั่วคราวระหว่างสลับเส้นทาง หรือเฉพาะการเชื่อมต่อที่วิ่งบนเส้นทางนั้นหายอยู่ตลอด → บนหน้าจอ จู่ ๆ ก็ค้างไปไม่กี่วินาทีแล้วตามด้วยอาการกรอเร็ว หรือ “เชื่อมต่อใหม่แล้วดีขึ้น” (ถูกจัดไปเส้นทางอื่น)
- อาการ
- ค้าง, กรอเร็ว, วาร์ป
- ปัจจัย
- แพ็กเก็ตหาย
- ใครเจอ
- บางพื้นที่/บาง ISP
- เกิดเมื่อไร
- สุ่มเป็นครั้งคราว
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก อินฟราเครือข่าย (ทีมอินฟรา) · ร่วมกับ พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม), ภายนอก (ภายนอก)
- งานฝั่งทีมพัฒนาเกม
- เก็บสถิติการส่งซ้ำต่อการเชื่อมต่อ (TCP_INFO) ไว้เพื่อดึง IP, พอร์ต และเวลาของคนที่เจอปัญหาได้, อย่าตัดการเชื่อมต่อที่หยุดไปไม่กี่วินาทีทันที
- งานฝั่งทีมอินฟรา
- มอนิเตอร์อัตราการส่งซ้ำแยกตามพื้นที่/ISP, ตรวจว่าเชื่อมต่อใหม่แล้วเส้นทางเปลี่ยนหรือไม่, จัดหาลิงก์จากหลาย ISP, ตรวจหาลิงก์ที่เสียในเส้นทาง ECMP/LAG ของอุปกรณ์เรา, วัดเส้นทางด้วยพอร์ต TCP เดียวกับเกม (ใช้ mtr --tcp --port เพราะเส้นทางถูกกำหนดจากที่อยู่และพอร์ต ping ทั่วไปจึงอาจวิ่งไปอีกเส้นทางและดูปกติ)
- งานฝั่งภายนอก
- รายงานเส้นทางที่เสียให้ ISP โดยแนบผลวัดเส้นทางด้วยพอร์ต TCP เดียวกับเกมและผลเทียบก่อน/หลังเชื่อมต่อใหม่
- บนกราฟ
- ขึ้นเป็นขั้นบันไดจากจุดหนึ่ง · RTT (ปิง), อัตราการส่งซ้ำแยกตามพื้นที่/ISP
- จุดที่ต้องดู
- รวมการส่งซ้ำแยกตามการเชื่อมต่อด้วย bcc tcpretrans -c เพื่อดึงที่อยู่และพอร์ตของผู้เล่นที่เจอปัญหา แล้วรัน mtr ด้วยพอร์ต TCP เดียวกับเกม (mtr -T -P PORT) ทั้งจากเซิร์ฟเวอร์ไปหาผู้เล่นและจากผู้เล่นมาหาเซิร์ฟเวอร์แล้วเทียบกัน เทียบผลก่อนและหลังเชื่อมต่อใหม่ด้วย
- สัญญาณว่าใช่
- ตั้งแต่จุดเวลาหนึ่ง RTT ของพื้นที่หรือ ISP หนึ่งเปลี่ยนเป็นขั้นบันไดและแพ็กเก็ตหายกระจุกอยู่ไม่กี่วินาที หรือแม้ใน ISP เดียวกัน มีเพียงบางการเชื่อมต่อ (คู่ที่อยู่/พอร์ต) ที่ส่งซ้ำอยู่ตลอดและดีขึ้นเมื่อเชื่อมต่อใหม่ บางครั้ง ping ธรรมดาดูปกติ แต่เห็นแพ็กเก็ตหายเฉพาะใน TCP mtr
- สัญญาณว่าไม่ใช่
- ทุกการเชื่อมต่อของ ISP นั้นแย่ลงพร้อมกันช่วงพีคหัวค่ำ: น่าจะเป็น “คิวคอขวดล้น” ถ้าแย่อยู่คนเดียวและแพ็กเก็ตหายตั้งแต่ ping ไปถึงเราเตอร์ น่าจะเป็น “แพ็กเก็ตหายช่วงไร้สาย”
- วิธีตรวจ
- ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
- กรณีจริง
- Cloudflare 2020: คอนฟิกแบ็กโบนของ Cloudflare ผิดพลาด ทำให้ทราฟฟิกบางเมืองหายไป
แหล่งอ้างอิง
- RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection IETF
ใน multipath ผลจากเครื่องมือวินิจฉัยอย่าง ping และ traceroute เชื่อถือได้ยาก พร้อมอธิบายวิธีล็อกเส้นทางด้วยการ hash flow - RFC 2992: Analysis of an Equal-Cost Multi-Path Algorithm IETF
ECMP เลือกเส้นทางถัดไปจาก hash ของฟิลด์ใน header ที่ใช้แยก flow (flow เดียวกันไปเส้นทางเดียวกัน) - tcp(7) — Linux manual page Linux man-pages
TCP_INFO: ดึงสถานะรายซ็อกเก็ต (struct tcp_info) - mtr(8) manual page source mtr
-T (--tcp) ใช้ TCP SYN แทน ICMP, -P (--port) ระบุพอร์ตปลายทาง - Demonstrations of tcpretrans, the Linux eBPF/bcc version IO Visor
แสดงที่อยู่และพอร์ตของอีกฝั่งหนึ่งบรรทัดต่อการส่งซ้ำแต่ละครั้ง และ -c สรุปจำนวนการส่งซ้ำแยกตาม flow
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: ต้นเหตุของการส่งซ้ำใน TCP
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (ค้าง)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง