第13回 データグラム通信を実現するUDPプロトコル：基礎から学ぶWindowsネットワーク（3/4 ページ）

[デジタルアドバンテージ，著]

　UDPプロトコルの詳細は、RFC768（STD0006）で定義されている。以下にUDPのヘッダ部分の詳細構造を示しておく。

UDPヘッダの構造
UDPヘッダの構造は非常にシンプルである。8bytesしかない（データ部分はオプション）。「送信元」と「あて先」の2つのポート番号が主要なメンバーである。「送信元」と「あて先」のIPアドレスはIPヘッダ中から取り出すことになっている。「チェックサム」はIPヘッダなどと同様に、1の補数で計算する。

　見て分かるとおり、UDPヘッダの構造は非常にシンプルである。8bytesしかない（データ部分はオプション）。重要なのは「送信元ポート」と「あて先ポート」という、2つの16bitのポート番号フィールドである。これにより、どの（上位）アプリケーションから送られたUDPパケットであるかを識別し、正しいあて先アプリケーションにまで届けることができる。

「送信元ポート」フィールド：16bit幅

　これは、UDPパケットの送信元のアプリケーションを識別するための番号である。通常は、次の「あて先ポート」番号さえあれば、相手のアプリケーションへパケットを届けることができるが、応答を戻すために、この「送信元ポート」番号が必要になる。UDPの応答パケットの送信時には、この「送信元ポート」番号と「あて先ポート」番号を入れ換えたパケットが利用されるからである。このあたりの事情は、「第10回―１．IPパケットの構造」で解説した、IPパケット中における「送信元IPアドレス」フィールドと「あて先IPアドレス」フィールドの関係に似ている。送信されたIPパケットに対して返信をする場合、「送信元」と「あて先」のIPアドレス・フィールドを入れ換えてパケットを送信する。同様に、ポート番号フィールドも入れ換えて送信する。

　返信を要求しないUDPパケットの場合は、この「送信元ポート」フィールドの値は0になることもある。しかし一般的には、クライアント側で設定した一意の番号がセットされる（「あて先ポート」番号と同じ番号がセットされることも多い）。

「あて先ポート」フィールド：16bit幅

　このフィールドは、あて先となるアプリケーションが待ち受けしているポートの番号を表す。16bit幅なので、0〜65535まで利用できるが、以下のように、目的別に利用可能な範囲が決められている。

範囲	意味
0〜1023	Well Known Port（WKS、ウェル・ノウン・ポート）。特権ユーザーや管理者モードで動作するサービスが利用するポート。直訳して「よく知られたポート」と呼ばれることもある
1024〜49151	Registerd Port（登録済みポート）。登録されたサービスが利用するポート
49152〜65535	Dynamic Port／Private Port。動的なアプリケーションなどで利用するポート
UDP／TCPにおけるポート番号 UDP（およびTCP）では、16bit幅のポート番号が利用できるが、用途に応じて利用可能な範囲が決められている。OS標準のサービスはWKSのポートを利用し、ユーザー・アプリケーションはそれ以外のポートを利用することが望ましいとされている。

　1023番以下のポート番号は特権ポートであり、特権ユーザーや管理者モードで動作するサービスが利用するポートとされている。簡単にいうと、システムが標準的に提供するような、公共性／有用性が高いサービスが利用し、ユーザーが作成したプログラムなどでは1024以上のポート番号を利用することになっている。具体的なポート番号については後述する。

「長さ」フィールド：16bit幅

　これはUDPパケットの長さを表すフィールドである。UDPヘッダ（8bytes）と、UDPで送信するデータ部分の長さを加えたbytes数がセットされている（IPヘッダ中にも「長さ」フィールドが存在するので、そこから計算することも可能）。

　1つのUDPパケットで運ぶことのできるデータ（「ペイロード（荷物）」という）の長さは、下位層のIPパケットの長さの制約を受ける。（標準の）IPパケットでは、1回の送信で、最大では65515bytes（65535bytesから、IPヘッダの最低サイズ20bytesを引いたもの）までのデータを送信することができる（IPヘッダ・オプションが付くと、さらに小さくなる）。そのため、1つのUDPパケットで送信することのできる最大ペイロード・サイズは、65515bytesからUDPヘッダのサイズ（8bytes）を減算した、65507bytesまでとなる。このため、この「長さ」フィールドの値は、8（データが空の場合）〜65515となる。

　なお、下位層でIPフラグメンテーションが行われてIPパケットが分割されて送信されても、UDPで1度に送信することのできるサイズは影響を受けない。IPパケットのフラグメンテーション（分割）や再構成（元に戻すこと）は、IP層のレベルで行われるからである。ただしIPフラグメンテーションが禁止されていると（IPヘッダ中のDF bitがセットされていたり、ルータがフラグメント・パケットのルーティングを禁止していたりする場合）、より小さなサイズのUDPパケットしか送信できなくなる。

「チェックサム」フィールド：16bit幅

　これはUDPパケットの整合性を検査するための検査用データを表すフィールドである。計算方法は、IPヘッダ中のチェックサムと同様に、「1の補数演算」を利用して計算する。ただし、チェックサム計算の対象となるデータは、「UDP擬似ヘッダ（12bytes）」と「UDPヘッダ（8bytes）」「UDPペイロード」の3つの部分からなる。

