사용자 데이터그램 프로토콜

UDP은 여기로 연결됩니다. 다른 뜻에 대해서는 UDP (동음이의) 문서를 참고하십시오.
사용자 데이터그램 프로토콜
User Datagram Protocol
통신 프로토콜
개발데이비드 P. 리드
도입일1980
영향을 받음QUIC, UDP-라이트
OSI 계층전송 계층 (4)
RFC768

컴퓨터 망에서 사용자 데이터그램 프로토콜(User Datagram Protocol, UDP)은 인터넷 프로토콜 스위트의 핵심 통신 프로토콜 중 하나로, 인터넷 프로토콜(IP) 네트워크의 다른 호스트로 메시지(데이터그램으로 패킷에 담겨 전송됨)를 보내는 데 사용된다. IP 네트워크 내에서 UDP는 통신 채널이나 데이터 경로를 설정하기 위해 사전 통신을 요구하지 않는다.

UDP는 비연결 지향 프로토콜이며, 이는 연결 협상 없이 메시지를 보내고 UDP가 보낸 내용을 추적하지 않는다는 의미이다. UDP는 데이터 무결성을 위한 체크섬과 데이터그램의 송수신지에서 다른 기능을 주소 지정하기 위한 포트 번호를 제공한다. 핸드셰이킹 대화가 없으므로 사용자의 프로그램이 기본 네트워크의 비신뢰성에 노출된다. 즉, 전달, 순서 지정 또는 중복 방지에 대한 보장이 없다. 네트워크 인터페이스 수준에서 오류 수정 기능이 필요한 경우, 애플리케이션은 이를 위해 설계된 전송 제어 프로토콜(TCP) 또는 스트림 제어 전송 프로토콜(SCTP)을 대신 사용할 수 있다.

UDP는 오류 검사 및 수정이 필요하지 않거나 애플리케이션에서 수행되는 목적에 적합하다. UDP는 프로토콜 스택에서 이러한 처리 오버헤드를 피한다. 시간에 민감한 애플리케이션은 실시간 시스템에서 선택 사항이 아닐 수 있는 재전송으로 인해 지연된 패킷을 기다리는 것보다 패킷을 삭제하는 것이 더 좋기 때문에 UDP를 자주 사용한다.

이 프로토콜은 데이비드 P. 리드가 1980년에 설계했으며 RFC 768에 공식적으로 정의되었다.

속성

UDP는 RFC 768에 문서화된 간단한 메시지 지향 전송 계층 프로토콜이다. UDP는 헤더와 페이로드의 무결성 확인(체크섬을 통해)을 제공하지만 메시지 전달에 대한 상위 계층 프로토콜에 대한 보장을 제공하지 않으며, UDP 계층은 일단 전송된 UDP 메시지의 상태를 유지하지 않는다. 이러한 이유로 UDP는 때때로 비신뢰적 데이터그램 프로토콜이라고도 불린다. 전송 신뢰성이 요구되는 경우, 이는 사용자 애플리케이션에서 구현되어야 한다.

UDP의 여러 속성은 특정 애플리케이션에 특히 적합하다.

포트

애플리케이션은 데이터그램 소켓을 사용하여 호스트-투-호스트 통신을 설정할 수 있다. 애플리케이션은 소켓을 데이터 전송의 엔드포인트에 바인딩하며, 이 엔드포인트는 IP 주소와 포트의 조합이다. 이러한 방식으로 UDP는 애플리케이션 다중화를 제공한다. 포트는 포트 번호, 즉 0에서 65535 사이의 포트 번호를 허용하는 16비트 정수 값으로 식별되는 소프트웨어 구조이다. 포트 0은 예약되어 있지만, 전송 프로세스가 응답 메시지를 기대하지 않는 경우 허용되는 소스 포트 값이다.

