실시간 게임 메시지의 최신성·순서·손실 요구에 따라 TCP와 UDP 또는 검증된 전송 계층을 어떻게 선택하나요?

TCP와 UDP는 우열이 아니라 메시지별 전달 계약의 선택입니다. 최신 상태가 중요해 오래된 위치를 기다리면 안 되는 메시지는 UDP에서 순서 번호로 낡은 값을 버리고 주기적으로 최신 스냅샷을 보내는 방식이 맞을 수 있습니다. 반면 계정 변경·결제·확정 명령처럼 유실되면 안 되는 작업은 확인·재전송·중복 방지·최종 상태 조회가 필요하므로 TCP나 검증된 신뢰성 전송 계층을 우선 검토하겠습니다. UDP를 선택한다고 지연이 자동으로 줄지는 않습니다.

메시지 의미를 나눈다

위치 스냅샷은 1, 2, 3 중 2가 늦게 도착해도 3을 이미 적용했다면 버릴 수 있습니다. 패킷 번호를 비교해 오래된 번호와 중복을 폐기하고, 손실된 스냅샷을 재전송하지 않는 대신 다음 최신 스냅샷이 상태를 덮도록 설계합니다. 입력 명령이나 아이템 획득은 순서·정확히 한 번에 가까운 실행이 필요하므로 명령 ID, ACK, 재전송, 서버의 멱등 처리와 결과 조회를 둡니다. 이를 메시지별 신뢰성 정책(per-message reliability policy)이라고 부르겠습니다.

TCP는 연결, 순서, 재전송, 흐름·혼잡 제어를 제공하지만 한 바이트가 늦어 뒤 바이트도 읽기 API에 보이지 않는 스트림 특성이 있습니다. UDP는 데이터그램 경계와 낮은 프로토콜 상태를 제공하는 대신 손실·중복·재정렬·도착 여부를 애플리케이션이 처리해야 합니다. UDP에서 모든 패킷을 순서대로 재전송하고 ACK를 기다리면 TCP와 비슷한 head-of-line 지연과 더 큰 구현 비용을 다시 만들 수 있습니다.

직접 구현할 책임과 대안

UDP를 사용해도 경로 혼잡 제어와 송신률 제한을 빼면 다른 트래픽을 해치고 자기 큐만 키울 수 있습니다. 패킷 크기를 경로 MTU보다 작게 제한하거나 애플리케이션 분할·재조립을 두며, 재조립 상태의 최대 개수·수명·메모리를 제한합니다. NAT·방화벽의 유휴 매핑, 서버 주소 위조와 증폭, 패킷 재정렬, 연결 식별과 인증도 설계합니다. 실시간 상태와 중요 명령을 같은 큐·재전송 정책으로 묶지 않습니다.

이미 요구를 충족하는 QUIC 같은 검증된 전송 계층이 있다면 직접 신뢰성 프로토콜을 만드는 것보다 먼저 비교하겠습니다. 실제 손실·재정렬·지연·NAT 경로에서 입력 지연, 최신성, 사용자 경험, 대역폭, CPU, 재전송량, 서버 증폭 위험을 측정합니다. 신뢰성 요구를 프로토콜 선택으로 끝내지 않고 서버 권위와 멱등 처리까지 포함해야, 패킷을 받았다는 사실이 게임 상태의 확정을 잘못 의미하지 않습니다.

신뢰성 요구는 ‘패킷이 반드시 도착해야 한다’와 ‘상태가 결국 최신 값으로 수렴해야 한다’를 나눠야 합니다. 스냅샷은 최신 번호가 오면 중간 번호를 버릴 수 있지만, 입력 명령은 순서·중복·서버 판정이 필요해 별도 ACK와 ID를 사용합니다. UDP 분할 조각 하나가 빠지면 전체 메시지를 버릴지 부분 복구할지 정하고, 조각 상태를 무제한 보관하지 않습니다. 이 정책이 불명확하면 UDP의 낮은 헤더 비용만 얻고 TCP가 제공하던 신뢰성·혼잡 공정성·운영 검증을 다시 구현하는 결과가 됩니다.

UDP의 데이터그램 경계를 이용하더라도 애플리케이션 메시지의 순서와 상태 버전을 별도로 설계할 수 있습니다. 예를 들어 위치는 최신 버전만 적용하고, 입력은 서버가 수락한 명령 번호를 응답해 재전송 여부를 판단합니다. 이런 계약을 명시하면 손실을 무조건 복구하는 대신 사용자 경험에 필요한 데이터만 비용을 지불하게 됩니다.