이 섹션의 문서

더보기

Photon Cloud와 Latency, 네트워크 지연

Photon 運営事務局
  • 업데이트 시간
팔로우

Photon Cloud와 Latency, 네트워크 지연

네트워크 구조 영역, 특히 서버를 포함한 네트워크상 활동에는 데이터 전송에 관한 문제가 다양하게 발생하기 마련입니다. 이 영역에서 흔히 볼 수 있는 네트워크 지연(회전 지연), 즉 Latency가 온라인 게임에 미치는 영향, 그리고 이에 대한 개선 여지에 관해 알아보겠습니다.

데이터 패킷 전송에 소요되는 시간이 바로 Latency입니다.

지연 Latency란 무엇인가?

Latency의 정의는 하나의 데이터 패킷이 한 지점(출처 지점)에서 다른 지점(도착 지점)으로 전송되어 이에 소요되는 시간을 지연 Latency라 합니다. 보통 msec를 단위로 사용합니다.

네트워크 지연이란 정보나 데이터 패킷을 출처 지점에서 도달 지점까지 전송하는 데 소요되는 시간을 말합니다. 그러나, 해당 정의는 수많은 복잡한 원인을 간소화한 것으로, 내부적으로는 네트워크 하드웨어와 관련된 기술 방면의 문제가 적지 않게 존재하며, 네트워크상 운영하는 시스템별로도 네트워크 지연을 초래하는 원인이 적지 않게 발생합니다.

모든 응용프로그램을 개발할 때는 사용자들이 쉽고 편리하게 사용하고 체험하며 자신이 처리해야 할 일에 집중할 수 있도록 반드시 Latency를 짧게(100ms 미만이 가장 적합) 설정해야 합니다. 특히, 네트워크에 관련된 많은 게임 개발에 있어 이러한 문제 발생의 심각성이 쉽게 나타나고 있어 프로그램 개발과 설계 단계별로 네트워크 지연을 유의해서 통제해야 합니다.

물론 이러한 네트워크 관련 문제는 Photon Server가 모두 기본적으로 최적화해 처리하기 때문에, Photon Server/Cloud 사용법만 파악한 후 게임 설계에 집중하면 됩니다!

Latency 발생 요인

네트워크 지연(Latency) 요소

네트워크에는 인터넷 공유기인 라우터가 다양하게 존재합니다. 네트워크 데이터 패킷 전송 전용이긴 하나 일반적으로 일부 요소가 지연을 초래합니다. 그 유형은 다음과 같습니다.

  • Transmission Delay: 전송 지연
    네트워크 카드는 데이터를 네트워크 라인으로 전송(또는 네트워크에서 수신)하는 데 소요되는 시간으로, 이는 네트워크 설비의 전송 속도와 관련이 있습니다. (예로, EtherNet 전송 속도=100Mbps)
    대역폭=L(bit), 데이터 전송 속도=R(bit/sec), 전송 지연=L/R
  • Propagation Delay: 전파 지연
    데이터 패킷은 네크워크상 전송 시 소용되는 시간값과 네트워크 라인 자체의 전자 신호 전송 속도의 영향으로, 전송 거리를 신호 전송 속도로 획득한 수치로 나누면 전파 지연 시간이 산출됩니다.
    전송 거리=d, 전송 속도=s, 전파 지연=d/s
  • Nodal Processing Delay: 노드 처리 지연
    라우터 자체 작업인 데이터 패킷 헤더(packet header) 처리, 비트 데이터 오류 및 적절한 유통 경로 찾기 등, 이러한 작업 진행 시 소요되는 시간이 바로 해당 노드의 처리 지연 시간을 의미합니다.
  • Queuing Delay: 큐 지연
    라우터가 어떠한 원인으로 데이터 패킷을 바로 네트워크로 전송할 수 없을 때 패킷은 일시적으로 큐(queue)에 머무르게 되며, 대기 후 재전송됩니다. 이때 지연된 대기 시간이 바로 큐 지연입니다.

네트워크 지연(Latency) 구성

  1. Transmission Delay, 전송 지연은 네트워크 설비의 데이터 전송 속도로 결정되며 서버-클라이언트 간 거리와는 무관합니다. 따라서, 우리가 두 라인의 네트워크를 사용할 때 둘 중 한 라인의 속도가 10Mbps고 다른 한 라인은 100Mbps일 때, 이 두 네트워크로 각각 10Mb 파일 데이터를 전송한다면, 첫 번째 10Mbps 네트워크에서는 데이터 전송 시 1초가 걸리고 100Mbps 네트워크에서는1초가 소요됩니다. 이렇게 두 라인 간의 지연도 10배 차이가 나게 됩니다.
  2. Propagation Delay, 전파 지연 시간은 신호의 전송 거리와 전송 매개체로 결정되지만, 네트워크 신호 전달 속도는 빛의 속도보다 다소 떨어지는 정도로, 다른 지연 시간과 비교할 경우 보통 매우 작은 값이므로 때로는 산출하지 않기도 합니다.
  3. 공유기 라우터는노드 처리 지연에 해당하며, 네트워크 패킷을 라우터로 전송할 때 라우터에서 패킷 헤더를 검사하여 패킷을 어디로 전송할지 결정하게 됩니다. 패킷 헤더 이외에도 때때로 패킷 내부의 데이터 일부를 검사하기도 하는데 검사 과정에 어느 정도의 시간이 필요하고, 이 과정이 하드웨어에서 직접 처리되어 소요 시간이 적게 들더라도 약간의 시간 지연이 발생하게 됩니다.
  4. 그밖에 데이터 패킷을 라우터로 전송할 때 속도가 빠르면 라우터에서 제때 처리하지 못해 해당 패킷이 일시적으로 완충 구역인 큐에 머무르며 대기하게 됩니다. 해당 대기 기간에 소요되는 시간을 Queuing Delay, 큐 지연이라고 합니다.

