Hết hạn theo dõi kết nối của security group trên cloud Cloud security group connection tracking timeout
ID nguyên nhân dc-cloud-conntrack · Phụ trách chính Hạ tầng server (Độ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)
Tường lửa gắn với server cloud (security group) cũng theo dõi kết nối, và mục theo dõi của kết nối nhàn rỗi sẽ hết hạn sau một khoảng thời gian định sẵn. Ngay cả với server nhận kết nối trực tiếp không qua bộ cân bằng tải, người chơi để yên một lúc cũng có thể bị mất kết nối.
Vì sao Security group được cấu hình theo cách có theo dõi kết nối game (chỉ cho phép một số địa chỉ, hạn chế quy tắc chiều ra, đi qua NLB…) → Dẫn đến Mục theo dõi của kết nối đã nhàn rỗi một lúc bị hết hạn, và các gói đến sau đó bị security group âm thầm bỏ → Trên màn hình Rời máy một lúc rồi quay lại di chuyển thì không có phản hồi, sau đó mất kết nối. Chương trình server rất lâu sau mới biết
Phụ trách chính Hạ tầng server (Độ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 (TCP 350 giây thì tối đa 175 giây, UDP stream 180 giây thì tối đa 90 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 thời gian theo dõi kết nối của instance (TcpEstablishedTimeout) và tăng nếu cần (UDP tối đa 180 giây nên không tăng được), xem xét cấu hình security group không tạo theo dõi (cổng game cho phép mọi địa chỉ, quy tắc chiều ra cho phép toàn bộ; kết nối qua NLB vẫn bị theo dõi), thử để nhàn rỗi khi chuyển sang instance thế hệ mới.
Con số tham khảo
Theo AWS, các loại instance Nitro v6 mặc định xóa mục theo dõi của kết nối TCP nhàn rỗi sau 350 giây (các loại khác là 5 ngày). Với UDP, mặc định là 180 giây cho luồng có yêu cầu và phản hồi qua lại nhiều lần (stream), 30 giây cho luồng chỉ đi một chiều hoặc chỉ có một lần yêu cầu và phản hồi.
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 cấu hình thời gian theo dõi kết nối của instance và quy tắc security group (có phải cấu hình tạo theo dõi không), rồi gom thời gian nhàn rỗi của các kết nối bị ngắt. Ngay sau khi bị ngắt, dùng ss -tnoi trên server xem kết nối đó có còn ở trạng thái ESTABLISHED, timer truyền lại (timer:(on,…)) đang chạy và backoff tăng dần không
Đú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 mức TCP 350 giây, UDP stream 180 giây, UDP một chiều 30 giây, và socket phía server vẫn ở ESTABLISHED mà không phát hiện kết nối đã đứt (nếu server có dữ liệu cần gửi thì chỉ lặp lại truyền lại)
Loại trừ nếu
security group có cấu hình không theo dõi (cổng game cho phép mọi địa chỉ, quy tắc chiều ra cho phép toàn bộ, không đi qua NLB) → không phải nguyên nhân này; có đi qua NLB → so sánh giá trị với “Idle timeout của bộ cân bằng tải”
Cách kiểm tra
Kiểm tra bằng công cụ hạ tầng (không cần code game)
Nguồn
Amazon EC2 security group connection trackingAWS Theo dõi TCP nhàn rỗi mặc định 350 giây (Nitro v6, loại khác 432.000 giây = 5 ngày), UDP một chiều 30 giây, stream 180 giây (tối đa 180); quy tắc cho phép mọi địa chỉ thì không theo dõi; kết nối qua NLB luôn bị theo dõi