연결 설정도 재전송도 하지 않고 그냥 보내는 전송 계층 프로토콜 (User Datagram Protocol).
TCP와의 대비
| TCP | UDP | |
|---|---|---|
| 연결 | 3-way handshake | 없음 |
| 신뢰성 | 재전송으로 보장 | 없음. 유실돼도 모른다 |
| 순서 | 보장 | 없음 |
| 흐름·혼잡 제어 | 있음 | 없음 |
| 헤더 크기 | 20바이트 이상 | 8바이트 |
| 속도 | 상대적으로 느림 | 빠름 |
헤더가 8바이트뿐이다
┌───────────┬───────────┬─────────┬───────────┐
│ 출발 포트 │ 도착 포트 │ 길이 │ 체크섬 │
│ 2바이트 │ 2바이트 │ 2바이트 │ 2바이트 │
└───────────┴───────────┴─────────┴───────────┘
시퀀스 번호도, ACK도, 윈도우 크기도 없다. 상태를 전혀 유지하지 않는다. TCP 헤더의 순서 번호·확인 응답·플래그가 전부 "신뢰성"을 위한 것인데, 그것을 포기하니 헤더가 이렇게 작아진다.
"신뢰성이 없다"가 왜 장점이 되나
① 지연이 예측 가능하다
TCP는 패킷이 유실되면 재전송하고 그것을 기다린다. 그동안 뒤의 데이터가 이미 도착했어도 애플리케이션에 전달되지 않는다(HOL Blocking).
화상 통화에서 0.5초 전 프레임이 유실됐다면? TCP : 재전송을 기다린다 → 영상이 멈췄다가 몰아서 재생된다 UDP : 그냥 버리고 다음 프레임을 보여 준다 → 잠깐 깨지지만 실시간 유지
늦게 도착한 데이터가 쓸모없는 경우, 재전송은 손해다.
② 오버헤드가 없다
연결 수립(RTT 1회)이 없어 첫 패킷부터 데이터를 보낸다. DNS 조회처럼 짧은 요청-응답에 큰 이점이다.
③ 일대다 전송이 가능하다
TCP는 1:1 연결만 가능하지만 UDP는 브로드캐스트·멀티캐스트를 지원한다.
어디에 쓰이나
| 용도 | 이유 |
|---|---|
| DNS | 짧은 질의-응답. 연결 비용이 아깝다 (512바이트 초과 시 TCP) |
| 실시간 스트리밍·화상통화 | 지연 < 완전성 |
| 온라인 게임 | 위치 정보는 다음 것이 오면 옛것은 무의미 |
| DHCP | 아직 IP가 없어 연결을 맺을 수 없다 |
| NTP, SNMP | 짧고 가볍게 |
| QUIC (HTTP/3) | UDP 위에 신뢰성을 새로 구현 |
QUIC — UDP의 재발견
"TCP가 느린 게 아니라 TCP를 고칠 수 없는 게 문제" 였다. TCP는 OS 커널과 전 세계 네트워크 장비에 박혀 있어 개선이 불가능하다.
QUIC = UDP + (신뢰성 + 암호화 + 멀티플렉싱)을 애플리케이션 레벨에서 재구현
- 스트림별 독립 재전송 → HOL Blocking 해결
- 연결 수립 0-RTT (재접속 시)
- 연결 마이그레이션 (와이파이 → LTE 전환해도 연결 유지)
UDP를 "아무것도 안 하는 그릇"으로 쓰고 그 위에 원하는 것을 얹은 것이다. HTTP/3가 이 위에서 동작한다.
애플리케이션이 책임진다
UDP를 쓴다는 것은 필요한 보장을 직접 구현한다는 뜻이다.
- 순서가 필요하면 — → 애플리케이션에 시퀀스 번호를 넣는다
- 유실 감지가 필요하면 → ACK를 직접 설계한다
- 혼잡 제어가 필요하면 → 직접 구현한다 — ← 이것이 가장 어렵다
혼잡 제어 없이 UDP를 남발하면 네트워크 전체를 마비시킬 수 있다. QUIC이 어려운 이유도 이 부분을 제대로 만들어야 하기 때문이다.