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

User Datagram Protocol
인터넷 프로토콜 스위트
응용 프로그램레이어
트랜스포트 레이어
인터넷 레이어
링크 레이어

컴퓨터 네트워킹에서 UDP(User Datagram Protocol)는 인터넷 프로토콜 스위트의 핵심 멤버 중 하나입니다.UDP를 사용하면 컴퓨터 응용 프로그램은 인터넷 프로토콜(IP) 네트워크의 다른 호스트에 메시지를 보낼 수 있습니다. 이 경우 데이터그램이라고 합니다.통신 채널 또는 데이터 경로를 설정하기 위해 사전 통신이 필요하지 않습니다.

UDP는 최소한의 프로토콜 메커니즘으로 단순한 무연결 통신 모델을 사용합니다.UDP는 데이터 무결성에 대한 체크섬과 데이터그램의 송신원 및 수신처에 있는 다양한 기능을 처리하기 위한 포트 번호를 제공합니다.핸드쉐이크 다이얼로그가 없기 때문에, 유저의 프로그램은, 기반이 되는 네트워크의 신뢰성에 노출됩니다.전달, 주문, 또는 중복 보호의 보장은 없습니다.네트워크 인터페이스레벨에서 에러 정정 기능이 필요한 경우, 애플리케이션은 대신에, 이 목적을 위해서 설계된 Transmission Control Protocol(TCP) 또는 Stream Control Transmission Protocol(SCTP)을 사용할 수 있습니다.

UDP는 오류 검사 및 수정이 필요하지 않거나 응용 프로그램에서 수행되는 목적에 적합합니다. UDP는 프로토콜 스택에서 이러한 처리의 오버헤드를 방지합니다.패킷의 폐기는 재전송에 의해 지연되는 패킷을 기다리는 것보다 바람직하기 때문에 시간에 민감한 애플리케이션에서는 UDP를 사용하는 경우가 많습니다.이는 실시간시스템에서는 [1]선택사항이 아닐 수 있습니다.

이 프로토콜은 David P에 의해 설계되었다. 1980년에 리드가 정식으로 정의되었습니다. RFC768.

특성

UDP는 RFC 768에 문서화되어 있는 단순한 메시지 지향 전송 계층 프로토콜입니다.UDP는 헤더와 [2]페이로드의 무결성 검증(체크섬을 통해)을 제공하지만 상위 계층 프로토콜에 메시지 전달을 보장하지 않으며 UDP 계층은 한 번 전송된 UDP 메시지 상태를 유지하지 않습니다.이러한 이유로 UDP를 신뢰할 수 없는 데이터그램 [3]프로토콜이라고 부르기도 합니다.전송의 신뢰성이 필요한 경우는, 유저의 애플리케이션에 실장할 필요가 있습니다.

UDP의 속성에는 여러 가지가 있어 특정 응용 프로그램에 특히 적합합니다.

포트

애플리케이션은, 데이터그램 소켓을 사용해 호스트간 통신을 확립할 수 있습니다.애플리케이션은 소켓을 IP 주소와 포트의 조합인 데이터 전송 엔드포인트에 바인드합니다.이와 같이 UDP는 애플리케이션 멀티플렉싱을 제공합니다.포트는 포트 번호(16비트 정수값)로 식별되는 소프트웨어 구조이며 0 ~65535의 포트 번호를 사용할 수 있습니다.포토 0 은 예약되어 있습니다만, 송신 프로세스가 응답 메시지를 상정하지 않는 경우는, 허가되는 송신원포트 값입니다.

Internet Assigned Numbers Authority(IANA; 인터넷 할당 번호 기관)는 포트 번호를 3개의 [4]범위로 분할했습니다.포트 번호 0 ~1023 은, 일반적인 well-known 서비스에 사용됩니다.Unix와 유사한 운영 체제에서 이러한 포트 중 하나를 사용하려면 슈퍼 사용자 운영 권한이 필요합니다.포트 번호 1024 ~49151은 IANA 등록 서비스에 사용되는 등록 포트입니다.포트 49152 ~65535는 특정 서비스에 대해 공식적으로 지정되지 않은 다이내믹포트로, 임의의 목적으로 사용할 수 있습니다.이러한 포트는 사용 후 삭제 포트로 사용될 수도 있습니다.이 포트는 호스트에서 실행 중인 소프트웨어가 필요에 [4]따라 통신 엔드포인트를 동적으로 생성하기 위해 사용할 수 있습니다.

