핑은 낮은데 게임이 튄다: 지연·지터·손실을 구간별로 나눠 재는 법

국내 게임 서버까지의 왕복 지연은 대개 한 자릿수에서 20밀리초대 안에 들어온다. 이렇게 낮은 구간에서는 평균값보다 흔들림이 체감을 지배한다. 평균 12밀리초인데 가끔 90밀리초가 섞이는 회선과 평균 25밀리초로 평평한 회선을 비교하면 뒤쪽이 훨씬 낫게 느껴진다. 그런데 대부분은 게임 화면에 뜨는 평균 하나만 보고 회선을 판단한다.

고장의 종류는 셋으로 갈리고 각각 원인과 처방이 다르다. 지연이 큰 것, 지연이 흔들리는 것, 패킷이 사라지는 것이다. 이 셋을 섞어 놓고 핑이 튄다고 뭉뚱그리면 진단이 되지 않는다. 아래는 장비를 더 사지 않고 구간을 나눠 세 지표를 분리하는 절차다.

세 지표를 먼저 분리한다

• 지연(RTT): 패킷이 목적지까지 갔다 오는 시간이다. 물리적 하한이 있다. 광섬유 안에서 신호는 대략 초속 20만 킬로미터로 움직이므로 편도 100킬로미터마다 왕복 지연이 1밀리초쯤 더해진다. 경로는 직선이 아니고 장비마다 처리 시간이 붙으므로 실제 값은 그보다 크다.
• 지터: 연속으로 잰 지연의 변동 폭이다. 실시간 트래픽의 체감은 여기에 달려 있다. 수신 측 버퍼가 흡수할 수 있는 범위를 넘으면 끊김으로 드러난다.
• 손실: 목적지에 도달하지 못한 패킷의 비율이다. 게임은 적은 손실을 보정하지만 몇 퍼센트를 넘기면 순간 이동이나 입력 지연으로 나타난다.
• 순서 뒤바뀜: 손실은 아닌데 애플리케이션에서는 손실처럼 처리되기도 한다. 경로가 여러 갈래로 나뉘어 흐를 때 생긴다.

도구가 알려 주는 숫자가 이 넷 중 무엇인지 구분하면서 봐야 한다. 게임 클라이언트가 표시하는 핑은 대개 평균이거나 최근 값이고 튀는 순간의 최댓값은 보여 주지 않는다. 반면 ping 명령은 최솟값·평균·최댓값을 함께 알려 주므로 흔들림을 보기에 훨씬 낫다.

구간을 넷으로 잘라 잰다

1. 1단말에서 공유기까지. 기본 게이트웨이 주소로 오래 핑을 돌린다. 윈도우는 ping -n 300 192.168.0.1, macOS와 리눅스는 ping -c 300 192.168.0.1 형태이고 게이트웨이 주소는 ipconfig나 ip route로 확인한다. 여기서 이미 최댓값이 수십 밀리초로 튀면 집 안 무선 구간이 원인이다.
2. 2공유기에서 통신사 첫 홉까지. traceroute로 두 번째와 세 번째 홉 주소를 확인하고 같은 방식으로 오래 핑을 돌린다. 1단계는 깨끗한데 여기서 흔들리면 인입 회선이나 통신사 장비 쪽이다.
3. 3국내 목적지까지. 국내에 서버를 둔 잘 알려진 사이트를 대상으로 같은 측정을 한다. ICMP에 응답하지 않는 곳도 많으므로 응답하는 대상을 하나 골라 고정해 두고 계속 같은 대상으로 비교한다.
4. 4실제 목적지까지. 게임 서버나 업무용 서버를 대상으로 측정한다. 앞 단계가 모두 깨끗한데 여기서만 튀면 그 서비스로 가는 경로나 서버 쪽 문제다.
5. 5각 단계는 최소 5분, 가능하면 문제가 재현되는 시간대에 돌린다. 30초 측정으로는 몇 분에 한 번 오는 스파이크를 잡을 수 없다.
6. 6윈도우는 pathping, 리눅스와 macOS는 mtr(macOS는 별도 설치 필요)을 쓰면 홉별 손실률과 지연을 한 화면에서 볼 수 있어 단계를 압축할 수 있다.

해석 규칙은 단순하다. 문제가 처음 나타나는 구간이 원인 구간이다. 1단계에서 이미 흔들린다면 뒤 단계의 숫자는 모두 그 흔들림을 물려받은 값이므로 따로 해석할 필요가 없다. 순서를 건너뛰고 마지막 구간부터 재는 것이 가장 흔한 실수다.

무선 구간이 범인일 때

