본문으로 건너뛰기

RTT(핑) 관련

핑이 무엇인가요?​

자세한 설명은 핑 문서 혹은 렉 (Lag) 문서를 참고 바랍니다.

핑 평균값은 낮은 게 좋은건가요?​

네. 그렇습니다. 핑의 평균값이 낮으면 낮을 수록 빠르다는 것을 가리킵니다.

핑 표준 편차는 낮은 게 좋은건가요?​

그렇습니다. :-) 표준 편차값이 0 에 가까울 수록 해당 연결이 굉장히 안정적이라는 것을 의미합니다.

핑 평균값과 표준 편차 중 어느 것이 우선순위가 높나요?​

사실 둘 다 중요한데요, 평균값을 속도를 나타낸다고 가정을 한다면 표준 편차를 연결의 안정도를 나타내는 지표입니다. 만약 속도가 비슷하지만 편차가 다른 두 중계 서버 중 하나를 선택한다면 표준 편차가 0 에 가까운 것이 좀 더 좋을 것입니다.

어떻게 해야 가장 빠른 핑을 얻을 수 있을까요?​

가장 빠른 핑이란 것이 '사용자 컴퓨터' 에서 목적지 '게임 서버'까지 가장 낮은 RTT (핑값) 가 나오는 인터넷 경로를 찾는 것인데요, 게임이 미꾸라지에 등록되어 있다면 아래와 같은 방법으로 최단 경로 검색을 하실 수 있습니다.

  1. (v4 버전 기준으로 설명을 드리면) 우선 Launcher 를 실행하고 해당 게임 아이템을 장착합니다. 반드시 Launcher 를 통해 대쉬 보드에 접근하셔야 합니다.
  2. 대쉬 보드에서 해당 게임의 아이콘을 클릭합니다.
  3. '설정' 탭에서 중계 서버 항목의 '고급 모드'를 클릭하신 후 돋보기 아이콘을 클릭합니다.
  4. 뜬 팝업창에서 게임 서버의 목적지를 클릭하시면 미꾸라지가 계산한 최단 경로들이 보이실 겁니다. 한개의 중계 서버를 통해 우회하여 접근하는 것이 빠른지 아니면 두 개의 중계 서버를 경유하여야 하는지를 보여줍니다.

좀 더 다양한 방법에 대해서는 RTT(핑)을 낮추는 방법 문서를 참고하시기 바랍니다.

핑이 제일 괜찮은 중계 서버라는게 뭐죠?​

'핑이 괜찮다'는 표현은 보통 '사용자 컴퓨터 → 중계 서버 → 게임 서버'까지 도달하는데, 빠른 경로를 가진 중계 서버를 가리킵니다. 앞서 말씀드렸지만, 해당 표현은 단순히 '사용자 컴퓨터 ↔ 중계 서버' 간의 핑을 말하는 것도 아니고, '중계 서버 ↔ 게임 서버'간의 경로를 말하는 것도 아니기 때문에 유의하셔야 합니다.

미꾸라지에서 핑이 제일 괜찮다고 중계 서버를 찾기 위해서는 보통 아래의 방법으로 결과를 참고하실 수 있습니다.

  1. 우선 Launcher 를 실행하고 해당 게임 아이템을 장착합니다. 미꾸라지 Launcher 를 통해 대쉬 보드에 접근하시는 것을 추천합니다.
  2. 대쉬 보드에서 해당 게임의 아이콘을 클릭합니다.
  3. '설정' 탭에서 중계 서버 항목의 '기본 모드'를 클릭하신 후 돋보기 아이콘 을 클릭합니다. 클릭을 하게 되면 팝업창이 뜨게 되는데, 접속하실 게임 서버 위치를 클릭하시면 계산된 그래프 및 평가 점수를 확인할 수 있는데, 보통 평가 점수가 낮은 중계 서버를 나타냅니다.

핑이 그대롭니다! 핑이 적용이 안되는 것 같아요.​

우선 아래의 각 항목들은 자가진단을 위해 도움이 될 수 있는 질문들입니다. 아래의 조치들에 대해서 테스트를 해보았는지를 먼저 살펴보시기 바랍니다.

질문 항목들예아니오
적용 여부 확인해 보기 방법으로 테스트시 제대로 적용되는 것을 확인하셨나요?
1. 게임 트래픽이 제대로 미꾸라지를 통해 전달되고 있는지요? 1
2. 중계 서버 선택을 '자동 선택'으로 지정해 놓으셨는지요? 2
3. 현재 사용하고 계신 중계 서버에서 다른 중계 서버들로 변경하셔서 테스트를 해보셨습니까? 3
4. ADN 모드를 이용하셔서 시도해 보셨습니까? 4
5. FastConnect 모드를 이용하여 시도해 보셨는지요? 5
6. 현재 연결 프로토콜을 TCP 로 사용하고 계신가요? 6

UI 상 예측 그래프에서의 RTT 와 실제 게임내에서 RTT 가 달라요!​

