RFC 768 |
J. Postel ISI 28 August 1980 |
このユーザデータグラムプロトコル (UDP: User Datagram Protocol) は、一組のコンピュータネットワークが相互接続された環境で、パケット交換コンピュータ通信のデータグラムモードを利用可能にするために定義される。このプロトコルは、下位プロトコルとしてインターネットプロトコル (IP: Internet Protocol)[1] が使用されることを想定している。
このプロトコルは、最小限のプロトコルメカニズムで、メッセージを他のプログラムに送信するためのアプリケーションプログラムの手続きを提供する。このプロトコルはトランザクション指向で、配送や重複を防ぐことは保証されない。信頼できる順序でのデータストリームの配送を必要とするアプリケーションは、転送制御プロトコル (TCP: Transmission Control Protocol)[2] を使用すべきである。
0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | Source | Destination | | Port | Port | +--------+--------+--------+--------+ | | | | Length | Checksum | +--------+--------+--------+--------+ | | data octets ... +---------------- ... ユーザデータグラムヘッダ形式
Source Port は任意のフィールドであり、意味を持つ場合は送信側プロセスのポートを示す。これは他の情報が存在しない場合に、応答の宛先にすべきポートであると仮定してもよい。もし使用しないならば、0 の値が挿入される。
Destination Port は、ある特定のインターネット宛先アドレスのコンテキストの範囲で意味を持つ。
Length は、このヘッダとデータを示している、このユーザデータグラムのオクテット長である。(これは、Length の最小値が 8 であることを意味する)。
Checksum は、IP ヘッダや UDP ヘッダ、データからの情報の擬似ヘッダの 1 の補数の和の 16 ビットの 1 の補数である。擬似ヘッダは、(もし必要ならば) 2 オクテットの倍数とするために最後に 0 のオクテットでパディングされる。
擬似ヘッダは、概念的に UDP ヘッダの前に付けられ、送信元アドレス、宛先アドレス、プロトコル、UDP 長を含む。この情報を用いて、誤った経路で送られたデータグラムを遮断する。このチェックサムの手続きは、TCP で使用されているものと同じである。
0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | source address | +--------+--------+--------+--------+ | destination address | +--------+--------+--------+--------+ | zero |protocol| UDP length | +--------+--------+--------+--------+
もし算出したチェックサムが 0 ならば、全て 1 (1 の補数演算と同等) として転送される。全て 0 で転送されるチェックサムは、送信者がチェックサムを生成しなかったことを意味する (デバッグのためか、あるいは上位レベルのプロトコルが気にしないため)。
ユーザインタフェースは、以下を可能にすべきである。
UDP モジュールは、インターネットヘッダから送信元と宛先のインターネットアドレスと、プロトコルフィールドを決定できなければならない。一つのあり得る UDP/IP インターフェースは、受信操作に応じて、インターネットヘッダの全てを含んでいるインターネットデータグラム全体を返却するだろう。そのようなインタフェースは、送信するヘッダ付きの完全なインターネットデータグラム全体を、UDP が IP に渡すことも可能にするだろう。IP はあるフィールドの一貫性を確認し、インターネットヘッダのチェックサムを算出するだろう。
このプロトコルが主に使われているのは、インターネットネームサーバ [3] と簡易ファイル転送 [4] である。
インターネットプロトコルで使用される場合、プロトコル番号は 17 (8 進数で 21) である。他のプロトコル番号は、[5] で一覧化されている。
[1] Postel, J., "Internet Protocol,"RFC 760, USC/Information Sciences Institute, January 1980.
[2] Postel, J., "Transmission Control Protocol,"RFC 761, USC/Information Sciences Institute, January 1980.
[3] Postel, J., "Internet Name Server,"USC/Information Sciences Institute, IEN 116, August 1979.
[4] Sollins, K., "The TFTP Protocol,"Massachusetts Institute of Technology, IEN 133, January 1980.
[5] Postel, J., "Assigned Numbers,"USC/Information Sciences Institute, RFC 762, January 1980.