HTTP/2 PRIORITYフレームの深層：マルチプレクシングの調律者か、それとも諸刃の剣か
ウェブの高速化という永遠の課題において、HTTP/2はその多重化（Multiplexing）によってHTTP/1.xの頭痛の種であったヘッド・オブ・ライン・ブロッキング（HoLブロック）を華麗に克服した。単一のTCPコネクション上で、CSS、JavaScript、画像、そしてAPIのJSONレスポンスが、まるでカオスの如く入り乱れて流れていく。
しかし、パケットアナライザの波形を覗いたことがあるエンジニアなら、すぐに一つの疑問に突き当たるはずだ。「この無秩序なストリームの洪水の中で、どうやってブラウザは『本当に今必要なクリティカルパスのCSS』を優先して受け取っているのか？」と。
その答えの鍵を握るのが、PRIORITYフレームである。
今回は、パケットの微視的な挙動からLinuxカーネルのバッファチューニング、そしてセキュリティの闇に隠された脆弱性に至るまで、PRIORITYフレームが奏でるストリーム依存関係と重み付けのメカニズムを、徹底的に解剖していこう。
—
1. パケットレベルで見るPRIORITYフレームの解剖学
HTTP/2のフレームは、すべて9バイトの共通ヘッダー（長さ、タイプ、フラグ、ストリーム識別子）から始まる。PRIORITYフレームのタイプは `0x2` であり、そのペイロード構造は極めてシンプルに見える。
+————————————————-+
| Flags (8) |
+————————————————-+
|R| Stream Dependency (31) |
+-+————————————————-+
| Weight (8) |
+————————————————-+
しかし、この数バイトのデータ構造が、トランスポート層（TCP）の枠を超えたアプリケーション層の「帯域配分調律」を司っている。
- E (Exclusive) フラグと Stream Dependency (31ビット): 親ストリームIDを指定する。最上位ビットの `E` が立っている場合、このストリームは親ストリームの「排他的な」子となり、親の直下にぶら下がる唯一のブランチとなる。
- Weight (8ビット): 重み付け。実際の値は `0` から `255` までだが、HTTP/2の仕様上、計算時にはここに `1` が加算される（実効値は `1` 〜 `256`）。つまり、パケット上の表現が `0` であっても、重みとしては `1` として扱われる点に注意が必要だ。
これが意味するのは、クライアント（ブラウザ）がサーバーに対して「私の構築した依存関係ツリーと重みに従って、帯域を配分してくれ」という強いリクエストを送り続けているという事実に他ならない。
—
2. 依存関係ツリーと帯域配分の数学的挙動
サーバーはこのPRIORITYフレームを受け取ると、メモリ上に「優先度ツリー（Priority Tree）」を構築する。このツリー構造の挙動は、ネットワークアーキテクトであれば誰もが知る「重み付けラウンドロビン（Weighted Round Robin: WRR）」の概念を拡張したものだ。
例えば、以下のようなツリーを想定してみよう。
[Stream 0 (Root)]
/ \
(Weight: 16) (Weight: 32)
[Stream 3] [Stream 5] (Critical CSS)
|
(Weight: 2)
[Stream 7] (Thumbnail Image)
このとき、Stream 3とStream 5が同時に送信データを抱えている場合、サーバーは親（Root）から与えられた帯域を、それぞれのWeightの比率（16 : 32 ＝ 1 : 2）で分配する。Stream 5はStream 3の2倍の帯域を得ることになる。
さらに、Stream 3の子供であるStream 7は、親であるStream 3が帯域を消化しきった余剰分、あるいはStream 3を経由する形でなければ帯域を得られない。
なぜこの仕組みが現場のトラブルを生むのか？
ここでインフラエンジニアが直面する大きなジレンマがある。「アプリケーション層（HTTP/2）でどれほど緻密な優先度制御を行っても、それが下位のトランスポート層（TCP）の挙動と完全に乖離している」という点だ。
TCP層は、HTTP/2のストリームの概念など一切知らない。ただ一連のバイトストリームを混在させて送り出すだけである。
もしTCPの輻輳制御（CUBICやBBR）においてウィンドウサイズが制限されていたり、パケットロスによる再送が発生したりした場合、アプリケーション層が「このストリームを最優先に！」と叫んでも、TCPのバッファ内でパケットが詰まっていれば、PRIORITYフレームは何の意味も持たなくなってしまう。
—
3. 実務を揺るがす重大な脆弱性：HTTP/2 Priority Multiplexing (CVE-2023-44487)
PRIORITYフレームの語るべき歴史において、避けて通れない暗黒面がある。それが2023年秋に発覚した 「HTTP/2 Rapid Reset Attack（CVE-2023-44487）」 である。
攻撃者は、HTTP/2のマルチプレクシングとPRIORITYフレーム（あるいはRST_STREAM）の仕様の隙を突き、次のような悪行を働いた。
1. 大量の新しいストリームを開く。
2. 直後に `RST_STREAM` または過剰な `PRIORITY` 更新を送信し、サーバー側にそのストリームのキャンセルや再構築を強制する。
3. これを数千、数万の並行ストリームで高速に繰り返す。
サーバー側は、クライアントからのリクエストに従ってストリームの割り当てとツリーの再計算、メモリの確保・解放を真面目に実行する。結果として、CPU使用率が100%に張り付き、正当なユーザーのリクエストが一切処理できなくなる（DDoS攻撃の完成）。
対策：NginxやEnvoyでの適切なリミット設定
この脆弱性への対策として、各Webサーバーやプロキシのベンダーは、ストリームのキャンセル頻度やPRIORITYフレームの処理回数にハードリミットを設けた。
例えば、Nginx（最新のパッチ適用版）やEnvoyなどのエッジプロキシでは、以下のようにHTTP/2の接続あたりの最大アクティブストリーム数や、リセットの閾値を厳しくチューニングする必要がある。
Envoy ProxyのサーキットブレーカーおよびHTTP/2設定例
static_resources:
listeners:
- name: ingress_listener
address:
socket_address: { address: 0.0.0.0, port_value: 443 }
filter_chains:
- filters:
- name: envoy.filters.network.http_connection_manager
typed_config:
“@type”: type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
codec_type: AUTO
stat_prefix: ingress_http
http2_protocol_options:
# 同時アクティブストリーム数を制限し、リソース枯渇を防ぐ
max_concurrent_streams: 100
# 初期ウィンドウサイズを適切に設定
initial_stream_window_size: 65536
initial_connection_window_size: 1048576
セキュリティスペシャリストやインフラ担当者は、自社のフロントエンドプロキシがこの「Rapid Reset」に対応したバージョンにアップデートされているか、今一度確認すべきである。
—
4. チューニングの極意：RTT削減、TCPバッファ、そしてHTTP/3への移行
PRIORITYフレームを活かしきる、あるいは現代のWebインフラストラクチャにおける優先度制御の限界を突破するためには、OSカーネルレベルのチューニングが不可欠となる。
Linuxカーネルパラメータの最適化 (`/etc/sysctl.conf`)
HTTP/2の多重化と効率的な帯域配分を支えるのは、広範なTCPウィンドウと効率的なキューイングだ。以下のパラメータは、高負荷なHTTP/2サーバーにおいて最低限施すべき設定である。
TCPの送受信バッファの最大値を拡張し、マルチプレクシングによる大量のデータ滞留に対応
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ウィンドウのスケーリングを有効化
net.ipv4.tcp_window_scaling = 1
驚愕の事実：実は主要ブラウザはPRIORITYフレームの送信を「辞めた」？
ここで、プロトコルスペシャリストとしての最大のインサイトをシェアしよう。
実は、ここまで熱く語ってきたHTTP/2のPRIORITYフレームによる依存関係ツリーは、現代のモダンブラウザ（Google ChromeやFirefoxなど）において、デフォルトではほとんど使われなくなっている。
なぜか？ 理由は2つある。
1. 複雑性とオーバーヘッド: ブラウザが構築する複雑な依存関係ツリーをサーバー側が完全に、かつ意図通りに解釈して帯域配分を実装するのは実装依存が激しく、期待通りのパフォーマンス向上に繋がらなかった。
2. HTTP/3 (QUIC) へのシフト: HTTP/2のTCP上での多重化は、依然として「トランスポート層でのHoLブロック（単一のパケットロスが全ストリームを止める現象）」という構造的欠陥を抱えていた。
この反省から生み出されたのが HTTP/3 であり、QUICプロトコルではストリームごとに独立したトランスポート層のフローを持つため、TCPのような結合されたブロックが発生しない。さらに、HTTP/3における優先度制御は、PRIORITYフレームの複雑なツリー構造を捨て、よりシンプルで軽量な 「Extensible Prioritization（拡張優先度）」（HTTP/Extensible Priorities）へと移行している。これはHTTP/2上でもバックポートして利用可能だ。
—
5. 結びにかえて：プロトコルを見据える眼差し
HTTP/2のPRIORITYフレームは、アプリケーション層がネットワークの挙動を自らの手で支配しようとした、美しくも複雑なロマンの結晶であった。
しかし、セキュリティ脆弱性（CVE-2023-44487）の露呈や、トランスポート層の限界、そしてHTTP/3/QUICへの世代交代という歴史の波の中で、その役割は変容しつつある。
インフラアーキテクトやテックリードに求められるのは、単に「仕様通りに設定を投入すること」ではない。「今、目の前のパケットがどのレイヤーでどのようにブロックされ、どのバッファで息を潜めているのか」を脳内でビジュアライゼーションし、プロトコルの美しさと現実の脆弱性のバランスを見極める、その鋭い眼差しなのだ。
コメント