Idle timeout của bộ cân bằng tải Load balancer idle timeout

ID nguyên nhân dc-lb-idle · Phụ trách chính Hạ tầng mạng (Đội hạ tầng) · Phối hợp Phát triển client (Đội phát triển game), Phát triển server (Đội phát triển game)

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

Bộ cân bằng tải xóa kết nối nhàn rỗi sau một khoảng thời gian nhất định. Game vẫn coi là kết nối còn đó cho đến lúc bị mất kết nối.

Vì sao Người chơi một lúc không gửi gói nào (đang ở cửa sổ chat, rời máy) → Dẫn đến Bộ cân bằng tải dọn kết nối nhàn rỗi (giá trị mặc định thường gặp là 60–350 giây) → Trên màn hình Mất kết nối ngay khi di chuyển lại

Triệu chứng: Mất kết nối
Yếu tố: Mất gói
Ai gặp phải: Chỉ mình tôi, Cả server
Khi nào: Sau khi để yên một lúc
Phụ trách: Phụ trách chính Hạ tầng mạng (Đội hạ tầng) · Phối hợp Phát triển client (Đội phát triển game), Phát triển server (Đội phát triển game)
Việc cần làm (Đội phát triển game): Client: gửi heartbeat với khoảng cách không quá một nửa idle timeout ngắn nhất (nếu đứng sau ALB 60 giây thì tối đa 30 giây), mất kết nối thì tự động kết nối lại. Server: phản hồi heartbeat, nếu một thời gian không nhận được thì chủ động dọn kết nối trước, dùng session token để nối tiếp phiên.
Việc cần làm (Đội hạ tầng): Kiểm tra idle timeout của các bộ cân bằng tải trên tuyến đường rồi chia sẻ với đội phát triển game, tăng lên nếu cần.
Con số tham khảo: Giá trị mặc định: AWS ALB là 60 giây, NLB là 350 giây với TCP và 120 giây với UDP, Azure Load Balancer là 4 phút với TCP. Giá trị TCP của ALB và NLB có thể đổi, nhưng 120 giây UDP của NLB thì không. Khi hết thời gian, ALB đóng cả kết nối phía server, còn NLB xóa âm thầm nên dễ để lại kết nối mà server không hề biết.
Trên đồ thị: Rớt kết nối hàng loạt · Số lần mất kết nối, thời gian nhàn rỗi trước khi bị ngắt
Chỗ cần xem: Kiểm tra giá trị cấu hình idle timeout của bộ cân bằng tải trên tuyến đường, và gom thời gian từ gói cuối cùng tới lúc bị ngắt của từng kết nối đã mất. Với AWS NLB, xem thêm TCP_ELB_Reset_Count (số RST do bộ cân bằng tải gửi) trên CloudWatch
Đúng nếu: thời gian nhàn rỗi của các kết nối bị ngắt dồn ngay sau giá trị cấu hình (ALB 60 giây, NLB TCP 350 giây…), và tái hiện được khi để yên lâu hơn thời gian đó rồi mới di chuyển. Với NLB, TCP_ELB_Reset_Count tăng vào thời điểm đó
Loại trừ nếu: bị ngắt không liên quan tới thời gian nhàn rỗi → không phải nguyên nhân này; server nhận kết nối trực tiếp không qua bộ cân bằng tải mà vẫn dồn quanh 350 giây → xem “Hết hạn theo dõi kết nối của security group trên cloud”; nằm ở phía router nhà người chơi → xem “Ánh xạ NAT hết hạn”
Cách kiểm tra: Kiểm tra bằng công cụ hạ tầng (không cần code game)

Nguồn

Edit attributes for your Application Load Balancer AWS
Idle timeout của ALB mặc định 60 giây (1–4.000 giây); nếu kết nối phía client hoặc phía target im lặng trong khoảng này, bộ cân bằng tải đóng kết nối
Network Load Balancers AWS
Idle timeout TCP của NLB mặc định 350 giây (60–6.000 giây); quá thời gian thì chỉ ngừng theo dõi, sau đó nếu có dữ liệu đến thì gửi RST; luồng UDP 120 giây không đổi được
Configure load balancer TCP reset and idle timeout Microsoft Azure
Idle timeout của Azure Load Balancer mặc định 4 phút (4–100 phút), quá thời gian thì không bảo đảm giữ phiên, TCP reset là cấu hình tùy chọn
CloudWatch metrics for your Network Load Balancer AWS
TCP_ELB_Reset_Count: số gói RST do bộ cân bằng tải tạo ra và gửi đi

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

Cùng tầng: L5 Thiết bị mạng trung tâm dữ liệu

Nguyên nhân ở tầng khác gây cùng triệu chứng (Mất kết nối)

Rò rỉ bộ nhớ phía client L1 Tiến trình game phía client
Client bị crash L1 Tiến trình game phía client
Kiểm tra của module bảo mật game (anti-cheat) L1 Tiến trình game phía client
Ứng dụng di động chuyển xuống chạy nền L2 OS và thiết bị phía client
Chuyển đổi Wi-Fi ↔ LTE hoặc 5G L2 OS và thiết bị phía client
Giới hạn xử lý khi cửa sổ bị thu nhỏ hoặc mất focus L2 OS và thiết bị phía client
Phần mềm overlay can thiệp vào game L2 OS và thiết bị phía client
Ánh xạ NAT hết hạn L3 Mạng gia đình

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