User Datagram Protocol

出典: フリー百科事典『ウィキペディア（Wikipedia）』
移動先: 案内、 検索

テンプレート:Redirect テンプレート:Infobox User Datagram Protocol（ユーザ データグラム プロトコル、UDP（ユーディーピー））は、主にインターネットで使用されるインターネット・プロトコル・スイートの中核プロトコルの一つ。アプリケーションから Internet Protocol (IP) ネットワーク上の他のホストへ「データグラム」と呼ばれるメッセージを送るのに使われ、事前に転送チャネルやデータ経路といった特別な設定をする必要がない。テンプレート:仮リンクが1980年に設計し、RFC 768 で定義した（STD番号: 6）。非常にシンプルに設計されており公式仕様のRFC 768はわずか3ページである。

主にIPプロトコル上に実装されておりOSI参照モデルのトランスポート層にあたる。明確なハンドシェイクを省いたコネクションレスであり、送達確認などを行わない言わば無手順方式のデータ転送で、信頼性・順序性・データ完全性を保証しない。通信中のパケット紛失や重複、データ誤り等の検出やその為の対応が必要な場合はアプリケーションで行う。それによってトランスポート層でのそのような処理のオーバーヘッドを削減している。リアルタイム・システムでは遅れているパケットを待つよりもそういうパケットはないものとして処理する方が好ましいため、適時性を重視するアプリケーションでよく使われている[1]。トランスポート層での誤り訂正機能が必要なら、その用途に設計された Transmission Control Protocol (TCP) または Stream Control Transmission Protocol (SCTP) を使えばよい。

UDPは内部状態を持たない「ステートレス」であり、多数のクライアントからの簡単な問い合わせに応えるサーバなどの用途に有効である。TCPとは異なり、ブロードキャスト（ローカル・ネットワーク上の全ホストへの送信）とマルチキャスト（購読者全員への送信）をサポートしている[2]。

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つの範囲に分割した[2]。0から1023まではウェルノウンポートであり、よく知られている一般的サービスが使用する。Unix系オペレーティングシステムでは、そのうちの一部の使用にはスーパーユーザーの権限を必要とする。1024から49,151まではレジスタードポートであり、IANAが登録したサービスが使用する。49,152から65,535まではダイナミックポートであり、公式には特定サービスに割り当てられておらず、任意の用途で使用可能である。エフェメラルポートとしても使用でき、ソフトウェアがランダムに選んで使うことができる[2]。一般に、クライアントが何らかのサーバと通信する際に一時的ポートとして使用する。

パケット構造

UDPは最小メッセージ指向のトランスポート層プロトコルで、仕様は IETF RFC 768 にある。

上位層プロトコルへのメッセージ配送を全く保証せず、送信済みのUDPメッセージについて何の状態も保持しない。このため、UDPを Unreliable Datagram Protocol（信頼できないデータグラム・プロトコル）と呼ぶこともある[3]。

UDPは（ポート番号による）アプリケーション多重化と、（チェックサムによる）ヘッダおよびペイロードの完全性検証を提供する[4]。高信頼転送が必要なら、上位アプリケーションが実装しなければならない。

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

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

送信元ポート番号
送信元のポート番号で、相手からの応答が不要の場合はゼロ。それ以外の値の場合、必要なら相手からの応答を受け付けるポート番号を示す。送信元がクライアントの場合、エフェメラルポート番号ということが多い。送信元がサーバの場合、ウェルノウンポート番号ということが多い[2]。
宛先ポート番号
宛先のポート番号であり、必須である。送信元ポート番号と同様、宛先がクライアントならエフェメラルポート、サーバならウェルノウンポートということが多い[2]。
データ長
ヘッダとデータを含むデータグラム全体のバイト数を指定する。ヘッダが8バイトなので、それが最小値となる。理論上の上限は65,535バイト（ヘッダ8バイト + データ65,527バイト）である。下位層がIPv4の場合、実際の上限は65.507バイト（IPヘッダ20バイトとUDPヘッダ8バイトを差し引いた値）となる[2]。
IPv6のジャンボグラム機能では、65.535バイトを越えるサイズのUDPパケットを扱える[5]。この場合、IPv6のオプションヘッダでサイズを指定し、最大4,294,967,295バイト（232 - 1）を指定できるので、ヘッダ部の8バイトを差し引くと最大4,294,967,287バイトのデータを扱える。
チェックサム
ヘッダとデータの誤り検出に使用。送信元がチェックサムを生成しない場合、このフィールドの値はゼロとする[6]。IPv6ではオプションではないので、ゼロにはできない[7]。

チェックサムの計算

チェックサムの計算法は RFC 768 で以下のように定義されている。

IPヘッダからの情報で作られる擬似ヘッダとUDPヘッダとデータを長さが2オクテットの倍数になるように（必要なら）値がゼロのオクテットでパディングし、各2オクテットの1の補数の総和の1の補数の下位16ビットをチェックサムとする[6]。

つまり、全16ビットワードを1の補数演算で足しあわせる。その合計を1の補数化すればUDPのチェックサム・フィールドの値になる。

チェックサム計算の結果がゼロになる場合（16ビット全部が0）、チェックサムを省略する場合と区別するため、その1の補数（全ビットが1）を設定する。

IPv4とIPv6ではチェックサム計算に使うデータに差異がある。

