# 4장 \~ 6장

## 4장 게임 서버와 클라이언트

### 4.6 게임 서버의 품질

서버 불안정 극복 방법

* 서버가 죽더라도 최대한 빨리 되살린다 : 중지되면 감시 프로그램이 서버 재실행
* 서버가 죽더라도 최대한 적은 서비스만 죽는다 : 프로세스 여러개 띄운다. 비상용 서버를 둔다.
* 오작동에 대해 기록을 남긴다

수직적 확장

* 서버 하드웨어 좋은걸로 바꾸기
* 소프트웨어 설계 비용은 낮지만, 확장 비용이 높다

수평적 확장

* 서버 머신의 개수를 증설한다
* 설계 비용 높고 확장 비용 낮다

성능만 좋고 확장성 나쁘면 사용자 수 늘어날수록 연산 처리 시간 오래 걸림 확장성만 좋으면 게임 사용자 수 상관 없이 처리 시간 일정하게 큼

게임 서버 성능 높이기

* 기본 원칙 : 서버 단위 처리 속도 높이기
* 코드 최적화나 알고리즘 최적화
* 연산을 클라에 미리 맡긴다
* 더 빠른 속도로 실행되는 언어 쓴다
* 코드 프로파일링으로 과부하 영역 찾은 뒤 분산한다 (ex. 길찾기 담당 서버)
* 네트워크 프로토콜 최적화
  * 메시지 양을 줄인다
  * 메시지 압축한다 (잠깐 정밀도 낮춘 후에 받았을 때 다시 해석 등)
  * 메시지 교환 횟수 줄인다
* 노품질 네트워크 회선 가진 데이터 센터에 서버 설치
* 지리적으로 가까운 데이터 센터에 서버들 분산 설치
* 서버 거치지 않고 클라끼리 직접 통신하게 한다
  * 일부 공유기(NAT 라우터)는 클라끼리 통신 못해서 릴레이 서버 있어야 할 때도 있음

서버 관리 도구

* 게임 서버는 콘솔 앱이므로 상호작용 불가
* 프로그램 켜지면 백그라운드에서 자동 실행 : 서비스(윈도), 데몬(리눅스)
* GUI 앱, 콘솔 앱, 웹앱 등으로 원격 관리 프로그램 따로 만든다
  * 서버 켜기/ 끄기
  * 동접자 수 보기
  * CPU, RAM 사용량 보기

### 4.7 플레이어 정보의 저장

데이터베이스 소프트웨어 장점

* 데이터 관리와 분석 쉽다. 특정 조건 만족 데이터 빠르게 찾기 가능.
* 데이터 복원 강력하다. 변경 사항을 1개 이상의 사본 저장소에 보관 가능.
* transaction으로 원자적 변경 가능. 전부 바꾸거나 아예 바꾸지 않거나.
* 데이터 일관성 유지시켜줌. 경험치 음수 막을 수 있다.
* lock으로 한 데이터가 여러 데이터 액세스 시 결과 이상해지는거 막아줄 수 있다.
* 장애 내성 강하다. 데이터 기록 전 로그 버퍼에 할 일 기록 후 적용하는데, 갑자기 꺼지면 로그 버퍼에서 마저 안 한 일 찾아서 복원한다.

## 5장 게임 네트워킹

### 5.2 게임 플레이 네트워킹

레이턴시가 길어지는 요인

* 서버가 멀리 있음
* 클라우드 서버에서 다른 가상 머신이 CPU 사용량 잠식
* 패킷 드롭으로 인한 재송신 (간헐적인 큰 지연 시간)
* 인구 낮은 국가는 인터넷 느림
* 무선 네트워크는 레이턴시와 패킷 드롭률 크게 증가

추측항법 (dead reckoning)

* 상대방 움직임을 어느 정도 예상해서 보정
* 두 기기 간의 레이턴시 알고 있어야 함
  * 라운드 트립 레이턴시 측정 방법 : 보낸 후에 응답 다시 받은 시간 2로 나눈다
* 위치와 속도로 미래 보정
* 예측 틀렸을 때 점프 해결하기 위해 타깃이라는 쫓아가야 할 대상 새로 만든다

### 5.3 레이턴시 마스킹

