システムデザイン完全ガイド ②｜ネットワークと通信

┌──────────────────────────────────────────┐
│ L7 アプリケーション  HTTP, gRPC, DNS, SMTP  │ ← 何を伝えるか
├──────────────────────────────────────────┤
│ L4 トランスポート    TCP, UDP, QUIC         │ ← 確実に届けるか
├──────────────────────────────────────────┤
│ L3 ネットワーク      IP, ICMP, BGP          │ ← どの経路で運ぶか
├──────────────────────────────────────────┤
│ L2 データリンク      Ethernet, ARP          │ ← 隣の機器へ渡す
├──────────────────────────────────────────┤
│ L1 物理             光ファイバ, 電波        │ ← 物理的な信号
└──────────────────────────────────────────┘

クライアント          サーバー
    │ ── SYN ────────► │
    │ ◄──── SYN+ACK ── │      ここまでで 1 RTT かかる
    │ ── ACK ────────► │
    │ ── データ ─────► │

リクエスト                         レスポンス
GET /users/42 HTTP/1.1             HTTP/1.1 200 OK
Host: api.example.com              Content-Type: application/json
Authorization: Bearer xxx          Cache-Control: max-age=60
Accept: application/json           ETag: "a1b2c3"

                                   {"id":42,"name":"Kota"}

Cache-Control: public, max-age=3600, stale-while-revalidate=86400
ETag: "v3-a1b2c3"
Last-Modified: Wed, 21 Aug 2026 07:28:00 GMT

クライアント: GET /a.js   If-None-Match: "v3-a1b2c3"
サーバー:     304 Not Modified （ボディを送らない = 数十バイトで済む）

Client                             Server
  │─ ClientHello (鍵共有材料, 対応暗号) ──►│
  │◄─ ServerHello + 証明書 + Finished ────│   ← ここで鍵が確定
  │─ Finished ─────────────────────────►│
  │═══ 暗号化された HTTP ══════════════►│

ルート CA（ブラウザに埋め込み済み）
  └ 中間 CA
      └ サーバー証明書（example.com、公開鍵、有効期限、署名）

ブラウザ
  │ ① ブラウザキャッシュ → OS キャッシュ → hosts ファイル
  ▼
リゾルバ（ISP or 8.8.8.8 / 1.1.1.1）
  │ ② キャッシュになければ再帰的に問い合わせ
  ├──► ルートサーバー (.)        「.com は c.gtld-servers.net に聞け」
  ├──► TLD サーバー (.com)       「example.com は ns1.example.com に聞け」
  └──► 権威サーバー (example.com) 「A レコードは 93.184.216.34 だ」
  ▼
IP アドレスが返る（TTL 付き）

GET    /v1/users              一覧
POST   /v1/users              作成
GET    /v1/users/{id}         取得
PATCH  /v1/users/{id}         部分更新
DELETE /v1/users/{id}         削除
GET    /v1/users/{id}/posts   サブリソース
POST   /v1/videos/{id}:publish  ← 動詞が必要な場合はカスタムメソッド（Google API 設計ガイド流）

GET /posts?offset=100000&limit=20

GET /posts?after=eyJpZCI6MTIzLCJ0cyI6MTY5OTk5fQ&limit=20
→ WHERE (created_at, id) < (:ts, :id) ORDER BY created_at DESC, id DESC LIMIT 20

POST /v1/payments
Idempotency-Key: 8f14e45f-ea...   ← クライアントが生成する UUID
{"amount": 1000, "currency": "JPY"}

1. キー、リクエストハッシュ、状態（in_progress / succeeded / failed）、レスポンスを保存
2. 既存キーが succeeded なら、同じリクエストか検証して保存済みレスポンスを返す
3. in_progress なら同時実行を抑止し、ポーリングまたは再試行可能な応答を返す
4. 新規キーは一意制約とトランザクションで claim し、副作用と結果保存を安全に結び付ける
5. タイムアウトやクラッシュ後は、lease の期限切れ、照合、再実行・照会の方針を定義する
6. 保持期間は業務上の再送期間と、プロバイダの仕様に合わせて決める

{
  "error": {
    "code": "RESOURCE_EXHAUSTED",
    "message": "Rate limit exceeded. Retry after 30s.",
    "details": [{"@type": "RetryInfo", "retry_delay": "30s"}],
    "request_id": "req_01H..."
  }
}

POST /v1/videos:transcode → 202 Accepted, {"operation_id": "op_123"}
GET  /v1/operations/op_123 → {"done": false, "progress": 0.4}

サーバー → クライアントの一方向で十分？
  ├─ YES → SSE を選ぶ（HTTP なので LB・プロキシと相性が良く、自動再接続も仕様にある）
  └─ NO（双方向・低遅延が必要）→ WebSocket
       └─ 極端な低遅延・多少の欠損を許容（ゲーム）→ WebRTC / QUIC datagram

              ┌── 接続サーバー #1 (10 万接続) ──┐
クライアント ──│                                  │
              ├── 接続サーバー #2 (10 万接続) ──┤
              └── 接続サーバー #3 (10 万接続) ──┘
                          │
                  「誰がどのサーバーに繋がっているか」
                          ▼
              ┌────────────────────────┐
              │ セッションレジストリ    │ Redis: user_id → server_id
              └────────────────────────┘
                          │
              ┌────────────────────────┐
              │ Pub/Sub（Redis/Kafka）  │ サーバー間でメッセージを中継
              └────────────────────────┘