이 부분은 여러가지 원인으로 인해 발생할 수 있는데요, 각각에 대해 말씀드리면,

  1. RTT 계산을 위해 측정하는 IP 대역이 미꾸라지의 것과 게임의 것이 다를 경우

    모든 미꾸라지 중계 서버들은 주기적으로 게임 서버를 대상으로 RTT 체크를 하고 이 정보를 중앙 서버에 전송하게 되어 있습니다. 하지만 이 RTT 체크를 하기 위한 대상(보통 IPv4 address)이 게임이 체크를 하는 방식과 다를 경우, 미꾸라지의 값과 다르게 나올 수 있습니다.

    간혹 미꾸라지가 RTT 체크를 위한 대상을 잘못 지정하여 실제 게임 서버가 아닌 곳으로 측정하여 문제가 발생될 수 도 있습니다.

  2. RTT 계산을 위해 측정하는 프로토콜이 미꾸라지의 것과 게임의 것이 다를 경우

    기본적으로 미꾸라지는 TCP 프로토콜을 이용하여 RTT 를 측정합니다만, 간혹 게임 트래픽이 TCP 프로토콜 기반이 아닌 UDP 프로토콜 기반인 경우, 이로 인해 (보통 QoS 장비로 인해 패킷 처리 우선순위가 변경될 수 있습니다.) 그래프의 값과 실제 값이 다를 수 있습니다.

  3. 게임 서버의 부하의 영향으로 인해

    만약 게임 내 RTT 계산이 실제 게임이 이루어지는 게임 서버를 대상으로 RTT 계산을 한다고 했을 때, 해당 서버의 부하로 인해 차이가 발생할 수 있습니다.

    미꾸라지의 RTT 그래프는 실제 게임 서버를 대상으로 하는 것이 아니라, 해당 게임 서버가 위치한 네트워크 혹은 인근으로 추정되는 네트워크를 대상으로 RTT 계산을 하기 때문입니다.

  4. 게임 서버가 위치한 네트워크 부하의 영향으로 인해

    만약 게임 서버가 위치한 네트워크 단이 많은 트래픽으로 인해 부하가 발생되고 있는 상황에서 미꾸라지 RTT 가 해당 네트워크 단을 대상으로 계산되는 것이 아닌 경우, 그래프의 차이가 있을 수 있습니다.

  5. 현재 사용하고 있는 컴퓨터 자체의 부하로 인해

    드물게도 컴퓨터가 게임을 진행하면서 인해 발생하는 부하로 인해 컴퓨터 운영체제(OS)의 처리 속도가 전반적으로 느려져 RTT 차이가 발생될 수 있습니다.

실시간 핑 그래프가 가끔 3000 으로 나옵니다.​

핑 3000 ms 는 미꾸라지에서는 packet loss 를 뜻합니다. 즉 해당 중계 서버를 통해 필 테스트를 진행하였는데, 어떠한 원인으로 인해 packet loss 가 되었음을 나타냅니다. 이럴 경우 여러 가지 원인이 있을 수 있지만 보통 다음과 같은 경우입니다.

  • 현재 사용하고 계신 인터넷 회선 (ISP) 에서 문제가 있을 경우

    이 경우, "상태 → 중계 서버" 메뉴를 보면 많은 중계 서버와의 RTT 가 문제가 있음을 확인할 수 있습니다. 만약 여러 개의 중계 서버와 문제가 없다면 사용하는 인터넷 회선의 문제가 아닐 수 있습니다.

  • 사용하고 있는 중계 서버가 문제가 있을 경우.

    이럴 경우는 중계 서버를 변경하여 시도를 해 보실 수 있습니다.

  • 게임 서버 쪽 네트웍이 문제가 있을 경우

핑이 전부 3000 이라고 나와요​

보통 이 문제는 1) 현재 사용하고 계신 네트워크 환경에 방화벽이 존재하여 '사용자 ↔ 중계 서버'간의 RTT 를 측정하지 못해서 생기거나, 2) 미꾸라지 서버 문제로 인해 '중계 서버 ↔ 게임 서버'간의 RTT 를 측정하지 못해서 생길 수 있습니다.

1 번 문제로 판단될 경우 다음과 같이 하셔서 문제를 해결할 수 있습니다.

  • 미꾸라지 UI 상에서 '설정 → 프로그램' 메뉴에 들어가시면 'RTT 검사 방법'이 있습니다. 이 설정을 ICMP, TCP, UDP 중 기존과 다르게 설정하시고 미꾸라지를 재시작해보시기 바랍니다.

2 번 문제로 판단될 경우, 미꾸라지 포럼에 글을 남겨 주시면 제가 수정해 드릴 수 있습니다.

Footnotes​

  1. 미꾸라지를 실행하였음에도 불구하고 전혀 핑 변화가 없다면 체크해 보아야 할 항목입니다. 게임을 하는 도중 대쉬보드의 '실시간 트래픽 현황' 그래프가 움직이고 있는지 혹은 그대로 멈춰져 있는지 확인해 보셔야 합니다. ↩

  2. '자동 선택'으로 되어 있다면 다른 중계 서버를 수동으로 설정하셔서 테스트를 해보시기 바랍니다. ↩

  3. 사용하고 계셨던 중계 서버가 일시적으로 네트웍 상황이 안좋을 수 있습니다. ↩

  4. 1 개의 중계 서버를 통해 Network Congestion 구간을 우회하는 것이 힘들 경우, ADN 모드를 사용하셔서 2 개의 중계 서버를 거치도록 할 수 있습니다. ↩

  5. 만약 게임 자체가 TCP 프로토콜 기반의 게임이라면 FastConnect 를 이용하여 시도해 보시는 것도 좋습니다. ↩

  6. 만약 기본값인 UDP 를 사용해도 문제가 없다면 '''전혀''' TCP 를 사용하실 이유가 없습니다. ↩