Bản cập nhật làm thay đổi mô hình lưu lượng Patch changes traffic pattern
ID nguyên nhân sp-patch-traffic · Phụ trách chính Phát triển server (Đội phát triển game) · Phối hợp Hạ tầng server (Đội hạ tầng), Hạ tầng mạng (Đội hạ tầng)
Khi nội dung, hiệu ứng hoặc trường đồng bộ mới làm tăng kích thước và tần suất gói tin, server đang chạy tốt bắt đầu chạm giới hạn MTU, băng thông và số gói kể từ sau bản cập nhật.
Vì sao Bản cập nhật thêm hiệu ứng skill mới, trường đồng bộ, thông tin vật phẩm, khiến gói tin to hơn hoặc dày hơn → Dẫn đến Gói lớn vượt MTU nên bị phân mảnh, còn lượng tăng thêm chạm giới hạn băng thông, giới hạn PPS của cloud và bộ đệm gửi → Trên màn hình Từ ngay sau bản cập nhật, ở nơi đông người bị dịch chuyển tức thời, nuốt skill, trễ thao tác. Hạ tầng không thay đổi gì mà mất gói lại tăng
Cả server, Một địa điểm hoặc kênh, Một khu vực hoặc nhà mạng
Khi nào
Khi đông người, Giờ cao điểm buổi tối, Luôn luôn
Phụ trách
Phụ trách chính Phát triển server (Đội phát triển game) · Phối hợp Hạ tầng server (Đội hạ tầng), Hạ tầng mạng (Đội hạ tầng)
Việc cần làm (Đội phát triển game)
Tự chia gói xuống từ 1.200 byte trở xuống; với trường đồng bộ mới, chỉ gửi phần thay đổi và giảm tần suất theo khoảng cách và mức độ quan trọng; trước khi triển khai, so sánh số gói và byte mỗi giây của mỗi người chơi cùng kích thước gói lớn nhất với build trước trên server test; gắn phiên bản build vào chỉ số lưu lượng.
Việc cần làm (Đội hạ tầng)
Thiết bị server·OS: đánh dấu thời điểm triển khai trên đồ thị và so sánh số gói, byte mỗi giây của mỗi người chơi và kích thước gói trung bình trước và sau khi triển khai, cảnh báo theo bộ đếm vượt giới hạn của instance, chuyển sang instance lớn hơn nếu cần. Mạng: kiểm tra giới hạn xử lý của tường lửa, bộ cân bằng tải, thiết bị chống DDoS và việc chúng có chặn fragment hay không.
Con số tham khảo
Gói UDP từ 1.200 byte trở xuống là an toàn; path MTU trên Internet thường là 1.500 byte, đi qua tunnel thì nhỏ hơn (tunnel GRE là 1.476 byte). Gói vượt path MTU sẽ bị phân mảnh hoặc bị bỏ, và gói bị phân mảnh chỉ cần mất một fragment là mất cả gói. Số gói mỗi giây của mỗi người chơi tăng 20% thì cả server cũng tăng 20%, và instance vốn đang chạy gần giới hạn sẽ tràn ngay.
Trên đồ thị
Tăng như bậc thang từ một thời điểm · Số gói và byte mỗi giây của mỗi người chơi, kích thước gói trung bình
Chỗ cần xem
Số gói và byte mỗi giây trên NIC của server (rxpck/s, txpck/s, rxkB/s, txkB/s của sar -n DEV; NetworkPacketsOut, NetworkOut trên EC2) chia cho số người chơi đồng thời, so sánh trước và sau thời điểm triển khai. Kích thước gói trung bình = byte ÷ gói; phân bố kích thước thì chạy thống kê Packet Lengths của Wireshark trên bản bắt gói (packet capture)
Đúng nếu
ngay sau khi triển khai, số gói và byte của mỗi người chơi hoặc kích thước gói trung bình tăng một bậc rồi giữ nguyên, và từ cùng thời điểm đó số fragment server tạo ra (fragcrt/s của sar -n IP) hoặc bộ đếm vượt giới hạn của instance (pps_allowance_exceeded, bw_out_allowance_exceeded của AWS ENA) tăng lên
Loại trừ nếu
mô hình lưu lượng trước và sau triển khai như nhau mà chỉ độ trễ và mất gói tăng → xem các thay đổi hạ tầng cùng thời điểm (cấu hình, tuyến đường, thiết bị, cập nhật OS hoặc kernel)
Cách kiểm tra
Kiểm tra bằng công cụ hạ tầng (không cần code game)
Tìm hiểu thêm
Khi có báo cáo “trước bản cập nhật vẫn ổn”, đây là nguyên nhân phía game cần kiểm tra trước tiên, cùng với các thay đổi hạ tầng. Dù patch note không có thay đổi gì về mạng, chỉ một hiệu ứng hoặc trường đồng bộ mới cũng bị nhân lên hàng trăm lần ở nơi đông người. Chỗ mà lưu lượng tăng thêm thực sự chạm giới hạn được trình bày ở các mục “Phân mảnh IP của gói UDP”, “Vượt giới hạn PPS trên cloud”, “Băng thông NIC bị bão hòa”, “Bộ đệm socket của kernel quá nhỏ”, “Thiết bị trung gian vượt giới hạn xử lý (tường lửa, IPS, chống DDoS)”. Mục này nói về trường hợp chính bản cập nhật game đã đẩy lưu lượng chạm các giới hạn đó, nên trước khi nâng giới hạn, hãy giảm phần lưu lượng mà bản cập nhật làm tăng thêm. Nếu cùng lúc đó OS hoặc kernel cũng được cập nhật, hãy phân biệt với “Hiệu năng thay đổi sau khi cập nhật OS, kernel, driver hoặc firmware” dựa vào việc lưu lượng của mỗi người chơi có thay đổi hay không.
Nguồn
RFC 8085: UDP Usage GuidelinesIETF Ứng dụng UDP không nên (SHOULD NOT) gửi datagram lớn hơn path MTU; mất một fragment là mất cả gói bị phân mảnh, và một số NAT, tường lửa bỏ hết mọi fragment
sar(1) — Linux manual pagesysstat rxpck/s và txpck/s (số gói mỗi giây), rxkB/s và txkB/s (số KB mỗi giây) trong sar -n DEV; fragcrt/s (số fragment IP tạo ra mỗi giây, ipFragCreates) trong sar -n IP