こんにちは！ネットワークの世界へようこそ。インフラやプロトコルを学び始めると、専門用語の壁にぶつかって「うっ…」と頭が痛くなりますよね。でも、一歩ずつ紐解いていけば、実は私たちの身の回りの当たり前の仕組みと同じなんだなと気づけるはずです。
今回は、Webの通信を裏で支える「HTTP/2」という仕組み、その中でもちょっと通なテーマである「CONTINUATION（コンティニューーション）フレーム」について、一緒に優しく探検していきましょう！
—
1. そもそもHTTP/2の「ヘッダー」ってどんな状態だっけ？
私たちが普段何気なく見ているWebサイト。ブラウザはサーバーに対して「このページをちょうだい！」とリクエストを送り、サーバーは「はい、どうぞ！」とデータ（HTMLや画像など）を返しますよね。
このやり取りのとき、データ本体（ボディ）のほかに、「ヘッダー」というお供の荷物が必ずくっついてきます。
ヘッダーには、こんな大事な情報が書かれています。
- 「私、こういうブラウザを使ってます！」（User-Agent）
- 「こんな言葉を話せます！」（Accept-Language）
- 「ログイン中の合言葉（Cookie）です！」
HTTP/2のすごいところは、この荷物のやり取りを「マルチプレクシング（多重化）」という技を使って、1本の通信道路（TCPコネクション）の上で同時に何個も、まるでジャグリングのように効率よく行える点です。
郵便配達に例えてみましょう
HTTP/2の通信は、いわば「巨大な郵便配達システム」です。
1本の大きなメインストリート（コネクション）を行き交うバイク（ストリーム）たちが、たくさんの手紙を同時にピュンピュン配達しています。
手紙には、あて名書きや注意事項（ヘッダー）と、中身の書類（ボディ）が入っていますよね。通常は、1通の手紙の「ヘッダー」は、最初の封筒の表書きにきれいに収まります。
しかし……世の中には、めちゃくちゃ文字数が多い手紙もあるんです。
—
2. 入り切らない！そんなときに登場するのが「CONTINUATIONフレーム」
「ねぇ、今回のリクエスト、送りたいお供の荷物（ヘッダー情報）が多すぎて、最初の封筒の表面に書ききれないよ！」
そんなピンチのときに登場するのが、今回主役の「CONTINUATIONフレーム」です。英語の「continue（続く）」から来ています。つまり、「続きのヘッダーだよ！」と知らせるためのバトンタッチ用フレームなんです。
なぜヘッダーがそんなに大きくなるの？
「そんなにヘッダーが大きくなることある？」って思いますよね。実は現代のWebでは、以下のような理由でヘッダーが肥大化しがちです。
1. 巨大なCookie: ログイン情報やセッションID、広告のトラッキング用データがてんこ盛り。
2. 複雑なセキュリティ設定: 厳重なアクセス権限や暗号化のルールが書かれた長い認証トークン。
これらが重なると、HTTP/2が「一度に送る荷物のサイズ（フレームの最大サイズ）」の限界をあっさり超えてしまうことがあります。
—
3. 実際のパケットのやり取りをのぞいてみよう
HTTP/2の世界では、データはすべて「フレーム」という小さな箱（段ボール箱のようなもの）に詰められて流れます。
ヘッダーを送るときは、まず「HEADERSフレーム」という最初の箱を使います。しかし、箱の容量がいっぱいになってしまったら、次のようにバトンタッチが行われます。
1. HEADERSフレーム（1箱目）
- 「ヘッダーを送るよ！ でも、まだ続きがあるからね！」という目印（フラグ：`END_HEADERS`がOFF）をつけて送り出す。
2. CONTINUATIONフレーム（2箱目以降）
- 「さっきの続きだよ！」とばかりに、残りのヘッダーを詰めてすぐ後ろを追いかける。
- 最後の箱には「これでヘッダーは全部おしまい！」という目印（フラグ：`END_HEADERS`がON）をつける。
一連の流れのイメージ
[浏览器] ──( HEADERS: ヘッダー前半 + 「まだ続くよ」 )──> [サーバー]
[浏览器] ──( CONTINUATION: ヘッダー後半 + 「これで終わり！」 )──> [サーバー]
この「続きだよ」と繋げるルールがあるおかげで、どんなに大きなヘッダーでも、交通ルール（フレームのサイズ制限）を守りながら安全に届けられるというわけです。
—
4. 実務やデバッグで気をつけるべきポイント
さて、このCONTINUATIONフレーム、普段のアプリ開発ではあまり意識することはありません。しかし、インフラの構築や、プロキシサーバー（NginxやEnvoyなど）のチューニング、セキュリティの現場では、思わぬ落とし穴になることがあります。
いくつかの重要な制約と、実務での注意点を見ていきましょう。
① 割り込み厳禁！のルール
HTTP/2は複数のストリーム（手紙）を混ぜて送れるのがウリですが、「HEADERSフレームの直後から、最後のCONTINUATIONフレームが終わるまでの間」は、絶対に他のストリームのフレームを割り込ませてはいけないという鉄則（アトミック性）があります。
もし途中で別のストリームのデータが割り込んでしまうと、サーバー側で「あれ？どっちの手紙の続きだっけ？」とパニックになってしまいます。これを防ぐため、ネットワーク機器やプロキシは厳密に順序を守る必要があります。
② HTTP/2の「HTTP/3（QUIC）」への引き継ぎ
ちなみに、最新のWeb標準である「HTTP/3」では、トランスポート層にTCPではなくUDPベースの「QUIC」が使われるようになり、ヘッダー圧縮やフレームの構造も大きく刷新されました。HTTP/2特有のこのCONTINUATIONフレームの複雑さも、HTTP/3ではより洗練された仕組みに生まれ変わっています。
③ デバッグ時の設定例（Nginxやプロキシの裏側）
実務でWebサーバー（Nginxなど）を触る際、クライアントから送られてくる巨大なヘッダーを受け止めるために、バッファサイズの設定が必要になることがあります。
以下は、NginxでHTTP/2のヘッダーサイズやバッファを調整する際の設定イメージです。
server {
listen 443 ssl http2;
server_name example.com;
# HTTP/2のリクエストヘッダーを受け取るためのバッファサイズを指定
# 巨大なCookieなどでCONTINUATIONが多発する場合、ここが小さすぎるとエラーになることがあります
http2_max_field_size 16k; # 1つのヘッダーフィールドの最大値
http2_max_header_size 32k; # リクエスト全体のヘッダーの最大値
# SSL/TLSやその他の設定…
}
※実務で「HTTP/2の通信が431 (Request Header Fields Too Large) エラーになる」といったトラブルに直面したときは、こうしたバッファのサイジングや、クライアントが送ってくるヘッダーの総量を見直すのが定石です。
—
まとめ
いかがでしたでしょうか？
「CONTINUATIONフレーム」という名前だけ聞くと、なんだか難しそうな呪文のようですが、中身は「大きな手紙を封筒に入りきらないから、2通目に分けて『これ続きね！』って書くメモ」のような、とてもシンプルで人間らしい工夫でした。
ネットワークのプロトコルは、突き詰めていくと「限られたリソースの中で、どうやって確実かつ効率よく情報を伝えるか」という、先人たちの知恵と工夫の積み重ねです。
日々のインフラ運用やトラブルシューティングでパケットキャプチャを開いたとき、「あ、今CONTINUATIONでヘッダーの続きが流れているな」と心の中でニヤリとできたら、あなたも立派なネットワーク・スペシャリストの仲間入りです！
それでは、また次回の技術探検でお会いしましょう！
コメント