게임 렉 백서 › TCP 재전송의 근본 원인
ACK가 늦거나 사라짐 (업로드 포화) ACK path congestion on asymmetric links
원인 ID rt-ack-path · 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발
그림과 실험이 있는 원본 카드로 열기 →
데이터는 잘 도착했는데 “받았다”는 ACK가 꽉 찬 업로드 대기열에서 늦어지거나 사라지면, 보내는 쪽이 손실로 판단해 재전송합니다.
왜 집에서 영상 업로드·클라우드 백업으로 업로드가 꽉 참 → 그러면 ACK가 공유기 대기열에서 수백 ms 늦어지거나 넘쳐서 버려짐 → 화면에서는 서버가 보내는 게임 패킷은 대체로 제때 옴. 같은 업로드 대기열에 쌓인 내 입력이 늦어 입력 지연·고무줄, 가끔 불필요한 재전송
증상 입력 지연 , 고무줄 요인 지연, 손실
누가 겪나 같은 집
언제 가끔 무작위로, 저녁 피크 시간
담당 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일 핑이 급등하면 화면에 네트워크 상태 표시, “업로드 중인 프로그램 확인” 안내 띄우기.
외부 할 일 유저에게 공유기 SQM으로 업로드 대기열 짧게, 작은 패킷(ACK) 우선 처리, 업로드 속도 제한(영상 업로드·클라우드 백업) 안내.
수치 감각 ACK는 뒤의 ACK가 앞의 것을 대신 확인해 주므로 몇 개 사라지는 것은 대개 괜찮습니다. 렉을 만드는 것은 대기열에서 늦어지는 ACK입니다.
그래프에서는 확인할 곳 유저 PC에서 업로드(영상 업로드·클라우드 백업)를 켠 상태와 끈 상태로 게임 서버 ping을 비교함. 서버에서는 ss -ti로 그 유저 연결의 rtt를 봄 이러면 맞음 업로드 중에만 ping이 수백 ms로 오르고 입력 지연·고무줄이 생기며 업로드를 멈추면 곧 돌아옴. 서버에서 보면 그때 그 연결의 rtt도 함께 오름 이러면 아님 업로드와 상관없이 손실과 지연이 생기면 “무선 구간 손실”이나 경로 쪽 원인. 서버에서 유저로 가는 방향만 늦고 업로드와 상관없으면 “병목 대기열 넘침” 확인 수단 유저 쪽 환경에서 확인
출처 RFC 3449: TCP Performance Implications of Network Path Asymmetry IETF 업로드가 좁은 비대칭 회선에서 ACK가 늦거나 사라지면 TCP 성능이 떨어짐, ACK는 누적 확인이라 일부가 사라져도 뒤 ACK가 대신함, ACK 우선 스케줄링 같은 대책 Smart Queue Management Bufferbloat.net 공유기에서 대기열 관리와 셰이핑으로 대기열을 짧게 유지 tc-cake(8) — Linux manual page iproute2 CAKE는 흐름을 나눠 드문드문 보내는 흐름(sparse flow)의 지연을 최소화 ss(8) — Linux manual page iproute2 ss -i의 rtt(평균 왕복 시간)와 rttvar(편차) 함께 보면 좋은 원인
같은 층: TCP 재전송의 근본 원인
같은 증상(입력 지연)의 다른 층 원인
그림과 실험이 있는 원본 카드 보기