UDP ユーザー･データグラムプロトコル

UDP ユーザー データグラムプロト･

コル2002/07/19

miyu

introduction

UDP （ User 　 Datagram 　 Protocol ）トランスポート層プロトコル信頼性を提供しない

送りっぱなし　あて先に到着するかの保証なしIP データグラムとして送信正式仕様　 RFC768

UDP のカプセル化

IP ヘッダ20bytes

IP データグラム

UDP データグラム

UDP ヘッダ8bytes UDP データ

ポート番号

送り手と受け手のプロセスの識別IP から受け取ったデータを、宛先ポート番号

を利用してデマルチプレクス

16 ビット発信元ポート番号16 ビット宛先ポート番号

16 ビット UDP データ長16 ビット UDP チェックサム

データ

8bytes

15 16 310

UDP データ長フィールド

UDP ヘッダと UDP データの長さをバイト単位で表記最小値 8byte

（ 0byte のデータで UDP データグラムを送ってもOK ）

( データグラムのデータ長 ) ー (IP ヘッダ長 )=UDPデータ長 16 ビット発信元ポート番号16 ビット宛先ポート番号

16 ビット UDP データ長16 ビット UDP チェックサム

データ

8bytes

UDP チェックサムUDP ヘッダとデータをカバー

IP ヘッダのチェックサムは IP ヘッダのみUDP チェックサムはオプション

でも常に有効にしておくべきバグで転送中に内容が変わるかもしれない

16 ビット発信元ポート番号16 ビット宛先ポート番号

16 ビット UDP データ長16 ビット UDP チェックサム

データ

8bytes

UDP チェックサムの計算用フィールド

32 ビット発信元 IP アドレス

データ

16 ビット発信元ポート番号16 ビット宛先ポート番号

16 ビット UDP データ長16 ビット UDP チェックサム

UDP 擬似ヘッダ

ゼロ 16 ビット UDP データ長

32 ビット宛先 IP アドレス

8 ビットプロトコル

UDP ヘッダ

パッド バイト（０）･

(12byte)

データ長が２回出てくることに注意奇数データ長の

ときに必要

UDP チェックサムの計算方法16 ビットずつに分割して加算

（ IP ヘッダのチェックサムと似ている）データ長が奇数バイトの場合

8 ビット余る計算用のパッド・バイトを足す

転送はされないUDP 擬似ヘッダ

20 バイトの IP ヘッダ宛先 IP アドレスを検証

IP ヘッダは削除されて UDP に渡されるから

tcpdump の結果• 改造版 tcpdump

– UDP のチェックサムを入手

1 0.0 sun.1900 > gemini.echo:udp 9(UDP cksum=6e90)2 0.303755 (0.30389) gemini.echo > sun.1900:udp 9(UDP cksum=0)

3 17.392480(17.0887) sun.1904 >aix.echo:udp 9(UDP cksum=6e3b)4 17.614371(0.2219) aix.echo >sun.1904:udp 9(UDP cksum=6e3b)

5 32.092454(14.4781) sun.1907 > solaris.echo:udp 9(UDP cksum=6e74)6.32.314378(0.2219) solaris.echo > sun.1907:udp 9(UDP cksum=6e74)

Checksum の同一性UDP チェックサムを

無効にしていた

16bit 値の入れ替わりは検出されていない

チェックサムによるエラー検出

負荷の高い NFS サーバを 40 日監視データリンク層やネットワーク層でもエラー検出を実施

ARP も Ethernet 上で利用されるため、全ての Ethernet フレームは IP データグラムというわけではないICMP も IP を利用するため、全ての IP データグラムが TCPorUDP というわけではない

TCP の方が UDP よりエラー確率が高いこのとき UDP トラフィックはローカルに用いられていた？TCP トラフィックは多くのルータを経由する傾向があった？

UDP 、 TCP チェックサムも完全に信頼することはできない単純…全てのエラーを検出できない

UDP データグラムの流れ

最初のデータグラムが送られるまで、コネクションをはらないいきなりトラフィックを流す確認応答もない

データを受け取ったかどうか分からない

プログラムが実行される度に発信元ポート番号が変わるエフェメラル・ポート

ポート番号 1024 ～ 5000

