UDP:ユーザー・データグラム・プロトコルon1
View Slide
目次• 11.1 イントロダクション• 11.2 UDPヘッダ• 11.3 UDPチェックサム• 11.4 単純な例• 11.5 IPフラグメンンテーション• 11.6 ICMP到達不可エラー(フラブメンテーション要求)• 11.7 Tracerouteを用いてパスMTUを決定する• 11.8 UDPによるパスMTUディスカバリ• 11.9 UDPとARPの間のやり取り• 11.10 UDPデータグラム・サイズの最大値• 11.11 ICMP発信元抑制エラー• 11.12 UDPサーバーの設計• 11.13 まとめ2
11.1 イントロダクション• UDP• データグラム指向(↔ストリーム指向)• トランスポート層プロトコル3
11.2 UDPヘッダ4• ポート番号:送り手、受け手のプロセスを示す• デマルチプレクス後参照されるため、ポート番号はTCPとUDPで独立• UDPデータ長:UDPヘッダ+UDPデータの長さ• 最小値は8バイト(データがないこともある)• IPヘッダに全体のデータ長、IPヘッダ長が記載済み→全体のデータ長ーIPヘッダ長=UDPデータグラムのデータ長
11.3 UDPチェックサム• 対象:UDPヘッダとUDPデータ• チェックサムはUDPではオプション、TCPでは必須• 計算:基本16ビット・ワードの1の補数計算• 相違点①UDPデータグラムが奇数バイトのとき最後に0をくっつける(パット・バイト)②12バイトの擬似ヘッダを使用5
11.3 UDPチェックサム• 擬似ヘッダ• IPヘッダを簡略化• 正しい宛先に到着したことを再確認• エラー検出• 破棄• エラー・メッセージなし• チェックサムをオフにもできる• 推奨されない6
11.3 UDPチェックサム• Tcpdump出力• UDPチェックサムを有効にしているか見たい• 受信UDPチェックサムを出力させた(0のときオフ)• Sockプログラム7
11.3 UDPチェックサム• いくつかの統計情報• 40日間のFNSのエラー件数を記録8
11.4 単純な例• TcpdumpでUDPデータグラムを見る(sockプログラム)• 宛先svr4• TCPにかえてUDPを指定(-u)• 2つ目はデータ長0(-w0)9
11.4 単純な例10• 結果
11.5 IPフラグメンテーション• MTUとデータグラムのサイズを比較→必要なら断片化• IPヘッダ• フラグ• フラグ・フィールドの一部がオン→「自分は最後のフラグメントではない」ことを示す• フラグメント・オフセット• 自分がオリジナルのデータグラムのどの位置にあたるか示す• 全データ長• フラグメントされると変更される• フラグ・フィールドの1つのビットがオン• フラグメント化してはいけない→ICMPエラーを送り返す11
11.5 IPフラグメンテーション• フラグメントが1つでも失われたら、全体を再送• 途中のルーターでフラグメンテーションが行われたとき、発信元はどのようにフラグメント化されたかを知ることができない12
11.5 IPフラグメンテーション• Tcpdumpでフラグメント化を見てみる13
11.5 IPフラグメンテーション• 結果14
11.5 IPフラグメンテーション15• フラグメント化
11.6 ICMP到達不可エラー(フラグメンテーション要求)• フラグメンテーション必要 しかし 「フラグメント化してはいけない(DF)」フラグがオン のときに発生16
11.6 ICMP到達不可エラー(フラグメンテーション要求)• 例17
11.6 ICMP到達不可エラー(フラグメンテーション要求)18• 結果
11.6 ICMP到達不可エラー(フラグメンテーション要求)19
11.7 tracerouteを用いてパスMTUを決定する• DFビットをオン→送信インターフェースのMTUに合わせてパケット送信→ICMPエラーが返ってくるとパケットサイズを縮小してパケット送信20
11.7 tracerouteを用いてパスMTUを決定する• BsdiのICMPコードを修正送信インターフェースのMTUを返すようにする21
11.8 UDPによるパスMTUディスカバリ• UDPを利用するアプリケーションとパスMTUディスカバリの関係22
11.8 UDPによるパスMTUディスカバリ23
11.8 UDPによるパスMTUディスカバリ• Solarisによる想定(576)は適正ではなかった本当のMTUは296→solarisでフラグメント化された後、bsdiでもフラグメント化される24
11.8 UDPによるパスMTUディスカバリ• 同じ例ただし、bsdiがICMPエラーで次のホップのMTUを返すよう修正25
11.9 UDPとARPの間のやりとり• UDPとARP実装の話26
11.9 UDPとARPの間のやりとり• 結果27
11.10 UDPデータグラム・サイズの最大値• 理論的には65535-20-8=65507バイトしかし殆どの場合これより小さい• 原因• アプリケーション・プログラムがプログラム・インターフェースに制限される• TCP/IPのカーネルの実装• UDPプログラム・インターフェースは、アプリケーションが戻ってくるデータグラムの最大値を毎回指定できるようにしている28
11.11 ICMP発信元抑制エラー• 受信データグラムが処理できないほど早く流れてきたときに生成• あくまで「できる」だけ(必須ではない)29
11.11 ICMP発信元抑制エラー• Bsdiからsunを経由してsolarisへデータグラムを送る• SLIPリンクはEthernetより1000倍ほど遅い• 100個の1024バイトのデータグラムを送る30
11.11 ICMP発信元抑制エラー• 結果31
11.12 UDPサーバーの設計• UDPを利用するサーバーの設計と実装にUDPのプロトコルとしての機能がどのように影響するのか32
11.12 UDPサーバーの設計• クライアントのIPアドレスとポート番号• UDPデータグラムには• 発信元と宛先のIPアドレス• 発信元と宛先のポート番号• 応答は要求してきたクライアントに返すことができる• 宛先IPアドレス• いくつかのアプリケーションは宛先IPアドレスを知る必要がある• OSが受信したUDPデータグラムから宛先IPアドレスをパスすることを要求しているが、全ての実装がこの機能を提供しているわけではない33
11.12 UDPサーバーの設計• UDP入力キュー• UDPポートには入力キューがある• オーバーフローするとデータグラムが破棄されることがある• Sockプログラムで実験してみる34
11.12 UDPサーバーの設計35
11.12 UDPサーバーの設計36• 結果• Sunから送られた全部1のデータグラム• Svr4から送られた全部4のデータグラム が届いた• 残りは破棄
11.12 UDPサーバーの設計• ローカルIPアドレスの制御37
まとめ• チェックサムの検証• フラグメンテーションの観察• ICMP到達不可エラー• TracerouteとUDPによるパスMTUディスカバリの調査• UDPとARPのやり取り• ICMP発信元抑制エラー38