주 담당 외부·외부 · 함께 인프라팀·서버 인프라, 게임개발팀·서버 개발, 게임개발팀·클라이언트 개발
게임개발팀 할 일
서버: TCP_NODELAY 켜기(Nagle이 켜져 있으면 RACK이 손실 판단에 쓸 뒤따르는 패킷이 없음), 재전송으로 막힌 동안 보낼 상태 업데이트는 쌓아 두지 말고 최신 것만 보내기(커널에 쌓이는 양은 TCP_NOTSENT_LOWAT로 제한). 클라이언트: TCP_NODELAY 켜기(내 입력 방향의 손실은 클라이언트 OS가 복구), 손실이 몰리거나 핑이 급등하면 화면에 네트워크 상태 표시.
인프라팀 할 일
RACK-TLP로 손실 복구를 빠르게 하기(서버는 무선 손실을 막을 수 없고 복구를 빠르게 하는 것까지만 가능), 최신 리눅스 기본값인 net.ipv4.tcp_recovery=1(RACK)·net.ipv4.tcp_early_retrans=3(TLP)이 바뀌지 않았는지 확인.
외부 할 일
유저에게 유선 연결, 5GHz·6GHz 사용, 공유기 위치·채널 바꾸기 안내.
수치 감각
무선 손실 1%면 게임 패킷 100개에 1개가 사라집니다. 1초에 10개를 받으면 10초에 한 번꼴로 멈칫합니다. RACK-TLP가 없으면 한 번마다 RTO(핑 + 200ms 이상)만큼 멈춥니다.
그래프에서는
일부만 높음 · 연결별 재전송률, 연결별 RTT(핑)
확인할 곳
유저 PC에서 공유기(게이트웨이) 주소와 게임 서버로 각각 ping을 수백 번 보내 손실과 지연 폭을 비교하고, 유선이나 모바일 데이터로 바꿔 다시 잼. 서버에서는 ss -ti로 그 유저 연결의 retrans와 rtt(평균/편차)를 봄
이러면 맞음
공유기까지 가는 ping에서 이미 손실이나 들쭉날쭉한 지연이 보이고 유선으로 바꾸면 사라짐. 서버에서 보면 그 유저 연결만 retrans와 RTT 편차가 큼
이러면 아님
공유기까지는 깨끗하고 그 너머에서 손실이 시작되면 통신사·경로 쪽(“병목 대기열 넘침”, “경로 변경·ECMP 불량 경로”). 같은 통신사 유저 여럿이 동시에 나빠지면 통신사 구간부터 봄
확인 수단
유저 쪽 환경에서 확인
더 알아보기
무선 장비의 재시도는 지터를 만들고(재시도마다 수 ms), 재시도 한도를 넘은 경우만 손실이 됩니다. 그래서 무선 품질이 나빠질수록 “지터 → 가끔 멈춤 → 잦은 멈춤” 순서로 증상이 커집니다. 공유기(AP) 사이를 옮겨 가는 순간(로밍)에는 수십 ms~수 초 동안 연달아 잃기도 합니다. 모바일망은 기지국 구간에서 재전송을 많이 하므로, 손실보다 수백 ms 지연 급등으로 나타나는 경우가 많습니다.