IP Fragmentation

Physical network 層では転送できるフレームサイズに上限インターフェース毎に MTU(Maximum Transmit Uni

t) が異なるフラグメンテーション

データグラムの大きさによる最終のあて先に到着するまで再構築されないデータグラムのフラグメントが再びフラグメント

化されることもフラグメント化とリアセンブリに必要な情報は IP ヘッダ

に記載宛先の IP 層でリアセンブリされる

（復習） IP ヘッダ

4 ビットバージョン 16 ビット全長 ( バイト )

16 ビット識別子 13 ビット・フラグメントオフセット

8 ビット・プロトコル16 ビット・ヘッダチェックサム

32 ビット発信元 IP アドレス32 ビット宛先 IP アドレス

オプション ( 任意 )

データ

8 ビット生存時間 (TTL)

ビットフラグ

8 ビット TOS4 ビットヘッダ長

20 バイト

IP データグラムに対して一意データグラムのフラグメント

の全てにコピーされる

立っている時は、最後のフラグメントでない

もっとフラグメントがある

元データグラムの先頭からどの位置なのか

フラグメントのサイズで変

更される

フラグメント化されると

別々のパケット 別々にルーティング受け手が IP ヘッダからリアセンブリ

フラグメントが欠けた場合全データグラムを破棄

中継ルータでフラグメントされた場合、再構成が困難IP レイヤーではタイムアウトも再転送もしない

TCP ならトランスポート層で TCP セグメント全体を再送

UDP は再送しない

フラグメンテーションの tcpdump

1 0.0 bsdi.1112 > svr4.discard: udp 1471

2 21.008303(21.0083) bsdi.1114 > srv4.discard: udp 1472

3 50.449704(29.4414) bsdi.1116> svr4.discard: udp1473

(frag 26304: 1480@0+)

4 50.450040(0.0003)bsdi > svr4:(frag26304:1@1480)

5 75.328650(24.8786) bsdi.1118>svr4.discard: udp 1474

(frag 26313:1480@0+)

6 75.328982(0.0003) bsdi > svr4: (frag 26313:2@1480)

フラグメンテーションの例

• ethernet フレームの最大データ量は 1500 バイト– ヘッダを引くとデータは最大 1472 バイト

IP ヘッダ20bytes

IP ヘッダ20bytes

UDP ヘッダ8bytes UDP データ (1473bytes)

IP データグラム

UDP ヘッダ8bytes UDP データ (1473bytes)

パケット　１

IP ヘッダ20bytes

1byte

パケット 2

ICMP Unreachable Error(Fragmentation Required)

フラグメントが必要なデータグラムフラグ・フィールドの「フラグメント禁止」ビット

が立っている

フラグメント化せず、データグラムを破棄ICMP エラーを返す

宛先パスまでの最小 MTU の発見に応用パス MTU ディスカバリ・メカニズム

ICMP Unreachable Error

コード (3) チェックサム

未使用 (0) ネクストホップの MTU

IP ヘッダ ( オプションを含む )+ オリジナル IP データグラムの最初の 8 バイト

8 バイトタイプ (3)

ネクストホップの MTU 記述あり (未サポート時は 0)

Traceroute でパス MTU を決定してみよう！

ほとんどのシステムはパス MTU ディスカバリメカニズムをサポートしていない

改造 traceroute を使用フラグメント化禁止ビットを立てたパケット

を送る最初は送信インターフェースの MTU で

ICMP Unreachable Error を受け取ったらパケットサイズを縮小して再送

Traceroute によるパス MTU決定

%traceroute.pmtu slip

Traceroute to slip(140.252.13.65),30 hops max

Outgoing MTU=1500

1 bsdi(140.252.13.35) 53ms 6ms 6ms

2 bsdi (140.252.13.35) 6ms

Fragmentation required DF set, next hop MTU =296

2 slip (140.252.13.65) 377ms 378ms 377ms

UDP によるパス MTU ディスカバリ

アプリケーションが中継回線にとって大きすぎるデータグラムを作成するとどうなる？

MTU の異なる複数のインターフェイスの存在する環境で検証DF ビット ( フラグメント化禁止 ) で送信開始エラーが起きるとフラグメント化する

