こんにちは。ネットワークインフラの現場を渡り歩いてきた私だが、最近若手エンジニアからよくこんな質問を受ける。
「HTTP/2って、1つのTCPコネクションで同時にリクエストを流せる（マルチプレクシング）から速いんですよね？ でも、サーバとクライアントって、最初にどうやってその『ルール』を決めてるんですか？」
非常に良い着眼点だ。TCPの3Wayハンドシェイクが終わったあと、HTTP/2の世界では何が行われているのか。TLSのALPN（Application-Layer Protocol Negotiation）で「よし、ここからはHTTP/2で行こうぜ」と握手をした直後、実は裏側で「SETTINGSフレーム」という極めて重要な外交官がパケットに乗って往復している。
今日は、このSETTINGSフレームの構造、ACKフラグによる確実な同期、そして実務でトラブルシューティングを行う際に知っておくべき「現場のリアル」を、シニアエンジニアの視点から徹底的に紐解いていこう。
—
1. SETTINGSフレームとは何か？ RFC 7540が定めた「事前交渉」の正体
HTTP/2（RFC 7540）は、HTTP/1.xのテキストベースのやり取りを完全に覆し、すべてをバイナリの「フレーム」に変換して流すプロトコルだ。その中で、コネクション全体に関わる動作パラメータ（ウィンドウサイズや同時ストリーム数の上限など）を定義し、お互いに適用するのがSETTINGSフレームである。
ここで重要なのは、「SETTINGSフレームは、クライアントとサーバの双方が、相手に対して自分の希望するパラメータを一方的に送り、相手がそれを適用する」という非対称な仕組みになっている点だ。
フレームの基本構造
HTTP/2のフレームは共通して「9オクテット（バイト）のヘッダ」を持つ。SETTINGSフレームの場合、その内訳はこうだ。
- Length (24bit): ペイロードの長さ。1つのパラメータは6バイト（ID 2バイト + 値 4バイト）なので、パラメータの個数×6がここに入る。
- Type (8bit): `0x04` （これがSETTINGSフレームを示すコード）
- Flags (8bit): 設定の確認応答を示す `ACK` フラグ（`0x01`）などがここに立つ。
- Reserved (1bit) + Stream Identifier (31bit):
- 超重要： SETTINGSフレームは常にコネクションの根幹を担うため、ストリームIDは必ず `0x00000000`（ストリーム0）でなければならない。もしストリームIDが0以外でSETTINGSフレームが飛んできた場合、実装側は「コネクションエラー（PROTOCOL_ERROR）」として容赦なく即座に切断する。
—
2. ネゴシエーションのシーケンス：ACKが紡ぐ信頼関係
HTTP/2の接続が確立された瞬間、通信の裏側では以下のようなドラマチックなパケットの往復が繰り広げられている。
Client Server
| |
|— [TCP Handshake & TLS Negotiation (ALPN: h2)] ——>|
| |
|— [Client Connection Preface (マジック文字列)] ——->|
|— [SETTINGS (Clientの初期設定)] ———————>|
| |<-- (クライアントの設定を適用)
| |
| |--- [SETTINGS (Serverの初期設定)] ----->|
| |— [SETTINGS (ACK)] ——————->| (Serverの設定に対する返答を待たずに即座にストリーム発行可能)
|<-- (サーバーの設定を適用) -------------------------------|
| |
|--- [SETTINGS (ACK)] ---------------------------------->| (Clientの設定に対してServerがACKを受信)
| |
|=== ここからマルチプレクシングによるリクエスト爆撃開始 ===|
ここでプロトコル設計の妙がある。クライアントは、自分のSETTINGSを送ったあと、サーバからのSETTINGS(ACK)を待たずにリクエストを送り始めてもよい仕様になっている（※サーバ側の初期設定パラメータが届くまでは、RFCで定められたデフォルト値が一時的に適用される）。
しかし、サーバ側の設定（例えば「我がサーバが許容する最大同時ストリーム数はここまでだ」といった制限）を確実に同期させるために、受信側は必ず以下のルールを守る必要がある。
1. SETTINGSフレームを受信する
2. その内容を自分の内部状態に適用する
3. 速やかに `ACK` フラグ（`0x01`）を立てたSETTINGSフレームを折り返し送信する
もしクライアントがこのACKを見落とすような実装であれば、ネットワークの海に沈むことになる。
—
3. 実務で知るべき主要パラメーターの顔ぶれ
SETTINGSフレームのペイロードには、いくつかのお馴染みのパラメータID（Identifier）が存在する。インフラ運用やAPI設計で必ず押さえておくべき主要な4つを紹介しよう。
| パラメータ名 (ID) | 16進数ID | デフォルト値 | 現場での実務的意味・チューニング指針 |
| :— | :— | :— | :— |
| SETTINGS_HEADER_TABLE_SIZE | `0x01` | 4,096 バイト | HPACK（ヘッダー圧縮）で使用する動的テーブルの最大サイズ。メモリをケチる組込み機器なら小さく、巨大なCookieをやり取りするモダンWebアプリなら大きめ（例: 65536）に設定されることがある。 |
| SETTINGS_ENABLE_PUSH | `0x02` | `1` (有効) | サーバプッシュ機能の有効/無効。現代のモダンブラウザや多くのAPIクライアントでは、帯域の無駄遣いやセキュリティ上の懸念から、クライアント側から `0`（無効）を送りつけてサーバプッシュを封じるのがデファクトスタンダードになっている。 |
| SETTINGS_MAX_CONCURRENT_STREAMS | `0x03` | 無制限 (実質無限) | 同時に処理を並行させられるストリーム（リクエスト）の数。Webサーバ側（NginxやEnvoyなど）で `100` や `256` などに制限されていることが多い。これを迎撃すると、クライアントはキューイングを強いられる。 |
| SETTINGS_INITIAL_WINDOW_SIZE | `0x04` | 65,535 バイト | フロー制御の初期ウィンドウサイズ。動画配信や大容量ファイル転送を扱うAPI基盤では、この初期値が小さいと帯域をフルに使い切れないため、大きめの値を設定してスループットを稼ぐチューニングが行われる。 |
—
4. デバッグの現場から：パケットキャプチャでSETTINGSを覗き見る
実務で「なぜかHTTP/2の通信が途中で固まる」「ストリームが突然リセットされる」という現象に遭遇したとき、私は迷わず `tcpdump` と `Wireshark` を立ち上げる。
実際に、Pythonの `h2` ライブラリや `curl` を使って通信を行った際の、Wiresharkでのキャプチャの見方をイメージしてほしい。
Wiresharkのフィルターに `http2.type == 4` と入力すると、SETTINGSフレームだけが綺麗に抽出される。
Frame 5: 74 bytes on wire
Transmission Control Protocol (TCP), Src Port: 443, Dst Port: 54321
HyperText Transfer Protocol Version 2
Length: 12
Type: Settings (4)
Flags: 0x00 (No ACK)
Identifier: SETTINGS_MAX_CONCURRENT_STREAMS (3)
Value: 128
Identifier: SETTINGS_INITIAL_WINDOW_SIZE (4)
Value: 1048576
このログから読み取れるのは、「サーバが最大同時ストリーム数を128に制限し、初期ウィンドウサイズを1MB（1,048,576バイト）に拡張してきているな」というサーバー側の意図だ。
もしあなたがGo言語やNode.jsでカスタムHTTP/2クライアントを実装している場合、サーバが送ってきたこれらのSETTINGSを正しくパースし、ウィンドウサイズやストリーム数の制限を内部のバッファ管理に反映させなければ、デッドロックやメモリリークの原因になる。
—
5. 開発者・インフラエンジニアへの実践的Tips
最後に、現場で役立つ実践的なTipsをいくつか置いておこう。
1. APIクライアントライブラリの設定に注意する
Pythonの `httpx` や Goの `net/http`、あるいは Node.js の `http2` モジュールを使う際、デフォルトのSETTINGSパラメータはライブラリ側で安全な値に抽象化されている。しかし、極限までレイテンシを詰めたい超高速マイクロサービス間通信などでは、カスタムで `SETTINGS_INITIAL_WINDOW_SIZE` をいじる必要が出てくる。その際は、サーバ側（EnvoyやNginx）の `http2_max_field_size` や `http2_window_size` の設定と整合性が取れているかを必ず確認すること。
2. 「SETTINGSのACKが返ってこない」＝ 致命的なサイレント障害
TCPコネクションは繋がったのに、HTTP/2のリクエストを送った途端にタイムアウトする場合、中間プロキシ（WAFやロードバランサー）がHTTP/2のプレースホルダーや初期SETTINGSフレームを正しく解釈できず、ドロップしているケースがある。`curl –http2 -v` を叩いて、ターミナルに以下のようなやり取りが出ているか確認しよう。
$ curl -v –http2 https://api.example.com/health
- Using HTTP/2, Server supports multi-streaming
- Connection state (HTTP/2 updated)
- We are using a TCP connection.
- Using Stream ID: 1 (easy handle 0x7fae…)
> GET /health HTTP/2
> Host: api.example.com
> …
もし `Connection state (HTTP/2 updated)` の直後に固まるなら、SETTINGSフレームのネゴシエーションで破綻している可能性が極めて高い。
—
まとめ
HTTP/2のSETTINGSフレームは、派手さこそないものの、「安全で高効率なマルチプレクシングの世界へ入るためのパスポート」である。
次にあなたがネットワークのトラブルシュートでパケットを眺める機会があれば、ぜひストリーム0でやり取りされるこのバイナリの会話に注目してほしい。そこには、クライアントとサーバが「お互いの限界と好みをリスペクトし合う」ための、美しく洗練されたプロトコルの意思疎通が確実に存在しているはずだ。
コメント