Webエンジニアやインフラの道へ一歩を踏み出した皆さん、日頃からブラウザでウェブサイトを見たり、APIの通信設計をしたりと、HTTPという言葉に触れない日はありませんよね。
「Webページを表示する」「データを送受信する」――何気なく使っているその裏側では、目にも留まらぬ速さでパケットたちがネットワークの海を駆け巡っています。中でも、現代のWebを支える「HTTP/2」は、通信の効率を劇的に進化させた主役です。
今回は、そのHTTP/2の心臓部とも言える「HEADERSフレーム」と、通信の終わりを告げる「エンドストリームフラグ（END_STREAM）」にスポットを当てます。
「難解なプロトコル仕様書は眠くなる……」そんなあなたのために、身近な世界に置き換えて、一歩ずつ優しく紐解いていきましょう！
—
1. 郵便配達でイメージする「HTTP/2」の世界
これまでのHTTP/1.1という古い世界は、いわば「1つの封筒に手紙を1通しか入れて送れない」ような仕組みでした。画像が10枚あるページなら、10通の封筒を順番に、1通ずつ往復させて運んでいたのです。これでは時間がかかって当然ですよね。
そこで登場したHTTP/2は、「1つの大きなトラック（TCPコネクション）の中に、いくつもの専用レーン（ストリーム）を作って、荷物を同時に仕分けして運ぶ」ような超効率的な仕組みを手に入れました。
この「レーン」ごとに、荷物のやり取りを管理するための「フレーム（小さなダンボール箱）」という単位が使われます。HTTP/2の通信は、すべてこのダンボール箱をトラックに積み込んで行われているんです。
—
2. 「HEADERSフレーム」ってなぁに？
トラックに積むダンボール箱（フレーム）には、色々な種類があります。中身が画像データなら「DATAフレーム」、そして、宛先や宛名、パスワードのようなメタデータを詰めたダンボール箱が「HEADERS（ヘッダーズ）フレーム」です。
郵便に例えると「宛名ラベル付きの重要書類」
私たちが手紙を送るとき、封筒の表に「宛先（URL）」や「差出人」、そして「中身の種類（コンテンツタイプ）」を書きますよね。HEADERSフレームは、まさにその「宛名ラベル」の役割を持っています。
HTTP/2では、この宛名情報（ヘッダー）をそのまま送るのではなく、「HPACK（エーフパック）」という技術でギュッと圧縮して小さくしてから、HEADERSフレームに詰めて送り出します。回線をムダづかいしないための、先人たちの粋な工夫です。
—
3. 通信の終わりを告げる魔法の合図「END_STREAM」
さて、ここからが今回の本題です。
いくつもの荷物が同時に行き交うHTTP/2のレーン（ストリーム）では、受信側（ブラウザやサーバー）にとって、大きな疑問が生まれます。
「ねぇ、送られてきているこの荷物、これで全部？ まだ続きがあるの？」
1つのレーンで、ヘッダーを送って、データを送って……とやり取りしているとき、「ここで今回のやり取りは終わりです！」とハッキリ教えないと、受信側はずっと待ちぼうけを食らってしまいます。
そこで登場するのが、「END_STREAM（エンド・ストリーム）」フラグです。
「これにて一件落着！」のスタンプ
END_STREAMは、ダンボール箱のフタにポンと押す「これにて荷物はすべて終了です（おしまい）」という完了スタンプのようなものです。
- リクエストを送るとき： 「私の注文はこれで全部です（ブラウザ → サーバー）」
- レスポンスを送るとき： 「お探しのページのデータはこれで全部出し切りました（サーバー → ブラウザ）」
このスタンプが押されたフレームを受け取った瞬間、受信側は「あ、このレーンの仕事は終わったんだな」と安心して、次の処理に移ることができるのです。
—
4. 開発者の目で見るリアルな挙動（デバッグの世界）
インフラやバックエンドの現場では、ブラウザの開発者ツールや、通信を覗き見するツール（Wiresharkやnghttp2など）を使って、このフレームのやり取りをリアルタイムで確認することがあります。
もし実際にパケットを覗いたとしたら、HEADERSフレームとEND_STREAMは、次のようなイメージ（ログ表現）で見ることができます。
[HTTP/2 プレーンテキスト風のデバッグイメージ]
// 1. ブラウザからサーバーへ：リクエストの出発
フレーム種別: HEADERS
フラグ: END_HEADERS (ヘッダーの記述はこれで終わり) | END_STREAM (リクエストの本体データもこれで終わり、つまりGETリクエストなど中身がない場合)
ストリームID: 1
内容:
:method: GET
:path: /index.html
:authority: example.com
// 2. サーバーからブラウザへ：レスポンスの返却（HTMLファイルが大きい場合）
フレーム種別: HEADERS
フラグ: END_HEADERS (ヘッダーはここまで)
ストリームID: 1 (先ほどと同じレーン番号)
内容:
:status: 200 OK
content-type: text/html; charset=utf-8
// 3. サーバーからブラウザへ：HTMLデータの本体を送る
フレーム種別: DATA
フラグ: なし (まだデータが続くよ)
ストリームID: 1
内容:
// 4. サーバーからブラウザへ：データの仕上げと完了通知
フレーム種別: DATA
フラグ: END_STREAM (すべてのHTMLデータを送り終えた！)
ストリームID: 1
内容: …
このように、「HEADERSフレームで宛名とルールを伝え、DATAフレームで中身を運び、最後にEND_STREAMフラグで綺麗に店じまいをする」という美しいストーリーが、HTTP/2の通信ルールとして裏で繰り広げられているのです。
—
まとめ：ネットワークの裏側を想像してみよう
いかがでしたでしょうか？
「HEADERSフレーム」も「END_STREAMフラグ」も、名前こそ少し難しそうですが、やっていることは「効率よく荷物を仕分けして、終わりをきちんと相手に伝える」という、人間社会のロジスティクスと全く同じです。
こうしたプロトコルの基本原理を知っておくと、Webアプリのパフォーマンスチューニングでつまずいたときや、ネットワークのトラブルシューティング（「あれ、レスポンスが途中で途切れてる？ END_STREAMが来てないぞ？」など）に直面したとき、強力な武器になります。
パケットの動きが頭の中でスラスラとイメージできるようになると、インフラやネットワークの世界がぐっと楽しく、エキサイティングになっていきますよ。
それでは、また次回の技術解説でお会いしましょう！
コメント