HTTP/2のフロー制御はなぜTCPとは違うのか？
Webの進化に伴い、私たちはHTTP/1.1の呪縛であった「Head-of-Line（HoL）ブロック」から解放された。TCPコネクションという一本の太いパイプラインの上に、仮想的な「ストリーム」を多重化し、リクエストとレスポンスを同時に流し込むHTTP/2のマルチプレクシングは、当時、エンジニアリング界のちょっとした革命だった。
しかし、ネットワークスペシャリストであるなら、ここで一つの疑問が湧くはずだ。
「TCPにはすでにトランスポート層のフロー制御（ウィンドウ制御）があるのに、なぜアプリケーション層であるHTTP/2の内部で、わざわざ独自にフロー制御を行っているのか？」と。
答えは残酷なまでにシンプルだ。「TCPのフロー制御では、多重化された個別のストリームを保護できないから」である。
TCPのウィンドウは、あくまで「単一のコネクション全体」を管理する。もし、1本のHTTP/2コネクション上で100個のストリームが同時に走っているとき、そのうちの1つの重い動画ファイル（ストリーム#3）のせいで、クライアント側のバッファが溢れそうになったとしよう。
TCPレベルで送信を止めると、どうなるか？
無関係な他の99個の軽量なAPIレスポンス（ストリーム#5や#7など）の転送まで、すべてが強制的にストップしてしまうのだ。これではアプリケーション層でマルチプレクシングをやっている意味が完全に失われる。
だからこそ、HTTP/2はトランスポート層の上に独自のフロー制御機構を構築した。その主役こそが、今回深く切り込む `WINDOW_UPDATE` フレーム である。
—
WINDOW_UPDATEフレームの解剖学：パケットレベルの内部挙動
HTTP/2のすべての通信は「フレーム」というバイナリの単位で行われる。`WINDOW_UPDATE` も例外ではない。そのペイロード構造は極めてミニマルだが、ネットワークの挙動を支配する絶大な権力を持っている。
フレームの基本構造を眺めてみよう。
+—————————————————————+
| Length (24) |
+—————+——————————-+
| Type (8) | Flags (8) |
+-+————-+——————————-+
|R| Stream Identifier (31) |
+-+———————————————+
| Pad Length? (8) |
+———————————————–+
|+———————————————-+
|| [Padding]? |
|+———————————————-+
| Window Size Increment (31) |
+-+———————————————+
注目すべきは、ペイロードの本体である `Window Size Increment`（ウィンドウサイズ増分） のフィールドだ。ここには、受信側が「あとこれだけのバイト数なら、バッファに余裕があるから送ってきていいよ」という許可のサイズが格納される。
ストリームレベル vs 接続（Connection）レベル
`WINDOW_UPDATE` の美しさは、そのスコープが2つの階層に分かれている点にある。
1. ストリームレベルのフロー制御 (`Stream Identifier > 0`)
特定のストリームIDを指定して送信される。そのストリームだけで消費されるバッファの量を管理する。
2. 接続レベルのフロー制御 (`Stream Identifier = 0`)
ストリームIDに `0` が指定される。これはHTTP/2コネクション全体で共有される最大バッファサイズを制御する。
送信側（クライアントまたはサーバー）は、データを送信する際、この「2つのウィンドウサイズ（Stream Window と Connection Window）」の両方が許容する最小値しか一度に送信できない。つまり、どれだけ特定のストリームに空きがあっても、コネクション全体のウィンドウが枯渇していれば、パケットの送信はピタリと止まる。
—
ウィンドウサイズの増分計算と「クレジット枯渇」の罠
初期状態では、HTTP/2のネゴシエーション（SETTINGSフレームの交換）により、送受信双方のウィンドウサイズは 65,535バイト（64KB） に設定される。これは近代的なネットワークの帯域幅（BDP: Bandwidth-Delay Product）から見れば、あまりにも小さすぎる。
高スループットを維持するためには、受信側はデータを受け取るたびに `WINDOW_UPDATE` を送り返し、ウィンドウサイズを積極的に「チャージ（増分）」し続けなければならない。
リアルな計算モデル
ここに、受信側アプリケーションのバッファ管理とウィンドウ更新のアルゴリズムの基本形がある。擬似的なC/Rust風のロジックを見てみよう。
// 受信側がDATAフレームを受け取ったときの処理フロー
void handle_data_frame(uint32_t stream_id, uint32_t payload_len) {
// 1. ストリームおよび接続レベルの利用可能ウィンドウを減算
stream_windows[stream_id] -= payload_len;
connection_window -= payload_len;
// 2. ウィンドウが一定の閾値（例: 半分）を下回ったら、回復させるための増分を計算
if (stream_windows[stream_id] < INITIAL_WINDOW_SIZE / 2) {
uint32_t increment = INITIAL_WINDOW_SIZE - stream_windows[stream_id];
// ストリームレベルの WINDOW_UPDATE を送信
send_window_update(stream_id, increment);
// ローカルのウィンドウ管理値を復元
stream_windows[stream_id] += increment;
}
// 3. コネクション全体（Stream ID = 0）についても同様にチェック
if (connection_window < CONNECTION_WINDOW_THRESHOLD) {
uint32_t conn_increment = TOTAL_BUFFER_SIZE - connection_window;
send_window_update(0, conn_increment);
connection_window += conn_increment;
}
}
この「増分計算」において、インフラエンジニアが陥りがちな罠が 「ウィンドウの枯渇（Starvation）」 である。
もしアプリケーションの読み出し速度（`read()` システムコールなど）が遅く、受信側が `WINDOW_UPDATE` を送るタイミングを逸すると、送信側はウィンドウサイズが `0` になった時点で完全に沈黙する。
Wiresharkなどのパケットキャプチャで、サーバー側が `TCP Window Full` ではなく、HTTP/2層でデータ送信をぴたりと止めている瞬間があれば、それはまさにこのフロー制御のクレジットが尽きた瞬間だ。
—
極限のパフォーマンス：TCPバッファチューニングとTLSハンドシェイクの最適化
HTTP/2のフロー制御を語る上で、下位層であるTCPおよびTLSとの協調を無視することはできない。アプリケーション層のウィンドウ制御がどれほど完璧であっても、トランスポート層のチューニングが疎かであれば、真のパフォーマンスを引き出すことは不可能だからだ。
1. BDP（帯域幅遅延積）とTCPウィンドウサイズ
高速な回線（例えば1Gbps、RTT 20msの環境）において、BDPは以下のように計算される。
$$\text{BDP} = 1,000,000,000 \text{ bps} \times 0.020 \text{ s} / 8 = 2,500,000 \text{ bytes} \approx 2.4 \text{ MB}$$
LinuxカーネルのデフォルトのTCP受信バッファ（`net.ipv4.tcp_rmem`）では、この容量を十分に受け止められないことがある。カーネルパラメータのチューニングは、HTTP/2のマルチプレクシングを支える土台となる。
/etc/sysctl.conf における高スループット向けTCPバッファチューニング例
最小値、デフォルト値、最大値（バイト単位）
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
TCPウィンドウのスケーリングを確実に有効化
net.ipv4.tcp_window_scaling = 1
HTTP/2の `SETTINGS_INITIAL_WINDOW_SIZE` も、このTCPのBDPにあわせて拡大すべきである。Nginxなどのプロダクション環境では、初期ウィンドウサイズを標準の64KBから、例えば `1MB (1048576)` などに拡張してラウンドトリップのロスを防ぐ設定がよく行われる。
2. TLS 1.3とHTTP/2の密な関係
HTTP/2は実質的にTLS（特にTLS 1.3）の利用が必須（h2）とされている。
TLS 1.3の 0-RTT (Zero Round Trip Time) データの送信において、HTTP/2のフロー制御はセキュリティとパフォーマンスの微妙なバランスの上に成り立つ。
0-RTTハンドシェイクで送信されるリクエストは、サーバー側がまだ接続の信頼性を完全に確立していない状態で処理されるため、悪意あるリプレイ攻撃のリスクを伴う。そのため、サーバー側は0-RTTで受け取るデータ量や、それに応じた初期ウィンドウの割り振りを厳格に管理する必要がある。
—
セキュリティの暗黒面：WINDOW_UPDATEが生む脆弱性
完璧に見えるプロトコル設計にも、悪意ある攻撃者の魔の手は伸びる。`WINDOW_UPDATE` フレームは、DDoS攻撃やリソース枯渇攻撃の温床になり得る二面性を持っている。
1. HTTP/2セッション流出 / HTTP/2 Rapid Reset 攻撃 (CVE-2023-44487)
記憶に新しい2023年の大恐慌、「HTTP/2 Rapid Reset」は、まさにこのストリームのライフサイクルとフロー制御、そしてキャンセル処理の隙を突いた歴史的な脆弱性だった。
攻撃者は、数百、数千のストリームを同時にオープンし、サーバーがレスポンスを返し始めるやいなや、即座に `RST_STREAM` フレームを送ってストリームをキャンセルする。これを高速で繰り返すことで、サーバー側はCPUとメモリの限界までリクエストの処理と破棄を強制される。
2. スロー・パケット / ウィンドウサイズ操作攻撃
さらに、`WINDOW_UPDATE` の仕様（最大値 $2^{31}-1$）を悪用した攻撃もある。
悪意あるクライアントが、サーバーに対して非常に小さな `WINDOW_UPDATE` を刻みながら送り、サーバー側の送信バッファを意図的にホールドさせ続ける。あるいは逆に、極端に大きなウィンドウを宣言しておきながら一切データを読み出さないことで、サーバー側のカーネルメモリやアプリケーションバッファを占有し続ける。
対策としての防御策（NginxやEnvoy等のプロキシの設定例）：
プロダクション環境を護るためには、ストリームごとのバッファ上限や、不正なフレーミングに対する厳格なバリデーションが不可欠である。
NginxにおけるHTTP/2関連のバッファおよびウィンドウ制限のチューニング
http {
# 1つのコネクション内で同時に処理できる最大ストリーム数
http2_max_concurrent_streams 128;
# 受信バッファのチャンクサイズ（過剰なメモリ割り当てを防ぐ）
http2_chunk_size 8k;
# 悪意あるスローリクエストを防ぐためのタイムアウト設定
client_body_timeout 10s;
client_header_timeout 10s;
}
—
結びにかえて：パケットの微細な息づかいを感じろ
HTTP/2の `WINDOW_UPDATE` フレームは、一見すると地味なバイナリのやり取りにすぎない。しかし、その背後には「限られたネットワークリソースを、複数のアプリケーション間でいかに公平かつ効率的に調停するか」という、ネットワークアーキテクトたちの知的闘争の歴史が詰まっている。
パケットキャプチャを開いたとき、そこに見える無数の `WINDOW_UPDATE` は、単なる制御信号ではない。それは、クライアントとサーバーが呼吸を合わせ、お互いのバッファの健康状態を確かめ合いながら、極限のスピードでデータを紡ぎ出している「生きた鼓動」そのものなのだ。
このメカニズムを深く理解したあなたなら、明日からのトラブルシューティングで、ログの向こう側で起きているパケットのドラマが手に取るように見えるはずだ。
コメント