Sách trắng lag game › Nguyên nhân gốc của truyền lại TCP

Truyền lại nhanh không cần thiết do gói đến sai thứ tự Reordering triggers spurious fast retransmit

ID nguyên nhân rt-reorder · Phụ trách chính Hạ tầng mạng (Đội hạ tầng) · Phối hợp Hạ tầng server (Đội hạ tầng)

Mở thẻ gốc có hình minh họa và thí nghiệm →

Khi đi qua nhiều tuyến hoặc các link được gộp, thứ tự gói tin có thể bị đảo; bên nhận dùng ACK trùng (duplicate ACK) để báo “có gói bị thiếu”, và bên gửi gửi lại cả gói vẫn còn nguyên vẹn.

Vì sao Thiết bị chia tuyến theo từng gói, LAG (gộp link) chia tải theo từng gói, hoặc khoảnh khắc đổi tuyến làm xáo trộn thứ tự → Dẫn đến Gói phía sau đến trước nên dồn đủ 3 ACK trùng → truyền lại nhanh → Trên màn hình Gói game đi lại thưa thớt nên gần như không bị ảnh hưởng. Bản cập nhật trạng thái lớn ở chỗ đông người và việc tải bản cập nhật (patch) bị chậm lại, thỉnh thoảng giật khựng

Triệu chứng

Giật khựng, Trễ thao tác

Yếu tố

Jitter

Ai gặp phải

Một khu vực hoặc nhà mạng, Cả server

Khi nào

Luôn luôn, Khi đông người

Phụ trách

Phụ trách chính Hạ tầng mạng (Đội hạ tầng) · Phối hợp Hạ tầng server (Đội hạ tầng)

Việc cần làm (Đội hạ tầng)

Mạng: chia tải theo kết nối thay vì theo gói (ECMP và LAG dùng hash địa chỉ và cổng). Thiết bị server·OS: dùng RACK (xác định mất gói dựa trên thời gian, chịu được gói sai thứ tự; khi phát hiện truyền lại không cần thiết qua DSACK sẽ tự nới rộng mức chấp nhận sai thứ tự), kiểm tra mức sai thứ tự mà Linux tự ước tính cho từng kết nối (giá trị reordering trong ss -ti, giá trị khởi đầu tcp_reordering=3).

Trên đồ thị

Luôn cao ngay từ đầu · Số lần phát hiện sai thứ tự, số DSACK nhận được

Chỗ cần xem

TcpExtTCPSACKReorder và TcpExtTCPTSReorder (số lần phát hiện sai thứ tự) cùng TcpExtTCPDSACKRecv trong nstat; theo từng kết nối thì xem reordering (chỉ hiển thị khi khác 3) và reord_seen trong ss -ti. Với bản bắt gói, dùng filter Wireshark tcp.analysis.out_of_order

Đúng nếu

counter sai thứ tự và DSACK tăng đều bất kể khung giờ, giá trị reordering của các kết nối đi qua một tuyến hoặc thiết bị nhất định lớn hơn 3. Trong bản bắt gói phía nhận, gói sau đến trước và gói trước cũng đến ngay sau đó

Loại trừ nếu

counter sai thứ tự không đổi mà TcpExtTCPLostRetransmit tăng → mất gói thật. DSACK chỉ tăng vào lúc RTT vọt lên → “Truyền lại không cần thiết do độ trễ tăng vọt”

Cách kiểm tra

Kiểm tra bằng công cụ hạ tầng (không cần code game)

Nguồn

1. RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection IETF
   Chia tuyến theo từng gói làm đảo thứ tự, và nếu từ 3 gói phía sau trở lên đến trước thì TCP truyền lại nhanh một cách không cần thiết
2. RFC 2992: Analysis of an Equal-Cost Multi-Path Algorithm IETF
   ECMP chọn tuyến bằng hash của các trường header dùng để phân biệt luồng (chia tải theo luồng)
3. RFC 5681: TCP Congestion Control IETF
   Truyền lại nhanh ở ACK trùng thứ ba
4. RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP IETF
   RACK xác định mất gói dựa trên thời gian nên chịu được gói sai thứ tự, và khi nhận DSACK thì nới rộng thời gian chấp nhận sai thứ tự (reo_wnd)
5. IP Sysctl Linux kernel
   tcp_reordering khởi đầu là 3 (mỗi kết nối tự điều chỉnh, tối đa đến tcp_max_reordering), cấu hình RACK trong tcp_recovery
6. misc/ss.c iproute2
   ss -ti hiển thị reordering:giá trị khi giá trị reordering của kết nối khác mặc định 3, và reord_seen:số lần nếu kết nối từng gặp gói sai thứ tự
7. SNMP counter Linux kernel
   TcpExtTCPSACKReorder, TcpExtTCPTSReorder (phát hiện sai thứ tự), TcpExtTCPDSACKRecv (số DSACK đã nhận), TcpExtTCPLostRetransmit (gói đã gửi lại lại bị mất)
8. include/uapi/linux/tcp.h Linux kernel
   tcpi_reord_seen trong tcp_info: số lần kết nối gặp gói sai thứ tự
9. Display Filter Reference: Transmission Control Protocol Wireshark
   Bộ lọc hiển thị tcp.analysis.out_of_order

Nguyên nhân nên xem cùng

Cùng tầng: Nguyên nhân gốc của truyền lại TCP

• Mất gói ở chặng không dây
• Tràn hàng đợi ở điểm nghẽn (mất gói do tắc nghẽn)
• Burst gửi làm tràn bộ đệm nhỏ
• Policer bỏ phần vượt mức
• Lỗi vật lý (cáp, module quang, đầu nối hỏng)
• Không khớp chế độ duplex
• Host server nhận bỏ gói tin
• Tường lửa và theo dõi kết nối bỏ gói
• Thiết bị trung gian vượt giới hạn xử lý (tường lửa, IPS, chống DDoS)
• MTU black hole (chỉ gói lớn liên tục bị mất)
• Ánh xạ NAT hoặc bộ cân bằng tải hết hạn giữa chừng kết nối
• Đổi tuyến đường hoặc tuyến ECMP lỗi
• Truyền lại không cần thiết do độ trễ tăng vọt
• ACK đến muộn hoặc bị mất (chiều tải lên bị bão hòa)
• Cấu hình RTO không hợp với môi trường
• Thin stream phục hồi chậm
• Thiết bị trung gian xóa tùy chọn TCP
• Zero window (khoảng dừng dễ nhầm là truyền lại)
• Truyền lại yêu cầu kết nối (SYN)

Nguyên nhân ở tầng khác gây cùng triệu chứng (Giật khựng)

• Frame time vọt lên L1 Tiến trình game phía client
• Thu gom rác (GC) phía client L1 Tiến trình game phía client
• Tải đồng bộ trên main thread và biên dịch shader L1 Tiến trình game phía client
• Ổ lưu trữ chậm khiến streaming asset không theo kịp L1 Tiến trình game phía client
• Tải render khi đông người L1 Tiến trình game phía client
• Bộ đệm nội suy không có hoặc quá ngắn L1 Tiến trình game phía client
• Ngoại suy quá mức (dead reckoning) L1 Tiến trình game phía client
• Fixed timestep chạy bù mất kiểm soát L1 Tiến trình game phía client

Xem thẻ gốc có hình minh họa và thí nghiệm