UDP 데이터그램 구조

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 길이 체크섬

UDP 데이터그램은 데이터그램 헤더와 데이터 섹션으로 구성됩니다.UDP 데이터그램헤더는 4개의 필드로 구성되어 있으며 각 필드는 2바이트(16비트)[1]입니다.데이터 섹션은 헤더에 이어 애플리케이션에 대해 전송되는 페이로드 데이터입니다.

IPv4 에서는, 체크 섬필드와 송신원포트 필드의 사용은 옵션입니다(테이블의 분홍색 배경).IPv6 에서는, 송신원포트 필드만이 옵션입니다.

송신원포트 번호
이 필드는, 송신자의 포토(사용했을 경우)를 식별합니다.필요에 따라서 응답하는 포토로 간주합니다.사용하지 않을 경우 0이어야 합니다.소스 호스트가 클라이언트인 경우 포트 번호는 사용 후 삭제 포트 번호일 수 있습니다.송신원호스트가 서버인 경우, 포토 번호는 기존의 포토 [4]번호일 가능성이 있습니다.
수신처 포트 번호
이 필드는 수신기의 포트를 식별합니다.이 필드는 필수입니다.송신원포트 번호와 마찬가지로, 클라이언트가 행선지 호스트인 경우는, 포토 번호가 ephemeral 포토 번호가 되어, 행선지 호스트가 서버인 경우는, 포토 번호가 well-known 포토 [4]번호가 될 가능성이 있습니다.
길이
UDP 헤더 및 UDP 데이터의 길이를 바이트 단위로 지정합니다.최소 길이는 헤더의 길이인8 바이트입니다필드 사이즈는 UDP 데이터그램의 이론상 제한을 65,535바이트(8바이트 헤더 + 65,527바이트 데이터)로 설정합니다.단, 기본 IPv4 프로토콜에 의해 부과되는 데이터 길이의 실제 제한은 65,507바이트(65,535바이트 - 8바이트 UDP 헤더 - 20바이트 IP 헤더)[5]입니다.
IPv6 점보그램을 사용하면 65,[6]535바이트보다 큰 크기의 UDP 데이터그램을 가질 수 있습니다.RFC 2675에서는 UDP 헤더와 UDP 데이터의 길이가 65,535보다 클 경우 length 필드는 0으로 설정되어 있습니다.
체크섬
체크섬 필드는 헤더 및 데이터의 오류 검사에 사용할 수 있습니다.이 필드는 IPv4 에서는 옵션이며 IPv6 [7]에서는 필수입니다.필드는 사용하지 [8]않을 경우 모두 제로를 전송합니다.

체크섬 계산

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

체크섬은 IP 헤더, UDP 헤더 및 데이터의 의사 헤더에 대한 16비트의 보완 합계를 보완한 것으로, 필요에 따라 마지막에 0 옥텟으로 패딩하여 2 옥텟의 [8]배수를 만듭니다.

즉, 모든 16비트 단어들은 하나의 보완 산술로 합산된다.16비트 값을 더합니다.또한 각 반출(17번째 비트)이 생성되면 그 17번째 반출 비트를 회전시켜 주행 [9]합계의 최하위 비트에 가산한다.마지막으로 UDP 체크섬필드의 값을 산출하기 위해 합계가 보완됩니다.

체크섬 계산 결과 값이 0(모두 16비트 0)인 경우, 제로값 체크섬은 체크섬이 [8]계산되지 않았음을 나타내므로 1의 보완값(모두 1s)으로 전송해야 합니다.이 경우 수신기에서 특정 처리는 필요하지 않습니다. 왜냐하면 모든 0과 모든 1은 1의 보완 산술에서 0과 같기 때문입니다.

