User Datagram Protocol(ユーザ データグラム プロトコル、UDP)はIPネットワーク上のアプリケーション間データグラム送信を実現する通信プロトコルである[1]

概要

編集

UDPInternet Protocol[2]IP[3][4]

P1980RFC 768 STD: 6RFC 7683IP17OSITCPSCTP

[5]VoIPMPEG-TSIPSNMPTFTPDNSDHCPRTP


機能

編集

UDPはInternet Protocol上で利用されるプロトコルであり[2]、IPと合わせてUDP/IPスタックとして機能する。一方でUDPはそれ単体でプロトコルであり、UDP自体で提供する明確な機能がある。以下はこの2つの観点に基づいた機能の説明である。

UDP/IPスタック

編集

次の表はIP、UDP/IPスタック、TCP/IPスタックが提供する機能の比較である。

表. IP, UDP/IP, TPC/IP 比較
IP UDP/IP TCP/IP
ホスト間通信 by アドレス
アプリ間通信 by ポート -
パケットトランザクション [6]
バイトストリーム送信 - -
信頼性/到達保証 - -
流量制御 - -
順序制御 - -
輻輳制御 - -

すなわちUDP/IPは「ネットワークのネットワークにおけるトランザクション指向のアプリケーション間データグラム送信[1]」を実現する。UDPはこれを最小限のプロトコルで実現するよう意図されているため[7]、UDP/IPはTCP/IPより少ない機能のみを提供する。単一パケットの到達保証や複数パケットに渡る流量制御・順序制御はサポートしていない(データグラムモデル)。このため、UDPを Unreliable Datagram Protocol(信頼できないデータグラム・プロトコル)と呼ぶこともある[8]

UDPは2つの機能のみを提供する。  

  • ホスト内通信振り分け: ポート
  • データグラム完全性チェック: チェックサム

IPはホスト間通信を可能にするが、そのままだとホストへの全信号を1つのアプリケーションのみが受け取る。UDPはポート機能を提供することで1ホスト内複数アプリケーションへの通信振り分けを可能にする。またIPはヘッダチェックサムによる宛先誤り検出を可能にするが、そのままだとペイロードの破壊を検出できない。UDPはIPアドレス・ポート・ペイロードに基づくチェックサムを提供することで単一データグラムのルーティング誤りおよびデータ破壊を (100%ではないが) 検出できる[9]

すなわちUDPはアプリケーション間通信を可能にし[3]、パケットトランザクション(all-or-nothing通信[10])を提供する[11][12]

仕組み

編集

パケット構造

編集

UDPの送受信単位はユーザデータグラム: user datagram)であり、UDPヘッダ: UDP header)およびデータ: data)から構成される。ビット列として次の構造を持つ。

オフセット(ビット) 0 – 15 16 – 31
0 送信元ポート番号 宛先ポート番号
32 データ長 チェックサム
64+  
データ
 

UDPヘッダには4つのフィールドがあり、それぞれ2バイト(16ビット)である[5]。そのうち2つ(ピンク色の部分)はIPv4ではオプションである。IPv6では送信元ポート番号だけがオプションである(後述)。

送信元ポート

編集

: Source Port[13]

UDP[14]使[15][16][4]

宛先ポート

編集

宛先ポート: Destination Port)は受信側プロセスのポートである。

宛先ポートはUDPヘッダの必須フィールドである。送信元ポート番号と同様、宛先がクライアントならエフェメラルポート、サーバならウェルノウンポートということが多い[4]

データ長

編集

: LengthUDP + [17]

UDPUDP88[18]65,5358 + 65,527IPv465,507IP20UDP8[4]IPv665,535UDP[19]IPv64,294,967,295232 - 184,294,967,287

チェックサム

編集

: ChecksumIP +  + [20]

UDP[21]使[22]使IPv6[23][24]  RFC 768 


IPUDP221116[25]


1611UDP

16011

IPv4IPv6使
IPv4 擬似ヘッダ
編集

IPv4UDPIPv4使IPv4使
bits 0 – 7 8 – 15 16 – 23 24 – 31
0 送信元IPアドレス
32 あて先IPアドレス
64 ゼロ プロトコル番号 UDP長
96 送信元ポート番号 宛先ポート番号
128 データ長 チェックサム
160+  
データ
 

IPIPIPv4UDP17 (0x11) UDPUDP

UDPIPv4使
IPv6 擬似ヘッダ
編集

IPv6UDPUDP[26] RFC 2460 


IP使IPv6128IPv6使[23]


IPv6
bits 0 – 7 8 – 15 16 – 23 24 – 31
0 送信元IPアドレス
32
64
96
128 あて先IPアドレス
160
192
224
256 UDP長
288 ゼロ 次のヘッダ
320 送信元ポート番号 宛先ポート番号
352 データ長 チェックサム
384+  
データ
 

