HTTP とは

HTTP (HyperText Transfer Protocol) は、Web ブラウザと Web サーバーの間でデータをやり取りするための通信プロトコルです。1991 年に Tim Berners-Lee が World Wide Web とともに設計した HTTP/0.9 が起源で、HTML ドキュメントの転送を目的としていました。HTML に限らず、画像、動画、JSON データ、API レスポンスなど、Web 上のあらゆるリソースの転送に使われています。仕様は 2022 年 6 月に RFC 9110 (HTTP の意味論)、RFC 9111 (キャッシュ)、RFC 9112 (HTTP/1.1 のメッセージ構文) として再編され、長く参照されてきた RFC 2616 や RFC 7230 系は廃止扱いになりました。

ブラウザのアドレスバーに URL を入力すると、裏側では HTTP リクエストがサーバーに送信され、サーバーが HTTP レスポンスを返す - この往復が Web ページ表示の基本的な仕組みです。HTTP はステートレス (状態を持たない) なプロトコルであり、各リクエストは独立して処理されます。ログイン状態の維持などには Cookie や認証トークンを併用する必要があります。

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

HTTP 通信は「クライアントがリクエストを送り、サーバーがレスポンスを返す」という単純なモデルで成り立っています。

メソッド (GET, POST, PUT, DELETE など) でサーバーに対する操作を指定し、URL パスで対象リソースを示す。ヘッダーにはブラウザの種類 (User-Agent)、受け入れ可能なデータ形式 (Accept)、認証情報 (Authorization) などのメタデータが含まれる。POST や PUT ではボディにフォームデータや JSON を格納して送信する。

ステータスコード (200, 404, 500 など) で処理結果を示し、ヘッダーにはコンテンツの種類 (Content-Type)、キャッシュ制御 (Cache-Control)、セキュリティヘッダーなどが含まれる。ボディには HTML、JSON、画像バイナリなど実際のデータが格納される。

GET リクエストはリソースの取得に使い、原則としてボディを持ちません。RFC 9110 は GET のボディに一般に定義された意味はないとしており、クライアントはボディを付けるべきでないと規定しています。POST はデータの送信 (フォーム送信、API 呼び出し) に使い、ボディにデータを含めます。REST API では PUT (更新)、DELETE (削除)、PATCH (部分更新) も頻繁に使われます。

主要なステータスコード

HTTP ステータスコードは 3 桁の数字で、レスポンスの種類を示します。先頭の数字でカテゴリが決まります。

200 OK はリクエスト成功。201 Created はリソースの新規作成成功。204 No Content は成功したがレスポンスボディなし (DELETE 後など)。

301 Moved Permanently は恒久的な URL 変更。Google は、このリダイレクトを「移転先こそが正規の URL である」というシグナルとして扱うと説明している。302 Found は一時的なリダイレクト。304 Not Modified はキャッシュが有効であることを示す。

400 Bad Request はリクエストの構文エラー。401 Unauthorized は認証が必要。403 Forbidden はアクセス権限なし。404 Not Found はリソースが存在しない。429 Too Many Requests はレート制限超過。

500 Internal Server Error はサーバー側の汎用エラー。502 Bad Gateway はリバースプロキシがバックエンドから不正な応答を受けた場合。503 Service Unavailable はサーバーが一時的に利用不可 (メンテナンス、過負荷)。

ステータスコードは API 設計においても重要です。適切なコードを返すことで、クライアント側のエラーハンドリングが容易になり、デバッグ効率が向上します。

HTTP のバージョンと進化

HTTP は 1991 年の HTTP/0.9 から 30 年以上にわたって進化を続けており、各バージョンでパフォーマンスと効率が大幅に改善されています。

2026 年 8 月時点でも広く使われている基幹バージョン。1997 年 1 月の RFC 2068 で規定され、2022 年 6 月に RFC 9112 として再編された。Keep-Alive による接続の再利用、チャンク転送エンコーディング、Host ヘッダーによるバーチャルホストをサポート。ただし 1 つの TCP 接続で同時に 1 つのリクエストしか処理できず、Head-of-Line Blocking (先頭のリクエストが詰まると後続が待たされる) が課題。

Google の SPDY プロトコルを基に 2015 年 5 月の RFC 7540 で標準化され、2022 年 6 月に RFC 9113 へ改訂。1 つの TCP 接続上で複数のリクエスト・レスポンスを並行処理する多重化 (Multiplexing) を実現し、ヘッダー圧縮 (HPACK) でオーバーヘッドを削減。クライアントが要求する前にリソースを送るサーバープッシュも規定されているが、Chrome は 2022 年 9 月の Chrome 106 で既定無効化し、代替として 103 Early Hints が推奨されている。TCP レベルの Head-of-Line Blocking も残存。

2022 年 6 月の RFC 9114 で標準化。TCP の代わりに QUIC (UDP ベース・RFC 9000) を採用し、TCP レベルの Head-of-Line Blocking を解消。ハンドシェイクは初回接続が 1-RTT で、一度接続した相手には 0-RTT での再開が使える。通信相手を IP アドレスではなく接続 ID で識別するため、モバイル環境で Wi-Fi とセルラーが切り替わっても通信が途切れにくい。利用できるかどうかはサーバーが Alt-Svc ヘッダーなどで通知し、対応しないクライアントは HTTP/2 以下にフォールバックする。

HTTP/2 と HTTP/3 は実質的に HTTPS が前提です。主要ブラウザは暗号化されていない HTTP/2 接続をサポートしておらず、HTTP/3 は QUIC 自体に TLS 1.3 が組み込まれています。プロトコルの高速化とセキュリティの強化は表裏一体で進んでいます。

HTTP と HTTPS の関係

HTTP は通信内容を平文のまま送受信するため、ネットワーク上の第三者に盗聴・改ざんされるリスクがあります。HTTPS は HTTP に TLS による暗号化層を追加したプロトコルで、通信経路のセキュリティを確保します。

HTTP: ポート 80 を使用。通信は平文。2026 年 8 月時点の Chrome はアドレスバーに「保護されていない通信」と表示し、Chrome や Safari は HTTP のページ遷移を自動的に HTTPS へ格上げしようとします。
HTTPS: ポート 443 を使用。TLS で暗号化。Google は 2014 年 8 月に HTTPS を検索順位のシグナルとして使い始めたと公表しており、発表時の説明では「グローバルなクエリの 1 % 未満に影響する、非常に軽いシグナル」とされていました。

HTTP はプロトコルとしての基盤であり、HTTPS は HTTP の上に暗号化を重ねた拡張です。HTTP のリクエスト・レスポンスモデル、メソッド、ステータスコードといった仕組みは HTTPS でもそのまま使われています。開発者ツールで通信を観察する際も、HTTP の構造を理解していることが前提になります。

実務で誤解しやすいのは、暗号化されているかどうかをアドレスバーの見た目で判断してしまうことです。Chrome は 2023 年 9 月の Chrome 117 で鍵アイコンを廃止し、サイト設定を開く「tune」アイコンに置き換えました。鍵マークの有無ではなく、URL のスキームが https:// かどうかで判断する必要があります。また HTTPS が保証するのは通信経路の暗号化と接続先ドメインの確認までで、サイト運営者の信頼性や掲載内容の正しさは保証しません。フィッシングサイトも無料の証明書で HTTPS を利用できるためです。

よくある誤解

HTTP と HTTPS は全く別のプロトコル: HTTPS は HTTP に TLS 暗号化を追加したものであり、リクエスト・レスポンスの構造やメソッド、ステータスコードは HTTP と同一です。HTTP の仕組みを理解していれば HTTPS の理解も容易です。違いは TLS による暗号化層の有無と、それに伴う URL スキームや既定ポート (80 と 443) の差です。
HTTP/2 や HTTP/3 にすればサイトが必ず速くなる: HTTP/2 の多重化や HTTP/3 の QUIC は通信効率を改善しますが、サーバー側の処理速度、データベースのクエリ時間、フロントエンドのレンダリング性能がボトルネックの場合は体感速度が変わらないこともあります。プロトコルの高速化はネットワーク層の改善であり、アプリケーション全体の最適化とは別の話です。
HTTP はもう使われていない古い技術: HTTPS が事実上の標準になった後も、HTTP のプロトコル仕様自体は HTTPS の基盤として使われ続けています。また、ローカル開発環境やイントラネット、IoT デバイス間の通信など、暗号化が不要な場面では HTTP が直接使われることもあります。

HTTP