TCP vs UDP: 신뢰성과 속도의 트레이드오프
TCP와 UDP의 핵심 차이, 헤더 구조, 각 프로토콜이 선택받는 이유를 연결 지향성·신뢰성·흐름 제어 관점에서 비교합니다.
지난 글에서 포트와 소켓이 프로세스 간 통신의 끝점이 되는 원리를 살펴봤다. 전송 계층에는 두 가지 주요 프로토콜이 공존한다. TCP는 신뢰성을 보장하는 대신 복잡한 메커니즘을 갖추고, UDP는 단순한 구조로 낮은 지연을 추구한다. 이 두 프로토콜을 정확히 이해하면 언제 무엇을 써야 하는지 스스로 판단할 수 있다.
TCP: 신뢰성을 보장하는 연결 지향 프로토콜
TCP(Transmission Control Protocol)는 연결을 먼저 수립한 뒤 데이터를 주고받는다. 통신 전에 3-way handshake로 쌍방 합의를 거치고, 데이터를 분할해 순서 번호(Sequence Number)를 붙인 다음, 수신 측이 ACK으로 확인 응답한다. 응답이 없으면 재전송한다.
TCP 신뢰성 보장 요소
─────────────────────────────────────────────
• 순서 번호(Seq) / 확인 응답(ACK)
• 재전송 타이머 (RTO)
• 슬라이딩 윈도우 (흐름 제어)
• CWND (혼잡 제어)
• 중복 패킷 감지 및 제거
─────────────────────────────────────────────
TCP가 이렇게 많은 메커니즘을 갖춘 결과, 헤더 크기는 최소 20바이트, 옵션 포함 시 최대 60바이트까지 커진다. 연결 수립(3-way)과 해제(4-way) 절차도 RTT를 추가한다.
UDP: 단순함이 곧 성능인 비연결 프로토콜
UDP(User Datagram Protocol)는 헤더가 8바이트 고정이다. 연결 수립 과정이 없고, 순서 보장·재전송·혼잡 제어도 없다. 데이터그램을 그냥 던진다. 도착하면 좋고, 유실되어도 프로토콜 레벨에서 아무 처리를 하지 않는다.
UDP 헤더 (8 bytes 고정)
┌─────────────────┬──────────────────┐
│ Source Port │ Dest Port │
│ (16 bit) │ (16 bit) │
├─────────────────┼──────────────────┤
│ Length │ Checksum │
│ (16 bit) │ (16 bit) │
└─────────────────┴──────────────────┘
이 단순함이 DNS 쿼리, DHCP, 실시간 스트리밍, VoIP, 게임 서버처럼 지연 민감 또는 소량 반복 요청 시나리오에 UDP가 선호되는 이유다. 손실 몇 프레임이 재전송 대기보다 낫다.
헤더 구조 비교
TCP 헤더의 Window Size 필드(16비트, 최대 65,535 bytes)는 흐름 제어의 핵심이다. 수신 측이 이 값을 조절해 송신 속도를 제한한다. UDP에는 이 필드 자체가 없으므로 애플리케이션이 직접 속도를 제어해야 한다.
언제 TCP를, 언제 UDP를 쓸까
TCP 선택 기준
- 데이터 무결성이 필수 (파일 전송, HTTP, 금융 거래)
- 순서가 중요한 스트림 (SSH 세션, 데이터베이스 쿼리)
- 연결 지속 시간이 길어서 핸드셰이크 오버헤드가 희석됨
UDP 선택 기준
- 낮은 지연이 무결성보다 우선 (VoIP, 게임, 라이브 스트리밍)
- 요청-응답이 단건으로 짧음 (DNS, SNMP)
- 멀티캐스트/브로드캐스트 필요 (DHCP)
- 애플리케이션이 자체 재전송 로직 포함 (QUIC)
QUIC(HTTP/3의 전송 기반)은 UDP 위에서 구현되지만 TCP가 제공하는 신뢰성을 애플리케이션 레이어에서 재구현한 사례다. TCP의 HOL(Head-of-Line) 블로킹을 피하기 위해 UDP를 선택했다.
체크섬 차이
두 프로토콜 모두 Checksum 필드를 갖지만 동작이 다르다. TCP에서는 체크섬이 필수이고 오류 발생 시 세그먼트를 버리고 재전송을 요청한다. UDP에서는 IPv4 기준으로 선택 사항(0으로 채워도 됨)이며, IPv6에서는 필수다. UDP 체크섬은 오류 감지만 할 뿐 복구는 상위 계층 몫이다.
다음 글: TCP 3-way 핸드셰이크: 연결 수립의 모든 것
읽어주셔서 감사합니다. 😊