[TIL][C++] 251022 MMO 서버 개발 120일차: 레이턴시(Latency)와 핑(Ping)의 차이, 그리고 Lag에 대해서, MaxLatency를 활용한 동기화 전략

주의사항: 해당 글은 일기와 같은 기록용으로, 다듬지 않은 날것 그대로인 글입니다. 

레이턴시(Latency)와 핑(Ping)의 차이

• 핑(Ping)은 레이턴시를 측정하는 도구 또는 행위.
• 레이턴시(Latency)는 그 측정으로 얻어진 결괏값. 즉, 지연 시간(ms)이다.

 

핑(Ping)에 대한 보다 자세한 설명

• 핑은 레이턴시를 측정하기 위해 사용되는 유틸리티 프로그램 또는 명령어.
• 명령어 ping은 네트워크 장치(클라이언트)가 다른 장치(서버)로 ICMP 에코 요청을 보내고, 서버가 다시 ICMP 에코 응답 패킷을 되돌려 보내도록 하는 행위를 한다.
• 핑이 측정하는 것은 RTT이며, 많은 경우 RTT를 레이턴시라고 칭한다.
  • 구문 예시: “내 컴퓨터에서 핑을 해봤더니 레이턴시가 10ms가 나왔다.”

 

게임에 표시되는 네트워크 지표는 무엇을 의미하는가? ⇒ 대부분 RTT를 의미!

• 위 사진처럼 LOL에는 ms단위의 네트워크 성능 지표가 있다. 이 성능 지표는 무엇일까 궁금해할 수 있는데, 이 성능 지표는 RTT를 의미, 즉, 통상 레이턴시라고 부르는 그 녀석이다.
  • 16ms라고 적혀있으니 클라이언트와 서버를 왕복으로 오가는 시간이 16ms정도 소요되었다는 것을 알 수 있다.
• 비단 LOL 뿐만 아니라 다른 게임들에서도 ms단위의 네트워크 성능 지표를 표시하는 경우들이 있는데, 대게 똑같이 RTT를 의미하게 된다.

 

어느 정도의 레이턴시가 낮은 레이턴시인가?

• 게임의 장르를 떠나서 단순 네트워크 상태를 진단했을 때 레이턴시가 낮을수록 상태가 좋다고 평가할 수 있다.
• 그런데 어느정도로 낮아야 게임하는데 지장이 없는지는 또 이야기가 다르다. 지장이 생길지 판단하고 싶다면 아래 구분을 참고하자.

 

레이턴시에 따른 쾌적함 정도(RTT 기준임)

• 0~20ms: 매우 쾌적함. 게임플레이에 있어 문제가 없다.
• 20ms~50ms: 충분히 쾌적함. 가끔 아주 약간의 딜레이가 있을 수는 있음
• 50ms~100ms: 플레이가 가능하긴 하나, 경쟁적인 게임에서는 렉이 있음을 인지하고 플레이해야 할 정도
• 100ms+: 빠른 속도의 물체가 있는 게임(Ex. FPS, MOBA, Racing)은 플레이 불가능에 가까움.
• 200ms+: 실시간 이동 동기화가 들어가는 모든 게임 플레이 불가능(답이 없는 수준)

---

레이턴시 예측을 위한 척도 - 지구 반대편과의 통신 시 RTT는 몇 ms?

• 지구 둘레는 약 40,075km. 즉, 왕복 전송 거리가 40,075km라는 것.
• “진공 상태”의 빛의 속도가 약 300,000km라는 것을 감안했을 때 순수 거리만 따지면 RTT는 133~134ms.
• 현실적으로 따지면 광섬유 사용 + 진공이 아닌 환경 + 라우팅 시간 + 서버 레이턴시 등이 포함되므로 약 200ms로 추정됨.

 

결론

• 지구 반대편과의 통신은 약 200ms로 추정됨.
• ⇒ 대한민국이라는 쪼그마한 땅에서 통신하는 경우 순수 물리적 거리 때문에 50ms 이상 나오는 경우는 없다고 보면 된다.

---

