連載
|
![]() |
|
|
|
UDPプロトコルの詳細は、RFC768(STD0006)で定義されている。以下にUDPのヘッダ部分の詳細構造を示しておく。
![]() |
| UDPヘッダの構造 |
| UDPヘッダの構造は非常にシンプルである。8bytesしかない(データ部分はオプション)。「送信元」と「あて先」の2つのポート番号が主要なメンバーである。「送信元」と「あて先」のIPアドレスはIPヘッダ中から取り出すことになっている。「チェックサム」はIPヘッダなどと同様に、1の補数で計算する。 |
見て分かるとおり、UDPヘッダの構造は非常にシンプルである。8bytesしかない(データ部分はオプション)。重要なのは「送信元ポート」と「あて先ポート」という、2つの16bitのポート番号フィールドである。これにより、どの(上位)アプリケーションから送られたUDPパケットであるかを識別し、正しいあて先アプリケーションにまで届けることができる。
「送信元ポート」フィールド:16bit幅
これは、UDPパケットの送信元のアプリケーションを識別するための番号である。通常は、次の「あて先ポート」番号さえあれば、相手のアプリケーションへパケットを届けることができるが、応答を戻すために、この「送信元ポート」番号が必要になる。UDPの応答パケットの送信時には、この「送信元ポート」番号と「あて先ポート」番号を入れ換えたパケットが利用されるからである。このあたりの事情は、「第10回―1.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ファイルからの抜粋 |
このファイルは、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のサービスも数多く存在する。このファイルは広く一般的に使われているサービスの一覧を示しているにすぎないので、パケットをキャプチャして解析するような場合には、注意していただきたい。
| INDEX | ||
| [連載]基礎から学ぶWindowsネットワーク | ||
| 第13回 データグラム通信を実現するUDPプロトコル | ||
| 1.UDPプロトコルとは | ||
| 2.UDPパケットの構造 | ||
| 3.UDPパケットの例 | ||
| 連載 |
TechTargetジャパン
- 第365話 盛るヒトビト (2013/5/21)
「盛る」。本来よりも増した自分を演出すること。増さないと生きていけないヒトビトによる、果てしない盛り合戦がいまここに - Win 7/8のインストールUSBメモリをdiskpartで作る (2013/5/20)
DVDドライブを搭載しないPCでも、インストール・イメージを格納したUSBメモリからOSのインストールが可能だ。OS標準のdiskpartコマンドによる作成手順を解説 - Server 2012でサーバの初期設定作業を行う (2013/5/17)
Windows Server 2012のサーバ・マネージャは従来とは使い勝手が異なる。従来のようにサーバの初期設定作業を行うには? - フェイルオーバー構成がサポートされたDHCPサービス (2013/5/16)
DHCPは基本サービスであり高い耐障害性が求められる。DHCPサーバを2重化するフェイルオーバー機能とは?
|
|
キャリアアップ
- - PR -
イベントカレンダー
- - PR -
転職/派遣情報を探す
**先週の人気講座ランキング**
〜 Android編 〜
ホワイトペーパー(TechTargetジャパン)
「ITmedia マーケティング」新着記事
2013年4月の検索市場――Googleは高水準を維持、MicrosoftとYahooは今一歩及ばず
米国における4月の検索件数約200億件のうち、Googleは133億件、Bingは35億件、Yahooが24...
浜松ホトニクス、オラクルのCMS「Oracle WebCenter Sites」でグローバルサイトを刷新――問い合わせ2割増、負荷5割軽減
日本オラクルは5月22日、光技術の研究/開発で世界的な評価を受けている浜松ホトニクスが...
第12回 カナダのマクドナルドが宣材写真の制作プロセスを公開。「不都合な真実」を自ら明るみにするその真意とは?
カナダのマクドナルドが2012年6月にYouTubeで公開した動画が再燃し、その再生回数が850万...


