User Datagram Protocol（ユーザ データグラム プロトコル、UDP（ユーディーピー））は、主にインターネットで使用されるインターネット・プロトコル・スイートの中核プロトコルの一つ。アプリケーションから Internet Protocol (IP) ネットワーク上の他のホストへ「データグラム」と呼ばれるメッセージを送るのに使われ、事前に転送チャネルやデータ経路といった特別な設定をする必要がない。が1980年に設計し、RFC 768 で定義した（STD番号: 6）。非常にシンプルに設計されており公式仕様のRFC 768はわずか3ページである。主にIPプロトコル上に実装されておりOSI参照モデルのトランスポート層にあたる。明確なハンドシェイクを省いたコネクションレスであり、送達確認などを行わない言わば無手順方式のデータ転送で、信頼性・順序性・データ完全性を保証しない。通信中のパケット紛失や重複、データ誤りなどの検出やそのための対応が必要な場合はアプリケーションで行う。それによってトランスポート層でのそのような処理のオーバーヘッドを削減している。リアルタイム・システムでは遅れているパケットを待つよりもそういうパケットはないものとして処理する方が好ましいため、適時性を重視するアプリケーションでよく使われている。トランスポート層での誤り訂正機能が必要なら、その用途に設計された Transmission Control Protocol (TCP) または Stream Control Transmission Protocol (SCTP) を使えばよい。UDPは内部状態を持たない「ステートレス」であり、多数のクライアントからの簡単な問い合わせに応えるサーバなどの用途に有効である。TCPとは異なり、ブロードキャスト（ローカル・ネットワーク上の全ホストへの送信）とマルチキャスト（購読者全員への送信）をサポートしている。UDPを使っている主なネットワーク・アプリケーションとしては、途中でデータが抜け落ちても問題が少ない音声や画像のストリーム形式での配信（VoIP、MPEG-TS、Realストリーミング、QuickTimeストリーミング、IP放送など）、小さなデータをリアルタイムで大量に転送するオンラインゲームなどがある。その他、SNMP、TFTP、DNS、DHCPなどの各種上位プロトコルがある。IPヘッダにおけるプロトコル番号は17である。UDPアプリケーションはデータグラム・ソケットを使ってホスト間の通信を行う。アプリケーションでソケットとデータ転送のエンドポイントを結びつけるのだが、そのエンドポイントはIPアドレスとサービスポートの組み合わせで表される。ポートとはポート番号で識別されるソフトウェア構造であり、ポート番号は16ビット整数値で0から65,535まである。ポート番号0は予約されているが、送信側プロセスが応答を期待していない場合は使うことも許されている。Internet Assigned Numbers Authority (IANA) はポート番号を3つの範囲に分割した。0から1023まではウェルノウンポートであり、よく知られている一般的サービスが使用する。Unix系オペレーティングシステムでは、そのうちの一部の使用にはスーパーユーザーの権限を必要とする。1024から49,151まではレジスタードポートであり、IANAが登録したサービスが使用する。49,152から65,535まではダイナミックポートであり、公式には特定サービスに割り当てられておらず、任意の用途で使用可能である。エフェメラルポートとしても使用でき、ソフトウェアがランダムに選んで使うことができる。一般に、クライアントが何らかのサーバと通信する際に一時的ポートとして使用する。UDPは最小メッセージ指向のトランスポート層プロトコルで、仕様は IETF RFC 768 にある。上位層プロトコルへのメッセージ配送を全く保証せず、送信済みのUDPメッセージについて何の状態も保持しない。このため、UDPを "Unreliable Datagram Protocol"（信頼できないデータグラム・プロトコル）と呼ぶこともある。UDPは（ポート番号による）アプリケーション多重化と、（チェックサムによる）ヘッダおよびペイロードの完全性検証を提供する。高信頼転送が必要なら、上位アプリケーションが実装しなければならない。UDPヘッダには4つのフィールドがあり、それぞれ2バイト（16ビット）である。そのうち2つ（ピンク色の部分）はIPv4ではオプションである。IPv6では送信元ポート番号だけがオプションである（後述）。チェックサムの計算法は RFC 768 で以下のように定義されている。IPヘッダからの情報で作られる擬似ヘッダとUDPヘッダとデータを長さが2オクテットの倍数になるように（必要なら）値がゼロのオクテットでパディングし、各2オクテットの1の補数の総和の1の補数の下位16ビットをチェックサムとする。つまり、全16ビットワードを1の補数演算で足しあわせる。その合計を1の補数化すればUDPのチェックサム・フィールドの値になる。チェックサム計算の結果がゼロになる場合（16ビット全部が0）、チェックサムを省略する場合と区別するため、その1の補数（全ビットが1）を設定する。IPv4とIPv6ではチェックサム計算に使うデータに差異がある。IPv4上のUDPでは、実際のIPv4ヘッダからの情報から作った擬似ヘッダをチェックサム計算に使用する。擬似ヘッダは実際のIPv4ヘッダそのものではない。以下にチェックサム計算にのみ使用する擬似ヘッダを示す。送信元IPアドレスとあて先IPアドレスはIPv4ヘッダにある値である。プロトコル番号はUDPを表すので17 (0x11) である。UDP長フィールドはUDPのヘッダとデータの全長である。UDPチェックサム計算はIPv4ではオプションである。チェックサムを使わない場合はゼロを設定する。IPv6上のUDPでは、チェックサムは必須である。チェックサム計算法の違いは RFC 2460 で次のように文書化されている。トランスポート層かそれより上位のプロトコルで、IPヘッダ内のアドレスをチェックサム計算に使う場合、IPv6では128ビットのIPv6のアドレスを使用する。チェックサム計算では、実際のIPv6ヘッダを真似た次のような擬似ヘッダを用いる。送信元IPアドレスはIPv6ヘッダにある値を使う。あて先IPアドレスは最終的なあて先であり、IPv6パケットにルーティングヘッダがなければIPv6ヘッダ内のあて先IPアドレスを使い、さもなくば送信側ではルーティングヘッダの最後の要素を、受信側ではIPv6ヘッダのあて先IPアドレスを使う。次のヘッダというフィールドはプロトコル番号を意味し、UDPなので17を指定する。UDP長フィールドはUDPのヘッダとデータを合わせた長さである。信頼性を欠いているため、UDPアプリケーションは一般に喪失・誤り・重複を覚悟しなければならない。TFTPなどのアプリケーションでは、アプリケーション層で必要に応じて基本的な信頼性機構を付与している。多くの場合、UDPアプリケーションは信頼性機構を持たず、むしろそのオーバーヘッドを嫌っている。ストリーミング、リアルタイムのオンラインゲーム、VoIPといった用途ではUDPを使うことが多く、パケット喪失は大きな問題とはならない。高信頼性が求められる用途では、Transmission Control Protocol などのプロトコルやを代わりに使う。より深刻なのは、TCPとは異なり、UDPアプリケーションでは輻輳を回避・制御する機構を持たないことがある点である。帯域の大きな部分を消費して輻輳を起こしやすいUDPアプリケーションは、インターネットの安定性を危険にさらす可能性があり、実際に帯域を大幅に占める事態が発生している。制御できないUDPトラフィックによって輻輳崩壊になる可能性を低減するためのネットワーク機構が提案されてきた。現状では、ルーターなどのネットワーク機器でのパケット・キューイングやパケット・ドロッピングが過度なUDPトラフィックをスローダウンさせる唯一の手段となっている。Datagram Congestion Control Protocol (DCCP) はこの問題を部分的に解決すべく設計されたプロトコルで、ストリーミングなどの高転送レートのUDPストリームに対してTCPのような輻輳制御を追加するものである。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) などがある。音声や動画のトラフィックも一般にUDPを使用している。リアルタイムの動画・音声ストリーミングのプロトコルはパケット喪失が発生しても画質・音質が若干低下するだけで済むよう設計されており、喪失パケットの再送を待って止まってしまう方が不都合である。TCPとUDPは同じネットワーク上で使われており、ストリーミングなどの用途が増えているため、UDPトラフィックの割合も増えている。そのため、POS、会計、データベースなどのTCPを使っているシステムはUDPトラフィックに圧迫されつつある。TCPでパケットを喪失すると、輻輳制御が働いて転送レートを抑えるというのも一因である。リアルタイム・アプリケーションもビジネス・アプリケーションもビジネスには重要なので、Quality of Service のソリューション開発が大切だとする者もいる。TCPはコネクション指向のプロトコルであり、エンドツーエンドの通信を設定するためのハンドシェイクを必要とする。コネクションが設定されると、そのコネクション上で双方向のデータ転送が行われる。UDPはより単純なメッセージベースのコネクションレス・プロトコルである。コネクションレス・プロトコルはエンドツーエンドのコネクション確立を行わない。通信は送信側から受信側へ、特に相手の状態を確認することなく一方的に行われる。UDPがTCPに対して優れているのはリアルタイム性であり、VoIPなどの用途で重視される。

出典:wikipedia