유저가 느끼는 실질적 지연 시간은 Latency가 아닌 Lag!

• Latency만이 지연을 만들어내지 않는다. 정말 다양한 이유로 다양한 곳에서 지연이 발생할 수 있다. 따라서, 전체적인 지연 시간을 따져야 실제로 유저가 느끼는 지연 시간을 가늠할 수 있는데, 그것이 바로 우리가 자주 말하는 Lag이 다.
• Lag은 사용가자 체감하는 총 지연 시간을 의미하므로, Latency는 Lag에 포함되는 지연 시간이다.

 

Lag에 포함될 수 있는 여러 요인들

• 서버 로직 처리 Latency
• Input Latency(키보드 입력 처리)
• 네트워크 Latency(물리적 거리, 회선 품질 포함)
• 그래픽 Latency(렌더링 지연)

 

---

MaxLatency를 활용한 동기화 전략

• 대부분의 경우, 클라이언트들의 레이턴시는 제각각이다. 즉, 동시간에 스킬을 시전해도 레이턴시가 높은 유저는 낮은 유저보다 늦게 스킬 발동 결과를 받는다.
• 서버를 개발하는 사람들은 공정한 환경을 만들어야 할 책임이 있으므로, 같은 시간에 스킬 발동 결과를 받을 수 있도록 해야 한다. 이때 사용할 수 있는 전략이 MaxLatency이다.

 

MaxLatency를 활용하는 과정

• 레이턴시를 구하기 위해 각 클라이언트의 RTT를 계산한다.
• RTT 중에서 가장 높은 RTT를 MaxLatency로 지정.
• 각 클라이언트에게 MaxLatency를 넘겨주고, 클라이언트들은 MaxLatency를 활용해 각 이동 패킷이 적용될 타이밍을 뒤로 미룬다.

 

뒤로 미루는건 어떻게?

• 이동 패킷이 바로 적용되면 안 되니 패킷이 오면 MoveQueue에 넣어놓기만 한다.
  • MoveQueue는 우선순위 큐임
• 클라이언트는 매 프레임마다 Tick함수를 실행할 텐데, 이때마다 MoveQueue에서 가장 앞에 있는 타임스탬프와 (현재시간 + MaxLatency)를 비교한다.
  • 만약 타임스탬프에 찍힌 시간이 적거나 같으면 pop 하고, 다시 확인하며 반복한다.
  • 만약 타임스탬프에 찍힌 시간이 크면 무시한다.

 

자유 필드(즉, 사냥터)에서 MaxLatency 이동 동기화 전략을 사용하는 것이 옳을까?

• 개인적으로 그렇지 않다고 본다. MaxLatency 이동 동기화 전략을 사용했을 때 장점도 있지만, 분명 단점도 있기 때문. 자유 필드에선 단점이 더 크게 다가올 것으로 느껴진다. MaxLatency 적용 시의 장단점을 이야기하자면 아래와 같다.
  • 장점: 필드 내(또는 동기화 해야 할 대상) 플레이어들의 각 클라이언트는 동시간대에 같은 패킷이 실행된다.(먼저 받는 클라이언트가 있을 순 있어도 Extra Latency를 더 크게 받기 때문에 동시간 실행)
  • 단점: 다른 플레이어의 레이턴시가 나보다 높다면 내가 그만큼 Extra Delay를 먹는다. ⇒ 게임플레이 경험 떨어지게 됨
• 자유 필드의 경우, 생판 모르는 사람의 높은 레이턴시 때문에 내가 스킬이 늦게 나가는 것은 불합리하다고 생각됨. 그래서 최소한의 Extra Delay를 먹이거나 아예 무시하는 게 답.

 

최소한의 Extra Delay를 먹인다는 건 어떤 걸 말하는가?

• MaxLatency가 아닌 AverageLatency를 사용하거나, 고정된 레이턴시를 초과하여 딜레이를 먹지 않도록 하는 방식을 말한다. 이렇게 딜레이를 먹이면 딜레이가 훨씬 적게 먹기 때문에 스킬이 좀 더 빠릿빠릿하게 날아가게 된다.