[go: up one dir, main page]
コンテンツにスキップ

User Datagram Protocol

出典: フリー百科事典『ウィキペディア（Wikipedia）』
（UDPから転送）
曖昧さ回避 「UDP」はこの項目へ転送されています。ヌクレオチドの一種のUDPについては「ウリジン二リン酸」をご覧ください。
TCP/IP群
アプリケーション層
カテゴリ
トランスポート層
カテゴリ
インターネット層
カテゴリ
リンク層
カテゴリ

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

概要

[編集]

UDPはインターネットを始めとしたInternet Protocolネットワーク上で利用される通信プロトコルである[2]。ホスト間通信を担うIP上でアプリケーション間通信を可能にする[3]。通信はデータグラム方式、すなわち到達保証・流量制御・順序制御をせず、データグラムをステートレス・コネクションレスに相手側へと送信する。またブロードキャストとマルチキャストをサポートしている[4]。

デイヴィッド・P・リード（英語版）が1980年に設計し、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スタックとして機能する。一方で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

[編集]

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]。

データ長

[編集]

データ長（英: Length）はユーザーデータグラム（UDPヘッダ + データ）のオクテット数である[17]。

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

チェックサム

[編集]

チェックサム（英: Checksum）は「IP疑似ヘッダ + ユーザーデータグラム + パディング」に対するチェックサムである[20]。

チェックサムはUDPヘッダの条件付き任意フィールドである[21]。不使用時はゼロ埋めされる[22]。ヘッダとデータの誤り検出に使用。IPv6ではオプションではないので、ゼロにはできない[23]。[24] チェックサムの計算法はRFC 768で以下のように定義されている。

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

つまり、全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では、チェックサムは基本的に必須である。ただし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モジュール

[編集]

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]。

規格

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

脚注

[編集]
[脚注の使い方]
  1. ^ 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より引用。
  2. ^ a b "This protocol  assumes  that the Internet  Protocol ... is used as the underlying protocol."RFC 768より引用。
  3. ^ a b "This protocol provides a procedure for application programs to send messages to other programs"RFC 768より引用。
  4. ^ a b c d e Forouzan, B.A. (2000). TCP/IP: Protocol Suite, 1st ed. New Delhi, India: Tata McGraw-Hill Publishing Company Limited.
  5. ^ a b c Kurose, J. F.; Ross, K. W. (2010). Computer Networking: A Top-Down Approach (5th ed.). Boston, MA: Pearson Education. ISBN 9780131365483 
  6. ^ IP header のみトランザクション成立
  7. ^ "This protocol provides a procedure ...with a minimum of protocol mechanism"RFC 768より引用。
  8. ^ content@ipv6.com. “UDP Protocol Overview”. Ipv6.com. 2012年2月27日閲覧。
  9. ^ "UDP header contains ... the destination  address ... This information gives protection against misrouted datagrams."RFC 768より引用。
  10. ^ 「正常かわからないパケット」が存在せず、「壊れた/届かないパケット」と「正常なパケット」のみからなる
  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. ^ 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
  24. ^ 井上直也、松山公保、荒井透、苅田幸雄『マスタリング TCP/IP 入門編 第6版』オーム社、2019年、260-261頁。ISBN 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. 2011年8月17日閲覧。

関連項目

[編集]

外部リンク

[編集]
7. アプリケーション層
6. プレゼンテーション層
5. セッション層
4. トランスポート層
3. ネットワーク層
2. データリンク層
1. 物理層
カテゴリ カテゴリ
「https://ja.wikipedia.org/w/index.php?title=User_Datagram_Protocol&oldid=102630243」から取得