　「UDP擬似ヘッダ（pseudo header）」とは、チェックサムの計算時だけに使われる仮想的なヘッダ・データであり、実際のUDPパケット中には含まれていない。具体的には、以下のような擬似ヘッダがUDPパケットの先頭に存在するものとして、これら全体を対象としてチェックサムが計算される。

オフセット	長さ	データ
0	4bytes	送信元IPアドレス
4	4bytes	あて先IPアドレス
8	1byte	0（ダミー・データ。未使用）
9	1byte	17（「17」は、IPヘッダ中において、UDPプロトコルを表すためのプロトコル番号）
11	2byte	パケット長（UDPヘッダも含めた長さ）
チェックサム計算のためのUDP擬似ヘッダ UDPのチェックサムを計算する場合は、先頭にこの擬似的なヘッダが存在するものとして、UDPヘッダ、UDPペイロードとともに計算する。IPアドレスの情報はIPヘッダ中から抜き出してくる。ペイロード長が奇数の場合は、最後に1byteの「0」を補って計算する（この追加する1byteのデータは、パケット長には含めない）。

　擬似ヘッダの内容を見ると分かるように、これはIPヘッダの内容を非常に簡略化したものとなっている。これにより、IPアドレスも含めたUDPパケットの整合性を検査することができる。受信したUDPパケットのチェックサムを計算して、結果がUDPヘッダ中のチェックサムと異なっていれば、エラーが生じたものとして、パケットは破棄される（破棄されても、送信元に再送を要求したりはしない）。

　なおUDPヘッダ中のチェックサム・フィールドの内容を0にして送信すると、チェックサム計算を省略するという意味になる（詳しくは述べないが、「1の補数表現」ではチェックサムの結果は必ず0以外になるので区別できる）。これは処理能力の低いコンピュータのために用意されている機能であるが、信頼性を考えると、あまり推奨されない。

代表的なUDPのポート番号

　ここでよく使われるUDPのポート番号について見ておく。UDPを使ったサービスやアプリケーションは、これらのポートを使ってクライアントからの要求を待ち受けしている。もちろんこれら以外のポート番号を使っても構わないが、標準的なUDPアプリケーションではこれらのポート番号で待ち受けするのが一般的であるし、ファイアウォールなどでもこれらのポート番号に基づいてパケット・フィルタリングなどを行っていることが多い。

　UDPで使われるポート番号の一覧は、いわゆる「servicesファイル」（Windows 2000／XPならば%windir%\system32\drivers\servicesファイル）に記述されている。このservicesファイルには、TCPプロトコルに関するサービスも含まれているが、ここではUDPプロトコルの部分のみを抜き出している。

※これはWindows XPに含まれているservicesファイルからの抜粋
※UDP部分のみを掲載している。各行の#以降はコメント

# <service name>  <port number>/<protocol>  [aliases...]
echo        7/udp
discard     9/udp   sink null
daytime     13/udp
qotd        17/udp  quote              #Quote of the day
chargen     19/udp  ttytst source      #Character generator
time        37/udp  timserver
rlp         39/udp  resource           #Resource Location Protocol
nameserver  42/udp  name               #Host Name Server
domain      53/udp                     #Domain Name Server
bootps      67/udp  dhcps              #Bootstrap Protocol Server
bootpc      68/udp  dhcpc              #Bootstrap Protocol Client
tftp        69/udp                     #Trivial File Transfer
kerberos    88/udp  krb5 kerberos-sec  #Kerberos
sunrpc      111/udp rpcbind portmap    #SUN Remote Procedure Call
ntp         123/udp                    #Network Time Protocol
epmap       135/udp loc-srv            #DCE endpoint resolution
netbios-ns  137/udp nbname             #NETBIOS Name Service
netbios-dgm 138/udp nbdatagram         #NETBIOS Datagram Service
snmp        161/udp                    #SNMP
snmptrap    162/udp snmp-trap          #SNMP trap
ipx         213/udp                    #IPX over IP
（…中略…）
radius      1812/udp                   #RADIUS authentication protocol
radacct     1813/udp                   #RADIUS accounting protocol
nfsd        2049/udp    nfs            #NFS server

　このファイルは、1行ごとに、UDPのサービス名とポート番号などが記述されている（「#」記号以降はコメント）。例えば先頭にある「echo 7/udp」とは、『「echo」というサービスはUDPのポート番号7番を利用する』という意味である。また「domain 53/udp」とは、『「domain（DNSのこと）」というサービスはUDPのポート番号53番を利用する』という意味である。

　echoやdomain、netbios-nsなどというサービス名は、人間が見てすぐに分かるように付けられたものであり、実際のプロトコル中では数値で指定しなければならない。だがネットワーク・アプリケーションでは、これらのサービス名でも、実際の数値でも、どちらでも利用できるように作られているのがほとんどである。サービス名が指定された場合は、このファイルを参照して具体的な数値のポート番号に変換している。そのため、新しくUDPを利用するサービスを開発した場合は、このファイルにプロトコルの定義を記述しておけば、サービス名でも数値でもどちらでも使用できることになる。

　なお、このservicesファイルに記述されているサービスの一覧は、そのすべてがWindows OSで提供されているというわけではないし、逆に、ここには記述されていないTCP/UDPポートを使うWindows OSのサービスも数多く存在する。このファイルは広く一般的に使われているサービスの一覧を示しているにすぎないので、パケットをキャプチャして解析するような場合には、注意していただきたい。