상위 질문
타임라인
채팅
관점
사용자 데이터그램 프로토콜
인터넷 프로토콜 스위트의 주요 프로토콜 가운데 하나 위키백과, 무료 백과사전
Remove ads
UDP은 여기로 연결됩니다. 다른 뜻에 대해서는 UDP (동음이의) 문서를 참고하십시오.컴퓨터 망에서 사용자 데이터그램 프로토콜(User Datagram Protocol, UDP)은 인터넷 프로토콜 스위트의 핵심 통신 프로토콜 중 하나로, 인터넷 프로토콜(IP) 네트워크의 다른 호스트로 메시지(데이터그램으로 패킷에 담겨 전송됨)를 보내는 데 사용된다. IP 네트워크 내에서 UDP는 통신 채널이나 데이터 경로를 설정하기 위해 사전 통신을 요구하지 않는다.
UDP는 비연결 지향 프로토콜이며, 이는 연결 협상 없이 메시지를 보내고 UDP가 보낸 내용을 추적하지 않는다는 의미이다.[1][2] UDP는 데이터 무결성을 위한 체크섬과 데이터그램의 송수신지에서 다른 기능을 주소 지정하기 위한 포트 번호를 제공한다. 핸드셰이킹 대화가 없으므로 사용자의 프로그램이 기본 네트워크의 비신뢰성에 노출된다. 즉, 전달, 순서 지정 또는 중복 방지에 대한 보장이 없다. 네트워크 인터페이스 수준에서 오류 수정 기능이 필요한 경우, 애플리케이션은 이를 위해 설계된 전송 제어 프로토콜(TCP) 또는 스트림 제어 전송 프로토콜(SCTP)을 대신 사용할 수 있다.
UDP는 오류 검사 및 수정이 필요하지 않거나 애플리케이션에서 수행되는 목적에 적합하다. UDP는 프로토콜 스택에서 이러한 처리 오버헤드를 피한다. 시간에 민감한 애플리케이션은 실시간 시스템에서 선택 사항이 아닐 수 있는 재전송으로 인해 지연된 패킷을 기다리는 것보다 패킷을 삭제하는 것이 더 좋기 때문에 UDP를 자주 사용한다.[3]
Remove ads
속성
UDP는 RFC 768에 문서화된 간단한 메시지 지향 전송 계층 프로토콜이다. UDP는 헤더와 페이로드의 무결성 확인(체크섬을 통해)을 제공하지만[4] 메시지 전달에 대한 상위 계층 프로토콜에 대한 보장을 제공하지 않으며, UDP 계층은 일단 전송된 UDP 메시지의 상태를 유지하지 않는다. 이러한 이유로 UDP는 때때로 비신뢰적 데이터그램 프로토콜이라고도 불린다.[5] 전송 신뢰성이 요구되는 경우, 이는 사용자 애플리케이션에서 구현되어야 한다.
UDP의 여러 속성은 특정 애플리케이션에 특히 적합하다.
- 도메인 네임 시스템 또는 네트워크 타임 프로토콜과 같은 간단한 쿼리-응답 프로토콜에 적합한 트랜잭션 지향적이다.
- IP 터널링 또는 원격 프로시저 호출 및 네트워크 파일 시스템과 같은 다른 프로토콜 모델링에 적합한 데이터그램을 제공한다.
- 동적 호스트 구성 프로토콜 및 단순 파일 전송 프로토콜과 같이 전체 프로토콜 스택 없이 부트스트래핑 또는 기타 목적에 적합한 단순하다.
- IPTV와 같은 스트리밍 애플리케이션에서와 같이 매우 많은 수의 클라이언트에 적합한 무상태이다.
- 재전송 지연이 없으므로 음성 인터넷 프로토콜, 온라인 게임 및 실시간 스트리밍 프로토콜을 사용하는 많은 프로토콜과 같은 실시간 애플리케이션에 적합하다.
- 멀티캐스트를 지원하므로 많은 종류의 서비스 검색 및 정밀 시각 프로토콜 및 라우팅 정보 프로토콜과 같은 공유 정보에서와 같이 브로드캐스트 정보에 적합하다.
Remove ads
포트
애플리케이션은 데이터그램 소켓을 사용하여 호스트-투-호스트 통신을 설정할 수 있다. 애플리케이션은 소켓을 데이터 전송의 엔드포인트에 바인딩하며, 이 엔드포인트는 IP 주소와 포트의 조합이다. 이러한 방식으로 UDP는 애플리케이션 다중화를 제공한다. 포트는 포트 번호, 즉 0에서 65535 사이의 포트 번호를 허용하는 16비트 정수 값으로 식별되는 소프트웨어 구조이다. 포트 0은 예약되어 있지만, 전송 프로세스가 응답 메시지를 기대하지 않는 경우 허용되는 소스 포트 값이다.
인터넷 할당 번호 관리기관 (IANA)은 포트 번호를 세 가지 범위로 나누었다.[6] 0부터 1023까지의 포트 번호는 일반적인 잘 알려진 서비스에 사용된다. 유닉스 계열 운영체제에서는 이러한 포트 중 하나를 사용하려면 슈퍼유저 운영 권한이 필요하다. 1024부터 49151까지의 포트 번호는 IANA에 등록된 서비스에 사용되는 등록된 포트이다. 49152부터 65535까지의 포트 번호는 공식적으로 특정 서비스에 지정되지 않았으며 어떤 목적으로든 사용될 수 있는 동적 포트이다. 이들은 또한 호스트에서 실행되는 소프트웨어가 필요에 따라 통신 엔드포인트를 동적으로 생성하는 데 사용할 수 있는 임시 포트로 사용될 수도 있다.[6]
Remove ads
UDP 데이터그램 구조
요약
관점
UDP 데이터그램은 데이터그램 헤더 다음에 데이터 섹션(애플리케이션의 페이로드 데이터)으로 구성된다. UDP 데이터그램 헤더는 각각 2바이트(16비트)인 4개의 필드로 구성된다.[3]
체크섬 및 소스 포트 필드의 사용은 IPv4에서 선택 사항이다(표에서 연한 보라색 배경). IPv6에서는 소스 포트 필드만 선택 사항이다. 사용되지 않는 경우 이 필드는 0으로 설정해야 한다.[7]
- 소스 포트: 16 bits:이 필드는 사용될 때 송신자의 포트를 식별하며, 필요한 경우 응답할 포트로 가정해야 한다. 소스 호스트가 클라이언트인 경우 포트 번호는 임시 포트일 가능성이 높다. 소스 호스트가 서버인 경우 포트 번호는 0에서 1023까지의 잘 알려진 포트 번호일 가능성이 높다.[6]
- 목적지 포트: 16 bits:이 필드는 수신자의 포트를 식별하며 필수이다. 소스 포트 번호와 유사하게, 클라이언트가 목적지 호스트인 경우 포트 번호는 임시 포트 번호일 가능성이 높고, 목적지 호스트가 서버인 경우 포트 번호는 잘 알려진 포트 번호일 가능성이 높다.[6]
- 길이: 16 bits:이 필드는 UDP 데이터그램(헤더 필드 및 데이터 필드)의 길이를 옥텟 단위로 바이트로 지정한다. 최소 길이는 헤더의 길이인 8바이트이다. 필드 크기는 UDP 데이터그램에 대해 65,535바이트(8바이트 헤더 + 65,527바이트 데이터)의 이론적인 한계를 설정한다. 그러나 기본 IPv4 프로토콜에 의해 부과되는 데이터 길이의 실제 한계는 65,507바이트(65,535바이트 − 8바이트 UDP 헤더 − 20바이트 IP 헤더)이다.[8]
- IPv6 점보그램을 사용하면 65,535바이트보다 큰 UDP 데이터그램을 가질 수 있다. UDP 헤더와 UDP 데이터의 길이가 65,535보다 크면 길이 필드는 0으로 설정된다.[9]
- 체크섬: 16 bits:체크섬 필드는 헤더와 데이터의 오류 검사에 사용될 수 있다. 이 필드는 IPv4에서는 선택 사항이며, IPv6에서는 대부분의 경우 필수이다.[10]
- 데이터: Variable:UDP 패킷의 페이로드.
체크섬 계산
요약
관점
체크섬 계산에 사용되는 방법은 RFC 768에 정의되어 있으며, 효율적인 계산은 RFC 1071에 설명되어 있다.
체크섬은 IP 헤더의 정보, UDP 헤더, 데이터로부터의 가상 헤더의 1의 보수 합에 대한 16비트 1의 보수이며, 끝에 (필요한 경우) 0 옥텟으로 채워져 두 옥텟의 배수가 되도록 한다.[7]
즉, 모든 16비트 워드는 1의 보수 산술을 사용하여 합산된다. 16비트 값들을 더한다. 각 덧셈에서, 캐리 아웃(17번째 비트)이 생성되면, 그 17번째 캐리 비트를 뒤로 돌려 실행 중인 합계의 최하위 비트에 더한다.[11] 마지막으로, 합계는 1의 보수로 변환되어 UDP 체크섬 필드의 값을 생성한다.
체크섬 계산 결과가 0(모든 16비트가 0)인 경우, 1의 보수(모든 1)로 전송되어야 한다. 왜냐하면 0 값 체크섬은 체크섬이 계산되지 않았음을 나타내기 때문이다.[7] 이 경우, 수신자는 특별한 처리가 필요하지 않다. 왜냐하면 모든 0과 모든 1은 1의 보수 산술에서 0과 같기 때문이다.
IPv4와 IPv6의 차이점은 체크섬을 계산하는 데 사용되는 의사 헤더와 IPv6에서는 체크섬이 선택 사항이 아니라는 점이다.[12] 특정 조건 하에서, IPv6를 사용하는 UDP 애플리케이션은 터널 프로토콜과 함께 UDP 0-체크섬 모드를 사용할 수 있다.[13]
IPv4 의사 헤더
UDP가 IPv4 위에서 실행될 때, 체크섬은 실제 IPv4 헤더의 일부 정보를 포함하는 의사 헤더를 사용하여 계산된다.[7]:2 이 의사 헤더는 IP 패킷을 전송하는 데 사용되는 실제 IPv4 헤더가 아니라 체크섬 계산에만 사용된다. IPv4의 경우 UDP 체크섬 계산은 선택 사항이다. 체크섬을 사용하지 않으면 값은 0으로 설정되어야 한다.
체크섬은 다음 필드에 대해 계산된다.
- 원본 주소: 32 bits:IPv4 헤더의 원본 주소.
- 목적지 주소: 32 bits:IPv4 헤더의 목적지 주소.
- 0들: 8 bits; Zeroes == 0:모두 0.
- 프로토콜: 8 bits:UDP의 프로토콜 값: 17 (또는 0x11).
- UDP 길이: 16 bits:UDP 헤더와 데이터의 길이 (옥텟 단위).
IPv6 의사 헤더
IPv6는 더 큰 주소와 다른 헤더 레이아웃을 가지고 있으므로, 체크섬을 계산하는 데 사용되는 방식도 그에 따라 변경된다.[10](§8.1)
체크섬 계산에 IP 헤더의 주소를 포함하는 모든 전송 또는 기타 상위 계층 프로토콜은 32비트 IPv4 주소 대신 128비트 IPv6 주소를 포함하도록 IPv6에서 사용하기 위해 수정되어야 한다.
체크섬을 계산할 때 실제 IPv6 헤더를 모방한 의사 헤더가 다시 사용된다.
체크섬은 다음 필드를 사용하여 계산된다.
- 원본 주소: 128 bits:IPv6 헤더의 주소.
- 목적지 주소: 128 bits:최종 목적지; IPv6 패킷이 라우팅 헤더를 포함하지 않으면 TCP는 IPv6 헤더의 목적지 주소를 사용하고, 그렇지 않으면 출발 노드에서는 라우팅 헤더의 마지막 요소에 있는 주소를 사용하며, 수신 노드에서는 IPv6 헤더의 목적지 주소를 사용한다.
- UDP 길이: 32 bits:UDP 헤더 및 데이터의 길이(옥텟으로 측정).
- 0: 24 bits; Zeroes == 0:모두 0.
- 다음 헤더: 8 bits:UDP의 전송 계층 프로토콜 값: 17.
Remove ads
신뢰성 및 혼잡 제어
신뢰성이 부족한 UDP 애플리케이션은 일부 패킷 손실, 재정렬, 오류 또는 중복을 겪을 수 있다. UDP를 사용하는 경우 최종 사용자 애플리케이션은 메시지가 수신되었음을 실시간으로 확인하는 등의 필요한 핸드셰이킹을 제공해야 한다. TFTP와 같은 애플리케이션은 필요에 따라 애플리케이션 계층에 기본적인 신뢰성 메커니즘을 추가할 수 있다.[6] 애플리케이션이 높은 신뢰성을 요구하는 경우, 전송 제어 프로토콜과 같은 프로토콜을 대신 사용할 수 있다.
대부분의 경우 UDP 애플리케이션은 신뢰성 메커니즘을 사용하지 않으며, 오히려 그러한 메커니즘에 의해 방해를 받을 수도 있다. 스트리밍, 실시간 멀티플레이어 게임 및 음성 인터넷 프로토콜 (VoIP)은 종종 UDP를 사용하는 애플리케이션의 예이다. 이러한 특정 애플리케이션에서는 패킷 손실이 일반적으로 치명적인 문제는 아니다. 예를 들어 VoIP에서는 대기 시간과 지터가 주요 관심사이다. TCP를 사용하면 손실된 패킷을 재전송할 것을 요청하는 동안 TCP가 애플리케이션에 후속 데이터를 제공하지 않기 때문에 패킷이 손실될 경우 지터가 발생할 수 있다.
Remove ads
애플리케이션
수많은 주요 인터넷 애플리케이션은 도메인 네임 시스템 (DNS), 간이 망 관리 프로토콜 (SNMP), 라우팅 정보 프로토콜 (RIP)[3] 및 동적 호스트 구성 프로토콜 (DHCP)을 포함하여 UDP를 사용한다.
음성 및 비디오 트래픽은 일반적으로 UDP를 사용하여 전송된다. 실시간 비디오 및 오디오 스트리밍 프로토콜은 가끔 손실되는 패킷을 처리하도록 설계되어, 손실된 패킷을 재전송할 경우 발생하는 큰 지연 대신 약간의 품질 저하만 발생한다. TCP와 UDP가 모두 동일한 네트워크에서 실행되기 때문에 2000년대 중반에 일부 기업은 이러한 실시간 애플리케이션의 UDP 트래픽 증가가 판매 시점 정보 관리, 회계용 소프트웨어, 데이터베이스 관리 시스템과 같은 TCP를 사용하는 애플리케이션의 성능을 약간 저해한다는 사실을 발견했다(TCP는 패킷 손실을 감지하면 데이터 전송 속도 사용량을 조절한다).[14]
오픈VPN과 같은 일부 VPN 시스템은 UDP를 사용하고 애플리케이션 수준에서 오류 검사를 수행하면서 신뢰할 수 있는 연결을 구현할 수 있다. 와이어가드는 UDP를 사용하고 오류 검사를 수행하지만, 신뢰성 보장을 제공하지 않으므로 캡슐화된 프로토콜이 처리하도록 맡긴다.
QUIC은 UDP 위에 구축된 전송 프로토콜이다. QUIC은 안정적이고 보안적인 연결을 제공한다. HTTP/3은 이전 버전의 HTTPS가 TCP와 TLS의 조합을 사용하여 각각 신뢰성과 보안을 보장했던 것과는 달리 QUIC을 사용한다. 이는 HTTP/3이 TCP와 TLS에 대해 두 개의 별도 핸드셰이크를 갖는 대신 단일 핸드셰이크를 사용하여 연결을 설정하므로 연결 설정에 걸리는 전체 시간이 줄어든다는 것을 의미한다.[15]
Remove ads
UDP와 TCP의 비교
요약
관점
전송 제어 프로토콜은 연결 지향 프로토콜이며 종단 간 통신을 설정하기 위해 핸드셰이킹이 필요하다. 일단 연결이 설정되면 사용자 데이터는 연결을 통해 양방향으로 전송될 수 있다.
- 신뢰성 – TCP는 메시지 확인, 재전송 및 시간 초과를 관리한다. 메시지를 전달하기 위해 여러 번 시도한다. 도중에 데이터가 손실되면 데이터는 재전송된다. TCP에서는 누락된 데이터가 없거나, 여러 번 시간 초과가 발생하면 연결이 끊어진다.
- 순서 유지 – 두 메시지가 순서대로 연결을 통해 전송되면 첫 번째 메시지가 먼저 수신 애플리케이션에 도달한다. 데이터 세그먼트가 잘못된 순서로 도착하면 TCP는 모든 데이터를 올바르게 재정렬하고 애플리케이션에 전달될 때까지 순서가 뒤바뀐 데이터를 버퍼링한다.
- 오버헤드 – TCP는 사용자 데이터를 전송하기 전에 소켓 연결을 설정하기 위해 세 개의 패킷이 필요하다. TCP는 신뢰성과 혼잡 제어를 처리한다.
- 스트리밍 – 데이터는 바이트 스트림으로 읽힌다. 메시지(세그먼트) 경계를 알리는 구별되는 표시는 전송되지 않는다.
사용자 데이터그램 프로토콜은 더 간단한 메시지 기반의 비연결 프로토콜이다. 비연결 프로토콜은 전용 종단 간 연결을 설정하지 않는다. 통신은 수신자의 준비 상태나 상태를 확인하지 않고 원본에서 목적지로 단방향으로 정보를 전송함으로써 이루어진다.
- 비신뢰성 – UDP 메시지가 전송될 때 목적지에 도달할지 알 수 없다. 도중에 손실될 수 있다. 확인, 재전송 또는 시간 초과의 개념이 없다.
- 순서 없음 – 두 메시지가 동일한 수신자에게 전송될 경우 도착 순서는 보장할 수 없다.
- 경량 – 메시지 순서 지정, 연결 추적 등이 없다. IP 위에 설계된 매우 간단한 전송 계층이다.
- 데이터그램 – 패킷은 개별적으로 전송되며 도착 시 무결성이 확인된다. 패킷은 명확한 경계를 가지며, 수신 시 이 경계가 존중된다. 수신자 소켓에서의 읽기 작업은 원래 전송된 것과 동일한 전체 메시지를 산출한다.
- 혼잡 제어 없음 – UDP 자체는 혼잡을 피하지 않는다. 혼잡 제어 조치는 애플리케이션 수준 또는 네트워크에서 구현되어야 한다.
- 브로드캐스트 – 비연결성이기 때문에 UDP는 브로드캐스트를 할 수 있다. 전송된 패킷은 서브넷의 모든 장치가 수신할 수 있도록 주소를 지정할 수 있다.
- 멀티캐스트 – 단일 데이터그램 패킷이 복제 없이 가입자 그룹으로 자동으로 라우팅될 수 있도록 지원되는 멀티캐스트 작동 모드이다.
Remove ads
표준
같이 보기
위키미디어 공용에 사용자 데이터그램 프로토콜 주제와 관련된 미디어 분류가 있습니다.
각주
외부 링크
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads