新 米 エ ン ジ ニ ア の た め のはじめにこの連載もついに11 回目となった。過去

初歩 の10 回で非常におおざっぱではあるが、ひととおりインターネットのアドレスやルーティングの仕組みについて解説してきたつもりである。しかし結構細かいところをすっ飛ばして進めてきているので、「これじゃなんにもわかんねーよ」と、いつか誰かに怒ら

インターネット技術れるのではないかと、元来小心者の筆者は《第11回 ホストまでのメッセージ処理》

らプカプカ浮いとるやんけ」とか「最初の小鳩の胸をうち震わせながら毎日を過ごしている。一方、「インターネットマガジンの連載の中で1 人だけハードコアで、周りかほうは楽しいんですが、途中からよくわかんなくなります。あら、可愛い猫♪」などという声も聞く。ううむ。
それでも、「あっさばさんの記事わっかりやすいっすよー」と営業マンが励ましてくれることもある。そのニコニコ顔を見ていると、よっしゃ焼肉でも食って元気出して頑張ったろかい、という気分にもなる。と

浅羽 登志也

はいえ、「プロバイダーのエンジニアがこのasaba@iij.ad.jp
株式会社インターネットイニシアティブ

記事読んで勉強しているらしいです」という風の噂を耳にすると、ええええええ、これ読んでもルーター1 つ設定できるようにな

インターネットでは、一般のユーザーでも自分の送り出したメッセージが特定のホストに接続されるまでの仕組みを実際に確かめることができます。今回は、そのためのいくつかの便利なコマンドについて解説します。また、それを実際に使って目的地までどういう経路を通っているのか、相手ホストからなぜ応答が返ってこないのかを調べてみることにしましょう。

290 INTERNET magazine 1996/3

るわけじゃないのに、ええんかいなぁ…と再び不安な気持ちで胸が詰まる。
原稿はいつも夜中か休日か飛行機の中で書くことにしているのだが、最近はこんな感じで悶々としているうちに時が流れてしまうことも多い。
かくして、人は白いワニが見えるようになるのである。

インターネットマガジン／株式会社インプレスR&D©1994-2007 Impress R&Dせんか？

運転を始める前にさて、ではいったい何が確かめられるとISP（Internet Service Provider）との接いうのだろうか？

んがちゃんと動いているということなんだろうが、じゃあなんで離れたところからそんなことが分かるのだろうか？

続が完了して人々はまず最初に何をするのだろうか？

目を輝かせながら知っている

ping コマンド

ICMP

インターネットに繋がったということは、この仕組みは結構単純で、相手を呼んで当然インターネット上のいろいろなホストみて一定時間以内に返事をするかどうかでにアクセスできるようになったということで判断しているのである。この相手を呼ぶと限りのURL にかたっぱしからクリック攻撃をかける？ よい時代（？）になったものである。
しかし、ちょっと待った。それで本当にもちろんそれでもよいある。では特定のホストにインターネット

い う 行 為 は 、 ICMP（ Internet Controlのだが、少なくとも本稿の読者は違うと信経由で到達できるかどうかを調べるにはどMessage Protocol）というプロトコルを用じたい！

うしたらよいだろうか？

いて行われる。ICMP はすべてのIP のソフよいのだろうか？

これはたとえば車を買ったときにまず何をするかということと似ているよ

これを確認するためにはping というコマトウェアの一部として実装されているので、うな気がする。つまりいきなりエンジンをンドを用いればよい。ping はもともとUNIX用いているホストがワークステーションだろ

かけてドライブに出かけてしまうのか、そワークステーション上のアプリケーション

うが、Mac だろうがPC だろうが、コーヒーれとも、まずボンネットを開けて、よく分（Windows95 にも同様のコマンドがあるし、メーカーだろうが冷蔵庫だろうが、ともかからないまでも、ふむふむとか言いながらMac にも MacTCP Ping というのがある）

くIP を用いて通信を行うことができるもの

ひととおりあちこち触ってみたり、叩いてで、指定したホストが生きているかどうかであれば必ず利用できる（はずの）プロトみたり、キャップを開けてみたりした後、を調べることができる。

コルである。

さらにエンジンをかけてみて、おおあっちが図1 はSunOS 4.1.4 付属のping コマンド

ICMP にはいくつかの種類のメッセージ動いている、こっちが回っている、なーるを実行した例である。ベンダーやOS のバーが定義されていて、ping コマンドではこのほどと満足そうに笑みを浮かべた後、初めジョンによって実行の仕方やオプションにうちのエコー要求（Echo Request）とエコてドライブに出かけていくかの違いである。

違いがあるので注意してほしい。

ー応答（Echo Reply）という2 つのメッセ

せっかくまだまだインターネットを動かこの図を見ると、確かにftp.iij.ad.jp といージを用いている。ICMP のエコー要求メしているいろいろな部分がユーザーにも比うホストを指定してping コマンドを実行すッセージを受け取ったホストは、送り主に較的むき出しに見えてしまう時代なのだかると「ftp.iij.ad.jp は生きてるよん（ftp.iij.

対してICMP のエコー応答メッセージを返ら、まずはいろいろ確かめてみないことにad.jp is alive）」という応答が返ってくる。

すことになっているのである。

は楽しみも半減するってぇもんじゃありま「生きている」ということは、ftp.iij.ad.jp さ

図1 ping コマンドの例1

asaba:shiosai>ping ftp.iij.ad.jp
ftp.iij.ad.jp is alive

インターネットマガジン／株式会社インプレスR&D©1994-2007 Impress R&D

INTERNET magazine 1996/3291

図 2 のように、ping コマンドは、指定さ置したあとで外部との接続性を確認するた

このように、ping コマンド自体は単純なれたホストに対してICMP エコー要求メッ

めに、このping コマンドを用いているはずことしかしていないのだが、結構いろいろセージを送り、一定時間内に相手のホストである（面白がって、端末を後ろからのぞなことを調べられて便利である。

からICMP エコー応答メッセージが返ってき込んだりしないように:-））。

待てよ、では、ping コマンドが失敗した

さらに、SunOS 4.1.4 付属のping コマン

とき、つまり、ICMP のエコー要求メッセ

さて、ここでもうちょっと考えてみよう。

ドではオプション--s を指定することにより、ージを送ったけれども、エコー応答メッセ送り出したエコー要求メッセージに対して繰り返し相手ホストに対してICMP エコーージが返ってこなかったような場合は、いエコー応答メッセージがちゃんと返ってき要求メッセージを送ることもできる（このったい何が起こっているのだろうか？

た場合に、いったい何が確認できたことに動作がデフォルトであるバージョンもある）。の場合は上記の1 2 3 のうちどれかがうなるのだろう？

各々のエコー要求メッセージを送り出してまくいっていないことになるのだが、そのどからエコー応答が返ってくるまでの時間をれかを特定することはできない。こういう計ることにより、相手ホストとの間のRTTときにどこがおかしいのかもうちょっと詳し（Round Trip Time）を測定することができく調べる方法はないものだろうか？

くるかどうかを調べていたわけである。

たとえば図2 で考えると、実は次の3 つのことが確認できたことになる。
1 ホストA からホストB までICMP エコーこるのである。このRTT とは1 組のホスト間でパケットが往復するのにかかる時間のこ要求メッセージがちゃんと届く
2 ホストB のIP のソフトウェアがICMP メとである。

traceroute コマンド

図 3 の例では、shiosai.iij.ad.jp というホ以前にも一度紹介したが、UNIX ワークストからftp.iij.ad.jp というホストに対してステーションで動くtraceroute というコマ

ICMP のエコー要求メッセージを繰り返しンドがある（Windows95 にも同様のtrac-10 回送っている。1 行の出力が1 つのエコ

ert というコマンドがあるし、Mac にもmacー要求メッセージに対応している。行の右

traceroute というのがある）。traceroute コ

つまり、相手ホストまで到達できるとい