인터넷 할당 번호 관리기관 (IANA)은 포트 번호를 세 가지 범위로 나누었다. 0부터 1023까지의 포트 번호는 일반적인 잘 알려진 서비스에 사용된다. 유닉스 계열 운영체제에서는 이러한 포트 중 하나를 사용하려면 슈퍼유저 운영 권한이 필요하다. 1024부터 49151까지의 포트 번호는 IANA에 등록된 서비스에 사용되는 등록된 포트이다. 49152부터 65535까지의 포트 번호는 공식적으로 특정 서비스에 지정되지 않았으며 어떤 목적으로든 사용될 수 있는 동적 포트이다. 이들은 또한 호스트에서 실행되는 소프트웨어가 필요에 따라 통신 엔드포인트를 동적으로 생성하는 데 사용할 수 있는 임시 포트로 사용될 수도 있다.

UDP 데이터그램 구조

UDP 데이터그램은 데이터그램 헤더 다음에 데이터 섹션(애플리케이션의 페이로드 데이터)으로 구성된다. UDP 데이터그램 헤더는 각각 2바이트(16비트)인 4개의 필드로 구성된다.

UDP 헤더 형식
오프셋 옥텟 0 1 2 3
옥텟 비트 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 소스 포트 목적지 포트
4 32 길이 체크섬
8 64 데이터
12 96
⋮ ⋮

체크섬 및 소스 포트 필드의 사용은 IPv4에서 선택 사항이다(표에서 연한 보라색 배경). IPv6에서는 소스 포트 필드만 선택 사항이다. 사용되지 않는 경우 이 필드는 0으로 설정해야 한다.

소스 포트: 16 bits:이 필드는 사용될 때 송신자의 포트를 식별하며, 필요한 경우 응답할 포트로 가정해야 한다. 소스 호스트가 클라이언트인 경우 포트 번호는 임시 포트일 가능성이 높다. 소스 호스트가 서버인 경우 포트 번호는 0에서 1023까지의 잘 알려진 포트 번호일 가능성이 높다.
목적지 포트: 16 bits:이 필드는 수신자의 포트를 식별하며 필수이다. 소스 포트 번호와 유사하게, 클라이언트가 목적지 호스트인 경우 포트 번호는 임시 포트 번호일 가능성이 높고, 목적지 호스트가 서버인 경우 포트 번호는 잘 알려진 포트 번호일 가능성이 높다.
길이: 16 bits:이 필드는 UDP 데이터그램(헤더 필드 및 데이터 필드)의 길이를 옥텟 단위로 바이트로 지정한다. 최소 길이는 헤더의 길이인 8바이트이다. 필드 크기는 UDP 데이터그램에 대해 65,535바이트(8바이트 헤더 + 65,527바이트 데이터)의 이론적인 한계를 설정한다. 그러나 기본 IPv4 프로토콜에 의해 부과되는 데이터 길이의 실제 한계는 65,507바이트(65,535바이트 − 8바이트 UDP 헤더 − 20바이트 IP 헤더)이다.
IPv6 점보그램을 사용하면 65,535바이트보다 큰 UDP 데이터그램을 가질 수 있다. UDP 헤더와 UDP 데이터의 길이가 65,535보다 크면 길이 필드는 0으로 설정된다.
체크섬: 16 bits:체크섬 필드는 헤더와 데이터의 오류 검사에 사용될 수 있다. 이 필드는 IPv4에서는 선택 사항이며, IPv6에서는 대부분의 경우 필수이다.
데이터: Variable:UDP 패킷의 페이로드.

체크섬 계산

체크섬 계산에 사용되는 방법은 RFC 768에 정의되어 있으며, 효율적인 계산은 RFC 1071에 설명되어 있다.

체크섬은 IP 헤더의 정보, UDP 헤더, 데이터로부터의 가상 헤더의 1의 보수 합에 대한 16비트 1의 보수이며, 끝에 (필요한 경우) 0 옥텟으로 채워져 두 옥텟의 배수가 되도록 한다.

