HTTP/2フロー制御の深層：マルチプレクシングの光と影を制するパケットエンジニアリング
ネットワークスペシャリストにとって、プロトコルの進化とは「制約との終わりなき戦い」に他ならない。TCPが抱えるヘッド・オブ・ライン（HoL）ブロッキングを打破し、単一のTCPコネクション上で無数のリクエストとレスポンスを同時に多重化（マルチプレクシング）するHTTP/2は、誕生以来、Webのパフォーマンスを劇的に引き上げてきた。
しかし、ここで立ち止まって考えてみてほしい。
無制限に並列化されたストリームが、もし受信側のメモリバッファを無視してデータを送りつけたらどうなるか？ 答えは明白だ。受信側のカーネルやアプリケーション層は瞬時にリソースを枯渇させ、コネクション全体が崩壊する。
この「リソースの暴走」を防ぐためにHTTP/2レイヤーに実装された防波堤、それが 「HTTP/2フロー制御（Flow Control）」 である。
今回は、TCPの輻輳制御とは何が異なり、なぜアプリケーション層のフロー制御が必要なのか。そのパケットレベルの挙動から、Linuxカーネルのチューニング、そして悪名高いスロウロリス系攻撃への対策まで、インフラの深淵を覗く者たちのための知見を紐解いていこう。
—
1. なぜTCPがあるのにHTTP/2独自のフロー制御が必要なのか？
「TCPにはウィンドウベースのフロー制御（ウィンドウサイズ通知）があるのだから、上位プロトコルであるHTTP/2でわざわざ同じような制御をする必要はないのではないか？」
実務経験の浅いエンジニアから、よくこのような質問を受ける。
結論から言えば、TCPのフロー制御は「コネクション全体」を管理するものであり、HTTP/2の「個別のストリーム」を保護できない。これがすべての核心だ。
[ TCP Connection ] （全体で1つのウィンドウ）
├── Stream 1 (重い画像データを取得中…帯域を大量消費)
├── Stream 2 (小さなAPI JSON応答。今すぐ読みたいのにブロックされる)
└── Stream 3 (ユーザーが中断した動画ストリーム。まだデータを送り続けている)
HTTP/2の美しさは、1つのTCPコネクション上で複数の独立した「ストリーム」を多重化できる点にある。しかし、これは同時に、1つの重いストリーム（例えば数GBのファイルダウンロード）がTCPバッファを独占し、同じコネクション上で流れているクリティカルなAPIリクエストのパケットを窒息させるという致命的な構造的矛盾を孕む。
これがHTTP/2レイヤーにおける「アプリケーション層のヘッド・オブ・ライン・ブロッキング」だ。
だからこそ、HTTP/2はトランスポート層（TCP）の下位から独立して、ストリーム単位（Stream-Level）およびコネクション単位（Connection-Level）の二重の防衛線を持つ必要があるのだ。
—
2. パケットレベルで見る WINDOW_UPDATE のメカニズム
HTTP/2のフロー制御は、信用に基づく（Credit-based）方式を採用している。
すべての送受信者は、相手から「これだけのバイト数を送ってもいいよ」という許可（クレジット）を得なければ、データを送信できない。この許可を動的に通知するのが `WINDOW_UPDATE`フレーム である。
初期ウィンドウサイズ（SETTINGSフレーム）
コネクション確立直後、クライアントとサーバーは `SETTINGS` フレームを交わす。ここで定義される `SETTINGS_INITIAL_WINDOW_SIZE`（デフォルトは65,535バイト、64KB）が、すべての新規ストリームの初期送信可能バイト数となる。
WINDOW_UPDATE の往復運動
データ送信者がペイロード（`DATA`フレーム）を送り出すと、保有している送信ウィンドウサイズ（Send Window）がその分だけ減少する。受信側は、データを消費（アプリケーションがバッファから読み出し）するにつれて、空いた容量分だけ `WINDOW_UPDATE` フレームを送り返し、相手のウィンドウを回復させる。
[クライアント (送信)] [サーバー (受信)]
│ │
│── DATA (64KB) ─────────────────────────>│ (バッファに格納)
│ (Send Window: 0) │ (アプリがデータを読み出し)
│ │
│<── WINDOW_UPDATE (Increment: 64KB) ─────│ (ウィンドウを回復)
│ (Send Window: 64KB) │
│ │
この制御には、以下の2つのスコープが存在する。
1. ストリーム単位のフロー制御:
特定の一つのストリームが他のストリームを圧迫しないように制御する。フレームの `Stream Identifier` に対象のストリームIDが指定される。
2. コネクション単位のフロー制御:
`Stream Identifier` が `0` に設定される。これはTCPコネクション全体で使用可能なトータルのバッファサイズを制御し、サーバー全体のメモリ枯渇を防ぐ。
—
3. チューニングと実装：NGINXやGo言語におけるウィンドウサイズ最適化
高スループットが要求される大規模配信基盤（CDNや動画配信など）では、デフォルトの64KBというウィンドウサイズは、ナノ秒単位で帯域を競い合う現代の高速ネットワーク（高BDP: Bandwidth-Delay Product環境）においてボトルネックになる。
例えば、RTT（往復遅延時間）が50msの環境でウィンドウサイズが64KBに固定されている場合、理論上の最大スループットは以下の計算式で頭打ちになる。
$$\text{Throughput} = \frac{\text{Window Size}}{\text{RTT}} = \frac{65,535 \text{ bytes}}{0.05 \text{ s}} \approx 1.31 \text{ MB/s} \approx 10.5 \text{ Mbps}$$
いくら回線が1Gbpsの太いパイプを持っていても、HTTP/2のフロー制御ウィンドウが小さければ、パケットは常に送信をストップし、RTTの度にアイドル時間が生まれてしまうのだ。
NGINXにおけるHTTP/2ウィンドウサイズの変更
現代のNGINX（1.25.x以降など）では、HTTP/2の実装がモダナイズされ、動的なウィンドウ管理やパフォーマンス向上のためのディレクティブが洗練されている。以下は、高スループットを狙うインフラにおける設定例だ。
http {
# HTTP/2の設定コンテキスト
# クライアントからの初期ウィンドウサイズ要求に対するサーバー側の設定
# 大きなBDP環境では、デフォルトよりも大きな値を検討する（例: 256KB〜1MB）
http2_recv_buffer_size 256k;
server {
listen 443 ssl http2;
server_name edge.example.internal;
# SSL/TLSの最適化（TLS 1.3推奨、OCSP Stapling有効化など）
ssl_protocols TLSv1.3 TLSv1.2;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
location / {
root /usr/share/nginx/html;
index index.html;
# プロキシ時のバックエンドへのバッファリング制御
proxy_buffering on;
proxy_buffer_size 128k;
proxy_buffers 4 256k;
}
}
}
Go言語によるHTTP/2サーバーでのウィンドウサイズ変更実装
自社製のAPIゲートウェイやマイクロサービス間通信（gRPC含む）をGo言語で構築している場合、`http.Server` の `ConnState` や `Transport` のチューニング、あるいは内部の `golang.org/x/net/http2` パッケージを用いた低レイヤーでの制御が必要になる。
以下は、明示的に初期ウィンドウサイズを変更するサンプルコードである。
package main
import (
“log”
“net/http”
“golang.org/x/net/http2”
)
func main() {
mux := http.NewServeMux()
mux.HandleFunc(“/”, func(w http.ResponseWriter, r http.Request) {
w.Write([]byte(“Hello, HTTP/2 Flow Control Tuning!”))
})
server := &http.Server{
Addr: “:8443”,
Handler: mux,
}
// HTTP/2プロトコルの詳細設定を初期化
h2s := &http2.Server{
// クライアントに通知する初期ストリームウィンドウサイズを拡大 (例: 512KB)
// 大容量レスポンスを高速に返却する際にRTTによるアイドルを防ぐ
MaxUploadBufferPerConnection: 1024 1024 10, // 10MB
MaxUploadBufferPerStream: 1024 1024 2, // 2MB
}
// http2ライブラリを標準サーバーに明示的にバインド
err := http2.ConfigureServer(server, h2s)
if err != nil {
log.Fatalf(“Failed to configure HTTP/2: %v”, err)
}
log.Printf(“Starting HTTP/2 TLS server on https://localhost:8443”)
// 本番環境ではValidなTLS証明書パスを指定する
log.Fatal(server.ListenAndServeTLS(“server.crt”, “server.key”))
}
—
4. セキュリティの罠：スローロリス攻撃（Slowloris）とHTTP/2の脆弱性
プロトコルの高度化は、新たな攻撃ベクターを生む。フロー制御はその利便性の裏で、悪意ある攻撃者に「サーバーのリソースを合法的に人質に取る」手段を与えてしまうことがある。
リソース枯渇攻撃（HPACK Bomb & Slow Read）
代表的なものが 「Slow Read Attack（スロー・リード・アタック）」 だ。
攻撃者は、正当なHTTP/2コネクションを確立した後、意図的に自身の受信ウィンドウを極端に小さく（あるいは `WINDOW_UPDATE` を全く送らない状態に）して、大量のリクエストを発行する。
サーバー側は、レスポンスデータを生成したものの、クライアントのウィンドウが `0` のため送信できず、カーネルのソケットバッファやアプリケーションメモリ内にデータを保持し続けざるを得なくなる。これが多数のストリームで行われると、サーバーのメモリは瞬時に枯渇し、正当なユーザーがサービスを受けられなくなる（Denial of Service）。
実戦的な防御策
こうしたフロー制御を悪用した攻撃からインフラを守るためには、アプリケーション層とロードバランサー（WAF/リバースプロキシ）の協調防衛が不可欠である。
1. タイムアウトの厳格化:
`WINDOW_UPDATE` が長期間返ってこないストリームに対しては、サーバー側から `RST_STREAM`（エラーコード: `SETTINGS_TIMEOUT` または `CANCEL`）を送信し、強制的にコネクションを切断する。
2. バッファ制限の設定:
単一のクライアントが消費できるメモリ量（未送信データのバッファ上限）にハードリミットを設ける。
3. HTTP/3（QUIC）への移行視野:
TCPおよびHTTP/2のトランスポート層の限界を根本から解決するため、UDPベースのQUICでは、ストリーム単位のフロー制御がさらに洗練されており、UDPの特性を活かしたマルチプレクシングによる耐障害性が向上している。インフラの将来的なロードマップとしてHTTP/3の導入を検討すべきタイミングに来ている。
—
5. まとめ：パケットの呼吸を感じるインフラ運用へ
HTTP/2のフロー制御は、一見すると開発者が意識する必要のない、ブラックボックス化されたレイヤーの挙動に見えるかもしれない。しかし、高負荷時における不可解なスループット低下、メモリリーク、あるいは突発的なDDoS兆候のトラブルシューティングにおいて、パケットがどのように流れ、どこで堰き止められているかを想像できるか否かは、エンジニアとしての生存を分ける決定的な差となる。
「なぜ今、このストリームの転送が止まっているのか？」
そう疑った時、`tcpdump` や `Wireshark` を開き、`WINDOW_UPDATE` フレームの往来とウィンドウ残量の推移を追ってみてほしい。そこには、美しく、かつシビアに設計されたプロトコルの「呼吸」がありありと見えてくるはずだ。
コメント