【実務・中級編】HEADERSフレームとエンドストリームフラグ(END_STREAM)の役割 – HTTPプロトコル・通信規格実践ガイド

こんにちは。現場を渡り歩くネットワークエンジニアの皆さん、日々のトラフィック分析やAPIのチューニング、お疲れ様です。

ブラウザの裏側やマイクロサービスの通信基盤で当たり前のように使われているHTTP/2ですが、その本質である「ストリーム」や「フレーム」の挙動を、パケットキャプチャの波形レベルまで意識したことはあるでしょうか。

今日は、HTTP/2の心臓部とも言える `HEADERS`フレーム と、その終端を告げる `END_STREAM`フラグ について、RFC 7540の仕様の裏側にある「現場のリアル」を交えながら徹底的に紐解いていきたいと思います。API設計で不可解なハングアップに悩まされている方や、プロキシのログ解析で頭を抱えているエンジニアの皆さんの処方箋になれば幸いです。

—

1. なぜ「HEADERSフレーム」と「END_STREAM」を知る必要があるのか

HTTP/1.1の時代、私たちは1つのTCPコネクションにつき1つのリクエストしか流せないという「Head-of-Line Blocking（ヘッドオブラインブロッキング）」の呪縛に苦しめられていました。これを打破するために登場したHTTP/2は、単一のTCPコネクション上で仮想的な双方向ストリームを多重化（マルチプレクシング）します。

このストリーム上で、リクエストやレスポンスのメタデータ（ヘッダー）を運ぶのが `HEADERS`フレーム です。

しかし、考えてみてください。単一のTCPセッションのなかで、無数のリクエストとレスポンスの断片（フレーム）が入り乱れて流れてくる時、受信側のアプリケーションやプロキシは、「一体どのフレームまでがひとまとまりのリクエスト（あるいはレスポンス）なのか」をどうやって判断しているのでしょうか？

その境界線を引く決定打こそが、`HEADERS`フレーム（あるいはそれに続く`DATA`フレーム）に付与される `END_STREAM`フラグ です。ここを誤解していると、APIクライアントが無限にレスポンスを待ち続けたり、リバースプロキシが不正なリクエストとしてコネクションを強制切断（RST_STREAM）したりするトラブルに見舞われます。

—

2. HEADERSフレームの構造とEND_STREAMの仕様

HTTP/2のすべてのフレームは、9オクテット（バイト）の共通ヘッダーから始まります。

+—————————————————————+
| Length (24) |
+—————+——————————-+
| Type (8) | Flags (8) |
+-+————-+——————————-+
|R| Stream Identifier (31) |
+-+———————————————–+
| Frame Payload (0…) …
+—————————————————————+

このフレーム群の中でも、`Type` が `0x1`（HEADERS）であるものが、HTTP/2のトランザクションの口火を切ります。

フラグ（Flags）と `END_STREAM` の正体

`Flags`フィールド（1バイト）のビットマスクにおいて、`END_STREAM` は非常に重要な意味を持ちます。

• `END_STREAM` (0x1):

このフラグが `1` にセットされている場合、「このストリームにおいて、この送信者から送信するデータはこれで終わり（もうこれ以上フレームを送らない）」ことを示します。

リクエストボディを持たない単純なGETリクエストの場合、クライアントが送信する最初の `HEADERS` フレームにいきなりこの `END_STREAM` が立ちます。「ヘッダーを送った、そして私の話はこれで終わりだ」という意味ですね。

逆に、POSTリクエストのようにボディ（JSONデータなど）を伴う場合はどうなるでしょうか？
1. クライアントは `HEADERS` フレームを送る（この時点では `END_STREAM` は 立たない）。
2. 続いて `DATA` フレームでボディを送信する。
3. 最後の `DATA` フレームに `END_STREAM` フラグを立てて、リクエストの完結を告げる。

このように、「どこでリクエスト/レスポンスが完結するか」を正確に制御するためのスイッチが `END_STREAM` なのです。

—

3. 通信シーケンス：パケットレベルの挙動を追う

言葉だけではイメージしにくいので、典型的な「GETリクエスト」と「POSTリクエスト」の通信シーケンスを見てみましょう。

パターンA：ボディなし（GETリクエスト）

クライアントからサーバーへ、ヘッダー送信と同時にストリームを閉じる最もシンプルなパターンです。

[Client] [Server]
| |
|— HEADERS (Stream ID: 1, END_STREAM=1) ———>|
| (:method = GET, :path = /api/v1/status) | (リクエスト受信完了＆終了)
| |
|<-- HEADERS (Stream ID: 1, END_STREAM=0) ----------| | (:status = 200, content-type = application/json) |<-- DATA (Stream ID: 1, END_STREAM=1) -------------| | ({"status": "ok"}) | (レスポンス完了) | | サーバー側のレスポンスに注目してください。サーバーはまず `HEADERS` フレームでステータスコードを返し（この時点では `END_STREAM=0`）、実際のJSONボディを `DATA` フレームで送り、その最後の `DATA` フレームで `END_STREAM=1` を立ててストリームを閉じます。

パターンB：ボディあり（POSTリクエスト）

リクエストボディを伴う場合、`HEADERS` フレーム単体でストリームは終わりません。