IPv4 와 IPv6 의 차이는, 체크 섬 계산에 사용되는 의사 헤더에 있습니다.또, 체크 섬이 [10]IPv6 에서는 옵션인 것은 아닙니다.

IPv4 의사 헤더

UDP 가 IPv4 상에서 동작하는 경우, 체크섬은, 실제 IPv4 [8]: 2 헤더로부터의 같은 정보의 일부를 포함한 「의사 헤더」를 사용해 계산됩니다.의사 헤더는, IP 패킷의 송신에 사용되는 실제의 IPv4 헤더가 아니고, 체크섬 계산에만 사용됩니다.

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 송신원IPv4 주소
4 32 수신처 IPv4 주소
8 64 제로즈 프로토콜 UDP 길이
12 96 송신원포트 수신처 포트
16 128 UDP 길이 체크섬
20 160+ 데이터.

송신원주소와 행선지 주소는, IPv4 헤더내의 주소입니다.프로토콜은 UDP의 경우(IP 프로토콜 번호 목록 참조): 17(0x11)입니다.UDP length 필드는 UDP 헤더와 데이터의 길이입니다.필드 데이터는 전송된 데이터를 나타냅니다.

UDP 체크섬 계산은 IPv4의 경우 옵션입니다.체크섬을 사용하지 않을 경우 값 0으로 설정해야 합니다.

IPv6 의사 헤더

UDP가 IPv6 상에서 실행되는 경우 체크섬은 필수입니다.RFC 2460에 기재되어 있는 바와 같이 계산방법이 변경되었습니다.

체크섬 계산에 IP 헤더의 주소를 포함하는 전송 또는 기타 상위 계층 프로토콜은 128비트 IPv6 [7]주소를 포함하도록 IPv6을 통해 사용하도록 수정해야 합니다.

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

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 송신원IPv6 주소
4 32
8 64
12 96
16 128 수신처 IPv6 주소
20 160
24 192
28 224
32 256 UDP 길이
36 288 제로즈 다음 헤더 = 프로토콜[11]
40 320 송신원포트 수신처 포트
44 352 길이 체크섬
48 384+ 데이터.

송신원주소는, IPv6 헤더내의 주소입니다.행선지 주소는 최종 행선지 주소입니다.IPv6 패킷에 라우팅 헤더가 포함되어 있지 않은 경우는, IPv6 헤더의 행선지 주소가 됩니다.그렇지 않은 경우는, 발신기지 노드에서는, 라우팅 헤더의 마지막 요소의 주소가 되어, 수신 노드에서는 IPv6 헤더의 행선지 주소가 됩니다.[ Next Header ]필드의 값은 UDP: 17 의 프로토콜 값입니다.UDP length 필드는 UDP 헤더와 데이터의 길이입니다.

신뢰성 및 폭주 제어

신뢰성이 떨어지면 UDP 응용 프로그램에서 패킷 손실, 순서 변경, 오류 또는 중복이 발생할 수 있습니다.UDP를 사용하는 경우 최종 사용자 애플리케이션은 메시지가 수신되었음을 실시간으로 확인하는 등 필요한 핸드쉐이킹을 제공해야 합니다.TFTP 등의 어플리케이션은 [4]필요에 따라 기본적인 신뢰성 메커니즘을 어플리케이션레이어에 추가할 수 있습니다.애플리케이션이 높은 신뢰성을 필요로 하는 경우 전송 제어 프로토콜과 같은 프로토콜을 대신 사용할 수 있습니다.

대부분의 경우 UDP 애플리케이션은 신뢰성 메커니즘을 사용하지 않으며 이로 인해 장애가 발생할 수도 있습니다.스트리밍 미디어, 실시간멀티플레이어 게임 및 VoIP(Voice over IP)는 UDP를 자주 사용하는 어플리케이션의 예입니다.이러한 어플리케이션에서 패킷 손실은 보통 치명적인 문제가 아닙니다.예를 들어 VoIP에서는 지연과 지터가 주요 관심사입니다.TCP 를 사용하면, 누락된 데이터의 재발송을 요구하고 있는 동안, TCP 가 애플리케이션에 후속의 데이터를 제공하지 않기 때문에, 패킷이 없어지면 지터가 발생합니다.