エラー ICMP メッセージに MTU 記述があれば、それに従いフラグメントの設定をする

30秒に一度、再び DF ビットを設定して送信MTU が増加したか試す

UDP によるパス MTU ディスカバリ

slip bsdi sun netb solarisSLIP

MTU=1500MTU=1500

MTU=552 MTU=1500

MTU=1500 MTU=1500

MTU=296MTU=296

SLIP

DF ビットが設定された 650byte の UDP データグラム

ICMP Can’t fragment error

ここで tcpdump を実行

パス MTU ディスカバリ　 tcpdump

1. 0.0 solaris.38196> slip.discard:udp 650(DF)2. 0.04199(0.0042)bsdi>solaris:icmp:

slip unreachable – need to frag mtu = 296(DF)

3. 4.950193(4.9460) solaris.38196>slip.discard:udp 650(DF)4. 4.954325(0.0041) bsdi>solaris:icmp:

slip unreachable – need to frag mtu = 296(DF)

5. 9.779855(4.8255) solaris.37974>slip.discard:udp 650(frag 35278:272@0+)

6. 9.930018(0.1502)solaris>slip: (frag 35278:272@272+)7. 9.990170(0.0602) solaris>slip: (frag 35278:114@544)

Interaction Between UDP and ARP

ARPキャッシュを空にして UDP データグラムを生成最初のフラグメントが送信される前に ARP request と A

RP reply が交換されるはず

フラグメント化された全パケットが ARP requestを出すARP の実装は 1秒あたり 1 request にするべきとされて

いる応答を待つ間、最後のパケットだけが保持される

他のフラグメントは破棄される

Interaction Between UDP and ARP

最後の ARP reply から 5 分間、ICMP”time exceeded during reassembly”error

を待ち続けている… .. エラーは返されず最初のフラグメントが届いてからタイマーをス

タートTimeout したら全フラグメントを破棄

フラグメントの断片を破棄してバッファをクリアオフセット 0 のパケットが届かなかったら返さない

– トランスポート層ヘッダがないのてプロセスが識別できない

UDP データグラムサイズの最大値

理論的には 65535 バイトが IP データグラムの最大値 IP ヘッダの全長値 (16 ビット ) からUDP は 65535 – 20(IP header)– 8(UDP header) = 65507 バイト

実際はこれより最大値小さいアプリケーションの読み書きできるデータグラムサイズに依存 (8192 バイト以上 )

TCP/IP カーネルの実装上のバグ IP データグラムで 576 バイトまでは必須許容サイズより大きいときは？

→これも実装依存

ICMP Source Quench Error

• UDP トラフィックが処理できない速さの時発生

コード (0) チェックサム

未使用 (0)

IP ヘッダ ( オプションを含む )+ オリジナル IP データグラムの最初の 8 バイト

8 バイトタイプ (4)

ICMP Source Quench Error

送るのことは任意受け取るのも任意通常 UDP の場合、発信元抑制を受信しても無

視されるTCP と違ってあまり効果的でないプロセスは既に送信を完了

バッファから溢れたデータグラムは捨てられるUDP は信頼できないEnd-to-End でのフロー制御が必要

UDP サーバの設計発信元の IP アドレスと宛先ポート番号を見て処理

複数のクライアントを処理できるブロードキャストアドレス宛てのパケットは捨て

られる事もあるdestination IP address を必要とする UDP アプリケーショ

ンなど全てのクライアントからの要求を単一ポートで受

ける到着した順にアプリケーションに受け渡されるデータグラムは queing され、溢れたら破棄ICMP Source Quench Error のようなものは全く返されな

いFIFO （先入れ先出し）

UDP サーバの設計

ローカル IP アドレスの制限ワイルドカード化エンド・ポイント作成のとき、ホストのローカ

ル IP アドレスの１つをエンドポイントのローカル IP アドレスとして指定することが可能。　

外部から接続してくる IP アドレスの制限特定の IP アドレス +UDP ポートあたり 1

サーバの制限マルチキャストは例外

まとめ

UDP は単純なプロトコルIP以上はポート番号とオプショナルな

チェックサムだけ。

IP フラグメンテーションICMP 到達不可エラーUDP と ARP のやりとりICMP 発信元抑制エラー