User Datagram Protocol

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

**概要**
UDPはインターネットを始めとしたInternet Protocolネットワーク上で利用される通信プロトコルである。ホスト間通信を担うIP上でアプリケーション間通信を可能にする。通信はデータグラム方式、すなわち到達保証・流量制御・順序制御をせず、データグラムをステートレス・コネクションレスに相手側へと送信する。またブロードキャストとマルチキャストをサポートしている。
が1980年に設計し、768で定義した（STD番号: 6）。非常にシンプルに設計されており公式仕様の768はわずか3ページである。インターネット・プロトコル・スイートの観点ではトランスポート層プロトコルに属する。IPヘッダにおけるプロトコル番号は17である。OSI参照モデルに当てはめるのであればトランスポート層に相当する。しばしば対比されるプロトコルにTCPやSCTPがある。
適時性・低レイテンシが要求されるサービスで利用される。特に途中でデータが抜け落ちても問題が少ない音声や画像のストリーム形式での配信（VoIP、MPEG-TS、IP放送など）、小さなデータをリアルタイムで大量に転送するオンラインゲームなどで活用される。上位プロトコルとしてはSNMP、TFTP、DNS、DHCP、RTPなどが挙げられる。
設計方針として輻輳制御を持たないため、場合によりネットワークの輻輳を引き起こす問題がある。QUICというプロトコルに見られるように、独自に輻輳制御を実装する場合に用いることもある。

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

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

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

**仕組み**

**パケット構造**
UDPの送受信単位はユーザデータグラム（user datagram）であり、UDPヘッダ（UDP header）およびデータ（data）から構成される。ビット列として次の構造を持つ。
UDPヘッダには4つのフィールドがあり、それぞれ2バイト（16ビット）である。そのうち2つ（ピンク色の部分）はIPv4ではオプションである。IPv6では送信元ポート番号だけがオプションである（後述）。

**送信元ポート**
送信元ポート（Source Port）は送信側プロセスのポートである。
送信元ポートはUDPヘッダの任意フィールドである。不使用時はゼロ埋めされる。追加情報がなければ返信宛先ポートはこの番号と想定される。送信元がクライアントの場合、エフェメラルポート番号ということが多い。送信元がサーバの場合、ウェルノウンポート番号ということが多い。

**宛先ポート**
宛先ポート（Destination Port）は受信側プロセスのポートである。
宛先ポートはUDPヘッダの必須フィールドである。送信元ポート番号と同様、宛先がクライアントならエフェメラルポート、サーバならウェルノウンポートということが多い。

**データ長**
データ長（Length）はユーザーデータグラム（UDPヘッダ + データ）のオクテット数である。
データ長はUDPヘッダの必須フィールドである。UDPヘッダが8バイト固定であるため最小値は 8 である。理論上の上限は65,535バイト（ヘッダ8バイト + データ65,527バイト）である。下位層がIPv4の場合、実際の上限は65,507バイト（IPヘッダ20バイトとUDPヘッダ8バイトを差し引いた値）となる。IPv6のジャンボグラム機能では、65,535バイトを越えるサイズのUDPパケットを扱える。この場合、IPv6のオプションヘッダでサイズを指定し、最大4,294,967,295バイト（232 - 1）を指定できるので、ヘッダ部の8バイトを差し引くと最大4,294,967,287バイトのデータを扱える。

**チェックサム**
チェックサム（Checksum）は「IP疑似ヘッダ + ユーザーデータグラム + パディング」に対するチェックサムである。
チェックサムはUDPヘッダの条件付き任意フィールドである。不使用時はゼロ埋めされる。ヘッダとデータの誤り検出に使用。IPv6ではオプションではないので、ゼロにはできない。
チェックサムの計算法は768で以下のように定義されている。
IPヘッダからの情報で作られる擬似ヘッダとUDPヘッダとデータを長さが2オクテットの倍数になるように（必要なら）値がゼロのオクテットでパディングし、各2オクテットの1の補数の総和の1の補数の下位16ビットをチェックサムとする。
つまり、全16ビットワードを1の補数演算で足しあわせる。その合計を1の補数化すればUDPのチェックサム・フィールドの値になる。
チェックサム計算の結果がゼロになる場合（16ビット全部が0）、チェックサムを省略する場合と区別するため、その1の補数（全ビットが1）を設定する。
IPv4とIPv6ではチェックサム計算に使うデータに差異がある。

