Nếu một số tường lửa hoặc thiết bị tăng tốc xóa hay sửa tùy chọn TCP, khi mất nhiều gói thì mỗi vòng khứ hồi chỉ phục hồi được một gói, hoặc cửa sổ (lượng dữ liệu gửi được trong một lần) bị thu nhỏ, khiến kết nối chậm đi.
Vì sao “Chuẩn hóa TCP” (TCP normalization) của tường lửa hoặc thiết bị tăng tốc đời cũ xóa các tùy chọn SACK, timestamp, window scale → Dẫn đến Mất nhiều gói thì mỗi vòng khứ hồi chỉ phục hồi một gói, cửa sổ bị giới hạn ở 64 KB → Trên màn hình Mỗi lần mất gói, thời gian đứng hình dài hơn nhiều (không có SACK thì cũng không dùng được RACK-TLP), thông rồi thì tua nhanh. Truyền dữ liệu dung lượng lớn như tải bản cập nhật cũng chậm
Phụ trách chính Hạ tầng mạng (Đội hạ tầng) · Phối hợp Hạ tầng server (Đội hạ tầng)
Việc cần làm (Đội hạ tầng)
Mạng: tắt cấu hình chuẩn hóa TCP trên thiết bị đó, kiểm tra cả tính năng ngẫu nhiên hóa số thứ tự của tường lửa, bắt gói ở cả hai đầu để so sánh tùy chọn trong SYN. Thiết bị server·OS: kiểm tra xem các kết nối thiếu sack, wscale trong ss -ti có tập trung ở một tuyến nhất định không (PC Windows có thể không dùng ts tùy cấu hình, nên chỉ thiếu ts có thể vẫn là bình thường), kiểm tra net.ipv4.tcp_sack của server có bằng 1 không.
Trên đồ thị
Luôn cao ngay từ đầu · Số lần phục hồi bắt đầu mà không có SACK (TcpExtTCPRenoRecovery)
Chỗ cần xem
Có hay không sack và wscale ở từng kết nối trong ss -ti; tỷ lệ giữa TcpExtTCPRenoRecovery (phục hồi bắt đầu không có SACK) và TcpExtTCPSackRecovery, cùng TcpExtTCPSACKDiscard (số khối SACK bị bỏ vì không khớp) trong nstat. Với tuyến bị nghi ngờ, bắt SYN ở cả hai đầu để so sánh tùy chọn (tcp.options.sack_perm… trong Wireshark)
Đúng nếu
chỉ những kết nối đi qua một tuyến hoặc thiết bị nhất định thiếu sack, wscale và tỷ trọng TcpExtTCPRenoRecovery cao. Tùy chọn cho phép SACK có trong SYN phía gửi nhưng không còn trong SYN phía nhận. Nếu nguyên nhân là ngẫu nhiên hóa số thứ tự thì tùy chọn vẫn còn nhưng TcpExtTCPSACKDiscard tăng
Loại trừ nếu
mọi kết nối đều thiếu sack → kiểm tra giá trị net.ipv4.tcp_sack của server trước. Tùy chọn còn nguyên và TcpExtTCPSACKDiscard không đổi → phục hồi chậm vì lý do khác (“Thin stream phục hồi chậm”)
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
Tùy chọn vẫn còn mà SACK vẫn có thể hỏng. Nếu tính năng ngẫu nhiên hóa số thứ tự (sequence randomization) của tường lửa chỉ đổi số thứ tự trong header mà giữ nguyên các số bên trong SACK, bên gửi sẽ bỏ các SACK không khớp. Trường hợp server đã tắt SACK bằng tcp_sack=0 hồi xảy ra lỗ hổng bảo mật SACK năm 2019 rồi quên bật lại cũng cho kết quả tương tự.
SNMP counterLinux kernel TcpExtTCPRenoRecovery (bắt đầu phục hồi không có SACK), TcpExtTCPSackRecovery (bắt đầu phục hồi bằng SACK), TcpExtTCPSACKDiscard (số khối SACK không hợp lệ)