図 1 ping は ICMP バケットの彳星延日計を表示する h0S11 host2 Plng ℃ MP Echo Request 往復遅延時間 ICMP EchO Reply 図 2 ICMP ヘッダに含まれる言 ! 届 ファイ非偏集 ( 印表示キャプチャ 0 モニタツール設定 0 ウインドウヘルプ はー LAN 團住 @ ソ斗「目↓ 園 ; 住 @ 冫 0 ; ! 斗ー目↓ フ ... プ発信元 .. - マ受信先 ... ププ ... マサマリ フ…マ発信元 ... マ受信先 ... “プ…マサマリ 223 hostl ho 2 I CMP Type= 8 Echo Requ r¯ 226 h05t2 226 h05t2 hostl 1 CMP Type=0 Echo Repl Type: 0 Echo Repl 第を ASTECÆyest„キャプチャデタく p ⅲ ho 1 ~ をれ c» キャフチャデタく ping—hostl. enc>; 屋 , 一 23- ho 1 回区三 を手第デ夕イ可新叫に = I CMB= 、、 Type=8 Echo Req1J 言ロ X hü 2 I CMP host 1 lnternet Cont rol Message Protocol Type 8 Echo Request 0 xcc 3 ()o rrect) 3035 lnte rnet Con レ引 Message Prot oc 引 0 Echo RepI y Type ミ Code 0 (correct ) ldent if ier Sequence Number Data cks ldentifier quence Data 8035 言こ》」 p i n 言の出力 に / 田 ID226 h03t2 ー > h03t1 IOMP 旧 entifier フィールドの値を利用して、 EchO Request に対応する EchO 日 ep Ⅳをみつける 図 1 は、 ping コマンドが往復遅延時間を測定する様子 4. Echo Request ノヾケットの送信時刻と Echo Reply パ を示したものです。 ケットの受信時刻の差分を求め、往復遅延時間を表示す る。 1. ping が hostl から ICMP の Ech0 Request バケッ トを送る。 実際に、 ping が表示した往復遅延時間をみてみましょ 2. Echo Request バケットを受け取ったコンピュータ う。図 3 は、 hostl から host2 に向けて ping を実行し (host2) は、プロトコルの仕様に従って Echo Reply たときの出力です。バケットを 4 回送受イ言しており、表示 バケットを返す。 された術夏遅延時間は、 3. Echo Reply ノヾケットを受け取った ping は、 ICMP へ ・最初の 1 回は約 2ms ッダに含まれる識別子 (ldentifier フィールドの値 ) を 残りの 3 回は 0.8ms 前後 参照して、 Echo Request バケットと対応づける ( 図 となっています。 0 60 UNIX MAGAZINE 2005 . 3

図 5 正時間の言に使用したネットワーク hostl 送信側 ℃ MP Echo Request LA N バケットをキャプチャ 100Mbps スイッチ 、第ををを第 ℃ MP Echo Reply 図 6 Echo Request のタ里日罰の重み h0S12 でキャプチャしたバケット キャプチャデタく ping-host2.enc> 園ー白一〇住 : 9 。 ! ー観圄↓む副 受信側 host2 バケットをキャプチャ 100Mbps 回区 フ .. マ発イ言元 ... プ受信先 ... プ ... マサマリ マデルタ時問 時刻 2 : 50 : 56 .855 134 hostl 135 host2 hostl hßt 2 hostl 207 ho 虱 2 hostl host 2 2 1 3 2 1 2 206 200 133 host 2 hostl ho 2 host 1 host 2 host 1 ho 虱 2 host 1 I CMP ICMP ICMP ICMP ICMP ICMP ICMP ICMP . e れ C 〉 Type= 8 Echo Request Type: 0 Echo RepI y Type: 8 Echo Request Type: 0 Echo RepI y Type= 8 Echo Request Type20 Echo RepI y Type: 8 Ech0 日 e 叩” Type= 0 Echo RepI y 0. 圓 0000 0 圓 00 1 . 0 囲 154 0 .000037 1 .010032 0 .000038 1 .010044 . 0.000043 EchO Request の処理に かかった時間 hostl でキャプチャしたバケット キャプチャデータく ping—hostl マ発信元 ... プ受信先 .. ーー ! 目↓む副 プ ... マサマリ 223 hostl ho 2 hostl 23S host2 host 1 ho 2 hostl hos を 2 256 255 246 245 235 226 host2 h05 い host 2 2 hostl host 2 ho 1 ICMP I CMP I CMP ICMP ICMP I CMP I CMP ICMP マデルタ時問 Type:8 E 0 Request Echo RepI y 一 0 .000000 Type= 0 Type:0 Echo RepI y Type= 8 Echo Request Type= 0 Ech0 RepI y Type= 8 Echo Request Type= 0 Echo RepI y Type= 8 Echo Request 1 .005053 0 . 000750 1 .003331 0 .000737 1 .003323 0 .000763 表 1 往彳延日の害冾 図 6 の彳夏遅延時間と、図 3 の ping コマンドの往復遅 延時間は若干異なっています。これは、送受信したノヾケッ トをプログラムが処理するのにかかる時間の差です。 表 1 に示したように、 host2 での処理にかかる時間は、 往復遅延時間の 5 % 前後であることが分かります。 今回の実験に使った hostl と host2 は同じ LAN 上に あり、ネットワーク的に近接しています。インターネット 62 . 22 : 50 : 56.855 . 22 : 50 : 57.861 . 22 : 50 : 57 . 861 . 22 : 50 : 58.871 . 22 : 50 : 58 . 871 . 22 : 50 : 53.881 . 22 : 50 : 53.881 22 : 51 : 00.608 . 22 : 5 1 : 00.610 . 22 : 5 1 : 01 . 6 1 5 . 22 : 5 1 : 0 1 . 6 1 6 . 22 : 5 1 : 02 .625 . 22 : 51 : 02.626 . 22 : 5 1 : 03.635 . 22 : 51 : 03.636 を経由するなど、ネットワーク的に遠いコンピュータと通 回区 時刻 往復遅延時間 バケット 1 2 3 4 host2 計 0.080mS 0.037mS 0.036mS 0.043mS 彳星蔀 1.933mS 0.750mS 0.737ms 0.763mS 害冾 4.1 % 4.9 % 4.9 % 5.6 % 信する場合は、往復遅延時間に占める ICMP の処理時間 UNIX MAGAZINE 2005.3

ネットワー ク・ミニ実験室 0 図 3 ping コマンドの実行結果 hostl$ ping -c 4 hos む 2 PING h0Sし2 . mydomain ( 192 .168 .10 . 2 ) 56 ( 84 ) bytes Of data . . 10 . 2 ) : 64 bytes from hOSt2 . mydomain ( 192 . 16 8 こに 1 = 253 time=l . 98 ms 64 bytes from h0St2 . mydomain 亡 t1 = 253 し ime = 0 . 790 ms 64 bytes from hOSt2 . mydomain ttl = 253 に土 me = 0 . 783 ms 64 bytes from hOS し 2 . mydomain t し 1 = 253 time = 0 . 801 ms ( 192 . 16 8 . 10 . 2 ) : ( 192 . 168 ・ 10 . 2 ) : ( 192 . 16 8 . 10 . 2 ) : icmp_seq=l icmp_seq=3 icmp_seq=2 icmp_seq=4 hos し 2 . mydomain ping statistics 4 packets transmitted, 4 received, 0 packet loss ′ r しこ min/avg/max/mdev = O . 783 / 1 . 088 / 1 . 980 / 0 . 515 ms hostl$ 往復遅延時間の最小値 / 平均値 / 最大値 / 標準偏差 ℃ MP Echo の往復遅延時間 time 3027mS host2 図 4 彳星延日訐とネットワーク遅延日計 host 1 Plng EchO Request 往復遅延時間 遍以値の精度 Echo Rep\y ネットワーク遅延時間 CMP の処理時間 ネットワーク遅延時間 ネットワーク遅延時間彳断夏遅延時間亠 を求めました。 2 次に、 ping の出力から得られた近似値と、実際のネット ワーク遅延時間とのあいだには、どの程度の誤差があるの を合計したものです ( 図 4 ) 。 3. 帰りのネットワーク遅延時間 ド 2. host2 が ICMP バケットを処理する際のオーバ 1. 往きのネットワーク遅延時間 ping カ俵示する彳星延時間は、前項の例の場合、 かを検討してみましよう。 UNIX MAGAZINE 2005.3 と仮定し、近似値として、 往きと帰りのネットワーク遅延時間カ蒔しい 分に短い ・ host2 でのオーバーヘッドが往復遅延時間と比較して十 それでは、 ICMP バケットの処理にかかる時間はどの程 度景彡響するのでしようか。これを調べるために、図 5 のよ うな構成のネットワークを使って測定をしました。その結 果カ咽 6 です。 図 6 の上の画面は、 host2 でキャプチャしたバケットで す。下線部の値は、 host2 が Echo Request バケットを 受け取った時刻と Echo RepIy バケットを送り出した時刻 の差、すなわち host2 で ICMP を処理するためにかかっ た時間です。 下の画面は、 hostl でキャプチャしたバケットです。下 線部の値は、 hostl が Echo Request バケットを送った 時刻と Echo RepIy バケットカってきた時刻の差、すな わち ICMP バケットの往復遅延時間を表しています。 61

図 12 tracerout が送受信したバケットの様子 キャプチャデタく traceroute-enc 〉 ロ ; 目住 @ & 9 ーー斗目↓ ! む副 回区 フ .. マ発信元 ... マ受信先…マプロト . 104 hostl rout e rl ho 1 「 0 沚 e rl 1 1 5 ho 虱 1 routerl hostl ro e r2 host 1 rout e r2 host 1 「 0 沚 e r2 host 1 ho 3 host 1 host 3 host 1 ho 3 146 1 45 142 141 137 135 131 130 127 126 1 2 1 120 1 1 6 1 1 2 1 1 1 106 ho 3 hostl host 3 hostl host 3 hostl ho 3 hostl host3 hos い h 。 3 hostl host 3 host 1 hast3 ho 虱 1 ho 3 hos を 1 TRACEROUTE I CMP TRACEROUTE ICMP TRACEROUTE ICMP TRACEROUTE ICMP TRACEROUTE I CMP TRACEROUTE I CMP TRACEROUTE ICMP TRACEROUTE ICMP TRACEROUTE ICMP マサマリ SEQ=I, 0riginal TTL:I Type= 1 1 T ime Exceeded , Cde:0 SEQ=2, Original TTL:I Type= 1 1 T i me Exceeded , C0de=0 SEQ:3, 0riginal TTL:I Type= 1 1 T i me Exceeded, 師 d 0 SEQ=4, 0riginal TTL=2 Type=11 Time Exceeded, Cod 0 舮 5 , 0riginal TTL=2 Type=11 刊 me Exceeded, Cod ド 0 SEQ:G, 0riginal TTL:2 Type: 1 1 刊 me Exceeded, Code:0 SEQ=7, OriginaI TTL=3 Type= 3 D い nati on lJn reachab 厄 , C0de: 3 SEQ=9, 0 日引 n 引 TTL=3 Type=3 Desti nat i on Unreachab 尾 , C 3 0riginal TTL:3 Type= 3 Desti nati on Un reachab , C0de: 3 route 「 1 まで届いたバケット 「 oute 「 2 まで届いたバケット host3 まで届いたバケット ・ポートが開いていればリクエストのバケットとして処理 ではありません。近いところから順番にバケットを 1 つ送 トが通過したルータまでの遅延時間を次々と送り返すわけ traceroute は、バケットを 1 つだけ送り、そのバケッ ることが分かるでしよう。 ほうが遠くのルータより往復遅延時間が長くなる場合もあ traceroute の仕組みか理解できれば、近くのルータの 近くのルータが遠くなる " 理由 などの様子力毓み取れるでしよう。 ・ host3 が ICMP の Destination Unreachable を返す Time Exceeded を返す 経路の途中にある routerl と router2 が ICMP の ットカ隧り出される ・ hostl から host3 へ向けて TTL 値を変えながらバケ 図 12 を見れば、 ICMP バケットが返されます。 のように動作します。通常はポートが開いていないので、 reachable/Port Unreachable" を返す ポートが閉じていれば ICMP の、、 Destination Un- する 66 り、そのたびに術星延時間を 1 回言則します。ですから、 コンピュータやネットワークの環境により、遠くのルータ より近くのルータのほうが遅延が大きくなることもあるの です。 それでは最初の疑問に戻り、図 8 の routerl までの往 復遅延時間が 1 つだけ大きな値を示した理由を考えてみま しよう。 たとえば、最初のリクエストと応答のあいだに ARP な どによるアドレス解決がおこなわれていれば、遅延時間が 長くなるはずです。ところが、今回の場合はアドレス解決 は関係がなさそうです。 図 13 は、 traceroute が送信した最初のバケットと、そ れに対する応答が返されるまでに流れたすべてのバケット を表示したものです。最初のノヾケットの送信と応答のあい だには X プロトコルのノヾケットが 1 つ流れただけで、ア ドレス解決などの traceroute と関係するようなバケット は何も流れていません。したがって、応に時間がかかっ たのは別の理由があったと考えられます。 残念ながら、ネットワーク上を流れるバケットを調べた だけではその理由は分かりませんが、 ・ ping のときも 1 回目の応答だけ時間がかかっている UNIX MAGAZINE 2005.3

連載 / ネットワークとセキュリティ 次に、入手したソースコードを展開します。 nmap-download. html ・ http://www.insecure.org/nmap/ 時点での Nmap の最新版は 3.75 です。 の Web ページからソースコードを入手します。原稿執筆 ソースコードからコンパイルする場合は、ます Nmap % tar xvjf nmap—3.75. tar. bz2 または % tar xvzf nmap-3.75. tgz カレント・ディレクトリを変更し、 ノヾイルを実行します。 # make install % su % make % . /configure % cd nmap-3.75 最後にインストールをおこないます。 /configure とコン N m ap の利用方法 nmap コマンドの基本的な書式は次のとおりです。 # nmap スキャンタイブオプションスキャン対象のホスト / ネットワーク nmap にはたいへん多くのオプションがありますが、 こでは主要なもののみを紹介します。 スキャンタイプ TCP の SYN スキャンをおこないます。 SYN スキャ ンでは、単一の SYN バケットを j 言し、 SYN 十 ACK が 返ってきたらポートが開いていると判断し、 RST カ弡され た場合には閉じていると判断します。完全に TCP のセッ ションを確立しないため、ハーフォープン・スキャンとも 呼ばれます。多くのポートスキャナカリ用している方式で す。このオプションを利用するには root 権限が必要です。 TCP ポートに対して connect() スキャンを実行しま す。正しい 3way ハンドシェイクの手順を踏んでスキャン をおこなうため、スキャンの完了までに時間がかかります。 54 —sU UDP スキャンをおこないます。 UDP では開いてい ないポートにバケットが送信されると ICMP port un- reachable メッセージを返すので、ポートのた態が分かり ます。このオプションの利用には root 権限が必要です。 —sP ICMP ECHO Request を j 言し、 ICMP ECHO Re- ply をもとにがあるホストを調査します。 —sF ステルス FIN スキャンをおこないます。 UNIX 系 OS の多くは、開いていないポートへ FIN が送信された場合、 RST を返します。ステルス FIN スキャンでは、この性質 を利用し、 3way ハンドシェイクとは関係なく FIN を週言 して、それに対する応答をもとにポートの状況を判断しま す。このオプションを利用するには root 権限が必要です。 —sX クリスマスツリー・スキャンをおこないます。 FIN 、 URG 、 PSH フラグをオンにした TCP バケットを送信 し、それに対するエラー応答をもとにポートの状況を判断 します。このオプションの利用には root 権限が必要です。 —sN 全フラグがオフの無効な TCP バケットを j 当言する Null スキャンをおこない、 FIN スキャンやクリスマスツリー スキャンと同様、エラー応答をもとにポートの状況を判断 します。このオプションの利用には root 権限カ必要です。 オプション —PO ICMP ECHO Request の結果にかかわらずスキャン をおこないます。 ICMP ECHO Request に対する反応 がないホストをスキャンする際に利用します。 -p スキャンするポートの範囲 スキャンするポート ( の範囲 ) を 1 ー 65535 のように、、開 始ポートー終了ポート " か、 25 , 110 のようにカンマ区切りで 指定します。スキャンするポート範囲を指定しない場合、 - ヨ殳的なサービス提供ポートのみをスキャンします。 スキャンの結果をより冗長に出力します。 UNIX MAGAZINE 2005 . 3

図 8 traceroute コマンドの実行結果 hOS し 1 $ traceroute hOS に 3 traceroute 亡 0 host3 ( 192 .168 . 20 . 3 ) ′ packets 1 routerl ( 192 . 16 8 . 0 . 1 ) 11 . 9 31 ms 0 . 8 5 5 ms 2 router2 ( 192 . 16 8 . 11 . 2 ) 1 . 2 04 ms 1 . 0 3 6 ms 3 hos む 3 ( 192 . 16 8 . 2 0 . 3 ) 1 . 84 2 ms 1 . 3 6 7 ms 1 hos し 1 $ 30 hops max, 図 9 traceroute の実験に使用したネットワーク 38 byte . 338 ms 。← host3 までの往復遅延時間 1 . 02 7 ms ←「 oute 「 2 までの往復遅延時間 0 ・ 846 ms ←「 outerl までの往復遅延時間 LA N 送信側 host 1 / ヾケットをキャプチャ routerl です。 routerl" 、、 router2" 、、 host3 " の後ろに並んだ数値が途 中のルータまで、あるいは宛先のホストまでの往復遅延時 間を表しています。 ところで、これらの値には腑に落ちない点があります。 3 つずっ表示されている術夏遅延時間のうち、 1 番目佐 端 ) の時間に注目してください。 router2 や host3 までの 彳星延時間が 1—2ms なのに対し、それらより近くにあ る routerl までの往復遅延時間が 11.931mS で、遠くの ルータより近くのルータのほうが、、遠い " という結果にな っています。 このように、 traceroute は一見説明がつきそうにない結 果を表示することがありますが、測定の問題でもプログラ ムのバグでもありません。不思議な結果が出る理由を探る ため、まずは traceroute コマンドの基本的な仕組みを解 説しましよう。 traceroute の仕組み 図 10 は、 traceroute コマンドの仕組みを図示したもの です。 traceroute は宛先ホストへ向けて、 IP ヘッダの TTL 64 受信側 host3 「 oute 「 2 UNIX MAGAZINE 2005.3 1 OS によっては ICMP バケットを送る場合もあります。 2. 次は TTL=2 のバケットを 3 回送り 1. TTL = 1 のバケットを 3 回送ったら traceroute は、 を表示します。 取るまでにかかった時間 ・ UDP バケットを送信してから ICMP バケットを受け ・応答を返してきた機器のホスト名やアドレス は、バケットが宛先まで届かなかったと判断し、さらに Time Exceeded メッセージを受け取った traceroute るために用意されています。 ときに、バケットが同じ場所を無限に回り続けるのを避け られません。 TTL は、ループ状のネットワークがあった 切れたバケットはルータによって破棄され、その先へは送 の、、生存時間 " が切れたことを表しています。生存時間が ICMP の Time Exceeded メッセージは、バケット セージを含む ICMP バケットを返します。 値を 1 減らし、 0 になったときは、、 Time Exceeded" メッ す ( 図 11 ) 。ルータはバケットを中継するたびに TTL の (Time To Live) を 1 にした UDP バケット 1 を送信しま

ーク・ミニ実験室 0 図 13 routerl との送受信のあいだに流れたバケット キャプチャデタく traceroute. enc> フ ... 発信元 ... マ受信先 ... プロト . 園ー白巨一〇多ダ当ー観目うに副 ネットワ 回区 マデルタ時問 1 04 hostl 105 host5 106 routerl host3 host 1 hostl TRACEROUTE ICMP マサマリ SEQ=1 0ri inal TTL:I Event : NoExposu re Type= 1 1 T i me Exceeded , C0de= 0 0 . 圓圓 00 0 . 圓 0778 0 . 0 10235 t 「 aceroute とは関係のない バケットしか流れていない 図 14 ネットワーク延の厨以 〇往復遅延時間を使ってネットワーク遅延時間を近似できる EchO Request Echo Rep\Y 往復遅延時間 ネットワーク遅延時間 ↓ ℃ MP の処理時間 ( 短い ) ℃ MP を利用した往復遅延時間寺ネットワーク遅延時間 X2 X 往復遅延時間を使ったネットワーク遅延時間の近似はできない リクエスト 往復遅延時間 ネットワーク遅延時間 応答までの時間 ( 長い ) 応答 アプリケーション一般の往復遅延時間ネットワーク遅延時間 X2 ・ routerl カ芍反す 1 回目の traceroute の応答だけ時間が かかっている といったた兄から、ルータなどが最初の 1 回だけなんらか の処理をおこない、 2 回目以降は前の処理結果を利用して いるようにみえます。 旧電話のネットワーク遅延 ping コマンドや traceroute コマンドの場合、受信側が ICMP Echo Request や UDP バケットを処理するのに かかる時間はバケットがネットワークを移動する際にかか UNIX MAGAZINE 2005.3 る時間より、、十分に短い " ため、ネットワーク遅延の近似値 として往復遅延時間の半分を使うことができました。 ところが、 -- 一般的なアプリケーションの場合、リクエス トを受け取ってから応答を返すまでの時間は、かならずし も、、十分に短い " わけではないので、往復遅延時間をネット ワーク遅延の近似値として利用できるケースはめったにあ りません ( 図 14 ) 。 IP 電話では、音声を詰めたバケットが通話の相手に届 くまでの遅延が、会話の聴き取りやすさに重大な影響をお よほします。そのため、 IP 電話のプロトコルの一部である RTCP (RTP Control Protocol) に、ネットワーク遅 67

ク・ミニ実験室 0 ネットワー 図 16 RTCP にはネットワーク遅延を計算するため窈、黼肋ゞ含まれている 自ファイル ( 日編集 ( 印表示 キャプチャ 0 モニタツレ (I) 設定 0 ウインドウヘルプ ( 旦 ) - x : 'LAN ぎ目↓む副 フ ... マ発信 . . “受信 .. プロ ... マサマリ マ 129 hostl host 2 RTCP Packet Type: Sende r Repo rt 回区 朝 0 ASTEC Eyes ーャプチャデタく cp れ c 〉 ] 1 . 05 K パイトー 時刻 . 1 7 : 07 : 1 2 . 3 84 デルタ時問一 0 . 圓圓 00 Packet Type: Reæ ive r Report 283 h05t2 、 1 7 : 07 : ⅱ .46 4 5 .073360 RTCP ho 1 RTP Con レ引 P rot oc 引 Versi 0 ロ P 記 n ぎ no を exi stent Recepti on Repo Co 凵 を . 0 0001 Packet Type 201 R 引「 Report 32 octet(s) Length Synchronization Source ldentif ier 「 0 「 Sender 0 CIC42e3 Recepti on Report ( 1 ) Source I denti 日 er 0x 訂 817d 0 ( 1 / 256 リ n は ) Fracti on Lo Cumu はい ve Number of Packets Lo 0 packets Count of Sequence Number Cycl es 0 H ighest Sequence Number c 引 ved 37813 10 (timestamp 社 ) lnterarrival J 汢 t 日「 Del ay 引 nce い st Sender Repo erslon RTCP 2 1 332800 ( 1 / 65536 second unit) に / 2 ] ID283 t2 ー〉 hostl RTC RTCP の Sender Repo を送ってから Receiver Repo 員を受け取るまでの時間 hostl が Sender Repo を受け取ってから Receiver Repo を返すまでの時間 332800 = 5.078125 秒 65536 の 3 種類について、往復遅延時間やネットワーク遅延時間 この計算結果は、最初に ping で測定したネットワーク ( 近似値 ) を求める仕組みを紹介しました。また、送ったパ 遅延である約 0.8ms とも近い値になりました。 ケットに応答を返す際の時間的なオーバーヘッドや、バケ ット長がネットワーク遅延時間に与える影響についてもお ネットワークの性能を表す指標の 1 つに、送信したバケ 話ししました。 ットが目的地へ着くまでにかかる時間 ( ネットワーク遅延 ) ( あらい・みちこ ASTEC) があります。バケットの送信元と受信先の時計を正確に合 [ 赭文献 ] わせないかぎり、ネットワーク遅延を直接正確に測定する [ 1 ] J. Postel, User 、〃観佖 gram ProtocoI, RFC768, August ことはできません。 1980 そこで考えられたのが、往復遅延時間を測定して近似す [ 2 ] J. PosteI, ん 7 れ et ProtocoI, RFC791, September 1981 る方法です。今回は、 [ 3 ] J. Postel, lnternet Co れ ol Message ProtocoI, RFC ・ ping コマンド (ICMP Echo バケット ) 792 , September 1981 ・ traceroute コマンド (ICMP Time Exceeded バケ [ 4 ] H. Schu レ rinne, S. Casner, R. Frederick, V. Jacobson, RTP: A ・佖れ s 〃 0 Protocol 和月 e 襯 - Time 員〃 ca - 厖 0 れ s , RFC1889 , January 1996 ・ RTCP の Sender Report と Receiver Report ☆ 69 UNIX MAGAZINE 2005.3

図 10 traceroute コマンドの仕組み ①宛先ホストへ向けて TTL = 1 の UDP バケットを送る lnternet Pro を引 Version 4 (IPv4) ネットワー ℃ MP ク・ミニ実験室 0 宛先ホスト 送信元ホスト UDP TTL=I 往復遅延時間 1 段目のルータ TTL=O ℃ MP Time Exceeded ②宛先ホストへ向けて TTL = 2 の UDP / ヾケットを送る UDP TTL=2 TTL=I 往復遅延時間 ③宛先ホストに到達するまで TTL の値を 1 ずつ増やしてバケットを送る UDP TTL=n TTL=n-1 2 段目のルータ TTL=O ℃ MP Time Exceeded TTL=n-2 往復遅延時間 図 11 TTLØ{ 直 Header Length F ragment Of f を Time To Live P ro を 08 ー Heade r Checksum Source IP Add ress 4 20 byte(s) ()o option header) 0 b e s 1 7 UDP 0X557f (correct) 132.168.0.4 ( hos い ) Destination UnreachabIe Po Unreachable t 「 ace 「 oute の最初の / ヾケットの TTL は 1 ルータを経由するごとに幵 L は 1 減る Destination IP A re 132.168.20.3 (host3) 0ption No IPv4 options 3. その次は TTL=3 のバケットを 3 回送る UNIX MAGAZINE 2005.3 していき、宛先のコンピュータに届くと ( バケットを 3 回 到達できる距離を徐々に増やしながらバケットを送り出 という処理を、 TTL の値を増やしながら繰り返します。 送ってから ) 送信を終了します。宛先のコンピュータは、 ICMP の、 Destination Unreachable" メッセージを返 します。 traceroute は、通常のアプリケーションには利用されに くい 30000 番以降の UDP ポートへ向けてバケットを送 信します。バケットを受け取った宛先ホストでは、 65

連載 ネットワーク・ミニ実験室 ネットワーク遅延 荒井美千子 ネットワークの利用においては、しばしばデータを送受 信する際の、、時間 " カ墹題になります。 たとえば、メールを送ったコンピュータの時計が半年進 んでいたとすると、未来からメールが届くという奇妙な現 象カ起きてしまいます。 送ったメールが相手に届くまでにかかる時間も重要で す。 UUCP によるバケツリレー方式で配送していたころ は、国内のサイトに届くのに数時間かかることも珍しくあ りませんでした。 IP 接続の現在では相手に数十秒で届く ので、電話に代わる連絡手段として利用されています。で すから、数十秒で届くはずのメールがどこかで、、引っかかっ て " しまい、翌日まで届かなけれは不都合があるでしよう。 Web ではメールよりも時間に対する要求が厳しくなり ます。メールなら 10 分くらいは平気で待てますが、 Web ページが表示されるまでに待てる時間はせいぜい数十秒程 度です。 telnet や ssh などのインタラクテイプな処理ではさら に要求が厳しくなります。たとえば、キーポードから入力 した文字はリモートログイン先のコンピュータで処理され、 手許の画面にエコーバックされます。工コーバックまでに 1 秒かかる様子を想像してください。タイピングの速い人 なら、入力した文字カ俵示されるまでにさらにもう 5 ~ 6 文 オ丁ち込んでいるでしよう。 アナログの電話回線とモデムを使って遠方のコンピュー タにログインしていたころは、まさにそのような状態でし た。、、エコーバックされた文字を見ないほうがまだマシ " というくらいフラストレーションは溜まるし、エコーバッ クに惑わされてタイピングが遅くなってしまいます。 プロードバンド回線が当り前の現在では、エコーバック UN 工 X MAGAZINE 2005.3 に惑わされるほど遅い状況には当しなくなりました。し かし、 IP 電話やストリーミングなど、さらに時間に厳しい 使い方カ嶝場しています。 このような、、、時間カになる " ネットワーク・アプリケ ーションの応答が遅い場合は、 ・リクエストや応答がネットワークを流れる時間 ・リクエストを処理する時間 のどちらがボトルネックなのかを区別する必要があります。 残念ながら、どのようなアプリケーションにも利用でき る一般的な手法はありません。しかし、バケットがネット ワークを流れるのにかかる時間については、ネットワーク の仕組みができた当初から関心がもたれており、 TCP/IP にもいくつかの測定方法が用意されています。以下では、 それらについてみていきます。 データがネットワーク上を流れるのに要した時間のこと を、、ネットワーク遅延 " と呼びます。ネットワーク遅延は 正確な測定力攤しいので、データが彳夏する時間を 2 分の 1 にしたものが近似値としてよく使われます。 データの往復時間を測定するもっとも身近なツールとい えば ping コマンドでしよう。本来、 ping はバケットの 到達性を確認するツールですが、 ICMP の性を利用し、 バケットの往復遅延時間 (Round-Trip Time) も測定で ネットワーク遅延の測定 ています。 そのため、 きます。 したものが、ネットワーク遅延時間の近似値として使われ ping で得られた彳主復遅延時間を 2 分の 1 に 59