HTTP/2ストリーム：TCPの「鎖」を解き放つ論理的進化の深淵
HTTP/1.1の時代、私たちは「HOL（Head-of-Line）ブロッキング」という悪霊に長年苦しめられてきた。1つのTCP接続で1つのリクエストを捌き、それが終わるまで後続が待機する。ブラウザはこれを回避するために6本ものTCP接続を並列で張り、カーネルのソケットバッファを浪費していた。
HTTP/2は、この非効率を「ストリーム」という論理層の導入で完全に解体した。単一のTCP接続を多重化（マルチプレクシング）し、あたかも複数の仮想的な「パイプ」が通っているかのように振る舞う。だが、この洗練された抽象化の裏側で、パケットレベルでは何が起きているのか。インフラを司るエンジニアとして、そのライフサイクルと最適化の勘所を紐解いていこう。
ストリームのライフサイクル：状態遷移という「戦場」
HTTP/2のストリームは、単なるデータの流れではない。RFC 7540で定義された厳格な状態遷移（State Machine）を持つエンティティだ。
- Idle: まだ生まれていない状態。
- Open: `HEADERS`フレームが送受信され、双方向通信が可能な状態。
- Half-closed (Remote/Local): 片側が`END_STREAM`フラグを立てて終了を宣言した状態。
- Closed: 完全に終了。RST_STREAMを受け取った際もここに遷移する。
特筆すべきは、`RST_STREAM`の扱いだ。TCPは「切断」にはコストがかかるが、HTTP/2はストリーム単位で即座にキャンセルできる。クライアントが途中でスクロールを止めて画像を要求しなくなった際、`RST_STREAM`を投げればカーネルバッファ上の不要なペーロードを即座に破棄できる。これは、モバイル環境のような帯域が不安定な領域では、QoSを維持するための極めて重要な武器となる。
HPACK：ヘッダー圧縮の「静」と「動」
HTTP/2のパフォーマンスを支える最大の功労者がHPACKだ。冗長なHTTPヘッダーを、静的テーブル（共通のヘッダー名）と動的テーブル（通信中に学習した値）でインデックス化する。
ここで注意すべきは、「動的テーブルのサイズ管理」だ。
多くの実装ではデフォルトの動的テーブルサイズは4KBに設定されているが、高トラフィックなAPIサーバーでは、この値を調整することでパケットサイズを削減できる。
NginxでHPACKの動的テーブルサイズを最適化する例
サーバーメモリとメモリ消費のトレードオフを考慮し、大規模ヘッダーに対応させる
http {
# 応答ヘッダーの動的テーブルサイズを調整 (デフォルトは4096)
http2_max_header_size 16k;
# HPACKのインデックスキャッシュのメモリ割り当て
http2_chunk_size 8k;
}
注意：動的テーブルを大きくしすぎると、クライアント・サーバー間のメモリ消費が肥大化し、DoS攻撃（HPACK Bomb）の標的となるリスクがある。セキュリティとの境界線をどこに引くか、これがアーキテクトの腕の見せ所だ。
ネットワーク層のチューニング：TCPとTLSの狭間で
HTTP/2を語る上で、トランスポート層のチューニングを無視することはできない。HTTP/2は1つのTCP接続に依存するため、パケットロスが発生すると、その接続上の「全ストリーム」が停止する。
これを防ぐための、現場の鉄板設定を紹介する。
1. TCP初期輻輳ウィンドウ（initcwnd）の拡大
デフォルトの10セグメントは現代のWeb環境では小さすぎる。遅延（RTT）が大きい環境では、これを増やすことで最初のRTTでより多くのデータを押し込むことが可能だ。
Linuxカーネルパラメータ: initcwndを10から20〜30へ
ip route change default via 192.168.1.1 dev eth0 initcwnd 20
2. BBR輻輳制御アルゴリズムの採用
Googleが開発したBBRは、パケットロスを「混雑」とみなす従来のCubicとは異なり、帯域幅とRTTを測定してボトルネックを予測する。HTTP/2のマルチプレクシング環境下では、Cubicよりも圧倒的にスループットが安定する。
sysctlでBBRを有効化
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr
セキュリティの深淵：ストリーム制御の脆弱性
HTTP/2の柔軟性は攻撃者にとっての隙でもある。「ストリーム多重化」を悪用した`Rapid Reset`（CVE-2023-44487）が記憶に新しいだろう。大量のストリームをオープンし、即座にキャンセルする行為を繰り返すことで、サーバーのリソース（CPU）を枯渇させる攻撃だ。
対策は、「ストリームの同時実行数（SETTINGS_MAX_CONCURRENT_STREAMS）」の適切な制限に尽きる。
サーバーの負荷を守るためのストリーム制限設定
http {
# 接続あたりの最大同時ストリーム数を厳格に制御
# APIの特性に合わせて100〜250程度が現実的な妥協点
http2_max_concurrent_streams 128;
}
結びに：プロトコルの美学
HTTP/2のストリームは、単なる通信規格ではない。それは、物理的な制約（TCPの順序保証やハンドシェイクの遅延）に対して、ソフトウェアがいかに「論理的な抽象化」で対抗するかという、人類の知恵の結晶だ。
インフラアーキテクトとして意識すべきは、設定ファイルの値をなぞることではない。カーネルがどうメモリを割り当て、パケットがどのバッファで待機し、HPACKがどのタイミングでインデックスを生成しているのか。その「呼吸」を想像することだ。
HTTP/3（QUIC）へと時代は移ろいつつあるが、HTTP/2で培ったストリーム制御とフロー制御の勘所は、未来のプロトコルを理解するための最強の武器になるはずだ。さあ、次はあなたのサーバーのログを開き、TCPダンプを眺めてみてほしい。そこには、まだ見ぬ最適化のヒントが隠れているはずだ。
コメント