サーバープッシュの幻想と現実、そして「PUSH_PROMISE」という名の予言
おい、ちょっとこっちに来てくれ。
昨今のWebフロントエンドのパフォーマンスチューニングの話題になると、必ずと言っていいほど名前が挙がる「HTTP/2 サーバープッシュ（Server Push）」。クライアントから要求される前に、サーバー側から「これ絶対後で必要になるだろ？」と先回りしてリソースを送りつける、あのロマンあふれる仕組みだ。
だがな、現場のインフラエンジニアやネットワークスペシャリストの視点から言わせてもらうと、この機能、実は「諸刃の剣」を通り越して、下手に実装するとキャッシュの汚染や帯域の無駄遣いを引き起こす「じゃじゃ馬」なんだ。HTTP/3（QUIC）の時代を迎え、ついに主要ブラウザでもサーバープッシュの廃止や再検討が進んでいる今だからこそ、その根幹を支えるプロトコル上のメカニズム——`PUSH_PROMISE`フレームの挙動を、一度しっかりと骨の髄まで理解しておく必要がある。
今回は、このサーバープッシュの予約システムである`PUSH_PROMISE`が、ワイヤー上でどう動き、ストリームIDのルールがどうなっているのか。そして、実務の現場でどう向き合うべきかを、シニアの視点ですべて叩き込んでやろう。
—
1. PUSH_PROMISEフレームの正体とストリームIDの厳格なルール
HTTP/2の最大の武器といえば「マルチプレクシング（多重化）」だ。1本のTCPコネクション上で、独立した複数の「ストリーム」を並行して流す。このストリームの概念が、サーバープッシュにおいては非常にトリッキーな挙動を見せる。
通常の通信はすべて「クライアントがイニシエート（開始）」する。クライアントがリクエストを投げるときに使うストリームIDは、必ず奇数（1, 3, 5…）だ。
じゃあ、サーバーから一方的にリソースを送り出すサーバープッシュはどうなる？
ここで登場するのが、今回の主役である`PUSH_PROMISE`フレームだ。
ストリームIDの奇数・偶数の掟
HTTP/2の仕様（RFC 7540）では、ストリームの割り当てに関して絶対的なルールがある。
- クライアントが開始するストリーム： 奇数（1, 3, 5, 7…）
- サーバーが開始するストリーム： 偶数（2, 4, 6, 8…）
サーバープッシュを行う際、サーバーは既存のクライアントからリクエストされたストリーム（例えば、クライアントが `GET /index.html` を投げたストリームID `1`）の中で、「今からこのリソースをプッシュするから、心の準備をしておけよ」という予告（予約）を行う。これが`PUSH_PROMISE`だ。
ここで重要なのが、`PUSH_PROMISE`フレーム自体が持つストリームIDと、それが指し示す「新しく作成されるプッシュ用ストリーム」の関係だ。
1. クライアントがストリーム `1` で `GET /index.html` をリクエストする。
2. サーバーはストリーム `1` の上で、`PUSH_PROMISE`フレームを送信する。
3. この `PUSH_PROMISE` フレームの中には、「これから使う予定の新しいプッシュ用ストリームのID（例：偶数の `2`）」と、プッシュするリソースの擬似ヘッダー（`:method`, `:path`, `:authority` など）が含まれている。
4. これにより、クライアントは「ストリーム `2` で画像ファイル（`/css/style.css` など）が後から降ってくるんだな」と事前に知ることができる。
この一連の「予約」が完了して初めて、サーバーはストリーム `2` を使って実際のレスポンスボディ（DATAフレーム）を流し始めるわけだ。
—
2. 通信フロー（シーケンス）の解剖
言葉だけだとイメージしにくいだろう。パケットキャプチャやh2specのようなテストツールを覗いていると、次のような美しい（そして時にはカオスな）シーケンスが展開されている。
Client Server
| |
|— [Stream 1] HEADERS (GET /) —–>| 1. クライアントがHTMLを要求
| |
| (サーバーがindex.htmlを解析し、CSSのプッシュを決意)
| |
|<-- [Stream 1] PUSH_PROMISE ---------| 2. 「ストリーム2でCSSを送るよ」と予約
| (Promised Stream ID: 2) |
| |
|<-- [Stream 1] DATA (HTML body) -----| 3. HTML本体の返送
|<-- [Stream 2] HEADERS / DATA -------| 4. プッシュされたCSSの送信開始
| |
このシーケンスの美しさは、「リクエストの往復（RTT）を待たずに、必要なアセットを先回りして送り込める」という点にある。しかし、現場のネットワークエンジニアとして警告しておきたいのは、「クライアントがすでにそのCSSをブラウザキャッシュに持っていた場合」の無駄だ。
クライアントは、`PUSH_PROMISE` を受け取った時点で「あ、これ持ってるわ」と思ったら、ストリームの処理中に `RST_STREAM`フレーム（エラーコード: `CANCEL` または `REFUSE_STREAM`） をサーバーに叩きつけて、プッシュを強制キャンセルしなければならない。このハンドリングを誤ると、帯域の無駄食い（带宽の枯渇）を引き起こす。これが、サーバープッシュが実務で敬遠されがちな最大の理由だ。
—
3. PUSH_PROMISEフレームの構造とHPACK圧縮
ネットワークアナライザやデバッグログで `PUSH_PROMISE` を確認するとき、その中身がどうなっているかを知っておく必要がある。
`PUSH_PROMISE` フレームのペイロードは、ざっくり言うと以下の構造をしている。
1. Pad Length (オプション): パディングを入れる場合の長さ（1バイト）
2. Promised Stream ID: 次にサーバーが使用する偶数のストリームID（31ビット）
3. Header Block Fragment: プッシュするリソースのリクエストヘッダー（HPACKで圧縮されている）
HPACKの文脈
通常のHTTP/2リクエストヘッダーと同様に、`PUSH_PROMISE` 内のヘッダーも HPACK によって圧縮されている。
ここで重要なのは、「プッシュされるリクエストのヘッダーは、親ストリーム（この場合はストリーム `1`）のHPACKコンテキストを共有する」という点だ。サーバー側とクライアント側でHPACKのダイナミックテーブルが完全に同期していなければならないため、パケットの順序が狂ったり、解釈のズレが生じたりすると、一瞬でコネクションエラー（`COMPRESSION_ERROR`）となり、TCPセッションごと切断される。シビアな世界だろ？
—
4. 【実践】環境構築と挙動のデバッグ
理屈はこれくらいにして、実際に手を動かしてみよう。
現代のWebサーバー（NginxやEnvoy、あるいはNode.jsやGoのHTTP/2実装）でサーバープッシュを構成し、その挙動を確認する。
今回は、最も堅牢で現場でも使われる Go言語 を使って、明示的に `PUSH_PROMISE`（Goの標準ライブラリでは `http.Pusher` インターフェース経由で制御）を発生させる最小限のサーバーを書いてみよう。
Goによるサーバープッシュ実装例
package main
import (
“fmt”
“log”
“net/http”
)
func handleRoot(w http.ResponseWriter, r http.Request) {
// 1. クライアントがHTTP/2をサポートしており、プッシュが可能かチェック
pusher, ok := w.(http.Pusher)
if ok {
// 2. /static/style.css のプッシュを予約（ここで内部的にPUSH_PROMISEが飛ぶ）
err := pusher.Push(“/static/style.css”, nil)
if err != nil {
log.Printf(“Failed to push style.css: %v”, err)
} else {
log.Println(“Successfully pushed /static/style.css via PUSH_PROMISE”)
}
}
// 3. メインのHTMLレスポンスを返す
w.Header().Set(“Content-Type”, “text/html; charset=utf-8”)
w.WriteHeader(http.StatusOK)
fmt.Fprintf(w, `
Hello, HTTP/2 PUSH_PROMISE!
`)
}
func handleStaticCSS(w http.ResponseWriter, r http.Request) {
w.Header().Set(“Content-Type”, “text/css; charset=utf-8”)
w.WriteHeader(http.StatusOK)
// プッシュされるCSSの中身
fmt.Fprintf(w, “body { background-color: #f0f0f2; color: #333; font-family: sans-serif; }”)
}
func main() {
mux := http.NewServeMux()
mux.HandleFunc(“/”, handleRoot)
mux.HandleFunc(“/static/style.css”, handleStaticCSS)
// HTTP/2を有効にするにはTLS（HTTPS）が必須
// 自己証明書等でローカル環境にSSL/TLSを構築してください
log.Println(“Starting HTTP/2 server on https://localhost:8443…”)
err :=ListenAndServeTLS(“:8443”, “server.crt”, “server.key”, mux)
if err != nil {
log.Fatalf(“Server failed: %v”, err)
}
}
デバッグの勘所：curlでパケットの挙動を追う
このサーバーを立ち上げた状態で、ローカルからHTTP/2の通信をデバッグしてみよう。
おなじみの `curl` コマンドを使うときは、HTTP/2の明示的な指定と、詳細ログ（`-v`）の出力が必須だ。
–http2 オプションでHTTP/2を強制し、詳細な通信ログ(-v)を出力する
curl -v –http2 –insecure https://localhost:8443/
コンソールに吐き出されるログを注意深く見てほしい。
サーバーからのレスポンスヘッダーの中に、次のような `PUSH_PROMISE` に関連するログや、それに伴う偶数ストリームでのレスポンス受信の痕跡を確認できるはずだ。
> 実務でのトラブルシューティングTips:
> もし `curl` や特定のクライアントで「Protocol error」や「Stream closed」といったエラーに直面したら、まず疑うべきは「サーバーがクライアント側の `SETTINGS` フレームで許可された最大同時ストリーム数や、プッシュの有効/無効設定（`SETTINGS_ENABLE_PUSH`）を無視していないか」だ。
> クライアントが `SETTINGS_ENABLE_PUSH = 0`（サーバープッシュ禁止）と宣言しているにもかかわらず、サーバーが強引に `PUSH_PROMISE` を送りつけると、仕様違反として即座にコネクションが切断（`PROTOCOL_ERROR`）される。ここ、テストに出るくらい重要な現場のハマりポイントだ。
—
5. シニアネットワークエンジニアからの提言
ここまで、`PUSH_PROMISE` の構造、ストリームIDのルール、そして実装とデバッグの手法を解説してきた。
冒頭でも触れた通り、HTTP/2のサーバープッシュ、そしてそれを予約する `PUSH_PROMISE` は、複雑性とキャッシュ管理の難しさから、最新のWebアーキテクチャ（特にHTTP/3やCDNが絡む環境）では利用が縮小傾向にある。ブラウザのプリロード機能（``）や、細やかなリソースヒント、あるいはモダンなCDNのエッジコンピューティングを活用する方が、結果的にトラブルが少なく効率的であることが多いためだ。
しかし、だからといって「古い技術だから覚えなくていいや」で済ませるな。
プロトコルの根底にある「マルチプレクシングされた空間でのストリームの協調動作」「HPACKのコンテキスト共有」「フレーム単位のライフサイクル管理」は、HTTP/3やgRPC、さらには次世代のマイクロサービス間通信を理解する上での「羅針盤」となる。
ネットワークの裏側で、奇数と偶数のストリームIDがどのように舞い、`PUSH_PROMISE` が未来のパケットを予約しているのか——そのダイナミクスを頭に描きながら、君のインフラストラクチャを設計してほしい。頼もしい成果を楽しみにしている。
コメント