HTTP/2は2015年にRFC 7540として標準化されたHTTPの第2世代バージョンです。多重化、バイナリフレーミング、HPACK圧縮、サーバープッシュなどの機能でWebの高速化を実現します。

HTTP/2 | 用語集 | IT/AIエンジニア　野口真一

Q: HTTP/2とHTTP/3の違いは？

HTTP/2はTCP上で動作しTCPレベルのHead-of-Lineブロッキングがありますが、HTTP/3はQUIC（UDP上）で動作しこの問題を解消しています。HTTP/3は0-RTT接続確立にも対応しています。

Q: NginxでHTTP/2を有効化するにはどうすればよいですか？

server ブロックのlistenディレクティブに http2 パラメータを追加し、TLS証明書を設定します。多くのブラウザはTLS（HTTPS）接続でのみHTTP/2を利用するため、SSL証明書の設定が事実上必須です。

HTTP/2とは

HTTP/2は、2015年にRFC 7540として標準化されたHTTPプロトコルの新バージョンです。Googleが開発したSPDYプロトコルをベースとして設計され、HTTP/1.1の約15年ぶりの大幅な改訂となりました。Webページの表示速度を向上させることを主な目的としています。

SEO 最強のワードプレステーマはこれ!

国内最高峰のSEO最適化WPテーマ「ゴールドメディア」

多重化（Multiplexing）

HTTP/2の最も重要な機能は多重化です。1つのTCP接続上で複数のリクエストとレスポンスを並行して処理できるため、HTTP/1.1で問題となっていたヘッドオブラインブロッキングが解消されます。これにより、ページの読み込み速度が大幅に向上します。

バイナリフレーミング

HTTP/2では、テキストベースだったHTTP/1.1とは異なり、バイナリ形式でデータを送受信します。バイナリフレーミング層により、データをフレームという小さな単位に分割し、効率的な通信を実現しています。

SEO 最強のワードプレステーマはこれ!

国内最高峰のSEO最適化WPテーマ「ゴールドメディア」

ヘッダー圧縮

HPACK圧縮アルゴリズムを使用して、HTTPヘッダーを効率的に圧縮します。重複するヘッダー情報を省略し、ハフマン符号化により通信量を削減します。これは特に、多数の小さなリクエストを行うWebアプリケーションで効果を発揮します。

サーバープッシュ

サーバープッシュ機能により、クライアントがリクエストする前に、サーバー側から必要なリソースを先行して送信できます。HTMLファイルを要求されたときに、CSSやJavaScriptファイルも同時に送信することで、ページの表示速度を向上させます。

ストリーム優先度制御

HTTP/2では、各ストリームに優先度を設定できます。重要なリソースを優先的に送信することで、ユーザー体験を最適化します。たとえば、表示に必要なCSSを画像よりも優先して送信できます。

設定例：NginxでのHTTP/2有効化

WebサーバーでHTTP/2を有効にする代表的な例として、Nginxの設定を示します。多くのブラウザはTLS（HTTPS）接続でのみHTTP/2を使用するため、SSL証明書の設定と併せて行うのが一般的です。

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    location / {
        root /var/www/html;
        index index.html;
    }
}

設定後、実際にHTTP/2で応答しているかはcurlで確認できます。

# --http2 オプションでHTTP/2を強制し、レスポンスのプロトコルバージョンを確認
curl -v --http2 https://example.com/ 2>&1 | grep "HTTP/2"

メリット・デメリット

メリット

読み込み速度の向上：多重化により1接続で多数のリソースを並行取得でき、HTTP/1.1のドメインシャーディングのような回避策が不要になります。
通信量の削減：HPACKによるヘッダー圧縮で、Cookieなど繰り返し送信される冗長なヘッダー情報を効率化します。
優先度制御による体感速度向上：重要なリソースを優先的に配信し、レンダリングに必要なCSSなどを早期に取得できます。

デメリット

TCPレベルのHoLブロッキングは未解決：アプリケーション層では多重化されていても、TCPでパケットロスが起きると全ストリームが待たされます。
バイナリ形式でデバッグしにくい：HTTP/1.1のようにテキストをそのまま読めないため、Wiresharkのプロトコル解析やブラウザの開発者ツールが実質的に必須になります。
サーバープッシュの形骸化：当初の目玉機能だったサーバープッシュは多くのブラウザで非推奨・廃止されており、103 Early Hintsなど代替手段への移行が必要です。
実装の複雑さ：ストリーム管理や優先度制御など、HTTP/1.1に比べてサーバー・プロキシ実装が複雑になります。

HTTP/1.1・HTTP/2・HTTP/3の比較

項目	HTTP/1.1	HTTP/2	HTTP/3
トランスポート層	TCP	TCP	UDP（QUIC）
多重化	なし	ストリーム多重化	ストリーム多重化（TCP由来のHoLも解消）
ヘッダー圧縮	なし	HPACK	QPACK
接続確立	TCPハンドシェイク＋TLS	TCPハンドシェイク＋TLS	QUICハンドシェイク（0-RTT対応）

実務での活用シーンと導入時の注意点

