WEB PROTOCOL

HTTP/1.1 vs HTTP/2(多重化と直列処理の比較)

HTTP/1.1の直列処理とHTTP/2の多重化を、サイドバイサイドのウォーターフォールチャートで比較します。Head-of-line blockingの影響も確認できます。

INTERACTIVE VISUALIZATION
HTTP/1.1
HTTP/2
HOL blocking
HTML
CSS
JavaScript
画像
API
フォント
H1合計時間読み込み中...
14リソース / 6接続
H2合計時間読み込み中...
14リソース / 1接続(多重化)
スピードアップ
完了後に表示
フェーズ1 / 8
初期状態
IDLEHTTP/1.1とHTTP/2のリクエスト処理方法を比較します。左がHTTP/1.1、右がHTTP/2のウォーターフォールチャートです。
HTTP/1.1 CONNECTIONS (6)
C0使用率 100%
/index.html0-100ms
/style.css100-180ms
/thumb1.jpg180-320msBLOCKED
/font.woff2320-410msBLOCKED
C1使用率 100%
/theme.css150-210msBLOCKED
/thumb2.jpg210-340msBLOCKED
/icons.woff2340-415msBLOCKED
C2使用率 100%
/app.js150-310msBLOCKED
/thumb4.jpg310-455msBLOCKED
C3使用率 100%
/vendor.js150-350msBLOCKED
/api/init350-470msBLOCKED
C4使用率 100%
/analytics.js150-220msBLOCKED
/thumb3.jpg220-370msBLOCKED
C5使用率 100%
/hero.jpg150-370msBLOCKED
HTTP/2 STREAMS (14)
多重化
S1/index.html0-100ms
S3/style.css100-180ms
S5/theme.css100-160ms
S7/app.js100-260ms
S9/vendor.js100-300ms
S11/analytics.js100-170ms
S13/hero.jpg100-320ms
S15/thumb1.jpg100-240ms
S17/thumb2.jpg100-230ms
S19/thumb3.jpg100-250ms
S21/thumb4.jpg100-245ms
S23/font.woff2180-270ms
S25/icons.woff2180-255ms
S27/api/init260-380ms
シナリオ
典型的なWebページ。14リソースを読み込みます。接続確立コストの差に注目
ステップ1 / 8
自動再生でHTTP/1.1とHTTP/2の読み込み速度の違いを確認できます
解説

1
HTTP/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 conn
1本のTCP接続上で複数のHTTPリクエスト/レスポンスを同時にやり取りする技術。HTTP/2の中核機能で、各リクエストは独立した「ストリーム」として処理されます。ただし、リソース間に依存関係がある場合は同時にリクエストできません。例えばフォントファイルはCSSの@font-faceで参照されるため、CSSのダウンロード・解析が完了するまでブラウザはフォントの存在を知らず、リクエストを送れません。多重化が効くのは「同時に発見されたリソース」に限られます。
ストリーム(Stream)
S1S3S5
HTTP/2接続内の論理的な双方向チャネル。各ストリームには一意のID(奇数=クライアント発、偶数=サーバー発)が付与され、独立してデータを送受信します。
Head-of-line blocking
BLOCKED
HTTP/1.1で、同じTCP接続上の先行リクエストのレスポンスが遅いと、後続のリクエストがすべてブロックされる問題。HTTP/2のストリームは独立しているため、アプリケーション層のHOL blockingは解消されます。
HPACK
Plain HeadersHPACK
HTTP/2のヘッダー圧縮アルゴリズム。静的テーブル(よく使われるヘッダー)と動的テーブル(接続中に学習したヘッダー)を使い、ヘッダーサイズを大幅に削減します。
サーバープッシュ
ClientServerGET /PUSH /style.css
サーバーがクライアントのリクエストなしにリソースを先行送信する機能。HTMLを送信する際に、関連するCSS/JSを予測的にプッシュできます。ただし実装の複雑さから、Chrome 106以降では削除されています。
フレーム(Frame)
HDRS1DATAS1HDRS3DATAS3DATAS1
HTTP/2通信の最小単位。HEADERS、DATA、SETTINGS、PING、GOAWAYなど10種類のフレームタイプがあります。各フレームにはストリームIDが含まれ、同じTCP接続上で複数のストリームのフレームがインターリーブされます。

5
HTTP/1.1 vs HTTP/2 比較表

項目HTTP/1.1HTTP/2
接続方式ドメインあたり最大6本のTCP接続1本のTCP接続で多重化
多重化非対応(直列処理)対応(ストリームで並行処理)
ヘッダー形式プレーンテキスト(毎回全送信)HPACK圧縮(差分のみ送信)
サーバープッシュ非対応対応(PUSH_PROMISE)
優先度制御非対応対応(ストリーム優先度)
プロトコルテキストベースバイナリフレーム

6
通信の手順比較

1
TCP接続確立
HTTP/1.16 connectionsHTTP/21 connection
HTTP/1.1: 6本のTCP接続を確立(3-wayハンドシェイク × 6)
HTTP/2: 1本のTCP接続を確立(3-wayハンドシェイク × 1)
2
リクエスト送信
直列処理queued並行処理
HTTP/1.1: 各接続で1つずつ直列に送信。6接続を超えるリクエストはキューで待機
HTTP/2: すべてのリクエストを1本の接続で同時に並行送信
3
レスポンス受信
順序保証slow...任意順序slow but OK
HTTP/1.1: レスポンスは送信順に受信(順序保証)。遅いレスポンスがあると後続が待たされる
HTTP/2: レスポンスは任意の順序で受信可能。先に完了したストリームから処理される
4
追加リクエスト
キュー待ちwaiting...即時送信new stream = instant
HTTP/1.1: 空き接続を待つ必要あり。すべて使用中の場合キュー待ちが発生
HTTP/2: 即時送信可能。新しいストリームを開いてすぐにリクエストできる

7
Head-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.1
Cloudflare
/* デフォルトで有効(設定不要) */
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通信

ブラウザとサーバー間のHTTPリクエスト/レスポンスの仕組みを可視化

TLSハンドシェイク

TLSハンドシェイク

HTTPSで安全に通信するためのTLSハンドシェイクの仕組みを可視化

QUIC(HTTP/3基盤)

QUIC(HTTP/3基盤)

UDPベースの次世代トランスポートプロトコル。0-RTT接続、ストリーム多重化、接続マイグレーションを可視化

JWTの作り方

JWTの作り方

ヘッダー.ペイロード.署名の構造と検証の仕組みを可視化

MQTT(Pub/Subモデル)

MQTT(Pub/Subモデル)

MQTTブローカーを経由したPublish/Subscribeモデルの通信フローを可視化します

SSE(Server-Sent Events)

SSE(Server-Sent Events)

サーバーからクライアントへの一方向リアルタイムストリーミング通信