패킷을 네트워크상에서 전송할 때마다, 4가지 유형의 지연이 발생합니다. 출발지와 목적지 간의 전송 거리가 멀수록 전파 지연이 커지고, 전송 과정에서 비교적 많은 라우터를 경과하게 되면 노드 처리 지연과 전송 지연도 길어지게 됩니다. 네트워크상 부하량이 높을 경우에도 비교적 높은 확률로 라우터에서 처리하지 못한 패킷이 큐에 머무르게 되어 큐 지연 시간이 증가합니다. 😱

여러 요소로 인해 초래되는 이러한 지연 시간이 바로 일반적으로 온라인 게임에서 자주 듣던 클라이언트와 서버 간의 네트워크 지연인 Latency입니다. 👻

Latency 측정 방법

Linux와 MacOS에서 traceroute 명령으로 검사해 볼 수 있습니다. Windows에서는 tracert를 사용할 수 있는데, 이들의 주 기능은 바로 패킷이 IP 네트워크에서 경과하는 라우터의 IP 위치, 패킷 용량 및 시간을 추적하는 것입니다.

패킷마다 동일한 출처 지점(Source)에서 같은 목적지(Dest)로 전송되는 과정이 매번 같지는 않으나 대부분 동일한 경로를 거쳐 진행됩니다. TraceRoute는 장치 노드마다 세 차례 패킷을 전송하기 때문에 동일 노드에서 세 개의 지연 시간(msec로 산출)을 확인할 수 있습니다.

Translating "www.google.com"...domain server (168.95.192.1) [OK]

Type escape sequence to abort.
Tracing the route to www.google.com (64.233.187.106)

  1 TPDB-3516.hinet.net (210.65.161.22) 0 msec 4 msec 0 msec
  2 TPDT-3011.hinet.net (220.128.1.146) 4 msec 4 msec 4 msec
  3 tyfo-3012.hinet.net (220.128.9.81) 4 msec 4 msec 4 msec
  4 220-128-8-173.HINET-IP.hinet.net (220.128.8.173) 0 msec 0 msec 4 msec
  5 72.14.205.102 4 msec 4 msec
    72.14.196.3 4 msec
  6 108.170.244.34 0 msec
    108.170.244.99 4 msec 4 msec
  7 108.170.238.245 72 msec 28 msec
    209.85.249.1 0 msec
  8 72.14.238.136 8 msec
    108.170.235.215 4 msec
    72.14.232.139 8 msec
  9 209.85.245.68 12 msec
    216.239.50.45 8 msec
    209.85.245.16 4 msec
 10 * * *
 11 * * *
 12 * * *
 13 * * *
 14 * * *
 15 * * *
 16 * * *
 17 * * *
 18 www.google.com (64.233.187.106) 4 msec 8 msec 4 msec

위와 같은 수치는 hinet.net - google.com 간의 경로와 시간으로, 타이베이의 엔진룸에서는 Hinet.net - Google.com 사이에 대략 4~8ms가 산출되고, 만약 대만에서 Photon Server를 가설하는 경우라면 가장 먼저 엔진룸을 선택하는 것이 좋습니다!

Photon Cloud 서버의 패킷 전송 Latency를 검사할 때도 Ping 명령으로 본체와 다른 IP에 연결한 패킷을 주고받은 시간을 보거나 일부 서버의 온라인 상태를 조회해 볼 수 있습니다.

$ ping www.google.com
PING www.google.com (74.125.203.103): 56 data bytes
64 bytes from 74.125.203.103: icmp_seq=0 ttl=44 time=24.826 ms
64 bytes from 74.125.203.103: icmp_seq=1 ttl=44 time=24.994 ms
64 bytes from 74.125.203.103: icmp_seq=2 ttl=44 time=25.145 ms
64 bytes from 74.125.203.103: icmp_seq=3 ttl=44 time=25.304 ms

--- www.google.com ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 24.826/25.067/25.304/0.177 ms

