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

HTTP/2の裏側でうごめく巨獣：CONTINUATIONフレームの真実と、静かなる脅威の回避策

ネットワークの深淵を覗くとき、私たちはしばしばレイヤー4のTCPセグメントやTLSの暗号化パケットの往来に目を奪われがちだ。しかし、アプリケーション層のプロトコルがどれほど洗練されていようとも、物理的な制約と歴史的なしがらみから完全に逃れることはできない。

HTTP/2は、長年Webの足かせとなってきたHTTP/1.xのヘッド・オブ・ライン・ブロック（HoLB）を打ち破るべく、単一のTCPコネクション上で複数のリクエストとレスポンスを並行処理する「マルチプレクシング」というパラダイムを私たちにもたらした。その美しさは、ひとつのストリームがパケットロスで足止めを食らおうとも、他のストリームが平然とデータを流し続けられるという、トランスポート層上の擬似的な独立世界にある。

だが、プロトコルの仕様書という冷徹な現実の隙間には、しばしば設計者たちの苦悩の歴史が染み込んでいる。
今回スポットを当てるのは、HTTP/2の内部構造において最も地味でありながら、一歩間違えれば巨大なセキュリティホールとシステム崩壊を引き起こす時限爆弾――`CONTINUATION`フレーム（Type: 0x9）である。

なぜこのフレームが存在するのか。ヘッダー圧縮の文脈、HPACKのコンテキスト、そして実務の現場でインフラエンジニアが直面するリスクと最適化の境界線について、パケットの微細な挙動から紐解いていこう。

—

1. なぜ`CONTINUATION`が必要なのか：フレーム分割の不可避な現実

HTTP/2のすべての通信は「フレーム」というバイナリの単位でカプセル化される。
リクエストやレスポンスのメタデータ（HTTPヘッダー）を伝送するためには、主に `HEADERS` フレームが使用される。ここで思い出してほしいのは、HTTP/2のフレームヘッダーの構造だ。

フレームの先頭には必ず9オクテット（バイト）のヘッダーが付与される。

• 長さ（Length）: 24ビット（最大 16,384 バイト = 16KB、初期設定値の場合）
• タイプ（Type）: 8ビット（`HEADERS` なら `0x1`）
• フラグ（Flags）: 8ビット
• 予約ビット＋ストリーム識別子（Stream Identifier）: 32ビット

ここでひとつの疑問が生じる。
「もし、送信したいHTTPヘッダーの総量が、設定された最大フレームサイズ（SETTINGS_MAX_FRAME_SIZE）を超えたらどうなるのか？」

現代のWebアプリケーションでは、巨大なCookie、複雑なOAuthのBearerトークン、あるいは大量のカスタムヘッダーやCDNのトレースヘッダーが飛び交う。これらが軽く16KBを超えることは日常茶飯事だ。

HTTP/2の設計において、ひとつの `HEADERS` フレームの途中でパケットを分断することは許されていない。なぜなら、HPACKによるヘッダー圧縮は、連続したバイトストリームとしてのコンテキスト（動的テーブルの状態）に完全に依存しているからだ。中途半端な位置でフレームをぶった切ると、デコーダー側が何を指しているのかを見失い、HPACKの整合性が一瞬で崩壊する。

そこで登場するのが、`CONTINUATION` フレームである。

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

クライアントが巨大なヘッダーブロックを送出する際、最初のチャンクは `HEADERS` フレーム（あるいは `PUSH_PROMISE`）として送信される。この時、もし全ヘッダーを収めきれないと判断した場合、送信側はフラグ制御によって次のような振る舞いを見せる。

1. `HEADERS` フレームの `END_HEADERS` フラグ（0x4）をオフにして送信する。
2. 「まだ続きがあるぞ」という意思表示を残したまま、フレームの最大長に達するまでデータを詰める。
3. 直後のフレームとして、`CONTINUATION` フレーム（Type: 0x9）を連続して送出する。
4. 最後のチャンクとなる `CONTINUATION` フレームに到達した時点で、初めて `END_HEADERS` フラグをオンにする。

この一連の連続したフレーム群は、プロトコル上、単一の論理的な「ヘッダーブロック」として扱われなければならない。途中に他のストリームのフレームが割り込むことは、HTTP/2の仕様上厳に禁じられている。

—

2. HPACKと `CONTINUATION`：圧縮の整合性を維持する鎖

