คู่มือเกมแลค › ต้นเหตุของการส่งซ้ำใน TCP
fast retransmit โดยไม่จำเป็นเพราะแพ็กเก็ตสลับลำดับ Reordering triggers spurious fast retransmit
ID สาเหตุ rt-reorder · ผู้รับผิดชอบหลัก อินฟราเครือข่าย (ทีมอินฟรา) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
เมื่อแพ็กเก็ตสลับลำดับเพราะวิ่งผ่านหลายเส้นทางหรือลิงก์ที่รวมกัน ฝั่งรับจะแจ้งว่า “มีแพ็กเก็ตขาดหาย” ด้วย duplicate ACK และฝั่งส่งจะส่งแพ็กเก็ตที่ไม่ได้หายซ้ำ
ทำไม อุปกรณ์ที่แบ่งเส้นทางเป็นรายแพ็กเก็ต, LAG (การรวมลิงก์) ที่กระจายเป็นรายแพ็กเก็ต และจังหวะที่เส้นทางเปลี่ยน ทำให้ลำดับสลับกัน → ผลคือ แพ็กเก็ตหลังมาถึงก่อน duplicate ACK สะสมครบ 3 ตัว → fast retransmit → บนหน้าจอ แพ็กเก็ตเกมที่วิ่งห่าง ๆ แทบไม่ได้รับผล อัปเดตใหญ่ในที่ที่คนเยอะและการดาวน์โหลดแพตช์ช้าลง และบางครั้งกระตุก
- อาการ
- กระตุก, อินพุตดีเลย์
- ปัจจัย
- จิตเตอร์
- ใครเจอ
- บางพื้นที่/บาง ISP, ทั้งเซิร์ฟเวอร์
- เกิดเมื่อไร
- ตลอดเวลา, ตอนคนแห่มารวมกัน
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก อินฟราเครือข่าย (ทีมอินฟรา) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา)
- งานฝั่งทีมอินฟรา
- เครือข่าย: กระจายเป็นรายการเชื่อมต่อแทนรายแพ็กเก็ต (ใช้ hash ของที่อยู่และพอร์ตกับ ECMP/LAG) เครื่องเซิร์ฟเวอร์/OS: ใช้ RACK (ตัดสินการหายตามเวลา ทนต่อการสลับลำดับ และเมื่อตรวจพบการส่งซ้ำโดยไม่จำเป็นจาก DSACK จะขยายช่วงที่ยอมให้สลับลำดับเองอัตโนมัติ), ตรวจระดับการสลับลำดับที่ Linux ประเมินเองในแต่ละการเชื่อมต่อ (ค่า reordering ใน ss -ti ค่าเริ่มต้น tcp_reordering=3)
- บนกราฟ
- สูงตลอดตั้งแต่แรก · จำนวนครั้งที่ตรวจพบการสลับลำดับ, จำนวน DSACK ที่ได้รับ
- จุดที่ต้องดู
- TcpExtTCPSACKReorder และ TcpExtTCPTSReorder (จำนวนครั้งที่ตรวจพบการสลับลำดับ) กับ TcpExtTCPDSACKRecv ใน nstat ส่วนแต่ละการเชื่อมต่อดู reordering (แสดงเมื่อไม่ใช่ 3) และ reord_seen ใน ss -ti ใน packet capture ใช้ตัวกรอง Wireshark tcp.analysis.out_of_order
- สัญญาณว่าใช่
- ตัวนับการสลับลำดับและ DSACK ขึ้นเรื่อย ๆ ไม่ขึ้นกับช่วงเวลา และค่า reordering ของการเชื่อมต่อที่ผ่านเส้นทางหรืออุปกรณ์หนึ่งสูงกว่า 3 ใน capture ฝั่งรับ แพ็กเก็ตหลังมาก่อน และแพ็กเก็ตก่อนหน้าก็ตามมาในไม่ช้า
- สัญญาณว่าไม่ใช่
- ตัวนับการสลับลำดับไม่ขยับ แต่ TcpExtTCPLostRetransmit เพิ่ม: เป็นแพ็กเก็ตหายจริง ถ้า DSACK เพิ่มเฉพาะจังหวะที่ RTT พุ่ง น่าจะเป็น “การส่งซ้ำโดยไม่จำเป็นเพราะความหน่วงพุ่ง”
- วิธีตรวจ
- ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
แหล่งอ้างอิง
- RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection IETF
ถ้าแบ่งเส้นทางเป็นรายแพ็กเก็ต ลำดับจะสลับ และถ้าแพ็กเก็ตหลังตั้งแต่ 3 ตัวขึ้นไปมาถึงก่อน TCP จะทำ fast retransmit โดยไม่จำเป็น - RFC 2992: Analysis of an Equal-Cost Multi-Path Algorithm IETF
ECMP ที่เลือกเส้นทางจาก hash ของฟิลด์ใน header ที่ใช้แยก flow (กระจายเป็นราย flow) - RFC 5681: TCP Congestion Control IETF
ทำ fast retransmit เมื่อได้รับ duplicate ACK ตัวที่สาม - RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP IETF
RACK ตัดสินการหายตามเวลา จึงทนต่อการสลับลำดับ และเมื่อได้รับ DSACK จะขยายช่วงเวลาที่ยอมให้สลับลำดับ (reo_wnd) - IP Sysctl Linux kernel
tcp_reordering ค่าเริ่มต้น 3 (ปรับอัตโนมัติต่อการเชื่อมต่อได้ถึง tcp_max_reordering), การตั้งค่า RACK ใน tcp_recovery - misc/ss.c iproute2
ss -ti แสดง reordering:ค่า เมื่อค่า reordering ของการเชื่อมต่อต่างจากค่าเริ่มต้น 3 และแสดง reord_seen:จำนวนครั้ง เมื่อเคยเจอการสลับลำดับ - SNMP counter Linux kernel
TcpExtTCPSACKReorder และ TcpExtTCPTSReorder (ตรวจพบการสลับลำดับ), TcpExtTCPDSACKRecv (จำนวน DSACK ที่ได้รับ), TcpExtTCPLostRetransmit (แพ็กเก็ตที่ส่งซ้ำหายอีก) - include/uapi/linux/tcp.h Linux kernel
tcpi_reord_seen ใน tcp_info: จำนวนครั้งที่การเชื่อมต่อเจอการสลับลำดับ - Display Filter Reference: Transmission Control Protocol Wireshark
display filter tcp.analysis.out_of_order
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: ต้นเหตุของการส่งซ้ำใน TCP
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (กระตุก)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง