TCP coi mất gói là tín hiệu tắc nghẽn và giảm tốc độ gửi 30–50%. Mất gói do Wi-Fi cũng bị xử lý y như vậy.
Vì sao Có chút mất gói trên Wi-Fi hoặc đường truyền đúng lúc cần gửi nhiều dữ liệu → Dẫn đến TCP giảm mạnh tốc độ gửi rồi hồi phục chậm (CUBIC, thuật toán mặc định của Linux và Windows, giảm 30%) → Trên màn hình Ở nơi đông người, bản cập nhật bị dồn lại, gây tua nhanh và trễ thao tác
Phụ trách chính Hạ tầng server (Đội hạ tầng) · Phối hợp Phát triển server (Đội phát triển game)
Việc cần làm (Đội phát triển game)
Giảm lượng gửi (vùng quan tâm, chỉ gửi phần thay đổi), chia nhỏ ra gửi để không dồn một lượt.
Việc cần làm (Đội hạ tầng)
Chuyển sang thuật toán kiểm soát tắc nghẽn như BBR (tcp_congestion_control).
Trên đồ thị
Tăng dần rồi rơi thẳng · Cửa sổ tắc nghẽn (cwnd) và tốc độ gửi theo từng kết nối
Chỗ cần xem
Chụp ss -ti nhiều lần cho kết nối của người chơi bị dồn bản cập nhật để xem cwnd, ssthresh thay đổi thế nào và tên thuật toán kiểm soát tắc nghẽn (cubic, bbr), đồng thời xem Send-Q có dồn lên không
Đúng nếu
sau mỗi lần mất gói, cwnd giảm mạnh rồi tăng lại chậm, lặp đi lặp lại; trong lúc cwnd thấp, Send-Q dồn lên, trùng với thời điểm người chơi báo tua nhanh và trễ thao tác
Loại trừ nếu
cwnd dư dả mà vẫn bị dồn → xem cửa sổ của bên nhận (“Zero window (khoảng dừng dễ nhầm là truyền lại)”) hoặc phía gửi của server
Cách kiểm tra
Kiểm tra bằng công cụ hạ tầng (không cần code game)
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Giá trị Recv-Q và Send-Q trong ss: với socket đang listen là số kết nối chờ accept và giới hạn backlog; với socket đã kết nối là số byte ứng dụng chưa đọc và số byte đã gửi nhưng chưa nhận được ACK