위와 같은 수치는 타이베이의 HiNet ADSL에서 google.com으로 연결 시 ping 값으로,  round-trip 패킷의 전송 왕복 시 최소, 평균, 최대 시간 유형의 수치가 대략 25ms임을 확인할 수 있습니다.

그렇다면 타이베이에서 Photon Cloud 클라우드 엔진룸에 연결한 아시아/일본 등의 나라에서는 시간이 얼마나 소요될까요?

이는 PUN에서 제공하는 PhotonNetwork.GetPing()으로 찾아볼 수 있으며, 실시간 Round-Trip 패킷 왕복 시간을 반환할 수 있기 때문에, 해당 수치는 클라이언트에서 서버로 전송한 후 다시 클라이언트로 전달한 수치입니다!

void Start () {
  Connect();
  InvokeRepeating("UpdatePing", 2, 2);
}

void Connect() {
  PhotonNetwork.ConnectUsingSettings("PUN_PhotonCloud_1.0");
}

void UpdatePing() {
  int pingRate = PhotonNetwork.GetPing();
  Debug.Log( "Ping: " + pingRate );
}

위와 같은 Unity + PUN 프로그램 코드로 타이베이에서 측정한 Photon Cloud의 아시아 및 일본 두 곳의 Ping 값은 다음과 같습니다.

1.png

Photon Cloud — 아시아 지역 — 타이베이에서 측정

2.png

Photon Cloud — 일본 지역 — 타이베이에서 측정

Photon Cloud의 아시아 지점은 싱가포르에 있고, 일본 지점은 도쿄에 있습니다. 이 두 번의 간단한 테스트를 보면 타이베이의 Hinet ADSL에서 일본 도쿄로 연결하는 것이 싱가포르보다 더 빨라 보입니다!

따라서, 여러분 모두 자체적으로 검증해보시고 어떤 연결 방법이 좋은지 알아본 후 프로그램 중 PhotonNetwork.ConnectToRegion(region, gameVersion)으로 직접 연결하고 싶은 구역을 설정해보거나, PhotonNetwork.ConnectToBestCloudServer를 이용하면 자체적으로 검사 후 가장 좋은 구역으로 자동 연결됩니다!

주의해야 할 점은 우리가 네트워크를 신청할 때 대규모 네트워크 대역폭을 설치해 사용하긴 하나 규모가 크다고 해서 전송 품질 자체의 안정도를 보장할 수 없다는 것입니다. 때로는 네트워크 막힘, 장치 고장, 해커 공격 등의 원인으로 대역폭과 지연에 영향을 미치기도 합니다. 현재의 네트워크 기술 분야에서 상황별로 일어나는 모든 일이 연구 과제이고, 이러한 상황 변화의 사전 예측, 처리, 관리 조정하는 방법 등 모두 매우 복잡하게 변화하고 있습니다.

Latency 개선 방법

네트워크에서 흔히 보이는 마지막 1마일 문제, 즉 우리의 연결 설치 장치(클라이언트 또는 서버)와 연결하려는 ISP와 관련된 문제는 기관별 ISP에서 사용하는 엔진룸 장치 기술, 네트워크 구조, 토폴로지 등 각각의 요소를 고려해볼 때, 모든 ISP가 동일하지는 않습니다.

심지어 지금까지도 여전히 연관된 모든 시간과 장소에서 함께 할 것입니다. 단지 네트워크 속도를 빠르게만 하고 싶다면 네트워크 지연이 비교적 낮은 ISP를 선택하는 것이 좋은데, 대만의 전체 네트워크 속도가 주변 국가보다 더 느리기 때문에 그다지 좋은 선택은 없습니다.

과거 연구에 따르면 온라인 게임 지연 시간이 100 ~ 200ms 사이일 경우, 약간의 지연(lag)을 감지할 수 있고, 최대 300ms 내에서는 좀 더 심한 지연을 감지하게 되는데… 지연 시간이 1,000ms(1초)일 때는 주의력이 다른 곳으로 전환되기 시작해 게임 일시 중단, 게임 나가기 및 재연결 시도 등의 다른 행동을 하기 시작한다고 합니다!

따라서 대만에서 일본까지 Photon Cloud로 연결 시 오가는 Ping 수치가 100ms 미만인 기술인데 사용하지 않을 수 있겠습니까? 😃

만약에 네트워크 게임 프로그램 성능을 향상시키고 싶다면 게임 구조를 설계할 때 사용하는 통신 프로토콜과 방식에서 사용하는 네트워크를 최적화해야 합니다. 예를 들어, 장거리 네트워크 전송 작업을 줄이거나, 데이터를 최대한 클라이언트 쪽에 가깝게 하거나, 빠른 데이터 전송을 가능케 하는 캐싱, 음향과 빛 효과(FX) 방식처럼, 네트워크 지연을 프로그램 처리나 주의력으로 숨길 수 있습니다. 이런 기술은 다음 문서나 범례에서, 자세히 설명해드릴 테니 많이 기대해주세요!

 

관련 문서

댓글

댓글 0개

댓글을 남기려면 로그인하세요.