【テクニカル・上級編】HTTP/2におけるCONTINUATIONフレームの役割 – HTTPプロトコル・通信規格実践ガイド

CONTINUATIONフレームの正体：HTTP/2ヘッダー肥大化がもたらすパケットの深淵と、脆弱性・最適化のリアル

ネットワークの底流を流れるパケットの挙動に思いを馳せる時、私たちはしばしばレイヤーの境界線が織りなす巧妙な美しさに魅了される。TCPの3ウェイハンドシェイクが完了し、TLS 1.3によって暗号化のベールがまとわれたその瞬間、HTTP/2のセッションが幕を開ける。

HTTP/2の最大の功績は、単一のTCPコネクション上で複数のリクエストとレスポンスを多重化（マルチプレクシング）したことにある。HTTP/1.x時代、ブラウザの頭を悩ませた「ドメイン・シャドリング」や「HOL（Head-of-Line）ブロッキング」の呪縛は、ストリームという概念の導入によって見事に粉砕された。

しかし、プロトコルが高度化すればするほど、エッジケースや物理的限界に対する妥協点が生じる。その代表例が、今回焦点を当てる `CONTINUATION`フレーム だ。

教科書的な仕様書を開けば「ヘッダーブロックが単一のフレームに収まらない場合に分割して送信する」と冷徹に記されている。だが、インフラアーキテクトやセキュリティの最前線に立つエンジニアにとって、このフレームは単なる「分割機構」ではない。それは、HPACK圧縮のコンテキスト、TCPのセグメンテーション、TLSレコードのパッキング、そして2024年に業界を震撼させた「HTTP/2 Continuation Flood（CVE-2024-27983等）」という深刻なセキュリティリスクの交差点なのだ。

パケットアナライザの画面を見つめながら、この小さなフレームがネットワーク全体に与える影響の深淵を覗いてみよう。

—

1. なぜCONTINUATIONフレームが必要なのか？（HPACKとフレーム構造の必然）

HTTP/2の通信単位は「フレーム」であり、すべてのフレームは一律で9バイトのヘッダーを持つ。

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

このペイロード部分に、リクエスト/レスポンスのメタデータ、すなわちHTTPヘッダーが格納される。ここで登場するのが、HTTP/2の隠れた主役である HPACK（RFC 7541） だ。

HTTP/1.xでは毎度数キロバイトに及ぶテキストベースのヘッダーを平文（あるいは圧縮なし）で流していたが、HTTP/2では静的テーブルと動的テーブルを用いてヘッダーをハフマン符号化およびインデックス化し、極限まで圧縮する。

ここで一つの矛盾が生じる。
「ヘッダーは圧縮されているはずなのに、なぜ1つのフレームに収まらないことがあるのか？」

現実のWebアプリケーションを見てほしい。OAuth2のJWT（JSON Web Token）、巨大なCookie、複雑なトラッキングパラメータ、サードパーティ製タグの乱立。これらが絡み合う現代のHTTPリクエストでは、HTTPヘッダーの総量が数キロバイト、時として十数キロバイトに達することは珍しくない。

一方、HTTP/2の仕様（RFC 9113）では、デフォルトの最大フレームペイロードサイズ（`SETTINGS_MAX_FRAME_SIZE`）の下限は16,384バイト（16KB）に定められている。動的テーブルの更新や長大な文字列リテラルを含むヘッダーブロックがこのサイズを超過する場合、どうなるか？

ここで、HTTP/2設計陣の苦渋の決断が垣間見える。
「1つの `HEADERS` フレームにすべてを詰め込むことはできない。かといって、途中で別のストリームのフレームを割り込ませる（インターリーブさせる）と、HPACKの動的テーブルの順序が狂い、デコードが完全に破壊される」

この難問を解決するために生まれたのが、`CONTINUATION`フレーム（Type: 0x9） である。

—

2. パケットレベルの挙動：HEADERSからCONTINUATIONへのバトンタッチ

Wiresharkのキャプチャを思い浮かべてほしい。巨大なヘッダーを持つリクエストが送信される時、ネットワーク上では以下のようなパケットの連鎖が発生する。

1. `HEADERS` フレーム（Flags: END_HEADERS が立っていない）

  • ストリームIDを指定し、ヘッダーブロックの前半部分（最大16KB）を送信する。
  • この時点ではまだヘッダーの送信が完了していないため、フラグに `END_HEADERS (0x4)` はセットされない。

