Day 7: HTTPとWebの仕組み
今日学ぶこと
- Webの仕組み（URL → DNS → TCP → HTTP）
- HTTPの進化（HTTP/1.1、HTTP/2、HTTP/3）
- HTTPメソッド（GET、POST、PUT、DELETE、PATCH）
- ステータスコード（1xx〜5xx）
- ヘッダー（Content-Type、Authorization、Cache-Control等）
- Cookieとセッション
- REST APIの基本
- WebSocketによるリアルタイム通信
Webの仕組み
ブラウザでURLを入力してからWebページが表示されるまで、複数のプロトコルが連携して動作します。
flowchart LR
subgraph Step1["1. URL解析"]
A["https://example.com/page"]
end
subgraph Step2["2. DNS解決"]
B["example.com → 93.184.216.34"]
end
subgraph Step3["3. TCP接続"]
C["3ウェイハンドシェイク"]
end
subgraph Step4["4. TLSハンドシェイク"]
D["暗号化確立"]
end
subgraph Step5["5. HTTPリクエスト"]
E["GET /page HTTP/1.1"]
end
subgraph Step6["6. HTTPレスポンス"]
F["200 OK + HTML"]
end
A --> B --> C --> D --> E --> F
style Step1 fill:#3b82f6,color:#fff
style Step2 fill:#8b5cf6,color:#fff
style Step3 fill:#22c55e,color:#fff
style Step4 fill:#f59e0b,color:#fff
style Step5 fill:#ef4444,color:#fff
style Step6 fill:#3b82f6,color:#fff
URLの構造
https://www.example.com:443/path/page?key=value#section
|_____| |______________|___|__________|_________|_______|
scheme host port path query fragment
| 要素 | 説明 | 例 |
|---|---|---|
| scheme | プロトコル | https, http |
| host | ドメイン名 | www.example.com |
| port | ポート番号（省略可） | 443（HTTPS既定） |
| path | リソースのパス | /path/page |
| query | クエリパラメータ | ?key=value |
| fragment | ページ内の位置 | #section |
HTTPの進化
HTTP/1.1（1997年〜）
HTTP/1.1は長年Webの標準として使われてきました。
sequenceDiagram
participant Client as クライアント
participant Server as サーバー
Note over Client, Server: HTTP/1.1 - 1リクエスト/1レスポンスが基本
Client->>Server: GET /index.html
Server-->>Client: 200 OK (HTML)
Client->>Server: GET /style.css
Server-->>Client: 200 OK (CSS)
Client->>Server: GET /script.js
Server-->>Client: 200 OK (JS)
特徴と制限：
- テキストベースのプロトコル
- Keep-Aliveで接続を再利用可能
- Head-of-Line Blocking：1つの接続で1つずつしかリクエストを処理できない
- ブラウザはドメインあたり6接続まで同時に開く
HTTP/2（2015年〜）
sequenceDiagram
participant Client as クライアント
participant Server as サーバー
Note over Client, Server: HTTP/2 - 多重化で同時送受信
par 多重化ストリーム
Client->>Server: Stream 1: GET /index.html
Client->>Server: Stream 3: GET /style.css
Client->>Server: Stream 5: GET /script.js
end
par 応答
Server-->>Client: Stream 1: 200 OK (HTML)
Server-->>Client: Stream 3: 200 OK (CSS)
Server-->>Client: Stream 5: 200 OK (JS)
end
改善点：
| 機能 | 説明 |
|---|---|
| 多重化（Multiplexing） | 1つの接続で複数のリクエスト/レスポンスを並行処理 |
| ヘッダー圧縮（HPACK） | 冗長なヘッダー情報を圧縮 |
| サーバープッシュ | クライアントの要求前にリソースを送信 |
| バイナリフレーミング | テキストからバイナリ形式に変更し効率化 |
HTTP/3（2022年〜）
HTTP/3は、TCPの代わりにQUIC（UDP上に構築）を使用します。
| 比較項目 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| トランスポート | TCP | TCP | QUIC（UDP） |
| 多重化 | なし | あり | あり（改善） |
| Head-of-Line Blocking | あり | TCPレベルであり | なし |
| 接続確立 | TCP + TLS | TCP + TLS | 0-RTT可能 |
| ヘッダー圧縮 | なし | HPACK | QPACK |
HTTP/3ではストリームごとに独立しているため、1つのストリームでパケットロスが起きても他のストリームに影響しません。
HTTPメソッド
HTTPメソッドは、リソースに対して行いたい操作を示します。
| メソッド | 用途 | べき等性 | リクエストボディ |
|---|---|---|---|
| GET | リソースの取得 | あり | なし |
| POST | リソースの作成 | なし | あり |
| PUT | リソースの全体更新 | あり | あり |
| PATCH | リソースの部分更新 | なし | あり |
| DELETE | リソースの削除 | あり | なし |
| HEAD | ヘッダーのみ取得 | あり | なし |
| OPTIONS | 対応メソッドの確認 | あり | なし |
べき等性とは
べき等性（Idempotency） とは、同じリクエストを何度実行しても結果が同じになる性質です。
# GET is idempotent: always returns the same resource
curl https://api.example.com/users/1
# POST is NOT idempotent: each call creates a new resource
curl -X POST https://api.example.com/users \
-H "Content-Type: application/json" \
-d '{"name": "Alice"}'
# PUT is idempotent: replaces the same resource
curl -X PUT https://api.example.com/users/1 \
-H "Content-Type: application/json" \
-d '{"name": "Alice", "email": "alice@example.com"}'
# DELETE is idempotent: deleting the same resource multiple times
curl -X DELETE https://api.example.com/users/1
ステータスコード
HTTPレスポンスには、リクエストの結果を示すステータスコードが含まれます。
flowchart TB
subgraph Codes["HTTPステータスコード"]
A["1xx<br/>情報"]
B["2xx<br/>成功"]
C["3xx<br/>リダイレクト"]
D["4xx<br/>クライアントエラー"]
E["5xx<br/>サーバーエラー"]
end
style A fill:#3b82f6,color:#fff
style B fill:#22c55e,color:#fff
style C fill:#f59e0b,color:#fff
style D fill:#ef4444,color:#fff
style E fill:#8b5cf6,color:#fff
よく使われるステータスコード
| コード | 名前 | 説明 |
|---|---|---|
| 200 | OK | リクエスト成功 |
| 201 | Created | リソース作成成功 |
| 204 | No Content | 成功（レスポンスボディなし） |
| 301 | Moved Permanently | 恒久的リダイレクト |
| 302 | Found | 一時的リダイレクト |
| 304 | Not Modified | キャッシュ利用可 |
| 400 | Bad Request | リクエスト不正 |
| 401 | Unauthorized | 認証が必要 |
| 403 | Forbidden | アクセス拒否 |
| 404 | Not Found | リソースが見つからない |
| 405 | Method Not Allowed | メソッド非対応 |
| 429 | Too Many Requests | レート制限超過 |
| 500 | Internal Server Error | サーバー内部エラー |
| 502 | Bad Gateway | ゲートウェイエラー |
| 503 | Service Unavailable | サービス利用不可 |
HTTPヘッダー
ヘッダーは、リクエストやレスポンスに付加情報を追加します。
リクエストヘッダー
GET /api/users HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
User-Agent: Mozilla/5.0
Accept-Language: ja, en;q=0.8
Cache-Control: no-cache
レスポンスヘッダー
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 256
Cache-Control: max-age=3600
Set-Cookie: session=abc123; HttpOnly; Secure
Access-Control-Allow-Origin: https://example.com
主要ヘッダーの解説
| ヘッダー | 方向 | 説明 |
|---|---|---|
Content-Type |
両方 | データの形式（MIME型） |
Authorization |
リクエスト | 認証情報（Bearer token等） |
Cache-Control |
両方 | キャッシュ動作の制御 |
Accept |
リクエスト | 受け入れ可能な形式 |
Set-Cookie |
レスポンス | Cookieの設定 |
Access-Control-* |
レスポンス | CORS設定 |
Cookieとセッション
HTTPはステートレス（状態を保持しない）プロトコルです。Cookieを使うことで、状態管理を実現します。
sequenceDiagram
participant Browser as ブラウザ
participant Server as サーバー
Browser->>Server: POST /login (ID + パスワード)
Server-->>Browser: 200 OK + Set-Cookie: session=abc123
Note over Browser: Cookieを保存
Browser->>Server: GET /dashboard + Cookie: session=abc123
Server-->>Browser: 200 OK (ダッシュボード)
Browser->>Server: GET /profile + Cookie: session=abc123
Server-->>Browser: 200 OK (プロフィール)
Cookieの属性
| 属性 | 説明 | セキュリティ |
|---|---|---|
HttpOnly |
JavaScriptからアクセス不可 | XSS対策 |
Secure |
HTTPS通信のみ送信 | 盗聴防止 |
SameSite |
クロスサイトリクエスト制御 | CSRF対策 |
Max-Age |
有効期限（秒） | - |
Domain |
有効なドメイン | - |
Path |
有効なパス | - |
REST APIの基本
REST（Representational State Transfer） は、WebAPIを設計するためのアーキテクチャスタイルです。
RESTの原則
- リソース指向：URLでリソースを一意に識別
- HTTPメソッドの活用：操作をメソッドで表現
- ステートレス：サーバーはクライアントの状態を保持しない
- 統一インターフェース：一貫したURL設計
RESTful API設計例
GET /api/users → ユーザー一覧取得
GET /api/users/1 → ユーザー1の詳細取得
POST /api/users → 新規ユーザー作成
PUT /api/users/1 → ユーザー1の全体更新
PATCH /api/users/1 → ユーザー1の部分更新
DELETE /api/users/1 → ユーザー1の削除
GET /api/users/1/posts → ユーザー1の投稿一覧
curlでHTTPリクエストを実践
# GET request
curl -v https://httpbin.org/get
# POST request with JSON body
curl -X POST https://httpbin.org/post \
-H "Content-Type: application/json" \
-d '{"name": "Alice", "email": "alice@example.com"}'
# View response headers only
curl -I https://example.com
# Follow redirects
curl -L https://example.com
# Send with custom headers
curl -H "Authorization: Bearer mytoken" \
-H "Accept: application/json" \
https://api.example.com/data
WebSocket
WebSocketは、クライアントとサーバー間で双方向のリアルタイム通信を実現するプロトコルです。
sequenceDiagram
participant Client as クライアント
participant Server as サーバー
Note over Client, Server: HTTPからWebSocketへアップグレード
Client->>Server: GET /chat (Upgrade: websocket)
Server-->>Client: 101 Switching Protocols
Note over Client, Server: 双方向通信開始
Client->>Server: メッセージ送信
Server-->>Client: メッセージ受信
Server->>Client: プッシュ通知
Client->>Server: メッセージ送信
Server->>Client: リアルタイム更新
Client->>Server: Close
Server-->>Client: Close ACK
HTTPとWebSocketの比較
| 項目 | HTTP | WebSocket |
|---|---|---|
| 通信方向 | リクエスト/レスポンス | 双方向 |
| 接続 | 毎回確立（Keep-Alive可） | 永続的 |
| オーバーヘッド | ヘッダーが毎回付く | 初回のみ |
| 用途 | 通常のWeb閲覧 | チャット、ゲーム、リアルタイム更新 |
| プロトコル | http:// / https:// |
ws:// / wss:// |
まとめ
今日学んだことの整理
| トピック | キーポイント |
|---|---|
| Webの仕組み | URL → DNS → TCP → TLS → HTTP の順で処理 |
| HTTPの進化 | HTTP/1.1 → HTTP/2（多重化） → HTTP/3（QUIC） |
| HTTPメソッド | GET（取得）、POST（作成）、PUT（更新）、DELETE（削除） |
| ステータスコード | 2xx成功、3xxリダイレクト、4xxクライアントエラー、5xxサーバーエラー |
| ヘッダー | Content-Type、Authorization、Cache-Control等 |
| Cookie/セッション | ステートレスなHTTPで状態管理を実現 |
| REST API | リソース指向のAPI設計スタイル |
| WebSocket | 双方向リアルタイム通信 |
重要ポイント
- HTTPはWebの基盤：すべてのWeb通信はHTTPの上に成り立っている
- HTTPの進化は性能改善：HTTP/2の多重化、HTTP/3のQUICは遅延を削減
- ステータスコードを正しく使う：API設計で適切なコードを返すことが重要
- セキュリティを意識：Cookie属性やCORSヘッダーの正しい設定が必要
練習問題
基礎レベル
- HTTP/1.1のHead-of-Line Blocking問題を説明し、HTTP/2がどのように解決したか述べてください。
- GET、POST、PUT、DELETEの違いを、べき等性の観点から説明してください。
- ステータスコード200、301、404、500のそれぞれの意味を説明してください。
中級レベル
curl -v https://example.comを実行し、リクエストとレスポンスの各要素（メソッド、ヘッダー、ステータスコード等）を解説してください。- ユーザー管理APIのRESTful URLを設計してください（CRUD操作すべて）。また、パスワード変更のエンドポイントはどのように設計すべきか考えてください。
- Cookieの
HttpOnly、Secure、SameSite属性がそれぞれどのセキュリティ脅威に対応するか説明してください。
上級レベル
- HTTP/2のサーバープッシュが廃止の方向に向かっている理由を調査し、代替技術（103 Early Hints等）と比較してください。
- HTTP/3が使用するQUICプロトコルが、TCPと比較してどのような利点を持つか、接続確立、パケットロス時の動作、コネクションマイグレーションの3点から説明してください。
- WebSocketの代替として使われるSSE（Server-Sent Events）との違いを説明し、それぞれの適切なユースケースを挙げてください。
参考リンク
次回予告
Day 8: TLS/SSLとネットワークセキュリティ では、暗号化の仕組みを深掘りします。TLSハンドシェイクの詳細、証明書の仕組み、そしてネットワーク攻撃からの防御方法を学びます。