Hạ RTO tối thiểu quá thấp thì chỉ trễ một chút cũng sinh ra truyền lại không cần thiết, còn giá trị mặc định (200 ms) lại quá dài với game nên mỗi lần mất gói là đứng lâu.
Vì sao Hạ mạnh RTO tối thiểu theo kiểu dành cho trung tâm dữ liệu, hoặc để nguyên giá trị mặc định cho chặng Internet → Dẫn đến Thấp thì chỉ một thoáng trễ cũng làm truyền lại ồ ạt, cao thì mỗi lần mất gói phải chờ lâu → Trên màn hình Với giá trị mặc định, mỗi lần mất gói là đứng hình vài trăm ms rồi tua nhanh; hạ quá thấp thì đứng hình ít đi nhưng truyền lại không cần thiết tăng vọt, lãng phí đường truyền
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)
Với Linux 6.15 trở lên, cân nhắc hạ trần RTO cho kết nối game bằng TCP_RTO_MAX_MS (thời gian đến lúc bỏ cuộc cũng ngắn lại nên đặt kèm thời gian kết luận mất kết nối bằng TCP_USER_TIMEOUT); chỉ với kết nối nội bộ giữa các server mới hạ RTO tối thiểu bằng tùy chọn socket TCP_RTO_MIN_US (6.15 trở lên); cân nhắc dùng tùy chọn socket TCP_THIN_LINEAR_TIMEOUTS để riêng kết nối game không bị tăng gấp đôi khi RTO liên tiếp.
Việc cần làm (Đội hạ tầng)
Chỉ hạ rto_min theo tuyến cho kết nối nội bộ giữa các server; chặng Internet giữ giá trị mặc định nhưng bù lại bằng RACK-TLP và cấu hình thin stream (tcp_thin_linear_timeouts).
Con số tham khảo
RTO của Linux = thời gian khứ hồi + max(200 ms, độ lệch RTT×4). Mỗi lần thất bại tăng gấp đôi, tối đa 120 giây. Từ Linux 6.15 có thể dùng TCP_RTO_MAX_MS để hạ mức trần này xuống tới 1 giây.
Trên đồ thị
Luôn cao ngay từ đầu · RTO theo từng kết nối, số RTO không cần thiết
Chỗ cần xem
Cấu hình RTO tối thiểu của server (rto_min trong ip route show, từ Linux 6.11 là sysctl net.ipv4.tcp_rto_min_us), rto và rtt trong ss -ti, phần tăng của TcpExtTCPSpuriousRTOs trong nstat
Đúng nếu
trên server đã hạ giá trị tối thiểu, rto của các kết nối Internet sát ngay rtt và TcpExtTCPSpuriousRTOs tăng nhiều. Nếu để nguyên mặc định thì rto của kết nối game lớn hơn rtt từ 200 ms trở lên, và mỗi lần mất gói là đứng hình đúng chừng ấy thời gian
Loại trừ nếu
rto đúng theo cách tính mặc định (khoảng rtt + 200 ms), RTO không cần thiết cũng ít mà thời gian đứng hình vẫn dài bất thường → do mất gói liên tiếp hoặc do cách phục hồi (“Thin stream phục hồi chậm”, “Thiết bị trung gian xóa tùy chọn TCP”)
Cách kiểm tra
Kiểm tra bằng công cụ hạ tầng (không cần code game)
Nguồn
RFC 6298: Computing TCP's Retransmission TimerIETF RTO = SRTT + max(G, 4·RTTVAR), khuyến nghị tối thiểu 1 giây, mỗi lần thất bại tăng gấp đôi, nếu đặt giá trị tối đa thì phải từ 60 giây trở lên
include/net/tcp.hLinux kernel TCP_RTO_MIN của Linux là 200 ms, TCP_RTO_MAX là 120 giây
net/ipv4/tcp_input.cLinux kernel RTO của Linux là SRTT + rttvar, và rttvar không xuống dưới RTO tối thiểu (mặc định 200 ms)
IP SysctlLinux kernel tcp_rto_min_us mặc định 200000 (tùy chọn tuyến rto_min và tùy chọn socket TCP_RTO_MIN_US được ưu tiên hơn), tcp_rto_max_ms 1.000–120.000 (mặc định 120.000), tcp_thin_linear_timeouts