インターネットの仕組み

インターネットは「ネットワークのネットワーク」である。データがあなたの PC からサーバーまでどのように届くのか――パケット通信、ISP の階層構造、海底ケーブル、ルーティングプロトコルを体系的に理解することで、ネットワークトラブルシューティングからアーキテクチャ設計まで、あらゆる場面での判断力が飛躍的に向上する。

この章で学ぶこと

• インターネットの物理的構造（海底ケーブル、IX、データセンター）を理解する
• パケット通信の仕組みと回線交換との違いを把握する
• ルーティングの原理と BGP の役割を説明できるようになる
• ISP の階層構造（Tier 1 / Tier 2 / Tier 3）を理解する
• traceroute、ping、tcpdump 等のツールで通信経路を解析できる
• DNS 解決から Web ページ表示までの全工程を追跡できる
• ネットワーク設計におけるアンチパターンを認識し、回避できる

前提知識

• コマンドライン（ターミナル）の基本操作
• IP アドレスの基礎概念（IPv4 / IPv6 の表記方法）
• TCP/UDP の存在を知っている程度で十分

1. インターネットとは何か

1.1 歴史的背景

インターネットの起源は 1969 年の ARPANET に遡る。米国国防総省の高等研究計画局（DARPA）が資金提供し、カリフォルニア大学ロサンゼルス校（UCLA）、スタンフォード研究所（SRI）、カリフォルニア大学サンタバーバラ校（UCSB）、ユタ大学の 4 つのノードを接続したのが始まりである。

ARPANET の発展タイムライン:

1969年  ARPANET 開始（4ノード）
  │
1973年  TCP/IP の原型が提案（Vint Cerf & Bob Kahn）
  │
1983年  ARPANET が NCP から TCP/IP に移行（"Flag Day"）
  │      → この日がインターネットの「誕生日」とされる
  │
1986年  NSFNET 稼働開始（学術ネットワークのバックボーン）
  │
1991年  CERN で WWW 公開（Tim Berners-Lee）
  │
1993年  Mosaic ブラウザ登場 → 一般ユーザーの利用拡大
  │
1995年  NSFNET 廃止 → 商用インターネットへ完全移行
  │
1998年  Google 設立 / ICANN 設立
  │
2004年  Web 2.0 時代（SNS、UGC の爆発的増加）
  │
2010年代 モバイルインターネットが主流に
  │
2020年代 5G / エッジコンピューティング / IoT の時代

ARPANET の設計思想で特筆すべきは「分散型」というコンセプトである。冷戦下、中央集権的な通信システムは核攻撃に対して脆弱であった。一箇所が破壊されても通信が継続できるネットワーク――これがパケット交換方式の採用につながり、現在のインターネットの根幹を成している。

1.2 インターネットの定義

インターネットは、技術的には以下の要素の組み合わせとして定義される。

1. プロトコルスイート: TCP/IP を共通言語として使用する
2. 相互接続: 独立したネットワーク（AS: Autonomous System）が互いに接続する
3. 分散管理: 単一の管理者は存在せず、ICANN、IETF、各国 NIC 等が役割を分担する
4. エンドツーエンド原則: ネットワークの知性はエッジ（端末）に置き、コアネットワークはシンプルに保つ

インターネットの概念モデル:

│                    │                    │
          └────────────┬───────┘────────────┬──────┘
                       │                    │

AS = Autonomous System（自律システム）
   各 AS は独自のルーティングポリシーを持つ
   BGP で AS 間の経路情報を交換する

1.3 数字で見るインターネットの規模

2. インターネットの物理構造

2.1 階層的なネットワーク接続

インターネットは論理的にも物理的にも階層構造を持っている。この階層を理解することは、遅延の原因特定やネットワーク設計において極めて重要である。

ISP 階層構造（ASCII 図解）:

│      │

│         │                       │      │

│         │                     │         │
      [家庭]    [企業]               [家庭]     [企業]

Tier 1: トランジット料金を一切支払わない
        → ピアリング（相互接続）のみで全インターネットに到達可能
        → 世界に約15社程度

Tier 2: Tier 1 にトランジット料金を支払う
        → 一部のネットワークとはピアリング
        → 地域的なカバレッジを持つ

Tier 3: Tier 2 にトランジット料金を支払う
        → エンドユーザーに直接サービスを提供
        → 地域密着型のプロバイダ

2.2 トランジットとピアリング

ISP 間の接続形態は大きく2つに分類される。

トランジット（Transit）: 上位 ISP に料金を支払い、その ISP を経由してインターネット全体にアクセスする関係。顧客-プロバイダの関係。

ピアリング（Peering）: 同等の規模を持つ ISP 同士が、相互のトラフィックを無償で交換する関係。通常、IX（Internet Exchange Point）で物理的に接続する。

2.3 IX（Internet Exchange Point）

IX は複数の ISP が一箇所に集まり、トラフィックを直接交換する施設である。IX が存在しなければ、同じ都市内にあるサーバー同士の通信であっても、遠方の上位 ISP を経由する必要があり、遅延とコストが増大する。

日本における主要な IX:

• JPIX（Japan Internet Exchange）: 東京を拠点とする日本最大級の IX
• JPNAP（Japan Network Access Point）: インターネットマルチフィード社が運営
• BBIX: ソフトバンクグループが運営
• Equinix IX Tokyo: グローバル企業 Equinix が運営

IX における接続の仕組み:

   ISP-A ──┐                    ┌── ISP-D
            │    ┌──────────┐   │
   ISP-B ──┼────┤  IX      ├───┼── ISP-E
            │    │ スイッチ  │   │
   ISP-C ──┘    └──────────┘   └── ISP-F

   IX 内部のスイッチ（L2スイッチ）で全ISPが相互に接続可能
   各 ISP は IX のポートに自社のルーターを接続する
   BGP セッションを確立し、経路情報を交換する

   IX がない場合:
   ISP-A のユーザー → ISP-A → Tier1 → ISP-B → ISP-B のユーザー
                     （遠回り、高コスト、高遅延）

   IX がある場合:
   ISP-A のユーザー → ISP-A → IX → ISP-B → ISP-B のユーザー
                     （直接接続、低コスト、低遅延）

2.4 海底ケーブル

国際通信の 99% 以上は海底ケーブルによって運ばれている。衛星通信のイメージが強いかもしれないが、帯域幅と遅延の両面で海底ケーブルが圧倒的に優れている。

海底ケーブルの構造

海底ケーブルの断面図:

直径: 深海部で約17mm（浅瀬部はより太い）
        光ファイバー対数: 8〜24対が一般的
        リピーター間隔: 約60〜100km
        設計寿命: 25年
        敷設コスト: 1km あたり数万〜数十万ドル

海底ケーブル vs 衛星通信

主要な海底ケーブル（太平洋）

• FASTER: Google 等が出資。日本-米国間。容量 60 Tbps
• JUPITER: 日本-米国間。Amazon / Facebook 等が参加
• SJC2（Southeast Asia-Japan Cable 2）: 東南アジア-日本間
• APG（Asia Pacific Gateway）: アジア太平洋地域を結ぶ
• Unity: 日本-米国間。Google / KDDI 等

2.5 データセンターとクラウド

現代のインターネットにおいて、トラフィックの大部分はデータセンター間、またはデータセンターとエンドユーザー間で発生している。主要なクラウドプロバイダー（AWS、Google Cloud、Microsoft Azure）は世界中にデータセンターを展開し、それぞれが独自のバックボーンネットワークを持っている。

クラウドプロバイダーのネットワーク構成（概念図）:

   ユーザー
     │
     ▼
   ISP ── IX ──┐
               │

クラウドプロバイダーは:
   - 自社専用の海底ケーブルを保有/リース
   - IX に直接接続して遅延を最小化
   - 各リージョン間を専用回線で結ぶ
   - CDN エッジサーバーを ISP 内に配置（PNI: Private Network Interconnect）

3. パケット通信の詳細

3.1 回線交換 vs パケット交換

インターネット以前の電話網は「回線交換（Circuit Switching）」方式を採用していた。これは通話の間、発信者から受信者まで専用の物理回線を確保する方式である。一方、インターネットは「パケット交換（Packet Switching）」方式を採用している。

回線交換（Circuit Switching）:

   電話A ═══════════════════════════ 電話B
          （通話中は専用回線を占有）
          （無言の時間も回線は使用中）

   利点: 一定の品質保証、遅延が安定
   欠点: 回線の無駄遣い、スケールしにくい

