HTTP/2コネクションの魔力と呪縛：ストリームと接続全体のフロー制御が織りなすパケットレベルの攻防
Webの高速化という至上命題のもと、HTTP/1.1の呪縛であった「Head-of-Line（HoL）ブロック」を打ち破るべく登場したHTTP/2。1つのTCPコネクション上で無数のストリームを多重化（マルチプレクシング）し、バイナリフレーミングレイヤーによって効率的にパケットを流し込むそのアーキテクチャは、初めて見たときには魔法のように感じられたものです。
しかし、インフラエンジニアやテックリードとして現場の最前線に立ち、高負荷なプロダクション環境でパケットキャプチャを睨み続けている私たちにとって、HTTP/2は単なる「速いプロトコル」ではありません。それは、TCPという信頼性はあるが融通の利かないトランスポート層の上に、アプリケーション層で独自の「仮想的な世界」を構築し、見えないところで複雑な駆け引きを行う、極めてアクロバティックな制御機構です。
今回はその中でも、多くのエンジニアがブラックボックスとして見過ごしがちな、しかし高スループット環境ではシステムの生死を分ける「コネクションレベルのフロー制御制限」にスポットを当てます。ストリーム単位の制御とコネクション全体のウィンドウがどのように相互作用し、時として予期せぬパフォーマンス低下やスループットの頭打ちを引き起こすのか。パケットの挙動、TLSの現実、そしてLinuxカーネルのチューニングに至るまで、徹底的に解き明かしていきましょう。
—
1. パケットレベルで見る二重のフロー制御：ストリーム vs コネクション
HTTP/2のフロー制御は、OSI参照モデルの概念をあざ笑うかのように、TCPの上位（アプリケーション層）で独自に実装されています。しかも、それが「ストリームレベル」と「コネクションレベル」という二階層のウィンドウ管理で行われている点が、美しくも厄介なところです。
全体と部分のジレンマ
HTTP/2では、各ストリーム（個別のリクエスト/レスポンスの単位）に対して独立したウィンドウサイズ（デフォルトは65,535バイト）が割り当てられます。これにより、ある重い画像データを取得するストリームがウィンドウを使い果たしてブロックされても、軽量なJSONデータをやり取りする別のストリームは滞りなく流れる……これがマルチプレクシングの真骨頂です。
しかし、これと並行して「コネクション全体（Stream ID 0）」のウィンドウサイズが存在します。
[ TCP Connection (TLS / Socket Buffer) ]
├── Stream ID 1 (Header/Data) ──┐
├── Stream ID 3 (Header/Data) ──┼──> [ Connection-Level Window (Stream ID 0) ]
└── Stream ID 5 (Header/Data) ──┘
ここで重要なのは、「個々のストリームがどれだけ高速にデータを送受信できる状態であっても、コネクション全体のウィンドウが枯渇していれば、すべてのデータ転送がストップする」という厳然たる事実です。
パケットの往来：WINDOW_UPDATEの罠
受信側は、データを消費する（アプリケーション層がバッファから読み出す）たびに、送信側に対して `WINDOW_UPDATE` フレームを送信し、ウィンドウサイズを回復させます。
ここでトラップとなりやすいのが、この `WINDOW_UPDATE` が「ストリーム用」と「コネクション用」の2つのスコープで発行される必要がある点です。
1. ストリームがデータを受け取る $\rightarrow$ ストリーム用 `WINDOW_UPDATE` を送信
2. コネクション全体としてデータを受け取る $\rightarrow$ コネクション用 `WINDOW_UPDATE` を送信
もし、アプリケーションのバッファ処理やリバースプロキシ（NginxやEnvoyなど）の内部キューイングに非効率な点があり、コネクションレベルの `WINDOW_UPDATE` が遅延するとどうなるか。アプリケーションは「まだストリームのウィンドウに余裕があるから送れる」と判断してバイナリフレームを送り出そうとしますが、ネットワーク層（HTTP/2レイヤー）の手前でピタリと足が止まります。これが、マルチプレクシング環境下で突如発生する「原因不明のスループット低下」の正体です。
—
2. TLSハンドシェイクとTCPバッファチューニングの極限最適化
HTTP/2のパフォーマンスを語る上で、トランスポート層とセキュア層の底上げを避けて通ることはできません。特にHTTP/2（RFC 7540）では、プレーンテキスト（h2c）が実質的にブラウザでサポートされていないため、すべての通信はTLS（通常はTLS 1.3）の上で行われます。
TLS 1.3とHTTP/2の密な関係
TLS 1.3の登場により、ハンドシェイクは1-RTT（早期データ活用時は0-RTT）へと劇的に高速化されました。しかし、暗号化ハンドシェイクが完了した直後から、HTTP/2の初期セッティング（SETTINGSフレームの交換）が始まります。
ここで、TCPの初期ウィンドウサイズ（IW10 / 初期10セグメント、約14.6KB）が小さすぎると、HTTP/2の初期セッティングやHPACKの動的テーブルサイズ変更、そして最初のヘッダー・データフレームの往来で、無駄なRTT（Round Trip Time）を消費することになります。
Linuxカーネルパラメータの極限チューニング
高トラフィックなHTTP/2サーバー（Nginx、Envoy、Go製カスタムサーバーなど）を運用する場合、以下のカーネルパラメータ (`/etc/sysctl.conf`) は必須のチューニング項目です。TCPバッファが小さすぎると、HTTP/2のストリーム多重化によって生じる膨大なインフライトデータを受け止めきれず、ウィンドウ制御以前にTCPの輻輳制御（CUBICやBBR）レベルで帯域がドブに捨てられます。
コネクションあたりの送受信TCPバッファの最大値・デフォルト値を引き上げ
多重化された数多くのストリームが同時に大容量データを流すのを想定
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432
初期ウィンドウサイズを最大化し、最初の数ラウンドトリップでフルスロットルを維持
net.ipv4.tcp_slow_start_after_idle = 0
パケットロス耐性と高スループットを両立させるため、BBR輻輳制御アルゴリズムの採用を推奨
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
—
3. HPACKとフロー制御の隠れた相関関係
HTTP/2のもう一つの大黒柱であるヘッダー圧縮「HPACK（RFC 7541）」も、実はフロー制御と密接に関係しています。
HTTP/1.1では数キロバイトに及んでいたHTTPヘッダーが、HPACKによって数十バイトに圧縮されます。これにより、初期の `HEADERS` フレームは非常に小さくなり、ストリームやコネクションの初期ウィンドウサイズを圧迫することなく迅速に相手に届きます。
しかし、ここで注意すべきは「HPACKの動的テーブルサイズ更新（Dynamic Table Size Update）」です。
送信側と受信側は、セッション内で共有する動的テーブルのサイズを同期させます。もし、巨大なCookieやカスタムヘッダーを頻繁に送受信し、動的テーブルが激しく更新される高負荷な状況下では、CPUのデコード処理に負荷がかかるだけでなく、特定のストリームがヘッダーの巨大なフラグメントを処理し続けることで、結果的にアプリケーション層の処理がつまり、コネクション全体のウィンドウ解放（`WINDOW_UPDATE` の送信）が遅れるというドミノ倒しが発生します。
—
4. 重大なネットワーク脆弱性の回避策：リソース枯渇攻撃の防衛
コネクションレベルのフロー制御は、パフォーマンスを最適化するための機能であると同時に、悪意ある攻撃者からの防衛ラインでもあります。
HTTP/2 Rapid Reset Attack (CVE-2023-44487) とフロー制御
2023年後半に世界中のインフラエンジニアを震撼させた「HTTP/2 Rapid Reset Attack」は、HTTP/2のマルチプレクシングとストリームキャンセル機能を悪用したDDoS攻撃の手法でした。
攻撃者は、1つのTCPコネクション上で数千ものストリームを同時にオープンし、直後に `RST_STREAM`（ストリーム強制終了）フレームを送り続けます。サーバー側はリクエストを受け付け、応答を準備しようとしてはキャンセルされるという無駄なCPU/メモリリソースを消費させられ、最終的にサービスがダウンします。
この脆弱性の根本的な対策として、各HTTP/2実装（Nginx, Apache, Envoy, Node.js等）では、「同時に処理できるアクティブなストリーム数の厳格な制限（`SETTINGS_MAX_CONCURRENT_STREAMS`）」や、「1秒間に処理するキャンセル数のレートリミット」が導入されました。
しかし、ここでフロー制御の文脈に戻ると、攻撃者は `RST_STREAM` の代わりに、「極端に小さなウィンドウサイズを宣言し、データを全く読み出さない（あるいは `WINDOW_UPDATE` を送らない）ことで、サーバー側のバッファを意図的に枯渇させる」というクラシックな Slowloris 攻撃のHTTP/2版（Slow Read Attack）を仕掛けることも可能です。
堅牢なサーバー設定の例（Nginxのパラメータ調整例）
実運用において、コネクションおよびストリームの制御を適切に行うための設定例を示します。
http {
# 1つのTCPコネクションで許可する最大同時ストリーム数を制限し、
# リソースの枯渇とRapid Reset系攻撃のインパクトを抑制する
http2_max_concurrent_streams 128;
# ヘッダーの最大サイズとバッファを適切に設定し、メモリ爆発を防ぐ
http2_max_field_size 16k;
http2_max_header_size 32k;
# コネクションごとのリード/ライトのタイムアウトを厳しめに設定し、
# ウィンドウを意図的に止められたまま放置されるのを防ぐ
client_body_timeout 10s;
client_header_timeout 10s;
send_timeout 10s;
server {
listen 443 ssl http2;
# SSL証明書等の設定…
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;
location / {
root /var/www/html;
index index.html;
}
}
}
※注: 近年のNginx（バージョン1.25.1以降など）では、HTTP/2の有効化構文が `listen 443 ssl;` に加え、`http2 on;` ディレクティブを使用するモダンな設計へ移行しつつあります。環境に合わせて適切な記述を確認してください。
—
5. 結びにかえて：パケットの呼吸を感じるエンジニアリングへ
HTTP/2のコネクションレベルのフロー制御制限は、一見すると「プロトコルの仕様書の一項」に過ぎません。しかし、その裏側では、TCPの輻輳制御、TLSの暗号化パケットのフラグメンテーション、カーネルのソケットバッファ、そしてアプリケーション層のメモリ管理が、幾重にも複雑に絡み合っています。
「なぜか特定の大容量ファイル転送時に全体のレスポンスが鈍る」「高負荷時に一部のストリームが無応答になる」。
そんなトラブルに直面したとき、単にアプリケーションのログを眺めるだけでは解決の糸口は見えてきません。`tcpdump` や `Wireshark` を手にとり、`WINDOW_UPDATE` フレームがどのタイミングで誰から誰へ送られているのか、コネクション全体のウィンドウがゼロになっていないかをパケットのレベルで読み解く。
それこそが、現代のインフラアーキテクトやテックリードに求められる、真のプロトコルリテラシーなのです。パケットの呼吸を感じ取りながら、今日も最高のパフォーマンスとセキュリティの境界線をデザインしていきましょう。
コメント