적용들

Domain Name System(DNS; 도메인네임 시스템), Simple Network Management Protocol(SNMP), Routing Information Protocol(RIP)[1] 및 Dynamic Host Configuration Protocol(DHCP) 등 다수의 주요 인터넷응용 프로그램이 UDP를 사용합니다.

음성 및 비디오 트래픽은 일반적으로 UDP를 사용하여 전송됩니다.실시간 비디오 및 오디오 스트리밍 프로토콜은 때때로 손실되는 패킷을 처리하도록 설계되어 있기 때문에 손실된 패킷이 재발송될 경우 큰 지연이 발생하지 않고 약간의 품질 저하만 발생합니다.모두 TCP및 UDP는 같은 네트워크 위를 달리, 2000년대 중반에 몇몇 기업은 이러한 실시간 응용 프로그램에서 증가하는 UDP트래픽 약간 응용 프로그램 판매, 회계, 그리고 데이터베이스 시스템(때 TCP패킷 손실을 감지하면, 그것의 데이터 속도 사용을 끊기게 될 것이다)의 관점 같은 TCP를 사용하여의 성능을 저하를 발견했다.[12]

OpenVPN 등의 일부 VPN 시스템에서는 신뢰성 높은 접속을 구현하면서 UDP를 사용하여 응용 프로그램레벨에서 에러 체크를 실행할 수 있습니다.

QUIC는 UDP 위에 구축된 전송 프로토콜입니다. QUIC는 신뢰할 수 있고 안전한 연결을 제공합니다.HTTP/3 는, 각각 신뢰성과 시큐러티를 확보하기 위해서 TCP 와 TLS 의 편성을 사용하는 이전 버전의 HTTPS 와 달리, QUIC 를 사용합니다.즉, HTTP/3는 TCP와 TLS에 대해2개의 개별 핸드쉐이크를 사용하는 것이 아니라, 1개의 핸드쉐이크를 사용해 접속을 셋업 하는 것으로, 접속 확립에 걸리는 전체적인 시간이 [13]단축됩니다.

UDP와 TCP의 비교

다음 항목도 참조하십시오.트랜스포트 레이어

Transmission Control Protocol은 연결 지향 프로토콜이며 엔드 투 엔드 통신을 설정하려면 핸드쉐이킹이 필요합니다.연결이 설정되면 연결을 통해 사용자 데이터가 양방향으로 전송될 수 있습니다.

  • 신뢰성 – TCP는 메시지 확인 응답, 재발송신 및 타임아웃을 관리합니다.메시지 전달을 여러 번 시도합니다.도중에 데이터가 손실되면 데이터가 다시 전송됩니다.TCP 에서는, 누락된 데이터가 없거나, 복수의 타임 아웃이 발생했을 경우는, 접속이 드롭 됩니다.
  • Ordered: 2개의 메시지가 순서대로 접속을 통해 전송될 경우 첫 번째 메시지가 수신 응용 프로그램에 먼저 도착합니다.데이터 세그먼트가 잘못된 순서로 착신하면 TCP는 모든 데이터가 올바르게 정렬되어 애플리케이션에 전달될 때까지 순서가 잘못된 데이터를 버퍼링합니다.
  • Heavyweight – TCP는 소켓 연결을 설정하기 위해 3개의 패킷이 있어야 사용자 데이터를 전송할 수 있습니다.TCP 는, 신뢰성과 congestion 제어를 처리합니다.
  • 스트리밍 – 데이터는 바이트 스트림으로 읽혀지며 신호 메시지(세그먼트) 경계에는 구별되는 표시가 전송되지 않습니다.