パケット交換（Packet Switching）:

   PC-A ──┐  [pkt1] [pkt3]          ┌── PC-B
          │    ↓      ↓             │
          ├── Router ── Router ── Router ──┤
          │    ↑                     │
   PC-C ──┘  [pkt2]                 └── PC-D

   利点: 回線の効率的共有、スケーラブル、障害耐性
   欠点: 遅延が変動（ジッター）、パケットロスの可能性

3.2 パケットの構造

パケットはヘッダーとペイロード（データ本体）で構成される。TCP/IP モデルにおいて、各層がそれぞれのヘッダーを追加する。これを「カプセル化（Encapsulation）」と呼ぶ。

カプセル化の過程:

アプリケーション層:
  [HTTP データ: "GET / HTTP/1.1\r\nHost: example.com\r\n\r\n"]

  ↓ TCP がヘッダーを追加

トランスポート層:
  [TCP ヘッダー][HTTP データ]
  ├─ 送信元ポート: 54321
  ├─ 宛先ポート: 80
  ├─ シーケンス番号: 1000
  ├─ ACK 番号: 0
  ├─ フラグ: SYN
  └─ ウィンドウサイズ: 65535

  ↓ IP がヘッダーを追加

ネットワーク層:
  [IP ヘッダー][TCP ヘッダー][HTTP データ]
  ├─ バージョン: 4 (IPv4)
  ├─ ヘッダー長: 20 bytes
  ├─ 全長: 60 bytes
  ├─ TTL: 64
  ├─ プロトコル: 6 (TCP)
  ├─ 送信元IP: 192.168.1.100
  └─ 宛先IP: 93.184.216.34

  ↓ イーサネットがヘッダーとトレーラーを追加

データリンク層:
  [Ethernet ヘッダー][IP ヘッダー][TCP ヘッダー][HTTP データ][FCS]
  ├─ 宛先MAC: AA:BB:CC:DD:EE:FF
  ├─ 送信元MAC: 11:22:33:44:55:66
  ├─ タイプ: 0x0800 (IPv4)
  └─ FCS: フレームチェックシーケンス（誤り検出用）

最終的なフレームサイズ:
  Ethernet ヘッダー: 14 bytes
  IP ヘッダー:       20 bytes
  TCP ヘッダー:      20 bytes
  HTTP データ:       可変（MTU 1500 の場合、最大 1460 bytes）
  FCS:              4 bytes

3.3 MTU とフラグメンテーション

MTU（Maximum Transmission Unit）は、1つのフレームで送信できるデータの最大サイズである。イーサネットの標準 MTU は 1500 バイトだが、経路上に MTU が小さいリンクがあると、パケットが分割（フラグメンテーション）される。

フラグメンテーションの例:

送信側が 3000 バイトの IP パケットを送信
MTU = 1500 のリンクに到達

  元のパケット:
  [IP ヘッダー(20)][データ(2980)]  = 3000 bytes

  フラグメント1:
  [IP ヘッダー(20)][データ(1480)]  = 1500 bytes
  ├─ MF (More Fragments) フラグ: 1
  └─ Fragment Offset: 0

  フラグメント2:
  [IP ヘッダー(20)][データ(1480)]  = 1500 bytes
  ├─ MF フラグ: 1
  └─ Fragment Offset: 185 (= 1480/8)

  フラグメント3:
  [IP ヘッダー(20)][データ(20)]    = 40 bytes
  ├─ MF フラグ: 0 (最後のフラグメント)
  └─ Fragment Offset: 370 (= 2960/8)

  受信側で再組み立て（Identification フィールドで識別）

注意: IPv6 では中間ルーターによるフラグメンテーションが禁止されている。送信元で Path MTU Discovery を行い、適切なサイズでパケットを送信する必要がある。

3.4 パケット解析の実践（コード例1: tcpdump）

tcpdump は、ネットワークインターフェースを流れるパケットをキャプチャするコマンドラインツールである。パケットの中身を直接観察することで、通信の仕組みを深く理解できる。

# コード例1: tcpdump による HTTP パケットキャプチャ
 
# 基本的な使い方: TCP ポート 80 のパケットをキャプチャ
$ sudo tcpdump -i eth0 -n port 80
 
# 出力例:
# 14:23:01.123456 IP 192.168.1.100.54321 > 93.184.216.34.80:
#   Flags [S], seq 1000, win 65535, options [mss 1460,sackOK,TS val 123 ecr 0],
#   length 0
# 14:23:01.234567 IP 93.184.216.34.80 > 192.168.1.100.54321:
#   Flags [S.], seq 2000, ack 1001, win 65535, options [mss 1460,sackOK,TS val 456 ecr 123],
#   length 0
# 14:23:01.234789 IP 192.168.1.100.54321 > 93.184.216.34.80:
#   Flags [.], ack 2001, win 65535, length 0
 
# フラグの意味:
# [S]  = SYN（接続要求）
# [S.] = SYN-ACK（接続応答）
# [.]  = ACK（確認応答）
# [P.] = PSH-ACK（データ送信+確認）
# [F.] = FIN-ACK（接続終了）
# [R]  = RST（接続リセット）
 
# より詳細なオプション:
# -X: パケットの中身を16進数とASCIIで表示
$ sudo tcpdump -i eth0 -n -X port 80
 
# 出力例（HTTP GET リクエスト）:
# 14:23:01.345678 IP 192.168.1.100.54321 > 93.184.216.34.80:
#   Flags [P.], seq 1001:1078, ack 2001, win 65535, length 77
#   0x0000:  4500 0075 1234 4000 4006 abcd c0a8 0164
#   0x0010:  5db8 d822 d431 0050 0000 03e9 0000 07d1
#   0x0020:  5018 ffff 1234 0000 4745 5420 2f20 4854
#   0x0030:  5450 2f31 2e31 0d0a 486f 7374 3a20 6578
#   0x0040:  616d 706c 652e 636f 6d0d 0a0d 0a
#            G  E  T     /     H  T  T  P  /  1  .  1
#            H  o  s  t  :     e  x  a  m  p  l  e  .  c  o  m
 
# pcap ファイルに保存して後から Wireshark で解析
$ sudo tcpdump -i eth0 -n -w capture.pcap port 80
# → Wireshark で capture.pcap を開くと GUI で詳細分析が可能

3.5 パケットの一生: 送信から受信まで

あるユーザーが https://example.com にアクセスしたとき、パケットがどのような旅をするのかを追跡する。

パケットの旅路（詳細版）:

Step 1: アプリケーション（ブラウザ）
  ├─ URL を解析: プロトコル=HTTPS, ホスト=example.com, パス=/
  ├─ DNS 解決を要求（後述のセクション 5 で詳細解説）
  └─ TCP 接続を開始

Step 2: OS のネットワークスタック
  ├─ ソケット API 経由でデータを受け取る
  ├─ TCP セグメントを生成（ポート番号、シーケンス番号を付与）
  ├─ IP パケットを生成（送信元/宛先 IP を付与）
  ├─ ルーティングテーブルを参照 → 次のホップを決定
  ├─ ARP で次のホップの MAC アドレスを解決
  └─ イーサネットフレームを生成

Step 3: NIC（ネットワークインターフェースカード）
  ├─ フレームを電気信号（有線）or 電波（無線）に変換
  └─ 物理媒体に送出

Step 4: 家庭用ルーター
  ├─ フレームを受信 → IP パケットを取り出す
  ├─ NAT テーブルを参照（プライベート IP → グローバル IP に変換）
  ├─ 新しい IP パケットを生成
  └─ ISP 向けインターフェースから送出

Step 5: ISP のネットワーク
  ├─ 複数のルーターを経由
  ├─ 各ルーターでルーティングテーブルを参照
  ├─ BGP によって決定された最適経路を選択
  └─ 次の ISP または IX へ転送

Step 6: IX（Internet Exchange Point）
  ├─ L2 スイッチでフレームを転送
  └─ 宛先の AS に所属するルーターへ到達

Step 7: 宛先ネットワーク
  ├─ ファイアウォールで検査（許可/拒否）
  ├─ ロードバランサーで適切なサーバーに振り分け
  └─ サーバーの NIC に到達

Step 8: サーバーの OS
  ├─ フレームから IP パケットを取り出す
  ├─ IP パケットから TCP セグメントを取り出す
  ├─ TCP セグメントからアプリケーションデータを取り出す
  └─ アプリケーション（Web サーバー）にデータを渡す

Step 9: アプリケーション（Web サーバー）
  ├─ HTTP リクエストを解釈
  ├─ HTML コンテンツを生成
  └─ レスポンスを返す（逆の経路をたどる）

4. ルーティングの原理

4.1 ルーティングとは