画像・CSS・JSが多いWebサイト：多数の静的リソースを扱うサイトほど、多重化によるHTTP/2の恩恵が大きくなります。
API・マイクロサービス間通信：gRPCはHTTP/2を基盤としており、内部API通信でもHTTP/2化の効果があります。
ALPNの対応確認：クライアント・サーバー間でHTTP/2かHTTP/1.1かを決めるALPN（Application-Layer Protocol Negotiation）が正しく動作しているか、古いロードバランサーや中間プロキシで対応状況を確認する必要があります。
ドメインシャーディングの見直し：HTTP/1.1時代に行っていたリソースの複数ドメイン分割は、HTTP/2では接続数増加によるオーバーヘッドで逆効果になるため、単一ドメインへの統合が推奨されます。

導入と互換性

HTTP/2は、ほとんどの主要なWebブラウザとWebサーバーでサポートされています。HTTP/1.1との下位互換性も維持されており、段階的な移行が可能です。ただし、多くのブラウザはHTTP/2をTLS接続でのみサポートしています。nginx、Apache、Caddy、IISなど主要なWebサーバーがHTTP/2に対応しています。

HTTP/2の課題とHTTP/3への進化

HTTP/2はHTTP/1.1から大幅な改善を実現しましたが、TCPレベルのHead-of-Lineブロッキングという課題が残っています。HTTP/2の多重化はアプリケーション層で実現されていますが、TCP層では1つのパケットロスがすべてのストリームをブロックします。この問題を解決するため、HTTP/3ではQUIC（UDPベース）がトランスポート層として採用されました。

また、サーバープッシュ機能は2025年現在、多くのブラウザで非推奨となっています。103 Early Hintsヘッダーや、Service Workerによるプリキャッシュが代替手段として推奨されています。

2025-2026年の最新動向

HTTP/2は引き続きWebの主力プロトコルであり、2025年時点でWebサイトの約65%がHTTP/2を使用しています。HTTP/3の普及が進む一方、サーバー環境やファイアウォール設定の関係でHTTP/2が当面のデフォルトとなるケースも多くあります。

Webパフォーマンス最適化の観点では、HTTP/2のストリーム優先度制御の実装がブラウザ間で統一されつつあります。Chrome、Firefox、Safariが共通の優先度スキーム（RFC 9218 Extensible Prioritization Scheme）を実装し、より一貫したパフォーマンスが得られるようになっています。

外部リンク

よくある質問（FAQ）

Q. HTTP/2とは？

2015年にRFC 7540として標準化されたHTTPの第2世代バージョンです。多重化、ヘッダー圧縮、サーバープッシュなどの機能でWebの高速化を実現します。

Q. HTTP/2とHTTP/1.1の違いは？

HTTP/2は1つのTCP接続で複数リクエストを並行処理（多重化）でき、バイナリフレーミング、HPACK圧縮で通信効率が向上します。HTTP/1.1では接続あたり1リクエストが基本でした。

Q. HTTP/2とHTTP/3の違いは？

HTTP/2はTCP上で動作しTCPレベルのHoLブロッキングがありますが、HTTP/3はQUIC（UDP上）で動作しこの問題を解消。接続確立も0-RTTに対応しています。

Q. HTTP/2の普及状況は？

2025年時点でWebサイトの約65%がHTTP/2を使用。ほぼすべてのブラウザとWebサーバーが対応済みです。

Q. NginxでHTTP/2を有効化するにはどうすればよいですか？

serverブロックのlistenディレクティブにhttp2パラメータを追加し、TLS証明書を設定します。多くのブラウザはTLS（HTTPS）接続でのみHTTP/2を利用するため、SSL証明書の設定が事実上必須です。

AIエンジニアとしての実務経験

HTTP/2の恩恵を最も実感したのは、AI推論APIのパフォーマンス最適化プロジェクトでした。LLMを使ったチャットサービスで、ストリーミングレスポンス（Server-Sent Events）とHTTP/2の多重化を組み合わせることで、複数の会話セッションを1つの接続で効率的に処理できるようになりました。

特にgRPC（HTTP/2ベース）を使ったマイクロサービス間通信では、HTTP/2のバイナリプロトコルと双方向ストリーミングが威力を発揮しました。AI推論サービスとフロントエンドの間で、リクエストとレスポンスを同時に流すことで、体感遅延を大幅に削減できました。

注意点として、HTTP/2のサーバープッシュは実際にはあまり使われなくなっています。ブラウザのキャッシュとの相性が悪く、かえってパフォーマンスが低下するケースがあったため、現在は非推奨となっています。

HTTP/2の最新動向（2025年）

HTTP/3への移行: QUICベースのHTTP/3が主流に移行中
サーバープッシュ非推奨: Chrome等でサーバープッシュ機能の無効化
gRPCの普及: マイクロサービスでのHTTP/2ベースgRPC採用拡大
CDN最適化: HTTP/2接続の再利用による効率化
Early Hints: 103ステータスコードによるリソースヒント

よくあるトラブルと失敗例

TLS必須見落とし: HTTP/2は実質的にHTTPS必須。Let's Encrypt等で証明書取得
古いプロキシ: HTTP/2非対応のプロキシでダウングレード発生
接続数制限: HTTP/2でも同時ストリーム数に制限あり。100前後が一般的
デバッグ困難: バイナリプロトコルのため、Wiresharkでの解析が複雑に
サーバープッシュ失敗: キャッシュ済みリソースの重複送信でかえって遅延
ALPN非対応: 古いTLSライブラリでHTTP/2ネゴシエーション失敗

権威ある外部リソース

この用語についてもっと詳しく

HTTP/2に関するご質問や、Web高速化のご相談など、お気軽にお問い合わせください。

お問い合わせサービス一覧

HTTP/2