IPIPv6使IPIPv6IPv6IP使IPv6IP使UDP17UDPUDP

データ

編集

伝達したい情報が収納される。

UDPモジュール

編集

UDPモジュールはソケットを介してプログラムからアクセスする場合が多い。ポート番号0は送信側プロセスが応答を期待していない場合は使うことも許されている。

用途

編集

UDP

Domain Name System (DNS): 11UDP使

Simple Network Management Protocol (SNMP)

Routing Information Protocol (RIP)[5]

Dynamic Host Configuration Protocol (DHCP)

Network Time Protocol (NTP)

VoIP:  = 

UDPTFTP[4]

問題点

編集

UDPは設計方針として輻輳制御を提供しない。これがネットワーク全体への負荷を引き起こすケースがある。

帯域の大きな部分を消費して輻輳を起こしやすいUDPアプリケーションは、インターネットの安定性を危険にさらす可能性があり、実際に帯域を大幅に占める事態が発生している。制御できないUDPトラフィックによって輻輳崩壊になる可能性を低減するためのネットワーク機構が提案されてきた。現状では、ルーターなどのネットワーク機器でのパケット・キューイングやパケット・ドロッピングが過度なUDPトラフィックをスローダウンさせる唯一の手段となっている。Datagram Congestion Control Protocol (DCCP) はこの問題を部分的に解決すべく設計されたプロトコルで、ストリーミングなどの高転送レートのUDPストリームに対してTCPのような輻輳制御を追加するものである。

POS会計データベースなどのTCPを使っているシステムはUDPトラフィックに圧迫されつつある。TCPでパケットを喪失すると、輻輳制御が働いて転送レートを抑えるというのも一因である。リアルタイム・アプリケーションもビジネス・アプリケーションもビジネスには重要なので、Quality of Service のソリューション開発が大切だとする者もいる[27]

規格

編集
表. UDP 規格
規格書名 規格種別 発行日
RFC 768 User Datagram Protocol RFC Internet Standard 1980-08-28

脚注

編集


(一)^ ab"User Datagram Protocol ... make available  a datagram mode of packet-switched computer communication in the environment of an interconnected set of computer networks. ... provides a procedure for application programs to send messages to other programs ... is transaction oriented" RFC 768 

(二)^ ab"This protocol  assumes  that the Internet  Protocol ... is used as the underlying protocol." RFC 768 

(三)^ ab"This protocol provides a procedure for application programs to send messages to other programs" RFC 768 

(四)^ abcdeForouzan, B.A. (2000). TCP/IP: Protocol Suite, 1st ed. New Delhi, India: Tata McGraw-Hill Publishing Company Limited.

(五)^ abcKurose, J. F.; Ross, K. W. (2010). Computer Networking: A Top-Down Approach (5th ed.). Boston, MA: Pearson Education. ISBN 9780131365483 

(六)^ IP header 

(七)^ "This protocol provides a procedure ...with a minimum of protocol mechanism" RFC 768 

(八)^ content@ipv6.com. UDP Protocol Overview. Ipv6.com. 2012227

(九)^ "UDP header contains ... the destination  address ... This information gives protection against misrouted datagrams." RFC 768 

(十)^ /

(11)^ "The protocol is transaction oriented" UDP specification.

(12)^ Clark, M.P. (2003). Data Networks IP and the Internet, 1st ed. West Sussex, England: John Wiley & Sons Ltd.

(13)^ "Source Port ... indicates the port of the sending proces" RFC 768 

(14)^ "Source Port is an optional field" RFC 768 

(15)^ "If not used, a value of zero is inserted." RFC 768 

(16)^ "Source Port ... may be assumed to be the port to which a reply should be addressed in the absence of any other information." RFC 768 

(17)^ "Length is the length in octets of this user datagram" RFC 768 

(18)^ "the minimum value of the length is eight." RFC 768 

(19)^ RFC 2675

(20)^ "Checksum is of a pseudo header of information from the IP header, the UDP header, and the data, padded" RFC 768 

(21)^ "no checksum  (for debugging or for higher level protocols that don't care)" RFC 768 

(22)^ "An all zero transmitted checksum value means that the transmitter generated no checksum" RFC 768 

(23)^ abDeering S. & Hinden R. (December 1998). RFC 2460: Internet Protocol, Version 6 (IPv6) Specification. Internet Engineering Task Force. Retrieved from //tools.ietf.org/html/rfc2460

(24)^  TCP/IP  62019260-261ISBN 978-4-274-22447-8 

(25)^ Postel, J. (August 1980). RFC 768: User Datagram Protocol. Internet Engineering Task Force. Retrieved from //tools.ietf.org/html/rfc768

(26)^ Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, April 2013.

(27)^ The impact of voice/video on data applications. Networkperformancedaily.com. 2011817

関連項目

編集

外部リンク

編集