第 11 章コンピュータネットワーク¶

まえがき — 世界をつなぐパイプ¶

https://google.com と URL を打ち込むと、なぜ 0.3 秒で世界の反対側のサーバーから情報が返るの? Wi-Fi は壁越しでもつながるのに、なぜスマホが「ここのサーバーに送って」と知っているの? HTTPS の鍵マークは何を保証している?

これらの疑問を解くのが ネットワーク です。

ネットワークは「異なるコンピュータ間でデータを送り届ける技術」。物理的な電波・光・銅線から、HTTP の文字列まで、何層にも積み重なった工夫の結晶。現代のソフトウェアの 99% はネットワーク越しに動く ので、避けては通れません。

🎯 章の目標

「階層化」というネットワーク設計の哲学を理解する

IP, TCP, UDP, DNS, HTTP, TLS の仕組みを説明できる

ping, traceroute, dig, curl -v, tcpdump でトラブルシュートできる

ロードバランサ、CDN、NAT などモダンな構成要素を把握する

11.1 なぜネットワークか¶

「ネットワークは見えないので難しい」と思いがちですが、実は 目に見える層 から順に積み上げて理解できます。

層	何をする?
物理	電気・光・電波で 0/1 を運ぶ
データリンク	隣接機器の間でフレームをやり取り
ネットワーク (IP)	世界中のホスト間でパケットを届ける
トランスポート (TCP/UDP)	「信頼性」「順序」を保証
アプリ (HTTP, DNS)	意味のあるやり取り

「下の層が上の層を支える」と覚えると、次々に理解できます。

11.2 階層化と参照モデル¶

階層化の全体像:

graph TB
    subgraph "送信側 (例: Web ブラウザ)"
        A1[アプリ層: HTTP]
        T1[トランスポート層: TCP]
        N1[ネットワーク層: IP]
        L1[リンク層: Ethernet/Wi-Fi]
    end
    subgraph "受信側 (例: Web サーバ)"
        A2[アプリ層: HTTP]
        T2[トランスポート層: TCP]
        N2[ネットワーク層: IP]
        L2[リンク層: Ethernet/Wi-Fi]
    end
    A1 -.->|論理的な通信| A2
    T1 -.->|論理的な通信| T2
    N1 -.->|論理的な通信| N2
    L1 -->|実際の通信| L2

    A1 --> T1
    T1 --> N1
    N1 --> L1
    L2 --> N2
    N2 --> T2
    T2 --> A2

    style A1 fill:#c5e1a5
    style A2 fill:#c5e1a5
    style T1 fill:#ffe0b2
    style T2 fill:#ffe0b2
    style N1 fill:#bbdefb
    style N2 fill:#bbdefb
    style L1 fill:#f8bbd0
    style L2 fill:#f8bbd0

各層は同じ層同士で論理的に話していると思い、下の層に丸投げします。

11.2.1 OSI 7 層モデル¶

層	役割	例
7 アプリケーション	意味のある通信	HTTP, SMTP, DNS
6 プレゼンテーション	データ形式・暗号	TLS, JSON
5 セッション	会話管理	RPC
4 トランスポート	信頼性・順序	TCP, UDP
3 ネットワーク	ルーティング	IP
2 データリンク	隣接機器のやり取り	Ethernet
1 物理	電気・光・電波	ケーブル, Wi-Fi

11.2.2 TCP/IP 4 層モデル（実用）¶

OSI を簡略化:

層	例
アプリケーション	HTTP, DNS
トランスポート	TCP, UDP
インターネット	IP
リンク	Ethernet, Wi-Fi

階層化のメリット: 各層は下を抽象化された配管として扱える。HTTP を書く人は TCP の輻輳制御を意識しなくていい。

11.3 物理層・データリンク層¶

11.3.1 物理層¶

ケーブル: ツイストペア（Cat5e/6）、光ファイバ、同軸
無線: Wi-Fi (2.⅘/6 GHz)、Bluetooth、5G
信号符号化: NRZ, Manchester, 4B/5B

11.3.2 データリンク層¶

「隣接した機器の間」の通信を担当。

Ethernet¶

┌──────┬──────┬───────┬─────────────────┬──────┐
│ 宛先MAC│ 送信元MAC│ Type │      Payload     │ FCS  │
└──────┴──────┴───────┴─────────────────┴──────┘
   6B    6B      2B    46-1500B     4B

MAC アドレス¶