[Client] [Server]
| |
|— HEADERS (Stream ID: 3, END_STREAM=0) ———>|
| (:method = POST, :path = /api/v1/users) | (ヘッダー受信、まだ待つ)
| |
|— DATA (Stream ID: 3, END_STREAM=1) ————->|
| ({“name”: “Taro”, “role”: “engineer”}) | (ボディ受信＆リクエスト完了)
| |
|<-- HEADERS (Stream ID: 3, END_STREAM=0) ----------| | (:status = 201 Created) | |<-- DATA (Stream ID: 3, END_STREAM=1) -------------| | ({"id": 1042, "status": "created"}) | | | ここで重要なポイントがあります。もしクライアントがPOSTリクエストを送信する際、誤って最初の `HEADERS` フレームに `END_STREAM=1` を立ててしまったらどうなるでしょうか？ サーバーは「ボディがないリクエストだな」と解釈して処理を進めようとしますが、直後に `DATA` フレームが飛んでくると、HTTP/2のプロトコル違反（`STREAM_CLOSED` エラーなど）としてコネクションごと切断されてしまいます。 ---

4. 実務で役立つ！コードとデバッグの実践例

ここからは、実際の開発やインフラの現場で、この仕組みをどのように確認・実装するかをコードベースで解説します。

4-1. curlを用いたパケット（フレーム）の可視化

HTTP/2のフレーム構造をデバッグする際、最も手っ取り早いのは `curl` の詳細ログ（`-v` や `–http2`）や、Wiresharkでのキャプチャです。

以下のコマンドを実行すると、HTTP/2での通信の様子を確認できます。

HTTP/2を強制しつつ、詳細な通信ログを出力する
curl -v –http2 https://httpbin.org/get

出力されるログの中に、次のようなHTTP/2特有のやり取りが見て取れます。

• Using HTTP/2, Stream 1 (for GET)
• Copying HTTP/2 data in stream buffer to connection buffer!
• [:method: GET]
• [:path: /get]
• [:scheme: https]
• [:authority: httpbin.org]
• Using Stream ID: 1 (easy handle 0x7fa… )

> GET /get HTTP/2
> Host: httpbin.org
> User-Agent: curl/7.68.0
> Accept: /
>
< HTTP/2 200 < date: Wed, 25 Oct 202X 00:00:00 GMT < content-type: application/json < この時、裏では `HEADERS` フレームに `END_STREAM=1` が付与されてサーバーに送られています。

4-2. Node.js (Fetch API) でのリクエストとストリームの意識

モダンなJavaScript環境（Node.js 18+ や ブラウザ）の `fetch` は、デフォルトでHTTP/2をサポートしています。

// 実務を想定した堅牢なAPIクライアントの例
async function postUserData() {
try {
const response = await fetch(‘https://api.example.com/v1/users’, {
method: ‘POST’,
headers: {
‘Content-Type’: ‘application/json’,
// HPACKによって、これらのカスタムヘッダーも効率的に圧縮されます
‘X-Request-Source’: ‘Backend-Worker’
},
body: JSON.stringify({ name: ‘Hanako’, role: ‘architect’ })
});

// サーバーからの HEADERS (END_STREAM=0) と DATA (END_STREAM=1) の処理を隠蔽してくれる
if (!response.ok) {
throw new Error(`HTTP error! status: ${response.status}`);
}

const data = await response.json();
console.log(‘Success:’, data);

} catch (error) {
console.error(‘通信またはプロトコルエラー:’, error);
}
}

postUserData();

JavaScriptの `fetch` を使っている限り、開発者が直接 `END_STREAM` のビットを操作することはありません。しかし、プロキシサーバー（EnvoyやNginxなど）の設定や、下流のgRPC/HTTP2マイクロサービス間通信をデバッグする際には、この「裏側で何が行われているか」を知っているかどうかが、障害切り分けのスピードを大きく左右します。

—

5. シニアエンジニアからの実務Tips & トラブルシューティング

最後に、現場で私たちがしばしば遭遇する「HEADERSとEND_STREAMにまつわるトラブル」と、その処方箋を共有します。

トラブル1：APIクライアントからのPOSTリクエストが途中でハングする

• 症状: サーバー側のログにリクエストの到達痕跡はあるが、レスポンスが返ってこず、最終的にタイムアウトする。
• 原因の推測: クライアント側（またはカスタム実装されたHTTP/2クライアントライブラリ）のバグにより、POSTリクエストの `DATA` フレームの最後に `END_STREAM` フラグが正しく付与されなかったケース。サーバー側は「まだボディの続きがあるはずだ」と待ち続けてしまいます。
• 対策: Wiresharkや `nghttp2` などのツール（`nghttp`コマンドなど）を使い、該当ストリームの最終フレームに `END_STREAM` が本当に立っているかを確認します。

トラブル2：リバースプロキシ（Nginx / Envoy）でのヘッダーサイズ肥大化エラー

• 症状: 特定の巨大なCookieやAuthorizationトークンを含むリクエストを送ると、突然 `RST_STREAM (PROTOCOL_ERROR)` が返される。
• 原因の推測: HTTP/2の `HEADERS` フレームはHPACKによって圧縮されますが、圧縮前の生ヘッダーサイズやデコード後のサイズが、プロキシ側の制限（例: Nginxの `large_client_header_buffers` や Envoyの `max_request_headers_kb`）を超過している場合、プロキシが強制的にストリームを遮断します。
• 対策: アプリケーション側で不要な巨大ヘッダーを送信しないよう設計を見直すか、インフラ側の許容値を適切にチューニングします。

—

まとめ

HTTP/2の `HEADERS` フレームと `END_STREAM` フラグは、一見すると開発者が普段の業務で意識する必要のない、低レイヤーの決まりごとに見えます。

しかし、ひとたびマイクロサービス間の通信不良や、ロードバランサーを介したリクエストのドロップといった深部の一大障害に直面したとき、「パケットのなかでストリームの終了がどのように宣言されているか」をイメージできる能力は、あなたを救う最大の武器になります。

プロトコルの基本原理に立ち返り、パケットの呼吸を感じながら、堅牢で美しいネットワークアーキテクチャを築き上げていきましょう。