즉, 모든 16비트 워드는 1의 보수 산술을 사용하여 합산된다. 16비트 값들을 더한다. 각 덧셈에서, 캐리 아웃(17번째 비트)이 생성되면, 그 17번째 캐리 비트를 뒤로 돌려 실행 중인 합계의 최하위 비트에 더한다. 마지막으로, 합계는 1의 보수로 변환되어 UDP 체크섬 필드의 값을 생성한다.

체크섬 계산 결과가 0(모든 16비트가 0)인 경우, 1의 보수(모든 1)로 전송되어야 한다. 왜냐하면 0 값 체크섬은 체크섬이 계산되지 않았음을 나타내기 때문이다. 이 경우, 수신자는 특별한 처리가 필요하지 않다. 왜냐하면 모든 0과 모든 1은 1의 보수 산술에서 0과 같기 때문이다.

IPv4와 IPv6의 차이점은 체크섬을 계산하는 데 사용되는 의사 헤더와 IPv6에서는 체크섬이 선택 사항이 아니라는 점이다. 특정 조건 하에서, IPv6를 사용하는 UDP 애플리케이션은 터널 프로토콜과 함께 UDP 0-체크섬 모드를 사용할 수 있다.

IPv4 의사 헤더

UDP가 IPv4 위에서 실행될 때, 체크섬은 실제 IPv4 헤더의 일부 정보를 포함하는 의사 헤더를 사용하여 계산된다.: 2  이 의사 헤더는 IP 패킷을 전송하는 데 사용되는 실제 IPv4 헤더가 아니라 체크섬 계산에만 사용된다. IPv4의 경우 UDP 체크섬 계산은 선택 사항이다. 체크섬을 사용하지 않으면 값은 0으로 설정되어야 한다.

체크섬 계산을 위한 UDP 의사 헤더 (IPv4)
오프셋 옥텟 0 1 2 3
옥텟 비트 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 원본 주소
4 32 목적지 주소
8 64 0들 프로토콜 UDP 길이
12 96 원본 포트 목적지 포트
16 128 길이 체크섬
20 160 데이터
24 192
⋮ ⋮

체크섬은 다음 필드에 대해 계산된다.

원본 주소: 32 bits:IPv4 헤더의 원본 주소.
목적지 주소: 32 bits:IPv4 헤더의 목적지 주소.
0들: 8 bits; Zeroes == 0:모두 0.
프로토콜: 8 bits:UDP의 프로토콜 값: 17 (또는 0x11).
UDP 길이: 16 bits:UDP 헤더와 데이터의 길이 (옥텟 단위).

IPv6 의사 헤더

IPv6는 더 큰 주소와 다른 헤더 레이아웃을 가지고 있으므로, 체크섬을 계산하는 데 사용되는 방식도 그에 따라 변경된다.: §8.1 

체크섬 계산에 IP 헤더의 주소를 포함하는 모든 전송 또는 기타 상위 계층 프로토콜은 32비트 IPv4 주소 대신 128비트 IPv6 주소를 포함하도록 IPv6에서 사용하기 위해 수정되어야 한다.

체크섬을 계산할 때 실제 IPv6 헤더를 모방한 의사 헤더가 다시 사용된다.

체크섬 계산을 위한 UDP 의사 헤더 (IPv6)
오프셋 옥텟 0 1 2 3
옥텟 비트 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 원본 주소
4 32
8 64
12 96
16 128 목적지 주소
20 160
24 192
28 224
32 256 UDP 길이
36 288 0 (0) 다음 헤더 (17)
40 320 원본 포트 목적지 포트
44 352 길이 체크섬
48 384 데이터
52 416
⋮ ⋮

체크섬은 다음 필드를 사용하여 계산된다.

