こんにちは！世界を駆け巡るパケットの鼓動を感じるインフラの最前線から、皆さんのネットワークライフをちょっぴり豊かにする情報をお届けする、主筆ライターの私です！
さて、今日は皆さんが普段何気なく使っているWebサイトの裏側で、高速化のために頑張っている「HTTP/2」プロトコルに隠された、とある「縁の下の力持ち」にスポットを当ててみましょう。
特に、Web通信の「顔」とも言えるヘッダー情報が、ときに膨れ上がってしまっても、HTTP/2がどうやってそれを賢く、そして確実に運んでいるのか。その秘密を解き明かす鍵となるのが、今回ご紹介する「CONTINUATIONフレーム」なんです。
「え、コンティニュエーション…って何ですか？」
大丈夫です！難しそうな名前ですよね。でも、ご安心ください。郵便配達の仕組みや、身近な例えを交えながら、一歩ずつ一緒に理解を深めていきましょう！
—
## HTTP/2の舞台裏！大きなヘッダーも安心「CONTINUATIONフレーム」って何だろう？
# Webページの顔！「ヘッダー」って、そんなに大きくなることあるの？
皆さんがWebサイトにアクセスするとき、ブラウザ（ChromeやSafariなど）は、たくさんの情報をサーバーに送っています。そして、サーバーもまた、たくさんの情報をブラウザに返しています。このやり取りの中で、データ本体（画像や文章など）の前に付随する「情報」、それがヘッダー（Header）です。
例えるなら、手紙を送るときに封筒の表に書く「宛先」「差出人」「日付」のようなもの。あるいは、宅配便の荷物に貼る「送り状」のようなもの、と言えばイメージしやすいでしょうか。
このヘッダーには、例えばこんな情報が含まれています。
- どんなブラウザを使っているか？ (User-Agent)
- どんな言語で表示してほしいか？ (Accept-Language)
- 以前アクセスした時に発行された識別情報 (Cookie)
- どのページから来たのか？ (Referer)
- この通信をどれくらいの間、キャッシュしていいか？ (Cache-Control)
これらは、Webサイトを正しく、そして快適に表示するために欠かせない、とっても大切な情報なんですよね。
普段は意識しないかもしれませんが、実はこのヘッダー情報、特に「Cookie」なんかは、ログイン情報や閲覧履歴、セッションIDなど、たくさんのデータが詰め込まれていて、意外と大きくなることがあるんです！ 長いURLや、ウェブアプリケーションが独自に設定する「カスタムヘッダー」がたくさんある場合も同様です。
「え、そんなに大きくなるなら、通信の邪魔にならないの？」
はい、その通り！そこでHTTP/2が力を発揮するんです。
# HTTP/2の賢い工夫：ヘッダー圧縮「HPACK」
HTTP/1.1の時代は、このヘッダーが毎回、何の工夫もなくテキスト形式で送られていました。同じ情報が何度も繰り返し送られることもザラで、これが通信速度を低下させる一因にもなっていたんです。
そこでHTTP/2では、「HPACK（エイチパック）」という、とっても賢いヘッダー圧縮技術が導入されました。
HPACKは、例えるなら「辞書」と「メモ帳」を駆使する郵便局員さんのようなもの。
1. 静的テーブル（Static Table）: 「よく使われる宛名や差出人名はこれね！」と、あらかじめ決まった定型文のリスト（辞書）を持っておく。毎回フルネームで書かずに、辞書の「番号」だけを送ればOK！
2. 動的テーブル（Dynamic Table）: 「このお客さん、いつも同じような宛名で送ってくるから、今回使った宛名もメモ帳に書いておこう！次からは番号だけで済むかも！」と、過去に送ったヘッダー情報も記憶しておき、再利用する。
このように、重複する情報を効率よく省略したり、差分だけを送ったりすることで、ヘッダーのデータ量を劇的に減らすことができるようになりました。これは、通信速度の向上に大きく貢献している、素晴らしい技術なんですよね！
# 問題発生！？ヘッダーが「一つの箱」に収まらない！
さて、HPACKのおかげでヘッダーは小さくなりました。HTTP/2では、この圧縮されたヘッダー情報が、「HEADERフレーム」という専用の「箱」に入れられて送られます。
イメージとしては、圧縮された送り状を専用の透明なプラスチックケースに入れて送るような感じですね。
しかし！先ほどお話ししたように、たとえ圧縮されたとしても、Cookieがものすごく長かったり、カスタムヘッダーがたくさんあったりすると、この「HEADERフレーム」という箱に、すべてのヘッダー情報が入りきらない！ という事態が起こり得ます。
さあ、困りました。郵便局員さんが送り状をプラスチックケースに入れようとしたら、一部がはみ出ちゃった…みたいな状況です。このまま無理やり送っても、途中で情報が欠落したり、受け取った側が正しく読み取れなかったりするかもしれません。特にヘッダー圧縮は、途中の情報が欠けると全体が解読できなくなる可能性があるので、これは一大事です！
# 颯爽登場！「CONTINUATIONフレーム」の役割
ここで満を持して登場するのが、今日の主役である「CONTINUATIONフレーム」なんです！
CONTINUATIONフレームの役割は、ずばりこうです。
「HEADERフレームに収まりきらなかったヘッダー情報の続きを運ぶフレーム」
イメージとしては、最初のプラスチックケース（HEADERフレーム）に入りきらなかった送り状の残りを、「これはさっきの続きだよ！」と明記した別のプラスチックケース（CONTINUATIONフレーム）に入れて、セットで送るようなものですね。
これにより、受け取った側（ブラウザやサーバー）は、
1. 「HEADERフレームが来たぞ。あれ？まだ続きがあるぞ？」
2. 「CONTINUATIONフレームが来た。これはHEADERフレームの続きだな」
3. 「よし、これで全部揃った！一つのまとまった送り状として処理しよう！」
と、正しく認識して、一つのヘッダーブロックとして処理することができるわけです。
## なぜ「HEADERフレーム」の続きを「CONTINUATIONフレーム」に分ける必要があるの？
「なんでわざわざ別のフレームに分けるの？HEADERフレームを大きくすればいいじゃん？」
そう思いますよね！実はこれには、ヘッダー圧縮（HPACK）の整合性を保つという、とっても大切な理由があるんです。
HPACKは、一連のヘッダーブロックが途切れることなく連続していることを前提として圧縮・展開を行います。もし、一つのフレームに収まらない場合に、中途半端な状態で別のフレームを挟んだり、ただ分割して送ったりしてしまうと、受け取った側が「あれ？どこからどこまでが一つのヘッダーブロックなんだ？」と混乱してしまい、正しく解凍できなくなる可能性があります。
CONTINUATIONフレームは、「私はHEADERフレームとセットで一つのヘッダーブロックを構成するパーツです！」と、明確にその役割を宣言しています。これにより、HTTP/2のプロトコルは、これら複数のフレームを「一塊のヘッダーブロック」として正しく扱い、HPACKの圧縮・展開処理を滞りなく進めることができるのです。
## 「END_HEADERS」フラグが合図！
ここで少しだけ専門的な話になりますが、HTTP/2のフレームには、そのフレームが持つ意味を示す「フラグ」という小さな目印が付いています。
CONTINUATIONフレームを理解する上で大切なのが、`END_HEADERS`というフラグです。これは文字通り、「これでヘッダーブロックは終わりですよ！」という合図になります。
- ヘッダー情報がHEADERフレーム一つに収まる場合:
HEADERフレームに`END_HEADERS`フラグがセットされます。
- ヘッダー情報がHEADERフレームとCONTINUATIONフレームにまたがる場合:
HEADERフレームには`END_HEADERS`フラグはセットされず、最後のCONTINUATIONフレームに`END_HEADERS`フラグがセットされます。
この`END_HEADERS`フラグが、受け取った側が「これで一つのヘッダーブロックの受信が完了したぞ！」と判断する重要な目印になる、というわけですね。これによって、たとえヘッダー情報が複数フレームに分割されても、全体として正しく処理できるんです。
# 実際に見てみよう！デバッグのヒント
普段、皆さんがWebサイトを閲覧している分には、このCONTINUATIONフレームが使われているかどうかを意識することはありません。しかし、Webアプリケーションの開発やネットワークのトラブルシューティングをしていると、「あれ？ヘッダーが送れてない？」とか「Cookieが大きすぎて問題が起きているかも？」といった時に、このCONTINUATIONフレームの存在を意識すると、原因究明のヒントになることがあります。
例えば、Chromeの開発者ツール（F12キーで開くやつですね！）の「Network」タブでHTTP/2通信の詳細を確認したり、Wiresharkのようなパケットキャプチャツールで実際のネットワークのやり取りを覗いてみると、HEADERフレームやCONTINUATIONフレームが送受信されている様子を見ることができるかもしれません。
特にWiresharkでは、HTTP/2のフレーム構造を詳細に解析してくれるので、`HEADER`フレームの後に`CONTINUATION`フレームが続き、最後に`END_HEADERS`フラグが付いている様子などを確認できます。
残念ながら、CONTINUATIONフレームはプロトコルの低レイヤーで自動的に処理されるものなので、皆さんが直接「よし、CONTINUATIONフレームを送るぞ！」とコードを書くことはありません。ですが、「もしヘッダーが大きくなりすぎたら、HTTP/2のプロトコルが裏でこんな風に頑張ってくれているんだな」という知識は、Webアプリケーションの設計やデバッグにおいて、きっと役立つはずです。
# まとめ：縁の下の力持ち、CONTINUATIONフレーム
いかがでしたでしょうか？
HTTP/2の「CONTINUATIONフレーム」は、一見地味な存在に思えるかもしれませんが、実は大きなヘッダー情報も効率的かつ確実に送るための、非常に重要な「縁の下の力持ち」なんです。
このフレームがあるおかげで、WebブラウザもWebサーバーも、どんなに大きなヘッダー情報が来ても、ヘッダー圧縮の恩恵を受けながら、正しく情報をやり取りできるわけですね。
HTTP/2がWebの高速化と効率化を実現するために、一つ一つのパケットの送り方にまで、こんなにも緻密な工夫が凝らされているなんて、驚きですよね！
ネットワークの世界は、目に見えないところでたくさんの技術が連携して動いています。一つ一つの仕組みを紐解いていくと、まるで精巧な機械の歯車が噛み合うように、全体が機能しているのがわかります。
今日ご紹介したCONTINUATIONフレームも、そんなHTTP/2の賢い工夫の一つ。この知識が、皆さんのネットワークへの理解を深める一助となれば嬉しいです。
これからも一緒に、Webの世界の奥深さを探求していきましょう！
コメント