HTTP/2フロー制御の深層：マルチプレクシングの光と影を制するパケットエンジニアリング
Webの高速化を推し進めたHTTP/2。その最大の目玉である「マルチプレクシング（Multiplexing）」は、1本のTCPコネクション上で無数のリクエストとレスポンスを同時に多重化し、HTTP/1.xの頭部ブロック抜け（Head-of-Line Blocking）という長年の呪縛を鮮やかに解き放ちました。
しかし、プロトコル設計者であれば誰もがここで一つの恐怖に直面するはずです。「もし、帯域を食いつぶす重いリクエストが、細々とデータを送りたい他のストリームを完全に圧倒したらどうなるのか？」あるいは、「受信側のメモリバッファが底をつき、カーネルが悲鳴を上げたとき、あふれ出たパケットはどこへ消えるのか？」
HTTP/2はこの課題に対し、アプリケーション層における精緻なフロー制御（Flow Control）という防衛策を用意しました。今回は、`WINDOW_UPDATE`フレームがパケットの海をどう制御し、TCP層やTLS層とどう協調して極限のパフォーマンスを引き出すのか、その内部挙動の深淵へと飛び込みましょう。
—
1. ストリームとコネクション：二重の制御レイヤー
HTTP/2のフロー制御を語る上で外せないのは、それが「ストリーム単位」と「コネクション（セッション）単位」という、二階建ての構造を持っている点です。ここを誤解していると、プロダクション環境のチューニングで思わぬハマりどころに遭遇します。
フロー制御の対象となるのは、データペイロードを運ぶ `DATA` フレームのみです。`HEADERS` や `SETTINGS` などの制御フレームは、このフロー制御の枠外に置かれます。なぜなら、メタデータのやり取りまで止まってしまっては、デッドロックを引き起こすからです。
制御のスコープ
- ストリーム単位（Stream-level Flow Control）: 個々のリクエスト/レスポンス単位で帯域やバッファを制御します。ある特定の重い動画ファイル転送が、APIのJSONレスポンスをブロックしないようにするために存在します。
- コネクション単位（Connection-level Flow Control）: 1本のTCPコネクション全体のスループットを制限します。単一のコネクションが配下の全ストリームを合算して過剰なメモリを消費するのを防ぎます。
受信側（クライアントまたはサーバー）は、自身のアプリケーションバッファの空き容量を相手に伝えることで、この制御の主導権を握ります。
—
2. パケットレベルの挙動：`WINDOW_UPDATE` とクレジット制
HTTP/2のフロー制御は、純粋なクレジット制（Window-based Flow Control）で動いています。
初期状態として、両者は `SETTINGS` フレーム（通常は `SETTINGS_INITIAL_WINDOW_SIZE`）によって、デフォルトのウィンドウサイズ（多くの実装で 65,535 バイト = 64KB弱）を設定し合います。送信側は、この「クレジット」の残高が許す限りしか `DATA` フレームを送ることができません。
[送信側 (Sender)] [受信側 (Receiver)]
| |
|— DATA (Len: 10,000 bytes) ———————–>| (ウィンドウ残高: 65,535 -> 55,535)
|— DATA (Len: 20,000 bytes) ———————–>| (ウィンドウ残高: 55,535 -> 35,535)
| |
| (アプリケーション層がデータを読み出し、 |
| バッファに空きが生まれたためクレジットを回復) |
| |
|<-- WINDOW_UPDATE (Increment: 30,000 bytes) ---------| (ウィンドウ残高: 35,535 -> 65,535)
| |
|— DATA (Len: 15,000 bytes) ———————–>|
ウィンドウ枯渇の瞬間
もし送信側がウィンドウサイズを超えてデータを送ろうとした場合、送信側のストリームはブロック（Stalled）状態に陥ります。これ以上 `DATA` フレームを送出できず、TCPの送信バッファやアプリケーションのキューで待機せざるを得なくなります。
ここで受信側がアプリケーション層でデータを処理し、バッファを解放すると、次に行うのが `WINDOW_UPDATE` フレームの送信です。このフレームには「これだけのバイト数を追加で受け取れるようになった（Window Increment）」という値が格納されており、送信側はこの数値を受け取ることで再びパケットの送出を再開できます。
—
3. トランスポート層（TCP）との相克と「TCPのHead-of-Line Blocking」
ここで、インフラエンジニアなら誰もが疑問に思うはずです。「なぜ、信頼性の高いトランスポート層（TCP）にフロー制御があるのに、わざわざアプリケーション層（HTTP/2）でも同じようなことをするのか？」と。
ここに、HTTP/2が抱える構造的なジレンマがあります。
TCPのフロー制御の限界
TCPもウィンドウサイズ（受信ウィンドウ）を用いたフロー制御を持っています。しかし、HTTP/2は1本のTCPコネクション上で複数のストリームを多重化しています。
もし、TCP層のフロー制御だけを使っていると、次のような現象が起きます。
1. ストリームAでパケットロスが発生し、TCPの受信バッファが順序待ち（Out-of-Order）のまま埋まる。
2. TCP層では「バッファが詰まった」と判断され、受信ウィンドウが縮小、あるいはゼロになる。
3. たとえストリームBのデータが完璧に揃っていても、同じTCPコネクションを共有しているがために、ストリームBのデータまでもがTCP層で足止めを食らう。
これが、HTTP/2における「TCPのHead-of-Line Blocking」です。
HTTP/2フロー制御の真の存在意義
HTTP/2のアプリケーション層フロー制御は、「特定のストリームがTCPバッファを独占し、他のストリームを窒息させるのを防ぐ」ためのものです。アプリケーションが適切にストリーム単位のウィンドウを管理することで、TCP層のブロックスコープを最小限に抑え、マルチプレクシングの恩恵を最大限に保つことができます。
—
4. 実務の現場で直面するパフォーマンス・ボトルネックとチューニング
プロダクション環境（Nginx, Envoy, あるいはGo/Node.js製カスタムサーバー等）において、このフロー制御が原因でスループットが伸び悩むケースは後を絶ちません。特に、広帯域かつ高遅延（High BDP: Bandwidth-Delay Product）なネットワーク環境では顕著です。
1. 初期ウィンドウサイズの最適化
デフォルトの65,535バイトでは、RTT（往復遅延）が大きいグローバルな通信において、最初の1往復分のデータしかパイプラインに乗せられず、帯域を完全に活用できません（BDPの法則）。
モダンなHTTP/2実装では、より大きな初期ウィンドウサイズを `SETTINGS` フレームでネゴシエーションします。
2. リバースプロキシ・APIゲートウェイの設定例 (Nginx)
Nginxをフロントエンドに置く場合、HTTP/2のバッファリング挙動はスループットに直結します。
http {
# HTTP/2接続における各ストリームの初期ウィンドウサイズを設定
# デフォルトから拡張し、高遅延環境でのスループット低下を抑制する
http2_max_concurrent_streams 128;
# サーバー側からクライアントへ送る際のウィンドウサイズバッファの割り当て
# クライアントからの WINDOW_UPDATE を効率的に処理するためのメモリチューニング
# (※実際のディレクティブはモジュールやバージョンに依存しますが概念としての設定例)
}
3. カーネルパラメータ（Linux TCPチューニング）との連携
HTTP/2のフロー制御をスムーズに機能させるためには、下位レイヤーであるLinuxカーネルのTCPバッファチューニングが不可欠です。`/etc/sysctl.conf` において、BDPに合わせた適切なメモリ割り当てを行います。
最大TCP受信バッファと送信バッファのサイズを拡大（高BDPネットワーク対策）
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
自動チューニングバッファの範囲設定 [最小, デフォルト, 最大 (バイト単位)]
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
ウィンドウのスケーリングを有効化（RFC 1323）
net.ipv4.tcp_window_scaling = 1
—
5. セキュリティの観点：フロー制御を悪用した攻撃と防御
高度なプロトコル仕様は、裏を返すとお手製の攻撃ベクトルになり得ます。HTTP/2のフロー制御も例外ではありません。
HTTP/2コンティニュエーション洪水 (CONTINUATION Flood) やリソース枯渇
悪意あるクライアントが、わざと極端に小さな `SETTINGS_INITIAL_WINDOW_SIZE` をサーバーに通知したり、ストリームを開いたまま `WINDOW_UPDATE` を一切送信しない（あるいは非常に遅延させる）ことで、サーバー側のバッファやメモリを意図的に枯渇させる攻撃が存在します。
サーバー側が「このストリームはまだデータを送る気がない」と判断してバッファを保持し続けた結果、ワーカープロセスが枯渇し、正当なユーザーへのサービス提供が停止する（DoS状態）に陥ります。
堅牢なインフラストラクチャ設計のための対策
1. タイムアウトの厳格化: アイドル状態のストリームや、長期間 `WINDOW_UPDATE` が返ってこないストリームに対しては、サーバー側から `RST_STREAM`（エラーコード: `CANCEL` または `ENHANCE_YOUR_CALM`）を送信して強制切断します。
2. メモリ制限の厳守: コネクションあたりの最大メモリ消費量や、同時オープン可能な最大ストリーム数（`SETTINGS_MAX_CONCURRENT_STREAMS`）を適切に制限し、リソースの暴走を防ぎます。
—
結びにかえて
HTTP/2のフロー制御は、パケットの洪水からアプリケーションを守るための「見えないダム」です。
パケットがNICを叩き、TLSの暗号化が解かれ、HTTP/2フレーミング層を経てアプリケーションのバッファに至るまで、この細やかなクレジット管理が絶えず行われています。単に「速いプロトコルだから」とデフォルトのまま放置するのではなく、背後にあるパケットの挙動とOSのバッファ戦略までを見通すことこそが、真のインフラアーキテクトに求められる視座と言えるでしょう。
ネットワークの挙動に思いを馳せながら、あなたのシステムの `SETTINGS` と `WINDOW_UPDATE` を、今一度見つめ直してみてください。
コメント