ルーティングとは、パケットを送信元から宛先へ届けるための経路選択プロセスである。各ルーターは「ルーティングテーブル」と呼ばれる経路情報のデータベースを保持し、パケットが到着するたびにテーブルを参照して次のホップ（転送先）を決定する。

4.2 スタティックルーティング vs ダイナミックルーティング

スタティックルーティング:
  → 管理者が手動で経路を設定
  → 小規模ネットワーク向け
  → 設定例:
    ip route 10.0.0.0/8 via 192.168.1.1
    ip route 172.16.0.0/12 via 192.168.1.2
    ip route 0.0.0.0/0 via 192.168.1.254  (デフォルトルート)

ダイナミックルーティング:
  → ルーティングプロトコルが自動で経路を学習・更新
  → 大規模ネットワーク向け
  → 障害時に自動で経路を切り替え（コンバージェンス）

4.3 ルーティングプロトコルの分類

4.4 BGP（Border Gateway Protocol）の詳細

BGP はインターネットのルーティングを支える最も重要なプロトコルである。約 75,000 の AS がBGP を使って経路情報を交換し、インターネット全体の到達性を維持している。

BGP の動作原理:

1. BGP ピアリングの確立
   AS 65001 のルーター ←── TCP port 179 ──→ AS 65002 のルーター
   │                                         │
   ├─ OPEN メッセージ交換                     │
   ├─ KEEPALIVE で生存確認（60秒間隔）        │
   └─ UPDATE メッセージで経路情報を交換        │

2. 経路情報の伝播
   AS 65001 が 10.1.0.0/16 を広告:

   AS 65001 ──→ AS 65002 ──→ AS 65003
   "10.1.0.0/16   "10.1.0.0/16   "10.1.0.0/16
    AS_PATH:       AS_PATH:        AS_PATH:
    65001"         65002,65001"    65003,65002,65001"

   → AS_PATH が長くなるほど「遠い」と判断される
   → ループ検出: 自分の AS 番号が AS_PATH にあれば破棄

3. 最適経路の選択（BGP ベストパス選択アルゴリズム）:
   ① LOCAL_PREF が最大（ローカルポリシー優先）
   ② AS_PATH が最短
   ③ ORIGIN タイプ（IGP > EGP > Incomplete）
   ④ MED（Multi-Exit Discriminator）が最小
   ⑤ eBGP > iBGP
   ⑥ IGP メトリックが最小（ネクストホップへの距離）
   ⑦ ルーター ID が最小

4.5 コード例2: ルーティングテーブルの確認

# コード例2: ルーティングテーブルの確認と解析
 
# Linux でルーティングテーブルを表示
$ ip route show
# 出力例:
# default via 192.168.1.1 dev eth0 proto dhcp metric 100
# 10.0.0.0/8 via 192.168.1.254 dev eth0 proto static metric 50
# 172.16.0.0/12 via 192.168.1.253 dev eth0 proto static metric 50
# 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100
 
# macOS でルーティングテーブルを表示
$ netstat -rn
# 出力例:
# Routing tables
#
# Internet:
# Destination        Gateway            Flags    Netif
# default            192.168.1.1        UGScg    en0
# 10.0.0.0/8         192.168.1.254      UGSc     en0
# 127.0.0.1          127.0.0.1          UH       lo0
# 192.168.1.0/24     link#4             UCS      en0
# 192.168.1.1        aa:bb:cc:dd:ee:ff  UHLWIir  en0
# 192.168.1.100      127.0.0.1          UHS      lo0
 
# 各フィールドの意味:
# Destination: 宛先ネットワーク
# Gateway:     次のホップ（転送先のルーター）
# Flags:
#   U = Up（有効）
#   G = Gateway（ルーター経由）
#   S = Static（静的ルート）
#   H = Host（ホストルート）
#   C = Clone（新しい接続時にクローン）
# Netif: 使用するネットワークインターフェース
 
# 特定の宛先への経路を確認
$ ip route get 8.8.8.8
# 出力例:
# 8.8.8.8 via 192.168.1.1 dev eth0 src 192.168.1.100 uid 1000
#     cache

5. DNS 解決の仕組み

5.1 DNS とは

DNS（Domain Name System）は、人間が読みやすいドメイン名（例: example.com）を IP アドレス（例: 93.184.216.34）に変換するシステムである。「インターネットの電話帳」とも呼ばれる。

5.2 DNS の階層構造

DNS の階層構造:

                    ┌──────────────┐
                    │  ルート DNS  │  ← 全 13 クラスタ（a〜m.root-servers.net）
                    │  サーバー    │     Anycast で世界中に数百台が分散
                    └──────┬───────┘

│

│               │

DNS 解決の手順（再帰クエリ）:

  ブラウザ → OS のリゾルバ → ISP のキャッシュ DNS
                                    │
                         キャッシュヒット？
                            │          │
                           Yes         No
                            │          │
                         即座に応答    ルート DNS に問い合わせ
                                       │
                                    ".com はここ" と応答
                                       │
                                    .com TLD DNS に問い合わせ
                                       │
                                    "example.com はここ" と応答
                                       │
                                    権威 DNS に問い合わせ
                                       │
                                    "93.184.216.34" と応答
                                       │
                                    キャッシュに保存（TTL 期間）
                                       │
                                    クライアントに応答

5.3 コード例3: DNS 解決の確認

# コード例3: DNS 解決の詳細確認
 
# dig コマンドで DNS クエリを実行
$ dig example.com
 
# 出力例:
# ;; QUESTION SECTION:
# ;example.com.                   IN      A
#
# ;; ANSWER SECTION:
# example.com.            86400   IN      A       93.184.216.34
#
# ;; Query time: 23 msec
# ;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
 
# トレース付きで DNS 解決の全過程を確認
$ dig +trace example.com
 
# 出力例:
# .                       518400  IN      NS      a.root-servers.net.
# .                       518400  IN      NS      b.root-servers.net.
# ...
# com.                    172800  IN      NS      a.gtld-servers.net.
# com.                    172800  IN      NS      b.gtld-servers.net.
# ...
# example.com.            172800  IN      NS      a.iana-servers.net.
# example.com.            172800  IN      NS      b.iana-servers.net.
# ...
# example.com.            86400   IN      A       93.184.216.34
 
# 各レコードタイプの確認
$ dig example.com A        # IPv4 アドレス
$ dig example.com AAAA     # IPv6 アドレス
$ dig example.com MX       # メールサーバー
$ dig example.com NS       # ネームサーバー
$ dig example.com TXT      # テキストレコード（SPF, DKIM 等）
$ dig example.com CNAME    # 別名
 
# nslookup でも同等の情報が取得可能
$ nslookup example.com
# Server:   192.168.1.1
# Address:  192.168.1.1#53
#
# Non-authoritative answer:
# Name: example.com
# Address: 93.184.216.34
 
# DNS キャッシュの確認（macOS）
$ sudo dscacheutil -statistics
# → キャッシュヒット率を確認可能
 
# DNS キャッシュのクリア（macOS）
$ sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

6. 通信経路の可視化と解析

6.1 コード例4: traceroute による経路追跡

traceroute は、パケットが宛先に到達するまでに経由するルーター（ホップ）を一覧表示するツールである。TTL（Time To Live）を 1 から順に増やしながら ICMP パケット（または UDP パケット）を送信し、各ルーターから返される ICMP Time Exceeded メッセージを利用して経路を特定する。

# コード例4: traceroute の実行と解析
 
# 基本的な使い方（Linux/macOS）
$ traceroute example.com
 
# 出力例:
# traceroute to example.com (93.184.216.34), 30 hops max, 60 byte packets
#  1  router.local (192.168.1.1)  1.234 ms  0.987 ms  1.123 ms
#  2  gw-001.isp.example.net (203.0.113.1)  5.678 ms  5.432 ms  5.891 ms
#  3  core-r01.tokyo.isp.net (198.51.100.1)  8.123 ms  7.987 ms  8.234 ms
#  4  ix-peer.jpix.ad.jp (192.0.2.1)  10.456 ms  10.234 ms  10.567 ms
#  5  edge-r01.datacenter.net (192.0.2.100)  15.789 ms  15.432 ms  15.678 ms
#  6  cdn-node.example.com (93.184.216.34)  18.012 ms  17.890 ms  18.123 ms
 
# 各列の意味:
# ホップ番号  ホスト名 (IPアドレス)  RTT1  RTT2  RTT3
# → 3回の RTT（Round Trip Time）が表示される
# → ばらつきが大きい場合、そのルーターが混雑している可能性
 
# * * * が表示される場合:
# → そのルーターが ICMP に応答しない設定（セキュリティポリシー）
# → パケットフィルタリングされている
# → 必ずしも問題があるわけではない
 
# TCP SYN を使った traceroute（ファイアウォール透過に有効）
$ sudo traceroute -T -p 443 example.com
 
# ICMP Echo を使った traceroute
$ sudo traceroute -I example.com
 
# Windows の場合は tracert コマンド
# > tracert example.com
 
# mtr（My Traceroute）: traceroute + ping のリアルタイム版
$ mtr example.com
 
# mtr の出力例:
#                              My traceroute  [v0.95]
# Host:                                Loss%   Snt   Last   Avg  Best  Wrst StDev
#  1. router.local                      0.0%    50    1.2   1.3   0.8   2.1   0.3
#  2. gw-001.isp.example.net            0.0%    50    5.4   5.6   5.1   6.8   0.4
#  3. core-r01.tokyo.isp.net            0.0%    50    8.1   8.3   7.8   9.2   0.3
#  4. ix-peer.jpix.ad.jp                0.0%    50   10.3  10.5  10.0  11.8   0.4
#  5. cdn-node.example.com              0.0%    50   18.0  18.2  17.5  19.1   0.4
 
# mtr の利点:
# - リアルタイムで統計情報が更新される
# - パケットロス率が可視化される
# - 遅延の変動（ジッター）が分かる
# - -r オプションでレポートモード（非対話型）
$ mtr -r -c 100 example.com

traceroute の動作原理

traceroute の内部動作:

Step 1: TTL=1 のパケットを送信
  PC ──[TTL=1]──→ Router-A ──X（TTL が 0 になり破棄）
                   │
                   └── ICMP Time Exceeded を返送
                       → Router-A の IP アドレスと RTT が判明

Step 2: TTL=2 のパケットを送信
  PC ──[TTL=2]──→ Router-A ──[TTL=1]──→ Router-B ──X
                                          │
                                          └── ICMP Time Exceeded を返送
                                              → Router-B の IP と RTT が判明

Step 3: TTL=3 のパケットを送信
  PC ──[TTL=3]──→ Router-A ──[TTL=2]──→ Router-B ──[TTL=1]──→ Server
                                                                │
                                                                └── ICMP Port Unreachable
                                                                    (or TCP RST) を返送
                                                                    → 宛先に到達したことを確認

  → TTL を 1 ずつ増やすことで、各ホップのルーターを順番に特定する
  → 最大ホップ数（デフォルト 30）に達しても応答がなければ終了

6.2 コード例5: ping による疎通確認と統計解析

# コード例5: ping の高度な使い方
 
# 基本的な ping（4回送信）
$ ping -c 4 example.com
# PING example.com (93.184.216.34): 56 data bytes
# 64 bytes from 93.184.216.34: icmp_seq=0 ttl=56 time=95.123 ms
# 64 bytes from 93.184.216.34: icmp_seq=1 ttl=56 time=94.876 ms
# 64 bytes from 93.184.216.34: icmp_seq=2 ttl=56 time=95.234 ms
# 64 bytes from 93.184.216.34: icmp_seq=3 ttl=56 time=94.987 ms
#
# --- example.com ping statistics ---
# 4 packets transmitted, 4 packets received, 0.0% packet loss
# round-trip min/avg/max/stddev = 94.876/95.055/95.234/0.131 ms
 
# 統計情報の読み方:
# min:    最小 RTT（ネットワークが空いているときの遅延）
# avg:    平均 RTT（通常の遅延の目安）
# max:    最大 RTT（混雑時の遅延）
# stddev: 標準偏差（ジッター: 値が大きいほど遅延が不安定）
 
# パケットサイズを指定して MTU 問題を診断
$ ping -c 4 -s 1472 example.com          # 1472 + 28 (IP+ICMP header) = 1500
$ ping -c 4 -s 1473 -D example.com       # DF ビットを設定（フラグメント禁止）
# → "Message too long" が返れば、経路上の MTU が 1500 未満
 
# フラッド ping（高負荷テスト: root 権限が必要）
$ sudo ping -f -c 1000 example.com
# → 大量のパケットを高速送信し、パケットロス率を計測
# → 本番環境では絶対に実行しないこと
 
# 送信間隔を指定（0.2秒間隔で10回）
$ ping -c 10 -i 0.2 example.com
 
# タイムスタンプ付き（障害の時刻特定に有用）
$ ping -c 100 example.com | while read line; do
>   echo "$(date '+%Y-%m-%d %H:%M:%S') $line"
> done
 
# 複数ホストへの同時 ping（fping）
$ fping -c 5 8.8.8.8 1.1.1.1 208.67.222.222
# 8.8.8.8     : [0], 84 bytes, 5.12 ms
# 1.1.1.1     : [0], 84 bytes, 3.45 ms
# 208.67.222.222 : [0], 84 bytes, 12.34 ms

6.3 ネットワーク遅延の構成要素

ネットワーク遅延は複数の要素から構成される。それぞれの寄与を理解することで、問題の切り分けが容易になる。

遅延の計算例:

東京のクライアント → ロサンゼルスのサーバー

伝搬遅延（片道）:
  距離: 約 8,800 km（海底ケーブル経由）
  光ファイバー中の光速: 約 200,000 km/s
  伝搬遅延 = 8,800 / 200,000 = 44 ms

RTT（往復遅延）:
  理論最小値 = 44 ms × 2 = 88 ms

  実際の値（ルーター処理等を含む）:
  → 約 100〜120 ms が典型的
  → 理論値との差分（12〜32 ms）がルーター処理+キューイング遅延

7. Web ページ表示の全工程

7.1 URL 入力からレンダリングまで

ブラウザで https://example.com にアクセスしたとき、以下の一連のプロセスが実行される。

Web ページ表示の全工程タイムライン:

    時間(ms)  イベント
    ─────────────────────────────────────────────────
    0         ユーザーが Enter キーを押す
    │
    ├── 1. ブラウザキャッシュ確認 (< 1 ms)
    │   └── キャッシュヒットならここで終了
    │
    ├── 2. DNS 解決 (20-100 ms)
    │   ├── ブラウザ DNS キャッシュ
    │   ├── OS DNS キャッシュ
    │   ├── ルーター DNS キャッシュ
    │   └── ISP DNS リゾルバ → 権威 DNS
    │
    ├── 3. TCP 3-way ハンドシェイク (1 RTT = 30-100 ms)
    │   ├── Client → Server: SYN
    │   ├── Server → Client: SYN-ACK
    │   └── Client → Server: ACK
    │
    ├── 4. TLS ハンドシェイク (1-2 RTT = 30-200 ms)
    │   ├── ClientHello（対応する暗号スイートの提示）
    │   ├── ServerHello（暗号スイートの選択+証明書送信）
    │   ├── 証明書検証（CA チェーンの確認）
    │   ├── 鍵交換（ECDHE 等で共有秘密を確立）
    │   └── Finished（暗号化通信の開始）
    │   ※ TLS 1.3 では 1-RTT（再接続時は 0-RTT も可能）
    │
    ├── 5. HTTP リクエスト送信
    │   GET / HTTP/2
    │   Host: example.com
    │   Accept: text/html
    │   Accept-Encoding: gzip, br
    │
    ├── 6. サーバー処理 (10-500 ms)
    │   ├── リクエストのパース
    │   ├── ルーティング
    │   ├── ビジネスロジック実行
    │   ├── DB クエリ（必要に応じて）
    │   └── レスポンス生成
    │
    ├── 7. HTTP レスポンス受信
    │   HTTP/2 200 OK
    │   Content-Type: text/html; charset=utf-8
    │   Content-Encoding: br
    │   Cache-Control: max-age=3600
    │
    ├── 8. HTML パース & DOM 構築 (50-200 ms)
    │   ├── HTML トークナイズ
    │   ├── DOM ツリー構築
    │   ├── サブリソースの発見（CSS, JS, 画像）
    │   └── プリロードスキャナーが並行してリソースを取得開始
    │
    ├── 9. CSS パース & CSSOM 構築
    │   ├── CSS ファイルのダウンロード
    │   ├── CSSOM ツリー構築
    │   └── Render Tree = DOM + CSSOM
    │
    ├── 10. JavaScript 実行
    │    ├── JS ファイルのダウンロード
    │    ├── パース & コンパイル
    │    ├── 実行（DOM 操作、イベントリスナー登録等）
    │    └── defer/async 属性による実行タイミングの制御
    │
    ├── 11. レイアウト計算 (Layout/Reflow)
    │    ├── 各要素の位置とサイズを計算
    │    └── ビューポートに基づくレイアウト
    │
    ├── 12. ペイント & コンポジット
    │    ├── レイヤーごとにピクセルを描画
    │    ├── GPU によるコンポジット
    │    └── 画面に表示
    │
    ─────────────────────────────────────────────────
    合計: 200 ms 〜 数秒（ネットワーク環境とページ複雑度に依存）

