HTTP/2 PRIORITYの真実：なぜあの「帯域制御の野望」は現場でスルーされるのか？
こんにちは。ネットワークの底を流れるパケットの挙動を見つめ続けて早幾年――。インフラの現場やWeb APIの設計現場で、こんな悩みに直面したことはないだろうか。
「SPA（Single Page Application）の初期ロード時に、どうしてもクリティカルなJSやAPIレスポンスの到着が遅れる」
「画像のような重要度の低いアセットが、メインのCSSやメインスクリプトの帯域を食いつぶしている気がする」
HTTP/1.1の時代、私たちはドメインシャーディング（複数ドメインへの並列接続）を駆使し、ブラウザのコネクション制限を無理やり突破してリソースをねじ込んでいた。そして鳴り物入登場したHTTP/2は、1本のTCPコネクション上で複数のリクエストとレスポンスを同時に多重化（マルチプレクシング）するという、圧倒的な美しさをもたらした。
しかし、ここで一つの疑問が生じる。
「1本の配管（TCPコネクション）にすべてのリソースを相乗りさせるなら、誰がどのリソースを優先して流すのかをどうやって決めるのか？」
その問いに対するHTTP/2の公式な答えが、今回深掘りする「PRIORITYフレーム」だ。
ストリームの依存関係と重み付け（Weight）を巧みに操り、ブラウザからサーバーへ「この順番で、この比率で帯域を配分しろ」と指示を出す――一見すると、インフラエンジニアのロマンをくすぐる完璧な仕組みに見える。
だが、シニアの現場感覚から正直に言おう。このPRIORITYフレーム、現在のWebの現場では「ほとんど使われていない（あるいは無視されている）」のが現実だ。
今回は、RFC 7540が定めたPRIORITYの美しい理論と構造を解説した上で、なぜそれが現場で廃れつつあるのか、そして現代のWeb APIやインフラ設計において私たちが本当に向き合うべき「通信制御の現実」は何なのかを、徹底的に紐解いていこう。
—
1. HTTP/2 PRIORITYの基本構造：依存関係ツリーと重み付け
まずは、HTTP/2がどのようにリソースの優先順位を定義しようとしたのか、そのメカニズムのコアを押さえよう。
HTTP/2のストリームは、単なる平坦なリストではない。ブラウザ（クライアント）は、送信する各リソースの優先順位を「依存関係ツリー（Dependency Tree）」として構築し、`PRIORITY`フレーム、あるいは`HEADERS`フレーム内のフラグとペイロードを通じてサーバーに通知する。
3つの構成要素
PRIORITYフレームのペイロード（4バイトのストリーム依存関係 + 1バイトの重み）は、以下の要素で構成されている。
1. Exclusive Flag（排他フラグ: 1bit）
指定した親ストリームに対して、自分が「唯一の子供」になる（既存の子供たちは自分の配下にぶら下がり直す）かを指定するフラグ。ツリー構造をダイナミックに組み替えるために使われる。
2. Stream Dependency（依存先ストリームID: 31bit）
「どのストリームが完了（あるいは処理）した後に、このストリームを処理すべきか」という依存先の親ストリームID。
3. Weight（重み: 8bit = 値 1〜256）
同じ親を持つ兄弟ストリーム間で、帯域をどのように分配するか比率を指定する。公式には「Weight – 1」が実際の値としてエンコードされるため、最小値「1」は「0（内部的には1）」、最大値「256」は「255」として流れる。実際の帯域配分は、兄弟の重みの総和に対する比率で決まる。
理論上の通信フローイメージ
例えば、Webページ全体の骨組みとなるHTML（ストリーム1）があり、その配下にCSS（ストリーム3）と、重要度の異なる2つの画像（ストリーム5, 7）があるとしよう。
[Stream 0 (Root)]
│
▼
[Stream 1 (HTML)] ── (優先度: 最高)
│
├─► [Stream 3 (CSS)] ── (Weight: 200)
│
├─► [Stream 5 (Critical Image)] ── (Weight: 100)
│
└─► [Stream 7 (Banner Ad)] ── (Weight: 10)
このツリー構造をサーバーが正しく解釈した場合、サーバーはHTMLの送出を最優先し、次にCSSとCritical Imageに多くの帯域を割き、Banner Adには余った帯域を少しずつ割り振る……という、非常にスマートな帯域制御が可能になるはずだった。
—
2. 実際のパケット構造とデバッグ時の確認方法
では、このPRIORITYフレームが実際のワイヤー上でどう流れているかを見てみよう。Wiresharkなどのパケットキャプチャや、HTTP/2対応のデバッグツールで見ると、フレームタイプは `0x2 (PRIORITY)` として現れる。
+————————————————-+
| Length (24) |
+—————–+—————+—————+
| Type (8) | Flags (8) |
+-+—————+—————+—————–+
|R| Stream Identifier (31) |
+=+=================================================+
|E| Dependent Stream Identifier (31)|
+-+————————————————-+
| Weight (8) |
+—————–+
実務の現場で「ブラウザが本当に意図した優先度でリクエストを送っているか？」を検証したい場合、ChromeのDeveloper Toolsの「Network」タブだけでは不十分なことがある。そんなときは、内部ログ（NetLog）を採取するか、ローカルプロキシ（mitmproxyやnghttp2など）を挟むのが定石だ。
例えば、C言語やPythonの実験用ライブラリ（`h2`や`hyper-h2`など）を用いて、明示的にPRIORITYフレームを送信するPythonコードのイメージは以下のようになる。
Pythonのh2ライブラリを用いたPRIORITYフレーム送信の概念コード
import h2.connection
import h2.config
クライアント接続の初期化
config = h2.config.H2Configuration(client_side=True)
conn = h2.connection.H2Connection(config=config)
接続開始のハンドシェイク（実際にはソケット通信が必要）
conn.initiate_connection()
ストリーム1でHTMLのリクエストを送信しつつ、
ストリーム3（CSS）をストリーム1に依存させ、重みを「200」に設定する例
stream_id_css = 3
conn.send_headers(
stream_id=stream_id_css,
headers=[
(‘:method’, ‘GET’),
(‘:path’, ‘/style.css’),
(‘:authority’, ‘example.com’),
(‘:scheme’, ‘https’),
]
)
明示的にPRIORITYフレームを送出する場合の構文（h2ライブラリの例）
conn.increment_flow_control_window(0) # 制御用のダミー
実際のPRIORITY制御：ストリーム3をストリーム1の配下に置き、重みを200にする
conn.prioritize(
stream_id=stream_id_css,
weight=200,
depends_on=1,
exclusive=False
)
しかし、ここでシニアエンジニアとして冷徹な現実を告げなければならない。「このコードを書いてサーバーに送っても、多くのモダンWebサーバーやリバースプロキシは、この優先度を完全に無視するか、あるいは独自のヒューリスティクスで上書きする」という事実を。
—
3. なぜ「PRIORITY」は現場で使われないのか？（闇と教訓）
HTTP/2のPRIORITYフレームは仕様としては美しかったが、実運用の現場ではいくつかの致命的な課題に直面し、事実上の「デッドコード」化していった。
1. ブラウザ実装のバラつきと「ツリーの複雑化」
かつて、Chrome、Firefox、Safariなどの各ブラウザベンダーは、それぞれ独自のアルゴリズムで依存関係ツリーを動的に構築して送信していた。
あるブラウザは「DOMの出現順に依存させる」、別のブラウザは「ファイルタイプごとに階層化する」といった具合だ。これを受け取るサーバー側からすると、クライアントごとに全く異なる、しかも頻繁に組み替えられる巨大な依存関係ツリーをメモリ上に維持し、それに基づいてパケットの送出順序を制御し続ける必要があった。これはサーバー側のCPUとメモリに対する巨大なDDoS攻撃に近い負荷を生む。
2. HOL（Head-of-Line）ブロッキングのレイヤー違い
HTTP/2は1本のTCPコネクション上で多重化を行うため、TCPレイヤーでのパケットロスが発生すると、そのコネクション上の「すべてのストリーム」が一時停止する（TCPのHOLブロッキング）。
いくらアプリケーション層でPRIORITYフレームを駆使して「このストリームを最優先しろ！」と叫んでも、大元のTCPパケットが1つロスしていれば、すべてが足止めを食らう。この構造的なジレンマが、PRIORITYフレームの努力を無力化してきた。
3. CDNやリバースプロキシの介在
現実のWebインフラストラクチャにおいて、クライアントとオリジンサーバーの間には、CloudflareやAWS CloudFront、Nginx、EnvoyといったCDNやリバースプロキシが存在する。
これらのミドルウェアの多くは、複雑なHTTP/2の依存関係ツリーをバックエンドのオリジンまで忠実に伝搬させることを放棄した（あるいは、単にリソースの効率的なバッファリングや公平な帯域配分を優先した）。
こうした背景から、IETF（HTTPWorking Group）もこの失敗を認め、次世代規格であるHTTP/3 (QUIC)では、複雑な依存関係ツリーを廃止し、もっとシンプルで軽量な「Extensible Priorities（拡張優先度：UrgencyとIncrementalの2つのパラメータ）」へと舵を切ることになった。
—
4. 現代のインフラ・API設計における「通信制御」の現実解
では、現在私たちがWeb APIやインフラを設計・運用するにあたって、帯域や読み込み順序の制御をどう考えるべきなのか。現場で役立つ実践的なプラクティスをいくつか提示しよう。
① HTTP/2の「マルチプレクシング過剰」に頼らない
1本のコネクションに何百ものリクエストを同時に流し込むのは、必ずしも得策ではない。特にサイズが大きく処理に時間のかかるAPIリクエストと、数KBの静的アセットが同じコネクションを奪い合うと、前述の通りリソースの枯渇やレイテンシの悪化を招く。
重要なAPIエンドポイントや、極限までレイテンシを詰めたいマイクロサービス間通信では、あえて接続（コネクション）を分ける、あるいはドメインやパスを適切に分離して設計する勇気も必要だ。
② サーバー側のリソースプールの分離（EnvoyやNginxのチューニング）
もし自社でNginxやEnvoyなどのプロキシを運用している場合、HTTP/2のストリーム制御やバッファサイズの設定を見直そう。
例えば、Envoyの過剰なバッファリングは、クライアントからのリクエスト順序を歪める原因になる。
Envoy ProxyにおけるHTTP/2設定のヒント（抜粋）
http_filters:
- name: envoy.filters.http.router
typed_config:
“@type”: type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
- name: envoy.filters.http.connection_manager
typed_config:
“@type”: type.googleapis.com/envoy.extensions.filters.http.connection_manager.v3.ConnectionManager
codec_type: AUTO
stat_prefix: ingress_http
http2_protocol_options:
# 同時ストリーム数の上限を適切に制限し、過剰な多重化を防ぐ
max_concurrent_streams: 100
# 初期ウィンドウサイズの調整
initial_stream_window_size: 65536
initial_connection_window_size: 1048576
③ プリロード（``）やヒントの活用
ブラウザにリソースの優先順位を正しく認識させたい場合、複雑なPRIORITYフレームの動的制御に期待するよりも、HTMLの`
`内での明示的なヒント (`rel=”preload”`, `rel=”preconnect”`) や、HTTPレスポンスヘッダでの `Link: <...>; rel=preload` を使う方が、はるかに確実でモダンなアプローチだ。レスポンスヘッダによる確実な事前通知の例
Link: ; rel=preload; as=style
Link: ; rel=preload; as=script
ブラウザはこれらのヘッダーを解釈すると、通常のHTMLパースを待たずに即座に高い優先度でリクエストを発行してくれる。これはミドルウェアやプロキシの仕様に依存しにくく、極めてロバストな手法である。
—
まとめ：プロトコルの美しさと「現場の現実」のバランス感覚
HTTP/2のPRIORITYフレームは、ネットワーク工学の観点からは非常に美しく、洗練された仕様だった。しかし、複雑すぎるツリー構造、サーバー・プロキシ側の実装コスト、そしてTCPというトランスポート層の限界により、実務の現場ではその輝きを失いつつある。
シニアエンジニアとして私たちが持つべき視点は、「仕様書に書いてあるから安心する」のではなく、「実際のパケットがネットワーク機器やプロキシを通過する時、どのように扱われ、どこでボトルネックになるのか」を常に疑い、検証する姿勢だ。
HTTP/2の裏側で何が起きているのかを深く理解した上で、あえてプリロードやコネクション分離といったシンプルで確実な手段を選ぶ――それこそが、トラブルに強く、スケーラブルなWebインフラを作り上げるための最大の秘訣である。
コメント