2. `CONTINUATION` フレームの連続

  • 直前の `HEADERS` フレームと同じストリームIDを持ち、残りのヘッダーブロックを分割して運ぶ。
  • 最後の `CONTINUATION` フレームには `END_HEADERS (0x4)` フラグがセットされ、ここで初めて受信側（リバースプロキシやアプリケーションサーバー）は「ヘッダーブロックが完結した」と判断し、HPACKデコーダーへ処理を引き渡す。

ここで極めて重要なルールがある。
「`HEADERS` フレームと、それに続く一連の `CONTINUATION` フレームの間には、絶対に他のストリームのフレームを挟み込んではならない（非分割の原則）。」

もし途中に別のストリームのフレームが割り込むと、受信側のHPACKステートマシンが誤った順序でデコードを試み、セッション全体が `COMPRESSION_ERROR`（エラーコード: 0x9）によって即座にRST_STREAM（あるいはGOAWAY）で強制切断される。

—

3. トランスポート層（TCP/TLS）との密な関係：RTT削減とバッファチューニング

インフラアーキテクトとして頭を悩ませるのが、この分割されたフレーム群がTCP層やTLS層でどのようにハンドリングされるかという点だ。

TLSレコードのパッキングとレイテンシー

HTTP/2は通常、TLS 1.3上で動作する。TLS層では、アプリケーションデータは「TLSレコード」という単位に暗号化・カプセル化される。
もし `HEADERS` フレームと `CONTINUATION` フレームが別々のTCPセグメントやTLSレコードに分かれて送信されると、次のようなペルソナ（ボトルネック）が顔を出す。

  • NagleアルゴリズムとDelayed ACKの悪影響: 小さな `CONTINUATION` フレームがNagleアルゴリズムによってバッファリングされ、次のACKを待たされることで、ミリ秒単位の無駄な遅延（RTT）が発生する。
  • TLSレコードのオーバーヘッド: 分割されたフレームごとにTLSのヘッダーや認証タグ（AEAD）のオーバーヘッドが乗るため、スループットが微小に悪化する。

カーネルパラメータのチューニング（Linux）

高トラフィックなHTTP/2ゲートウェイ（Envoy, NGINX, HAProxyなど）を運用する場合、このレイヤーでの最適化は死活問題となる。TCPのソケットバッファとパケットの送出タイミングを制御するため、以下のカーネルパラメータ調整が不可欠となる。

/etc/sysctl.d/99-http2-network.conf

TCPの初期輻輳ウィンドウ（initwnd）を拡大し、ハンドシェイク直後のバースト送信能力を向上
（デフォルトの10から、大規模サービスでは16〜32へ引き上げるケースもある）

Nagleアルゴリズムの無効化（インタラクティブな高速応答が求められるリバースプロキシのエッジで有効）
注: アプリケーション層で適切にバッファリングが行われていることが前提
net.ipv4.tcp_low_latency = 1

TCPソケットの送受信バッファの動的チューニング範囲を拡大
多数のストリームが並行するHTTP/2セッションのメモリフットプリントを支える
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

タイムスタンプを有効化し、RTTの正確な計測とPAWS（Wrapped Sequence Numbersの保護）を維持
net.ipv4.tcp_timestamps = 1

プロキシサーバーの設定（例: NGINXやEnvoy）においても、`SO_SNDBUF` / `SO_RCVBUF` のサイズや、バックエンドへ流す際のバッファプールサイズを、想定される最大ヘッダーサイズ（Cookieの肥大化などを考慮し、一般的には32KB〜64KB程度）に合わせて適切にサイジングすることが求められる。

—

4. セキュリティの暗部：CONTINUATION Floodの脅威と回避策

インフラエンジニア、特にセキュリティ専門家にとって、`CONTINUATION` フレームの名を聞いて背筋が凍るようになったのは、2024年4月に開示された一連の脆弱性（通称 HTTP/2 Continuation Flood）以降のことだ。

脆弱性のメカニズム

攻撃者は、次のような巧妙な手法でサーバーを無力化する。

1. 攻撃者はHTTP/2のコネクションを確立する。
2. `HEADERS` フレームを送信するが、最後の `END_HEADERS` フラグを立てない。
3. その後、際限なく巨大なゴミデータを含んだ `CONTINUATION` フレームを送り続ける。
4. サーバー側の実装に欠陥がある場合、サーバーは `END_HEADERS` が来るまで（あるいはメモリが枯渇するまで）受信したヘッダーブロックをメモリ上に蓄積し続ける。
5. 結果として、サーバーはOOM（Out of Memory）を引き起こすか、CPUがパース処理で完全に飽和し、正当なユーザーのリクエストを一切処理できなくなる（DoS攻撃の完成である）。

