ネットワークと通信 (Networking & Communication)

はじめに

Web アプリケーションは、ネットワークを介した通信の上に成り立っている。ブラウザに URL を入力してからページが表示されるまでに何が起きているかを理解することは、パフォーマンス最適化、セキュリティ対策、そしてデバッグの基盤となる。

ネットワークモデル

OSI 参照モデルと TCP/IP モデル

ネットワーク通信を階層的に理解するためのモデル。実務では TCP/IP モデルの方がよく使われる。

OSI 参照モデル        TCP/IP モデル        実例
─────────────────────────────────────────────────
7. アプリケーション層 ┐
6. プレゼンテーション層├ アプリケーション層   HTTP, HTTPS, DNS, SMTP
5. セッション層      ┘
4. トランスポート層    トランスポート層     TCP, UDP
3. ネットワーク層      インターネット層     IP, ICMP
2. データリンク層    ┐
1. 物理層           ┘ ネットワークIF層    Ethernet, Wi-Fi

実務で意識する層:

アプリケーション層: HTTP/HTTPS の仕様、ステータスコード、ヘッダー
トランスポート層: TCP (信頼性のある通信) vs UDP (高速だが信頼性なし)
インターネット層: IP アドレス、ルーティング

TCP vs UDP

特性	TCP	UDP
接続	コネクション型 (3-way handshake)	コネクションレス
信頼性	パケットの到達保証、順序保証	保証なし
速度	オーバーヘッドあり	高速
用途	Web, メール, ファイル転送	動画ストリーミング, DNS, ゲーム

Web リクエストの流れ

ブラウザに https://app.raica.jp/patients/123 と入力してからレスポンスが返るまで:

1. DNS 解決
   ブラウザ → DNS サーバー
   "app.raica.jp の IP アドレスは？" → "203.0.113.50"

2. TCP 接続確立 (3-way handshake)
   クライアント → SYN → サーバー
   クライアント ← SYN-ACK ← サーバー
   クライアント → ACK → サーバー

3. TLS ハンドシェイク (HTTPS の場合)
   証明書の検証、暗号化方式の合意、セッションキーの交換

4. HTTP リクエスト送信
   GET /patients/123 HTTP/2
   Host: app.raica.jp
   Authorization: Bearer eyJhbG...

5. サーバー側の処理
   ロードバランサー → アプリケーションサーバー → データベース

6. HTTP レスポンス返却
   HTTP/2 200 OK
   Content-Type: application/json
   {"id": "123", "name": "..."}

7. ブラウザでのレンダリング
   HTML パース → CSS 適用 → JavaScript 実行

主要プロトコル

HTTP/HTTPS

Web の基盤となるプロトコル。

HTTP メソッド:

メソッド	用途	冪等性	安全性
GET	リソースの取得	Yes	Yes
POST	リソースの作成	No	No
PUT	リソースの完全な更新	Yes	No
PATCH	リソースの部分更新	No	No
DELETE	リソースの削除	Yes	No

冪等性 (Idempotency): 同じリクエストを何度送っても結果が同じであること。リトライ時の安全性に関わる。

主要なステータスコード:

コード	意味	使いどころ
200	OK	正常なレスポンス
201	Created	リソース作成成功
204	No Content	成功だがレスポンスボディなし
301	Moved Permanently	恒久的なリダイレクト
400	Bad Request	クライアント側のエラー (バリデーション失敗等)
401	Unauthorized	認証が必要
403	Forbidden	認証済みだが権限なし
404	Not Found	リソースが存在しない
409	Conflict	競合 (楽観的ロックの失敗等)
429	Too Many Requests	レート制限超過
500	Internal Server Error	サーバー側のエラー
502	Bad Gateway	上流サーバーからの不正レスポンス
503	Service Unavailable	サーバーが一時的に利用不可

HTTP ヘッダーの重要なもの:

Content-Type: レスポンスのデータ形式 (application/json 等)
Authorization: 認証情報 (Bearer <token>)
Cache-Control: キャッシュの制御
CORS ヘッダー: クロスオリジンリクエストの制御

DNS (Domain Name System)

ドメイン名を IP アドレスに変換する仕組み。

ブラウザ → ローカルキャッシュ → OS キャッシュ → DNS リゾルバ
    → ルート DNS → TLD DNS (.jp) → 権威 DNS (raica.jp)

DNS レコードの種類:

A レコード: ドメイン → IPv4 アドレス
AAAA レコード: ドメイン → IPv6 アドレス
CNAME レコード: ドメイン → 別のドメイン (エイリアス)
MX レコード: メールサーバーの指定
TXT レコード: テキスト情報 (SPF, DKIM 等)

TLS (Transport Layer Security)

通信の暗号化を行うプロトコル。HTTPS = HTTP + TLS。

TLS が提供するもの:

暗号化: 通信内容の秘匿
認証: サーバーが本物であることの確認 (証明書)
完全性: データが改竄されていないことの保証

証明書: 認証局 (CA) が発行。Let's Encrypt による無料証明書が普及。AWS なら ACM (AWS Certificate Manager) で管理。

API 設計パターン

REST (Representational State Transfer)

リソース指向の API 設計。

GET    /api/patients          # 患者一覧の取得
GET    /api/patients/123      # 特定の患者の取得
POST   /api/patients          # 患者の新規登録
PUT    /api/patients/123      # 患者情報の更新
DELETE /api/patients/123      # 患者の削除

# ネストしたリソース
GET    /api/patients/123/appointments  # 特定患者の予約一覧

REST の原則:

URL はリソース (名詞) を表す
HTTP メソッドで操作を表現
ステートレス (サーバーはクライアントの状態を保持しない)

GraphQL

クライアントが必要なデータを正確に指定できるクエリ言語。

# クライアントが必要なフィールドだけ取得できる
query {
  patient(id: "123") {
    name
    dateOfBirth
    appointments(limit: 5) {
      date
      doctor {
        name
      }
    }
  }
}

REST vs GraphQL:

観点	REST	GraphQL
データ取得	エンドポイントごとに固定	クライアントが指定
Over-fetching	起きやすい	解消できる
Under-fetching	複数リクエスト必要	1リクエストで解決
キャッシュ	HTTP キャッシュが使える	独自のキャッシュ戦略が必要
学習コスト	低い	やや高い

WebSocket

双方向のリアルタイム通信を実現するプロトコル。

HTTP:       クライアント →リクエスト→ サーバー
            クライアント ←レスポンス← サーバー

WebSocket:  クライアント ⇄ サーバー (常時接続、双方向)

使いどころ: チャット、リアルタイム通知、ライブ更新。医療文脈では、診療中のリアルタイムなデータ共有など。

インフラコンポーネント

CDN (Content Delivery Network)

静的コンテンツを地理的に分散したサーバーから配信。ユーザーに近いサーバーからレスポンスすることで、レイテンシを削減。

配信するもの: JavaScript, CSS, 画像, フォントなど。 AWS の場合: CloudFront を使用。

リバースプロキシ (Reverse Proxy)

クライアントとバックエンドサーバーの間に位置するサーバー。

役割:

ロードバランシング: 複数サーバーへの振り分け
SSL 終端: TLS の処理をプロキシで行い、バックエンドの負荷を軽減
キャッシュ: レスポンスをキャッシュ
セキュリティ: バックエンドサーバーの IP を隠蔽

クライアント → [Reverse Proxy (Nginx/ALB)] → バックエンドサーバー群

実務でのデバッグ Tips

ネットワーク問題の切り分け

DNS の問題か? → nslookup / dig で確認
接続の問題か? → curl -v でハンドシェイクを確認
TLS の問題か? → openssl s_client で証明書を確認
アプリケーションの問題か? → HTTP ステータスコードとレスポンスボディを確認
CORS の問題か? → ブラウザの開発者ツールでプリフライトリクエストを確認

ブラウザ開発者ツールの Network タブ

Timing: DNS, 接続, TLS, 待機時間の内訳
Headers: リクエスト/レスポンスヘッダーの確認
Waterfall: リクエストの並列度と依存関係の可視化

Agent-first 開発においてこれが重要な理由

ネットワークの知識は、エージェントへの指示の精度と具体性を大きく左右する。

API 設計を指示できる: 「RESTful な設計で、適切なステータスコードを返すように」「CORS ヘッダーを設定して」と具体的に伝えられる
パフォーマンス問題を特定できる: 「N+1 リクエストが発生している」「CDN でキャッシュすべき」といった指示ができる
セキュリティ要件を明示できる: 「TLS 1.2 以上を必須に」「HSTS ヘッダーを設定して」と指定できる
エラーの原因を切り分けられる: 502 エラーが「アプリのバグ」なのか「インフラの問題」なのかを判断し、適切な対処をエージェントに依頼できる

ネットワークは「見えない」ため、知識がないとブラックボックスになりがちだ。基本を押さえることで、エージェントの出力を適切に評価できるようになる。