HTTP/2マルチプレクシング：単一TCP接続が解き放つ「真の並列」の深淵
ネットワークエンジニアとして現場を歩いていると、いまだに「HTTP/2は速い」という漠然とした理解だけでシステムを設計しているケースに遭遇する。だが、HTTP/2の本質は単なる「速さ」ではない。TCPという、もはやインターネットの老朽化したインフラの上で、いかにして「ストリームの概念」を擬似的に構築し、Head-of-Line Blocking（HoL Blocking）という呪縛から解き放たれるか。そのアーキテクチャの美学を解き明かそう。
1. TCPという「一本道」を切り裂くストリームの魔法
HTTP/1.1の最大の欠点は、TCP接続という単一のパイプラインに、リクエストとレスポンスを「直列」に流し込む点にあった。一つのリクエストが重ければ、後続のすべてが待機させられる。これが物理的なHoL Blockingだ。
HTTP/2のマルチプレクシングは、この単一のTCPストリームの中に、論理的な「Stream（ストリーム）」という概念を導入した。バイナリフレームを細切れにし、Stream IDを付与することで、サーバとクライアントは「リクエスト順序を無視して」データを交互に送り出せるようになった。
パケットレベルの挙動：バイナリフレーミング層
HTTP/2では、すべてが `HEADERS` フレームと `DATA` フレームというバイナリ形式に変換される。ここで重要なのは、TCPセグメントが届いた際、カーネルレベルでパケットが到着しても、アプリケーション層は「どのIDのストリームに対するデータか」を即座に再構成できる点だ。
// カーネル空間でのハンドリングをイメージする擬似的なロジック
// HTTP/2のフレームヘッダーからStream IDを抽出し、適切なバッファへ振り分ける
void process_h2_frame(frame_header_t h) {
// 0は接続制御用。1以上の奇数はクライアント発のストリーム
if (h->stream_id > 0) {
// ストリームごとのバッファへデータをディスパッチ
enqueue_to_stream_buffer(h->stream_id, h->payload);
} else {
// SETTINGSやWINDOW_UPDATEなど接続制御フレームを処理
handle_connection_control(h);
}
}
2. HPACK：ヘッダー圧縮という知的なトレードオフ
マルチプレクシングが効率化されるほど、ヘッダー情報のオーバーヘッドが目立つようになる。毎回 `User-Agent` や `Cookie` をフルテキストで送るのは、帯域の無駄遣い以外の何物でもない。
HTTP/2の HPACK は、静的テーブル（固定値）と動的テーブル（通信中に学習した値）を組み合わせ、ハフマン符号化を駆使してヘッダーを極限まで圧縮する。インフラ屋として注目すべきは、動的テーブルのサイズ管理だ。
- 設定のヒント (Nginx):
# HPACKの動的テーブルサイズを適切に設定する
# デフォルトの4096バイトは、高トラフィックなAPIではメモリと圧縮率のトレードオフになる
http2_max_field_size 16k;
http2_header_buffer_size 16k;
3. TCPバッファチューニングの限界とTLSの罠
HTTP/2のマルチプレクシングは、「一つのTCP接続にリソースを集中させる」ため、TCPの輻輳制御（Congestion Control）がボトルネックになりやすい。もし一つのパケットが欠落すれば、その接続上の「すべてのストリーム」が停止する。これこそが、HTTP/2におけるトランスポート層のHoL Blockingだ。
このリスクを軽減するために、現代のインフラでは以下のチューニングが必須となる。
カーネルパラメーターの最適化
TCPの初期ウィンドウサイズ（initcwnd）を大きくし、スロースタートを加速させる。
sysctlでのTCPバッファ最適化例
接続初期のデータ転送量を増やし、RTTの浪費を防ぐ
net.ipv4.tcp_init_cwnd = 10
BBR混雑制御アルゴリズムの採用（Linux 4.9以降推奨）
従来のCubicよりも高いスループットと低い遅延を実現する
net.ipv4.tcp_congestion_control = bbr
TLSハンドシェイクの最適化
HTTP/2は実質的にTLS 1.2以上が必須だ。TLS 1.3を選択すれば、1-RTTハンドシェイクにより接続開始時のオーバーヘッドを大幅に削減できる。さらに、0-RTT（Early Data）を有効にすれば、前回のセッション情報を再利用して、最初のパケットからHTTPリクエストを送出可能になる。ただし、リプレイ攻撃のリスクには細心の注意を払う必要がある。
4. セキュリティと設計への警鐘
マルチプレクシングの副作用として、「一つの接続が攻撃者のリクエストで埋め尽くされる」リスクがある。`SETTINGS_MAX_CONCURRENT_STREAMS` を適切に設定し、接続あたりのストリーム数を制限することは、DoS攻撃に対する最低限の防衛線だ。
また、HTTP/2はバイナリプロトコルであるため、WAF（Web Application Firewall）による検査負荷がHTTP/1.1よりも高くなる。アーキテクトとしては、復号とフレーム解析の負荷を考慮したスケーリング戦略が求められる。
結びに代えて：プロトコルの進化を追う覚悟
HTTP/2のマルチプレクシングを理解することは、TCPの制約をどうやってバイパスし、いかにしてレイテンシを削り取るかという「パケットとの対話」である。
だが忘れてはならない。HTTP/3（QUIC）が登場した今、私たちはついにTCPそのものを見限り、UDPベースで信頼性を再構築する時代に突入している。しかし、HTTP/2で培った「ストリーム管理」「ヘッダー圧縮」「フロー制御」の概念は、QUICの基礎設計に色濃く引き継がれている。
プロトコルは変わる。だが、その背後にある「いかに効率よく、安全にデータを届けるか」というエンジニアリングの哲学は、これからも変わることはない。次回の記事では、このマルチプレクシングがQUICでどのように再定義されたのか、その進化の系譜を深掘りしていこう。
コメント