UDP란?

---

들어가기 전

• UDP는 User Datagram Protocol의 약자다.
• 전송 계층(Transport Layer)의 비연결형(connectionless), best-effort, 메시지 지향(message-oriented) 프로토콜이다.
• TCP처럼 연결을 맺거나, 순서 보장/재전송/혼잡 제어를 기본 제공하지 않는다.

즉, UDP는 애플리케이션에 다음 정도만 제공한다.

• 포트 번호 기반 다중화
• 데이터그램 경계 유지
• 체크섬 기반 오류 검출

그 대신 아래 기능은 애플리케이션 또는 상위 프로토콜이 직접 책임져야 한다.

• 신뢰성
• 순서 보장
• 흐름 제어
• 혼잡 제어

UDP는 왜 사용할까?

• 연결 설정(3-way handshake)이 없어 초기 오버헤드가 작다.
• 메시지 단위 경계가 유지된다.
• 지연에 민감한 서비스에서 일부 손실을 감수하는 편이 더 나을 수 있다.
• 필요하면 애플리케이션이 자신에게 맞는 재전송/순서 제어 정책을 직접 설계할 수 있다.

대표 예시:

• 실시간 스트리밍
• VoIP
• 온라인 게임
• DNS
• QUIC(HTTP/3의 기반 전송)

UDP가 무조건 TCP보다 빠르다고 단정하면 안 된다. 프로토콜 자체의 상태와 오버헤드는 더 적지만, 실제 성능은 애플리케이션 설계와 네트워크 상황에 따라 달라진다.

1. UDP Header

• - `Source Port`: 송신 포트 - `Destination Port`: 수신 포트 - `Length`: UDP 헤더 + 데이터 길이 - `Checksum`: 오류 검출

UDP 헤더는 매우 단순하다. 그래서 TCP보다 제공 기능이 적고, 그만큼 전송 제어 로직도 단순하다.

참고:

• IPv4에서는 UDP 체크섬이 선택 사항이지만, 실제 구현에서는 보통 사용한다.
• IPv6에서는 UDP 체크섬이 사실상 필수다.

2. DNS가 왜 UDP를 많이 사용하는가?

전통적인 DNS 질의/응답은 작은 요청 1개 + 응답 1개 구조가 많았기 때문에 UDP가 잘 맞았다.

이유는 다음과 같다.

1. 연결 설정 없이 바로 질의할 수 있다.
2. 단문 질의/응답에는 TCP보다 오버헤드가 작다.
3. 손실 시 애플리케이션 차원에서 타임아웃 후 재질의할 수 있다.

기본 포트는 53이다.

3. 하지만 DNS는 TCP도 반드시 중요하다

DNS = UDP만 사용이라고 이해하면 현재 기준으로는 부정확하다.

• 응답이 잘린 경우(TC 비트)
• AXFR, IXFR 같은 zone transfer
• 큰 응답 처리
• 보호된 DNS 전송(DoT/DoH)

같은 경우에는 TCP가 사용되거나 필수다.

또한 EDNS(0)를 사용하면 전통적인 512바이트 한계를 넘는 UDP payload 크기를 협상할 수 있다. 다만 너무 큰 UDP 응답은 IP 단편화 문제를 일으킬 수 있어, 실제 운영에서는 적절한 크기 조정과 TCP fallback이 중요하다.

정리

• TCP: 연결 지향, 신뢰성/순서 보장 제공
• UDP: 비연결형, 최소 기능만 제공

UDP는 기능이 적은 대신 유연하다. 그래서 오늘날에도 DNS, 실시간 미디어, QUIC 같은 현대 프로토콜의 기반으로 널리 쓰인다.

[ref]

• RFC 768
• RFC 8085
• RFC 6891
• RFC 7766