第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まで利用できるが、以下のように、目的別に利用可能な範囲が決められている。

　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パケットの先頭に存在するものとして、これら全体を対象としてチェックサムが計算される。

　擬似ヘッダの内容を見ると分かるように、これは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プロトコルの部分のみを抜き出している。

　このファイルは、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のサービスも数多く存在する。このファイルは広く一般的に使われているサービスの一覧を示しているにすぎないので、パケットをキャプチャして解析するような場合には、注意していただきたい。