전송 계층의 최소한만 하는 프로토콜. 헤더가 8바이트뿐이다.
무엇을 하나
하는 일
- 포트로 어느 애플리케이션인지 구분한다
- 체크섬으로 손상 여부만 확인한다 (틀리면 버린다)
안 하는 일
- 연결 수립 · 도착 보장 · 순서 보장 · 중복 제거 · 흐름 제어 · 혼잡 제어
UDP 헤더 (8바이트) TCP 헤더 (최소 20바이트)
출발지 포트 2 출발지·목적지 포트
목적지 포트 2 순서번호 · 확인응답 번호
길이 2 플래그 · 윈도우 크기
체크섬 2 체크섬 · 긴급 포인터 · 옵션
언제 유리한가
-
① 지연이 신뢰성보다 중요하다
- 실시간 음성·영상 — 1초 전 프레임을 재전송받아 봐야 의미가 없다
-
② 요청-응답이 짧다
- DNS — 핸드셰이크 3번 하느니 한 번 묻고 한 번 받는 게 낫다
-
③ 브로드캐스트·멀티캐스트가 필요하다
- TCP 는 1:1 연결이라 불가능하다
-
④ 자기만의 신뢰성을 설계하고 싶다
④가 QUIC을 낳았다
TCP 의 문제
- 연결 수립에 왕복이 필요하다 (TCP 3-way + TLS 핸드셰이크)
- 한 패킷을 잃으면 그 뒤 모든 스트림이 함께 막힌다 (전송 계층 HoL 블로킹)
- 커널에 구현돼 있어 개선이 느리다 (OS 업데이트를 기다려야 한다)
QUIC 의 선택
- UDP 위에 신뢰성·순서·혼잡 제어를 '애플리케이션 층에' 다시 구현했다
- 스트림이 독립적이라 하나가 막혀도 나머지는 흐른다
- TLS 1.3 을 통합해 연결 수립이 1-RTT (재방문은 0-RTT)
- 연결 ID 로 IP 가 바뀌어도 연결이 유지된다 (Wi-Fi ↔ LTE 전환)
- 라이브러리 업데이트만으로 개선된다
HTTP/3 이 이 위에 선다
확인해 보기
dig example.com # DNS 는 기본이 UDP 53
dig +tcp example.com # 응답이 크면 TCP 로 넘어간다
ss -u -a # UDP 소켓 목록 (연결 상태 개념이 없다)
신뢰성이 필요하면 앱이 얹는다
순서번호 · 재전송 · ACK 를 애플리케이션 프로토콜이 직접 정의한다
- 필요한 것만 골라 얹을 수 있다 ("순서는 필요하지만 재전송은 필요 없다" 같은 선택)
- 게임 · 실시간 스트리밍 · QUIC 이 전부 이 길을 택했다
면접 함정
- ❌ "UDP는 신뢰할 수 없어서 나쁘다" → 보장을 안 하도록 설계한 것이고, 그래서 위에서 골라 얹을 수 있다.
- ❌ "UDP는 순서가 뒤바뀐다" → 뒤바뀔 수 있을 뿐이다. 보장하지 않을 뿐 일부러 섞지 않는다.
소켓 코드로 보는 차이
// TCP — 연결을 맺고 스트림으로 주고받는다
listen(fd, backlog);
conn = accept(fd, ...);
read(conn, buf, n);
// UDP — 연결이 없다. 소켓 하나로 아무에게나 받고 보낸다
bind(fd, addr);
recvfrom(fd, buf, n, 0, &from, &fromlen); // 누가 보냈는지 매번 알려 준다
sendto(fd, buf, n, 0, &to, tolen);
accept가 없다는 것이 비연결형의 실질적 의미다.
경계가 보존된다
-
TCP — 스트림 — 보낸 단위와 받는 단위가 다를 수 있다
- send("AB") + send("CD") → recv 가 "ABCD" 를 한 번에 줄 수 있다
- 애플리케이션이 길이 헤더나 구분자로 메시지 경계를 직접 표시해야 한다
-
UDP — 데이터그램 — 보낸 단위 그대로 받는다
- sendto("AB") + sendto("CD") → recvfrom 이 "AB" 와 "CD" 를 따로 준다
"TCP는 메시지 경계가 없다" 가 실무에서 자주 데는 지점이다.
크기 제한
UDP 데이터그램이 MTU 를 넘으면 IP 단편화가 일어난다
- 조각 하나만 잃어도 전체가 버려진다 (재전송이 없으니 그대로 손실)
- 그래서 실무에서는 1200바이트 이하로 맞추는 관행이 있다 (QUIC 도 이 선을 쓴다)