48 ビット (例: aa:bb:cc:dd:ee:ff)。機器ごとに固有（メーカ製造時に焼き付け）。

ARP (Address Resolution Protocol)¶

「IP アドレス → MAC アドレス」を解決。同一サブネット内でブロードキャスト:

A: 「192.168.1.5 の MAC アドレスは?」(全員に問い合わせ)
B: 「私です。MAC は xx:xx:xx」

スイッチと VLAN¶

スイッチ: MAC アドレス学習で、必要な相手にだけ転送
VLAN: 物理的には同じ LAN を、論理的に分割

11.4 ネットワーク層 (IP)¶

11.4.1 IPv4¶

32 ビットアドレス。192.168.1.1 の形式。

サブネット¶

ネットワーク部 + ホスト部。CIDR 記法で /24 のように示す。 - 192.168.1.0/24 → 192.168.1.0 〜 192.168.1.255（256 個）

私有アドレス¶

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

これらは家庭内・社内 LAN で使い、外には出ません。

NAT (Network Address Translation)¶

「家庭内では私有 IP、外向けには 1 つのグローバル IP」に変換する仕組み。IPv4 アドレス枯渇への応急処置。

家のルーター (グローバル IP: 203.0.113.1)
├ スマホ (192.168.1.10)
├ PC    (192.168.1.20)
└ TV    (192.168.1.30)

外から見るとすべて 203.0.113.1 から来ているように見え、ルーターがポート番号で内部のどの機器かを覚えています。

11.4.2 IPv6¶

128 ビット。2001:db8::1 の形式。アドレス枯渇を解消、自動構成、IPsec 標準。普及進行中。

11.4.3 ルーティング¶

ルーティングテーブル¶

宛先              次ホップ
192.168.1.0/24   直接接続
0.0.0.0/0       (デフォルト) ルーター

「最長プレフィックスマッチ」で最も具体的な経路を選択。

動的ルーティングプロトコル¶

OSPF (Open Shortest Path First): 内部、リンクステート、Dijkstra (第 7 章) を内部で使う
RIP: 距離ベクトル、古い
BGP (Border Gateway Protocol): 外部、インターネットの背骨。世界中の AS (自律システム) 間で経路情報をやり取り

11.4.4 IP パケット¶

┌─────────────────────────┐
│ IP ヘッダ                │
│  Version, TTL, Protocol  │
│  Src IP, Dst IP, Checksum│
├─────────────────────────┤
│ ペイロード (TCP/UDP データ)│
└─────────────────────────┘

TTL は「Time To Live」、ホップごとに減り 0 で破棄。ループを防ぐ。

11.4.5 ICMP¶

ping や traceroute の正体。

$ ping google.com
PING google.com (216.58.196.142): 56 data bytes
64 bytes from 216.58.196.142: icmp_seq=0 ttl=115 time=10.4 ms

$ traceroute google.com
1   192.168.1.1   1ms     ← 自宅ルーター
2   10.0.0.1      5ms     ← ISP
3   ...
9   216.58.196.142 30ms   ← Google

11.5 トランスポート層¶

11.5.1 UDP — 「速いが信頼性なし」¶

┌────────┬────────┬─────────┬─────────┐
│ Src Port│ Dst Port│ Length  │Checksum │
└────────┴────────┴─────────┴─────────┘

コネクションレス
信頼性なし、順序なし
軽量

用途: DNS, DHCP, リアルタイム動画/音声、ゲーム, QUIC のベース。

11.5.2 TCP — 「信頼性のあるストリーム」¶

コネクション指向
順序保証、再送、輻輳制御

3 ウェイハンドシェイク¶

sequenceDiagram
    participant C as クライアント
    participant S as サーバ

    C->>S: SYN (seq=x)<br/>「接続したい」
    S->>C: SYN + ACK<br/>(seq=y, ack=x+1)<br/>「OK、君の番号確認」
    C->>S: ACK (ack=y+1)<br/>「君の番号も確認」
    Note over C,S: 接続確立 ✅
    C->>S: データ送信開始
    S->>C: データ受信

「3 回握手して挨拶」してから本通信に入ります。これで両者が「お互いを認識した」と確証を得ます。

4 ウェイ FIN クローズ¶

正常終了は 4 段階で。「今送信し終わった」「了解した」を双方向で。

11.5.3 信頼性の仕組み¶

シーケンス番号 + ACK: 何バイト目まで届いたか
再送 (RTO, fast retransmit): 失われたら再送
ウィンドウ制御: 送信側ウィンドウ、受信側ウィンドウ
フロー制御: 受信側のバッファが溢れないように
輻輳制御: ネットワーク全体の混雑を抑える
スロースタート、輻輳回避
アルゴリズム: Reno, Cubic, BBR

11.5.4 ポート番号¶

0–65535。Well-known:

ポート	プロトコル
22	SSH
25	SMTP
53	DNS
80	HTTP
443	HTTPS
3306	MySQL
5432	PostgreSQL
6379	Redis
27017	MongoDB

11.6 アプリケーション層¶

11.6.1 DNS — 名前解決¶

google.com → 216.58.196.142 の変換。

sequenceDiagram
    participant User as ブラウザ
    participant Resolver as DNS リゾルバ
    participant Root as ルートサーバ (.)
    participant TLD as TLD サーバ (.com)
    participant Auth as 権威サーバ (google.com)

    User->>Resolver: google.com の IP は?
    Resolver->>Root: google.com を知ってる?
    Root->>Resolver: .com サーバに聞いて
    Resolver->>TLD: google.com を知ってる?
    TLD->>Resolver: google.com の権威に聞いて
    Resolver->>Auth: google.com の IP は?
    Auth->>Resolver: 216.58.196.142
    Resolver->>User: 216.58.196.142

電話帳のような 階層的データベース を辿って、ドメイン名を IP に変換します。

レコードの種類¶

種類	内容
A	IPv4 アドレス
AAAA	IPv6 アドレス
CNAME	別名 (エイリアス)
MX	メールサーバ
TXT	テキスト (SPF, DKIM など)
NS	ネームサーバ
SOA	ゾーン情報

キャッシュと TTL¶

DNS の応答は TTL 秒間キャッシュ。短いと負荷増、長いと変更反映が遅い。

dig でデバッグ¶

$ dig google.com
;; ANSWER SECTION:
google.com.   300  IN  A  216.58.196.142

DNSSEC, DoH, DoT¶

DNSSEC: 署名による真正性検証
DoH (DNS over HTTPS): プライバシ
DoT (DNS over TLS): プライバシ

11.6.2 HTTP¶

リクエストとレスポンス¶

GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234

<html>...</html>

メソッド¶

メソッド	用途
GET	取得
POST	作成
PUT	更新（全体）
PATCH	更新（部分）
DELETE	削除
HEAD	ヘッダのみ取得
OPTIONS	利用可能なメソッド

ステータスコード¶

範囲	意味	例
1xx	情報	100 Continue
2xx	成功	200 OK, 201 Created
3xx	リダイレクト	301, 302
4xx	クライアント誤り	400, 401, 403, 404
5xx	サーバ誤り	500, 502, 503

HTTP/1.1, HTTP/2, HTTP/3¶

バージョン	特徴
1.1	テキスト、Keep-Alive、Head-of-Line ブロッキング問題
2	バイナリ、多重化、HPACK 圧縮
3 (QUIC)	UDP ベース、TCP の HoL を解消

11.6.3 メール¶

SMTP: 送信
POP3 / IMAP: 受信
DKIM, SPF, DMARC: なりすまし防止

11.6.4 その他のプロトコル¶

WebSocket: HTTP からアップグレードして双方向通信
gRPC: HTTP/2 + Protobuf の RPC
MQTT: IoT 向け軽量 pub/sub

11.7 TLS/SSL — 暗号化通信¶

11.7.1 流れ (TLS 1.3)¶

ClientHello（対応する暗号）
ServerHello（選択暗号、証明書）
鍵交換 (ECDHE) で共通鍵を確立
アプリケーションデータを共通鍵で暗号化

11.7.2 証明書¶

公開鍵 + 識別情報を CA (認証局) が署名:

ルート CA → 中間 CA → サーバ証明書

ブラウザ・OS にルート CA がプリインストール。Let's Encrypt で 無料で取得 できるようになり、HTTPS 化が一気に普及。

11.7.3 失効¶

CRL (Certificate Revocation List)
OCSP, OCSP Stapling
短命証明書 (90 日) で運用

11.7.4 ハンドシェイクの最適化¶

0-RTT (TLS 1.3): 過去のセッションを再利用してすぐ送信
セッション再開、セッションチケット

11.8 ソケットプログラミング¶

import socket

# クライアント
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("example.com", 80))
s.sendall(b"GET / HTTP/1.0\r\nHost: example.com\r\n\r\n")
print(s.recv(4096))
s.close()

