HTTP/HTTPS とは #

HTTP (Hypertext Transfer Protocol) は、WWW において Web サーバと Web クライアント (ブラウザなど) の間で HTML や画像、API レスポンスといったコンテンツを送受信するためのテキストベース通信プロトコルである。TCP/IP のうちトランスポート層に TCP (HTTP/3 では QUIC = UDP ベース) を使い、その上にメッセージのやり取りを規定する。

HTTPS は HTTP の通信全体を TLS (旧 SSL) で暗号化したもので、盗聴・改ざん・なりすましの 3 つを同時に防ぐ。今日では Web のほぼすべてのトラフィックが HTTPS 経由であり、ブラウザは混在コンテンツや無効な証明書を強く警告するようになった。

HTTP の基本構造 #

クライアント・サーバモデル #

HTTP は ステートレスなリクエスト・レスポンス型 のプロトコルである。クライアントが要求 (リクエスト) を送り、サーバが応答 (レスポンス) を返す。この 1 往復を HTTP トランザクション と呼ぶ。サーバ側は基本的に過去のリクエストを覚えていない (= ステートレス)。状態を引き継ぐ必要があるときは Cookie やセッション、JWT などで補う。

HTTP メッセージの中身 #

通信内容は テキストベース の HTTP メッセージで表現される。リクエスト行 / ステータス行 + ヘッダ + 空行 + ボディ という 4 ブロック構造は HTTP/1.x の世代で共通。HTTP/2 以降はバイナリ化されてフレームに分割されるが、論理構造は変わらない。

