Reference

Game Server

권위 서버, 시뮬레이션 tick, 메시지 전달, 실시간 상태 동기화, 지연 보상, 세션과 확장 구조까지 온라인 게임 서버의 핵심 판단을 정리합니다.

전체30개

현재30개

레퍼런스 검색

서버 모델

게임 서버는 무엇을 최종 결정해야 하는가

클라이언트가 보내는 요청과 서버가 확정해야 하는 게임 상태를 나누고, 권위 서버가 치트 방지와 동기화의 기준점이 되는 이유를 정리합니다.

function handleFire(session: Session, command: FireCommand) {
  if (!session.acceptsNextSequence(command.sequence)) return;
  if (!world.canFire(session.playerId, command.weaponId)) return;

  const hit = world.raycastFromPlayer(session.playerId, command.aim);
  world.applyAuthoritativeFire(session.playerId, command.weaponId, hit);
}

게임 서버 tick은 무엇을 한 번에 처리해야 하는가

입력 수신, 규칙 적용, 상태 확정, 스냅샷 전송을 tick 경계로 묶고 tick rate와 전송 주기를 같은 값으로 고정하지 않는 방법입니다.

수신 callback: command를 session queue에 넣음
      -> tick: queue에서 이번 tick의 command를 꺼냄
      -> tick: movement·combat·cooldown·spawn을 순서대로 적용
      -> tick: authoritative state와 tick 번호를 확정
      -> 전송 주기: 관심 있는 상태만 snapshot 또는 event로 전송

방, 매치, 채널, 인스턴스를 어떻게 구분할까

room·match·channel·instance라는 이름보다 상태 소유자, 참여자, 수명, 이동 규칙을 먼저 정해 서버 구조가 섞이지 않게 만드는 방법입니다.

party 생성
  -> matchmaking queue 진입
  -> match 확정
  -> instance 할당 또는 생성
  -> player session을 instance에 attach
  -> 결과 저장 후 instance 종료 또는 재사용

통신과 프로토콜

게임 메시지에서 TCP와 UDP를 어떻게 고를까

TCP와 UDP를 게임 전체의 단일 선택으로 보지 않고, 메시지마다 신뢰성·순서·지연·중복 허용 여부를 정해 전송 계약을 고르는 방법입니다.

메시지를 먼저 분류한다
  -> 유실되면 게임 규칙이 깨지는가?
  -> 늦게 온 이전 메시지가 최신값을 막아도 되는가?
  -> 중복 처리해도 안전한가?
  -> 이 계약을 transport 또는 application protocol 어디에서 보장할 것인가?

TCP에서 메시지 경계를 어떻게 복원할까

TCP의 data callback 한 번을 패킷 하나로 취급하지 않고, length prefix·누적 버퍼·최대 크기 검사로 application message 경계를 복원하는 방법입니다.

const MAX_PAYLOAD = 8 * 1024;
let pending = Buffer.alloc(0);

function onData(chunk: Buffer) {
  pending = Buffer.concat([pending, chunk]);

  while (pending.length >= 2) {
    const size = pending.readUInt16BE(0);
    if (size > MAX_PAYLOAD) {
      closeForProtocolError("payload too large");
      return;
    }
    if (pending.length < 2 + size) return;

    const payload = pending.subarray(2, 2 + size);
    pending = pending.subarray(2 + size);
    handleMessage(payload);
  }
}

신뢰성 event는 승인·재전송·중복 제거를 어떻게 나눌까

발사·구매·매치 수락처럼 유실되면 안 되는 event를 event ID, acknowledgement, 재전송, 멱등 처리로 다루는 방법입니다.

게임 프로토콜 버전과 하위 호환성은 어떻게 관리할까

연결 협상, message schema, 게임 규칙 버전을 분리하고 구버전 client를 허용·차단·업데이트 안내하는 기준입니다.

실시간 동기화

클라이언트 예측과 서버 보정은 어떻게 함께 동작하는가

로컬 입력을 즉시 예측하면서도 서버 권위를 유지하려면 input sequence, 서버 승인 지점, 미승인 입력 재실행을 어떻게 연결해야 하는지 정리합니다.

client: input #42를 저장하고 로컬 state에 즉시 적용 -> server로 전송
server: #42를 검증·simulation 후 authoritative state와 lastProcessedInput=42 전송
client: server state로 되돌림 -> #43 이후의 미승인 input을 순서대로 다시 적용

snapshot 보간과 외삽은 언제 선택할까

다른 플레이어를 최신 snapshot에 바로 맞추지 않고, 약간 과거의 두 상태를 보간해 표시하며 외삽은 짧은 packet loss 구간에만 제한하는 방법입니다.

const renderTick = latestServerTick - interpolationDelayTicks;
const [before, after] = history.findBracketing(renderTick);
const position = lerp(before.position, after.position, fraction(renderTick, before, after));

지연 보상은 서버 판정을 어디까지 되감을까

발사 시점에 클라이언트가 본 과거 상태를 서버 history에서 제한적으로 복원해 판정하고, 되감기 범위·기록 기간·공정성 정책을 함께 정하는 방법입니다.

server가 tick마다 player의 hitbox history를 기록
  -> fire command 수신
  -> server가 허용 가능한 과거 판정 시각을 추정·제한
  -> 해당 시각의 대상 hitbox만 임시로 복원
  -> server raycast·피해 규칙 적용
  -> 현재 state로 복귀하고 결과 event 전송

rollback networking은 언제 필요한가

입력 지연을 줄이는 대신 과거 frame으로 되돌려 재시뮬레이션하는 rollback 방식의 조건, 비용, side effect 처리 기준입니다.

세션과 매치

매치메이킹 ticket은 어떤 상태로 관리해야 할까

파티의 매칭 요청을 ticket으로 고정하고, queue·검색·수락·배치·완료·취소를 상태 전이로 관리해 중복 매칭과 유령 입장을 막는 방법입니다.

party 검증
  -> ticket 생성: party version, 규칙, 지역·지연 정보, 만료 시각 고정
  -> queued / searching
  -> proposed: 수락이 필요한 경우
  -> placing: match는 만들었고 server 자리를 찾는 중
  -> completed: matchId와 입장 정보 발급
  -> cancelled / timedOut / failed

game session 입장은 어떻게 한 번만 허용할까

매치 완료 뒤 발급한 입장 권한을 game server가 검증하고, 정원·중복 연결·만료·재시도를 처리해 seat가 두 번 소비되지 않게 만드는 방법입니다.

match completed
  -> backend: playerId, matchId, instanceId, expiry를 묶은 join grant 발급
  -> client: game server에 grant 제시
  -> server: 서명·만료·match·player·instance·seat 상태 확인
  -> seat reserved -> joined 전환
  -> 초기 snapshot 전송 후 command 허용

연결이 끊긴 플레이어는 어떻게 재접속시킬까

socket 연결과 player session을 분리하고, 유예 시간·connection generation·초기 동기화 순서를 정해 재접속이 분신 플레이어와 상태 손실을 만들지 않게 하는 방법입니다.

connection close
  -> session: active -> disconnected, grace deadline 기록
  -> old connection generation 무효화
  -> resume 요청: player·match·expiry·generation 검사
  -> 새 connection attach
  -> full snapshot + 필요한 reliable event 재전송
  -> active

backfill과 late join은 어떤 상태를 이어받는가

빈 자리에 새 player를 매칭하는 backfill과 진행 중인 match에 붙는 late join을 구분하고, 입장 시 전달할 상태를 정하는 방법입니다.

상태 전파

관심 영역으로 누구의 상태를 보낼지 어떻게 정할까

모든 entity를 모든 client에 복제하지 않고, 거리·시야·팀·게임 규칙을 기준으로 replication set을 만들며 false negative와 update 우선순위를 함께 관리하는 방법입니다.

client connection
  -> 항상 필요한 entity를 추가
  -> 공간 index로 가까운 후보를 찾음
  -> 팀·시야·instance·game rule로 후보를 필터링
  -> bandwidth 예산 안에서 update priority를 정함
  -> spawn / delta / despawn을 전송

entity 생성·제거와 상태 버전은 어떻게 전파할까

client가 entity를 만들기 전에 delta를 받거나, 제거한 entity의 늦은 update를 적용하지 않도록 spawn·baseline·despawn·version의 순서를 정하는 방법입니다.

replication set에 새 entity 추가
  -> spawn(entityId, type, lifecycleVersion, baseline)
  -> client가 baseline을 확인 또는 reliable channel로 수신
  -> delta(entityId, lifecycleVersion, stateVersion, changed fields)
  -> despawn(entityId, lifecycleVersion)
  -> 같은 ID 재사용 전 version을 바꾸거나 재사용을 지연

delta snapshot은 어떤 baseline을 기준으로 보낼까

변한 field만 보내는 delta snapshot이 어느 full state를 기준으로 하는지, client acknowledgment·packet loss·resync를 어떻게 연결해야 복제 상태가 깨지지 않는지 정리합니다.

server: client가 확인한 baseline #120을 기억
  -> current #126에서 달라진 field만 delta로 전송
client: #120 위에 delta 적용 후 #126을 ack
  -> server: 다음 delta의 baseline을 #126으로 전진
  -> ack가 끊기면 마지막 확인 baseline 또는 full snapshot으로 복구

replication byte budget과 update 우선순위는 어떻게 정할까

관심 영역에 들어온 entity가 많아도 packet 크기와 전송 시간을 넘지 않도록 lifecycle·거리·변화량·굶주림을 기준으로 복제를 예약하는 방법입니다.

저장과 운영

게임 결과와 보상은 어떻게 한 번만 저장할까

tick마다 모든 월드 상태를 저장하지 않고, 확정 시점을 정해 결과·보상·재화를 operation ID와 transaction으로 기록하며 retry가 중복 지급을 만들지 않게 하는 방법입니다.

final tick에서 winner·score·reward를 authoritative state로 확정
  -> resultOperationId 생성 또는 조회
  -> transaction: match result 기록 + player reward ledger 기록
  -> commit
  -> client에 완료 event 전송
  -> retry는 같은 operation ID의 이미 확정된 결과를 반환

게임 서버 문제를 어떤 기록으로 재현할까

매치·instance·player·tick·protocol version을 함께 연결해 지연, desync, 입장 실패, 보상 오류를 한 흐름으로 추적하는 로그·metric·trace 기준입니다.

client join 실패
  -> admission log에서 grant·seat 전이 확인
  -> match trace에서 ticket / placement 대기 구간 확인
  -> instance metric에서 tick 지연·정원·queue depth 확인
  -> 같은 match의 server build·protocol version·event 순서 대조

게임 서버 종료와 session drain은 어떻게 진행할까

새 입장을 막는 drain, 진행 중인 match를 마무리하는 graceful shutdown, deadline 뒤 복구로 넘기는 강제 종료를 분리하는 운영 절차입니다.

ACTIVE
  -> DRAINING: 새 placement·입장·backfill 중지
  -> CLOSING: 남은 match에 종료 시각과 정책 통지
  -> FINALIZING: 결과·보상·telemetry를 한 번만 기록
  -> STOPPED

deadline 초과 -> state checkpoint 또는 복구 경로 -> 강제 종료

simulation bot으로 게임 서버 부하를 어떻게 검증할까

연결 수만 늘리는 테스트와 실제 입력·match 상태를 움직이는 simulation bot 테스트를 구분하고, tick 지연과 복제 예산을 측정하는 방법입니다.

분산과 확장

game session은 어떤 process가 소유해야 할까

game session 하나를 한 authoritative process가 소유하게 하고, 새 process를 늘려 수평 확장할 때 allocation·상태·연결 책임을 분리하는 방법입니다.

matchmaking 또는 session service
  -> idle process 선택 또는 새 process 기동
  -> process가 match ID와 rule data를 받아 world 생성
  -> ready 확인 뒤 client에 endpoint·admission grant 전달
  -> 해당 process만 match의 authority를 유지

shard, zone, instance 경계는 무엇을 기준으로 나눌까

player population, world geography, match lifecycle을 서로 다른 문제로 보고 shard·zone·instance의 소유 범위를 나누는 기준입니다.

server 사이 state handoff는 어떻게 한 번만 넘길까

zone 이동, instance 입장, owner 교체에서 source와 target이 동시에 player를 소유하지 않도록 handoff token·revision·확인 절차를 두는 방법입니다.

source: 이동 rule 검증 -> handoff {player, revision, state, token} 생성
target: token·expiry·revision 검증 -> target state 준비 -> accepted 응답
source: accepted 확인 -> source entity despawn·ownership 해제
client: target endpoint 접속 -> join snapshot 수신

regional placement와 player latency 정책은 어떻게 정할까

party 전체의 지연, 개인 상한, 대기 시간, region capacity를 함께 보고 match server location을 고르는 단계적 placement 정책입니다.

안전과 복구

game command rate limit과 abuse 격리는 어떻게 설계할까

connection·account·match 단위 한도를 분리하고, 입력을 버리거나 늦추거나 끊는 기준으로 message flood와 비정상 command를 격리하는 방법입니다.

packet 수신
  -> 최대 크기와 frame 형식 검사
  -> connection bytes·messages bucket 확인
  -> account와 command kind bucket 확인
  -> 권한·cooldown·state revision 검사
  -> tick command queue에 넣기

rolling update에서 game build 호환성은 어떻게 지킬까

새 server를 먼저 준비하고 새 match에만 배정한 뒤 기존 match를 drain하는 순서로, protocol·rule·content revision이 섞이지 않게 배포하는 방법입니다.

새 build 기동 -> readiness와 protocol compatibility 확인
  -> 새 match placement를 새 build로 전환
  -> 기존 build는 새 placement 중지 후 drain
  -> 남은 match 종료·deadline 처리
  -> 기존 build 종료

game server crash 뒤 session은 어떻게 복구할까

crash를 정상 종료처럼 숨기지 않고, mode별로 무효 처리·checkpoint 재개·결과 확정 중 하나를 선택하며 stale owner와 중복 보상을 막는 복구 기준입니다.

Loading category cards

Preparing references and filters for this topic. 이 주제의 레퍼런스와 필터를 준비하고 있습니다.