7.2 HTTP/1.1 vs HTTP/2 vs HTTP/3

8. NAT（Network Address Translation）

8.1 NAT の仕組み

NAT は、プライベート IP アドレスとグローバル IP アドレスを変換する技術である。IPv4 アドレスの枯渇に対する最も広く普及した対策として、ほぼすべての家庭用ルーターに実装されている。

NAT の動作:

  プライベートネットワーク           インターネット
  192.168.1.0/24

  PC-A (192.168.1.100)  ──┐
                          │   ┌──────────────┐      ┌──────────────┐
  PC-B (192.168.1.101)  ──┼───┤  NAT Router  ├──────┤   Server     │
                          │   │  203.0.113.1 │      │ 93.184.216.34│
  PC-C (192.168.1.102)  ──┘   └──────────────┘      └──────────────┘

NAT テーブルの例:

動作の流れ:
1. PC-A が 93.184.216.34:443 にパケットを送信
   送信元: 192.168.1.100:54321 → 宛先: 93.184.216.34:443

2. NAT ルーターがテーブルにエントリを作成
   送信元を 203.0.113.1:10001 に書き換え

3. サーバーがレスポンスを返送
   送信元: 93.184.216.34:443 → 宛先: 203.0.113.1:10001

4. NAT ルーターがテーブルを参照して宛先を書き換え
   宛先を 192.168.1.100:54321 に復元

5. PC-A にパケットが到着

8.2 NAT の種類

8.3 NAT と IPv6

IPv6 の本来の設計では、すべてのデバイスにグローバルユニキャストアドレスを割り当てることで NAT を不要にする意図がある。しかし、セキュリティポリシーの慣習やプライバシー上の理由から、IPv6 環境でもステートフルファイアウォールやプライバシーアドレス（RFC 4941）が利用される。

IPv4 vs IPv6 のアドレス空間:

IPv4: 32 ビット = 約 43 億アドレス
  → 90年代後半に枯渇が予測され、NAT + CIDR で延命
  → 2011年に IANA が最後の /8 ブロックを配布

IPv6: 128 ビット = 約 3.4 × 10^38 アドレス
  → 地球上の全砂粒（約 7.5 × 10^18 個）の一粒一粒に
     数千万個のアドレスを割り当てても余る
  → NAT なしで全デバイスにグローバルアドレスを付与可能

IPv6 アドレスの例:
  2001:0db8:85a3:0000:0000:8a2e:0370:7334
  → 省略表記: 2001:db8:85a3::8a2e:370:7334

9. CDN（Content Delivery Network）

9.1 CDN の仕組み

CDN は、コンテンツをユーザーに物理的に近いエッジサーバーから配信することで、遅延を短縮し、オリジンサーバーの負荷を軽減する技術である。

CDN なしの場合:

  東京のユーザー ──────────── 米国のオリジンサーバー
                  RTT: 100ms
                  全リクエストがオリジンに到達

CDN ありの場合:

  東京のユーザー ── 東京の CDN エッジ ──── 米国のオリジン
                   RTT: 5ms              （キャッシュミス時のみ）

CDN の配置:

│

│              │               │
         [東京の       [US西海岸の      [欧州の
          ユーザー]     ユーザー]        ユーザー]

9.2 CDN のリクエスト処理フロー

1. ユーザーが www.example.com を DNS 解決
2. CDN の DNS が地理的に最も近いエッジサーバーの IP を返す（GeoDNS / Anycast）
3. ユーザーのリクエストがエッジサーバーに到達
4. エッジサーバーがキャッシュを確認:
   • キャッシュヒット: 即座にレスポンスを返す（数 ms）
   • キャッシュミス: オリジンサーバーにリクエストを転送し、レスポンスをキャッシュしてから返す

10. アンチパターン

10.1 アンチパターン1: 単一障害点（SPOF）を持つネットワーク設計

アンチパターン: 単一の ISP 接続

  [全社ネットワーク]
         │

    ┌────┴────┐
    │ Router  │  ← 単一のルーター
    └────┬────┘

│
    [ISP-A のみ]  ← 単一の ISP 接続
         │
    [インターネット]

問題点:
  - ISP-A に障害が発生すると全通信が停止
  - ルーターが故障しても全通信が停止
  - メンテナンスウィンドウでの計画停止が必要

推奨パターン: マルチホーミング + 冗長構成

  [全社ネットワーク]
       │       │

│         │
  [ISP-A]   [ISP-B]   ← マルチホーミング
      │         │
  [インターネット]

利点:
  - ISP-A の障害時に ISP-B が自動引き継ぎ
  - ルーター故障時にもう一方が引き継ぎ
  - 無停止メンテナンスが可能
  - トラフィック分散による性能向上

なぜ危険か

大規模な事例として、2021 年の Fastly CDN 障害では、設定ミスにより広範囲のWebサイト（Reddit、GitHub、Amazon 等）が約 1 時間ダウンした。2023 年の KDDI 障害では、設備故障から約 86 時間にわたりモバイル通信に影響が出た。単一障害点の排除は、システム設計における最優先事項の一つである。

10.2 アンチパターン2: DNS の TTL を極端に短くする（または長くする）

アンチパターン: TTL = 0 または TTL = 30 秒

問題点:
  - 全てのリクエストで DNS 解決が発生
  - DNS サーバーへの負荷が急増
  - DNS サーバーがダウンすると即座に名前解決不能
  - 初回アクセスの遅延が毎回発生

  1リクエストあたりの DNS 解決コスト:
  → キャッシュヒット: < 1 ms
  → フルリゾルブ:   50-200 ms
  → TTL=0 の場合、毎回 50-200 ms のオーバーヘッド

アンチパターン: TTL = 86400（24時間）以上

問題点:
  - IP アドレス変更時の反映が遅延
  - フェイルオーバーに最大 24 時間かかる
  - CDN 切り替えやサーバー移行が困難

推奨: TTL = 300〜3600 秒（5分〜1時間）

  用途に応じた推奨値:

なぜ危険か

TTL が短すぎると、DNS サーバーの負荷だけでなく、DNS プロバイダーの障害がサービス全体の障害に直結する。逆に TTL が長すぎると、緊急時のフェイルオーバーが機能しない。DDoS 攻撃を受けた際に IP アドレスを変更して回避する「IP ローテーション」も、TTL が長いと効果が薄れる。

11. エッジケース分析

11.1 エッジケース1: BGP ハイジャック

BGP は本質的に「信頼ベース」のプロトコルであり、受信した経路広告の正当性を検証する仕組みが弱い。悪意のある（または設定ミスによる）AS が、本来自分のものではないプレフィックスを広告すると、インターネットトラフィックが不正な経路に誘導される。

BGP ハイジャックの例:

正常な状態:
  AS 65001 が 10.1.0.0/16 を広告
  → インターネット全体が 10.1.0.0/16 → AS 65001 と認識

ハイジャック発生:
  AS 99999（攻撃者）が 10.1.0.0/24 を広告
  → 10.1.0.0/24 はより具体的なプレフィックス（/24 > /16）
  → ロンゲストマッチルールにより、10.1.0.0/24 宛のトラフィックが
     AS 99999 に吸い込まれる

  正常: ユーザー → ISP → AS 65001（正規のサーバー）
  異常: ユーザー → ISP → AS 99999（攻撃者のネットワーク）

対策:
  - RPKI（Resource Public Key Infrastructure）
    → プレフィックスと AS の対応を暗号的に検証
    → ROA（Route Origin Authorization）を登録
  - BGPsec
    → 経路の各ホップを暗号的に検証（普及途上）
  - IRR（Internet Routing Registry）フィルタリング
    → 登録された経路情報に基づくフィルタリング

現実の事例:
  - 2008年: パキスタンテレコムが YouTube のプレフィックスを誤広告
    → 約2時間、世界中で YouTube がアクセス不能に
  - 2018年: 仮想通貨 MyEtherWallet の BGP ハイジャック
    → DNS サーバーのトラフィックを乗っ取り、フィッシングサイトに誘導
  - 2019年: China Telecom による大規模な経路リーク
    → 欧州のトラフィックが中国経由に

11.2 エッジケース2: 海底ケーブルの切断

