한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

คู่มือเกมแลค › L9 โปรเซสเกมฝั่งเซิร์ฟเวอร์

แพตช์ทำให้รูปแบบทราฟฟิกเปลี่ยน Patch changes traffic pattern

ID สาเหตุ sp-patch-traffic · ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา), อินฟราเครือข่าย (ทีมอินฟรา)

เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →

ถ้าคอนเทนต์ เอฟเฟกต์ หรือรายการที่ต้องซิงก์ใหม่ทำให้ขนาดและความถี่ของแพ็กเก็ตเพิ่ม เซิร์ฟเวอร์ที่เคยลื่นจะเริ่มชนขีดจำกัด MTU แบนด์วิดท์ และจำนวนแพ็กเก็ตหลังลงแพตช์

ทำไม แพตช์เพิ่มเอฟเฟกต์สกิล รายการที่ต้องซิงก์ หรือข้อมูลไอเทมใหม่ แพ็กเก็ตจึงใหญ่ขึ้นหรือถี่ขึ้น → ผลคือ แพ็กเก็ตใหญ่เกิน MTU จนถูกแบ่งชิ้น และปริมาณที่เพิ่มขึ้นไปชนแบนด์วิดท์ ขีดจำกัด PPS ของคลาวด์ และ send buffer → บนหน้าจอ ตั้งแต่ลงแพตช์ ที่ที่คนเยอะมีอาการวาร์ป สกิลไม่ออก และอินพุตดีเลย์ ฝั่งอินฟราไม่ได้เปลี่ยนอะไร แต่แพ็กเก็ตหายเพิ่มขึ้น

อาการ
วาร์ป, กดไม่ติด/โรลแบ็ค, อินพุตดีเลย์
ปัจจัย
แพ็กเก็ตหาย, ความหน่วง
ใครเจอ
ทั้งเซิร์ฟเวอร์, บางจุด/บางแชนแนล, บางพื้นที่/บาง ISP
เกิดเมื่อไร
ตอนคนแห่มารวมกัน, ช่วงพีคหัวค่ำ, ตลอดเวลา
ผู้รับผิดชอบ
ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา), อินฟราเครือข่าย (ทีมอินฟรา)
งานฝั่งทีมพัฒนาเกม
แบ่งแพ็กเก็ตเองให้ไม่เกิน 1,200 ไบต์, รายการซิงก์ใหม่ให้ส่งเฉพาะส่วนที่เปลี่ยนและลดความถี่ตามระยะห่างและความสำคัญ, ก่อน deploy ให้เทียบแพ็กเก็ตและไบต์ต่อวินาทีต่อผู้เล่นและขนาดแพ็กเก็ตใหญ่สุดกับบิลด์ก่อนหน้าบนเซิร์ฟเวอร์ทดสอบ, ใส่เวอร์ชันบิลด์ไว้ในเมตริกทราฟฟิก
งานฝั่งทีมอินฟรา
เครื่องเซิร์ฟเวอร์/OS: ทำเครื่องหมายเวลา deploy บนกราฟ และเทียบแพ็กเก็ตและไบต์ต่อวินาทีต่อผู้เล่นกับขนาดแพ็กเก็ตเฉลี่ยก่อนและหลัง deploy, ตั้ง alert ตัวนับเกินขีดจำกัดของอินสแตนซ์, ถ้าจำเป็นให้ใช้อินสแตนซ์ที่ใหญ่ขึ้น เครือข่าย: ตรวจขีดความสามารถของไฟร์วอลล์ โหลดบาลานเซอร์ และอุปกรณ์ป้องกัน DDoS และดูว่าบล็อก fragment หรือไม่
ตัวเลขที่ควรรู้
แพ็กเก็ต UDP ที่ไม่เกิน 1,200 ไบต์ถือว่าปลอดภัย path MTU ของอินเทอร์เน็ตปกติคือ 1,500 ไบต์ และจะเล็กลงเมื่อผ่าน tunnel (ถ้าเป็น GRE tunnel คือ 1,476 ไบต์) แพ็กเก็ตที่เกิน path MTU จะถูกแบ่งชิ้นหรือถูกทิ้ง และแพ็กเก็ตที่ถูกแบ่งชิ้นจะเสียทั้งหมดแม้ fragment หายไปแค่ชิ้นเดียว ถ้าแพ็กเก็ตต่อวินาทีต่อผู้เล่นเพิ่ม 20% ทั้งเซิร์ฟเวอร์ก็เพิ่ม 20% อินสแตนซ์ที่ใช้อยู่ใกล้ขีดจำกัดจะล้นทันที
บนกราฟ
ขึ้นเป็นขั้นบันไดจากจุดหนึ่ง · แพ็กเก็ตและไบต์ต่อวินาทีต่อผู้เล่น, ขนาดแพ็กเก็ตเฉลี่ย
จุดที่ต้องดู
แพ็กเก็ตและไบต์ต่อวินาทีของ NIC เซิร์ฟเวอร์ (rxpck/s, txpck/s, rxkB/s และ txkB/s จาก sar -n DEV, บน EC2 คือ NetworkPacketsOut และ NetworkOut) หารด้วยจำนวนผู้เล่นออนไลน์พร้อมกัน แล้วเทียบก่อนและหลังเวลา deploy ขนาดแพ็กเก็ตเฉลี่ยคือไบต์ ÷ แพ็กเก็ต ส่วนการกระจายขนาด ให้ใช้สถิติ Packet Lengths ของ Wireshark กับ packet capture
สัญญาณว่าใช่
ตั้งแต่หลัง deploy แพ็กเก็ตและไบต์ต่อผู้เล่นหรือขนาดแพ็กเก็ตเฉลี่ยขึ้นหนึ่งขั้นแล้วอยู่ระดับนั้น และตั้งแต่เวลาเดียวกัน จำนวน fragment ที่เซิร์ฟเวอร์สร้าง (fragcrt/s ของ sar -n IP) หรือตัวนับเกินขีดจำกัดของอินสแตนซ์ (pps_allowance_exceeded และ bw_out_allowance_exceeded ของ AWS ENA) เพิ่มขึ้น
สัญญาณว่าไม่ใช่
รูปแบบทราฟฟิกก่อนและหลัง deploy เหมือนกัน แต่มีแค่ความหน่วงและแพ็กเก็ตหายที่เพิ่มขึ้น: ให้ดูการเปลี่ยนแปลงฝั่งอินฟราในเวลาเดียวกัน (คอนฟิก, เส้นทาง, อุปกรณ์, การอัปเดต OS หรือเคอร์เนล)
วิธีตรวจ
ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
รายละเอียดเพิ่มเติม
เมื่อมีผู้เล่นแจ้งว่า “ก่อนลงแพตช์ยังเล่นได้ปกติ” นี่คือสาเหตุฝั่งเกมที่ต้องตรวจก่อนพร้อมกับการเปลี่ยนแปลงฝั่งอินฟรา ต่อให้แพตช์โน้ตไม่ได้ระบุการเปลี่ยนแปลงด้านเครือข่าย เอฟเฟกต์หรือรายการซิงก์ใหม่เพียงอย่างเดียวก็ถูกคูณด้วยคนหลายร้อยคนในที่ที่คนเยอะ จุดที่ทราฟฟิกที่เพิ่มขึ้นไปชนขีดจำกัดจริงอยู่ในสาเหตุ “IP fragmentation ของแพ็กเก็ต UDP”, “เกินขีดจำกัด PPS ของคลาวด์”, “แบนด์วิดท์ NIC เต็ม”, “บัฟเฟอร์ซ็อกเก็ตของเคอร์เนลไม่พอ” และ “อุปกรณ์กลางทางเกินขีดความสามารถ (ไฟร์วอลล์/IPS/ระบบป้องกัน DDoS)” ส่วนสาเหตุนี้คือกรณีที่จุดเริ่มต้นที่ทำให้ชนขีดจำกัดเหล่านั้นคือแพตช์เกม จึงควรลดทราฟฟิกที่เพิ่มขึ้นจากแพตช์ก่อนจะขยายขีดจำกัด ถ้าอัปเดต OS หรือเคอร์เนลในเวลาเดียวกันด้วย ให้แยกจาก “ประสิทธิภาพเปลี่ยนไปหลังอัปเดต OS/เคอร์เนล/ไดรเวอร์/เฟิร์มแวร์” โดยดูว่าทราฟฟิกต่อผู้เล่นเปลี่ยนหรือไม่

