UDP는 User Datagram Protocol의 약자로, 한국어로는 사용자 데이터그램 프로토콜 또는 유저 데이터그램 프로토콜이라고 한다. 인터넷 프로토콜 스위트에서 전송 계층에 속하는 핵심 통신 프로토콜 가운데 하나이며, 인터넷 프로토콜 위에서 동작한다. UDP는 연결을 설정하지 않고 데이터그램 단위로 데이터를 전송하는 비연결형 프로토콜이다.[1]
UDP는 TCP와 달리 연결 설정, 전달 보장, 순서 보장, 중복 제거, 흐름 제어를 자체적으로 제공하지 않는다. 대신 헤더가 단순하고 처리 부담이 작기 때문에, 지연 시간을 줄이는 것이 중요한 DNS, DHCP, RTP, VoIP, 온라인 게임, 일부 스트리밍 서비스, QUIC 기반 통신 등에 널리 사용된다. 다만 UDP 자체에는 혼잡 제어 기능이 없으므로, UDP를 사용하는 응용 프로그램이나 상위 프로토콜은 필요에 따라 신뢰성, 보안, 혼잡 제어, 오류 복구 기능을 별도로 구현해야 한다.[2]
UDP는 데이비드 P. 리드와 존 포스텔이 작성한 초기 인터넷 실험 노트인 IEN 71에서 형태가 제시되었고, 1980년에 존 포스텔이 작성한 RFC 768로 표준화되었다.[3][4] RFC 768은 현재도 UDP의 기본 표준 문서이며, 2025년에 발표된 RFC 9868은 UDP에 전송 옵션을 위한 확장 방식을 추가하면서 RFC 768을 업데이트하였다.[5]
개요[편집 / 원본 편집]
UDP는 응용 프로그램이 다른 호스트의 응용 프로그램으로 메시지를 보낼 수 있도록 포트 번호와 짧은 헤더를 제공한다. 송신 측은 수신 측과 사전에 연결을 맺지 않고 데이터를 전송할 수 있으며, 수신 측의 준비 상태나 전달 성공 여부를 UDP 계층에서 보장하지 않는다.
이러한 특성 때문에 UDP는 다음과 같은 상황에 적합하다.
- 지연 시간이 전달 보장보다 중요한 경우
- 일부 패킷 손실을 응용 프로그램이 허용하거나 직접 처리할 수 있는 경우
- 단순한 질의와 응답 구조의 통신이 필요한 경우
- 브로드캐스트 또는 멀티캐스트 전송이 필요한 경우
- 상위 계층에서 자체적인 신뢰성, 암호화, 혼잡 제어를 구현하는 경우
반대로 파일 전송, 전자우편 전송, 웹 페이지 전송처럼 데이터의 완전성과 순서가 중요한 경우에는 일반적으로 TCP 또는 TCP 기반 응용 프로토콜이 더 적합하다.
특징[편집 / 원본 편집]
| 특징 | 설명 |
|---|---|
| 비연결형 | 데이터를 보내기 전에 연결 설정 절차를 수행하지 않는다. |
| 데이터그램 기반 | 데이터가 독립적인 메시지 단위인 데이터그램으로 전송된다. |
| 낮은 오버헤드 | UDP 헤더는 기본적으로 8바이트로, TCP보다 구조가 단순하다. |
| 전달 보장 없음 | 패킷 손실, 중복, 순서 변경이 발생할 수 있으며 UDP 자체는 이를 복구하지 않는다. |
| 순서 보장 없음 | 여러 데이터그램이 전송된 순서와 다른 순서로 도착할 수 있다. |
| 흐름 제어 없음 | 송신 속도를 수신 측 처리 능력에 맞추는 기능을 제공하지 않는다. |
| 혼잡 제어 없음 | 네트워크 혼잡을 감지하거나 전송률을 자동으로 낮추는 기능을 제공하지 않는다. |
| 체크섬 제공 | 헤더와 데이터의 오류 검출을 위한 체크섬 필드를 제공한다. |
| 포트 번호 사용 | 송신지 포트와 목적지 포트를 이용해 호스트 안의 응용 프로그램을 구분한다. |
헤더 구조[편집 / 원본 편집]
UDP 헤더는 4개의 필드로 구성되며, 각 필드는 16비트이다. 따라서 기본 UDP 헤더의 크기는 8바이트이다.[6]
| 필드 | 크기 | 설명 |
|---|---|---|
| 송신지 포트 | 16비트 | 데이터를 보낸 응용 프로그램의 포트 번호이다. 사용하지 않을 경우 0으로 설정할 수 있다. |
| 목적지 포트 | 16비트 | 데이터를 받을 응용 프로그램의 포트 번호이다. |
| 길이 | 16비트 | UDP 헤더와 데이터 영역을 합친 전체 길이를 바이트 단위로 나타낸다. |
| 체크섬 | 16비트 | UDP 헤더와 데이터의 오류를 검출하기 위한 값이다. |
포트 번호[편집 / 원본 편집]
UDP는 포트 번호를 사용하여 한 호스트 안의 여러 응용 프로그램을 구분한다. 포트 번호는 0부터 65535까지의 16비트 값이며, IANA가 서비스 이름과 전송 프로토콜 포트 번호 등록소를 관리한다.[7]
| 범위 | 이름 | 설명 |
|---|---|---|
| 0-1023 | 시스템 포트 | 널리 알려진 표준 서비스에 주로 사용된다. |
| 1024-49151 | 사용자 포트 | 등록된 응용 서비스에 사용된다. |
| 49152-65535 | 동적 또는 사설 포트 | 임시 통신이나 사설 용도로 사용된다. |
UDP 자체는 IPv4와 IPv6에서 IP 상위 프로토콜로 캡슐화될 수 있으며, IANA의 IP 프로토콜 번호 등록소에서 UDP의 프로토콜 번호는 17이다.[8]
체크섬[편집 / 원본 편집]
UDP 체크섬은 전송 중 데이터가 손상되었는지 확인하기 위한 오류 검출 값이다. 체크섬 계산에는 UDP 헤더와 데이터뿐 아니라 IP 주소 등으로 구성된 의사 헤더도 포함된다.
IPv4에서 UDP 체크섬은 선택적으로 사용될 수 있지만, IPv6에서는 일반적인 UDP 통신에서 체크섬 사용이 필수이다. IPv6에서 UDP 체크섬 값이 0인 데이터그램은 기본적으로 폐기되어야 하며, 예외적으로 특정 터널링 프로토콜이 RFC 6935와 RFC 6936의 조건을 따르는 경우에만 0 체크섬 모드를 사용할 수 있다.[9][10]
TCP와의 비교[편집 / 원본 편집]
UDP와 TCP는 모두 전송 계층 프로토콜이며 포트 번호를 사용하지만, 설계 목표와 제공 기능이 다르다.
| 구분 | UDP | TCP |
|---|---|---|
| 연결 방식 | 비연결형 | 연결형 |
| 데이터 단위 | 데이터그램 | 바이트 스트림 |
| 연결 설정 | 없음 | 3방향 핸드셰이크 사용 |
| 전달 보장 | 제공하지 않음 | 제공함 |
| 순서 보장 | 제공하지 않음 | 제공함 |
| 중복 제거 | 제공하지 않음 | 제공함 |
| 흐름 제어 | 제공하지 않음 | 제공함 |
| 혼잡 제어 | 제공하지 않음 | 제공함 |
| 헤더 크기 | 기본 8바이트 | 기본 20바이트 이상 |
| 대표 용도 | DNS, DHCP, RTP, QUIC, 실시간 통신 | HTTP, HTTPS, SMTP, SSH, 파일 전송 |
UDP는 단순하고 빠르지만 신뢰성을 보장하지 않는다. TCP는 상대적으로 복잡하고 오버헤드가 크지만 신뢰성 있는 전송을 제공한다. 따라서 두 프로토콜 가운데 어느 것이 더 우수하다고 단정할 수 없으며, 응용 프로그램의 목적에 따라 적절한 프로토콜을 선택해야 한다.
주요 사용 사례[편집 / 원본 편집]
| 사용 사례 | 설명 |
|---|---|
| DNS | 짧은 질의와 응답이 많아 UDP가 널리 사용된다. 응답 크기나 보안 기능에 따라 TCP도 사용될 수 있다. |
| DHCP | IP 주소 자동 할당 과정에서 UDP를 사용한다. |
| RTP | 음성 및 영상과 같은 실시간 미디어 전송에 사용된다. |
| VoIP | 음성 통화에서 낮은 지연 시간이 중요하므로 UDP 기반 전송이 자주 사용된다. |
| 온라인 게임 | 플레이어 위치, 입력, 상태 정보처럼 최신성이 중요한 데이터를 빠르게 전송하는 데 사용된다. |
| QUIC | UDP 위에서 동작하는 전송 프로토콜로, HTTP/3의 기반이 된다. |
| TFTP | 단순한 파일 전송을 위해 UDP를 사용하는 프로토콜이다. |
| SNMP | 네트워크 장비 관리와 감시에 사용되며 UDP를 주로 사용한다. |
장점과 한계[편집 / 원본 편집]
장점[편집 / 원본 편집]
- 연결 설정 과정이 없어 지연 시간이 짧다.
- 헤더가 작고 구조가 단순하다.
- 구현이 비교적 쉽다.
- 브로드캐스트와 멀티캐스트 통신에 적합하다.
- 실시간 통신처럼 일부 손실보다 지연 시간이 더 중요한 환경에 적합하다.
- 상위 계층에서 필요한 기능을 자유롭게 설계할 수 있다.
한계[편집 / 원본 편집]
- 데이터 전달을 보장하지 않는다.
- 데이터 도착 순서를 보장하지 않는다.
- 중복 데이터그램을 제거하지 않는다.
- 흐름 제어와 혼잡 제어를 제공하지 않는다.
- 보안 기능을 자체적으로 제공하지 않는다.
- 응용 프로그램이 신뢰성, 인증, 암호화, 재전송, 혼잡 제어를 직접 구현해야 할 수 있다.
보안[편집 / 원본 편집]
UDP는 연결 설정이 없고 송신자 검증 기능이 약하므로 서비스 거부 공격과 반사 공격에 악용될 수 있다. 특히 응답 크기가 요청보다 훨씬 큰 UDP 기반 서비스는 DDoS 증폭 공격의 대상이 될 수 있다. 따라서 공개 네트워크에서 UDP 서비스를 운영할 때에는 접근 제어, 응답률 제한, 소스 주소 검증, 방화벽 정책, 서비스 구성 점검이 중요하다.
UDP 자체는 암호화나 인증을 제공하지 않는다. 보안이 필요한 경우에는 DTLS, IPsec, QUIC처럼 UDP 위 또는 아래에서 보안 기능을 제공하는 기술을 함께 사용한다.
확장과 관련 표준[편집 / 원본 편집]
UDP의 기본 형식은 RFC 768에 정의되어 있다. 이후 UDP 사용 지침, IPv6 체크섬 처리, UDP 옵션 등과 관련된 여러 표준 문서가 발표되었다.
| 문서 | 제목 | 내용 |
|---|---|---|
| RFC 768 | User Datagram Protocol | UDP의 기본 형식과 동작을 정의한 표준 문서이다. |
| RFC 8085 | UDP Usage Guidelines | UDP를 사용하는 응용 프로그램과 프로토콜 설계자를 위한 지침을 제공한다. |
| RFC 6935 | IPv6 and UDP Checksums for Tunneled Packets | IPv6 터널링 환경에서 UDP 체크섬 처리 문제를 다룬다. |
| RFC 6936 | Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums | IPv6 UDP 데이터그램에서 0 체크섬을 사용할 수 있는 제한적 조건을 설명한다. |
| RFC 9868 | Transport Options for UDP | UDP에 전송 옵션을 추가하기 위한 확장 방식을 정의하며 RFC 768을 업데이트한다. |
같이 보기[편집 / 원본 편집]
각주[편집 / 원본 편집]
- ↑ RFC Editor, “RFC 768: User Datagram Protocol”, https://www.rfc-editor.org/info/rfc768/
- ↑ IETF, “RFC 8085: UDP Usage Guidelines”, https://datatracker.ietf.org/doc/html/rfc8085
- ↑ RFC Editor, “IEN 71: User Datagram Protocol”, https://www.rfc-editor.org/ien/ien71.pdf
- ↑ RFC Editor, “RFC 768: User Datagram Protocol”, https://www.rfc-editor.org/info/rfc768/
- ↑ IETF Datatracker, “RFC 9868: Transport Options for UDP”, https://datatracker.ietf.org/doc/rfc9868/
- ↑ RFC Editor, “RFC 768: User Datagram Protocol”, https://www.rfc-editor.org/info/rfc768/
- ↑ IANA, “Service Name and Transport Protocol Port Number Registry”, https://www.iana.org/assignments/service-names-port-numbers
- ↑ IANA, “Assigned Internet Protocol Numbers”, https://www.iana.org/assignments/protocol-numbers
- ↑ IETF, “RFC 8200: Internet Protocol, Version 6 (IPv6) Specification”, https://datatracker.ietf.org/doc/html/rfc8200
- ↑ IETF, “RFC 6936: Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums”, https://datatracker.ietf.org/doc/html/rfc6936