TCP/IP Vol.1 プロトコル 11章 UDP

(1)

TCP/IP Vol.1 プロトコル

11 章 UDP

Seibe (Arch, Murai Lab.)

村井研究会TCP/IP輪講会2015.01.22

(2)

^はじめに ^{仕様と概要}

データグラムデータグラムとヘッダフィールド断片化

IP

フラグメンテーション

経路

MTU

探索

UDP

を用いた経路

MTU

探索

UDP

と

ARP UDP

による

ARP

の氾濫まとめまとめ

おまけ

UDPv6

上位層プロトコル、派生プロトコル

(3)

はじめに UDP (User Datagram Protocol)

•

トランスポート層プロトコルの

1

種。

RFC 768

に定義されている。

•

信頼性を保証しない、シンプルでデータグラム指向なプロトコル。

検査和オプションはあるが、再送・フロー・輻輳は制御しない。

Aside

よく比較されるTCPは、ストリーム指向と言われる。

実装がシンプルなら仕様書もシンプルで、RFC 768は5,896バイトしかない。

(4)

UDP データグラム

発信元IPアドレス(32) 宛先IPアドレス (32)

0 (8) プロトコル (8) UDPデータ長 (16)

発信元ポート番号 (16) 宛先ポート番号 (16)

UDPデータ長 (16) UDP検査和 (16)

データ

パッドバイト

0 7 8 15 16 23 24 31

(5)

UDP ヘッダ Source/Destination Port ( ポート番号 )

•

発信元と宛先それぞれのポート番号が格納される

•

アプリケーションがデータの転送先を識別（デマルチプレクス）するためにある

Aside

UDPをデマルチプレクスする前にIPデータグラムがデマルチプレクスされているために、UDPのポート番号がTCPによって覗かれることはない。

(6)

UDP ヘッダ Length (UDP データ長 )

• UDP

ヘッダと

UDP

データを合わせた長さをバイト単位で示す

• 0

バイトのデータが許されるため、最小値は

8

バイトとなる

•

理論上の最大値は

65535 (2^16 - 1)

バイト

Aside

UDPデータ長は、全データ長からIPヘッダ長を引くことで算出できるため、

冗長であるといえる。

(7)

UDP ヘッダ Checksum (UDP 検査和 )

• UDP

ヘッダと

UDP

データをカバーする検査和

•

正しい宛先に到着したことをダブルチェックし、さらに

UDP

データが正しいことをチェックするために用いる

•

このフィールドはオプションである。利用しない場合は

0

で埋める

•

受け手がエラーを検出しても、エラーメッセージは生成されず、

ただ破棄される。また、そもそも受け手が計算しない場合もある。

(8)

UDP ヘッダ Checksum (UDP 検査和 )

•

利用する場合は、

UDP

ヘッダの前に

UDP

疑似ヘッダを付け加える。

データ長が奇数バイトの場合は、データグラムの末尾にパッドバイトも付け加える。

•

それ以外は、

IP

検査和と同じ計算方法である

Aside

IP検査和はIPデータ（つまりプロトコル層）をカバーしていないため、エンドツーエンドのチェックサムとしてUDP検査和が用意された

(9)

断片化 IP Fragmentation (IP 断片化 )

•

下位層におけるフレームサイズ上限

(MTU)

に対応するための措置

• IP

データグラムが経路

MTU

より大きいとき、断片化を行う

•

断片化された各データグラムは、

IP

ヘッダを持つ独立したパケットになる。パケットは、最終宛先に到達するまで再構築されない

Aside

一般にMTUが大きいほど転送効率が良い。通信品質が低い環境では、

MTUが小さいほうがエラーによる再送が減り、転送効率が改善する場合もある

(10)

断片化

^バージョ

ン (4) ヘッダ

長 (4) サービスタイプ (8) 全長 (16) 識別子 (16) ビットフ

ラグ (3) フラグメントオフセット (13)

生存時間 (8) プロトコル (8) ヘッダ検査和 (16) 発信元IPアドレス(16)

宛先IPアドレス (16) オプション

データ

0 7 8 15 16 23 24 31

(11)

断片化 Identification ( 識別子 )

•

送り手が転送する各

IP

データグラムにおいて一意の値

•

断片化される際に、全て同じ値がコピーされる

•

これを用いて、受け手は複数のフラグメントのまとまりを把握できる

(12)

断片化 Fragment Offset ( フラグメントオフセット )

•

オリジナルのデータグラムの先頭からどの程度オフセットされているかを示す

•

これにより、受け手がフラグメントの順序を把握できる

Aside

各フラグメントのデータ長フィールドは、そのフラグメントのサイズに変更される

(13)

断片化 Flag: more fragments ( MF フラグ )

•

このビットが

ON

のデータグラムは、最後のフラグメント以外のフラグメントであることを示す

•

これにより、受け手がフラグメントの終わりを把握できる

Aside

断片化は、生成されたフラグメントのデータ部分(IPヘッダ以外)が、最後のフラグメント以外は、すべて8バイトの倍数にならなければならない

(14)

断片化 Flag: don’t fragment ( DF フラグ )

•

このビットが

ON

のデータグラムは、断片化してはいけないことを示す

•

もしも、断片化が必要なデータグラムに

DF

フラグが設定されていた場合、それは破棄され、

ICMP

到達不可エラー（フラグメンテーション要求）が返される

Aside

通常のICMP到達不可エラーとの違いは、エラーに次のホップのMTUが含まれる点である。もしルーターがこのICMPエラー形式に対応していない場合は、通常のICMP到達エラーが返される

(15)

経路 MTU

探索

UDP による経路 MTU 探索

•

割愛

Aside

とくになし

(16)

UDP と ARP UDP による ARP の氾濫

• UDP

は突然送信される

(

送信前のコネクションなど無い

)

• ARP

キャッシュが空の場合、

ARP

応答より前に

UDP

が送信され、

ことごとく失敗しデータが破棄される場合がある

•

詳細は割愛

Aside

ARP応答を待つ間、宛先向けのパケットのうち最後の1つだけを保持する実装がほとんどである

(17)

まとめ UDP は役に立つ（盲信）

• IP

断片化の仕組みを知るのに、

UDP

は役立った

•

経路

MTU

探索にも、

UDP

は役立った

• ARP

実装を観測するのにも、

UDP

は役立った

• UDP

は、単純なトランスポート層プロトコルであった

•

ユーザープロセスに提供するサービスは、ポート番号と、オプショナルな検査和であった

(18)

おまけ UDP に関連するプロトコル

•

上位プロトコル

DNS

、

TFTP

、

SSDP

、

DTLS

、

DCCP-UDP

、

SOAP/UDP

•

派生プロトコル

UDP-Lite

UDPv6

• UDP

検査和が必須フィールドになった

• IPv6

アドレスが

128

ビットな分、疑似ヘッダも肥大化した

(19)

おまけ

^発信元_IPv6^アドレス₍₁₂₈₎

宛先IPv6アドレス(128) UDPデータ長 (32)

0 (24) プロトコル (8)

発信元ポート番号 (16) 宛先ポート番号 (16)

UDPデータ長 (16) UDP検査和 (16)

データ

パッドバイト

0 7 8 15 16 23 24 31

TCP/IP Vol.1 プロトコル 11章 UDP