게임 네트워킹

모든 역할을 서버에서 하기

• 클라이언트가 하는 역할

1. 사용자 입력(키 입력, 마우스 좌표)
2.  화면 출력

• 서버에서 하는 역할

1. 게임 로직 연산
2. 화면 렌더링 (그래픽 데이터 보유)
3. 화면 송출(비디오 스트리밍)

 

온라인 게임을 방해하는 레이턴시가 길어지는 요인

1. 서버가 멀리 있으면 네트워킹 중에 레이턴시가 추가됨
2. 클라우드 서버 안에서 가상머신은 다른 가상머신이 CPU 사용량을 잠식하면서 조금씩 지연 시간이 있을 수 있음
3. 패킷 드롭으로 인한 재송신은 간헐적인 큰 지연 시간을 일으킴
4. 인구가 낮은 국가에서는 인터넷이 느림
5. 무선 네트워크에서는 레이턴시와 패킷 드롭률이 크게 증가함

 

서버 운영의 경제성 문제

1. 고퀄리티 그래픽을 60프레임으로 렌더링하려면 그래픽카드 하나가 모든 능력을 동원해야 함
   (서버에서 이것을 하려고 하면 서버에 접속해 있는 사용자 수만큼 그래픽 카드를 동원해야 할 것임)
2. 일반적인 MMORPG 서버 컴퓨터는 플레이어 처리를 2000개에서 2만 개까지 해야 제대로 경제성이 나옴

ex) 구글 스타디아, PS4 GaiKai, NCSoft 퍼플

 

렌더링은 클라이언트에서 하기

• 서버와 클라이언트가 하는 역할
• 서버와 클라이언트 간의 대화

 

클라이언트에서 서버로 보내는 플레이어가 취하는 행동 명령 메시지

1. 채팅 메시지 입력
2. 플레이어를 특정 방향으로 이동하라고 명령
3. 플레이어가 이동을 멈추라고 명령
4. 특정 아이템을 사용하라고 명령

 

서버에서 클라이언트로 보내는 월드 상태 변화 메시지

1. 캐릭터 등장 (데이터 추가)
2. 캐릭터가 특정 방향으로 이동 (데이터 변경)
3. 캐릭터가 웃음 (데이터 변경)
4. 캐릭터가 사라짐 (데이터 소멸)

 

단발성 이벤트

• 특정 좌표에서 수류탄이 터짐

 

단발성 이벤트를 지속성 이벤트로 만들 때

1. 특정 좌표에 수류탄이 생김
2. 수류탄이 터짐
3. 수류탄이 사라짐
4. 파티클 1초 모습
5. 파티클 2초 모습
6. 파티클이 사라짐

 

해결해야 할 문제

1. 서버에서는 1/60초마다 월드 상태를 업데이트 함
2. 서버는 1/60초마다 월드 상태의 변화를 클라이언트에 보냄
3. 클라이언트는 이를 지체 없이 받음
4. 클라이언트는 받은 것을 자기의 월드 상태에 반영함, 그리고 다음 렌더링 프레임에서 이를 그림

 

추측항법

: 상대방 움직임을 어느 정도 예상해서 그 위치로 갈 수 있게 보정시키는 방법

• 두 기기 간의 레이턴시를 알고 있어야 함
• 대표적인 측정 방법에는 라운드 트립 레이턴시가 있음

1. 기기 A에서 기기 B에 패킷을 보냄
2. 기기 B는 이를 받으면 기기 A에 패킷을 보냄
3. 기기 A는 1과정의 시간과 현재 시간의 차이를 구하여 2로 나눔

 

레이턴시 마스킹

1. 클라이언트에서 플레이어 캐릭터를 조종하는 명령을 서버에 보냄
2. 서버에서는 플레이어 캐릭터의 이동 연산을 함
3. 일정 시간(1/30초 ~ 1/10초)마다 클라이언트에 이동 정보 메시지를 보냄
4. 클라이언트는 이동 정보 메시지를 받으면 추츨항법으로 플레이어 캐릭터 위치를 부드럽게 만든 후 업데이트 함

• 플레이어 캐릭터가 약간의 시간 지연 후 움직일 때: 사소한 것들은 클라이언트에서 판단

 

