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などが挙げられる。
設計方針として輻輳制御を持たないため、ネットワークが輻輳する原因となるケースが問題点として存在する。
機能
UDPはInternet Protocol上で利用されるプロトコルであり[2]、IPと合わせてUDP/IPスタックとして機能する。一方でUDPはそれ単体でプロトコルであり、UDP自体で提供する明確な機能がある。以下はこの2つの観点に基づいた機能の説明である。
UDP/IPスタック
次の表はIP、UDP/IPスタック、TCP/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では送信元ポート番号だけがオプションである（後述）。
- 送信元ポート番号
- 送信元のポート番号で、相手からの応答が不要の場合はゼロ。それ以外の値の場合、必要なら相手からの応答を受け付けるポート番号を示す。送信元がクライアントの場合、エフェメラルポート番号ということが多い。送信元がサーバの場合、ウェルノウンポート番号ということが多い[4]。
- 宛先ポート番号
- 宛先のポート番号であり、必須である。送信元ポート番号と同様、宛先がクライアントならエフェメラルポート、サーバならウェルノウンポートということが多い[4]。
- データ長
- ヘッダとデータを含むデータグラム全体のバイト数を指定する。ヘッダが8バイトなので、それが最小値となる。理論上の上限は65,535バイト（ヘッダ8バイト + データ65,527バイト）である。下位層がIPv4の場合、実際の上限は65,507バイト（IPヘッダ20バイトとUDPヘッダ8バイトを差し引いた値）となる[4]。
- IPv6のジャンボグラム機能では、65,535バイトを越えるサイズのUDPパケットを扱える[13]。この場合、IPv6のオプションヘッダでサイズを指定し、最大4,294,967,295バイト（232 - 1）を指定できるので、ヘッダ部の8バイトを差し引くと最大4,294,967,287バイトのデータを扱える。
- チェックサム
- ヘッダとデータの誤り検出に使用。送信元がチェックサムを生成しない場合、このフィールドの値はゼロとする[14]。IPv6ではオプションではないので、ゼロにはできない[15]。[16]
チェックサム
チェックサムの計算法は RFC 768 で以下のように定義されている。
IPヘッダからの情報で作られる擬似ヘッダとUDPヘッダとデータを長さが2オクテットの倍数になるように（必要なら）値がゼロのオクテットでパディングし、各2オクテットの1の補数の総和の1の補数の下位16ビットをチェックサムとする[14]。
つまり、全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上でトンネリングプロトコルを利用する場合は例外的に計算を省略しゼロに設定して良い[17]。チェックサムの計算法は RFC 2460 で次のように文書化されている。
トランスポート層かそれより上位のプロトコルで、IPヘッダ内のアドレスをチェックサム計算に使う場合、IPv6では128ビットのIPv6のアドレスを使用する[15]。
チェックサム計算では、実際の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を利用するインターネットの重要なアプリケーションはいくつもある。以下はその例である。
- Domain Name System (DNS): 1つのクエリに素早く1つの応答パケットを返すだけなのでUDPを使用
- Simple Network Management Protocol (SNMP)
- Routing Information Protocol (RIP)[5]
- Dynamic Host Configuration Protocol (DHCP)
- Network Time Protocol (NTP)
- ストリーミング、ゲーミング、VoIP: パケット喪失 = 若干の品質低下、再送待ちはシステムを停止させてしまう
UDP上に信頼性保証プロトコルを載せて利用するケースも存在する。TFTPなどのアプリケーションでは、アプリケーション層で必要に応じて基本的な信頼性機構を付与している[4]。(消失訂正符号)は一つの選択肢である。
問題点
この節は(検証可能)な(参考文献や出典)が全く示されていないか、不十分です。（2023年1月） |
UDPは設計方針として輻輳制御を提供しない。これがネットワーク全体への負荷を引き起こすケースがある。
帯域の大きな部分を消費して輻輳を起こしやすいUDPアプリケーションは、インターネットの安定性を危険にさらす可能性があり、実際に帯域を大幅に占める事態が発生している。制御できないUDPトラフィックによって輻輳崩壊になる可能性を低減するためのネットワーク機構が提案されてきた。現状では、ルーターなどのネットワーク機器でのパケット・キューイングやパケット・ドロッピングが過度なUDPトラフィックをスローダウンさせる唯一の手段となっている。Datagram Congestion Control Protocol (DCCP) はこの問題を部分的に解決すべく設計されたプロトコルで、ストリーミングなどの高転送レートのUDPストリームに対してTCPのような輻輳制御を追加するものである。
POS、会計、データベースなどのTCPを使っているシステムはUDPトラフィックに圧迫されつつある。TCPでパケットを喪失すると、輻輳制御が働いて転送レートを抑えるというのも一因である。リアルタイム・アプリケーションもビジネス・アプリケーションもビジネスには重要なので、Quality of Service のソリューション開発が大切だとする者もいる[18]。
規格
脚注
- ^ 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." UDP specification ... provides a procedure for application programs to send messages to other programs ... is transaction oriented" UDP specification.
- ^ a b "This protocol assumes that the Internet Protocol ... is used as the underlying protocol." UDP specification.
- ^ a b "This protocol provides a procedure for application programs to send messages to other programs" UDP specification.
- ^ 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" UDP specification.
- ^ content@ipv6.com. “UDP Protocol Overview”. Ipv6.com. 2012年2月27日閲覧。
- ^ "UDP header contains ... the destination address ... This information gives protection against misrouted datagrams." UDP specification.
- ^ 「正常かわからないパケット」が存在せず、「壊れた/届かないパケット」と「正常なパケット」のみからなる
- ^ "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.
- ^ RFC 2675
- ^ a b Postel, J. (August 1980). RFC 768: User Datagram Protocol. Internet Engineering Task Force. Retrieved from //tools.ietf.org/html/rfc768
- ^ 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)。
- ^ 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. 2011年8月17日閲覧。
関連項目
外部リンク
- The Trouble with UDP Scanning (PDF)
- Breakdown of UDP frame
- UDP connections