원본 주소: 128 bits:IPv6 헤더의 주소.
목적지 주소: 128 bits:최종 목적지; IPv6 패킷이 라우팅 헤더를 포함하지 않으면 TCP는 IPv6 헤더의 목적지 주소를 사용하고, 그렇지 않으면 출발 노드에서는 라우팅 헤더의 마지막 요소에 있는 주소를 사용하며, 수신 노드에서는 IPv6 헤더의 목적지 주소를 사용한다.
UDP 길이: 32 bits:UDP 헤더 및 데이터의 길이(옥텟으로 측정).
0: 24 bits; Zeroes == 0:모두 0.
다음 헤더: 8 bits:UDP의 전송 계층 프로토콜 값: 17.

신뢰성 및 혼잡 제어

신뢰성이 부족한 UDP 애플리케이션은 일부 패킷 손실, 재정렬, 오류 또는 중복을 겪을 수 있다. UDP를 사용하는 경우 최종 사용자 애플리케이션은 메시지가 수신되었음을 실시간으로 확인하는 등의 필요한 핸드셰이킹을 제공해야 한다. TFTP와 같은 애플리케이션은 필요에 따라 애플리케이션 계층에 기본적인 신뢰성 메커니즘을 추가할 수 있다. 애플리케이션이 높은 신뢰성을 요구하는 경우, 전송 제어 프로토콜과 같은 프로토콜을 대신 사용할 수 있다.

대부분의 경우 UDP 애플리케이션은 신뢰성 메커니즘을 사용하지 않으며, 오히려 그러한 메커니즘에 의해 방해를 받을 수도 있다. 스트리밍, 실시간 멀티플레이어 게임 및 음성 인터넷 프로토콜 (VoIP)은 종종 UDP를 사용하는 애플리케이션의 예이다. 이러한 특정 애플리케이션에서는 패킷 손실이 일반적으로 치명적인 문제는 아니다. 예를 들어 VoIP에서는 대기 시간과 지터가 주요 관심사이다. TCP를 사용하면 손실된 패킷을 재전송할 것을 요청하는 동안 TCP가 애플리케이션에 후속 데이터를 제공하지 않기 때문에 패킷이 손실될 경우 지터가 발생할 수 있다.

애플리케이션

수많은 주요 인터넷 애플리케이션은 도메인 네임 시스템 (DNS), 간이 망 관리 프로토콜 (SNMP), 라우팅 정보 프로토콜 (RIP) 및 동적 호스트 구성 프로토콜 (DHCP)을 포함하여 UDP를 사용한다.

음성 및 비디오 트래픽은 일반적으로 UDP를 사용하여 전송된다. 실시간 비디오 및 오디오 스트리밍 프로토콜은 가끔 손실되는 패킷을 처리하도록 설계되어, 손실된 패킷을 재전송할 경우 발생하는 큰 지연 대신 약간의 품질 저하만 발생한다. TCP와 UDP가 모두 동일한 네트워크에서 실행되기 때문에 2000년대 중반에 일부 기업은 이러한 실시간 애플리케이션의 UDP 트래픽 증가가 판매 시점 정보 관리, 회계용 소프트웨어, 데이터베이스 관리 시스템과 같은 TCP를 사용하는 애플리케이션의 성능을 약간 저해한다는 사실을 발견했다(TCP는 패킷 손실을 감지하면 데이터 전송 속도 사용량을 조절한다).

오픈VPN과 같은 일부 VPN 시스템은 UDP를 사용하고 애플리케이션 수준에서 오류 검사를 수행하면서 신뢰할 수 있는 연결을 구현할 수 있다. 와이어가드는 UDP를 사용하고 오류 검사를 수행하지만, 신뢰성 보장을 제공하지 않으므로 캡슐화된 프로토콜이 처리하도록 맡긴다.

QUIC은 UDP 위에 구축된 전송 프로토콜이다. QUIC은 안정적이고 보안적인 연결을 제공한다. HTTP/3은 이전 버전의 HTTPS가 TCP와 TLS의 조합을 사용하여 각각 신뢰성과 보안을 보장했던 것과는 달리 QUIC을 사용한다. 이는 HTTP/3이 TCP와 TLS에 대해 두 개의 별도 핸드셰이크를 갖는 대신 단일 핸드셰이크를 사용하여 연결을 설정하므로 연결 설정에 걸리는 전체 시간이 줄어든다는 것을 의미한다.