일단 보여주고 나중에 얼렁뚱땅하기

1. 플레이어가 어떤 행동을 하면 행동 명령에 대한 메시지를 서버에 보냄, 동시에 행동을 연출하는 일부 모습을 클라이언트에서 즉시 시작함
2. 서버에는 행동 명려을 받아 처리하고, 플레이어 캐릭터에 가해야 하는 행동을 클라이언트에 메시지로 보냄
3. 클라이언트는 이 메시지를 받으면 연출해야 하는 나머지 부분들을 클라이언트에서 보여주기 시작함 

 

가시 영역 필터링

: 서버가 가진 월드 전체 상태 중에서 변화 하는 것 모두를 플레이어에게 보내 줄 필요가 없음, 플레이어의 가시 영역에 있는 것들만 보내도 됨

MMO 서버에서는 필수

• 클라리언트 부하 감소
• 네트워크 트래픽 감소
• 서버 부하 감소 (검색 스페이스 감소)

 

클라이언트가 가지고 있어야 할 정보

• 자기 근처에 있는 다른 캐릭터들 정보

서버가 가지고 있어야 할 정보

• 플레이어 각각에 대해 각 플레이어가 볼 수 있는 캐릭터 목록
• 캐릭터 각각에 대해 자기 자신을 볼 수 있는 플레이어 목록

 

락스텝

: 컴퓨터 프로그램의 같은 상태에 같은 입력을 주면 같은 결과가 나온다는 원리를 응용, 구동 원리는 아래와 같음

• 각 플레이어는 다른 플레이어들에게 입력 명령을 보냄
• 플레이어의 입력 명령에 따라 모든 클라이언트가 동시에 씬 업데이트를 함

락스템으로 얻는 효과

• 각 클라이언트 플레이어의 입력 명령만 주고받으며, 씬을 구성하는 캐릭터의 이동 상태를 주고받지 않음
• 입력 명령은 통신량이 상대적으로 매우 적음

 

전략 시뮬레이션 게임에서 레이턴시 마스킹

1. 실제로 캐릭터는 입력 명령을 처리하지 못했더라도 명령에 반응하는 연출만 보여줌
2. 이후에 미래 시간에 도달하면 실제로 캐릭터가 움직이게 함

 

실제 레이턴시를 줄이는 방법

: TCP 대신 UDP를 사용