아파트와 오피스텔이 밀집한 환경에서는 2.4GHz 대역이 이웃 신호로 붐빈다. 전파가 겹치면 재전송이 늘고, 재전송은 평균이 아니라 최댓값을 끌어올린다. 평균은 멀쩡한데 최댓값만 튀는 전형적인 모양이 여기서 나온다.

• 5GHz 대역으로 옮긴다. 기기와 공유기가 모두 지원하면 6GHz도 선택지다. 벽 투과는 약해지지만 혼잡이 줄어든다.
• 채널 폭을 무작정 넓게 두지 않는다. 넓을수록 겹치는 이웃이 늘어 간섭받을 확률이 올라간다.
• 노트북과 휴대폰의 무선 절전 옵션을 끈다. 절전 모드는 수신 주기를 늘려 지터를 만든다.
• USB 3.0 장치와 외장 SSD는 2.4GHz 대역에 잡음을 만든다. 공유기나 무선 동글에서 떨어뜨려 둔다.
• 메시 노드를 무선 백홀로 쓰고 있다면 그 구간이 그대로 지터가 된다. 가능하면 유선 백홀로 바꾼다.
• 결정적인 확인은 유선 연결이다. 이더넷 케이블을 꽂고 같은 측정을 돌려 숫자가 평평해지면 무선이 원인이다.

경로 쪽 숫자를 잘못 읽지 않기

traceroute 결과에서 중간 홉의 응답이 느리거나 별표로 나오는 것을 보고 그 홉에서 손실이 난다고 결론짓는 경우가 많다. 대개 틀린 해석이다. 라우터는 자기 앞으로 온 ICMP에 응답을 만드는 일을 낮은 우선순위로 처리하므로, 전달 성능이 멀쩡해도 응답만 늦거나 빠질 수 있다. 중간 홉의 숫자는 참고 값이고 판단의 기준은 끝점이다.

• 끝점까지의 손실률이 0이면 중간 홉의 손실 표시는 무시해도 된다.
• 손실이 어떤 홉에서 시작해 그 뒤 모든 홉에서 계속 이어진다면 그때는 실제 손실일 가능성이 높다.
• 왕복 경로는 비대칭인 경우가 많다. traceroute는 가는 길만 보여 준다.
• 경로가 여러 갈래로 나뉘어 흐르면 홉마다 다른 경로가 섞여 보인다. 실행할 때마다 홉 목록이 조금씩 달라지는 이유다.
• 시간대와의 상관관계를 기록한다. 저녁에만 재현되면 혼잡 쪽, 시간과 무관하면 장비나 배선 쪽일 확률이 높다.

터널을 켠 상태에서 비교 측정하기

터널은 경로와 전송 방식을 동시에 바꾼다. 켠 상태의 숫자 하나만 보면 무엇이 달라졌는지 알 수 없다. 같은 목적지, 같은 시간대에 켠 상태와 끈 상태를 번갈아 각각 세 번씩 재고 중앙값을 비교한다. 한 번씩만 재면 그날의 혼잡을 터널 탓으로 돌리기 쉽다.

• 지연이 늘고 지터는 그대로면 거리 때문이다. 물리적 하한은 설정으로 줄일 수 없다.
• 지연은 비슷한데 지터와 손실이 늘면 전송 방식이나 중간 구간을 의심한다.
• TCP 위에서 도는 터널은 손실이 생기면 재전송이 끝날 때까지 뒤따르는 데이터가 함께 멈춘다. 손실이 있는 환경에서는 지터가 증폭돼 보이므로 UDP 기반 전송이 유리하다.
• MTU 여유가 없으면 큰 패킷만 조각나거나 버려진다. 핑은 멀쩡한데 특정 동작에서만 멈추는 모양이다. 조각화 금지 옵션으로 크기를 바꿔 가며 핑을 보내면 임계값을 찾을 수 있다. 윈도우는 ping -f -l 1400 대상, macOS는 ping -D -s 1400 대상, 리눅스는 ping -M do -s 1400 대상이고, 통과한 크기에 28을 더한 값이 그 경로의 IPv4 MTU다.
• 주소 변환 계층이 여러 겹이면 매핑 수명이 짧아져 잠시 쉰 뒤 첫 패킷이 느려진다.

집 안 주소 구조가 원인일 수 있다면 회선의 IPv6와 NAT 계층을 확인하는 절차를 먼저 돌리는 편이 빠르다. 측정을 카페나 공용 무선망에서 하고 있다면 접속 페이지가 있는 무선망의 동작도 함께 감안해야 한다.

자주 묻는 질문