HTTP/2サーバープッシュの光と影：パケットの裏側から見た現実と、私たちが選ぶべき「次の一手」
ウェブの高速化において、ネットワークエンジニアやインフラアーキテクトが長年追い求めてきた聖杯の一つが「レイテンシーの削減」だ。往復遅延時間（RTT）という物理的な壁をいかに突破するか。その切り札としてHTTP/2に実装されたのが「サーバープッシュ（Server Push）」である。
クライアントがHTMLを要求し、そのレスポンスを解析してからCSSやJavaScriptをリクエストする――この「ラウンドトリップの直列化」を根絶し、HTMLの送信と同時に依存リソースを叩き込む。理論的には美しく、未来のウェブを予感させる機能だった。
しかし、現場の第一線でパケットを追いかけ、TLSハンドシェイクのバイナリを睨み続けているエンジニアなら知っているはずだ。この「善意の先回り」が、しばしばネットワーク帯域の無駄遣いや、最悪のキャッシュ効率という名の悪夢に変わることを。
今回は、HTTP/2サーバープッシュの内部メカニズム（`PUSH_PROMISE`フレームからHPACKの動的テーブルまで）を丸裸にし、実務で踏み抜く地雷とその回避策を、プロトコルの深淵から紐解いていこう。
—
パケットで見るHTTP/2サーバープッシュの全貌
HTTP/2は、TCP（またはQUIC）上の単一コネクションを多重化（マルチプレクシング）し、バイナリフレームのストリームとして通信を捌く。このアーキテクチャにおいて、サーバープッシュはどのようにトリガーされるのか。
クライアントが `GET /index.html` をリクエスト（Stream ID: 1）した瞬間、サーバーの脳内（アプリケーション層およびHTTP/2実装）では、「このHTMLなら、確実に `/css/style.css` が必要になる」と判断される。ここでサーバーは、通常のレスポンスを返す前に、一本の特別なフレームを流し込む。それが `PUSH_PROMISE`フレーム だ。
`PUSH_PROMISE`フレームの構造とライフサイクル
`PUSH_PROMISE` は、文字通り「これからこのストリーム番号で、私（サーバー）からリソースを送りつけるから、クライアント側はそのIDを予約しておけよ」という予告状である。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (24) |
+—————+—————+—————+
| Type (8) | Flags (8) |
+-+-+-+-+-+-+-+-+—————+——————————-+
|R| Stream Identifier (31) |
++=+————————————————————+
|Pad Length? (8)|
+—————+———————————————–+
|R| Promised Stream ID (31) |
+—————————————————————+
| Header Block Fragment (…)ങ്ങാ… |
+—————————————————————+
1. Stream Identifier: クライアントが開始した元のリクエストのストリームID（例: `1`）。
2. Promised Stream ID: これからサーバーがプッシュするリソースのために割り振る新しいストリームID（HTTP/2の仕様上、サーバーが開始するストリームなので偶数でなければならない。例: `2`）。
3. Header Block Fragment: プッシュするリソースへの擬似リクエストヘッダー（`:method`, `:path`, `:authority` など）。これはHPACKで圧縮されている。
この `PUSH_PROMISE` がワイヤー（回線）を流れた直後、サーバーは実際に `Promised Stream ID`（Stream 2）を使って `HEADERS` フレームと `DATA` フレームを送信し、リソースの本体を送りつける。クライアントは、自分がリクエストを出していないにもかかわらず、手元のキャッシュやメモリ上にそのコンテンツが出現する奇妙な体験をすることになる。
—
HPACKとTLSハンドシェイクの密接な関係
サーバープッシュを語る上で避けて通れないのが、HPACK（Header Compression for HTTP/2）の動态テーブル（Dynamic Table）と、トランスポートセキュリティ（TLS）の最適化だ。
ヘッダー圧縮の同期ズレという罠
HTTP/2のヘッダーは、クライアントとサーバー双方が保持するHPACKの動的テーブルを参照して圧縮・展開される。通常のリクエスト/レスポンスであれば、パケットの往復順序が厳密に同期するためテーブルの整合性が保たれる。
しかし、サーバープッシュは「非同期」だ。
クライアントがまだ受け取っていない、あるいは処理しきれていない動的テーブルのインデックスを、サーバー側の `PUSH_PROMISE` が先回りして参照した場合、どうなるか？
HPACKのデコーダーはテーブルの不整合を検知し、即座に `COMPRESSION_ERROR` (Code 0x9) のGOAWAYフレームを吐いてコネクションを強制切断する。
「良かれと思ってプッシュした結果、コネクションごと爆破する」――これが、安易なサーバープッシュ実装が陥る最初の落とし穴である。
このリスクを防ぐため、サーバー側のHPACK実装は、クライアントのSETTINGSフレーム（`SETTINGS_HEADER_TABLE_SIZE` や `SETTINGS_MAX_CONCURRENT_STREAMS`）を厳密に解釈し、まだ相手が同期できていないと推測される大きな動的テーブルエントリをプッシュ用ヘッダーに含めない、あるいは静的テーブル（Static Table）の範囲内に留めるような高度なチューニングが要求される。
TLS 1.3とTCPバッファチューニング
サーバープッシュの真価を発揮させるには、トランスポート層の底上げが不可欠だ。
TLS 1.3による 0-RTT / 1-RTT のハンドシェイク最適化はもちろんのこと、LinuxカーネルのTCPスタックにおいて、ウィンドウサイズやバッファの枯渇を防ぐ設定が命綱となる。
/etc/sysctl.conf におけるHTTP/2最適化の鉄板パラメータ
TCPウィンドウのスケーリングを有効化し、BDP（Bandwidth-Delay Product）を最大化
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
輻輳制御アルゴリズムにBBRを採用（高レイテンシー環境でのスループット最大化）
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
サーバープッシュは、クライアントから「これをくれ」と言われていないデータ（バイト列）を強烈な勢いで送りつけるため、TCPの輻輳ウィンドウ（cwnd）が適切に広がっていない初期段階でこれをやると、パケットロスやバッファあふれを引き起こしやすい。BBRのようなモダンな輻輳制御アルゴリズムと組み合わせることで、プッシュされたデータがパイプラインを詰まらせるリスクを最小化できる。
—
キャッシュ効率の破壊者：なぜ私たちはプッシュをやめるのか
ここまで技術的な美しさを語ってきたが、インフラアーキテクトとしての冷徹な現実を告げなければならない。
現代のウェブにおいて、HTTP/2サーバープッシュは「アンチパターン」として扱われるケースが急増している。
その最大の理由は 「クライアントキャッシュの完全な無視」 にある。
送信の重複と無駄な帯域消費
考えてみてほしい。ブラウザは一度訪れたサイトのリソース（CSSやJS）をDisk CacheやMemory Cacheに保持している。
しかし、サーバー側は、そのクライアントがブラウザキャッシュを持っているかどうかを（Cookieや専用のキャッシュDigest仕様が普及しきらなかった現実において）正確に知る術を持たない。
結果として何が起きるか？
- すでにブラウザがキャッシュしている `main.css` を、サーバーは親切心から毎回のHTMLリクエストごとにプッシュし続ける。
- クライアントは「いや、それ持ってるし…」と心の中で思いながら、無駄な帯域幅を使ってパケットを受信し、CPUサイクルを割いて破棄する。
- 帯域が圧迫された結果、本当に必要な別のリソースの転送が遅延する。
これが、「帯域の無駄遣い（Wasted Bandwidth）」と「キャッシュ汚染」のメカニズムである。
Nginxなどの実運用環境では、この問題があまりに深刻化したため、次のようなディレクティブでサーバープッシュを無効化、あるいは制限することが標準的になりつつある。
NginxにおけるHTTP/2プッシュの無効化（現代の推奨設定）
http2_push_preload off;
※ http2_push 自体も、多くのケースで実質的なデッドコードと化している
—
代替案：`Link: rel=preload` と 103 Early Hints
では、サーバープッシュの代わりに私たちは何を使うべきなのか？
業界のトレンドは、ブラウザに主導権を握らせる仕組みへと完全にシフトしている。
1. `Link: rel=preload` (HTTP Header)
サーバーは `PUSH_PROMISE` で強制的にリソースを送りつけるのではなく、レスポンスヘッダーにプレロードのヒントを載せる。
HTTP/2 200 OK
Content-Type: text/html
Link: ; rel=preload; as=style
Link: ; rel=preload; as=script
これを受け取ったブラウザは、「なるほど、このページにはこのCSSとJSが必要なんだな。しかも俺はすでにキャッシュを持っているから、これはリクエストしないでおこう」という判断を、自分自身のキャッシュストアと相談して下すことができる。
2. 103 Early Hints (RFC 8297)
さらに進化系として現在広く普及しているのが 103 Early Hints だ。
サーバーが本格的なHTMLの生成（DBクエリやレンダリング）に時間がかかっている間に、先行して `103 Early Hints` ステータスコードと `Link: rel=preload` ヘッダーをクライアントに返す。
これにより、クライアントはHTML本体の到着を待たずに、依存リソースのDNS名前解決、TCPハンドシェイク、TLSネゴシエーション、果てはプリロードのフェッチを並列で開始できる。サーバープッシュの「先回りしたい欲求」を満たしつつ、クライアントのキャッシュ機構を完全に尊重する、極めてエレガントな解決策である。
—
結びにかえて
HTTP/2サーバープッシュは、プロトコル仕様の美しさと、現実のネットワーク生態系の複雑さが衝突した歴史のひとコマと言える。
パケットの動きを熟知し、バイナリレベルで `PUSH_PROMISE` を解釈できるスキルはインフラエンジニアにとって今なお必須の教養だが、「技術的に可能だから使う」というフェーズはとうに過ぎ去った。
プロトコルの進化は止まらない。HTTP/3（QUIC）の時代において、HTTP/2のサーバープッシュ仕様はベースとしては引き継がれているものの、実務の世界では `103 Early Hints` や `rel=preload` といった「協調型」の最適化こそが、真のパフォーマンスを引き出す鍵となっている。
ネットワークの挙動を愛する者よ。パケットを信じるな、クライアントのキャッシュを信じろ。現場からは以上だ。
コメント