• 똑같은 양의 데이터를 보낸다고 하더라도 가급적 적은 수의 패킷으로 보냄
• 클라이언트와 서버 간 통신 (C/S 네트워킹과 클라이언트끼리 직접 통신하는 것(P2P 네트워킹)을 같이 섞어 씀

 

로그인 과정에서 클라이언트와 서버가 대화하는 주요 절차

1. 로그온 요청 메시지를 서버로 전송
2. 서버는 파일이나 데이터베이스에서 해당 유저의 ID와 비밀번호를 받아서 식별
3. 식별 결과, 즉 로그온 처리 결과를 클라이언트에 통보
4. 클라이언트에 통보를 하면서 플레이어 정보를 데이터베이스에서 로딩하여 게임 서버 메모리에 보관

 

게임 플레이 이외의 네트워킹

• 캐릭터를 만드는 과정

1. 클라이언트가 서버에 "내 캐릭터를 만들어라"라고 요청
2. 서버는 데이터베이스에 "새 캐릭터에 대한 데이터 개체, 즉 레코드를 만들어라"라고 요청
3. 데이터베이스는 이에 대해 응답
4. 서버는 클라이언트에 "캐릭터를 만드는 것이 성공했다"라고 알려줌
5. 클라이언트는 서버에 "내 캐릭터 중 OOO를 선택하겠다"라고 요청
6. 서버는 데이터베이스에 "캐릭터 OOO를 선택했다고 기록하자"라고 요청
7. 서버는 클라이언트에 "캐릭터 OOO를 성공적으로 선택했다"라고 알려줌

데이터베이스에 기록하되 그 결과를 기다릴 필요가 없을 때는 데이터베이스에 기록하는 함수를 별도의 스레드나 비동기 함수 호출로 처리

• 수 많은 고객 불만의 원흉이 되므로, 결과를 기다릴 필요가 없는 경우는 거의 없음
• 따로 Overlapped I/O 스타일로 구현
• thread 생성 오버헤드가 너무 크므로 기존 쓰레드들을 이용해야 함

 

매치메이킹_플레이어가 수동으로 방을 만들고, 다른 플레이어가 수동으로 방에 들어가는 방식 설계

1. 해킹을 방지하고자 방 만들기 혹은 들어가기 정보는 클라이언트에서 판단하지 말고 서버에서 모두 판단할 것
2. 클라이언트에서는 일방적으로 판단하지 말고 서버에 요청하여 그 결과에 따라서 행동할 것
3. 방 만들기 혹은 방 들어가기로 서버 내부의 방 목록이나 방 안의 플레이어 목록이 변할 때 클라이언트는 그 변화를 통보받을 것

 

서버에서는 방 목록과 각 방에 들어가 있는 플레이어, 즉 방 안의 플레이어 목록을 갖고 있어야 하며, 게임 플레이 중인 방의 상태 데이터도 갖고 있어야 함

1. 왼쪽 클라이언트는 서버에 "방 하나를 만들어라"라고 요청
2. 서버는 방을 만들고 만든 방을 자신의 메모리에 보관하고 클라이언트에 "방 하나를 만들었다"라고 응답
3. 이미 서버 접속 상태를 유지하고 있던 오른쪽 클라이언트에 "방 하나가 새로 만들어졌으니 너도 알고 있어라"라고 통보
4. 오른쪽 클라이언트의 플레이어는 이 방에 들어가고 싶음, 클라이언트는 서버에 "나는 이 방에 들어가겠다"라고 요청
5. 서버는 오른쪽 클라이언트에 "방에 성공적으로 들어왔다"라고 응답함, 동시에 방 정보와 방에 들어간 왼쪽 클라이언트의 존재도 알려줌
6. 오른쪽 클라이언트가 방에 들어갔음을 왼쪽 클라이언트도 이제 알아야 함, 따라서 서버는 자체 크라이언트에 "오른쪽 클라이언트가 네 방에 들어왔다"라고 통보, 이제 양쪽 클라이언트는 서로의 존재를 알고 있으며, 둘 다 방에 들어간 상태
7. 왼쪽 클라이언트는 서버에 "게임을 시작하자"라고 요청
8. 서버는 오른쪽 클라이언트에 "게임을 시작하라"라고 통보함
9. 서버는 왼쪽 클라이언트에 "게임을 시작하라"라고 통보함

 

게임 로직을 개발하는 과정에서 서버와 클라이언트의 대화 규칙

1. 클라이언트에서는 요청을 보냄
2. 서버에서는 그 요청을 받아 결과를 판단
3. 요청 결과에 영향을 받을 다른 클라이언트가 서버에 있으면 그 클라이언트에 통보

 

아이템 사용하기 과정 설계

1. 클라이언트에서는 사용하는 식별자(ID)를 인자로 담은 메시지를 서버에 전송
2. 서버에서는 해당 아이템을 플레이어가 사용할 수 있는 상태인지 판단해서 아이템 사용 결과를 판정
3. 그 결과를 클라이언트에 알려 주어 아이템이 사용됨을 고지

 

거시적인 흐름을 표현해야 할 때는 시퀀스 다이어그램을 사용하고, 세부적인 로직을 표현해야 할 때는 액티비티 다이어그램을 사용

MMO에서는 아이템 개수 감소를 데이터베이스에 요청하고 감소를 확인 후 계속 진행

 

게임 사용자들이 해킹을 하는 유형

1. 크래킹: 게임 외 분야에서 흔히 이야기하는 해킹

•  다른 사람의 ID와 비밀번호를 도용하거나 비밀 정보를 보는 것을 의미
• 서버에 저장된 데이터를 훼손하거나 훔치는 것도 포함

1. 치트 혹은 조작: 게임에서만 발견되는 형태의 해킹

• 내 능력치를 비정상적으로 높이거나 다른 사람의 플레이를 망가뜨리는 것을 의미

 

네트워크 해킹

1. 해커 Alice가 John과 게임 서버 사이에 있는 네트워크 기기에서 John과 게임 서버 간의 데이터 교환을 도청함
2. John이 게임 서버에 로그인함, 이때 John의 클라이언트는 서버의 ID와 비밀번호를 보냄
3. Alice는 ID와 비밀번호를 도청하는데 성공함

 

해결방법: 암호화

1. 도청 당해도 원래 암호가 무엇인지 알 수 없음
2. 그 때 그 때 암호 키를 바꿔야 함(안그러면 의미 없음)
3. 도청이 아니라 컴퓨터가 해킹당하면 의미 없음

암호화)

