UDP: 두 판 사이의 차이

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


== 각주 ==
== 각주 ==
5번째 줄: 189번째 줄:


[[분류:네트워크]]
[[분류:네트워크]]
[[분류:인터넷 프로토콜]]
[[분류:전송 계층 프로토콜]]

2026년 6월 17일 (수) 11:21 기준 최신판

UDPUser 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 자체는 IPv4IPv6에서 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을 업데이트한다.

같이 보기[편집 / 원본 편집]

각주[편집 / 원본 편집]

  1. RFC Editor, “RFC 768: User Datagram Protocol”, https://www.rfc-editor.org/info/rfc768/
  2. IETF, “RFC 8085: UDP Usage Guidelines”, https://datatracker.ietf.org/doc/html/rfc8085
  3. RFC Editor, “IEN 71: User Datagram Protocol”, https://www.rfc-editor.org/ien/ien71.pdf
  4. RFC Editor, “RFC 768: User Datagram Protocol”, https://www.rfc-editor.org/info/rfc768/
  5. IETF Datatracker, “RFC 9868: Transport Options for UDP”, https://datatracker.ietf.org/doc/rfc9868/
  6. RFC Editor, “RFC 768: User Datagram Protocol”, https://www.rfc-editor.org/info/rfc768/
  7. IANA, “Service Name and Transport Protocol Port Number Registry”, https://www.iana.org/assignments/service-names-port-numbers
  8. IANA, “Assigned Internet Protocol Numbers”, https://www.iana.org/assignments/protocol-numbers
  9. IETF, “RFC 8200: Internet Protocol, Version 6 (IPv6) Specification”, https://datatracker.ietf.org/doc/html/rfc8200
  10. IETF, “RFC 6936: Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums”, https://datatracker.ietf.org/doc/html/rfc6936

최근 바뀜

더 보기