HTTP/2優先度制御の幻想と現実：なぜブラウザ実装の差異がWebパフォーマンスを狂わせるのか
ネットワークの低レイヤーを愛する者にとって、プロトコルが洗練されていく過程を追うのは至上の喜びだ。TCPの無機質なバイトストリームの上に、アプリケーション層の論理チャネルを多重化（Multiplexing）したHTTP/2は、まさにその極致だった。TCPコネクションを1本に集約し、HOL（Head-of-Line）ブロックを克服したあの日の感動を、私は今でも鮮明に覚えている。
しかし、現実は美しい仕様書通りには動かない。
HTTP/2のパフォーマンスを語る上で避けて通れないのが「ストリーム優先度制御（Stream Prioritization）」である。リソースの依存関係と重み付けをサーバーに伝え、限られた帯域を最適な順序で配分する――理論上は完璧に見えたこのメカニズムは、実際には実装の複雑さとブラウザごとの方言にまみれ、ついにはHTTP/3（QUIC）において根本的な設計変更を余儀なくされるほどの「歴史的バグ」となった。
今回は、パケットの挙動、TLSハンドシェイクの裏側、そしてLinuxカーネルのバッファチューニングまで視野に入れながら、HTTP/2優先度制御の深淵へと潜っていく。
—
1. 優先度制御のメカニズム：DEPENDENCYとWEIGHTの正体
HTTP/2のストリームは、完全に独立した平行線ではない。ツリー構造を持つ。
クライアントは、HEADERSフレームまたはPRIORITYフレームを用いて、サーバーに「このストリームはこのストリームに依存している（`DEPENDENCY`）」こと、そして「どれだけの比率でリソースを割り当てるべきか（`WEIGHT`）」を指示する。
[Stream 0 (Root)]
│
├─ (Weight: 16) ──> [Stream 3 (HTML)]
│ │
│ ├─ (Weight: 32) ──> [Stream 5 (CSS)]
│ └─ (Weight: 2) ──> [Stream 7 (Image)]
│
└─ (Weight: 4) ──> [Stream 9 (Analytics Script)]
バイナリフレームの構造
パケットレベルで見ると、優先度情報は次のような9バイトのフレームヘッダーの後に続くペイロード（またはHEADERSフレーム内）にエンコードされている。
- Exclusive Flag (1bit): 依存先のストリームの既存の子を、自分の配下にぶら下げるかどうか。
- Stream Dependency (31bit): 親となるストリームID。
- Weight (8bit – 1): 重み（実際の値は `WEIGHT + 1` となり、`1` から `256` までの範囲をとる）。
サーバー側のスケジューラは、この依存関係ツリーと重みに従って、TCPの送信バッファ（Socket Send Buffer）へ流し込むデータチャンクの順序を決定する。親が完了する（あるいは帯域を使い切る）まで子は送信されない。これが理想的な優先度制御の姿だ。
—
2. 実装の地獄：ブラウザ依存が招く「リソース競合」の泥沼
仕様は美しかったが、それを実装したブラウザベンダーたちの解釈はバラバラだった。ここにHTTP/2優先度制御の最大の闇がある。
各ブラウザは、次のように全く異なる「ヒューリスティクス（推測アルゴリズム）」に基づいて依存関係ツリーを構築していた。
1. Google Chrome (Blink):
DOMの構築を最優先するため、CSSやパースをブロックするJSを深く複雑なツリー構造で管理。かつては非常にアグレッシブな排他制御（Exclusive Dependency）を行い、サーバーを自社の意図通りにコントロールしようとした。
2. Mozilla Firefox (Gecko):
もっとシンプルでフラットな重み付けを好み、Chromeほど複雑なツリーを生成しない。
3. Apple Safari (WebKit):
独自路線を走り、バージョンによって挙動が大きく変動。
結果として何が起きたか？
「サーバー側が、ブラウザごとの複雑なツリー構造を解釈・計算するためのCPUコスト（Priority Inversion問題）が爆発した」のだ。サーバー（Nginx, Apache, Envoyなど）は、クライアントから送られてくる刻一刻と変わるPRIORITYフレームの処理に追われ、肝心のバイト送出処理のパフォーマンスが低下するという本末転倒な事態に陥った。
さらに厄介なのは、CDNやリバースプロキシを挟んだ場合だ。エッジサーバーが優先度ツリーを適切にバックエンドへ転送できなかったり、そもそもキャッシュヒットしたアセットの優先度制御が無意味になったりすることで、ネットワークの最適化どころかレイテンシの悪化を招くケースが多発した。
—
3. インフラ・カーネルレイヤーからのアプローチ：TCPバッファとHTTP/2の衝突
アプリケーション層でどれほど巧みに優先度制御を行っても、下位層であるTCP（トランスポート層）の挙動を理解していなければ意味がない。
HTTP/2のマルチプレクシングは、1本のTCPコネクション上で複数のストリームをインターリーブ（混在）させる。ここで問題になるのがTCPの輻輳制御（Congestion Control）と送信バッファの肥大化（Buffer Bloat）だ。
高優先度のクリティカルなCSS（Stream 5）と、低優先度の巨大な画像（Stream 7）が同じTCPコネクションに流し込まれるとき、Linuxカーネルのソケットバッファが大きすぎると、低優先度の画像データがすでにTCP層に送出されてしまい、高優先度データの割り込みが効かなくなる。
Linuxカーネルチューニング（sysctl.conf）の指針
HTTP/2のパフォーマンスを極限まで引き出すためには、TCPソケットバッファのサイズを適切に制限し、アプリケーション層の優先度制御がトランスポート層に正しく反映されるようにチューニングする必要がある。
/etc/sysctl.conf
TCPの送信バッファの最小値、デフォルト値、最大値を設定
バッファを小さく保つことで、HTTP/2のストリーム切り替え時に古い低優先度パケットが溜まるのを防ぐ
net.ipv4.tcp_wmem = 4096 65536 4194304
BBR輻輳制御アルゴリズムの有効化（高スループットと低レイテンシの両立）
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
TCPウィンドウのスケーリングを有効化
net.ipv4.tcp_window_scaling = 1
解説: `net.ipv4.tcp_wmem` の上限を大きくしすぎないことがポイントだ。バッファが大きすぎると、HTTP/2サーバーが「高優先度データを送ろう」と判断した瞬間であっても、すでにTCPレイヤーのキューに詰まっている低優先度データが先にワイヤーに出てしまう。結果として、優先度制御が空振りする現象が起きる。
—
4. セキュリティとリソース枯渇攻撃（HTTP/2 Priority Flood）
インフラエンジニアやセキュリティ専門家として見逃せないのが、この優先度制御を悪用したDoS攻撃、いわゆる「HTTP/2 Priority Flood」だ。
攻撃者は、数百〜数千のストリームを開き、ひっきりなしに`PRIORITY`フレームを送信する。あるいは、意図的に複雑で深い依存関係ツリーを構築する。これを受けたサーバーは、ツリー構造を維持・更新するためのメモリとCPUリソースを強制的に消費させられ、正当なリクエストを処理できなくなる（CPU exhaustion）。
実際に、過去にはこうしたHTTP/2の脆弱性（CVE-2023-44487 など、いわゆる「HTTP/2 Rapid Reset Attack」の親戚筋や関連バグ）がインフラを揺るがした。
対策としてのサーバー設定（Nginxの例）
現代の堅牢なWebサーバーやプロキシでは、クライアントからの過剰なPRIORITYフレームや依存関係の深さを制限するディレクティブが用意されている。
http {
# HTTP/2のストリーム制御に関するセキュリティチューニング
# 同時オープン可能な最大ストリーム数を絞り、リソース枯渇を防ぐ
http2_max_concurrent_streams 128;
# クライアントからの過剰なPRIORITYフレームや複雑なツリー構造を抑制
# (※使用しているNginxモジュールやディレクティブのバージョンに依存しますが、
# アップストリームやCDN層でのレートリミットが非常に有効です)
}
セキュリティの鉄則は「クライアントを信用しないこと」だ。ブラウザが送ってくる優先度ヒューリスティクスをそのまま鵜呑みにするのではなく、サーバー側で適切にリミットをかけ、場合によっては無視する（あるいはフラットに扱う）勇気もインフラアーキテクトには求められる。
—
5. そしてHTTP/3（QUIC）へ：優先度制御のパラダイムシフト
ここまでHTTP/2の優先度制御の仕組みと闇を解説してきたが、IETFはこの失敗から何を学んだのだろうか？
その答えが HTTP/3（QUIC） である。
HTTP/3では、トランスポート層にUDPベースのQUICを採用し、TCPのような単一コネクション上のHOLブロックを完全に排除した。そして、ストリームの優先度制御においては、HTTP/2の複雑な「ツリー構造（DEPENDENCY）」を廃止した。
代わりに導入されたのが、Extensible Prioritization（拡張優先度）仕様である。
- Urgency (0〜7の整数): 緊急度
- Incremental (boolean): インクリメンタルに処理すべきか（例：動画のストリーミングなど）
これらをHTTPヘッダー（`Priority`フィールド）や専用フレームとしてシンプルに渡し、サーバー側の複雑なツリー計算を不要にした。ブラウザ実装の差異や、中間者（Proxy/CDN）での解釈の揺れも大幅に削減されている。
—
結びにかえて
HTTP/2の優先度制御は、エンジニアリングのロマンと現実の複雑さが織りなす見事な縮図だ。「より速く、より効率的に」というエンジニアの純粋な願いが、複雑怪奇な実装を生み、セキュリティリスクを呼び、そして次のプロトコル（HTTP/3）への進化の原動力となった。
もしあなたが今、高負荷なWebシステムのインフラ設計や、Nginx・Envoy・Envoyといったプロキシのチューニングに携わっているなら、単に「HTTP/2が有効になっているか」を確認するだけでは不十分だ。パケットキャプチャをとり、TCPバッファの挙動を監視し、そしてクライアントが持ち込む「優先度」という名の不確定要素にどう対処すべきか――その全レイヤーを見通す視点を持っていてほしい。
プロトコルの裏側にある文脈を愛する者にとって、ネットワークのパケットは、いつだって最高の読み物なのだから。
コメント