メインコンテンツまでスキップ

RFC 768 - ユーザデータグラムプロトコル (User Datagram Protocol)

公開日: 1980年8月28日
著者: J. Postel (ISI - 情報科学研究所)
ステータス: 標準プロトコル (Standard Protocol)

はじめに (Introduction)​

このユーザデータグラムプロトコル (User Datagram Protocol, UDP) は、相互接続されたコンピュータネットワークの環境において、パケット交換コンピュータ通信のデータグラムモード (Datagram Mode) を利用可能にするために定義されています。このプロトコルは、インターネットプロトコル (Internet Protocol, IP) [1] が基盤プロトコルとして使用されることを前提としています。

このプロトコルは、アプリケーションプログラムが最小限のプロトコル機構で他のプログラムにメッセージを送信するための手順を提供します。このプロトコルはトランザクション指向 (Transaction Oriented) であり、配信および重複保護は保証されません。順序付けられた信頼性のあるデータストリーム配信を必要とするアプリケーションは、伝送制御プロトコル (Transmission Control Protocol, TCP) [2] を使用すべきです。

フォーマット (Format)​

                  0      7 8     15 16    23 24    31  
                 +--------+--------+--------+--------+ 
                 |     Source      |   Destination   | 
                 |      Port       |      Port       | 
                 +--------+--------+--------+--------+ 
                 |                 |                 | 
                 |     Length      |    Checksum     | 
                 +--------+--------+--------+--------+ 
                 |                                     
                 |          data octets ...            
                 +---------------- ...                 

                      User Datagram Header Format

フィールド (Fields)​

Source Port (送信元ポート)​

送信元ポート (Source Port) はオプションフィールドであり、意味がある場合は送信プロセスのポートを示し、他の情報がない場合は応答を送信すべきポートであると仮定できます。使用されない場合は、値ゼロが挿入されます。

Destination Port (宛先ポート)​

宛先ポート (Destination Port) は、特定のインターネット宛先アドレスのコンテキスト内で意味を持ちます。

Length (長さ)​

長さ (Length) は、このヘッダとデータを含むこのユーザデータグラムのオクテット単位の長さです。(これは、長さの最小値が8であることを意味します。)

Checksum (チェックサム)​

チェックサム (Checksum) は、IPヘッダ、UDPヘッダ、およびデータからの情報の疑似ヘッダ (Pseudo Header) の1の補数和 (One's Complement Sum) の16ビット1の補数であり、必要に応じて末尾にゼロオクテットを埋め込んで2オクテットの倍数にします。

疑似ヘッダは概念的にUDPヘッダの前に付加され、送信元アドレス、宛先アドレス、プロトコル、およびUDP長を含みます。この情報は、誤ってルーティングされたデータグラムに対する保護を提供します。このチェックサム手順は、TCPで使用されているものと同じです。

                  0      7 8     15 16    23 24    31 
                 +--------+--------+--------+--------+
                 |          source address           |
                 +--------+--------+--------+--------+
                 |        destination address        |
                 +--------+--------+--------+--------+
                 |  zero  |protocol|   UDP length    |
                 +--------+--------+--------+--------+

計算されたチェックサムがゼロの場合、すべて1として送信されます (1の補数演算では等価です)。送信されたチェックサム値がすべてゼロである場合、送信者がチェックサムを生成しなかったことを意味します (デバッグ用、または気にしない上位レベルプロトコル用)。

ユーザインターフェース (User Interface)​

ユーザインターフェースは以下を可能にすべきです:

  • 新しい受信ポート (Receive Ports) の作成,

  • 受信ポートでの受信操作。データオクテットと送信元ポートおよび送信元アドレスの指示を返します,

  • およびデータグラムの送信を可能にする操作。送信するデータ、送信元ポートと宛先ポートおよびアドレスを指定します。

IPインターフェース (IP Interface)​

UDPモジュールは、インターネットヘッダから送信元および宛先インターネットアドレスとプロトコルフィールドを決定できる必要があります (MUST)。可能なUDP/IPインターフェースの1つは、受信操作への応答として、すべてのインターネットヘッダを含む完全なインターネットデータグラムを返すものです。そのようなインターフェースは、UDPが完全なインターネットデータグラム (ヘッダを含む) をIPに渡して送信することも可能にします。IPは、一貫性のために特定のフィールドを検証し、インターネットヘッダチェックサムを計算します。

プロトコルアプリケーション (Protocol Application)​

このプロトコルの主な用途は、インターネットネームサーバ (Internet Name Server) [3] および簡易ファイル転送 (Trivial File Transfer) [4] です。

プロトコル番号 (Protocol Number)​

インターネットプロトコルで使用される場合、これはプロトコル17 (8進数で21) です。他のプロトコル番号は [5] にリストされています。

参考文献 (References)​

[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.

関連リソース​

  • 公式テキスト: https://www.rfc-editor.org/rfc/rfc768.txt
  • 公式ページ: https://datatracker.ietf.org/doc/html/rfc768
に最終更新