HTTP とは

HTTP (HyperText Transfer Protocol) は、Web ブラウザと Web サーバーの間でデータをやり取りするための通信プロトコルです。1991 年に Tim Berners-Lee が World Wide Web とともに設計した HTTP/0.9 が起源で、HTML ドキュメントの転送を目的としていました。現在では HTML に限らず、画像、動画、JSON データ、API レスポンスなど、Web 上のあらゆるリソースの転送に使われています。

ブラウザのアドレスバーに 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 リクエストはリソースの取得に使い、ボディを持ちません。POST はデータの送信 (フォーム送信、API 呼び出し) に使い、ボディにデータを含めます。REST API では PUT (更新)、DELETE (削除)、PATCH (部分更新) も頻繁に使われます。

主要なステータスコード

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

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

301 Moved Permanently は恒久的な URL 変更。SEO 上、旧 URL の評価が新 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 は 30 年以上にわたって進化を続けており、各バージョンでパフォーマンスと効率が大幅に改善されています。

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

Google の SPDY プロトコルを基に標準化。1 つの TCP 接続上で複数のリクエスト・レスポンスを並行処理する多重化 (Multiplexing) を実現。ヘッダー圧縮 (HPACK) でオーバーヘッドを削減し、サーバープッシュでクライアントが要求する前にリソースを送信可能。ただし TCP レベルの Head-of-Line Blocking は残存。

TCP の代わりに QUIC (UDP ベース) を採用し、TCP レベルの Head-of-Line Blocking を解消。接続確立が高速 (0-RTT ハンドシェイク) で、モバイル環境での Wi-Fi とセルラーの切り替え時にも接続が途切れにくい。Google、Cloudflare、Meta など大手サービスで採用が進んでいる。

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

HTTP と HTTPS の関係

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

HTTP: ポート 80 を使用。通信は平文。ブラウザに「保護されていない通信」と警告が表示される。
HTTPS: ポート 443 を使用。TLS で暗号化。鍵マークが表示され、SEO 上も有利。

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

よくある誤解

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

HTTP