リクエスト例 #

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,*/*
Cookie: session=abc123

リクエストライン: メソッド (GET) / パス (/index.html) / プロトコルバージョン (HTTP/1.1)
ヘッダ: 名前: 値の形式で複数行。Host, User-Agent, Accept, Cookie, Authorization など
空行: ヘッダとボディの境界
ボディ: POST / PUT などで送るデータ本体 (フォーム、JSON など)

レスポンス例 #

HTTP/1.1 200 OK
Date: Sun, 17 May 2026 00:00:00 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 1234
Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Lax

<html>
...
</html>

ステータスライン: プロトコルバージョン / ステータスコード (200) / 説明文 (OK)
ヘッダ: Content-Type, Content-Length, Set-Cookie, Cache-Control など
ボディ: 実コンテンツ

HTTP メソッド #

メソッド	用途	ボディ	冪等性
`GET`	リソース取得	なし	あり
`POST`	新規作成 / 任意処理	あり	なし
`PUT`	リソース全体置換	あり	あり
`PATCH`	リソース部分更新	あり	なし
`DELETE`	リソース削除	任意	あり
`HEAD`	ヘッダのみ取得 (`GET` のメタ情報版)	なし	あり
`OPTIONS`	サポートメソッド問い合わせ (CORS プリフライトで多用)	なし	あり

冪等性 (idempotency) があるメソッドは「同じリクエストを何度送っても結果が変わらない」性質を持ち、リトライ可能。POST は冪等でないため二重送信防止の設計が必要になる。

ステータスコード #

3 桁の数字で、先頭の数字が大分類を示す。

系統	意味	代表例
1xx	情報	`100 Continue` / `101 Switching Protocols`
2xx	成功	`200 OK` / `201 Created` / `204 No Content`
3xx	リダイレクト	`301 Moved Permanently` / `302 Found` / `304 Not Modified`
4xx	クライアント側エラー	`400 Bad Request` / `401 Unauthorized` / `403 Forbidden` / `404 Not Found` / `429 Too Many Requests`
5xx	サーバ側エラー	`500 Internal Server Error` / `502 Bad Gateway` / `503 Service Unavailable` / `504 Gateway Timeout`

401 と 403 は混同されやすい。401 は「認証していない」、403 は「認証はしているが権限がない」 を意味する。

重要な HTTP ヘッダ #

セキュリティ・パフォーマンスに直結するヘッダだけ列挙する。

リクエスト側

Host: 仮想ホスト識別。1 つの IP で複数ドメインを区別する
User-Agent: クライアント識別。WAF や bot 検知の判定材料
Cookie: 過去にサーバから Set-Cookie で受け取った値を毎回送信
Authorization: Basic、Bearer <token> などの認証情報
Referer: 直前のページ URL (タイポではない)

レスポンス側

Set-Cookie: クライアントにクッキーを発行
Content-Type: MIME タイプ (例: application/json; charset=UTF-8)
Cache-Control: キャッシュ動作の指定 (no-store, max-age=3600 など)
Strict-Transport-Security (HSTS): 強制的に HTTPS で接続させる
Content-Security-Policy (CSP): スクリプト読み込み元を制限し、XSS を抑制
X-Frame-Options / Content-Security-Policy: frame-ancestors: クリックジャッキング対策

Cookie とセッション #

HTTP はステートレスなので、ログイン状態などを維持するには Cookie を使う。Set-Cookie で発行し、クライアントは以降のリクエストの Cookie ヘッダで送り返す。

セッションハイジャックを防ぐため、現代では以下の属性を必ず付与する。

Secure: HTTPS でのみ送信。HTTP 経由では送らない
HttpOnly: JavaScript の document.cookie から読み取れない。XSS で盗まれにくい
SameSite=Lax / Strict: 別オリジンからのリクエストでは送信しない。CSRF 対策
Expires / Max-Age: セッション Cookie か永続 Cookie かを制御

HTTP のバージョン進化 #

バージョン	特徴
HTTP/1.0 (1996)	リクエストごとに TCP 接続を張る (重い)
HTTP/1.1 (1997)	Keep-Alive で接続再利用、パイプライン (実用化は限定的)
HTTP/2 (2015)	バイナリフレーム、多重化で 1 接続で並列リクエスト、ヘッダ圧縮 (HPACK)
HTTP/3 (2022)	QUIC (UDP ベース) でハンドシェイクを最小化、パケットロス時の HoL ブロッキング解消

HTTP/2 では HTTP/1.1 で問題だった head-of-line blocking (TCP 順序保証で 1 パケット欠損が後続全部を止める) を緩和したが、TCP 層では残った。HTTP/3 は QUIC が UDP 上にストリーム多重化を実装することで、トランスポート層の HoL ブロッキングも解消する。

HTTPS の仕組み #

HTTPS = HTTP + TLS (Transport Layer Security)。TLS は以下 3 つを同時に達成する。

暗号化 — 通信内容を第三者から見えなくする (機密性)
改ざん検知 — メッセージ認証コードで内容の改ざんを検知 (完全性)
サーバ認証 — 証明書でサーバが本物だと確認 (真正性)

TLS ハンドシェイクの流れ (TLS 1.3 簡略) #

Client Hello — クライアントが対応する暗号スイート一覧と乱数を送る
Server Hello — サーバが暗号スイートを選び、証明書 と公開鍵を返す
鍵交換 — Diffie-Hellman 鍵共有で セッション鍵 を双方で生成 (盗聴者には解読不能)
Finished — ハンドシェイク完了。以降は AES-GCM などの対称暗号で通信

TLS 1.3 ハンドシェイクの 4 ステップを示す図

TLS 1.2 までは 2 往復必要だったが、TLS 1.3 では 1 往復 (1-RTT)、再接続なら 0-RTT で済む。

証明書と認証局 #

サーバ証明書は 認証局 (CA) が発行する。クライアントは OS / ブラウザに同梱された ルート CA の公開鍵で証明書チェーン (サーバ証明書 → 中間 CA → ルート CA) を検証し、信頼できる場合のみ TLS 接続を完成させる。

検証段階によって 3 種類:

DV (Domain Validation): ドメイン所有のみ確認。Let's Encrypt など無料発行が普及
OV (Organization Validation): 組織実在性も確認
EV (Extended Validation): より厳格な実在性確認 (旧緑バー表示は現在廃止)

セキュリティ上の落とし穴 #

サーバ管理者・開発者の観点で注意したい代表例。

MITM (中間者攻撃) — 公衆 Wi-Fi などで攻撃者が経路に割り込み、リクエストを盗聴・改ざん。HTTPS と正しい証明書検証で防ぐ
SSL Stripping — HTTPS リダイレクトを攻撃者がブロックし、HTTP に降格させて盗聴。HSTS (Strict-Transport-Security) を返すことで以降ブラウザが HTTPS を強制
HSTS Preload — Chrome / Firefox 等が同梱するプリロードリストにドメインを登録すると、初回アクセスから HTTPS 強制
Mixed Content — HTTPS ページが HTTP リソース (画像 / スクリプト) を読み込むと TLS の保護が崩れる。upgrade-insecure-requests CSP ディレクティブで自動 HTTPS 化
Cookie 属性の不備 — Secure / HttpOnly / SameSite を付け忘れるとセッションハイジャック / XSS / CSRF のリスク
証明書ピン留め (Pinning) のリスク — 厳格にピン留めしすぎると CA 更新時に通信不能。HTTP Public Key Pinning (HPKP) は廃止された
Heartbleed (CVE-2014-0160) など TLS 実装のバグ — OpenSSL を最新に保つことが防御の前提

ペネトレーションテストでは、Burp Suite や mitmproxy で TLS 通信を 手元のローカル CA で復号して中身を確認する手法が定番。これは「証明書検証を一時的に緩める」操作で、本番運用では絶対に行わないこと。