HTTP/2の高速性を支えるもうひとつの立役者が、HPACK（RFC 7541）によるヘッダー圧縮だ。
HTTP/1.xのテキストベースの冗長なヘッダー（`User-Agent`や`Accept-Encoding`など）を、静的テーブルと動的テーブル（Dynamic Table）を参照するインデックス番号へと置き換えることで、帯域を劇的に節約する。

ここで重要なのは、動的テーブルは、通信の両端（クライアントとサーバー）で完全に同期していなければならないという点だ。

もし、ネットワークの途中で `HEADERS` フレームの後に予期せぬフレームが挟まったり、`CONTINUATION` の鎖が途切れたりすると、デコーダーはどのインデックスがどの文字列を指しているのかの文脈（コンテキスト）をロストする。HPACKのデコードエラーは、即座にコネクション全体の致命的な崩壊（`CONNECTION_ERROR`、エラーコード `COMPRESSION_ERROR`）を引き起こし、接続中のすべてのストリームが強制切断される。

つまり、`CONTINUATION` フレームは単なる「長いデータの置き場所」ではなく、暗号化と圧縮のコンテキストを安全に対岸まで運ぶための、きわめてデリケートな架け橋なのだ。

—

3. 悪夢の始まり：CVE-2019-9512（CONTINUATION Flood）の脅威

プロトコルの美しさの裏には、常に悪意ある攻撃者の影が潜んでいる。
2019年、インターネット全体を震撼させた脆弱性群「HTTP/2 Multiplexing DoS Attacks（通称トレーラー）」の一つに、`CONTINUATION` Flood（CVE-2019-9512）がある。

攻撃のメカニズムはシンプルかつ悪質だった。

1. 攻撃者はHTTP/2のコネクションを確立する。
2. 攻撃者は `HEADERS` フレームを送信し、`END_HEADERS` フラグをあえて立てない。
3. その後、極小サイズのペイロードを持つ無数の `CONTINUATION` フレームを、終わりなく延々とサーバーへ送り続ける。
4. サーバーのHTTP/2実装（当時の多くの著名なWebサーバーやプロキシ）は、仕様に従い「このヘッダーブロックはまだ完了していない」と判断し、すべての `CONTINUATION` フレームのデータをメモリ上のバッファに蓄え続ける。
5. 結果として、サーバーのリソース（CPUとメモリ）は枯渇し、正当なユーザーのリクエストを処理できなくなる（拒绝服务 / DoS）。

この脆弱性が恐ろしいのは、単一のTCPコネクション、かつごくわずかな帯域幅の消費だけで、エンタープライズ向けの堅牢なサーバーすら容易に膝をつかせることができた点にある。アプリケーション層のバッファ管理の甘さと、プロトコル仕様の性善説的な解釈を突き崩した象徴的な事件だった。

現代のインフラにおける対策と防御コードの設定

この教訓から、Nginx、Apache、Envoy、Goの `net/http`、Node.jsなどの主要なHTTP/2実装は、厳しい防衛策をデフォルトで組み込むようになった。
例えば、ヘッダーの合計サイズに上限（例: 32KBや64KBなど）を設け、それを超えた瞬間に容赦なくコネクションを切断する、あるいは `CONTINUATION` フレームの連続回数にハードリミットを課すといったアプローチだ。

もしあなたがGo言語で独自のリバースプロキシやHTTP/2サーバーを実装・運用している場合、標準ライブラリのデフォルト挙動に依存するだけでなく、以下のように明示的な制限やガードを意識する必要がある。

package main

import (
“crypto/tls”
“log”
“net/http”
“golang.org/x/net/http2”
)

func main() {
server := &http.Server{
Addr: “:443”,
Handler: http.HandlerFunc(func(w http.ResponseWriter, r http.Request) {
w.Write([]byte(“Hello, HTTP/2 World!”))
}),
}

// HTTP/2 の詳細な挙動を制御するための設定
h2Server := &http2.Server{
// 最大Readバッファやストリームごとの制限を適切に管理
// 悪意ある巨大ヘッダーや CONTINUATION Flood によるメモリ枯渇を防ぐため、
// アプリケーション要件に応じた厳格な閾値を設けることが極めて重要。
MaxUploadBufferPerConnection: 1024 1024, // 1MB
MaxUploadBufferPerStream: 128 1024, // 128KB
}

// http2の設定を標準のhttp.Serverにバインド
http2.ConfigureServer(server, h2Server)

// TLS 1.3 を前提としたセキュアな設定
server.TLSConfig = &tls.Config{
MinVersion: tls.VersionTLS13,
CipherSuites: []uint16{
tls.TLS_AES_128_GCM_SHA256,
tls.TLS_AES_256_GCM_SHA384,
tls.TLS_CHACHA20_POLY1305_SHA256,
},
}

log.Println(“Starting secure HTTP/2 server with hardened settings…”)
// 実際の本番環境では適切な証明書パスを指定する
if err := server.ListenAndServeTLS(“server.crt”, “server.key”); err != nil {
log.Fatalf(“Server failed: %v”, err)
}
}

