คู่มือเกมแลค › L5 อุปกรณ์เครือข่ายในดาต้าเซ็นเตอร์
connection tracking ของ security group บนคลาวด์หมดอายุ Cloud security group connection tracking timeout
ID สาเหตุ dc-cloud-conntrack · ผู้รับผิดชอบหลัก อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา) · ร่วมกับ พัฒนาไคลเอนต์ (ทีมพัฒนาเกม), พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
ไฟร์วอลล์ที่ผูกกับเซิร์ฟเวอร์บนคลาวด์ (security group) ก็ติดตามการเชื่อมต่อเช่นกัน และรายการที่ติดตามของการเชื่อมต่อที่ idle จะหมดอายุหลังเวลาที่กำหนด แม้เป็นเซิร์ฟเวอร์ที่ผู้เล่นเชื่อมต่อตรงโดยไม่มีโหลดบาลานเซอร์ ผู้เล่นที่อยู่เฉย ๆ ก็อาจหลุดได้
ทำไม security group ถูกตั้งค่าในแบบที่ติดตามการเชื่อมต่อของเกม (อนุญาตเฉพาะบาง IP, จำกัดกฎขาออก, ผ่าน NLB ฯลฯ) → ผลคือ รายการที่ติดตามของการเชื่อมต่อที่ idle อยู่พักหนึ่งหมดอายุ แล้ว security group ทิ้งแพ็กเก็ตที่มาหลังจากนั้นเงียบ ๆ → บนหน้าจอ กลับมาขยับหลังจากไม่อยู่หน้าจอ แล้วไม่มีการตอบสนองจนหลุด โปรแกรมเซิร์ฟเวอร์ไม่รู้ตัวอยู่นาน
- อาการ
- หลุด
- ปัจจัย
- แพ็กเก็ตหาย
- ใครเจอ
- เราคนเดียว, ทั้งเซิร์ฟเวอร์
- เกิดเมื่อไร
- หลังอยู่เฉย ๆ สักพัก
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา) · ร่วมกับ พัฒนาไคลเอนต์ (ทีมพัฒนาเกม), พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
- งานฝั่งทีมพัฒนาเกม
- ไคลเอนต์: ส่ง heartbeat ทุกช่วงไม่เกินครึ่งหนึ่งของ idle timeout ที่สั้นที่สุด (ถ้า TCP 350 วินาที ก็ไม่เกิน 175 วินาที ถ้า UDP stream 180 วินาที ก็ไม่เกิน 90 วินาที), เชื่อมต่อใหม่อัตโนมัติเมื่อหลุด เซิร์ฟเวอร์: ตอบ heartbeat และถ้าไม่ได้รับตามเวลาที่กำหนดให้เก็บกวาดการเชื่อมต่อก่อน, ใช้ session token รับต่อ
- งานฝั่งทีมอินฟรา
- ตรวจเวลา connection tracking ของอินสแตนซ์ (TcpEstablishedTimeout) และเพิ่มถ้าจำเป็น (UDP สูงสุด 180 วินาที จึงเพิ่มไม่ได้), ทบทวนการตั้ง security group แบบที่ไม่เกิดการติดตาม (พอร์ตเกมอนุญาตทุก IP, กฎขาออกอนุญาตทั้งหมด ส่วนการเชื่อมต่อที่ผ่าน NLB ยังถูกติดตามอยู่ดี), ทดสอบ idle เมื่อย้ายไปอินสแตนซ์รุ่นใหม่
- ตัวเลขที่ควรรู้
- สำหรับ AWS อินสแตนซ์ประเภท Nitro v6 จะลบรายการที่ติดตามของการเชื่อมต่อ TCP ที่ idle หลัง 350 วินาทีเป็นค่าเริ่มต้น (ประเภทอื่น 5 วัน) ส่วน UDP ค่าเริ่มต้นคือ 180 วินาทีสำหรับ flow ที่มีคำขอและการตอบกลับไปมาหลายครั้ง (stream) และ 30 วินาทีสำหรับ flow ที่ไปทางเดียวหรือมีคำขอและการตอบกลับแค่ครั้งเดียว
- บนกราฟ
- การเชื่อมต่อหลุดพร้อมกัน · จำนวนครั้งที่หลุด, ระยะเวลา idle ก่อนหลุด
- จุดที่ต้องดู
- ตรวจการตั้งเวลา connection tracking ของอินสแตนซ์และกฎของ security group (ว่าเป็นแบบที่เกิดการติดตามหรือไม่) แล้วรวบรวมระยะเวลา idle ของการเชื่อมต่อที่หลุด ทันทีหลังหลุด ใช้ ss -tnoi บนเซิร์ฟเวอร์ดูว่าการเชื่อมต่อนั้นยังเป็น ESTABLISHED ตัวจับเวลาส่งซ้ำ (timer:(on,…)) ทำงานอยู่ และ backoff เพิ่มขึ้นหรือไม่
- สัญญาณว่าใช่
- ระยะเวลา idle ของการเชื่อมต่อที่หลุดกระจุกอยู่หลัง TCP 350 วินาที, UDP stream 180 วินาที หรือ UDP ทางเดียว 30 วินาทีพอดี และซ็อกเก็ตฝั่งเซิร์ฟเวอร์ยังเป็น ESTABLISHED โดยไม่รู้ว่าการเชื่อมต่อขาดไปแล้ว (ถ้าเซิร์ฟเวอร์มีข้อมูลต้องส่ง ก็จะส่งซ้ำวนไปเรื่อย ๆ)
- สัญญาณว่าไม่ใช่
- ถ้า security group ตั้งแบบที่ไม่ติดตาม (พอร์ตเกมอนุญาตทุก IP, กฎขาออกอนุญาตทั้งหมด, ไม่ผ่าน NLB) ก็ไม่ใช่สาเหตุนี้ ถ้าผ่าน NLB ให้เทียบค่ากับ “idle timeout ของโหลดบาลานเซอร์”
- วิธีตรวจ
- ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
แหล่งอ้างอิง
- Amazon EC2 security group connection tracking AWS
ค่าเริ่มต้นของการติดตาม TCP ที่ idle คือ 350 วินาที (Nitro v6, ประเภทอื่น 432,000 วินาที=5 วัน), UDP ทางเดียว 30 วินาที และ stream 180 วินาที (สูงสุด 180), ถ้ากฎอนุญาตทุก IP จะไม่ติดตาม, การเชื่อมต่อที่ผ่าน NLB ถูกติดตามเสมอ - Update the TCP idle timeout for your Network Load Balancer listener AWS
ถ้า idle timeout ของ NLB ยาวกว่าเวลา connection tracking ของอินสแตนซ์ปลายทาง ฝั่งอินสแตนซ์จะทิ้งสถานะการเชื่อมต่อเงียบ ๆ ไปก่อน - ss(8) — Linux manual page iproute2
timer:(on,…) ของ -o คือตัวจับเวลาส่งซ้ำ ส่วน backoff ของ -i คือจำนวนครั้งที่เพิ่มเวลารอส่งซ้ำเป็นสองเท่า
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: L5 อุปกรณ์เครือข่ายในดาต้าเซ็นเตอร์
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (หลุด)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง