はじめに
ブラウザに URL を入力してからページが表示されるまでに使われている技術を学び直しました。
用語や仕組みを丸暗記するのではなく、「それ以前にどんな問題があり、その技術がどう解決したのか」 という視点で整理します。
全体の流れ
① イーサネット MAC アドレスを使って、同じネットワーク内の隣の機器まで届ける
② IP IP アドレスを使って、ネットワークをまたいで宛先まで運ぶ
③ TCP パケットの欠落・順番・重複を両端で補正し、確実に届ける
④ DNS ドメイン名から IP アドレスを調べる
⑤ HTTP 「何が欲しいか」「どう返すか」をやり取りする
⑥ HTTPS(TLS) 通信を暗号化し、なりすまし・改ざんを防ぐ
1. イーサネット・MAC アドレス
イーサネット
| 問題 | 解決 |
|---|---|
| PC から PC にデータを送るには、物理的に繋がっている必要がある | ケーブルの種類・電気信号の送り方・データの形式（フレーム）を定めた規格がイーサネット |
MAC アドレス
| 問題 | 解決 |
|---|---|
| 線で繋いでも、誰宛てのデータか分からないと届けられない | 機器（NIC）ごとに割り当てられたMAC アドレス（例：00:1A:2B:3C:4D:5E）を宛先にする |
スイッチ
| 問題 | 解決 |
|---|---|
| 複数の PC を 1 対 1 で繋ぐと線が膨大になる | スイッチに全台を繋げば、1 台につき 1 本で済む |
| 全ポートにデータをばらまくと無駄が多い | スイッチは「どのポートにどの MAC アドレスがいるか」をMAC アドレステーブルとして自動で学習し、宛先のポートにだけ転送する |
残った問題
MAC アドレスで届けられるのは、同じネットワークの中だけです。ネットワークの外にいる相手には届きません。これを解決するのが次の IP です。
2. IP（Internet Protocol）
IP
| 問題 | 解決 |
|---|---|
| MAC アドレスは同じネットワークの中でしか使えず、ネットワークの外の相手とは通信できない | ネットワークをまたいで使える最終的な宛先として、IP アドレス（例：192.0.2.10）を定めた |
MAC アドレスと IP アドレスの役割分担
1 章の MAC アドレスは、IP が登場しても不要になるわけではありません。役割が分かれています。
| MAC アドレス | IP アドレス | |
|---|---|---|
| 役割 | 隣の機器までの宛先 | 最終的な宛先 |
| 範囲 | 同じネットワーク内 | ネットワークをまたぐ |
| ルーターを越えると | 書き換わる | 変わらない |
ルーターを 1 つ越えるたびに、MAC アドレスは「次の機器」のものに付け替えられます。IP アドレスは最後まで同じです。
パケット
| 問題 | 解決 |
|---|---|
| 1 本の回線を 1 組の通信が占有すると、他の通信が使えない | データを小さなパケットに分割し、多くの通信で回線を共有する |
| 途中の機器が壊れると通信が止まる | パケットごとに別経路を通れるので、故障箇所を避けて届けられる |
ルーターとルーティング
ルーターは宛先 IP アドレスを見て、ルーティングテーブルから「次に渡すルーター」だけを判断します。目的地までの全経路は知りません。これをバケツリレーのように繰り返して、パケットを宛先まで届けます。
ルーティングテーブルの中身
| 項目 | 意味 |
|---|---|
| 宛先ネットワーク | どのネットワーク宛てのパケットか（例：203.0.113.0/24） |
| ネクストホップ | 次に渡すルーターの IP アドレス |
| 出力インターフェース | どのポートから送り出すか |
送信元は見ておらず、宛先 IP アドレスだけを見て次の行き先を決めます。
デフォルトゲートウェイ
| 問題 | 解決 |
|---|---|
| ネットワークの外に送りたいとき、PC はバケツリレーを最初に誰に渡せばいいか分からない | ネットワークの出口となるルーターをデフォルトゲートウェイとして設定しておき、外宛てのデータはすべてそこに渡す |
PC は宛先が同じネットワーク内なら直接届け、外ならデフォルトゲートウェイに渡すだけです。その先の経路は PC は知らなくてよく、ルーターたちがバケツリレーで運んでくれます。家庭では、Wi-Fi ルーターがデフォルトゲートウェイになっていることがほとんどです。
状態を持たない設計
IP は届くことも、順番も、重複しないことも保証しません。
| もしルーターに「何を送ったか」を覚えさせたら | 問題 |
|---|---|
| 基幹ルーターは数百万の他人同士の通信を中継している | CPU・メモリが逼迫し、パケットを捨てたり再起動したりする |
| ルーターが故障すると記録が消える | そこを通る通信が一斉に破綻する |
解決：ルーターには何も覚えさせず、転送だけをさせる。信頼性の確保は、当事者である両端（クライアントとサーバー）に任せる。この考え方をエンドツーエンド原則といいます。
3. DNS（Domain Name System）
ドメイン名
| 問題 | 解決 |
|---|---|
IP アドレス（例：192.0.2.10）は数字の羅列で、人間には覚えにくい |
人間が覚えやすいドメイン名（例：www.example.com）でアクセスし、裏側で IP アドレスに変換する |
| サーバーの IP アドレスが変わると、利用者に知らせ直す必要がある | 名前と住所を切り離したので、DNS の登録を書き換えるだけで済む |
HOSTS.TXT 方式（DNS 以前）
DNS 以前は、ドメイン名と IP アドレスの対応表を HOSTS.TXT という 1 つのファイルにまとめ、SRI-NIC という組織が一元管理していました。各コンピュータはこのファイルを定期的にダウンロードしていました。
問題点
- 配布の負担：台数が増えるほど、全台に配る負荷が増大する
- 更新の手間：ホストを追加するたびに管理元へ申請し、手作業で追記する必要がある
- 情報の古さ：次にダウンロードするまで変更が反映されない
- 名前の衝突：全世界で 1 つの名前空間なので、同じ名前がぶつかる
根本原因は 「全員が全データのコピーを持つ」かつ「一か所で集中管理する」 ことでした。
DNS の解決策①：問い合わせ方式
| 問題 | 解決 |
|---|---|
| 全クライアントに対応表を配布しなければならない | クライアントは対応表を持たず、必要なときに必要な 1 件だけ問い合わせる |
DNS の解決策②：階層化と委任（分散管理）
| 問題 | 解決 |
|---|---|
| 一か所で集中管理すると、負荷・障害・更新が集中する | ドメインを階層ごとに分け、各組織に管理を任せる（委任） |
ドメイン名は右から左へ階層をたどります。
. (ルート)
└── com
└── example
└── www
| 階層 | 担当サーバー | 知っていること |
|---|---|---|
. |
ルートサーバー |
com を担当するサーバーの場所 |
com |
TLD サーバー |
example.com を担当するサーバーの場所 |
example.com |
権威サーバー |
www.example.com の IP アドレス |
上位のサーバーは最終的な IP アドレスを知っているわけではありません。「その下はあのサーバーが担当している」と教えるだけです。
権威サーバー
あるドメインについて正式な答えを持っているサーバーです。ドメインの管理者が登録した情報を持ち、「これが正解です」と答えます。各組織が自分のドメインの権威サーバーだけを管理すればよいので、更新の手間や名前の衝突が解消されました。
example.com と hogehoge.com では権威サーバーが別々なので、問い合わせも別々のサーバーに分散されます。
リゾルバー
| 問題 | 解決 |
|---|---|
| クライアントがルートから 1 つずつたどるのは複雑 | リゾルバーが代わりにたどって答えを持ってくる |
キャッシュ
| 問題 | 解決 |
|---|---|
| 毎回ルートからたどると遅く、上位サーバーに負荷が集中する | 一度調べた答えをキャッシュし、一定期間（TTL）使い回す |
冗長化
| 問題 | 解決 |
|---|---|
| サーバーが 1 台だと、止まったときに名前解決できなくなる | 1 つのドメインに権威サーバーを複数台置く。 |
DNS の負荷対策まとめ：階層化で負荷を分け、冗長化で障害に備え、キャッシュで問い合わせ自体を減らす。
4. TCP（Transmission Control Protocol）
| 問題 | 解決 |
|---|---|
| IP ではパケットの欠落・順番の入れ替わり・重複が起こる | 両端で通し番号（シーケンス番号）と確認応答（ACK）を使い、並べ替え・重複の破棄・再送を行う |
両端の機器は自分が当事者の通信だけを覚えればよいので、負担は小さくて済みます。
シーケンス番号と ACK
- 受信側は ACK で「ここまで受け取った。次はこの番号をください」と返します。
- 送信側は、相手が ACK で返した番号から次のデータを送ります。
クライアント：1001 番から 500 バイト送信（1001〜1500）
サーバー ：ACK 1501（1500 まで受け取った、次は 1501 から）
クライアント：1501 番から続きを送信
3 ウェイハンドシェイク
| 問題 | 解決 |
|---|---|
| データを送る前に、相手と送受信できるか、番号をいくつから数えるかを合意する必要がある | 3 回のやり取りで、お互いの開始番号を伝え合う |
データは双方向に流れるので、番号も向きごとに別々に用意します。
① SYN クライアント → サーバー：「私の番号は 1000 から」
② SYN-ACK サーバー → クライアント：「1000 了解、次は 1001 ちょうだい（ACK）」
＋「私の番号は 5000 から（SYN）」
③ ACK クライアント → サーバー：「5000 了解、次は 5001 ちょうだい」
②で「ACK」と「自分の SYN」を 1 つにまとめているため、4 回ではなく 3 回で済みます。
- SYN：自分の開始番号を伝える
- ACK：相手の番号を受け取ったと伝える（次に欲しい番号を返す）
開始番号は毎回ランダムに決めます。古い通信のパケットとの混同や、なりすましを防ぐためです。
5. HTTP（HyperText Transfer Protocol）
| 問題 | 解決 |
|---|---|
| 文書の取り出し方がシステムごとにバラバラ | 「何が欲しいか」「どう返すか」の共通の書式を定めた |
GET /index.html HTTP/1.1
Host: www.example.com
HTTP/1.1 200 OK
Content-Type: text/html
<html>...</html>
- メソッド：GET（取得）、POST（登録）、PUT（更新）、DELETE（削除）など
- ステータスコード：2xx 成功、3xx リダイレクト、4xx クライアント側の誤り、5xx サーバー側の誤り
6. HTTPS
| 問題 | 解決 |
|---|---|
| 相手が本物のサーバーか分からない（なりすまし） | サーバー証明書を検証して、本物か確認する |
| 通信内容を途中で読まれる（盗聴） | 暗号化する |
| 通信内容を途中で書き換えられる（改ざん） | MAC（メッセージ認証コードで検知する |
暗号化の仕組み
共通鍵暗号方式
| 問題 | 解決 |
|---|---|
| 通信内容を途中で読まれる | 暗号化と復号に同じ鍵を使って暗号化する。計算が軽く高速 |
ただし、鍵をどうやって安全に相手に渡すかという問題が残ります（鍵配送問題）。鍵をそのまま送ると、途中で盗まれれば終わりです。
公開鍵暗号方式
| 問題 | 解決 |
|---|---|
| 共通鍵を安全に渡せない | 公開鍵（誰に見られてもよい）と秘密鍵（サーバーだけが持つ）のペアを使う。公開鍵で暗号化したものは、対になる秘密鍵でしか復号できない |
ただし、計算が重く、大量のデータの暗号化には向きません。
ハイブリッド方式
| 問題 | 解決 |
|---|---|
| 共通鍵は速いが渡せない／公開鍵は安全に渡せるが遅い | 公開鍵暗号の仕組みで共通鍵を安全に共有し、実際のデータは共通鍵で高速に暗号化する |
公開鍵は誰でも配れるため、偽のサーバーが偽の公開鍵を渡してくる可能性があります。これを防ぐのが、上の表にあるサーバー証明書の検証です。
まとめ
今回改めて学習してみると、どのような課題をどのような技術で解決するのかを理解することがとても大切だと思いました。特にTCPの理解が曖昧だったため、IPで発生していた問題を解決するためだったことが知れたのは学びでした。今後もどのような問題を解決するための技術なのかを意識して学びたいと思いました。
参考資料