평문 + 암호 키 -> 암호문

복호화)

암호문 + 암호 키 -> 평문

 

암호화의 문제

1. 암호키 전달: 클라이언트에 어떻게 전달할 것인가?
2. 클라이언트에 넣어서 배포하면 해커도 암호키를 얻어낼 수 있음
3. 클라이언트마다 암호를 다르게 하려면 어떻게 해야 하는가?

(서버가 접속 후 암호 전달하는 것도 도청 가능)

 

암호 알고리즘

1. Open Source 알고리즘 사용
2. 암호키를 사용한 알고리즘이 주류

 

키 전달 문제 해결법

• 대칭키 알고리즘 사용 (공개키 알고리즘이라고도 불림)
• 대칭키: 암호키1과 암호키2로 이루어진 암호 알고리즘
• 암호키1로 암호화한 것은 암호키2로만 풀 수 있음
• 암호키2로 암호화한 것은 암호기1로만 풀 수 있음
• 암호키1은 공개

평문 + 암호키1 -> 암호문

암호문 + 암호키2 -> 평문

 

클라이언트 컴퓨터 해킹

: 이메일이나 스마트폰 문자 메시지로 악성코드가 들어 있는 첨부 파일이나 인터넷 주소를 보내서 악성 프로그램을 심는 것

• 멀웨어나 바이러스 등이 이에 해당
• 사람들이 사용하는 운영체제나 응용 프로그램의 결함을 이용해 악성 프로그램을 전파하기도 함
• 컴퓨터가 해킹을 당하지 않게 항상 최신 소프트웨어를 유지하고, 불필요한 보안 해제를 하지 말고, 알 수 없는 출처의 프로그램을 실행하지 않아야 함

 

서버 컴퓨터 해킹

: 클라이언트를 해킹할 때와 마찬가지로 서버 쪽 운영체제나 응용 프로그램 결함이나 보안 설정의 구멍을 이용하여 해킹

• 서버 고유의 역할인 웹 서버나 데이터베이스 서버에서는 클라이언트와는 다른 종류의 해킹을 추가로 예방해야 함
• 질의 구문 인젝션 등을 예로 들 수 있음
• 게임 서버에는 일반적인 유저가 접속할 수 있는 리스닝 포트를 제외하고 모두 방화벽으로 막아 버려야 함

 

게임 치트

• 네트워크 도청 및 조작을 해서 해킹하는 경우

1. 어떤 게임에서는 플레이어 캐릭터가 공격을 할 때마다 "플레이어가 공격 행동을 한다"라는 메시지를 서버에 보냄
2. 해커 Alice는 이 메시지를 갈무리하고 이 메시지를 마구잡이로 복제해서 서버에 보냄
3. 서버에서는 이 메시지를 다 처리함, 그리고 Alice는 엄청난 공격 속도로 다른 플레이어들을 모두 제압

 

게임 치트 또한 DDOS 공격과 유사하게 할 수 있음

1. Alice는 정밀하게 조작하지 않아도 되는 플레이어 캐릭터를 가지고 있음
2. Alice는 게임 서버나 다른 게임 클라이언트에 엄청난 양의 네트워크 데이터를 보냄, 그러면 멀티플레이어 품질이 매우 크게 떨어짐
3. 이 상태에서 Alice는 정밀한 컨트롤이 필요한 다른 플레이어들을 상대로 승부 우위를 차지함

게임 클라이언트를 해킹하여 치트를 하기도 함, 클라이언트 내부 데이터를 조작하여 클라이언트에서 처리하는 승부 판정을 조작함