シリーズの最終回。ブラウザに名前を打ってからページが表示されるまでを、最初から最後まで追いかけます。DHCP で設定をもらい、DNS で名前を番号にし、同じか外かを判定し、ARP で隣の MAC を知り、家のルーターの NAT を越え、各ルーターの表と BGP でバケツリレーされ、サーバーで開けられ、返事が戻るまで。traceroute と ping で自分の目で経路を見る方法も。
このシリーズの最終回です。ここまでの7本で、部品はすべて出そろいました。
| 本 | 部品 |
|---|---|
| 1 | 各ルーターは「次にどこへ渡すか」だけを知っている |
| 2 | データは層ごとの荷札で包まれる |
| 3 | 同じネットワークの中はスイッチが MAC で届ける |
| 4 | 同じか外かを IP のネットワーク部で判定する |
| 5 | 隣の MAC は ARP で知り、区間ごとに付け替える |
| 6 | ルーターは表の最長一致で次を決める |
| 7 | 表はルーター同士の話し合い（OSPF・BGP）で書かれる |
この作品では、これらを全部つなげて、ブラウザのアドレス欄に `example.com` と打ってから、ページが表示されるまでを、最初から最後まで追いかけます。
図の道は、左から「あなたの PC → 家のルーター → プロバイダ → 大きな通信会社 → データセンター → サーバー」です。実際にはもっと多くのルーターを通りますが、やっていることは同じです。
話は、ブラウザを開くより前から始まります。PC が Wi-Fi につながった瞬間です。
つないだばかりの PC は、まだ IP アドレスを持っていません。4本目で見た「4つの設定」（IP アドレス、サブネットマスク、デフォルトゲートウェイ、DNS サーバー）が、どれもありません。
そこで PC は、DHCP（Dynamic Host Configuration Protocol）という仕組みで、設定をもらいます。
| 順番 | やりとり |
|---|---|
| 1 | PC → 全員：「IP アドレスをください」 |
| 2 | 家のルーター → PC：「192.168.1.10 をどうぞ。マスクは /24、出口と DNS は 192.168.1.1」 |
| 3 | PC → 家のルーター：「それを使います」 |
| 4 | 家のルーター → PC：「了解」 |
PC はまだ IP アドレスを持っていないので、1の質問は MAC アドレスとブロードキャスト（3本目）で送ります。3本目で「IP アドレスをもらう前でも、線の上で話せる必要がある」と書いたのは、このためです。
家のルーターは、手の空いている番号をしばらくの間だけ貸し出します。期限が来たら延長を頼みます。だから、家に帰って Wi-Fi につないだ瞬間から、何も設定しなくてもインターネットが使えるのです。
ブラウザに example.com と打ちました。でも、2本目で見たとおり、IP の札には番号を書かなければなりません。まず、名前を番号にする必要があります。
PC は、DHCP でもらった DNS サーバー（ここでは家のルーター）に「example.com の A レコードは？」と問い合わせます。家のルーターは、プロバイダの DNS サーバーにその質問を回し、プロバイダの DNS サーバーが、世界中の DNS サーバーを順にたどって答えを見つけてきます。答えは 203.0.113.10 です。
DNS の仕組みそのものは、メールのしくみシリーズの2本目で詳しく見ました。ここで大事なのは、この DNS の問い合わせ自体も、1つの小さな小包として、これから見る旅とまったく同じ道を通っているということです。名前を引くためにも、ネットワークの仕組みがすべて使われています。
宛先の番号 203.0.113.10 が分かりました。PC は、4本目で見た判定をします。
自分は 192.168.1.10/24、相手は 203.0.113.10。ネットワーク部が 192.168.1 と 203.0.113 で違います。相手は外のネットワークにいます。
外宛てなので、デフォルトゲートウェイ（家のルーター、192.168.1.1）に渡します。その MAC アドレスを、5本目の ARP で確かめます（たいていは ARP テーブルに覚えています）。
荷札は、5本目で見たとおり、IP の宛先はサーバー、MAC の宛先は家のルーターになります。
実際には、PC はまず TCP で相手のサーバーと「接続の準備」をやりとりし、安全な通信（HTTPS）のための鍵の交換もしますが、ここでは細部を省いて、本題の依頼の小包だけを追います。
2本目で見たとおり、ブラウザが作った中身に、荷札が順に重なります。
| 荷札 | 中身 |
|---|---|
| 中身（アプリケーション層） | GET /（ページをください。HTTPS なので暗号化されている） |
| TCP（トランスポート層） | 宛先ポート 443、送信元ポート 51234 |
| IP（インターネット層） | 宛先 203.0.113.10、送信元 192.168.1.10、TTL 64 |
| MAC（リンク層） | 宛先は家のルーター、送信元は PC |
そして、Wi-Fi の電波として家のルーターへ送り出されます。
家のルーターは、6本目で見たルーターの仕事（MAC の札を捨て、IP の宛先を見て、表で次を決め、TTL を減らす）をします。表はほぼデフォルトルートだけなので、次はプロバイダです。
ただし、家のルーターには、もう1つ大事な仕事があります。4本目で見たとおり、192.168.1.10 はプライベートアドレスで、インターネットでは使えません。このままでは、サーバーが返事を返せません。
そこで家のルーターは、小包の送信元の番号を、自分の外側の番号に書き換えます。これを NAT（Network Address Translation）と呼びます。
| 送信元 IP : ポート | |
|---|---|
| 書き換え前 | 192.168.1.10 : 51234 |
| 書き換え後 | 198.51.100.7 : 40001（家のルーターの外側の番号） |
そして、「40001 番で返事が来たら、192.168.1.10 : 51234 に戻す」と自分の表に覚えておきます。家の中のスマホやゲーム機も、全部この1つの外側の番号を共有し、ポート番号で区別されています。
「IP の札は最後まで変わらない」と5本目で書きましたが、NAT だけは例外で、家の出口で送信元が書き換わります。宛先は変わりません。
小包はプロバイダのルーターに着きました。ここからが 、1本目で見たバケツリレーの本番です。
プロバイダのルーターは、6本目で見た5つの仕事を、機械的にこなします。MAC の札を確かめて捨て、宛先 IP 203.0.113.10 を表と照らします。
表には、203.0.112.0/20 の行があります（4本目の集約）。この行は、7本目で見た BGP で、「203.0.112.0/20 へは、通信会社（AS 2）経由で行ける」と教わって書いたものです。最長一致でこの行を選び、TTL を1減らし、通信会社へ向けて、新しい MAC の札を付けて送り出します。
プロバイダのルーターは、その先の道を知りません。知っているのは「通信会社に渡せば近づく」ということだけです。
通信会社のルーターも、まったく同じことをします。
通信会社（AS 2）の中には、たくさんのルーターがあります。その中の道は、7本目で見た OSPF のような話し合いで、最短経路が計算されています。小包はその中をバケツリレーで進み、AS 2 の出口に着きます。
出口のルーターの表には、BGP でデータセンター（AS 3）から教わった「203.0.113.0/24 はうち（AS 3）の中」という行があります。そこで、データセンターへ渡します。
ここまで来ても、誰一人として、PC からサーバーまでの全体の道を知りません。各自が自分の表を見て、次の1歩を決めているだけです。それでも小包は、着実にサーバーに近づいています。
データセンターのルーターの表では、203.0.113.0/24 の行が「直接」になっています。自分の口に、このネットワークがつながっているからです（6本目の「直結」）。
つまり、4本目の言葉で言えば、サーバーはこのルーターと「同じネットワーク」にいます。ほかのルーターに渡すのではなく、サーバー本人に直接渡します。
5本目で見たとおり、ARP でサーバーの MAC アドレスを確かめ、最後の MAC の札を付けて、送り出します。
サーバーは、2本目で見たとおり、小包を外側から1枚ずつ開けます。
MAC の札を見て「自分宛て」、IP の札を見て「自分宛て」、TCP の札のポート 443 を見て「Web サーバーのアプリ宛て」。そして、中身の GET / を Web サーバーのアプリに渡します。アプリは、ページを作って返事を用意します 。
ここで振り返ってみると、IP の札の宛先 203.0.113.10 は、PC を出たときから、1度も変わっていません。MAC の札は区間ごとに何度も付け替わり、送信元は家の出口で NAT で書き換わり、TTL は少しずつ減りましたが、最終の宛先だけは最初から最後まで同じでした。
サーバーの返事の小包は、宛先が 198.51.100.7 : 40001 です。サーバーから見ると、話し相手は家のルーターの外側の番号だからです。
返事も、行きとまったく同じやり方で戻っていきます。データセンター、通信会社、プロバイダの各ルーターが、自分の表で「198.51.100.7 へは次はここ」と決めて渡していきます。6本目 で見たとおり、行きと帰りで別の道を通ることもあります。
家のルーターに着くと、NAT の表を見て「40001 番は 192.168.1.10 : 51234」と、宛先を書き戻します。そして家の中の PC に渡します。
PC のブラウザは返事を受け取り、画面にページを表示します。ここまで、ほんの数十ミリ秒の出来事です。
小包が実際にどのルーターを通っているのかは、自分の PC から確かめられます。traceroute（Windows では tracert）というコマンドです。
仕組みは、6本目で見た TTL を逆手に取ったものです。
| 送る小包 | 何が起きるか |
|---|---|
| TTL 1 | 1台目のルーターで TTL が 0 になり捨てられ、「寿命が尽きた」と知らせが返る → 1台目が分かる |
| TTL 2 | 2台目で捨てられる → 2台目が分かる |
| TTL 3 | 3台目で捨てられる → 3台目が分かる |
| … | サーバーに着くまで繰り返す |
TTL を1ずつ増やして送るだけで、途中のルーターが1台ずつ名乗り出てくれるわけです。表示された一覧が、あなたの PC からサーバーまでの、いまこの瞬間の経路です。時間をおいて打つと、経路が変わっていることもあります。7本目で見た「話し合いで道が変わる」を、自分の目で確かめられます。
もう1つの定番の道具が ping です。相手に「生きてる？」という小さな小包（ICMP）を送り、返事が戻ってくるまでの時間を測ります。
$ ping example.com
64 bytes from 203.0.113.10: ttl=57 time=15.2 mstime=15.2 ms は、行って帰ってくるまでの時間です。
ttl=57 からも、面白いことが分かります。返事の小包は、サーバーを TTL 64 で出発した可能性が高いので、57 で届いたなら、途中で約7台のルーターを越えてきたことになります（出発時の TTL は機械によって違うので、目安です）。
ネットワークの調子が悪いときは、まず ping でつながるかを確かめ、つながらなければ traceroute でどこで止まっているかを確かめる、というのが基本の手順です。
シリーズの最初の疑問に、最後にもう一度答えます。
「どうやって場所も知らないコンピューターまで、まっすぐデータを送れるのか？」
あなたの PC は、相手の場所を知りません。知っているのは「外宛ては出口のルーターへ」だけです。出口のルーターも、その先のルーターも、全体の道は知りません。それぞれが宛先の番号を見て、自分の表で「次にどこへ渡せば近づくか」だけを決めています。その1歩1歩を積み重ねたものが、世界の反対側まで届く道になります。
「その経路はどうやって決めているのか？」
各ルーターの表は、ルーター同士が隣と話し合って書いています。組織の中では網の地図から最短経路を計算し（OSPF）、組織の間では「この宛先はうち経由」を伝え合っています（BGP）。線が切れれば、話し合いで数秒のうちに別の道へ切り替わります。
そして、それを支えている部品が、ここまでの作品で見てきたものです。
| 部品 | 役割 |
|---|---|
| IP アドレスの「まとまり」 | 遠くのルーターは方面だけ覚えればよい |
| IP と MAC の2つの宛先 | 最終の宛先は変えず、隣への渡し方だけを区間ごとに付け替える |
| 最長一致とデフォルトルート | 細かく知っている宛先は正確に、知らない宛先は上流へ |
| TTL | 誰も全体を知らないやり方の、安全装置 |
全体を知る者がいないからこそ、インターネットはここまで大きくな れました。 それが、このシリーズの結論です。
ログインするとコメントできます。
読み込み中…
権利侵害・不適切な内容の連絡: [email protected]