HTTP/HTTPS｜コンピュータネットワーク

🎓 レベル：基礎　|　重要度：A（必須） 📎 前提：TCP（3ウェイ・再送・フロー制御）

要点（BLUF）

HTTPは、クライアントがリクエストを送りサーバがレスポンスを返す、Webの問い合わせ応答プロトコルです（既定80番、TCP）。
HTTPSはHTTPをTLSで暗号化したもの（既定443番）。盗聴・改ざん・なりすましを防ぎます。
各応答にはステータスコードが付き、200=成功・404=未検出・500=サーバエラー等で結果を伝えます。

リクエストとレスポンスの構造

HTTPはテキストベースで、人が読める形です。

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: curl/8.0
Accept: text/html

（リクエストここまで・本文なし）

サーバの応答：

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1256

<!DOCTYPE html> ...本文...

リクエスト行：メソッド＋パス＋バージョン。
ヘッダ：Host（どのサイトか）・Content-Type（中身の種類）など。
本文：POSTのデータや、応答のHTML/画像など。

メソッドとステータスコード

メソッド	役割
GET	取得（副作用なし）
POST	送信・作成
PUT	置換・更新
DELETE	削除

コード帯	意味	例
2xx	成功	200 OK
3xx	リダイレクト	301 恒久移動・304 未変更
4xx	クライアント側エラー	404 未検出・403 禁止
5xx	サーバ側エラー	500 内部エラー・503 利用不可

HTTPSとTLS：安全に運ぶ

HTTPは平文なので、途中の機器に丸見えです。HTTPSはTLSでコネクションを暗号化します。

graph LR
  C["クライアント"]
  T["TLSハンドシェイク（鍵交換・サーバ証明書検証）"]
  S["サーバ"]
  C --> T --> S
  T -->|"以後は暗号化されたHTTP"| S

TLSは(1) サーバ証明書で相手が本物か検証し、(2) 鍵を交換して以後の通信を暗号化します。これにより盗聴・改ざん・なりすましを防ぎます。TLSや証明書の詳細はサイバーセキュリティ分野へ繋ぎ、ここでは「HTTPS＝HTTP＋TLS、443番」と押さえます。

HTTPの進化

HTTP/1.1：1コネクションで逐次。複数リクエストで待ちが発生。
HTTP/2：1コネクション上で多重化（並行ストリーム）。ヘッダ圧縮。
HTTP/3：TCPではなくUDP上のQUICで動き、TCPの先頭ブロッキングを回避。接続確立も高速。

下位層がTCP（1.1/2）からUDP（3）へ変わったのは、第4章で触れた「信頼性をアプリ側で作る」流れの実例です。

なぜステートレスなのか（設計の直観）

HTTPは基本ステートレス（各リクエストが独立で、前の状態を覚えない）です。これによりサーバは膨大なリクエストを軽くさばけ、負荷分散もしやすい。「ログイン状態」のような状態は、Cookieやトークンを各リクエストに添えることでアプリ側が補います。状態を持たない単純さでスケールを稼ぎ、必要な状態だけ明示的に運ぶ——Webが巨大化できた設計判断です。

⚠️ よくある誤解

「HTTPSなら何もかも隠れる」ではない。通信内容は暗号化されますが、接続先のドメイン（SNI/DNS）やIPは経路上から見えることがあります。
「404はサーバの故障」ではない。4xxはクライアント側の問題（URL間違い等）。サーバの障害は5xx。
「GETとPOSTは見た目以外同じ」ではない。GETはパスに情報が乗りキャッシュ・履歴に残る。秘密情報や作成操作はPOST/PUTを使います。

対応 lab

なし（curl・ブラウザ開発者ツールでの観察を推奨）