HTTP — 知星図

概要

HTTP（HyperText Transfer Protocol）は、ブラウザとサーバの間の「会話のルール」です。クライアントが「このURLのリソースが欲しい」というリクエストを送り、サーバがステータスコードと本文（ボディ）で応答する——このリクエスト・レスポンスの往復ひとつが、Webのすべての通信の基本形になっています。

ページを1枚開くだけでも、HTML、CSS、JavaScript、画像と、実際には何十回ものHTTP往復が発生しています。また、Webページの取得だけでなく、APIの呼び出し（多くはJSONのやり取り）にも同じHTTPが使われるため、フロントエンドからバックエンドまで、Web開発者が最も頻繁に触れるプロトコルだと言えます。

メソッド、ステータスコード、ヘッダ、キャッシュ制御——Web開発の語彙の多くはHTTPの仕様に由来します。HTTPを理解することは、Webの共通言語を身につけることそのものです。

なぜ生まれたか

1989年、CERNの研究者ティム・バーナーズ＝リーは、世界中に散らばる研究文書を相互にリンクして辿れる仕組み（World Wide Web）を構想しました。文書を識別するURL、文書を記述するHTML、そして文書を取り寄せるためのプロトコル——この3点セットの通信担当として生まれたのがHTTPです。

当時すでにFTPなどのファイル転送プロトコルはありましたが、接続やログインの手順が重く、「リンクをクリックしたら即座に文書が届く」体験には向きませんでした。HTTPは「1回のリクエストに1回のレスポンスを返して終わり」という極端にシンプルな設計を選んだことで、実装が容易になり、爆発的に普及しました。このシンプルさ（特に、サーバが過去のやり取りを覚えない「ステートレス」という性質）は、後にCookieやセッションという補完の仕組みを生む原因にもなります。

詳細

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

HTTPのやり取りはテキストで表現できるほど素直な構造をしています。リクエストは「メソッド + パス + バージョン」の1行（リクエストライン）で始まり、続いてヘッダ群、空行を挟んでボディが続きます。レスポンスも同様に「バージョン + ステータスコード」の1行から始まります。

メソッドはリクエストの「動詞」です。取得のGET、送信のPOSTが二大巨頭で、更新のPUT/PATCH、削除のDELETEなどが続きます。この動詞をリソース指向で使い分ける設計思想がREST APIです。ステータスコードは結果の要約で、2xxが成功（200 OK）、3xxがリダイレクト（301/302）、4xxがクライアント側の誤り（404 Not Found、403 Forbidden）、5xxがサーバ側の障害（500/503）という区分を覚えておくと、トラブルの切り分けが一気に楽になります。

ヘッダはリクエスト・レスポンスに付くメタ情報です。ボディの形式を示すContent-Type、キャッシュの可否と期限を制御するCache-Control、Cookieを運ぶSet-Cookie / Cookie、認証情報を載せるAuthorizationなど、Webアプリの挙動の多くはヘッダで制御されています。

ステートレスという設計

HTTPの重要な性質が「ステートレス」——サーバは各リクエストを独立したものとして扱い、前回のやり取りを覚えていない、という点です。この割り切りのおかげでサーバは実装が単純になり、どのサーバがどのリクエストを処理しても構わなくなるため、ロードバランサによる水平分散とも相性が良くなりました。一方で「ログイン状態を保つ」といった要求には別の仕組みが必要になり、Cookieとセッションがその穴を埋めています。

バージョンの進化

HTTPはTCP/IPの上で動くことを前提に進化してきました。HTTP/1.0では1リクエストごとにTCP接続を張り直していましたが、HTTP/1.1で接続の使い回し（Keep-Alive）が標準になりました。それでも「1つの接続では一度に1つのリクエストしか処理できない」制約が残り、ブラウザは複数接続を張って凌いでいました。2015年のHTTP/2は1本の接続に複数のやり取りを多重化してこの詰まり（Head-of-Lineブロッキング）を緩和し、HTTP/3ではTCPを捨ててUDPベースのQUICに乗り換えることで、パケットロス時の詰まりまで解消しています。バージョンが変わっても、メソッド・ステータスコード・ヘッダという意味論は一貫して同じです。

実務での視点

実務でHTTPの理解が効くのは、まずデバッグの場面です。ブラウザの開発者ツールのNetworkタブでリクエストとレスポンスを読めれば、「404だからパスが違う」「CORSのプリフライトで止まっている」「Cache-Controlが効きすぎて更新が反映されない」といった問題を自力で特定できます。また、GETは何度実行しても安全（冪等）だがPOSTはそうではない、という性質の違いは、リトライ設計やキャッシュ設計の土台になります。

なお、素のHTTPは平文で流れるため、盗聴も改ざんも可能です。現代のWebではTLSで暗号化したHTTPSを使うことが事実上の前提であり、素のHTTPは開発環境以外ではほぼ登場しません。また、HTTPの「クライアントから聞かれたら答える」一方向性を超えてサーバから任意のタイミングでデータを送りたい場合は、HTTPから昇格して使うWebSocketが選択肢になります。