皆さん、こんにちは！ネットワークの深淵を覗き込む探検家、〇〇（←著者名が入る想定）です。
Webブラウザを開けば、瞬く間に記事が読めたり、動画が途切れることなく再生されたり…当たり前のように享受しているこの体験、実はネットワークの裏側で、様々な「おもてなし」の工夫が凝らされているのをご存知でしたか？
今日はその中でも、特にHTTP/1.1というバージョンのHTTPプロトコルで大活躍している「Transfer-Encoding: chunked（チャンク転送）」という、ちょっと聞き慣れないけれど、とっても賢い仕組みについて、皆さんと一緒に紐解いていきたいと思います。
「チャンク転送？ 何それ、難しそう…」と思ったあなた、大丈夫です！郵便配達や身近な例え話を使って、パケットがWebを駆け巡る様子を、一つずつ丁寧に見ていきましょう。
—
Webページの「重さ」って、どうやって決まるの？ HTTP/1.0の悩み
まずは、チャンク転送がなぜ必要になったのか、その背景からお話ししましょう。
私たちがWebサイトにアクセスするとき、ブラウザはWebサーバーに「このページを見せてください！」とリクエストを送りますよね。するとサーバーは、そのページのHTMLや画像、CSSなどのデータをまとめてブラウザに送り返します。
HTTP/1.0という、ちょっと前のバージョンのHTTPプロトコルでは、サーバーはクライアント（ブラウザ）にデータを送る前に、「このデータは全部で〇〇バイトですよ！」というデータの全長（Content-Length）を、まず最初に伝えなければいけませんでした。
例えるなら、こんな感じです。
「配達員さん、この荷物を届けてください！」と依頼された郵便局員さんが、まず最初に、荷物の重さをきっちり量って「はい、この荷物はピッタリ1.5kgです！」と確認してからじゃないと、配達に出発できなかった…そんなイメージですね。
事前に重さが分からないと困る！
でも、ちょっと考えてみてください。私たちがWeb上で目にするコンテンツって、常に決まったサイズのものばかりでしょうか？
- リアルタイムで更新されるニュースフィード
- 大量の検索結果がデータベースから動的に生成されるページ
- チャットのメッセージのように、いつ終わるか分からないストリーミングデータ
これらは、サーバーがデータを全部作り終えてみないと、最終的なデータ量がどれくらいになるのか分かりません。
先ほどの郵便局員さんの例で言えば、荷物を梱包している最中に「あれ、まだ荷物が増えそうだぞ…」という状況なのに、「先に重さを言ってください！」と言われているようなものです。これでは、いつまで経っても配達に出発できませんよね。
この「データの全長を事前に知らなければならない」という制約が、HTTP/1.0の大きな課題でした。
HTTP/1.1の魔法！ 「Transfer-Encoding: chunked」の登場
そこで登場したのが、HTTP/1.1で導入された賢い仕組み、「Transfer-Encoding: chunked」です！
この仕組みは、先ほどの課題を見事に解決してくれました。
「データの全長を事前に知らなくても、小分けにして、準備ができたものから順に送り出していいよ！」
という、画期的な方法なのです。
配達員さんの例で言えば、こう変わりました。
「配達員さん、この荷物、まだ全部揃ってないんですけど、できた分から小分けにした段ボールに入れて送っちゃってください！全部送ったら、『これで終わり！』って書いた空っぽの箱を送りますから！」
これなら、郵便局員さんは、全部の荷物が揃うのを待つ必要はありません。できた分からどんどん送り出せますし、受け取る側も、届いた分からすぐに処理を開始できますよね。
これが、Webの世界で「ストリーミング転送」と呼ばれる、非常に効率的なデータのやり取りを可能にしたのです。
—
チャンク転送の仕組みを覗いてみよう！
では、具体的に「小分けにする」ってどういうことなのか、もう少し詳しく見ていきましょう。
チャンク転送では、サーバーから送られるデータは、いくつかの「チャンク（chunk）」と呼ばれる小さな塊に分割されます。
それぞれのチャンクは、以下のシンプルな構造を持っています。
1. チャンクサイズ（Chunk Size）：そのチャンクに含まれるデータのバイト数。
- 郵便配達の例えで言えば、「この段ボール箱にはリンゴが5個入ってますよ！」というメモ書きですね。
- このサイズは、ちょっとだけ特殊な「16進数」という形式で書かれますが、今は「データの長さを示しているんだな」くらいに思っていただければOKです。
2. データ本体（Chunk Data）：実際のコンテンツデータ。
- 先ほどの例の「リンゴ」そのものです。
3. 改行コード（CRLF）：各部分の区切りを示します。
そして、最も重要なのが、データの終端を示す「0チャンク」の存在です。
データの終端を示す「0チャンク」
サーバーがすべてのチャンクを送り終えたら、最後に必ず「0」というチャンクサイズを持つ、中身が空っぽのチャンクを送ります。
これは「もうこれ以上、送るデータはありませんよ！」という合図になります。
配達員さんの例で言えば、「これで全部です！」と書かれた、空っぽの段ボール箱を送るようなものです。受け取った側は、この空の箱を見れば「ああ、これで荷物はすべて届いたな」と安心して、荷物を受け取る作業を完了できるわけです。
この「0チャンク」があるおかげで、クライアント（ブラウザ）は、サーバーがいつデータの送信を終えるのかを正確に判断し、次の処理に移ることができるのです。
実際のデータの流れ（イメージ）
では、実際のHTTPレスポンスではどのように見えるのか、簡単な例で見てみましょう。
HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Transfer-Encoding: chunked <-- これがチャンク転送の合図！
7 <-- 1番目のチャンクサイズ (16進数で7 = 10進数で7バイト)
こんにちは <-- 1番目のデータ本体 (7バイト)
0a <-- 2番目のチャンクサイズ (16進数でa = 10進数で10バイト)
Webの世界へ！ <-- 2番目のデータ本体 (10バイト)
0 <-- 終端を示す0チャンク
<-- 最後の空行 (終端を示すメタデータやトレーラーがなければこれで終わり)
いかがでしょうか？
サーバーはまず「`Transfer-Encoding: chunked`」というヘッダーを付けて、「これから小分けに送るよ！」とブラウザに伝えます。
その後、
1. 「7バイトのデータが来るよ！」→「こんにちは」
2. 「10バイトのデータが来るよ！」→「Webの世界へ！」
3. 「もうデータは終わりだよ！」→空のチャンク
という流れでデータを送っています。ブラウザはこれを受け取ると、「こんにちはWebの世界へ！」と結合して表示してくれるわけです。
---
チャンク転送のココがすごい！ メリットを再確認
チャンク転送の仕組みが分かったところで、この方法がWebの世界にどんな素晴らしいメリットをもたらしたのか、改めて整理してみましょう。
1. 動的コンテンツの即時表示！ ストリーミング体験の実現
これが最も大きなメリットです。
サーバーは、すべてのコンテンツが生成されるのを待つ必要がありません。データベースからデータが一件ずつ取得されるたびに、あるいは計算結果が一部出ただけでも、すぐにクライアントに送り始めることができます。
例：
- 巨大なCSVファイルをダウンロードする際、サーバーが全ファイルをメモリに読み込んでから送るのではなく、生成できた部分から順に送れる。
- ライブチャットやライブストリーミングなど、リアルタイム性の高いコンテンツで、データが生成され次第すぐにユーザーに届けられる。
- ブラウザが、HTMLの最初の部分を受け取っただけで、ページのレンダリング（描画）を開始できるため、ユーザーは「真っ白な画面」を長時間見つめることなく、すぐにコンテンツの一部を目にすることができます。
2. メモリ効率の向上！ サーバーもクライアントもハッピー
もし巨大なファイルを転送する際に、サーバーがそのファイル全体をメモリに保持してから送信し、クライアントも全体をメモリに受け取ってから処理を始める、という方式だったらどうなるでしょう？
サーバーもクライアントも、莫大なメモリを消費することになり、特に大量アクセスがあるWebサービスでは、すぐにサーバーがパンクしてしまいます。
チャンク転送なら、データを小分けに処理できるため、サーバーもクライアントも、常に必要なチャンク分のメモリだけを確保すればよく、メモリ消費量を大幅に抑えることができます。
これにより、より多くのユーザーを同時にさばけるようになり、私たちのWeb体験が快適になるわけです。
3. タイムアウトの回避！ 長時間かかる処理も安心
Webサーバーには、「一定時間データが送られてこないと接続を切断する（タイムアウト）」という設定がよくあります。これは、悪意のあるユーザーや、応答しないサーバーからリソースを保護するための重要な機能です。
しかし、もしデータベースの検索に時間がかかったり、複雑な計算が必要なコンテンツだったりした場合、データが一切送られてこない時間が長く続くと、サーバーやプロキシによって接続が切られてしまう可能性があります。
チャンク転送を使えば、たとえ処理に時間がかかっても、途中で小さなチャンクを少しずつ送ることで、接続をアクティブな状態に保ち、「まだ生きてますよ！」というサインを送り続けることができます。これにより、タイムアウトによる不意な接続切断を防ぐことができるのです。
—
どんなところで使われているの？
私たちが普段使っているWebサービスでは、このチャンク転送が当たり前のように活用されています。
- 大手ニュースサイトのリアルタイム更新: ニュース記事が投稿されたり、速報が入ったりすると、すぐに画面に反映されるのは、チャンク転送のようなストリーミング技術のおかげです。
- Web API: サーバー側でデータ処理に時間がかかるAPIレスポンスでも、チャンク転送を使うことで、レスポンスを早く返し始めることができます。
- 動画ストリーミングサービス: YouTubeやNetflixのようなサービスも、動画全体をダウンロードしてから再生するのではなく、チャンク転送のように少しずつデータを送りながら再生することで、スムーズな視聴体験を提供しています。
- サーバーサイドイベント (SSE): サーバーからクライアントへ一方的にデータをプッシュし続けるようなリアルタイム通信でも、チャンク転送の考え方が基礎になっています。
普段意識することはないかもしれませんが、Webの快適さを支える、まさに縁の下の力持ちのような技術なんですね。
—
まとめ：Webを支える「Transfer-Encoding: chunked」
今日は、HTTP/1.1の非常に賢い仕組み、「Transfer-Encoding: chunked」について見てきました。
- HTTP/1.0までは、データの全長を事前に知る必要があり、動的なコンテンツ転送に課題があった。
- チャンク転送は、データを「チャンク」と呼ばれる小さな塊に分割し、準備できたものから順に送ることでこの課題を解決した。
- 各チャンクは「チャンクサイズ」と「データ本体」で構成され、最後に「0チャンク」を送ることでデータの終端を示す。
- この仕組みにより、動的コンテンツの即時表示、メモリ効率の向上、タイムアウトの回避といった、現代のWebに不可欠なメリットがもたらされた。
まるで、配達員さんが荷物の重さを気にせず、できた分からどんどん届けてくれるようになった郵便サービスのように、チャンク転送はWebの効率と快適さを飛躍的に向上させました。
この知識が、皆さんがWebの裏側を理解し、より深くネットワークの世界を楽しむための一助となれば幸いです。
次回は、また別のWebの秘密を探しに行きましょう！それでは！
コメント