HTTP/2

HTTP/2 とは

HTTP/2 は、2015 年に RFC 7540 として標準化された HTTP プロトコルのメジャーバージョンで、HTTP/1.1 の性能限界 (Head-of-Line Blocking、多数の TCP 接続) を解消する。Google の SPDY プロトコルがベースになっている。現行の仕様は 2022 年 6 月の RFC 9113 で、RFC 7540 はこれに置き換えられた (仕様値を確認するときは RFC 9113 を見る)。

HTTP/1.1 の問題

HTTP/1.1 の問題を図で示す。

HTTP/1.1: 1 つの TCP 接続で 1 リクエストずつ (直列)
  [リクエスト1] → [レスポンス1] → [リクエスト2] → [レスポンス2]

  ブラウザは 6 本の TCP 接続を並列に開いて回避 → 接続コストが高い

HTTP/2 の改善

HTTP/2 の改善を図で示す。

HTTP/2: 1 つの TCP 接続で複数リクエストを多重化 (並列)
  ストリーム1: [リクエスト1] → [レスポンス1]
  ストリーム2: [リクエスト2] → [レスポンス2]  ← 同時に処理
  ストリーム3: [リクエスト3] → [レスポンス3]

機能	HTTP/1.1	HTTP/2
多重化	1 接続で 1 リクエストずつ処理する	1 接続に複数のやり取りを同時に流せる
ヘッダー圧縮	毎回そのまま送るため重複が多い	HPACK (RFC 7541) でテーブルのインデックス参照に置き換える
バイナリフレーム	テキスト形式で送る	バイナリの枠に分割して送る
サーバープッシュ	仕組みが無い	仕様上は存在するが主要ブラウザが対応を外し利用は限定的
必要な TCP 接続数	6 本	1 本

HPACK (RFC 7541) は「前回との差分」を計算して送るのではない。頻出ヘッダーを収めた静的テーブルと、接続ごとに育つ動的テーブルへのインデックス参照に置き換え、残った文字列にハフマン符号化をかける。覚えているのはテーブルの中身であって、変更点ではない。

ブラウザが HTTP/2 を話すのは TLS 上 (ALPN で h2 を交渉できた場合) だけである。平文で HTTP/2 を始める h2c (HTTP/1.1 の Upgrade を使う方法) は普及せず、RFC 9113 で非推奨になった。リバースプロキシとアプリケーションサーバーの間を平文にしている構成では、両側に「最初から HTTP/2 で話す」設定を入れない限り HTTP/1.1 のままになる。

HTTP/3 (QUIC)

HTTP/3 (QUIC) を以下にまとめる。

観点	HTTP/2	HTTP/3
トランスポート	TCP	QUIC (UDP ベース)
HoL Blocking	TCP レベルで発生	ストリームごとに独立
接続確立	TCP + TLS で 2 RTT (TLS 1.3) 〜 3 RTT (TLS 1.2)	初回 1 RTT・再接続時は 0-RTT
対応状況 (2026 年 8 月時点)	ほぼ全ブラウザ	主要ブラウザ対応済み

CloudFront での HTTP/2 / HTTP/3

CloudFront はデフォルトで HTTP/2 をサポートし、HTTP/3 もオプションで有効化できる。

フロントエンド開発への影響

HTTP/2 の多重化により、リクエスト数を削ること自体を目的にした HTTP/1.1 時代のテクニックは前提を失った。ただし全部やめてよいわけではなく、圧縮率と初期描画への効き方で判断が変わる。

テクニック	HTTP/1.1	HTTP/2
CSS スプライト	必要 (リクエスト数削減)	ほぼ不要 (個別画像の方が差し替えやすい)
ファイル結合	必要	キャッシュ効率なら分割有利・圧縮率なら結合有利
ドメインシャーディング	必要 (接続数制限の回避)	逆効果 (多重化が使えない)
インライン化	有効	初期描画に必要な最小限の CSS には今も有効

分割しすぎれば別の代償が出る。gzip や Brotli は 1 ファイルが大きいほど既出のパターンを再利用できるため、細かく割ると合計の転送量は増える。リクエストごとの処理コスト (キャッシュ検証、JavaScript の解析開始) も多重化では消えない。目安は「更新頻度が違うものは分ける・同じものは束ねる」で、ファイル数そのものを目標にしない。

実務での活用方法は関連書籍にも詳しい。