[Teck Interview] 네트워크 및 멀티플레이

클라이언트-서버 모델과 P2P 모델의 차이점

항목	클라이언트-서버 (Client-Server)	P2P (Peer-to-Peer)
구조	중앙 서버가 모든 통신과 상태를 관리	모든 클라이언트가 서로 직접 통신
권위(Authority)	서버가 진실의 기준 (권위)	클라이언트 간 권한 공유 (종종 호스트에게 위임)
보안	상대적으로 안전 (서버 검증 가능)	취약 (해킹/조작에 취약)
동기화	서버 기준으로 일관된 상태 유지	각 클라이언트 상태가 불일치할 수 있음
성능	서버 성능에 의존, 확장성 필요	지연이 적을 수 있지만 불안정 가능성 있음
호스팅 비용	서버 인프라 필요 (비용 높음)	서버 불필요 (비용 절감 가능)

 

클라이언트-서버 모델

장점

- 일관된 상태 유지

- 보안 관리 쉬움

- 데이터 저장 용이

 

단점

- 서버 운영 비용

- 서버 지연 시 전체 영향

P2P 모델

장점

- 빠른 반응 속도

- 서버 비용 없음

단점

- 보안 취약

- 호스트 유저 나가면 게임 중단

- NAT, 방화벽 등 네트워크 연결 문제 가능

 

리슨 서버?

클라이언트-서버 모델과 P2P 중간 형태

한 플레이어가 클라이언트이자 동시에 서버 역할

 

---

 

패킷 유실 시 클라이언트 대응 전략

- TCP or Reliable UDP => 아크를 비롯한 신뢰성 있는 통신 TCP 단에서 알아서..

- 예측 및 보간: 이전, 다음 패킷 기준 추측 보간 (이동/회전같은 건 유실을 허용해도 됨)

- 중복 패킷 처리: 패킷 유실을 감안하여 중복 데이터를 여러 번 전송

 

---

 

RTT가 높아지면 클라이언트에 발생하는 현상?

 

RTT(Round Trip Time)

- 클라이언트가 서버로 데이터를 보내고 응답을 받기까지 걸리는 시간

현상	설명
입력 지연	눌렀는데 늦게 나감
텔레포트/워프 현상	위치 동기화 지연/보정 실패
판정 오차/판정 밀림	총알, 스킬 등 시간 차로 어긋남
동기화 불일치	다른 유저 위치, 애니메이션, 상태가 늦게 반영됨
상호작용 실패	문 열기, 아이템 줍기 등이 늦게 되거나 무시됨
오디오 지연	소리가 실제보다 늦게 출력
게임 끊김/버벅임	버벅이는 느낌 발생

 

대응 방법

- 클라이언트 예측 + 보정

- 입력 큐잉, 버퍼링 (지연 감추기)

- 서버 지연 허용 시간 확장

 

---

 

보간(interpolation)과 예측(prediction) 차이

완전히 다른 거임

 

보간

- 과거 데이터를 자연스럽게 이어주는 것

- 이전에 받은 서버 상태들 기반

- 다른 플레이어의 위치 표시

- 약간의 지연을 감추기 위해 사용

- 그냥 부드럽게 잇는 것

 

예측

- 미래 예상

- 클라이언트 입력 정보 기반

- 자기 자신의 조작 반응 향상

- 반응성을 높이기 위해 지연 없이 먼저 실행

- 서버와 다를 경우 롤백, 보정 필요