User Datagram Protocol은 보다 단순한 메시지 기반 무연결 프로토콜입니다.connectionless protocols는 전용 연결을 설정하지 않습니다.수신자의 준비 상태나 상태를 확인하지 않고, 송신원으로부터 송신지까지 한 방향으로 정보를 송신하는 것에 의해서 통신이 실현된다.

  • 신뢰할 수 없음: UDP 메시지가 전송될 때 수신처에 도달할지 여부를 알 수 없습니다.그 도중에 없어질 가능성이 있습니다.확인 응답, 재발송신, 타임아웃의 개념은 없습니다.
  • Not ordered (주문되지 않음)– 2개의 메시지가 같은 수신자에게 발송된 경우, 메시지가 도착하는 순서는 보증할 수 없습니다.
  • Lightweight – 메시지 순서나 추적 연결 등은 없습니다.IP 위에 설계된 매우 단순한 트랜스포트 레이어입니다.
  • 데이터그램: 패킷은 개별적으로 송신되어 착신시에 무결성이 체크됩니다.패킷에는, 수신시에 허가되는 일정한 경계가 있습니다.리시버 소켓에서의 읽기 조작은, 메세지가 최초로 송신되었을 때와 같이 전체로 출력됩니다.
  • congestion 제어 없음– UDP 자체는 congestion를 회피하지 않습니다.congestion 제어 대책은 애플리케이션레벨 또는 네트워크상에서 실장할 필요가 있습니다.
  • 브로드캐스트(접속 없음, UDP는 브로드캐스트 가능)는 서브넷상의 모든 디바이스가 수신할 수 있도록 송신된 패킷을 수신처로 지정할 수 있습니다.
  • 멀티캐스트: 멀티캐스트모드 동작이 지원되므로 단일 데이터그램패킷이 서브스크라이버 그룹에 중복되지 않고 자동으로 라우팅 됩니다.

표준

  • RFC 768 – 사용자 데이터그램 프로토콜
  • RFC 2460 – 인터넷 프로토콜, 버전 6 (IPv6) 사양
  • RFC 2675 – IPv6 점보그램
  • RFC 4113 – UDP용 관리 정보 베이스
  • RFC 8085 - UDP 사용상의 가이드라인

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b c Kurose, J. F.; Ross, K. W. (2010). Computer Networking: A Top-Down Approach (5th ed.). Boston, MA: Pearson Education. ISBN 978-0-13-136548-3.
  2. ^ Clark, M.P. (2003)데이터 네트워크 IP 및 인터넷, 1차판웨스트 서섹스, 영국: John Wiley & Sons Ltd.
  3. ^ content@ipv6.com (15 August 2006). "UDP Protocol Overview". Ipv6.com. Retrieved 17 August 2011.
  4. ^ a b c d e 포우잔, B.A. (2000년)TCP/IP: Protocol Suite, 제1판인도 뉴델리:타타 맥그로-힐 출판사.
  5. ^ Stevens, W. Richard (1994). TCP/IP Illustrated: The protocols. Vol. 1 (2 ed.). Addison-Wesley. ISBN 978-0-20-163346-7.
  6. ^ RFC 2675
  7. ^ a b Deering S. & Hinden R. (December 1998). "Internet Protocol, Version 6 (IPv6) Specification". Internet Engineering Task Force. RFC 2460.
  8. ^ a b c d Postel, J. (August 1980). User Datagram Protocol. Internet Engineering Task Force. doi:10.17487/RFC0768. RFC 768.
  9. ^ "Compute 16-bit One's Complement Sum". mathforum.org. John. 20 March 2002. Archived from the original (email) on 17 November 2020. Retrieved 5 November 2014.
  10. ^ Internet Protocol, Version 6 (IPv6) Specification. p. 27-28. doi:10.17487/RFC8200. RFC 8200.
  11. ^ Next Header 필드의 값은 UDP의 프로토콜 값입니다.
  12. ^ "The impact of UDP on Data Applications". Networkperformancedaily.com. Archived from the original on 31 July 2007. Retrieved 17 August 2011.
  13. ^ "QUIC, a multiplexed stream transport over UDP". chromium.org. Retrieved 17 February 2021.

외부 링크

Wikdiversity에는 사용자 데이터그램 프로토콜에 대한 학습 리소스가 있습니다.