Deprecated:  The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
RFC 768                                                        J. Postel
                                                                     ISI
                                                          28 August 1980
                     User Datagram Protocol
                     ----------------------
導入
----
このユーザデータグラムプロトコル (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 で転送されるチェックサムは、送信者がチェックサムを 
生成しなかったことを意味する (デバッグのためか、あるいは上位レベルのプ
ロトコルが気にしないため)。
ユーザインタフェース
--------------------
ユーザインタフェースは、以下を可能にすべきである。
  新しい受信ポートの生成
  受信ポート上でデータオクテットを返却し、送信元ポートと送信元アドレス
  を通知する受信操作。
  データや送信する送信元と宛先ポートとアドレスを指定して、データグラム
  の送信を可能にする操作。
IP インタフェース
-----------------
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.