—

4. パフォーマンスの最適化：RTT削減、TLS、そしてTCPバッファチューニング

`CONTINUATION` フレームが発生するシチュエーション、すなわち「巨大なヘッダーを送信する」という状況は、ネットワークのレイテンシやスループットの観点からも望ましくないアンチパターンに近い。
真のネットワークアーキテクトであれば、フレームの断片化を防ぐアプローチ、すなわち「そもそもヘッダーを小さく保つ」ことと、「トランスポート層のパイプラインを極限まで効率化する」ことの両面からアプローチすべきだ。

TLS 1.3 とのシナジー

HTTP/2は実質的にTLS（HTTPS）の上でしか動作しない（H2Cを除く）。そのため、レイテンシ削減の勝負の分かれ目はTLSハンドシェイクにある。

• 0-RTT（Resumption）: 前回のセッション情報を利用して、最初のTCPハンドシェイクのACKと同時に暗号化リクエスト（と巨大なヘッダー）を送り出す。
• この際、パケットサイズが初期輻輳ウィンドウ（Initial Congestion Window: IW10 / IWNever）の制限を超えると、TCPレイヤーでパケット分割（セグメンテーション）が発生し、さらにアプリケーション層の `CONTINUATION` 分割が重なると、パケットの往復（RTT）が増大する原因になる。

Linuxカーネルパラメータ（TCPバッファとBBR）のチューニング

もしあなたのサーバーが大量のHTTP/2コネクションを収容し、頻繁に大きなヘッダーやデータやり取りを行っているなら、Linuxカーネルのネットワークスタックのチューニングは避けて通れない。

`/etc/sysctl.conf` における以下のパラメーター群は、HTTP/2のマルチプレクシングとフロー制御を支える基礎体力となる。

TCPの送受信バッファの最小値、デフォルト値、最大値（バイト単位）
マルチプレクシングによって単一コネクション上に多数のストリームが相乗りするため、
バッファが小さすぎるとウィンドウサイズが直ちに枯渇する。
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

TIME_WAIT ソケットの再利用を許可
net.ipv4.tcp_tw_reuse = 1

輻輳制御アルゴリズムに Google BBR を採用
パケットロスを「混雑」と誤認せず、帯域幅と伝搬遅延をリアルタイム計測してスループットを最大化する。
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

最大SYNバックログキューの拡張
net.ipv4.tcp_max_syn_backlog = 8192

BBRと適切なTCPウィンドウサイズの組み合わせにより、仮に `CONTINUATION` フレームによって一連のヘッダーブロックが数パケットに分割されたとしても、それらがロスなく、かつ最短の遅延でクライアント・サーバー間を駆け抜けることが保証される。

—

結びにかえて：プロトコルの細部に宿る職人技を見据えて

HTTP/2の仕様書を眺めると、`CONTINUATION` フレームの存在は一見すると「やむを得ず追加された泥臭いパッチ」のように見えるかもしれない。しかし、ストリームの独立性を守りつつ、HPACKの圧縮コンテキストの整合性を保ち、なおかつ巨大なメタデータの往来を許容するための、極めて洗練された妥協点なのだ。

インフラストラクチャの設計やセキュリティ監査において、私たちが対峙するのは単なる「コードのバグ」だけではない。プロトコル仕様の境界線、設計思想のジレンマ、そしてそれを悪用しようとする攻撃者とのイタチごっこである。

パケットがNICを叩き、TLSの暗号化の海を渡り、カーネルのバッファを抜けてアプリケーションのメモリに到達するその瞬間まで――すべてのフレームの意図を正確に把握すること。それこそが、真のネットワークアーキテクトと、単なる設定ツールのオペレーターを分かつ決定的な境界線なのである。