ルーティングと距離、通信経路を調べるtracertコマンド、tracerouteコマンドについて

ルーティングと距離、通信経路を調べるtracertコマンド、tracerouteコマンドについて

みなさん、こんにちは!

ブリュの公式ブログ.netにお越しいただきまして、ありがとうございます。

このサイトでは、ITについて特化したサイトを運営しています。

今回は、ルーティングと距離について解説し、通信経路を調べるtracertコマンド、tracerouteコマンドについて紹介します。

この記事を読むと、ルーティングの結果、情報伝達経路がどのように形成され、データ通信ができるのか?

さらにはルーティング経路を調べるtracertコマンドとtracerouteコマンドで、データセンターのおおよその位置も特定できます。

さらにさらに、同じ地域にあるサーバーでも、会社によって通信経路が異なることも確認できます!

内容盛りだくさんですが、楽しめる記事だと思うので、ぜひ最後まで読んでくださいね!

スポンサーリンク

ルーティングとは?

ルーティングは、インターネット上の空間にある、経由ポイントだと思ってください。

道路でいえば、交差点のイメージです。

車は、交差点を曲がっていくことで目的地に到達します。

インターネットの情報も同じで、ルーターを通ったときの分岐で、曲がっていくことで目的の経路を探し当てます。

インターネット上に送信された情報は、宛先のIPアドレスを持っており、このiPアドレスに対して最適な経路となるようにルーターが経路の振り分けを行うのがルーティングです。

ルーティングにおける距離の要素

ルーティングにおける距離には、大きく3つの視点があります。

これらの情報を用いて、ルーターはルーティングテーブルを作成しています。

ネットワーク速度

ネットワーク上の通信速度の情報です。

回線の太さなども影響がでます。

その他、意外とあるのが物理上の距離です。

物理上の距離は、日常的なイメージがそのままです。

例えば、大阪から京都に通信する場合、大阪→京都と通信すれば距離は短いですが、大阪→東京→京都と通信すれば、物理的な距離は長くなります。

ルーティングにおいて、直接的に物理上の距離が情報としては使われませんが、距離が長ければ通信に時間がかかるので、間接的に影響している存在といえます。

経由するルーター数(ホップ数)

経由するルーターの数は、目的地に到達するまでに何個のルーターを経由するかを表しています。

ルーターの数が少ないほど、ホップ数の数値が小さくなります。

ルーターはあて先を判定するアルゴリズムを動かしているので、経由するルーターが少ないほど最適な経路となります。

ネットワークの信頼性

ルーティングにおいては、ネットワークの信頼性も含まれます。

簡単に言うと、車を運転していて、砂利道よりもアスファルトで舗装された道のほうが走りやすいでしょう。

スポンサーリンク

ルーティングの基本的な動作

ルーターは、上記の距離的な要因をリスト化したルーティングテーブルを保持しおり、その情報をもとに受信したデーター(パケット)を、次に隣接しているどのルーターに送るかを判定します。

もしも、ルーターの知らないIPアドレスがあったとしても、このIPアドレスのあて先を知っているルーターはどれかを判定します。

さらに、全く知らないIPアドレスがあっても、とりあえず自分よりも大規模なルーターに転送することで、情報の伝達を行います。

これだけの説明では意味が分からないでしょう。

実際に自宅から、通信経路を調べるtracertコマンドを使って通信経路の調査を行いました。

ルーティング経路を調べるtracertコマンドとtracerouteコマンド

ルーティングを調べる方法として、tracertコマンドtracerouteコマンドを紹介します。

Windowsの場合にはtracertコマンド、LinuxとMacの場合にはtracerouteコマンドになります。

OSの違いだけで、意味する動作は同じです。

Windowsの場合、コマンドプロンプトを開きます。

そこに、次のコマンドを入力して、Enterを押すと、経路探索ができます。

では、実際に実在する複数のウェブサイトについて、ルーティングの結果を調べてみましょう。

tracertコマンドで経路を調べた結果

レンタルサーバーの代表格として、東京、大阪、石狩の3つのデータセンターまでの経路を調べました。

日本地図とともに、直感的に通信経路を可視化していきましょう。

GMOペパボ:ヘテムル(東京)までの通信経路

当サイトbrionac-yu-yake.netはヘテムルで運営しており、IPアドレスは157.7.44.182です。

自宅からtracertコマンドを実行した結果です。

なお、自宅周辺のIPアドレスは伏字にしています。

No. ドメイン IPアドレス
1 6ms 2ms 1ms
2 * * * 要求がタイムアウトしました。
3 10ms 10ms 10ms
4 * * * 要求がタイムアウトしました。
5 8ms 8ms 8ms
6 9ms 10ms 10ms aha.37.s-port.biz 202.94.181.37
7 8ms 11ms 9ms unused-133-130-012-034.interq.or.jp 133.130.12.34
8 20ms 9ms 10ms unused-133-130-013-018.interq.or.jp 133.130.13.18
9 14ms 9ms 8ms g-o-p-2w-b01-1-gw-e-1-1.interq.or.jp 157.7.40.130
10 9ms 9ms 13ms pb-html-2w-b01-1-gw-e-1-1.interq.or.jp 157.7.38.206
11 9ms 8ms 8ms users307.vip.heteml.jp 157.7.44.182

interQに直接入り、ヘテムルのサーバーに接続しています。

interQは、GMO系列のプロバイダであり、ヘテムルのサーバーとの接続を行っている会社です。

関東圏から、東京のヘテムルまでの通信経路を図で表すと、次のようになります。

GMOデジロック:コアサーバー西日本リージョン(大阪)までの通信経路

当サイトのウェブサービスである、web.brionac-yu-yake.netは、コアサーバーの大阪データセンターで運営しています。

IPアドレスは150.95.12.102です。

同様に、自宅周辺のIPアドレスの情報は伏字にしています。

No ドメイン IPアドレス
1 3ms 2ms 2ms
2 * * * 要求がタイムアウトしました。
3 8ms 16ms 11ms
4 * * * 要求がタイムアウトしました。
5 9ms 8ms 8ms
6 14ms 10ms 9ms bdd.81.s-port.biz 49.143.244.81
7 10ms 14ms 11ms aha.33.s-port.biz 202.94.181.33
8 12ms 12ms 10ms unused-133-130-012-033.interq.or.jp 133.130.12.33
9 18ms 18ms 19ms b-osk-e5-7-1-2-e-0-1-0.interq.or.jp 157.7.40.202
10 19ms 17ms 17ms unused-133-130-004-033.interq.or.jp 133.130.4.33
11 19ms 16ms 18ms unused-133-130-004-038.interq.or.jp 133.130.4.38
12 19ms 19ms 21ms 133.130.5.133
13 18ms 20ms 17ms web.brionac-yu-yake.net 150.95.12.102

このルーティングの場合には、9番目のb-osk-e5-7-1-2-e-0-1-0.interq.or.jpから大阪にジャンプしています。

時間を見ると、平均的にも9番目から時間がかかっています。

これは、東京から大阪へ通信している時間といえます。

また、直接的な意味合いはないですが、ドメインのoskという文字がは大阪を連想させる文字列であることからも、意味が通ります。

ルーティングの状況を見ると、関東圏からのアクセスの場合、関東でinterQのネットワークに入り、東京から大阪までのアクセスはinterQ内部のネットワークでアクセスしていることがわかります。

通信経路のイメージ図は、下のようになります。

一度東京に集約されてから、interQのネットワークで大阪にアクセスしているイメージです。

エックスサーバー(大阪)までの通信経路

お試し期間中に調べたエックスサーバーの経路も紹介します。

No ドメイン IPアドレス
1 3ms 4ms 3ms
2 * * * 要求がタイムアウトしました。
3 8ms 10ms 9ms
4 * * * 要求がタイムアウトしました。
5 14ms 19ms 14ms osnrt-as17676.bb.sakura.ad.jp 157.17.146.37
6 16ms 14ms 16ms osnrt1s-nrt3-3.bb.sakura.ad.jp 157.17.146.242
7 16ms 14ms 14ms osnrt1b-nrt1s.bb.sakura.ad.jp 157.17.146.138
8 14ms 14ms 15ms osnrt9c-nrt1b.bb.sakura.ad.jp 157.17.147.110
9 14ms 15ms 14ms 210.188.213.213
10 14ms 14ms 14ms sv7203.xserver.jp 183.90.237.44

エックスサーバーは、さくらインターネットの大阪データセンターを利用しています。

場所は堂島のようです。

エックスサーバーへは、5番目の時にすでに大阪のネットワークに接続しています。

よって、直接さくらインターネットの大阪に接続されている様子がわかります。

コアサーバーの場合には、いったん東京でGMOの管轄に入り、大阪まで一気にアクセスしますが、エックスサーバーの場合には、さくらインターネットの東京の管轄は利用せず、直接大阪のネットワークにアクセスしています。

さくらインターネット石狩データセンターへの通信経路

最後に、関東圏から北海道石狩市にある石狩データセンターまでの通信経路を見てみましょう。

私はさくらインターネットは利用していないので、石狩データセンターは利用していません。

そこで、いろいろなサイトの通信経路を調べた結果見つけた、さくらインターネット石狩データセンターへの経路を紹介します。

なお、さくらインターネットの場合、ドメイン名に地域名が割り振られており、東京ならtk、大阪ならos、石狩ならisという文字があります。

※サイト名は伏せます。

No ドメイン IPアドレス
1 3ms 2ms 3ms
2 * * * 要求がタイムアウトしました。
3 8ms 7ms 9ms
4 * * * 要求がタイムアウトしました。
5 11ms 9ms 8ms tkort4-as17676.bb.sakura.ad.jp 157.17.130.129
6 24ms 25ms 24ms iskrt3-tkort4.bb.sakura.ad.jp 157.17.131.34
7 28ms 25ms 25ms iskrt1s-rt3.bb.sakura.ad.jp 103.10.113.110
8 26ms 28ms 25ms iskrt102b-rt1s-2.bb.sakura.ad.jp 103.10.113.98
9 25ms 24ms 26ms iskrt126e-rt102b.bb.sakura.ad.jp 103.10.114.222
以下省略

さくらインターネットの石狩データセンターまでは、いったんさくらインターネットの東京近郊ネットワークに入った後、さくらインターネットのネットワークにより石狩までアクセスを行います。

東京から石狩までのアクセス時間ですが、速さ的に言えば5ms程度で、北海道新幹線よりも圧倒的に速いです。

経路のイメージ図は下の図のようになります。

一度東京に集約されてから、さくらインターネットのネットワークで北海道石狩までアクセスしているイメージです。

通信経路を図で表すと・・・

日本地図上で簡単に接続経路を図で表すと、下のようになります。

関東圏からのアクセスの場合、東京のヘテムルへは、interQの東京近郊ネットワークに接続後、そのままサーバーに接続されます。

大阪のコアサーバー西日本リージョンへは、いったんinterQの東京近郊ネットワークに接続され、InterQの経路を通ってinterQの大阪近郊ネットワークに接続し、コアサーバーへの接続を行います。

エックスサーバーはさくらインターネットの大阪データセンターを利用しており、関東圏からのアクセスの場合、さくらインターネットの東京近郊ネットワークは利用せずに、直接大阪近郊のネットワークに接続されます。

これらは、接続したルーターが最適と判断した経路によって通信しているもので、同じ大阪への通信であっても、挙動が異なるのが面白いところです。

また、大阪への接続の場合には、さくらインターネットの場合には直接アクセスを行っていますが、石狩データセンターへのアクセスの場合には、GMOと同じような挙動になり、一度東京で集約されてから石狩にアクセスします。

これらの図は、あくまでもイメージ程度にしてください。

ルーティングと距離、通信経路を調べるtracertコマンドとtracerouteコマンドのまとめ

ここまで、ルーティングと距離、通信経路を調べるtracertコマンドとtracerouteコマンドについて説明してきました。

ルーティングは、ルーターが受信したデーター隣接するどのルーターに向けて送信するかを判定するアルゴリズムのことです。

ルーティングには、ネットワーク速度、ホップ数、ネットワークの信頼性があり、これらを総合的に判断して作成されたルーティングテーブルを利用します。

ルーターは受信したデーターのあて先IPアドレスを参照し、ルーティングテーブルをもとに、どのルーターに送信するかの判定を行います。

パソコンからは、ルーターのルーティングによって作成された通信経路を確認する方法として、tracertコマンドとtracerouteコマンドがあることを紹介しました。

Windowsの場合にはコマンドプロンプトでtracertコマンドを使います。

LinuxとMacでは、tracerouteコマンドを使います。

コマンドの文字列は異なりますが、基本的な動作は同じです。

最後に、tracertコマンドによって、複数のサーバーまでの通信経路を確認しました。

関東圏からのアクセスで、東京のレンタルサーバーであるヘテムル、大阪のレンタルサーバーであるコアサーバー西日本リージョンとエックスサーバー、北海道石狩市のレンタルサーバーであるさくらインターネット石狩データセンターを対象にしました。

この時、同じ大阪への通信であっても、ルーティングにより決定された通信経路が異なることを確認しました。

さらに、GMOのinterQで大阪に通信する場合、さくらインターネットで石狩に通信する場合では、関東圏のアクセスの場合、一度東京に集約している動きも確認しました。

最終的に日本地図と組み合わせることで、直感的に面白さを感じることができたと思います。

かなり盛りだくさんな内容でしたが、これを機に、通信の面白さについて体感していただければ幸いです。

以上、ルーティングについての説明でした。

記事の内容に関してご不明な点は、 お問い合わせからお願いします。

記事内容と関係なくても、WordPress等でわからないことがあったらコメントしてください!

スポンサーリンク

シェアする

  • このエントリーをはてなブックマークに追加

フォローする