端の数字は、その回のエコー要求に対するマンドはその名が示すとおり、経路（route）うことと、相手ホストのIP ソフトウェアがエコー応答が返ってくるまでの時間である。の追跡（trace）をするためのコマンドであ正常に動作しているということが分かるの

一番下の2 行には全体の統計情報が示されった。では、さっそく試してみよう。

である。おそらくISP からルーターなどのイている。この出力結果もping のバージョン

図4 は、urayasu.iij.ad.jp というホストかンストールをしにきた人は、ルーターを設によって若干異なるので注意してほしい。

らftp.iij.ad.jp に対してtraceroute コマンド

ッセージをきちんと処理し、ICMP エコー応答メッセージを送り返す
3 ホストB からホストA までICMP エコー
応答メッセージがちゃんと届く

時

ホストA

間

ICMPエコー要求

1

ホストB
ホストＢでのICMPメッセージの処理2

3
ICMPエコー応答

図2 ICMP エコー要求／応答メッセージ

292 INTERNET magazine 1996/3

asaba:shiosai>ping -s ftp.iij.ad.jp
PING ftp.iij.ad.jp: 56 data bytes
64 bytes from ftp.iij.ad.jp (192.244.176.50): icmp_seq=0. time=7. ms
64 bytes from ftp.iij.ad.jp (192.244.176.50): icmp_seq=1. time=7. ms
64 bytes from ftp.iij.ad.jp (192.244.176.50): icmp_seq=2. time=6. ms
64 bytes from ftp.iij.ad.jp (192.244.176.50): icmp_seq=3. time=8. ms
64 bytes from ftp.iij.ad.jp (192.244.176.50): icmp_seq=4. time=6. ms
64 bytes from ftp.iij.ad.jp (192.244.176.50): icmp_seq=5. time=7. ms
64 bytes from ftp.iij.ad.jp (192.244.176.50): icmp_seq=6. time=6. ms
64 bytes from ftp.iij.ad.jp (192.244.176.50): icmp_seq=7. time=6. ms
64 bytes from ftp.iij.ad.jp (192.244.176.50): icmp_seq=8. time=6. ms
64 bytes from ftp.iij.ad.jp (192.244.176.50): icmp_seq=9. time=6. ms^C---- ftp.iij.ad.jp PING Statistics---10 packets transmitted, 10 packets received, 0% packet loss
round-trip (ms) min/avg/max = 6/6/8
図3 ping コマンドの例2（オプション-s を指定した場合）

インターネットマガジン／株式会社インプレスR&D©1994-2007 Impress R&D

新米エンジニアのための初 歩 の イ ン タ ー ネ ッ ト 技 術を実行したときの結果である。これにより、
urayasu.iij.ad.jp からftp.iij.ad.jp に到達するまでどういうルーターを経由していくのかが分かる。

IP データグラムの構造

データグラムの最長生存時間

インターネット上でやりとりされるデーすべてのIP データグラムには必ず最長生

タの単位は、IP データグラムという。これ存時間（TTL）というものが定義されていまず1 行目は、最初に経由するルーターは連載の前のほうでも解説したと思う。する。これは実際には8 ビットの整数値であがmaihama.iij.ad.jp という名前のルーター

べてのデータグラムは、データグラムヘッダり、インターネット上に送り出されたデーであることを示している。さらに行の右側ーを持ち、ここにデータグラムの配送を制御

タグラムが生存し続けられる最長時間を秒の3 つの数字がurayasu からmaihama までするための情報が書き込まれている（図5）。

数で表したものである。TTL の値は、ルーのRTT を示している。なぜ3 つ表示される

これはちょうど葉書や封書を送るときにターがデータグラムを配送する際に、そのかは後で詳しく述べることにしよう。

は、表に宛先や送り主の住所を書いたり、処理にかかった秒数だけ減じられる。通常

2 行目は、maihama の次に、sanban-場合によっては速達と書いたりするのと同はルーターでのデータグラムの処理は、数cho-fw.iij.net というルーターを経由するこじことである。これを見て郵便屋さんはそミリから数十ミリ秒程度しかかからない。とを示している。行の右側の3 つの数字はれをどこに届けるのか、届かなかったとき

しかし、TTL の値は少なくとも1 ずつ減ら

1 行目と同様、urayasu からsanbancho-fwにはどこに送り返すのか、速達扱いで送るさないといけない（さもないと、永遠にまでのRTT を示す数字である。

べきかどうか、などを判断するのである。

TTL の値は減らない）ので、ルーターを通過するたびに1 ずつ減っていくと考えればよ以下同様に、otemachi-bb0.iij.net、IP のデータグラムヘッダーには、宛先やotemachi-gate0.iij.net というルーターを経送り主の住所に相当するIP アドレスや、由して最後 5 行目にftp.iij.ad.jp というホスTOS（Type Of Service）のような、配送こうしてルーターを経由するたびにTTLトに到達していることが分かる。このようの質を示す情報（これはたとえば郵便に普は1 ずつ減じられ、0 になった時点でデータに、経路上にあるすべてのルーターを経由通の郵便と速達があるようなものである。

グラムは廃棄される。これにより、たとえする順番に示してくれるのである。しかも、だがTOS は現在あまり使われていない）なばルーティング・ループなどが生じた場合各ルーターまでのRTT まで分かってしまうどが記されている。にも、データグラムが永遠にループするこのだ。なるほど、面白い。しかし、どうしてこんなことが分かるのだろう？

この他にもデータグラムヘッダーには、デいだろう。とを防止できるのである。

ータグラムに振られたシーケンス番号や、しかし、人様のデータグラムを廃棄して実はtraceroute コマンドもICMP を用いデータグラムの生存時間（TTL: Time Toしまうわけなので、ただ黙って捨ててしまているのである。しかし、ping コマンドとLive）や、途中でデータグラムがさらに細うわけにもいかない。そのデータグラムの送違って結構複雑なことをしている。tracer-

かく分割されたかどうかを示す情報などがり手に自分がデータグラムを廃棄してしま

oute コマンドの動作を理解するためには、含まれている。データグラムヘッダーの詳ったことをお知らせするのが礼儀というも実はいままですっ飛ばしてきた細かい部分

細については、別の機会に譲ることにして、のである。さて、どうしよう？

を理解する必要がある。

ここではtraceroute を理解するために必要なものだけ解説しよう。

大丈夫。困ったときのICMP ということで、ちゃんとそのためのメッセージが用意

toshiya:urayasu>traceroute ftp.iij.ad.jp
traceroute to ftp.iij.ad.jp (192.244.176.50), 30 hops max, 40 byte packets
1 maihama (192.244.184.33) 2.105 ms 1.975 ms 1.937 ms
2 sanbancho-fw.iij.net (192.244.191.45) 36.426 ms 33.858 ms 32.502 ms
3 otemachi-bb0.iij.net (202.232.0.33) 43.935 ms 39.508 ms 41.499 ms
4 otemachi-gate0.iij.net (192.244.176.14) 38.911 ms 37.909 ms 37.232 ms
5 ftp (192.244.176.50) 47.307 ms 37.76 ms 37.296 ms

ヘッダー

データ

図5 IP データグラム

図4 traceroute コマンドの例

インターネットマガジン／株式会社インプレスR&D©1994-2007 Impress R&D

INTERNET magazine 1996/3293

されているのである。この場合のデータグ

データグラムが途中で廃棄されるのは、Unreachable）メッセージである。ちょっラム廃棄の通知には、ICMP の時間切れ

TTL が0 になったときだけではない。経路と待ってよ。最初の2 つは分かるけど、最（Time Exceeded）メッセージを用いるこ

上のルーターやデータグラムのデスティネー後の「ポート」って何なのよ？とができる。

ションホストが、受け取ったデータグラムった。筆者もここで原稿を捨てちゃいたくをどう処理してよいのか分からずに困ってなるのだが、そうすると畳の上で寝られなしまうことがある。

くなってしまう人がいるので、そうもいか

図6 では、ホストA からホストB に向けてデータグラムをTTL=6 で送り出したが、経路上のルーター1でTTL の値が0となり、デルーターであれば、宛先ホストに対するータグラムが廃棄される。ルーター1 は、デ経路情報を持っていないため、次にどこにータグラムを廃棄したことを通知するため転送してよいのやら分からなくなったり、にホストA にICMP 時間切れメッセージを宛先ホスト自体がいなかったりした場合で送る。

ある。ホストであれば、確かに自分宛のデうーむ困ない。とりあえずここでは、ポートはアプリケーションを表すと思ってほしい。
これでやっと材料が揃った。

traceroute コマンドの仕組み

これを受け取ったホストA では、「ああ、ータグラムだけれども、それを渡すべきアTTL が0 になっちゃったのかぁ…」とデータプリケーションがないような場合である。

traceroute コマンドは、図 7 に示すようグラムが廃棄された原因を知ることができるのである。

困ったときには、そのまま持っていてもに、これまでに説明したいくつかのICMP仕方がないので「ええい捨てちゃえ！」とメッセージをうまく利用して、経路上のルなるのだが、この場合もやはり黙って捨てーターを調べていく。てしまうのは礼儀に反する。

宛先到達不可ホストA からホストB までの経路を調べ

このような場合のために、3 つのICMP メ

たい場合、まずホストA は、ホストB 上にtraceroute コマンドを説明するためには、ッセージが用意されている。ネットワーク存在しない（と思われる）アプリケーショ

さらにいくつかのICMP メッセージについて到達不可（Network Unreachable）メッン宛にデータグラムを送る。ただしこのと説明しておかないといけない。あともう少セージ、ホスト到達不可（Host Unreach-

きTTL の値を1 にして送るのである。

しだけ我慢しよう。

able）メッセージ、ポート到達不可（Portするとそのデータグラムを受け取ったルーター1 は、データグラムの転送の処理をする際にTTL の値を1 減らす。もともとTTL が1 だったものを、1 減らしてしまうと0 になるので、「おっとぉ、ざーんねんでしホストAICMP時間切れメッセージた捨てちゃうもんね」とデータグラムを廃棄する。

TTL=6

ホストB

だがこのとき礼儀正しいルーター1 は、TTL=5

ICMP 時間切れメッセージをホストA に送TTL=4り返して、自分がいみじくもデータグラムを廃棄してしまったことを通知する。これによりホストA は、最初のルーターがルーTTL=3ター1 であることが分かる。なぜ分かるかって？ ふっふっふ、まだまだ甘いな明智君。

TTL=2
TTL=1

R1TTL=0

廃 棄

送られてきたICMP メッセージのソースアドレスを見ればよいのだよ。
次にホストA は、最初と同じデータグラ
ムを再び、しかし今度はTTL の値を2 にして送り出す。すると今度はルーター1 でTTL が1 減らされてもまだ0 にはならず、ル

図6 TTL とICMP 時間切れメッセージ

294 INTERNET magazine 1996/3

インターネットマガジン／株式会社インプレスR&D©1994-2007 Impress R&D

新米エンジニアのための初 歩 の イ ン タ ー ネ ッ ト 技 術ーター2 にめでたく転送される。だがルータいても、ホストB にはそのデータグラムを処の宛先として指定されているアプリケーシ

ー2 で残念ながらTTL は0 となり、今度は理するアプリケーションがいない。良い子

ョンがホストB 上に存在していたらどうな

ルーター2 がデータグラムを廃棄する。ルーのホストB は「せっかく頂いたんですけどるの？ 思惑通りにICMP ポート到達不可

ター2 も礼儀正しい良い子なので、ホストねぇ」と言いながらもデータグラムを廃棄メッセージは返ってこないんじゃないかし

A に捨てちゃってごめんなさいと、ICMP 時するのだが、ホストA に対してICMP ポーら？ うーむ、良い質問だ。

間切れメッセージを送る。これでホストAト到達不可メッセージを送り返すことを忘は、2 番目のルーターがルーター2 であるこれない。

ふっふっふ。ぬかりはない。そのためにtraceroute コマンドは、データグラムを3 つホストA では、ICMP ポート到達不可メ

