HTTP/2サーバープッシュの栄枯盛衰：PUSH_PROMISEの内部挙動と「実質的廃止」に至ったアーキテクチャの教訓
ネットワークエンジニアやインフラストラクチャーの設計に携わる者にとって、プロトコルの仕様書をめくる瞬間ほど心躍るものはない。TCPの3wayハンドシェイクの裏で蠢くパケットのやり取り、TLS 1.3による1-RTTの美しさ、そしてHTTP/2がTCPの呪縛（Head-of-Line Blocking）を如何にしてアプリケーション層で調停したか——これらはすべて、デジタル社会の目に見えないインフラを支える精巧な歯車だ。
今回は、そのHTTP/2における最も野心的でありながら、結果的に「壮大な失敗の実験場」となった機能に焦点を当てたい。HTTP/2サーバープッシュ（Server Push）と、それを支える中核フレームである `PUSH_PROMISE` だ。
一世を風靡したこの最適化手法が、なぜ今、主要ブラウザのモダン実装から姿を消そうとしているのか。パケットレベルの挙動、HTTP/2のマルチプレクシングの深部、そしてプロトコル設計における致命的なジレンマを、現場のアーキテクトの視点から紐解いていこう。
—
1. HTTP/2マルチプレクシングと「先回り」のロジック
HTTP/1.1の時代、ブラウザはWebページの描画を高速化するため、同一ドメインに対して最大6つのTCPコネクションを並行して張り、リソース（HTML、CSS、JS、画像）をかき集めていた。しかし、これはいわゆる「TCP Slow Start」の壁にぶつかり、RTT（Round Trip Time）の往復回数に性能が支配されるという致命的な弱点を抱えていた。
HTTP/2はこの問題を一刀両断した。単一のTCPコネクション上に「ストリーム（Stream）」という論理的な多重化レイヤーを構築し、バイナリフレーム単位でデータをインターリーブ（混在）させて流すマルチプレクシングを実現したのだ。
[ TCP Connection ]
├── Stream 1 (HEADERS + DATA: GET /index.html)
├── Stream 3 (HEADERS + DATA: GET /style.css)
└── Stream 5 (HEADERS + DATA: GET /app.js)
このアーキテクチャにおいて、サーバープッシュは次のような思想で設計された。
> 「クライアントがHTMLを要求し、それを解析（パース）して初めて『あ、CSSやJSも必要なんだ』と気づくまでのRTTがもったいない。サーバー側があらかじめ必要なリソースを知っているなら、HTMLのレスポンスを返すのと同時に、クライアントから要求される前に自発的に送りつけてしまえばいいではないか」
この「先回り」を実現するために生み出されたのが、HTTP/2特有の制御フレームである `PUSH_PROMISE` である。
—
2. `PUSH_PROMISE` フレームの内部挙動とパケットの流れ
サーバープッシュがどのように行われるのか、そのプロトコル上のシーケンスをバイナリフレームのレベルで追ってみよう。
1. クライアントからのリクエスト:
クライアント（ブラウザ）は、奇数のストリームID（例：`Stream 1`）を使用して `GET /index.html` を送信する。
2. サーバーからの `PUSH_PROMISE`:
サーバーは `Stream 1` を通して、HTML本体を送る前に `PUSH_PROMISE` フレームを送信する。
- このフレームには、「これから偶数の新しいストリーム（例：`Stream 2`）を使って、`/style.css` のレスポンスを勝手に送り始めるから、そのつもりで準備しておいてくれ」という宣言（擬似リクエストヘッダー）が含まれている。
3. リソースの並行転送:
サーバーは `Stream 1` でHTMLのデータを流しつつ、同時並行で `Stream 2` を使って `/style.css` のヘッダーとデータを送りつける。
Client Server
| |
|— [Stream 1] HEADERS (GET /index.html) ————–>|
| |
|<-- [Stream 1] PUSH_PROMISE (Stream 2: GET /style.css)--| <-- 予告
|<-- [Stream 1] DATA (HTML Body) ------------------------|
|<-- [Stream 2] HEADERS & DATA (CSS Body) ---------------| <-- プッシュされた実体
| |
`PUSH_PROMISE` フレームの構造と注意点
`PUSH_PROMISE`（フレームタイプ: `0x5`）のペイロードには、以下の要素が格納される。
- Promised Stream ID: これからプッシュするリソースのために新しく割り当てられるストリームID（クライアント起因ではないため、サーバー側が割り当てる偶数IDとなる）。
- Header Block Fragment: プッシュするリソースに対する仮想的なリクエストヘッダー（`:method`, `:path`, `:authority` など）。これはHPACKによって圧縮されている。
ここで重要なインフラ的制約がある。`PUSH_PROMISE` は、必ず「クライアントが開始したストリーム（奇数ID）」の文脈内で送信されなければならない。勝手にサーバーがコネクションの隙間から唐突にプッシュを始めることはできず、あくまでクライアントのリクエストに対する「おまけ」として紐づけられる必要があるのだ。
—
3. なぜサーバープッシュは「失敗作」となったのか？
理論的には完璧に思えたサーバープッシュだが、現実のインターネット、特に大規模なCDNや複雑なWebアプリケーションの現場では、致命的な副作用が次々と露呈した。現在、主要ブラウザ（Google Chromeなど）のコミュニティや仕様策定グループがサーバープッシュの実質的な廃止（Deprecation）や機能縮小を進めているのは、以下の複合的な理由による。
① キャッシュとの二重送信問題（Redundant Data Transfer）
これが最大の悪夢だった。
サーバー側は「このクライアントは初めて来るはずだからCSSをプッシュしよう」と判断して送りつけるが、実際にはクライアントのブラウザキャッシュにはすでにそのCSSがしっかり保存されていたとする。
クライアントは、サーバーがプッシュしてきたCSSを途中まで受信した段階で「あ、これキャッシュにあるわ」と気づく。慌てて `RST_STREAM`（フレームタイプ: `0x3`） フレームを送信し、「おい、そのプッシュもういらん！ストリームを強制終了しろ！」とサーバーに伝える。
Server Client
| |
|— [Stream 2] PUSH_PROMISE & DATA (CSS) ————–>|
| | (キャッシュヒット！)
|<-- [Stream 2] RST_STREAM (CANCEL) ---------------------|
| |
しかし、この時すでにパケットは洋上（WAN回線）を飛んでおり、帯域幅が無駄に消費されている。最悪なことに、サーバーがすでに重い処理（データベースからのフェッチなど）を走らせてプッシュデータを生成していた場合、サーバーリソースの無駄遣いにもなる。
CookieやLocalStorageを用いた複雑なキャッシュ制御とサーバー側のプッシュ判断を同期させることは、実質的に不可能だった。
② 優先順位付け（Prioritization）の崩壊と帯域の奪い合い
HTTP/2のマルチプレクシングでは、リソースのロード順序を制御するために「ストリームの依存関係と重み（Priority）」という非常に複雑な仕様が用意されていた。
サーバープッシュを使うと、サーバー側が「どれを優先して送るか」を勝手に決めることになる。しかし、真に何が優先されるべきか（例えば、画面のファーストビューに絶対必要なクリティカルCSSなのか、画面下部のどうでもいいアイコン画像なのか）を最も正確に知っているのは、ローカルのDOMツリーを構築しているブラウザ自身である。
サーバーが良かれと思って送信した大容量のプッシュリソースが、ブラウザにとって本当に今必要なクリティカルパスのデータを押し出し、結果的にページの表示速度を悪化させるという「逆転現象（Resource Contention）」が頻発した。
③ HPACKのステート汚染
HTTP/2のヘッダー圧縮（HPACK）は、コネクション全体で動的テーブル（Dynamic Table）を共有し、過去に送信したヘッダーの文字列をインデックス番号に置き換えて圧縮率を高めている。
サーバープッシュによって「クライアントが実際には必要としていない、あるいは後回しでいいリソースのヘッダー」が大量に流し込まれると、HPACKの動的テーブルがゴミ（無駄なエントリ）で汚染される。これにより、本来必要なリソースのヘッダー圧縮効率が低下し、CPUとメモリのオーバーヘッドが増大するという本末転倒な事態を招いた。
—
4. 現代のインフラにおける代替案と未来
こうした深刻なアーキテクチャ上の欠陥から、今日のWebパフォーマンス最適化の主流はサーバープッシュから離れ、より確実で洗練されたプリロード手法へと移行している。
1. `Link: ; rel=preload` (Early Hints)
RFC 8297で定義された HTTP 103 Early Hints は、サーバープッシュの反省を踏まえて設計された美しい解決策だ。
サーバーは、本番のレスポンスヘッダー（200 OK）を返す前に、超高速で `103 Early Hints` ステータスコードのレスポンスを返す。その中に `Link: rel=preload` ヘッダーを仕込んでおく。
HTTP/1.1 103 Early Hints
Link: ; rel=preload; as=style
Link: ; rel=preload; as=script
これを受け取ったブラウザは、「なるほど、この後これらのリソースが必要になるんだな」と自ら主体的に判断し、自らのキャッシュ状態やネットワーク帯域の空き具合を考慮した上で、適切なタイミングでフェッチ（あるいは既存キャッシュの利用）を行う。
サーバーが一方的に押し付ける（Push）のではなく、サーバーが「ヒント（Hint）」を与え、クライアントが「自己決定（Pull）」する。この主従関係の逆転こそが、現代のネットワーク設計の鉄則なのだ。
2. HTTP/3 (QUIC) との親和性
現在普及が進む HTTP/3（QUIC）においても、HTTP/2の反省を生かしてサーバープッシュの仕様（擬似的な仕組み）は残されてはいるものの、実質的なブラウザサポートや現場での採用は下火になっている。
むしろ、UDPベースのQUICがもたらす「コネクション単位のHead-of-Line Blockingの完全解消」や「0-RTTハンドシェイク」の恩恵を受けた素直なマルチプレクシング（Fetch APIやPreloadの活用）こそが、これからの高スループットなWebインフラの基盤である。
—
5. まとめ：プロトコル設計の教訓
HTTP/2サーバープッシュと `PUSH_PROMISE` の歴史は、インフラエンジニアにとって非常に示唆に富む教訓を残した。
「通信のラウンドトリップを減らすために、サーバーが知性を働かせて先回りしてデータを送る」というアイデアは、一見すると極めて合理的で美しい。しかし、「エンドポイント（クライアント）の内部状態（キャッシュやレンダリングの優先順位）を、遠隔地にいるサーバーが正確に把握し続けることは不可能である」という分散システムの根本的な制約を無視した結果、システム全体としての複雑性と非効率を増大させる結果となった。
優れたプロトコルアーキテクチャとは、マジカルな全知全能の最適化を盛り込むことではない。それぞれのレイヤー（サーバーとクライアント）が持つべき責務を厳密に分離し、シグナル（ヒント）のやり取りによって協調動作を促す「シンプルで堅牢な設計」こそが、長きにわたって生き残るシステムを生み出すのだ。
パケットの荒野を行くネットワークアーキテクトよ、日々のインフラ設計において「便利そうに見えるマジック」に飛びつく前に、その裏側で何が同期不全を起こすか、今一度プロトコルのステートマシンに目を凝らそう。
コメント