Quick Comparison
UDP가 항상 빠르고 TCP가 항상 느린 것이 아닙니다. 손실 처리, congestion control, 보안과 메시지 순서를 application에서 다시 구현하면 UDP의 단순 header만으로 전체 비용을 판단할 수 없습니다.
| 기준 | TCP | UDP |
|---|---|---|
| 전달 형태 | 연결된 byte stream | 독립 datagram |
| 순서·재전송 | protocol이 순서와 재전송 제공 | application이 필요하면 구현 |
| 메시지 경계 | 보존하지 않음 | datagram 경계 보존 |
| 혼잡 제어 | 제공 | application 책임 |
| 대표 선택 | 파일, HTTP 연결, 확실한 명령 | 실시간 상태, discovery, 자체 transport |
전달 계약
TCP write 한 번이 상대 read 한 번으로 대응하지 않습니다. 길이 prefix나 delimiter로 application message framing을 만들어야 합니다. TCP는 연결 안에서 byte 순서를 유지하지만 application-level 요청의 의미와 중복 처리를 대신 정의하지 않습니다.
UDP datagram은 손실, 중복, 순서 변경이 가능하며 수신 buffer나 경로 MTU를 넘는 큰 packet은 fragmentation과 손실 위험이 커질 수 있습니다.
게임에서 선택
로그인·결제·인벤토리처럼 순서와 확정 처리가 중요한 명령은 reliable transport가 자연스럽습니다. 위치·조준처럼 최신 상태가 더 중요하고 오래된 packet을 재전송할 가치가 낮은 데이터는 UDP 기반 구조를 검토할 수 있습니다. 실제 게임은 traffic 성격에 따라 여러 channel 또는 QUIC 같은 다른 transport를 조합할 수 있습니다.
자주 틀리는 점
- TCP 연결이 살아 있다고 application 상대가 정상 처리 중이라고 보장하지 않습니다.
- UDP checksum과 application 신뢰성·인증을 같은 것으로 보지 않습니다.
- TCP는 message protocol이 아니므로 packet boundary에 의존하지 않습니다.
- Transport 선택 전에 NAT, firewall, congestion과 보안 요구를 확인합니다.
참고 링크
2 sources