HTTP/2（H2）とは？仕組み・メリット・導入時の注意点を現場目線で徹底解説
エバープレイ編集部H2とは — HTTP/2（通称 H2）の概要
「H2」は一般にウェブ技術の文脈で HTTP/2（Hypertext Transfer Protocol version 2）を指します。HTTP/2 はウェブ上の通信プロトコルである HTTP の第2世代規格で、主にページ読み込み性能の改善と効率化を目的に設計されました。2015年に IETF により RFC 7540（HTTP/2）として標準化され、同時にヘッダ圧縮方式として RFC 7541（HPACK）も規定されています。
設計の背景と目的
HTTP/1.1（1997年勧告）は長年にわたりウェブの基盤として使われてきましたが、画像やスクリプト、スタイルシートなど多くのリソースを同時に取得する現在のウェブにはいくつかの制約がありました。主な問題点は以下です：
- 同一接続あたりの同時並列リクエスト数が限定されている（ブラウザごとの制限）
- テキストベースのプロトコルであるため解析に手間がかかる
- ヘッダの冗長性（重複ヘッダによるオーバーヘッド）
- 複数ファイル取得のための多重接続による TCP オーバーヘッド
HTTP/2 はこれらの課題を解決するため、バイナリフレーミング、ストリームの多重化、ヘッダ圧縮、優先度制御、サーバプッシュなどの機能を導入しました。
主要な技術要素
HTTP/2 のコアとなる技術を要点ごとに説明します。
バイナリフレーミング
HTTP/2 はメッセージを「フレーム」と呼ばれるバイナリ単位で送受信します。これによりプロトコルの解析が機械的かつ効率的になり、拡張や中間機器での処理も容易になります。フレームは種類ごとに定義され、データ、ヘッダ、ウィンドウ更新、設定変更などが用意されています。
ストリームと多重化（Multiplexing）
一つの TCP 接続上で複数の「ストリーム」が並行して走り、それぞれ独立にリクエストとレスポンスをやり取りできます。これにより、HTTP/1.1 で必要だった多数の TCP 接続を張る手法が不要になり、接続数の削減、TLS ハンドシェイク回数の削減、遅延の改善が期待できます。
ヘッダ圧縮（HPACK）
HTTP/1.1 では毎回繰り返し送られるヘッダが冗長でオーバーヘッドを生んでいました。HPACK はヘッダ名・値を静的・動的なテーブルに格納し参照することで、同一接続内の重複を効率よく圧縮します。これにより、特に多くのクッキーや共通ヘッダを伴うリクエストで転送量が減ります。
優先度と依存関係
クライアントはストリームごとに優先度や依存関係を指定できます（ツリー構造）。これにより、サーバは重要度の高いリソースを先に送るなどの最適化が可能になります。ただし、実装や運用上の複雑さから、実際の効果はケースバイケースです。
サーバプッシュ
サーバは、クライアントの明示的な要求がなくても関連リソースを先回りして送信する「サーバプッシュ」機能を持ちます。理論上はラウンドトリップを削減できますが、キャッシュとの相性やネットワーク帯域の無駄遣い、実装の複雑さから実運用では限定的にしか使われないことが多く、ブラウザ側の挙動や CDN の対応状況に注意が必要です。
セキュリティと TLS（実装上の実情）
RFC 自体は HTTP/2 を平文（h2c）で動かす方法も規定しますが、実運用において主なブラウザは TLS 上での HTTP/2（h2）を要求しています。特に ALPN（Application-Layer Protocol Negotiation）拡張を使い、TLS ハンドシェイク中に HTTP/2 の利用をネゴシエートするのが一般的です。したがって、公開Webに対しては TLS（＝HTTPS）を設定することが実質的な前提です。
HTTP/1.x との違い（要点まとめ）
- テキスト→バイナリ：効率的で拡張しやすい
- 1リクエスト1接続→多重化されたストリーム：接続数削減、待ち時間低下
- ヘッダ圧縮（HPACK）：帯域の節約
- サーバプッシュ：先読み配信（ただし実務では慎重に運用）
HTTP/2 の制約と注意点
HTTP/2 は多くの性能改善をもたらしますが、万能ではありません。重要な点を列挙します。
- TCP 上に構築されているため、パケットロス発生時は TCP レベルの Head-of-Line（HOL）ブロッキングが残る。これが HTTP/3（QUIC）開発の背景の一つです。
- 中間のプロキシやロードバランサが HTTP/2 を理解していないと性能が劣化したり挙動が不安定になり得る。エンド・ツー・エンドで HTTP/2 が通るか確認すること。
- サーバプッシュは有効に使えば改善効果があるが、誤用は帯域浪費やキャッシュ無駄を招く。
- ヘッダ圧縮の実装には注意が必要。脆弱な実装はリスクを招くため、信頼できるライブラリや実績のあるサーバ実装を使うことが望ましい。
導入・運用の実務ポイント
サーバやインフラで HTTP/2 を有効化する際の実務的なチェックリスト：
- サーバソフトウェアが HTTP/2 をサポートしているか（Apache mod_http2, nginx 1.9.5+ の http2 モジュール、IIS、各 CDN など）。
- TLS 設定（ALPN 対応の TLS ライブラリ）を整備する。証明書やチェーンが正しく設定されているか確認。
- プロキシやロードバランサが HTTP/2 に対応しているか。非対応の場合はフロントで HTTP/2 を終端し、内部は HTTP/1.1 にフォールバックする構成が一般的。
- ブラウザ互換性：主要ブラウザは HTTP/2 をサポートしているが、古いクライアントでは HTTP/1.1 へフォールバックされることを念頭に。
- パフォーマンス測定：curl --http2 や nghttp2 のツール、ブラウザ DevTools、Lighthouse、h2load などで実測を行う。
HTTP/2 と HTTP/3 の関係
HTTP/3 は QUIC（UDP ベースのトランスポート）上に HTTP の概念を載せた次世代プロトコルで、TCP による HOL ブロッキング問題を解決します。HTTP/2 は現在広く使われており、HTTP/3 へ移行する流れが進んでいますが、完全移行には時間がかかるため、当面は HTTP/2 と HTTP/3 の共存が続きます。実務では両方をサポートする構成が望ましいでしょう。
デバッグと診断ツール
- curl —curl --http2/-I を使ってプロトコルネゴシエーションやレスポンスを確認
- nghttp2（nghttp, h2load） — HTTP/2 のクライアント/ベンチマークツール
- ブラウザ DevTools — ネットワークタブで protocol 列（h2/h3/https）を確認
- Wireshark — フレーム解析。ただし TLS で暗号化されていると復号が必要
- CDN/ロードバランサのログとメトリクス — TLS ネゴシエーション（ALPN）や接続の挙動を監視
いつ HTTP/2 を採用するべきか
一般的には新規サイトや既存サイトのパフォーマンス改善を図る場合、TLS を導入済みであれば HTTP/2 へアップグレードすることにほとんどデメリットはありません。特にリソース数が多いページ、CDN を活用している構成、TLS の最適化を行いたい場合に効果があります。ただし、プロキシやミドルボックスの互換性、サーバの実装状況、サーバプッシュ運用方針は検討が必要です。
まとめ
H2（HTTP/2）はウェブ通信の効率化を目指した主要な改良仕様で、バイナリフレーミング、ストリームの多重化、ヘッダ圧縮などを特徴とします。導入によって通信遅延やオーバーヘッドが減り、ページ表示改善が期待できますが、TCP ベースの制約や中間機器の互換性、サーバプッシュの扱いなど注意点もあります。将来的には HTTP/3（QUIC）への移行も進みますが、現状では HTTP/2 は広く実用的で推奨される選択肢です。
参考文献
- RFC 7540 — Hypertext Transfer Protocol Version 2 (HTTP/2)
- RFC 7541 — HPACK: Header Compression for HTTP/2
- MDN Web Docs — HTTP の概要（日本語）
- MDN Web Docs — HTTP/2 の仕組み（日本語）
- HTTP Working Group — HTTP/2 specifications
- Cloudflare — What happened to HTTP/2 server push?
- Google Developers — HTTP/2 (Web Fundamentals)
投稿者プロフィール
