【テクニカル・上級編】PUSH_PROMISEフレームによるサーバープッシュの予約 – HTTPプロトコル・通信規格実践ガイド

パケットが奏でる先読みの美学：HTTP/2 `PUSH_PROMISE` が描き出す非同期ストリームの裏側

ネットワークのパケットキャプチャを開いたとき、TCPの3ウェイ・ハンドシェイクの静寂が破られ、TLS 1.3の暗号化トンネルが確立された瞬間に流れ出すバイナリの奔流――私たちが日々何気なく叩いているウェブブラウザの裏側では、プロトコル設計者たちの狂気と美学に満ちた最適化のドラマが繰り広げられています。

HTTP/1.1時代、私たちは1つのリクエストが完了するまで次のリクエストがブロックされる「ヘッド・オブ・ライン・ブロック（HoLB）」という呪縛に囚われていました。それを打破するためにHTTP/2がもたらしたマルチプレクシングは、単一のTCPコネクション上で無数のストリームを並行処理することを可能にしました。しかし、真のインフラストラクチャー・スペシャリストであれば知っているはずです。「クライアントがリクエストを投げるのを待つ時間すら、ネットワークのレイテンシという観点からは無駄である」という冷徹な事実を。

この「無駄な待ち時間」を極限まで削ぎ落とすために生み出されたのが、今回焦点を当てる `PUSH_PROMISE` フレーム です。

教科書的な仕様のなぞり書きはここではしません。パケットレベルのバイナリ構造、ストリームIDの厳格な割り当てルール、そして現実のプロダクション環境でこの機能が抱える「暗い側面」とセキュリティリスクまで、ネットワークの深淵を愛する者たちの視点で深く紐解いていきましょう。

—

1. `PUSH_PROMISE` の本質：なぜ「先読み」が必要なのか

Webアプリケーションのパフォーマンスを語る際、最大のボトルネックは常に「ラウンドトリップタイム（RTT）」です。どれほど高速なバックエンドを持っていようとも、クライアントがHTMLを受信し、そのパースを開始し、内部に含まれるCSSやJavaScript、あるいはアイコン画像の存在に気づいて初めて追加のリクエストを発行する――この「リクエスト・レスポンスの往復」という因果律の連鎖は、物理的な光速の壁に阻まれています。

サーバープッシュ、そしてその中核をなす `PUSH_PROMISE` フレームは、この因果律をあらかじめ「予約」によってハックするメカニズムです。

クライアントが `GET /index.html` を要求した瞬間、サーバーはHTML本体のレスポンスを返す前に、こう囁きます。
「おい、お前はまもなくこのHTMLをパースしたら `/styles.css` を要求することになるだろう？わざわざリクエストを投げる手間は省いてやる。今からこのストリームでそのデータを送りつけてやるから、心して待て」

これが `PUSH_PROMISE` の本質です。データの実体をいきなり送りつけるのではなく、「これからこのリソースのレスポンスを特定の新しいストリームで配信する」という約束（Promise）を事前に交わすのです。

—

2. パケットレベルの構造とストリームIDの厳格な舞踏

HTTP/2のフレームは、すべて9オクテットの共通ヘッダーから始まります。

+———————————————–+
| Length (24) |
+—————+—————+—————+
| Type (8) | Flags (8) |
+-+————-+—————+——————————-+
|R| Stream Identifier (31) |
+-+———————————————–+
| – – – – – – – PUSH_PROMISE Payload – – – – – – |
| … |
+———————————————–+

`PUSH_PROMISE` フレームの `Type` フィールドには `0x5` が格納されます。ここでインフラエンジニアとして最も注目すべき、そして実装を誤ると即座にコネクションエラー（RST_STREAM / PROTOCOL_ERROR）を引き起こすのが、ストリームIDの割り当てルールです。

偶数と奇数の厳格な戒律

HTTP/2におけるストリームIDのパリティ（偶奇性）は、プロトコルの治安を維持するための絶対的な法律です。

奇数ストリームID（1, 3, 5…）：クライアントによって初期化される。
偶数ストリームID（2, 4, 6…）：サーバーによって初期化される（サーバープッシュやゴーン等）。

`PUSH_PROMISE` フレームは、クライアントが開始した既存のストリーム（必ず奇数ID）の上で送信され、そのペイロード内部に「これからサーバーが使用する新しい偶数ストリームのID」を宣言します。

具体的なパケットフローの例

1. クライアントがストリーム `1` で `GET /` を送信。
2. サーバーがストリーム `1` 上で `PUSH_PROMISE` フレームを送信。

このフレーム内の「Promised Stream ID」フィールドに、次に使う偶数ID（例: `2`）を指定。
同時に、HPACKで圧縮された仮想的なリクエストヘッダー（`:method: GET`, `:path: /styles.css` など）をペイロードに含める。

3. サーバーは、宣言したストリーム `2` を使って、実際に `/styles.css` のレスポンスボディ（`DATA` フレーム）を流し始める。

この一連のシーケンスにおいて、ストリームIDのインクリメント順序を誤ったり、クライアントがオープンしていないストリームに対してプッシュを試みたりすると、HTTP/2のステートマシンは即座に崩壊し、`PROTOCOL_ERROR` が吐き出されます。

