일부 방화벽·가속 장비가 TCP 옵션을 지우거나 고치면, 여러 개를 잃었을 때 한 왕복에 하나씩만 복구하거나 윈도우(한 번에 보낼 수 있는 양)가 작아져 느려집니다.
왜 방화벽의 “TCP 정규화”, 오래된 가속 장비가 SACK·타임스탬프·윈도우 스케일 옵션을 제거 → 그러면 잃은 패킷이 여러 개면 왕복마다 하나씩 복구, 윈도우가 64KB로 제한됨 → 화면에서는 손실마다 멈춤이 훨씬 길어지고(SACK이 없으면 RACK-TLP도 못 씀) 풀리면 몰아치기. 패치 같은 대용량 전송도 느림
네트워크: 해당 장비의 TCP 정규화 설정 끄기, 방화벽의 시퀀스 번호 무작위화도 확인, 양쪽 끝 패킷 캡처로 SYN의 옵션 비교. 서버 장비·OS: ss -ti에서 sack·wscale 표시가 빠진 연결이 특정 경로에 몰리는지 확인(ts는 윈도우 PC가 설정에 따라 쓰지 않으므로 ts만 빠진 것은 정상일 수 있음), 서버의 net.ipv4.tcp_sack이 1인지 확인.
그래프에서는
처음부터 늘 높음 · SACK 없이 시작한 복구 수(TcpExtTCPRenoRecovery)
확인할 곳
ss -ti에서 연결마다 sack·wscale 표시가 있는지 보고 nstat의 TcpExtTCPRenoRecovery(SACK 없이 시작한 복구)와 TcpExtTCPSackRecovery의 비율, TcpExtTCPSACKDiscard(앞뒤가 맞지 않아 버린 SACK 블록 수)를 봄. 의심 경로는 양쪽 끝에서 SYN을 캡처해 옵션(Wireshark의 tcp.options.sack_perm 등)을 비교함
이러면 맞음
특정 경로·장비를 지나는 연결만 sack·wscale이 빠져 있고 TcpExtTCPRenoRecovery 비중이 높음. 보낸 쪽 SYN에 있던 SACK 허용 옵션이 받은 쪽 SYN에는 없음. 시퀀스 번호 무작위화가 원인이면 옵션은 남아 있는데 TcpExtTCPSACKDiscard가 늘어남
이러면 아님
모든 연결에서 sack이 빠져 있으면 서버의 net.ipv4.tcp_sack 값부터 확인. 옵션이 온전하고 TcpExtTCPSACKDiscard도 그대로면 복구가 느린 이유는 다른 곳(“thin stream의 느린 복구”)
확인 수단
인프라 도구로 확인(게임 코드 불필요)
더 알아보기
옵션이 남아 있어도 SACK이 망가질 수 있습니다. 방화벽의 시퀀스 번호 무작위화(sequence randomization)가 헤더의 시퀀스 번호만 바꾸고 SACK 안의 번호는 그대로 두면, 보내는 쪽은 앞뒤가 맞지 않는 SACK을 버립니다. 2019년 SACK 보안 문제 때 서버에서 tcp_sack=0으로 꺼 두고 잊은 경우도 결과가 같습니다.