일정 시간마다 서버가 클라에 이동 정보 보내는 식이면 인터넷 안 빠를 때 답답. 약간의 지연 후 움직이기 때문.

플레이어가 조종하는 캐릭터는 클라가 직접 판단하게 하면 해결. 하지만 클라 해킹해서 이동 핵 쓴다면?

해결 1

* 클라가 이동 정보를 서버에 보낸다
* 서버는 이동 정보 받아서 값이 정상인지 확인한다

해결 2

* 클라가 플레이어 명령 정보 서버에 보낸다
* 클라는 자기 캐릭터를 일방적으로 움직인다. 이동 정보는 안 보낸다.
* 서버는 명령 정보에 따라 캐릭터를 이동한다
* 클라가 서버에서 이동 정보 받으면 앞서 움직임 무시하고 서버 메시지 따라 이동한다

2번째 방법은 해킹 막을 때 좋지만, 레이턴시 100밀리초 넘을 때마다 캐릭터 움직임 손상됨. 각 메시지 레이턴시가 균일하고, 레이턴시가 50밀리초 이하로 낮은 경우에 한해 채택한다.

해결 3 (일단 보여주고 나중에 처리)

* 플레이어가 어떤 행동 하면 행동 명령 서버에 보낸다. 행동하는 연출 클라에서 시작.
* 서버에서 행동 명령 받아 처리하고, 클라에 메시지로 보냄
* 클라가 메시지 받으면 연출할 나머지 부분을 클라에서 보여준다

디아3에서 플레이어가 공격 명령 키 입력하면 일단 공격하는 모션 취하는 예시.

### 5.4 넓은 월드, 많은 캐릭터 처리

캐릭터 많아도 보이는 영역에 있는 것들만 보내주면 된다

### 5.5 실시간 전략 시뮬레이션 게임에서 네트워크 동기화

rts는 캐릭 수 많아서 통신량 증가. lock step 동기화 알고리즘 사용.

구동 원리

* 각 플레이어가 다른 플레이어들에게 입력 명령
* 입력 명령 따라 모든 클라가 동시에 씬 업뎃

얻는 효과

* 입력 명령만 주고 받으며, 이동 상태 주고받지 않음
* 입력 명령은 통신량이 상대적으로 매우 적음

(이해 위한) 원시적 작동 방식

* 네트워크 지연 시간 없다 가정, 게임은 1/60초마다 업뎃
* 각 컴퓨터 게임 월드가 명령 받으며 업뎃하여 100% 항상 같은 상태
* 해킹 방지 위해 월드 상태 체크섬 계산하여 송신
* 모든 기기에서 메시지(명령, 시간, 체크섬) 온 후에야 게임 월드 업뎃

통신 레이턴시 문제 해결 위해 '언제 실행할 지 미래 시간' 같이 보낸다 미래 시간 : 현재 시간 + 왕복 레이턴시(RTT)/2 + 임의의 일정 값

rts에서의 레이턴시 마스킹

* 입력 명령 처리 못했어도 명령 반응 연출만 보여줌
* 이후 미래 시간에 도달하면 실제로 캐릭터 움직임

락스텝 한계

* 다른 플레이어 중간 난입 만들기 까다로움
* 게임 플레이에 관여하는 연산에 부동소수점 쓸 수 없음. (하드웨어 종류에 따라 연산 결과 차이나기 때문)
* 통신량이 플레이어 수 비례하여 증가하기 때문에, 플레이어 수 많아지기 어려움.
* 씬 업데이트 일시 정지 확률 높음
* 입력 명령 속도에 민감한 게임에 부적합. 필연적으로 행동은 미래 시간이 돼야 움직이기 때문.

### 5.6 실제 레이턴시 줄이기

* TCP 대신 TDP 사용. 캐릭터 이동 메시지는 1초에 여러 번 오기 때문에 패킷 유실 극복 가능.
* 똑같은 양 데이터 보내도 패킷 수 적게 하는게 좋음. 1초에 메시지 100개 보내면 뭉쳐서 보낸다. (뭉치는 시간은 10밀리초 이하가 적당)
* 클라-서버 통신과 클라끼리 통신을 섞어 쓴다


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://lazyartisan.gitbook.io/note/main-page/books/undefined/4-6.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.