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]

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) を以下にまとめる。

CloudFront での HTTP/2 / HTTP/3

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

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

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

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

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