こんにちは！ネットワークやインフラストラクチャーの世界へようこそ。世界最高峰のネットワークアーキテクトであり、技術ライターの私がお届けする今回のテーマは、Webの裏側を支える「HTTP/2」の、ちょっと通な主役「CONTINUATION（コンティニュエーション）フレーム」です。

「いきなり聞き慣れない英語が出てきたぞ……」と身構えてしまいましたか？大丈夫です！難しいビットの数や、RFCの分厚い仕様書を読む必要は一切ありません。今回は、私たちの身近にある「あるモノ」に例えて、このCONTINUATIONフレームの正体を優しく、そして深く紐解いていきましょう。

それでは、パケットが駆け巡るエキサイティングな旅に出発です！

—

1. HTTP/2の「ヘッダー圧縮」と、そこにある小さなお悩み

インターネットでWebサイトを見るとき、私たちのブラウザ（クライアント）とサーバーの間では、膨大な数のデータがやり取りされていますよね。HTTP/2は、従来のHTTP/1.1に比べて圧倒的なスピードスターです。なぜなら、1本の通信路（コネクション）の上で、複数のデータを同時にパラパラと送受信できる「マルチプレクシング（多重化）」という、まるで手品のような離れ業を持っているからです。

さらに、HTTP/2には「HPACK（エッチパック）」という賢い仕組みがあります。「Webの通信って、毎回同じようなお供え物（ブラウザの種類やクッキーなどのヘッダー情報）を何度も送って無駄じゃない？」という発想から生まれた、ヘッダーの圧縮技術です。

一歩ずつ理解していきましょう！
このHPACKのおかげで、ヘッダー情報は小さく圧縮されてパケットに詰め込まれます。しかし、ここで一つ、インフラの現場でよく起こる「物理的な壁」にぶつかるのです。

—

2. 郵便配達のルールに例えてみましょう

ここで、身の回りの現実世界に例えてみましょう。

想像してください。あなたは、ものすごく長〜い手紙（膨大なヘッダー情報）を書きました。これを相手に送りたいのですが、郵便局（ネットワーク）には「一度に封筒に入れられる手紙のサイズ（最大フレームサイズ、通常はデフォルトで16KB＝約16,384バイト）」という厳格なルールがあります。

「うわっ、この封筒には書ききれないよ！どうしよう……」

手紙をビリビリに破いて別々に送ったら、相手に届いたときに順番がごちゃ混ぜになって読めなくなってしまいますよね。かといって、全部を1枚の紙に無理やり収めようとすると、郵便局の窓口で「サイズオーバーです！」と突っ返されてしまいます。

そこで登場するのが、今回のヒーロー「CONTINUATIONフレーム」なのです！

—

3. 主役の登場：CONTINUATIONフレームの役割

HTTP/2の世界では、データは「フレーム」という小さな箱に分けて送られます。ヘッダー情報を送るときは、まず「HEADERSフレーム」という最初の箱を使います。

もし、ヘッダー情報が大きすぎて最初のHEADERSフレームの容量（16KBなど）をオーバーしてしまったら、どうなるでしょうか？

1. 最初の箱（HEADERSフレーム）に、入る限界ギリギリまでヘッダーの続きを詰め込みます。この時、「まだ続きがあるよ！」という合図（フラグ）をそっと添えておきます。
2. 溢れてしまった残りのヘッダーを、2つ目の箱（CONTINUATIONフレーム）に詰め替えて、すぐ後ろを追うように送信します。
3. もしそれでも入り切らなければ、3つ目、4つ目とCONTINUATIONフレームを連続（Continuation）して列車のように繋げて送ります。

つまり、CONTINUATIONフレームの役割とは、「大きすぎて1回で送りきれなかったヘッダー情報の続きを、安全にバトンタッチして届けること」なのです。

サーバー側（受け手）は、このCONTINUATIONフレームを受け取ると、「あ、さっきのHEADERSフレームの続きだな」と理解し、パズルのピースを綺麗に組み合わせて元の完全なヘッダーを復元します。この一連の流れがあるおかげで、どんなに大きなクッキーや複雑な認証情報が含まれていても、エラーを起こさずにスムーズにやり取りができるというわけですね。

—

4. 実務の現場でこの動きを見てみよう（デバッグのヒント）

インフラエンジニアやWebアプリケーションエンジニアとして現場に出ると、ブラウザの開発者ツールや、パケットキャプチャツール（Wiresharkなど）を使って通信の中身を覗き見する機会がやってきます。

例えば、Node.jsやNginxなどのサーバー設定、あるいはHTTP/2のライブラリを使って通信を模倣する際、次のようなイメージでデータの流れを意識することがあります（※概念的な設定・ログのイメージです）。

// 【イメージ】HTTP/2サーバー側でのフレーム処理の概念
http2Server.on(‘stream’, (stream, headers) => {
// クライアントから送られてきたヘッダー情報を受け取る
console.log(‘受信したヘッダー:’, headers);

// もしヘッダーが巨大で分割（CONTINUATION）されていても、
// Node.jsのHTTP/2モジュールが自動的に結合してくれて、
// ここでは綺麗に完成した状態の `headers` オブジェクトとして受け取れます。

// レスポンスの返却
stream.respond({
‘:status’: 200,
‘content-type’: ‘text/html; charset=utf-8’
});
stream.end(‘

こんにちは、HTTP/2の世界へ！

‘);
});

このように、実際のプログラミング言語やミドルウェアの内部では、このCONTINUATIONフレームの結合処理は自動で行われています。そのため、普段私たちがコードを書くときに「CONTINUATIONフレームを意識して手動で繋ぎ合わせる」ような面倒な作業はほとんどありません。

しかし、「なぜこのエラーが出るのか？」というトラブルシューティングの場面では、この知識が強力な武器になります。例えば、あまりにも巨大なヘッダー（数メガバイトもある巨大なCookieなど）を送りつけて、サーバー側の受信バッファ制限（`SETTINGS_MAX_HEADER_LIST_SIZE`など）に引っかかったとき、「あ、今CONTINUATIONフレームの途中でサーバーがブチギレて（RST_STREAMフレームを返して）接続を切断したな」という原因が、パケットの挙動から手に取るように分かるようになるのです。

—

おわりに

いかがでしたでしょうか？
一見すると難解な「CONTINUATIONフレーム」という技術用語も、「大きな手紙を封筒のサイズに合わせて分割し、後続の封筒でバトンタッチして届ける仕組み」として捉えると、ぐっと親しみやすく感じられたのではないでしょうか。

ネットワークの裏側では、こうした小さなフレームたちが一瞬の隙もなく連携し合い、私たちが日々快適にWebサイトを閲覧できる環境を支えています。

今回の学びが、あなたのインフラ学習の小さな一歩、そして確かな自信になれば幸いです。それでは、また次回の技術探訪でお会いしましょう！

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