แหล่งอ้างอิง

  1. RFC 8085: UDP Usage Guidelines IETF
    แอป UDP ไม่ควรส่ง datagram ที่ใหญ่กว่า path MTU (SHOULD NOT), ถ้า fragment หายหนึ่งชิ้นจะเสียแพ็กเก็ตที่ถูกแบ่งชิ้นทั้งหมด และ NAT หรือไฟร์วอลล์บางตัวทิ้ง fragment ทั้งหมด
  2. RFC 8899: Packetization Layer Path MTU Discovery for Datagram Transports IETF
    แนะนำ 1,200 ไบต์เป็นขนาดปลอดภัยพื้นฐาน (BASE_PLPMTU) สำหรับการส่งแบบ datagram เช่น UDP
  3. Maximum transmission unit and maximum segment size Cloudflare
    path MTU ของอินเทอร์เน็ต 1,500, ผ่าน GRE tunnel 1,476
  4. Monitor network performance for ENA settings on your EC2 instance AWS
    pps_allowance_exceeded และ bw_out_allowance_exceeded: จำนวนแพ็กเก็ตที่ถูกพักในคิวหรือถูกทิ้งเพราะเกินขีดจำกัด PPS หรือแบนด์วิดท์ขาออกของอินสแตนซ์
  5. sar(1) — Linux manual page sysstat
    rxpck/s และ txpck/s (แพ็กเก็ตต่อวินาที) และ rxkB/s และ txkB/s (KB ต่อวินาที) ใน sar -n DEV, fragcrt/s (IP fragment ที่สร้างต่อวินาที, ipFragCreates) ใน sar -n IP
  6. CloudWatch metrics that are available for your instances AWS
    NetworkPacketsOut (จำนวนแพ็กเก็ตที่อินสแตนซ์ส่งออกทาง network interface ทั้งหมด) และ NetworkOut (จำนวนไบต์ที่ส่ง)
  7. 8.7. Packet Lengths Wireshark
    แบ่งแพ็กเก็ตที่ดักจับไว้ตามช่วงความยาว แล้วแสดงจำนวน ค่าเฉลี่ย ค่าต่ำสุด และค่าสูงสุดของแต่ละช่วง

สาเหตุที่ควรดูประกอบ

ชั้นเดียวกัน: L9 โปรเซสเกมฝั่งเซิร์ฟเวอร์

สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (วาร์ป)

ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง