Quick Comparison

TCP는 신뢰성 있는 순서 보장 byte stream을 제공하고, UDP는 메시지 전달·순서·중복 방지를 보장하지 않는 datagram 기반 전송입니다. 그러나 게임에서 실제 선택 단위는 TCP냐 UDP냐보다 각 메시지가 무엇을 잃어도 되는지입니다.

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

TCP가 맞는 경우

TCP는 application에 신뢰성 있고 순서가 보장된 byte stream을 제공합니다. 로그인, 계정, 구매, 인벤토리처럼 누락·중복·순서 뒤바뀜을 application이 직접 감당하기 어려운 흐름에 잘 맞습니다. 구현과 운영이 단순해지는 것도 중요한 장점입니다.

대신 앞선 byte가 유실되면 뒤에 이미 도착한 byte도 application에 전달되지 못할 수 있습니다. 이를 head-of-line blocking이라고 합니다. 이전 위치 update가 복구될 때까지 최신 위치 update도 기다려야 한다면, 이미 낡은 상태를 받기 위해 최신 화면 반응도 늦어질 수 있습니다.

TCP가 느리다는 뜻은 아닙니다. 지연의 원인이 게임 rule, 서버 과부하, serialization, queue 정체일 수도 있습니다. 반대로 UDP를 쓴다고 지연이 자동으로 낮아지지도 않습니다. UDP 위에서 순서 보장, 재전송, congestion 대응을 다시 만들면 그 비용과 실패 조건을 application이 책임져야 합니다.

UDP가 맞는 경우

UDP는 datagram 단위로 보내며 배달, 순서, 중복 방지를 보장하지 않습니다. 그래서 연속적인 이동 input과 상태 snapshot처럼 이전 값이 곧 낡아지는 정보에 맞습니다. 최신 sequence만 반영하고 이전 sequence를 버리면, 유실된 중간 상태를 복구하느라 현재 상태가 멈추는 일을 줄일 수 있습니다.

그 대신 message header에 sequence, acknowledgement, timestamp 또는 tick 같은 application 정보가 필요할 수 있습니다. 어떤 packet이 최신인지, 중복 발사 command를 어떻게 막는지, 중요한 event를 언제 재전송할지는 UDP 자체가 답하지 않습니다. 신뢰성 channel을 제공하는 네트워크 라이브러리를 쓰면 이 계약이 라이브러리 설정과 message type에 어떻게 매핑되는지 확인합니다.

전송 선택 전에 정할 것

하나의 게임이 TCP와 UDP를 함께 쓰거나, 하나의 transport 안에서 reliable·unreliable channel을 나눌 수 있습니다. 이때 protocol은 MoveInput, Snapshot, InventoryChanged처럼 message type마다 전달 계약을 문서화해야 합니다. important: true 같은 모호한 flag는 나중에 재전송·순서·중복 처리 정책을 숨깁니다.

전송 방식과 게임 판정을 혼동하지 않습니다. UDP snapshot을 잃어도 서버의 체력·피해 판정은 다음 snapshot이나 reliable event로 일관되게 회복되어야 합니다. 반대로 TCP를 사용해도 TCP 메시지 경계는 따로 정의해야 합니다.