UDP와 TCP의 비교

전송 제어 프로토콜은 연결 지향 프로토콜이며 종단 간 통신을 설정하기 위해 핸드셰이킹이 필요하다. 일단 연결이 설정되면 사용자 데이터는 연결을 통해 양방향으로 전송될 수 있다.

사용자 데이터그램 프로토콜은 더 간단한 메시지 기반의 비연결 프로토콜이다. 비연결 프로토콜은 전용 종단 간 연결을 설정하지 않는다. 통신은 수신자의 준비 상태나 상태를 확인하지 않고 원본에서 목적지로 단방향으로 정보를 전송함으로써 이루어진다.

표준

같이 보기

각주

  1. ↑ Castelli, Matthew J. (2003). 《Network Sales and Services Handbook》. Cisco Press. ISBN 9781587050909.
  2. ↑ Stanek, William (2015). 《Windows Command Line: The Personal Trainer for Windows 8.1 Windows Server 2012 and Windows Server 2012 R2》. Stanek & Associates. ISBN 9781627164139.
  3. 1 2 3 Kurose, J. F.; Ross, K. W. (2010). 《Computer Networking: A Top-Down Approach》 5판. Boston, MA: Pearson Education. ISBN 978-0-13-136548-3.
  4. ↑ Clark, M.P. (2003). Data Networks IP and the Internet, 1st ed. West Sussex, England: John Wiley & Sons Ltd.
  5. ↑ content@ipv6.com (2006년 8월 15일). “UDP Protocol Overview”. Ipv6.com. 2011년 9월 4일에 원본 문서에서 보존된 문서. 2011년 8월 17일에 확인함.
  6. 1 2 3 4 5 Forouzan, B.A. (2000). TCP/IP: Protocol Suite, 1st ed. New Delhi, India: Tata McGraw-Hill Publishing Company Limited.
  7. 1 2 3 4 5 J. Postel, ed. (28 August 1980). User Datagram Protocol. IETF. STD 6. RFC 768. https://tools.ietf.org/html/rfc768. Internet Standard 6.
  8. ↑ Stevens, W. Richard (1994). 《TCP/IP Illustrated: The protocols》 2판 1. Addison-Wesley. ISBN 978-0-20-163346-7.
  9. ↑ D. Borman; S. Deering; R. Hinden (August 1999). IPv6 Jumbograms. Network Working Group. RFC 2675. https://tools.ietf.org/html/rfc2675. Proposed Standard. Obsoletes RFC 2147.
  10. 1 2 S. Deering; R. Hinden (July 2017). Internet Protocol, Version 6 (IPv6) Specification. Internet Engineering Task Force. STD 86. RFC 8200. https://tools.ietf.org/html/rfc8200. Internet Standard 86. Obsoletes RFC 2460.
  11. ↑ “Compute 16-bit Ones' Complement Sum”. 《mathforum.org》. John. 2002년 3월 20일. 2020년 11월 17일에 원본 문서 (email)에서 보존된 문서. 2014년 11월 5일에 확인함.
  12. ↑ Internet Protocol, Version 6 (IPv6) Specification. p. 27-28. RFC 8200. https://tools.ietf.org/html/rfc8200#page-27-28.
  13. ↑ Internet Protocol, Version 6 (IPv6) Specification. p. 23. RFC 8085. https://tools.ietf.org/html/rfc8085#page-23.
  14. ↑ “The impact of UDP on Data Applications”. Networkperformancedaily.com. 2011년 8월 17일에 확인함.
  15. ↑ “QUIC, a multiplexed stream transport over UDP”. 《chromium.org》. 2021년 2월 17일에 확인함.

외부 링크