巨大な荷物をどう届ける？HTTP/1.1「チャンク転送」の知恵
Webサイトを見ているとき、私たちは「パッとページが表示される」ことを当たり前だと思っていますよね。でも、サーバーがそのページを準備している最中、裏側ではどんなやり取りが行われているか、想像したことはありますか？
今日は、HTTP/1.1というプロトコルの影の立役者、「Chunked Transfer Encoding（チャンク転送）」についてお話しします。これがわかると、ネットワーク越しにデータがどう流れているのか、その「リアルな動き」が手に取るようにわかるようになりますよ。
—
そもそも、なんで「分割」が必要なの？
Webサーバーがブラウザにデータを送るとき、基本的には「このファイルは全部で100KBです」という情報を最初に伝えます。これを「Content-Length」と呼ぶのですが、これは受取人であるブラウザにとって非常に親切な情報です。
しかし、世の中には「大きさが事前にわからないデータ」が溢れています。
- リアルタイムで生成される株価のグラフ
- データベースから次々と検索結果を引っ張ってくるリスト
- ログをリアルタイムで垂れ流す管理画面
これらは、「全部で何KBになるか」を最後まで計算し終えないと送信を開始できない……なんてことになると、ユーザーは画面の前で真っ白なページを眺め続けることになりますよね。
そこで登場するのが、「とりあえずできた分から小分けにして送っちゃえ！」という作戦、それが「Chunked（チャンク＝塊）」転送です。
—
郵便配達で例えると？
巨大な荷物を送る場面を想像してください。
1. 通常（Content-Length）: 荷物を全部箱詰めして、重さを測ってから「重さ○kg」と伝票に書き、発送する。
2. チャンク転送: 箱の大きさを決めずに、「小分けにした袋」を一つずつ、紐でつないでどんどん配達員に渡していく。
配達員（ブラウザ）は、袋が届くたびに中身を取り出して、Webページに反映していきます。では、いつ配達が終わるのか？ それを知らせるのが、最後に送られる「空っぽの袋（0チャンク）」なんです。
—
実際に流れている「中身」を見てみよう
ネットワークの裏側では、具体的にどんな信号が流れているのでしょうか。少しだけ、HTTPの「生データ」を覗いてみましょう。
HTTP/1.1 200 OK
Transfer-Encoding: chunked // 「今から分割して送るよ！」という宣言
5 // 5バイト分送るよ
Hello
3 // 3バイト分送るよ
Web
0 // 0バイト＝「これで終わり！」という合図
// （最後に空行を入れて終了）
見ての通り、非常にシンプルです。「16進数でサイズを伝え、その後にデータ本体を送り、最後に0を送る」。これだけで、サーバーは「全部揃うのを待たずに」送信を開始できるわけです。
—
なぜこれが重要なのか？
この仕組みを知っておくと、トラブルシューティングの際に「勘」が働くようになります。
例えば、ブラウザでページを表示したときに「途中でプツンと切れる」ような現象が起きたとします。もしこれがチャンク転送を使っているサイトなら、「最後の0チャンクが届いていないのではないか？」という推測が即座に立ちますよね。
- 中継しているプロキシサーバーが、途中で接続を切ってしまっていないか？
- サーバーの処理がタイムアウトして、0を送る前に死んでいないか？
このように、通信の「始まり」と「終わり」のルールを知っているだけで、ネットワークエンジニアとしての視界がグッと広がるのです。
—
まとめ：ネットワークは「流れ」を意識する
HTTP/1.1のチャンク転送は、一見すると地味なルールですが、「ユーザーを待たせないための究極の工夫」です。
1. サイズが不明でも転送可能にする。
2. 小分けにして、できた端から送る。
3. 「0」という合図で「終わり」を告げる。
この「小分けの知恵」は、現代のストリーミング配信や、マイクロサービス間の通信など、あらゆるところで応用されています。
最初は難しく感じるパケットのやり取りも、こうして「郵便配達」のように例えると、ぐっと身近に感じられるはずです。これからも、データという名の「荷物」がネットワークという道をどう駆け巡っているのか、一緒に紐解いていきましょうね。
次回は、この「チャンク転送」が、より高度なキャッシュやプロキシとぶつかった時に何が起きるのか……そんな少し深掘りした現場の話もできればと思います。それでは、また！
コメント