【テクニカル・上級編】HTTP/2フレームの構造とヘッダーフィールド – HTTPプロトコル・通信規格実践ガイド

HTTP/2を解剖する：9バイトのフレームヘッダーが支配する「並列の美学」

HTTP/1.1の「テキストベースの逐次処理」という呪縛から世界を解放したHTTP/2。しかし、多くのエンジニアにとって、このプロトコルは依然として「ブラックボックス」に近い。ブラウザのデベロッパーツールで見る「Waterfall」の裏側では、何が起きているのか。

今日は、HTTP/2の心臓部である「9バイトのフレームヘッダー」を起点に、パケットレベルの挙動と、それが引き起こすインフラの最適化、そして現代のネットワークアーキテクトが直面するセキュリティの急所までを深掘りしていく。

—

1. 9バイトの支配者：フレームヘッダーの構造と意図

HTTP/2において、全てのデータは「フレーム」という最小単位でやり取りされる。このフレームの先頭にある9バイトのヘッダーこそが、通信の規律を定めている。

このわずか9バイトが、なぜ革命的なのか。それは、「ストリームの多重化（Multiplexing）」という概念を、TCPレベルで完結させるためだ。

例えば、`HEADERS`フレームが流れてきた瞬間、ストリームIDを見て「これは画像リクエストなのか、CSSなのか」を即座に判断できる。HTTP/1.1のように「前のレスポンスが終わるのを待つ」というホリデイ・オブ・ヘッドライン（Head-of-Line Blocking）は、このID管理によって物理的に排除された。

—

2. パフォーマンスの限界を突破する：HPACKとRTT削減

HTTP/2の真髄は、単なる並列化ではない。HPACKによる「ヘッダー圧縮」だ。

HPACKの魔術とアーキテクトの視点

HTTP/1.1では、数KBのクッキーを毎回送信していた。HTTP/2は「静的テーブル（Static Table）」と「動的テーブル（Dynamic Table）」を駆使し、重複するヘッダーをインデックス番号（整数）に変換する。

ここでセキュリティ上の注意点がある。
HPACKの動的テーブルサイズを適切に制限しないと、攻撃者が細工したヘッダーを送ることで、サーバーのメモリを枯渇させる「HPACK Bomb」攻撃を許すことになる。

Nginx設定例：HPACKの動的テーブルサイズ制限
メモリ枯渇攻撃を防ぐため、デフォルト値を適切に設定する
http2_max_header_size 16k;
ストリームごとのヘッダーサイズ制限を厳格化

—

3. TCPバッファとTLSの「見えない摩擦」

HTTP/2を語る上で避けて通れないのが、トランスポート層の挙動だ。HTTP/2は単一のTCPコネクションを使い回すため、「TCPのバッファ管理」がアプリケーションのレスポンスに直結する。

カーネルパラメーターの最適化

もし君が大規模なトラフィックを扱うインフラを担当しているなら、以下のチューニングは必須だ。

カーネルパラメータの最適化（sysctl.conf）
TCPウィンドウサイズを拡大し、高遅延環境でのスループットを最大化
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

初期輻輳ウィンドウ（initcwnd）を10に設定し、最初のラウンドトリップで
より多くのデータを送り込む（RTT削減の肝）
ip route change default via dev eth0 initcwnd 10

TLS 1.3との組み合わせも忘れてはならない。0-RTT（Zero Round Trip Time）機能を使えば、ハンドシェイクのオーバーヘッドを劇的に減らせる。しかし、0-RTTにはリプレイ攻撃のリスクが伴うため、サーバー側で「べき等性（Idempotency）」が担保されていないリクエスト（POST等）をどう処理するか、設計レベルでの判断が求められる。

—

4. 現場のトラブルシューティング：パケットをどう読むか

最後に、パケットが詰まった時の「眼」を養おう。`tcpdump` や `wireshark` でHTTP/2を覗く際、重要なのは「フラグの確認」だ。

`END_STREAM` フラグ: 正常にストリームが閉じているか？
`SETTINGS` フレーム: サーバーとクライアントでウィンドウサイズが不一致を起こしていないか？
`WINDOW_UPDATE` フレーム: 誰がフロー制御を止めているのか？

もし、特定のストリームだけが極端に遅い場合、それはTCPのパケットロスではなく、アプリケーション側の「フロー制御（Flow Control）」がボトルネックになっている可能性が高い。HTTP/2はTCPの上でさらに独自のフロー制御レイヤーを持っているからだ。

教訓

HTTP/2は魔法ではない。9バイトのヘッダーという「規律」を守ることで、TCPという古き良きプロトコルを極限まで使い倒すための「現代的なプロトコル」である。

君たちがコードを書き、サーバーを構築する際、この9バイトの向こう側にある「パケットの流れ」を想像してほしい。その時、君のネットワークは、単なる通信手段から、ビジネスを加速させる「精密なエンジニアリング」へと進化するはずだ。

次は、HTTP/3（QUIC）がこの9バイトをどう塗り替えようとしているのか……その話は、また別の機会にしよう。