—

3. HPACK圧縮とトランスポート層（TLS/TCP）の密接な関係

`PUSH_PROMISE` のペイロードには、プッシュするリソースに対する擬似ヘッダー（`:method`, `:scheme`, `:authority`, `:path` など）が含まれます。これらは当然、HTTP/2の心臓部である HPACK アルゴリズムによって圧縮されています。

ここでインフラアーキテクトが考慮しなければならないのが、HPACKのダイナミックテーブルの同期状態です。

HPACKは、クライアントとサーバーの双方で同一のダイナミックテーブル（コンテキスト）を維持することで、冗長なヘッダー文字列をインデックス番号に置き換えて圧縮します。サーバーが `PUSH_PROMISE` でヘッダーを送信するということは、サーバー側のダイナミックテーブルの状態が進むことを意味します。もしネットワークの途中でパケットロスが発生し、TCPの再送制御やウィンドウ制御に詰まりが生じると、HPACKのデコード順序が狂い、コネクション全体がデッドロックに陥る危険性があります。

トランスポート層の最適化：TLS 1.3とTCPバッファ

サーバープッシュを真に活かすためには、OSカーネルレベルのチューニングが不可欠です。

TCPウィンドウサイズとBBR混雑制御：

プッシュされたリソースは、クライアントが要求していないにもかかわらずネットワークパイプラインを流れてきます。クライアント側のTCP受信バッファ（`net.ipv4.tcp_rmem`）が小さすぎると、サーバーからの積極的なデータ送信（プッシュ）によってすぐにウィンドウが枯渇し、ゼロウィンドウパケットが飛び交う惨劇が起きます。現代のLinuxカーネルでは、CUBICよりも動的な帯域とRTTを計測する BBR 混雑制御アルゴリズムの採用が強く推奨されます。

TLS 1.3 0-RTTの罠：

コネクション確立と同時にデータを送り出すTLS 1.3の0-RTT機能は魅力的ですが、リプレイ攻撃のリスクを伴います。サーバープッシュを行う文脈においては、冪等性のないリクエストに対する不安全なプッシュを防ぐため、セキュリティポリシーとの厳密なトレードオフ評価が必要です。

—

4. 実務の現場における現実：なぜ現代の主要ブラウザはサーバープッシュを忌避するのか？

ここまで `PUSH_PROMISE` の美しさとメカニズムを語ってきましたが、ここでインフラエンジニアとしての冷徹な現実を告げなければなりません。

現在、主要なWebブラウザ（Google Chromeなど）は、HTTP/2のサーバープッシュ（`PUSH_PROMISE`）のデフォルトサポートを段階的に廃止・縮小しています。

なぜ、これほど洗練された技術が現場から敬遠されているのでしょうか？主な理由は以下の3点に集約されます。

1. キャッシュの二重送信（Wasted Bandwidth）：
サーバーは「クライアントがこの画像を持っていない」と信じてプッシュしますが、実際にはクライアントのブラウザキャッシュにすでに存在しているケースが多々あります。結果として、帯域の無駄遣い（キャッシュヒットするはずのデータがネットワークを流れる）が発生します。
2. プッシュのキャンセルコスト（RST_STREAMの氾濫）：
「すでにキャッシュにある」と気づいたクライアントは、慌ててサーバーに対して `RST_STREAM` フレーム（エラーコード: `CANCEL`）を送りつけます。しかし、そのパケットがサーバーに届く頃には、すでに大容量のデータが回線を駆け抜けた後であり、帯域の無駄食いは防げません。
3. リソース競合（Contention）：
本当にクライアントが必要としているクリティカルなレンダリングブロック・リソースよりも、サーバーが勝手に選んだプッシュリソースが優先されてしまい、結果的にページの表示速度が低下する「プッシュの暴走」が頻発しました。

現代における代替案：103 Early Hints との比較

この反省から生み出されたのが、HTTP/1.1およびHTTP/2で利用できる `103 Early Hints` ステータスコード です。
サーバープッシュが「データを強制的に送りつける（Push）」アプローチだったのに対し、Early Hintsは「これから必要になるリソースのヒントをヘッダーで先んじて教え、取得するかどうかはクライアント（ブラウザ）の判断に委ねる（Pull）」という、より協調的なアプローチです。

—

5. まとめ：パケットの奔流をデザインする者たちへ

`PUSH_PROMISE` フレームは、HTTP/2プロトコルが到達した最適化の一つの極みであり、クライアントとサーバーが非同期で対話するための美しいアーキテクチャの結晶です。

実務において `PUSH_PROMISE` を直接ハンドリングする機会、あるいはNginxやEnvoyなどのリバースプロキシで適切にチューニングする機会は減っているかもしれません。しかし、その内部で何が起きているのか――ストリームIDのパリティ、HPACKの状態管理、TCPバッファとRTTの関係性、そしてプロトコル設計における「強制」と「協調」のジレンマを深く理解しているインフラエンジニアこそが、真に信頼性の高いネットワークシステムを構築できるのです。

パケットアナライザの画面の向こう側で繰り広げられるバイナリのダンスに想いを馳せながら、今日も私たちは最高のインフラを組み上げていきましょう。