さらに恐ろしいことに、この攻撃は `RST_STREAM` でストリームを途中で切断しても、サーバー側のメモリ解放が追いつかない実装が存在したため、多くの主要なHTTP/2実装（Go, Node.js, Envoy, Apache Tomcat, nghttp2など）が緊急パッチのリリースを余儀なくされた。

実装レベルでの防御策とコード例（Go言語のカスタムサーバーでのハンドリング思想）

堅牢なインフラを構築する場合、フレームのサイズ制限や、メモリ消費の閾値を厳格に監視・制限する必要がある。以下は、低レイヤーでHTTP/2のトラフィックを扱う際の、防御的プログラミングの概念を示す擬似コード（Go言語ベース）である。

package main

import (
“errors”
“fmt”
“net”
)

// 悪意あるCONTINUATION Floodを防ぐための制限値定義
const (
MaxHeaderBlockSize = 65536 // ヘッダーブロック全体の最大許容サイズ（64KB）
MaxContinuationFrames = 32 // 連続して許容するCONTINUATIONフレームの最大数
)

type HTTP2StreamContext struct {
StreamID uint32
AccumulatedBytes int
ContinuationCount int
}

// 簡易的なフレーム受信・検証ロジック
func (ctx HTTP2StreamContext) ProcessFrame(frameType byte, flags byte, payload []byte) error {
// CONTINUATIONフレーム (Type 0x9) の場合のバリデーション
if frameType == 0x9 {
ctx.ContinuationCount++

// 連続フレーム数の制限超過チェック（DoS対策）
if ctx.ContinuationCount > MaxContinuationFrames {
return errors.New(“PROTOCOL_ERROR: Too many CONTINUATION frames (Potential Flood Attack)”)
}

ctx.AccumulatedBytes += len(payload)

// ヘッダーブロック全体の累積サイズ超過チェック
if ctx.AccumulatedBytes > MaxHeaderBlockSize {
return errors.New(“ENHANCE_YOUR_CALM: Header block too large, aborting stream”)
}

// END_HEADERS フラグ (0x4) が立っているかの確認
isEndHeaders := (flags & 0x4) != 0
if isEndHeaders {
// デコード処理へ移行
if err := ctx.finalizeHeaderDecode(); err != nil {
return err
}
}
}
return nil
}

func (ctx HTTP2StreamContext) finalizeHeaderDecode() error {
fmt.Printf(“Stream %d: Headers successfully received and validated. Total size: %d bytes\n”,
ctx.StreamID, ctx.AccumulatedBytes)
// HPACKデコード処理へ進む…
return nil
}

func main() {
// インフラストラクチャのエッジプロキシやサーバー実装では、
// このような厳格なバイト数・フレーム数のカウンターをストリームごとに保持し、
// 閾値を超えた瞬間にセッションを即座にRSTする実装が必須となる。
fmt.Println(“HTTP/2 Defensive Stream Parser Initialized.”)
}

現代のプロダクション環境（NGINX 1.25.x以降, Envoy v1.29.x以降など）では、こうした過剰なCONTINUATIONフレームや肥大化したヘッダーに対する防護壁がデフォルトで組み込まれているが、インフラエンジニアとしては、利用しているミドルウェアのバージョン管理と脆弱性情報のキャッチアップを怠ることは許されない。

—

5. 結びにかえて：パケットの細部に宿るプロトコルの美学

HTTP/2における `CONTINUATION` フレームは、一見すると仕様の綻びを繕うための「継ぎ当て」のように見えるかもしれない。しかし、限られたフレームサイズの中で複雑なHPACKの文脈を破綻させず、かつマルチプレクシングの性能を最大限に引き出そうとするプロトコル設計者たちの苦闘と知恵の結晶が、この9バイトのヘッダーの背後には隠されている。

ネットワークスペシャリストやテックリードが向き合うべきは、単に「動くシステムを作る」ことではない。パケットがどのように分割され、どのトランスポート層のバッファを経由し、どのようなセキュリティの脅威に晒されているのか。その全貌を解像度高く把握し、設計、チューニング、そして防衛の三位一体でシステムを組み上げることこそが、真にレジリエントなインフラストラクチャを創り出す唯一の道なのだ。

さあ、次にお手元のパケットアナライザを開くときは、ぜひ `HEADERS` のあとに続く静寂の `CONTINUATION` フレームの群れに目を凝らしてみてほしい。そこには、現代Webの通信を支える、美しくもスリリングな攻防のドラマが刻まれているはずだ。

スポンサーリンク

コメント

タイトルとURLをコピーしました