この記事の要点

HTTP/2 は HTTP/1.1 の性能課題を解決するために標準化された Web 通信プロトコル。意味 (メソッドやヘッダ) は HTTP/1.1 と同じで、伝送方式が刷新された 通信をテキストからバイナリの「フレーム」に変え、1 本の TCP 接続上で複数のリクエスト/レスポンスを多重化 (ストリーム) して並行処理する ヘッダを HPACK で圧縮し、繰り返し送られる似たヘッダの転送量を削減する サーバプッシュでクライアントが要求する前に関連リソースを先回りで送れる (ただし現在は非推奨化・削除の流れ) ブラウザ実装では事実上 TLS (HTTPS) 必須。ALPN で h2 をネゴシエーションして使う

概要

HTTP/2 は、Web のやり取りに使われる HTTP の性能を大きく改善した第 2 世代のバージョンです (2015 年に RFC 7540 として標準化、現在は RFC 9113)。メソッド (GET/POST など) やステータスコード、ヘッダといった HTTP の「意味」はそのままに、データをネットワーク上でどう運ぶかという「伝送方式」を全面的に作り替えた点が特徴です。アプリケーションから見れば同じ HTTP ですが、内部では大幅に高速化されています。親セクションは Web通信プロトコル です。

仕組み

HTTP/2 の高速化を支える要素は主に 3 つです。

• バイナリフレーミング: HTTP/1.1 はテキストで 1 行ずつ送っていましたが、HTTP/2 は通信を「フレーム」という小さなバイナリ単位に分割します。ヘッダ用 (HEADERS フレーム) と本文用 (DATA フレーム) などに分かれ、機械処理しやすくなります。
• ストリームによる多重化: 複数のリクエスト/レスポンスを「ストリーム」という論理的な通信路に割り当て、1 本の TCP 接続の上で並行してやり取りします。これにより HTTP/1.1 のアプリケーション層ヘッドオブラインブロッキング (前の応答待ちで後続が詰まる問題) が解消されます。
• ヘッダ圧縮 (HPACK): Cookie や User-Agent のように毎回似たヘッダが送られるため、HPACK という方式で差分・辞書圧縮を行い、転送量を削減します。

さらに サーバプッシュ という、クライアントが要求する前にサーバが関連リソース (CSS や JS など) を先回りで送る仕組みもありました。ただし実運用での効果が限定的で、主要ブラウザは対応を削除しており、現在は使わない方向です。

実用例

サーバが HTTP/2 で応答しているかは curl で確認できます。レスポンス先頭が HTTP/2 200 のようになっていれば HTTP/2 です。

# HTTP/2 でリクエストしてヘッダを確認
curl -I --http2 https://example.com/
# 出力例:
#   HTTP/2 200
#   content-type: text/html

# Nginx で HTTP/2 を有効化する設定例 (listen に http2 を付ける)
# server {
#     listen 443 ssl;
#     http2 on;            # 新しい書き方
#     server_name example.com;
#     ssl_certificate     /etc/ssl/example.crt;
#     ssl_certificate_key /etc/ssl/example.key;
# }

# どのプロトコルで接続したか詳細を見る (-v で ALPN: h2 を確認)
curl -v --http2 https://example.com/ 2>&1 | grep -i 'ALPN\|HTTP/2'

ブラウザでは開発者ツールの Network タブの Protocol 列に h2 と表示されれば HTTP/2 で通信しています。

主な用途

• 多リソースなページの高速化: 画像・CSS・JS を多数読み込むページで、多重化により読み込みを速くする。
• API の高スループット化: 1 接続で多数のリクエストを並行処理し、接続確立コストを抑える。
• gRPC の土台: gRPC は HTTP/2 の多重化・双方向ストリームを前提に設計されている。
• モバイル環境の改善: ヘッダ圧縮と多重化で、遅延の大きい回線でも体感速度を上げる。

HTTP/1.1 との比較

項目	HTTP/1.1	HTTP/2
伝送形式	テキスト	バイナリ (フレーム)
多重化	不可 (接続を複数張る)	1 接続で多重化 (ストリーム)
ヘッダ圧縮	なし	あり (HPACK)
サーバプッシュ	なし	あり (現在は非推奨)
トランスポート	TCP	TCP
TLS	任意	ブラウザでは事実上必須

注意点

• TCP レベルの HOL ブロッキングは残る: HTTP/2 はアプリ層の詰まりは解消するが、土台の TCP でパケットロスが起きると全ストリームが待たされる。これを解決するのが HTTP/3(QUIC)。
• ドメインシャーディングは逆効果: HTTP/1.1 時代の最適化 (リソースを複数ドメインに分散) は、1 接続多重化が効く HTTP/2 ではむしろ非効率になる。
• サーバプッシュは使わない: 効果が限定的で主要ブラウザが廃止済み。先読みは rel="preload" など別手段を使う。
• TLS 必須の実態: 規格上は平文 (h2c) も定義されるが、ブラウザは TLS 経由でしか HTTP/2 を使わない。証明書の準備が前提。

関連リンク

• Web通信プロトコル
• HTTP
• HTTPS
• HTTP/3(QUIC)
• gRPC
• TCP