IPv4 擬似ヘッダ

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 擬似ヘッダ

IPv6上のUDPでは、チェックサムは必須である。チェックサム計算法の違いは RFC 2460 で次のように文書化されている。

トランスポート層かそれより上位のプロトコルで、IPヘッダ内のアドレスをチェックサム計算に使う場合、IPv6では128ビットのIPv6のアドレスを使用する[7]。

チェックサム計算では、実際の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アプリケーションは一般に喪失・誤り・重複を覚悟しなければならない。TFTPなどのアプリケーションでは、アプリケーション層で必要に応じて基本的な信頼性機構を付与している[2]。

多くの場合、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)[1]、Dynamic Host Configuration Protocol (DHCP)、Network Time Protocol (NTP) などがある。

音声や動画のトラフィックも一般にUDPを使用している。リアルタイムの動画・音声ストリーミングのプロトコルはパケット喪失が発生しても画質・音質が若干低下するだけで済むよう設計されており、喪失パケットの再送を待って止まってしまう方が不都合である。TCPとUDPは同じネットワーク上で使われており、ストリーミングなどの用途が増えているため、UDPトラフィックの割合も増えている。そのため、POS、会計、データベースなどのTCPを使っているシステムはUDPトラフィックに圧迫されつつある。TCPでパケットを喪失すると、輻輳制御が働いて転送レートを抑えるというのも一因である。リアルタイム・アプリケーションもビジネス・アプリケーションもビジネスには重要なので、Quality of Service のソリューション開発が大切だとする者もいる[8]。

UDPとTCPの比較

テンプレート:Main TCPはコネクション指向のプロトコルであり、エンドツーエンドの通信を設定するためのハンドシェイクを必要とする。コネクションが設定されると、そのコネクション上で双方向のデータ転送が行われる。

信頼性
TCPではメッセージに対する確認応答があり、再送やタイムアウトを管理している。そして、何とかしてメッセージを確実に届けようとする。パケットが喪失した場合、相手側から再送を要求する。TCPでは全くデータが失われないか、あるいは複数のタイムアウトが発生してコネクションが維持できなくなるかのどちらかである。
順序性
2つのメッセージが順番に送り出されると、受信側アプリケーションには順番どおりにメッセージが届く。セグメントがばらばらな順番で届いた場合、TCPがそれらを蓄積し、正しい順番に並べ替えてアプリケーションに渡す。
オーバーヘッド
TCPでは、ユーザーのデータを送信する前に必ず3つのパケットをやり取りしてコネクションを確立する必要がある。また、信頼性と輻輳制御のためのオーバーヘッドもある。
ストリーミング
アプリケーションから見ればデータはバイトストリームであり、個々のメッセージ（セグメント）の境界を示す印はない。

UDPはより単純なメッセージベースのコネクションレス・プロトコルである。コネクションレス・プロトコルはエンドツーエンドのコネクション確立を行わない。通信は送信側から受信側へ、特に相手の状態を確認することなく一方的に行われる。UDPがTCPに対して優れているのはリアルタイム性であり、VoIPなどの用途で重視される。

信頼性
メッセージを送ったとき、それが相手に届いたかどうかを確認できず、喪失したらそのままである。チェックサムで誤りを検出したメッセージも廃棄され、廃棄したことはどちらのアプリケーションにも通知されない。確認応答、再送、タイムアウトといった概念がない。
順序性
2つのメッセージを相手に送ったとき、どちらが先に届くかは予測できない。
オーバーヘッド
メッセージの順序を保証せず、コネクションも保持しないなど、トランスポート層プロトコルとしてはオーバーヘッドが小さい。
データグラム
パケットは個別に送信され、受信されたときだけ完全性をチェックする。メッセージ単位の送受信であり、送信元のアプリケーションが1つのメッセージとして送ったものが、そのまま相手側アプリケーションに1つのメッセージとして届く。
輻輳
UDP自身は輻輳を防げない。広帯域アプリケーションでは輻輳が発生する可能性があり、必要ならば上位層で輻輳制御を実装しなければならない。

脚注・出典

テンプレート:Reflist

関連項目

RFC

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

外部リンク

テンプレート:Navbox
  1. ↑ 1.0 1.1 1.2 テンプレート:Cite book
  2. ↑ 2.0 2.1 2.2 2.3 2.4 2.5 2.6 Forouzan, B.A. (2000). TCP/IP: Protocol Suite, 1st ed. New Delhi, India: Tata McGraw-Hill Publishing Company Limited.
  3. ↑ テンプレート:Cite web
  4. ↑ Clark, M.P. (2003). Data Networks IP and the Internet, 1st ed. West Sussex, England: John Wiley & Sons Ltd.
  5. ↑ RFC 2675
  6. ↑ 6.0 6.1 Postel, J. (August 1980). RFC 768: User Datagram Protocol. Internet Engineering Task Force. Retrieved from http://tools.ietf.org/html/rfc768
  7. ↑ 7.0 7.1 Deering S. & Hinden R. (December 1998). RFC 2460: Internet Protocol, Version 6 (IPv6) Specification. Internet Engineering Task Force. Retrieved from http://tools.ietf.org/html/rfc2460
  8. ↑ テンプレート:Cite web
「http://wikippe.e-do-match.com/index.php?title=User_Datagram_Protocol&oldid=1066」から取得