# サーバ
server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind(("0.0.0.0", 8080))
server.listen()
while True:
    client, addr = server.accept()
    data = client.recv(1024)
    client.sendall(b"HTTP/1.1 200 OK\r\n\r\nHello!")
    client.close()

並行処理: - 1 接続 1 スレッド: 単純だがスケールしない - 1 接続 1 プロセス (fork): 古典的 - イベント駆動 (epoll): C10K 問題の解 - async/await: モダン

11.9 ネットワーク機器¶

機器	層	役割
ハブ	1	全ポートにブロードキャスト（古い）
スイッチ	2	MAC 学習で転送
ルーター	3	IP で転送
ファイアウォール	3-7	パケットフィルタ
ロードバランサ	4 (TCP) / 7 (HTTP)	振り分け、ヘルスチェック
リバースプロキシ	7	Nginx, HAProxy
WAF	7	Web の脅威検知
CDN	7	地理的に分散したキャッシュ

11.10 性能¶

11.10.1 帯域・遅延・ジッタ・パケットロス¶

帯域: ビット/秒
遅延 (latency): 片道、RTT/2
ジッタ: 遅延のばらつき
パケットロス: 失われた割合

光速の限界 (東京 ↔ ロサンゼルス約 50ms RTT) は超えられない。

11.10.2 TCP のスループット¶

\[\text{Throughput} \approx \frac{\text{Window size}}{\text{RTT}}\]

帯域遅延積 (BDP) が大きいほど大きなウィンドウが必要。

11.10.3 性能向上テクニック¶

接続再利用 (Keep-Alive)
HTTP/2 多重化
TCP Fast Open
0-RTT
HTTP キャッシング (Cache-Control, ETag)
圧縮 (gzip, Brotli)
CDN

11.10.4 観測ツール¶

ping example.com           # 到達性
traceroute example.com     # 経路
mtr example.com            # 統合
dig example.com            # DNS
curl -v https://...        # HTTP デバッグ
tcpdump -i eth0            # パケットキャプチャ
ss -tlnp                   # 接続状態
iperf3 -c server           # 帯域測定

Wireshark で GUI で見るとさらに分かりやすい。

11.11 セキュリティ視点¶

ARP スプーフィング、DNS キャッシュポイズニング
TCP RST 攻撃、SYN フラッド
DDoS と緩和（CDN, レート制限, Anycast）
中間者攻撃 (MitM)、HSTS で HTTP→HTTPS 強制

詳細は第 15 章で。

11.12 演習問題¶

192.168.1.0/26 のサブネットマスク、利用可能ホスト数を求めよ。
3 ウェイハンドシェイクのシーケンス番号と ACK の遷移を図示せよ。
dig www.google.com の出力を読み、A レコード, NS レコードを説明せよ。
HTTP/1.1 の Head-of-Line Blocking を例で示し、HTTP/2 がどう解消するか述べよ。
TLS 1.3 のハンドシェイクが 1-RTT で済む理由を説明せよ。
Python で TCP エコーサーバを実装し、複数クライアントを select で扱え。
1 Gbps の帯域・1 ms の RTT で TCP のウィンドウが 64 KB のとき、最大スループットはいくらか。
CDN がキャッシュするコンテンツと、しないほうが良いコンテンツの境界を述べよ。
tcpdump を使い、自分の HTTP リクエストをキャプチャしてヘッダを観察せよ。
自宅のルーターの NAT 設定を調べ、ポート転送ルールを 1 つ書け。

11.13 この章のまとめ¶

層	主要プロトコル
物理	Ethernet, Wi-Fi
データリンク	ARP, スイッチ
ネットワーク	IP, ICMP, OSPF/BGP
トランスポート	TCP, UDP
アプリ	HTTP, DNS, TLS

ネットワークは「階層化された配管設計の傑作」。トラブルシュートは「どの層で異常か」を切り分けるのが王道。

11.14 次に読むもの¶

Kurose & Ross, Computer Networking: A Top-Down Approach — 定番、トップダウン
Stevens, TCP/IP Illustrated — 詳細
Beej's Guide to Network Programming — 無料、ソケット入門
Ilya Grigorik, High Performance Browser Networking
『マスタリング TCP/IP 入門編』

🌟 メッセージ ネットワークは「ブラックボックス」と思われがち。でも tcpdump で実際のパケットを見ると、急に「実体」になります。1 度自分の通信を見てみてください。

第 11 章 コンピュータネットワーク¶