「UDP 」はこの項目へ転送 されています。ヌクレオチドの一種のUDPについては「ウリジン二リン酸 」をご覧ください。
User Datagram Protocol （ユーザ データグラム プロトコル、UDP ）はIP ネットワーク 上のアプリケーション間データグラム 送信を実現する通信プロトコル である[ 1]
UDPはインターネット を始めとしたInternet Protocol ネットワーク上で利用される通信プロトコル である[ 2] [ 3] データグラム 方式、すなわち到達保証・流量制御・順序制御をせず、データグラムをステートレス ・コネクションレス に相手側へと送信する。またブロードキャスト とマルチキャスト をサポートしている[ 4]
デイヴィッド・P・リード （英語版 ） RFC 768 で定義した（STD 番号: 6）。非常にシンプルに設計されており公式仕様のRFC 768 はわずか3ページである。インターネット・プロトコル・スイート の観点ではトランスポート層 プロトコルに属する。IPヘッダにおけるプロトコル番号 は17である。OSI参照モデル に当てはめるのであればトランスポート層 に相当する。しばしば対比されるプロトコルにTCP やSCTP がある。
適時性・低レイテンシ が要求されるサービスで利用される[ 5] ストリーム 形式での配信（VoIP 、MPEG-TS 、IP放送 など）、小さなデータをリアルタイムで大量に転送するオンラインゲーム などで活用される。上位プロトコル としてはSNMP 、TFTP 、DNS 、DHCP 、RTP などが挙げられる。
設計方針として輻輳制御 を持たないため、場合によりネットワークの輻輳 を引き起こす問題がある。QUIC というプロトコル に見られるように、独自に輻輳制御 を実装する場合に用いることもある。
UDPはInternet Protocol 上で利用されるプロトコルであり[ 2]
次の表はIP、UDP/IPスタック、TCP/IPスタックが提供する機能の比較である。
表. IP, UDP/IP, TPC/IP 比較 IP UDP/IP TCP/IP ホスト間通信 by アドレス ✔ ✔ ✔ アプリ間通信 by ポート - ✔ ✔ パケットトランザクション △[ 6] ✔ ✔ バイトストリーム送信 - - ✔ 信頼性/到達保証 - - ✔ 流量制御 - - ✔ 順序制御 - - ✔ 輻輳制御 - - ✔
すなわちUDP/IPは「ネットワークのネットワークにおけるトランザクション指向のアプリケーション間データグラム送信[ 1] [ 7] Unreliable Datagram Protocol （信頼できないデータグラム・プロトコル）と呼ぶこともある[ 8]
UDPは2つの機能のみを提供する。
ホスト内通信振り分け:ポート データグラム完全性チェック: チェックサム IPはホスト間通信を可能にするが、そのままだとホストへの全信号を1つのアプリケーションのみが受け取る。UDPはポート機能を提供することで1ホスト内複数アプリケーションへの通信振り分けを可能にする。またIPはヘッダチェックサムによる宛先誤り検出を可能にするが、そのままだとペイロードの破壊を検出できない。UDPはIPアドレス・ポート・ペイロードに基づくチェックサムを提供することで単一データグラムのルーティング誤りおよびデータ破壊を (100%ではないが) 検出できる[ 9]
すなわちUDPはアプリケーション間通信を可能にし[ 3] [ 10] [ 11] [ 12]
UDPの送受信単位はユーザデータグラム （英 :user datagram ）であり、UDPヘッダ （英 :UDP header ）およびデータ （英 :data ）から構成される。ビット列として次の構造を持つ。
オフセット（ビット） 0 – 15 16 – 31 0 送信元ポート番号 宛先ポート番号 32 データ長 チェックサム 64+
UDPヘッダには4つのフィールドがあり、それぞれ2バイト（16ビット）である[ 5]
送信元ポート （英 :Source Port ）は送信側プロセスのポートである[ 13]
送信元ポートはUDPヘッダの任意フィールドである[ 14] [ 15] [ 16] エフェメラルポート 番号ということが多い。送信元がサーバの場合、ウェルノウンポート番号ということが多い[ 4]
宛先ポート （英 :Destination Port ）は受信側プロセスのポートである。
宛先ポートはUDPヘッダの必須フィールドである。送信元ポート番号と同様、宛先がクライアントならエフェメラルポート、サーバならウェルノウンポートということが多い[ 4]
データ長 （英 :Length ）はユーザーデータグラム（UDPヘッダ + データ）のオクテット数である[ 17]
データ長はUDPヘッダの必須フィールドである。UDPヘッダが8バイト固定であるため最小値は 8 である[ 18] IPv4 の場合、実際の上限は65,507バイト（IPヘッダ20バイトとUDPヘッダ8バイトを差し引いた値）となる[ 4] IPv6 のジャンボグラム機能では、65,535バイトを越えるサイズのUDPパケットを扱える[ 19] 32 - 1）を指定できるので、ヘッダ部の8バイトを差し引くと最大4,294,967,287バイトのデータを扱える。
チェックサム （英 :Checksum ）は「IP疑似ヘッダ + ユーザーデータグラム + パディング」に対するチェックサム である[ 20]
チェックサムはUDPヘッダの条件付き任意フィールドである[ 21] [ 22] [ 23] [ 24] RFC 768 で以下のように定義されている。
IPヘッダからの情報で作られる擬似ヘッダとUDPヘッダとデータを長さが2オクテットの倍数になるように（必要なら）値がゼロのオクテットでパディングし、各2オクテットの1の補数の総和の1の補数の下位16ビットをチェックサムとする[ 25]
つまり、全16ビットワードを1の補数 演算で足しあわせる。その合計を1の補数化すればUDPのチェックサム・フィールドの値になる。
チェックサム計算の結果がゼロになる場合（16ビット全部が0）、チェックサムを省略する場合と区別するため、その1の補数（全ビットが1）を設定する。
IPv4 とIPv6 ではチェックサム計算に使うデータに差異がある。
IPv4上のUDPでは、実際のIPv4ヘッダからの情報から作った擬似ヘッダをチェックサム計算に使用する。擬似ヘッダは実際のIPv4ヘッダそのものではない。以下にチェックサム計算にのみ使用する擬似ヘッダを示す。
bits 0 – 7 8 – 15 16 – 23 24 – 31 0 送信元IPアドレス 32 あて先IPアドレス 64 ゼロ プロトコル番号 UDP長 96 送信元ポート番号 宛先ポート番号 128 データ長 チェックサム 160+
送信元IPアドレスとあて先IPアドレスはIPv4ヘッダにある値である。プロトコル番号 はUDPを表すので17 (0x11) である。UDP長フィールドはUDPのヘッダとデータの全長である。
UDPチェックサム計算はIPv4ではオプションである。チェックサムを使わない場合はゼロを設定する。
IPv6上のUDPでは、チェックサムは基本的に必須である。ただしUDP上でトンネリングプロトコルを利用する場合は例外的に計算を省略しゼロに設定して良い[ 26] RFC 2460 で次のように文書化されている。
トランスポート層かそれより上位のプロトコルで、IPヘッダ内のアドレスをチェックサム計算に使う場合、IPv6では128ビットのIPv6のアドレスを使用する[ 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+
送信元IPアドレスはIPv6ヘッダにある値を使う。あて先IPアドレスは最終的なあて先であり、IPv6パケットにルーティングヘッダがなければIPv6ヘッダ内のあて先IPアドレスを使い、さもなくば送信側ではルーティングヘッダの最後の要素を、受信側ではIPv6ヘッダのあて先IPアドレスを使う。次のヘッダというフィールドはプロトコル番号 を意味し、UDPなので17を指定する。UDP長フィールドはUDPのヘッダとデータを合わせた長さである。
伝達したい情報が収納される。
UDPモジュールはソケット を介してプログラムからアクセスする場合が多い。ポート番号0は送信側プロセスが応答を期待していない場合は使うことも許されている。
UDPを利用するインターネットの重要なアプリケーションはいくつもある。以下はその例である。
UDP上に信頼性保証プロトコルを載せて利用するケースも存在する。TFTP などのアプリケーションでは、アプリケーション層で必要に応じて基本的な信頼性機構を付与している[ 4] 消失訂正符号 （英語版 ）
UDPは設計方針として輻輳 制御を提供しない。これがネットワーク全体への負荷を引き起こすケースがある。
帯域の大きな部分を消費して輻輳を起こしやすいUDPアプリケーションは、インターネットの安定性を危険にさらす可能性があり、実際に帯域を大幅に占める事態が発生している。制御できないUDPトラフィックによって輻輳崩壊になる可能性を低減するためのネットワーク機構が提案されてきた。現状では、ルーター などのネットワーク機器でのパケット・キューイングやパケット・ドロッピングが過度なUDPトラフィックをスローダウンさせる唯一の手段となっている。Datagram Congestion Control Protocol (DCCP) はこの問題を部分的に解決すべく設計されたプロトコルで、ストリーミングなどの高転送レートのUDPストリームに対してTCPのような輻輳制御を追加するものである。
POS 、会計 、データベース などのTCPを使っているシステムはUDPトラフィックに圧迫されつつある。TCPでパケットを喪失すると、輻輳制御が働いて転送レートを抑えるというのも一因である。リアルタイム・アプリケーションもビジネス・アプリケーションもビジネスには重要なので、Quality of Service のソリューション開発が大切だとする者もいる[ 27]
^a b "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 より引用。 ^a b "This protocol assumes that the Internet Protocol ... is used as the underlying protocol."RFC 768 より引用。 ^a b "This protocol provides a procedure for application programs to send messages to other programs"RFC 768 より引用。 ^a b c d e Forouzan, B.A. (2000).TCP/IP: Protocol Suite, 1st ed . New Delhi, India: Tata McGraw-Hill Publishing Company Limited. ^a b c Kurose, 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. 2008年9月18日時点のオリジナル よりアーカイブ。2012年2月27日閲覧。 ^ "UDP header contains ... the destination address ... This information gives protection against misrouted datagrams."RFC 768 より引用。 ^ 「正常かわからないパケット」が存在せず、「壊れた/届かないパケット」と「正常なパケット」のみからなる ^ "The protocol is transaction oriented" UDP specification. ^ Clark, M.P. (2003).Data Networks IP and the Internet, 1st ed . West Sussex, England: John Wiley & Sons Ltd. ^ "Source Port ... indicates the port of the sending proces"RFC 768 より引用。 ^ "Source Port is an optional field"RFC 768 より引用。 ^ "If not used, a value of zero is inserted."RFC 768 より引用。 ^ "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 より引用。 ^ "Length is the length in octets of this user datagram"RFC 768 より引用。 ^ "the minimum value of the length is eight."RFC 768 より引用。 ^ RFC 2675 ^ "Checksum is of a pseudo header of information from the IP header, the UDP header, and the data, padded"RFC 768 より引用。 ^ "no checksum (for debugging or for higher level protocols that don't care)"RFC 768 より引用。 ^ "An all zero transmitted checksum value means that the transmitter generated no checksum"RFC 768 より引用。 ^a b Deering S. & Hinden R. (December 1998).RFC 2460 : Internet Protocol, Version 6 (IPv6) Specification.Internet Engineering Task Force . Retrieved from //tools.ietf.org/html/rfc2460 ^ 井上直也、松山公保、荒井透、苅田幸雄『マスタリング TCP/IP 入門編 第6版』オーム社、2019年、260-261頁。ISBN 978-4-274-22447-8 。 ^ Postel, J. (August 1980).RFC 768 : User Datagram Protocol.Internet Engineering Task Force . Retrieved from //tools.ietf.org/html/rfc768 ^ Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets",RFC 6935 , April 2013. ^ “The impact of voice/video on data applications ”. Networkperformancedaily.com. 2013年4月27日時点のオリジナル よりアーカイブ。2011年8月17日閲覧。 