海底ケーブルは、錨（アンカー）による損傷、地震、海底地滑り、鮫の噛みつき等で物理的に切断されることがある。国際通信の 99% 以上を担う海底ケーブルが切断された場合の影響は甚大である。

海底ケーブル切断時の影響と対応:

切断パターン1: 単一ケーブルの切断

→ 影響: 帯域の減少、一時的な遅延増加
  → 冗長経路により通信は継続

切断パターン2: 同一海域の複数ケーブル切断（大地震等）

→ 影響: 深刻な帯域不足、通信速度の大幅低下
  → 衛星回線等のバックアップが必要になる場合も

復旧プロセス:
  1. ケーブル敷設船の手配（数日〜数週間）
  2. 切断箇所の特定（OTDR: 光時間領域反射計測）
  3. ケーブルの引き揚げ
  4. 修復接続（融着接続）
  5. テストと復旧
  → 全体で 2 週間〜数ヶ月を要する

現実の事例:
  - 2006年: 台湾南部地震で太平洋の複数ケーブルが切断
    → 東南アジア各国のインターネットが数週間にわたり不安定化
  - 2011年: 東日本大震災で太平洋側のケーブルに被害
    → 冗長経路と日本海側ケーブルにより大規模断絶は回避
  - 2024年: 紅海でフーシ派による海底ケーブル損傷の報告
    → 中東-欧州間の通信に影響

12. IPv4 と IPv6 の詳細比較

インターネットプロトコルの最も基本的なバージョンである IPv4 は、1981 年に RFC 791 として標準化された。約 43 億個のアドレス空間は、インターネットの爆発的な普及により枯渇が避けられなくなり、1998 年に RFC 2460 として IPv6 が標準化された。

12.1 IPv4 vs IPv6 の比較表

12.2 IPv6 アドレスの種類

IPv6 アドレスの種類と用途:

1. グローバルユニキャスト（2000::/3）
   → インターネット上でルーティング可能
   → IPv4 のグローバル IP に相当
   例: 2001:db8:85a3::8a2e:370:7334

2. リンクローカル（fe80::/10）
   → 同一リンク（セグメント）内のみで有効
   → 全ての IPv6 インターフェースに自動設定
   例: fe80::1%eth0

3. ユニークローカル（fc00::/7, 実質 fd00::/8）
   → プライベートネットワーク内で利用
   → IPv4 の RFC 1918 アドレスに相当
   例: fd12:3456:789a::1

4. マルチキャスト（ff00::/8）
   → 複数のホストに同時送信
   例: ff02::1 (全ノード), ff02::2 (全ルーター)

5. ループバック（::1/128）
   → 自分自身を指す
   → IPv4 の 127.0.0.1 に相当

6. 未指定（::/128）
   → アドレス未設定状態を示す
   → IPv4 の 0.0.0.0 に相当

13. ネットワークセキュリティの基礎

13.1 通信の暗号化

インターネット上の通信は、暗号化しない限り途中経路で盗聴される危険性がある。TLS（Transport Layer Security）は、TCP 上で暗号化通信を提供するプロトコルである。

TLS 1.3 ハンドシェイクの流れ:

Client                                          Server
  │                                               │
  │  ClientHello                                  │
  │  + supported_versions: TLS 1.3               │
  │  + key_share: ECDHE パラメータ                │
  │  + signature_algorithms: RSA-PSS, ECDSA      │
  │  ──────────────────────────────────────────►  │
  │                                               │
  │                          ServerHello          │
  │                + key_share: ECDHE パラメータ  │
  │        {EncryptedExtensions}                  │
  │        {Certificate}                          │
  │        {CertificateVerify}                    │
  │        {Finished}                             │
  │  ◄──────────────────────────────────────────  │
  │                                               │
  │  {Finished}                                   │
  │  ──────────────────────────────────────────►  │
  │                                               │
  │  ◄═══════ 暗号化されたアプリケーションデータ ═══►  │
  │                                               │

  ※ {} = 暗号化されたメッセージ
  ※ TLS 1.3 では 1-RTT で完了（TLS 1.2 は 2-RTT）
  ※ 0-RTT 再接続: 以前接続済みのサーバーに対して、
     最初のメッセージからデータを送信可能（リプレイ攻撃のリスクあり）

13.2 DDoS 攻撃の種類

DDoS 攻撃の規模の推移:

2013年: Spamhaus 攻撃 → 300 Gbps（当時最大）
2016年: Dyn DNS 攻撃（Mirai ボットネット）→ 1.2 Tbps
2017年: Google への攻撃 → 2.54 Tbps（2020年に公表）
2020年: AWS への攻撃 → 2.3 Tbps
2023年: Google / Cloudflare への HTTP/2 攻撃 → 398 Mrps（リクエスト/秒）
→ 攻撃規模は年々増大し、防御側の対策も進化し続けている

14. 演習問題

14.1 基礎演習

以下の演習を順番に実行し、インターネットの基本的な仕組みを体験的に理解する。

演習 B-1: ping による遅延計測

# 異なる地理的距離のサーバーに ping を送信し、遅延を比較する
 
# ステップ1: 近隣サーバーへの ping
$ ping -c 10 www.google.co.jp
# RTT を記録: _____ ms
 
# ステップ2: 太平洋を跨ぐサーバーへの ping
$ ping -c 10 www.google.com
# RTT を記録: _____ ms
 
# ステップ3: 大西洋を跨ぐサーバーへの ping
$ ping -c 10 www.bbc.co.uk
# RTT を記録: _____ ms
 
# 考察:
# 1. 各サーバーへの RTT の違いを物理的距離で説明せよ
# 2. 光速（光ファイバー中: 約 20 万 km/s）から理論最小 RTT を計算し、
#    観測値との差分の原因を考察せよ
# 3. 時間帯を変えて（朝/昼/夜）計測した場合、違いが出るか予測せよ

演習 B-2: DNS 解決の追跡

# ステップ1: 通常の DNS 解決
$ dig example.com
 
# ステップ2: トレース付き DNS 解決
$ dig +trace example.com
 
# ステップ3: 異なる DNS サーバーを使って解決
$ dig @8.8.8.8 example.com       # Google Public DNS
$ dig @1.1.1.1 example.com       # Cloudflare DNS
$ dig @208.67.222.222 example.com # OpenDNS
 
# 考察:
# 1. 各 DNS サーバーの応答時間を比較せよ
# 2. dig +trace で表示される各ステップ（ルート → TLD → 権威）の
#    所要時間を記録し、どこに最も時間がかかるか分析せよ
# 3. 同じクエリを2回実行した場合の応答時間の変化を説明せよ
#    （キャッシュの効果を確認する）

演習 B-3: ルーティングテーブルの理解

# ステップ1: 自分のマシンのルーティングテーブルを表示
# Linux:
$ ip route show
# macOS:
$ netstat -rn
 
# ステップ2: デフォルトゲートウェイを特定
# → default または 0.0.0.0/0 のエントリを探す
 
# ステップ3: 特定の IP アドレスへの経路を確認
$ ip route get 8.8.8.8
$ ip route get 192.168.1.1
 
# 考察:
# 1. デフォルトゲートウェイの IP アドレスは何か？
#    それはどのデバイス（ルーター）を指しているか？
# 2. 直接接続されたネットワーク（"scope link"）のエントリを特定せよ
# 3. 192.168.1.1 と 8.8.8.8 への経路はどう異なるか説明せよ

14.2 応用演習

基礎を理解した上で、より深い分析を行う演習である。

演習 A-1: traceroute の比較分析

# 異なる宛先への traceroute を実行し、経路の違いを分析する
 
# ステップ1: 国内サーバーへの traceroute
$ traceroute www.yahoo.co.jp
# ホップ数を記録: _____ ホップ
# 最終 RTT を記録: _____ ms
 
# ステップ2: 海外サーバーへの traceroute
$ traceroute www.google.com
# ホップ数を記録: _____ ホップ
# 最終 RTT を記録: _____ ms
 
# ステップ3: 別の海外サーバーへの traceroute
$ traceroute www.bbc.co.uk
# ホップ数を記録: _____ ホップ
# 最終 RTT を記録: _____ ms
 
# ステップ4: 経路上の各ルーターの所属を確認
# → IP アドレスを whois で調べる
$ whois 203.0.113.1 | grep -i "org-name\|netname\|descr"
 
# 分析項目:
# 1. 各 traceroute で、ISP の境界（AS 境界）がどこにあるか特定せよ
# 2. IX を通過しているホップを特定せよ（ホスト名のヒント: ix, peer, exchange 等）
# 3. 海底ケーブルを通過していると推測されるホップを特定せよ
#    （RTT が急増するポイント）
# 4. 同じ宛先に対して時間を空けて再度実行し、経路が変わるか確認せよ

