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

UDP
ユーザー･データグラムプロトコル
2002/07/19
miyu
introduction
UDP（User Datagram Protocol）
トランスポート層プロトコル
信頼性を提供しない
送りっぱなしあて先に到着するかの保証なし
IPデータグラムとして送信
正式仕様 RFC768
UDPのカプセル化
IPデータグラム
UDPデータグラム
IPヘッダ
20bytes
UDPヘッダ
8bytes
UDPデータ
ポート番号
 送り手と受け手のプロセスの識別
 IPから受け取ったデータを、宛先ポート番号を利
用してデマルチプレクス
0
15
16ビット発信元ポート番号
16
31
16ビット宛先ポート番号
8bytes
16ビットUDPデータ長
16ビットUDPチェックサム
データ
UDPデータ長フィールド
UDPヘッダとUDPデータの長さをバイト単
位で表記
 最小値8byte
（0byteのデータでUDPデータグラムを送ってもOK）
(データグラムのデータ長)ー(IPヘッダ長)=UDPデータ長
16ビット発信元ポート番号
16ビット宛先ポート番号
8bytes
16ビットUDPデータ長
16ビットUDPチェックサム
データ
UDPチェックサム
 UDPヘッダとデータをカバー
 IPヘッダのチェックサムはIPヘッダのみ
 UDPチェックサムはオプション
 でも常に有効にしておくべき
バグで転送中に内容が変わるかもしれない
16ビット発信元ポート番号
16ビット宛先ポート番号
8bytes
16ビットUDPデータ長
16ビットUDPチェックサム
データ
UDPチェックサムの計算用フィールド
32ビット発信元IPアドレス
32ビット宛先IPアドレス
UDP擬似ヘッダ
(12byte)
ゼロ
8ビットプロトコル
16ビット発信元ポート番号
16ビットUDPデータ長
16ビット宛先ポート番号
UDPヘッダ
16ビットUDPデータ長
16ビットUDPチェックサム
データ
パッド･バイト（０）
奇数データ長の
ときに必要
データ長が２回
出てくることに注意
UDPチェックサムの計算方法
 16ビットずつに分割して加算
（IPヘッダのチェックサムと似ている）
 データ長が奇数バイトの場合
 8ビット余る
 計算用のパッド・バイトを足す
 転送はされない
 UDP擬似ヘッダ
 20バイトのIPヘッダ
 宛先IPアドレスを検証
 IPヘッダは削除されてUDPに渡されるから
tcpdumpの結果
• 改造版tcpdump
– UDPのチェックサムを入手
UDPチェックサムを
無効にしていた
Checksumの
同一性
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)
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 Unit)
が異なる
 フラグメンテーション
 データグラムの大きさによる
 最終のあて先に到着するまで再構築されない
 データグラムのフラグメントが再びフラグメント化され
ることも
 フラグメント化とリアセンブリに必要な情報はIPヘッダに記載
 宛先のIP層でリアセンブリされる
（復習）IPヘッダ
IPデータグラムに対して一意
データグラムのフラグメントの全て
にコピーされる
4ビット
バージョン
4ビット
ヘッダ長
8ビットTOS
ビット
フラグ
16ビット識別子
8ビット生存時間(TTL)
16ビット全長(バイト)
8ビット・プロトコル
元データグラムの先
頭からどの位置なのか
13ビット・フラグメントオフセット
16ビット・ヘッダチェックサム
20バイト
32ビット発信元IPアドレス
32ビット宛先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データグラム
IPヘッダ
20bytes
IPヘッダ
20bytes
UDPヘッダ
8bytes
UDPデータ(1473bytes)
UDPヘッダ
UDPデータ(1473bytes)
8bytes
パケット１
IPヘッダ
20bytes
パケット 2
1byte
ICMP Unreachable Error
(Fragmentation Required)
 フラグメントが必要なデータグラム
 フラグ・フィールドの「フラグメント禁止」ビットが立っている
フラグメント化せず、データグラムを破棄
ICMPエラーを返す
 宛先パスまでの最小MTUの発見に応用
 パスMTUディスカバリ・メカニズム
ICMP Unreachable Error
ネクストホップのMTU記述あり
(未サポート時は0)
タイプ(3)
コード(3)
チェックサム
8バイト
未使用(0)
ネクストホップのMTU
IPヘッダ(オプションを含む)
+オリジナルIPデータグラムの最初の8バイト
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ディスカバリ
ここでtcpdumpを実行
MTU=1500
SLIP
slip
MTU=296
MTU=1500 MTU=1500
MTU=1500
SLIP
bsdi
MTU=296
netb
sun
MTU=552
MTU=1500
DFビットが設定された650byteのUDPデータグラム
ICMP Can’t fragment error
solaris
パス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と
ARP 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トラフィックが処理できない速さの時発生
タイプ(4)
コード(0)
チェックサム
8バイト
未使用(0)
IPヘッダ(オプションを含む)
+オリジナルIPデータグラムの最初の8バイト
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発信元抑制エラー

Download Report