連載
|
![]() |
|
|
|
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ジャパン
- 秀丸スタートメニューで[スタート]ボタンを追加する (2013/5/24)
Windows 8では、[スタート]メニューがなく戸惑いを感じている人も多い。そこで[スタート]メニューを追加できる「秀丸スタートメニュー」を紹介する - LLMNRを使ったローカル・セグメント上での名前解決 (2013/5/23)
IPv6のアドレスは128bitもあり、そのままでは扱いづらい。FQDNによる表記からIPv6アドレスを求める名前解決について解説 - 第365話 盛るヒトビト (2013/5/21)
「盛る」。本来よりも増した自分を演出すること。増さないと生きていけないヒトビトによる、果てしない盛り合戦がいまここに - Win 7/8のインストールUSBメモリをdiskpartで作る (2013/5/20)
DVDドライブを搭載しないPCでも、インストール・イメージを格納したUSBメモリからOSのインストールが可能だ。OS標準のdiskpartコマンドによる作成手順を解説
|
|
- TwilioとRailsで作る、電話でテキスト読み上げアプリ
- Java SE 8、Java EE 7、Java Embeddedはどうなる?
- 「Scalr」を使ったAWS管理を試す
- Google I/OでモバイルアプリUXの条件を考えた
- 秀丸スタートメニューで[スタート]ボタンを追加する
- Chrome拡張機能にpush通知をしよう
- データ分析に必要な「道具」を揃える
- 複雑なデータをバインドするには?
- LLMNRを使ったローカル・セグメント上での名前解決
- 「演算子のインジェクション」と「SSJI」
- DNSを使ってネットワークデバイスにホスト名で接続
- 「ポジションが上がる=マネージャ業務」ではない
キャリアアップ
- - PR -
イベントカレンダー
- - PR -
転職/派遣情報を探す
**先週の人気講座ランキング**
〜 Android編 〜
ホワイトペーパー(TechTargetジャパン)
「ITmedia マーケティング」新着記事
スマホ vs. タブレット、ユーザーの行動特性から考えるマーケティング戦略
これまで「PC対モバイルデバイス(スマートフォン/タブレット)」という図式で語られる...
リアルワールド、34万人のクラウドソーシングによるソーシャルリスニングサービスを開始
リアルワールドは5月23日、同社が提供する国内最大級のクラウドソーシングサービス「CROW...
Googleアナリティクスでテラバイト級のビッグデータ解析機能を提供――プレミアムユーザー限定
Google BigQueryは、2010年のGoogle I/Oで発表された、大量データセットの解析を実現する...