演習 A-2: tcpdump によるパケット解析

# TCP 3-way ハンドシェイクをキャプチャし、パケットの中身を解析する
 
# ステップ1: tcpdump でキャプチャ開始（別ターミナルで実行）
$ sudo tcpdump -i any -n -v port 80 -w /tmp/capture.pcap &
 
# ステップ2: HTTP リクエストを送信
$ curl -v http://example.com
 
# ステップ3: キャプチャ停止
$ sudo kill %1
 
# ステップ4: キャプチャファイルの解析
$ tcpdump -r /tmp/capture.pcap -n -v
 
# 分析項目:
# 1. SYN パケットを特定し、以下の情報を抽出せよ:
#    - 送信元/宛先 IP アドレス
#    - 送信元/宛先ポート番号
#    - シーケンス番号
#    - ウィンドウサイズ
#    - TCP オプション（MSS, SACK, Window Scale 等）
# 2. SYN-ACK パケットから、サーバー側のシーケンス番号と
#    ウィンドウサイズを確認せよ
# 3. HTTP GET リクエストと HTTP レスポンスのサイズを確認せよ
# 4. FIN パケットによる接続終了プロセスを追跡せよ

演習 A-3: MTU 問題の診断

# Path MTU Discovery を手動で実行する
 
# ステップ1: DF ビット付きで段階的にパケットサイズを変えて ping
$ ping -c 1 -s 1472 -D example.com    # 1472 + 28 = 1500 (標準 MTU)
$ ping -c 1 -s 1473 -D example.com    # 1501 → フラグメント必要
$ ping -c 1 -s 8972 -D example.com    # 9000 (ジャンボフレーム用)
 
# ステップ2: バイナリサーチで正確な Path MTU を特定
# → 1472 で OK、1473 で NG の場合、Path MTU = 1500
 
# ステップ3: VPN やトンネル環境での MTU を確認
# → VPN 接続中に同じテストを実行
# → IPsec/GRE ヘッダーにより MTU が小さくなることを確認
 
# 考察:
# 1. 自分のネットワークの Path MTU はいくつか？
# 2. VPN 接続時とそうでない時で MTU は異なるか？
# 3. MTU 不一致が引き起こす症状（小さいパケットは通るが大きいパケットが
#    通らない: "黒い穴" 問題）を説明せよ

14.3 発展演習

ネットワークの設計や運用に踏み込んだ高度な演習である。

演習 D-1: BGP 経路情報の分析

# 公開 BGP データを使って、インターネットのルーティング構造を分析する
 
# ステップ1: RIPE RIS Looking Glass で BGP 経路を確認
# https://stat.ripe.net/ にアクセス
 
# ステップ2: コマンドラインから BGP 情報を取得
# bgpview.io の API を利用
$ curl -s "https://api.bgpview.io/ip/8.8.8.8" | python3 -m json.tool
# → Google (AS 15169) が広告しているプレフィックスを確認
 
$ curl -s "https://api.bgpview.io/asn/15169/prefixes" | python3 -m json.tool
# → AS 15169 が広告している全プレフィックスを確認
 
$ curl -s "https://api.bgpview.io/asn/15169/peers" | python3 -m json.tool
# → AS 15169 のピアリング相手を確認
 
# ステップ3: AS パスの分析
$ curl -s "https://api.bgpview.io/prefix/8.8.8.0/24" | python3 -m json.tool
# → 複数の視点からの AS パスを比較
 
# 分析項目:
# 1. Google (AS 15169) はどの AS とピアリングしているか？
# 2. 8.8.8.8 への AS パスは視点（観測地点）によってどう異なるか？
# 3. 自分が利用している ISP の AS 番号を特定し、その AS の
#    ピアリング関係を調査せよ
# 4. Tier 1 ISP の特徴（トランジット関係がない）を AS パスから確認せよ

演習 D-2: ネットワーク冗長設計の検討

以下のシナリオで、ネットワークの冗長設計を考案せよ。

シナリオ:
  - 東京と大阪にオフィスがある企業
  - 東京に主データセンター、大阪にDRサイト
  - インターネットへの接続は 1 Gbps が必要
  - 可用性目標: 99.99%（年間ダウンタイム 52 分以内）

検討事項:
  1. ISP の選択（何社契約するか、Tier はどうするか）
  2. 回線種別（専用線、広域イーサネット、インターネット VPN）
  3. ルーティングプロトコル（静的 vs BGP）
  4. フェイルオーバー方式（自動 vs 手動）
  5. DNS の冗長化（プライマリ/セカンダリ DNS、GeoDNS）
  6. CDN の利用（どのコンテンツを CDN にオフロードするか）

成果物:
  - ネットワーク構成図（ASCII でもツールでも可）
  - 各コンポーネントの障害シナリオと対応策の一覧表
  - コスト見積もり（概算）

演習 D-3: パケットキャプチャによる TLS ハンドシェイクの解析

# TLS 1.3 のハンドシェイクをキャプチャし、暗号化の確立過程を追跡する
 
# ステップ1: キャプチャ開始
$ sudo tcpdump -i any -n -v -w /tmp/tls_capture.pcap port 443 &
 
# ステップ2: HTTPS リクエストを送信
$ curl -v https://example.com
 
# ステップ3: キャプチャ停止
$ sudo kill %1
 
# ステップ4: tshark（Wireshark CLI 版）で TLS ハンドシェイクを解析
$ tshark -r /tmp/tls_capture.pcap -Y "tls.handshake" \
    -T fields -e frame.number -e ip.src -e ip.dst \
    -e tls.handshake.type -e tls.handshake.extensions.supported_version
 
# 出力例:
# 1  192.168.1.100  93.184.216.34  1  0x0304   (ClientHello, TLS 1.3)
# 2  93.184.216.34  192.168.1.100  2  0x0304   (ServerHello, TLS 1.3)
 
# ステップ5: 証明書チェーンの確認
$ openssl s_client -connect example.com:443 -showcerts 2>/dev/null | \
    openssl x509 -noout -text | head -30
 
# ステップ6: 使用されている暗号スイートの確認
$ openssl s_client -connect example.com:443 2>/dev/null | \
    grep -E "Protocol|Cipher"
 
# 分析項目:
# 1. ClientHello で提示された暗号スイートの一覧を確認せよ
# 2. サーバーが選択した暗号スイートは何か？
# 3. 鍵交換に使用されたアルゴリズム（ECDHE 等）を特定せよ
# 4. 証明書チェーンの構造（エンドエンティティ → 中間 CA → ルート CA）を
#    追跡せよ
# 5. TLS 1.3 と TLS 1.2 のハンドシェイクの往復回数の違いを
#    パケットキャプチャから確認せよ

15. インターネットの未来と新技術

15.1 QUIC プロトコル

QUIC（Quick UDP Internet Connections）は Google が開発し、IETF で標準化されたトランスポートプロトコルである。HTTP/3 の基盤として採用されている。

QUIC の主な特徴:

1. 接続確立の高速化
   TCP + TLS: 2-3 RTT → QUIC: 1 RTT（0-RTT 再接続も可能）

   TCP + TLS 1.3:
   Client ──SYN──────────► Server     ]
   Client ◄──SYN-ACK──── Server      ] 1 RTT (TCP)
   Client ──ACK+ClientHello──► Server ]
   Client ◄──ServerHello── Server     ] 1 RTT (TLS)
   Client ──Finished+Data──► Server   → 合計 2 RTT

   QUIC:
   Client ──Initial(ClientHello+Data)──► Server ]
   Client ◄──Initial(ServerHello)────── Server  ] 1 RTT
   Client ──Handshake(Finished)──────► Server   → 合計 1 RTT

2. Head-of-Line ブロッキングの解消
   TCP: 1つのパケットロスが全ストリームをブロック
   QUIC: パケットロスは該当ストリームのみに影響

3. コネクションマイグレーション
   TCP: IP アドレスが変わると接続が切れる（WiFi → モバイル切替時）
   QUIC: Connection ID で接続を識別するため、IP 変更でも接続継続

15.2 今後注目すべき技術

• Segment Routing（SR / SRv6）: MPLS に代わるネットワークプログラマビリティ技術
• SD-WAN: ソフトウェア定義による WAN の最適化と管理
• Network Slicing（5G）: 物理ネットワークを仮想的に分割して用途別に最適化
• RPKI の普及: BGP セキュリティの強化に向けた PKI インフラ
• Post-Quantum Cryptography: 量子コンピュータ耐性のある暗号アルゴリズムへの移行

