【入門編】Transfer-Encoding: chunkedの仕様とパケット構造 – HTTPプロトコル・通信規格実践ガイド

Webサイトを見ているとき、画像やテキストが上から順にパタパタと表示されていく様子を見たことはありませんか？

あれは単に表示が速いだけではありません。実は、Webサーバーが「まだデータは全部できていないけど、できた分からどんどん送るね！」と気を利かせているからなんです。この魔法を支えているのが、HTTP/1.1の影の立役者、『Transfer-Encoding: chunked』です。

今回は、この「小分け配送」の仕組みを、郵便局の仕分け作業に例えて紐解いていきましょう。

—

HTTPの歴史を振り返ると、昔（HTTP/1.0の頃）は「送るデータのサイズ」を事前に正確に伝える必要がありました。

これを郵便に例えると、「箱の中身が何キロあるか分からなければ、トラックを出発させない」というルールです。もしあなたが動的に生成されるデータ（例えば、リアルタイムの株価や、データベースから何行出てくるか分からない検索結果）を送ろうとしたらどうなるでしょう？

「全部生成されるまで待つ」必要がありますよね。これではユーザーは画面の前でずっと待ちぼうけです。そこで登場したのが、「重さが分からなくても、小分けにしてどんどん送っちゃおう！」というチャンク（Chunk＝塊）転送です。

—

チャンク転送のパケット構造は、実はとてもシンプルです。郵便物でいう「荷札」と「中身」を繰り返すだけ。ルールは以下の3ステップです。

1. サイズを伝える（荷札：この箱には何バイト入っているか）
2. データを送る（中身：実際のデータ本体）
3. 終わりを告げる（0という数字を送って「もうおしまい！」と伝える）

これを繰り返すことで、サーバーはメモリを無駄に占有することなく、生成できた端からパケットをネットワークに流し込めるのです。

—

実際に通信が行われている現場のパケットをイメージしてみましょう。こんな感じでデータが流れています。

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked // 「これからは小分けで送るよ！」という合図

5\r\n // 16進数で「5バイト」あるよ！という荷札
Hello\r\n // 実際のデータ（5バイト）

7\r\n // 「7バイト」あるよ！
World!\r\n // 実際のデータ（7バイト）

0\r\n // 「0」が来たら、もう終わり！
\r\n // 最後に空行を添えて終了

※ `\r\n` は改行コードです。サーバーはこのルールに従って、淡々と「サイズ→データ」のペアを送り続けます。最後に`0`を送ることで、ブラウザ（受け取り側）は「あ、これ以上待たなくていいんだな」と判断して画面を描画するわけですね。

—

一見するとただの小分けですが、ネットワークエンジニアの視点で見ると、これは革命的でした。

—

現場でトラブルシューティングをする際、`Transfer-Encoding: chunked` が絡むと少し難しく感じるかもしれません。特に注意すべきは以下の2点です。

Content-Lengthとの併用禁止: 「サイズを自分で決める（Content-Length）」と「小分けにする（Chunked）」を同時に使うことはできません。どちらか一方だけです！
プロキシサーバーの存在: 途中に挟まるプロキシやロードバランサーが、このチャンク構造を正しく解釈できないと、通信が途中で切断されてしまうことがあります。現場で「データが途中で消える」という相談を受けたら、まずは「チャンク転送が正しく処理されているか？」を疑うのが定石です。

—

『Transfer-Encoding: chunked』は、Webという巨大な物流システムを支える「柔軟な配送スタイル」です。

最初からパケットの中身をすべて完璧に理解する必要はありません。「送り手はサイズを書いて小分けにし、0が来たら終わりと決めている」。まずはこの大きな流れをイメージするだけで、デバッグの際に見える景色がガラリと変わるはずです。

ネットワークの世界は、こうした「ちょっとした工夫」の積み重ねでできています。皆さんもぜひ、ブラウザのデベロッパーツールを開いて、ネットワークタブから「Chunked」の挙動を眺めてみてください。普段見ているWebサイトが、また違った顔を見せてくれるかもしれませんよ。