**= IPv4 擬似ヘッダ =**
IPv4上のUDPでは、実際のIPv4ヘッダからの情報から作った擬似ヘッダをチェックサム計算に使用する。擬似ヘッダは実際のIPv4ヘッダそのものではない。以下にチェックサム計算にのみ使用する擬似ヘッダを示す。
送信元IPアドレスとあて先IPアドレスはIPv4ヘッダにある値である。プロトコル番号はUDPを表すので17 (0x11) である。UDP長フィールドはUDPのヘッダとデータの全長である。
UDPチェックサム計算はIPv4ではオプションである。チェックサムを使わない場合はゼロを設定する。

**= IPv6 擬似ヘッダ =**
IPv6上のUDPでは、チェックサムは基本的に必須である。ただしUDP上でトンネリングプロトコルを利用する場合は例外的に計算を省略しゼロに設定して良い。チェックサムの計算法は 2460 で次のように文書化されている。
トランスポート層かそれより上位のプロトコルで、IPヘッダ内のアドレスをチェックサム計算に使う場合、IPv6では128ビットのIPv6のアドレスを使用する。
チェックサム計算では、実際のIPv6ヘッダを真似た次のような擬似ヘッダを用いる。
送信元IPアドレスはIPv6ヘッダにある値を使う。あて先IPアドレスは最終的なあて先であり、IPv6パケットにルーティングヘッダがなければIPv6ヘッダ内のあて先IPアドレスを使い、さもなくば送信側ではルーティングヘッダの最後の要素を、受信側ではIPv6ヘッダのあて先IPアドレスを使う。次のヘッダというフィールドはプロトコル番号を意味し、UDPなので17を指定する。UDP長フィールドはUDPのヘッダとデータを合わせた長さである。

**データ**
伝達したい情報が収納される。

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

**用途**
UDPを利用するインターネットの重要なアプリケーションはいくつもある。以下はその例である。- Domain Name System (DNS): 1つのクエリに素早く1つの応答パケットを返すだけなのでUDPを使用- Simple Network Management Protocol (SNMP)- Routing Information Protocol (RIP)- Dynamic Host Configuration Protocol (DHCP)- Network Time Protocol (NTP) - ストリーミング、ゲーミング、VoIP: パケット喪失 = 若干の品質低下、再送待ちはシステムを停止させてしまう
UDP上に信頼性保証プロトコルを載せて利用するケースも存在する。TFTPなどのアプリケーションでは、アプリケーション層で必要に応じて基本的な信頼性機構を付与している。erasure codeは一つの選択肢である。

**問題点**
UDPは設計方針として輻輳制御を提供しない。これがネットワーク全体への負荷を引き起こすケースがある。
帯域の大きな部分を消費して輻輳を起こしやすいUDPアプリケーションは、インターネットの安定性を危険にさらす可能性があり、実際に帯域を大幅に占める事態が発生している。制御できないUDPトラフィックによって輻輳崩壊になる可能性を低減するためのネットワーク機構が提案されてきた。現状では、ルーターなどのネットワーク機器でのパケット・キューイングやパケット・ドロッピングが過度なUDPトラフィックをスローダウンさせる唯一の手段となっている。Datagram Congestion Control Protocol (DCCP) はこの問題を部分的に解決すべく設計されたプロトコルで、ストリーミングなどの高転送レートのUDPストリームに対してTCPのような輻輳制御を追加するものである。
POS、会計、データベースなどのTCPを使っているシステムはUDPトラフィックに圧迫されつつある。TCPでパケットを喪失すると、輻輳制御が働いて転送レートを抑えるというのも一因である。リアルタイム・アプリケーションもビジネス・アプリケーションもビジネスには重要なので、Quality of Service のソリューション開発が大切だとする者もいる。

**規格**
768 – User Datagram Protocol- 2460 – Internet Protocol, Version 6 (IPv6) Specification- 2675 - IPv6 Jumbograms- 4113 – Management Information Base for the UDP- 4347 - Datagram Transport Layer Security- 5405 – Unicast UDP Usage Guidelines for Application Designers

**脚注**

**関連項目**
 UDP-Lite- TCPやUDPにおけるポート番号の一覧- UDPヘルパーアドレス- TCP (Transmission Control Protocol)- SCTP- Reliable User Datagram Protocol (RUDP)

**外部リンク**
  The Trouble with UDP Scanning (PDF)-  Breakdown of UDP frame-  UDP connections