16. FAQ（よくある質問）

FAQ 1: インターネットに「中央管理者」は存在するのか？

回答: 厳密には存在しない。ただし、いくつかの組織がインターネットの重要な側面を調整・管理している。

• ICANN（Internet Corporation for Assigned Names and Numbers）: ドメイン名と IP アドレスの割り当てを調整する非営利組織。ルート DNS サーバーの管理も担う。
• IETF（Internet Engineering Task Force）: インターネットの技術標準（RFC）を策定するオープンな標準化団体。誰でも参加可能。
• 各国 NIC / RIR: IP アドレスの地域割り当てを管理。APNIC（アジア太平洋）、ARIN（北米）、RIPE NCC（欧州）等。
• 各 ISP / AS 運用者: 自分の管轄ネットワーク内のルーティングとポリシーを独自に管理。

インターネットは本質的に「合意に基づく分散システム」であり、全参加者が TCP/IP という共通プロトコルを使用することで相互接続が成立している。

FAQ 2: 自分のパケットが具体的にどの海底ケーブルを通っているか調べられるか？

回答: 直接的には困難だが、間接的に推測することは可能である。

1. traceroute で経路上のルーターを特定: ルーターのホスト名や IP アドレスから、所属する ISP やデータセンターの地理的位置を推測できる。
2. RTT の急増ポイントを探す: 太平洋横断のホップでは RTT が 50-100 ms 程度急増する。この急増が海底ケーブル区間に対応する。
3. 公開情報の活用: TeleGeography の Submarine Cable Map（submarinecablemap.com）で、自分の ISP が利用している海底ケーブルを調査できる。
4. PeeringDB の参照: peeringdb.com で ISP 間の接続関係やコロケーション施設を確認できる。

ただし、ISP はトラフィックエンジニアリングにより動的に経路を変更するため、「常にこのケーブルを通る」とは断言できない。

FAQ 3: なぜ IPv6 への完全移行は進まないのか？

回答: 技術的には IPv6 は十分に成熟しているが、以下の理由から移行が緩やかである。

1. NAT の成功: IPv4 アドレスの枯渇に対して NAT が効果的に機能したため、移行の緊急性が低下した。多くの組織にとって NAT で「十分に動く」状態が続いている。
2. デュアルスタックの複雑さ: 移行期間中は IPv4 と IPv6 の両方を運用する必要があり、運用コストと複雑性が増大する。
3. レガシーシステムの存在: IPv6 に対応していない古い機器やソフトウェアが依然として多く存在する。特に組み込みシステムや IoT デバイスで顕著。
4. 投資対効果の不透明さ: IPv6 移行に必要な投資（機器更新、スタッフ教育、テスト）に対して、即座に得られるビジネス上のメリットが見えにくい。
5. コンテンツプロバイダーの対応: Google、Facebook 等の大手は IPv6 対応済みだが、中小規模のコンテンツプロバイダーの対応が遅れている。

しかし、IPv4 アドレスの取引価格の上昇（1 アドレスあたり数十ドル）や、IoT デバイスの爆発的増加により、IPv6 移行は着実に進行している。2024 年時点で Google へのアクセスの約 45% が IPv6 経由である。

FAQ 4: VPN を使うとインターネットの経路はどう変わるのか？

回答: VPN（Virtual Private Network）は、ユーザーのトラフィックを暗号化して VPN サーバーを経由させる技術である。

VPN なしの経路:
  ユーザー → ISP → IX → 宛先サーバー
  (ISP はユーザーの通信先を把握可能)

VPN ありの経路:
  ユーザー → ISP ──[暗号化トンネル]──→ VPN サーバー → 宛先サーバー
  (ISP は VPN サーバーへの通信しか把握できない)
  (宛先サーバーは VPN サーバーの IP を見る)

VPN を使用すると:

• ISP から見た通信先は VPN サーバーのみとなり、プライバシーが向上する
• 通信経路が VPN サーバーを経由するため、遅延が増加する場合がある
• VPN サーバーの所在地によっては、地理的に遠回りになることもある
• 一方で、VPN サーバーが宛先に近い場合は遅延が減少する場合もある

FAQ 5: 光ファイバーの速度限界はどこにあるのか？

回答: 現在の光ファイバー通信技術には、いくつかの物理的・技術的限界がある。

• 伝搬速度の限界: 光ファイバー中の光速は真空中の約 2/3（約 20 万 km/s）であり、これは物理法則により改善できない。したがって、遅延の下限は距離によって決定される。
• 帯域幅の限界: シャノンの定理により、光ファイバー 1 本あたりの理論的な帯域幅の上限は約 100 Tbps とされている。現在のシステムは数十 Tbps に達しており、理論限界に近づきつつある。
• 非線形効果: 光パワーを上げすぎると、光ファイバー中の非線形光学効果（四光波混合、自己位相変調等）により信号品質が劣化する。
• 空間分割多重（SDM）: 次世代技術として、マルチコアファイバーやマルチモードファイバーを使った空間分割多重が研究されており、従来の 10 倍以上の帯域拡張が期待されている。

FAQ

Q1: このトピックを学ぶ上で最も重要なポイントは何ですか？

実践的な経験を積むことが最も重要です。理論だけでなく、実際にコードを書いて動作を確認することで理解が深まります。

Q2: 初心者がよく陥る間違いは何ですか？

基礎を飛ばして応用に進むことです。このガイドで説明している基本概念をしっかり理解してから、次のステップに進むことをお勧めします。

Q3: 実務ではどのように活用されていますか？

このトピックの知識は、日常的な開発業務で頻繁に活用されます。特にコードレビューやアーキテクチャ設計の際に重要になります。

17. まとめ

キーポイント

1. インターネットは階層構造である: Tier 1/2/3 ISP と IX によるピラミッド型の構成で、約 75,000 の AS が BGP で経路情報を交換することで成り立っている
2. パケット交換方式が通信の基盤: データを小単位に分割して独立にルーティングすることで、回線の効率的共有と障害耐性の高い通信を実現している
3. ISP と IX の役割が重要: トランジット契約とピアリング契約により AS 間の接続が決定され、IX が経路集約とコスト削減に寄与している

まとめ

このガイドでは以下を学びました:

• インターネットは ARPANET を起源とし、パケット交換方式に基づく「ネットワークのネットワーク」であること
• データはパケットに分割され、BGP によるルーティングで約 75,000 の AS 間を経由して宛先に届くこと
• ISP は Tier 1 / Tier 2 / Tier 3 の階層構造を持ち、IX（Internet Exchange）がピアリングの要所となること
• 海底ケーブルが大陸間通信の物理的基盤であり、その帯域・冗長性がインターネット全体の信頼性を支えていること
• DNS 解決から TCP 接続、TLS ハンドシェイク、HTTP リクエスト、レンダリングまで、Web ページ表示の全工程を追跡できること

次に読むべきガイド

参考文献

1. Kurose, J. F., Ross, K. W. "Computer Networking: A Top-Down Approach." 8th Edition, Pearson, 2021. -- ネットワーク工学の定番教科書。パケット通信、ルーティング、トランスポート層を体系的に解説している。
2. Peterson, L., Davie, B. "Computer Networks: A Systems Approach." 6th Edition, Morgan Kaufmann, 2021. -- システム設計の視点からネットワークを解説する名著。MIT OCW でも推薦されている。
3. TeleGeography. "Submarine Cable Map." https://submarinecablemap.com/ -- 世界中の海底ケーブルの位置、容量、所有者を視覚的に確認できるインタラクティブマップ。
4. RFC 791 - Internet Protocol (IPv4), September 1981. https://www.rfc-editor.org/rfc/rfc791 -- IPv4 の仕様を定義した原典 RFC。
5. RFC 8200 - Internet Protocol, Version 6 (IPv6) Specification, July 2017. https://www.rfc-editor.org/rfc/rfc8200 -- IPv6 の仕様を定義した RFC。RFC 2460 の改訂版。
6. RFC 4271 - A Border Gateway Protocol 4 (BGP-4), January 2006. https://www.rfc-editor.org/rfc/rfc4271 -- BGP-4 の仕様を定義した RFC。インターネットルーティングの基盤。
7. RFC 9114 - HTTP/3, June 2022. https://www.rfc-editor.org/rfc/rfc9114 -- HTTP/3 の仕様を定義した RFC。QUIC プロトコル上で動作する。
8. Clark, D. "The Design Philosophy of the DARPA Internet Protocols." ACM SIGCOMM Computer Communication Review, 1988. -- エンドツーエンド原則を含むインターネット設計思想の古典論文。

最終更新: 2025-01-15