同時に、それぞれ異なるアプリケーション宛あとは、これを繰り返していけばよい。

ッセージが送り返されると、「おお、やっとに送り出しているのである。これが図4 で、ホストA は、ICMP 時間切れメッセージをホストB に届いたか」と言いながら、trace-RTT が3 つずつ表示されている理由である。

受け取るたびに、TTL の値を1 つ増やしてroute コマンドの実行を終了するのである。

またこれによって、同じルーターに対するとをまんまと知ることができるのである。

RTT を3 回測定していることになるので、1前と同じデータグラムを送り出す。こうす
ることにより、データグラムが転送されて回だけ測定するよりもよいデータが得られおわりにいく経路上の順番どおりにどういうルータるのである。どうだまいったか？

ーがあるのかがホストA にばれていくのであ

こうして、ping コマンドやtraceroute コ

うーん、でもでも、もしその3 つの異なる。しかもホストA では、ICMP 時間切れ

マンドを用いれば、特定の相手に到達できるアプリケーションがたまたますべて存在しメッセージが送り返されてくるまでの時間るのかどうか、また、そこに至るまでにどていたらどうなるの？ ねぇどうなるの？

を計っているので、図 4 のようにRTT までういう経路を経由するのかを調べることがうっうーむ。再び良い質問だ…… おっばれてしまう。

できる。これだけでもいろいろ楽しめることぉ、そろそろ時間だぁ！ ふっふっふっふ。と請け合いである。

さらばじゃ明智君！ また会おう！

これを繰り返していくと、いつかはホス
トB までデータグラムが届くようになる。しあれ？

かし、せっかくホストB にデータグラムが届

でも、 ちょっと待 ってよ。

traceroute コマンドで、もし万が一データホストB

ホストA
存在しないアプリケーションへのデータ
ICMP時間切れメッセージ
ICMPボート到達不可メッセージ

ルーター3

TTL=4
TTL=3
TTL=2
TTL=1

ルーター2
ルーター1

図7 traceroute コマンドの仕組み

インターネットマガジン／株式会社インプレスR&D©1994-2007 Impress R&D

INTERNET magazine 1996/3295

［インターネットマガジン バックナンバーアーカイブ］ ご利用上の注意
この PDF ファイルは、株式会社インプレス R&D（株式会社インプレスから分割）が 1994 年～2006 年まで発行した月刊誌『インターネットマガジン』の誌面を PDF 化し、「インターネットマガジン バックナンバーアーカイブ」として以下のウェブサイト「All-in-One INTERNET magazine 2.0」で公開しているものです。

http://i.impressRD.jp/bn
このファイルをご利用いただくにあたり、下記の注意事項を必ずお読みください。
z 記載されている内容（技術解説、URL、団体・企業名、商品名、価格、プレゼント募集、アンケートなど）は発行当時のものです。
z 収録されている内容は著作権法上の保護を受けています。著作権はそれぞれの記事の著作者（執筆者、写真の撮影者、イラストの作成者、編集部など）が保持しています。
z 著作者から許諾が得られなかった著作物は収録されていない場合があります。
z このファイルやその内容を改変したり、商用を目的として再利用することはできません。あくまで個人や企業の非商用利用での閲覧、複製、送信に限られます。
z 収録されている内容を何らかの媒体に引用としてご利用する際は、出典として媒体名および月号、該当ページ番号、発行元（株式会社インプレス R&D）、コピーライトなどの情報をご明記ください。
z オリジナルの雑誌の発行時点では、株式会社インプレス R&D（当時は株式会社インプレス）と著作権者は内容が正確なものであるように最大限に努めましたが、すべての情報が完全に正確であることは保証できません。このファイルの内容に起因する直接的および間接的な損害に対して、一切の責任を負いません。お客様個人の責任においてご利用ください。

このファイルに関するお問い合わせ先
All-in-One INTERNET magazine 編集部
im-info@impress.co.jp
Copyright © 1994-2007 Impress R&D, an Impress Group company. All rights reserved.