WEB PROTOCOL
HTTP/1.1 vs HTTP/2（多重化と直列処理の比較）
HTTP/1.1の直列処理とHTTP/2の多重化の違い。Head-of-line blockingの影響を比較する
解説
1HTTP/1.1 vs HTTP/2 とは
HTTP/2は、HTTP/1.1の後継プロトコルで、2015年にRFC 7540として標準化されました。 Webページの読み込み速度を大幅に向上させるために設計されています。分かりやすいアナロジーで説明すると、HTTP/1.1は料金所が6つある高速道路のようなものです。 各料金所（TCP接続）では車（リクエスト）が1台ずつ順番に通過し、前の車が遅いと後ろの車も待たされます（Head-of-line blocking）。一方、HTTP/2は1本の道路に無制限の車線がある高速道路です。 1本のTCP接続の中で複数のリクエストが同時に並行して流れるため、1つの遅いリクエストが他をブロックしません。 上のビジュアライザーで「HOL blockingデモ」シナリオを選ぶと、この違いが鮮明に見えます。
2主な違い
- 🔀多重化（Multiplexing）：HTTP/2の最大の特徴です。1本のTCP接続で複数のリクエスト・レスポンスを同時に処理できます。HTTP/1.1ではドメインあたり最大6本のTCP接続を開き、各接続で1つずつ直列に処理していました。多重化により接続のオーバーヘッドが大幅に削減されます。
- 📦ヘッダー圧縮（HPACK）：HTTP/1.1ではヘッダーがプレーンテキストで毎回送信されていました。HTTP/2のHPAC圧縮は、ヘッダーの重複を除去し、ハフマン符号化でサイズを削減します。Cookieのような大きなヘッダーで特に効果的です。
- ⚡サーバープッシュ：サーバーがクライアントのリクエストを待たずに、必要になると予測されるリソースを先行送信できます。例えば、HTMLをリクエストされた時点で、そのHTMLが参照するCSSやJSをプッシュできます。
- 🔢ストリーム優先度：リソースに優先順位を付けられます。例えば、CSSとJSは画像より優先度を高く設定し、レンダリングブロッキングリソースを先に読み込むことで、体感速度を改善できます。
3ユースケース
大規模Webサイト
Google、Amazon、Netflixなどの大規模サイトでは、1ページに50〜100以上のリソースを読み込みます。HTTP/2の多重化により、接続数の制限なく並行読み込みが可能になり、ページロード時間が大幅に短縮されます。
SPA / API-heavy apps
React、Next.js、Vue.jsなどのSPAは、初期化時に多数のAPIを呼び出します。HTTP/2では10個以上のAPIリクエストを同時に送信でき、HTTP/1.1の6接続制限によるキュー待ちが解消されます。
モバイルアプリ
低帯域・高レイテンシのモバイル環境では、TCP接続のハンドシェイクコストが大きな影響を与えます。HTTP/2の単一接続モデルにより、接続確立のオーバーヘッドを最小化できます。
マイクロサービス
gRPCはHTTP/2上に構築されています。サービス間通信で双方向ストリーミングやヘッダー圧縮の恩恵を受け、効率的なRPC通信を実現します。Kubernetes内部のサービスメッシュでも広く利用されています。
4用語解説
多重化（Multiplexing）
1本のTCP接続上で複数のHTTPリクエスト/レスポンスを同時にやり取りする技術。HTTP/2の中核機能で、各リクエストは独立した「ストリーム」として処理されます。ただし、リソース間に依存関係がある場合は同時にリクエストできません。例えばフォントファイルはCSSの@font-faceで参照されるため、CSSのダウンロード・解析が完了するまでブラウザはフォントの存在を知らず、リクエストを送れません。多重化が効くのは「同時に発見されたリソース」に限られます。
ストリーム（Stream）
HTTP/2接続内の論理的な双方向チャネル。各ストリームには一意のID（奇数=クライアント発、偶数=サーバー発）が付与され、独立してデータを送受信します。
Head-of-line blocking
HTTP/1.1で、同じTCP接続上の先行リクエストのレスポンスが遅いと、後続のリクエストがすべてブロックされる問題。HTTP/2のストリームは独立しているため、アプリケーション層のHOL blockingは解消されます。
HPACK
HTTP/2のヘッダー圧縮アルゴリズム。静的テーブル（よく使われるヘッダー）と動的テーブル（接続中に学習したヘッダー）を使い、ヘッダーサイズを大幅に削減します。
サーバープッシュ
サーバーがクライアントのリクエストなしにリソースを先行送信する機能。HTMLを送信する際に、関連するCSS/JSを予測的にプッシュできます。ただし実装の複雑さから、Chrome 106以降では削除されています。
フレーム（Frame）
HTTP/2通信の最小単位。HEADERS、DATA、SETTINGS、PING、GOAWAYなど10種類のフレームタイプがあります。各フレームにはストリームIDが含まれ、同じTCP接続上で複数のストリームのフレームがインターリーブされます。
5HTTP/1.1 vs HTTP/2 比較表
| 項目 | HTTP/1.1 | HTTP/2 |
|---|---|---|
| 接続方式 | ドメインあたり最大6本のTCP接続 | 1本のTCP接続で多重化 |
| 多重化 | 非対応（直列処理） | 対応（ストリームで並行処理） |
| ヘッダー形式 | プレーンテキスト（毎回全送信） | HPACK圧縮（差分のみ送信） |
| サーバープッシュ | 非対応 | 対応（PUSH_PROMISE） |
| 優先度制御 | 非対応 | 対応（ストリーム優先度） |
| プロトコル | テキストベース | バイナリフレーム |
6通信の手順比較
1
TCP接続確立
HTTP/1.1: 6本のTCP接続を確立（3-wayハンドシェイク × 6）
HTTP/2: 1本のTCP接続を確立（3-wayハンドシェイク × 1）
2
リクエスト送信
HTTP/1.1: 各接続で1つずつ直列に送信。6接続を超えるリクエストはキューで待機
HTTP/2: すべてのリクエストを1本の接続で同時に並行送信
3
レスポンス受信
HTTP/1.1: レスポンスは送信順に受信（順序保証）。遅いレスポンスがあると後続が待たされる
HTTP/2: レスポンスは任意の順序で受信可能。先に完了したストリームから処理される
4
追加リクエスト
HTTP/1.1: 空き接続を待つ必要あり。すべて使用中の場合キュー待ちが発生
HTTP/2: 即時送信可能。新しいストリームを開いてすぐにリクエストできる
7Head-of-line blocking の詳細
Head-of-line（HOL）blockingは、先頭のリクエスト/レスポンスが遅い場合に、後続のリクエストがブロックされる問題です。 これはHTTPの各バージョンで異なるレベルで発生します。
HTTP/1.1 アプリケーション層HOL blocking
HTTP/1.1では、1つのTCP接続上でリクエストは厳密に順序付けられています。 レスポンスAが完了するまで、同じ接続上のリクエストBのレスポンスは送信できません。 遅いAPIレスポンスが1つあるだけで、同じ接続の他の全リクエストが待たされます。上のビジュアライザーで赤いハッチング領域がHOL blockingによる待機時間です。
HTTP/2 多重化で解消
HTTP/2では各ストリームが独立して処理されるため、アプリケーション層のHOL blockingは発生しません。 遅いストリームがあっても、他のストリームは影響を受けずに進行します。ただし、TCP層のHOL blockingはHTTP/2でも残ります。パケットロスが発生すると、TCPの再送待ちですべてのストリームが影響を受けます。 これを解決するのがHTTP/3（QUIC）です。
TCP層 HOL blocking（HTTP/2でも発生）
TCPはパケットの順序を保証するプロトコルです。パケットが1つでもロスすると、後続のパケットはすべて再送完了まで待機します。 HTTP/2は1本のTCP接続を使うため、パケットロスの影響がすべてのストリームに波及します。 HTTP/3はQUICプロトコル（UDP上に構築）を使い、ストリームごとに独立した再送制御を行うことで、この問題を完全に解決します。
8移行ガイド
サーバー設定
主要なWebサーバーはHTTP/2をネイティブサポートしています。設定変更だけで有効にできます。
Nginx
listen 443 ssl http2;Apache
Protocols h2 h2c http/1.1Cloudflare
/* デフォルトで有効（設定不要） */HTTPS（TLS）が必須
すべてのブラウザがHTTP/2にTLS（HTTPS）を要求しています。仕様上はh2c（平文HTTP/2）も定義されていますが、実質的にHTTPS対応が前提です。 Let's Encryptで無料のTLS証明書を取得し、まずHTTPS化を完了させてください。
HTTP/3（QUIC）への展望
HTTP/3はQUICプロトコル（UDP上）を使い、TCP層のHOL blockingを完全に解消します。2022年にRFC 9114として標準化され、 Google、Cloudflare、Fastlyなどが既にサポートしています。HTTP/2からHTTP/3への移行は、サーバー設定の変更だけで可能です。
ベストプラクティス
- ✓ドメインシャーディングは不要：HTTP/1.1では接続数を増やすためにリソースを複数ドメインに分散させていましたが、HTTP/2では逆効果です。1つのドメインにまとめましょう。
- ✓ファイル結合の削減：CSSやJSを1つの巨大ファイルに結合する必要性が低下します。個別ファイルのままでもHTTP/2の多重化で効率的に転送できます。
- ✓スプライトシートの見直し：小さな画像を1枚にまとめるCSSスプライトは、HTTP/2では個別画像の方がキャッシュ効率が良くなる場合があります。
- ✓インライン化の削減：小さなCSS/JSをHTMLにインライン化する手法も、HTTP/2では個別ファイルの方がキャッシュを活用できます。
関連コンテンツ
HTTP通信
ブラウザとサーバー間のHTTPリクエスト/レスポンスの仕組みを可視化
CORS
ブラウザのクロスオリジン制約とCORSヘッダーによるアクセス制御の仕組みを可視化
MQTT（Pub/Subモデル）
MQTTブローカーを経由したPublish/Subscribeモデルの通信フローを可視化します
AMQP（メッセージキュー）
RabbitMQなどで使われるAMQPのExchange・Queue・Bindingの仕組みを可視化します
WebSocket
HTTPハンドシェイクから始まる双方向リアルタイム通信プロトコルの仕組みを可視化
WebRTC（Web Real-Time Communication）
ブラウザ間のP2P通信。ビデオ通話・画面共有・ファイル転送に使われるリアルタイム通信技術