HTTPの「終わり」をどう告げるか？Chunked Transfer Encodingが支える動的レスポンスの舞台裏
Web APIを設計し、インフラを運用していると、避けて通れないのが「どれだけのデータが来るかわからない」という状況です。例えば、DBから順次ストリーミングされる検索結果や、生成AIが逐次出力するテキストなど。
HTTP/1.0の頃、クライアントは「レスポンスの終わり」を知るために、サーバーがコネクションを切断するのを待つしかありませんでした。しかし、これでは毎回TCPコネクションを張り直すコストがかかり、現代のWebのスピードには耐えられません。そこで登場したのが、HTTP/1.1の切り札の一つ、Chunked Transfer Encodingです。
今日は、この「断片化された通信」の正体と、現場でパケットを追う際に役立つ実務的な知見を紐解いていきましょう。
—
1. なぜ「サイズ不明」に耐えうるのか：仕組みの核心
通常のレスポンスでは `Content-Length` ヘッダーでサイズを明示しますが、動的に生成されるデータにはこれが使えません。そこで導入されたのが、データを複数の「チャンク（塊）」に分割し、それぞれにサイズ情報を付与して送る手法です。
通信のシーケンス
サーバーから送られてくるデータの流れは、以下のようになります。
1. ヘッダー: `Transfer-Encoding: chunked` を送信。
2. チャンクの連続: `[サイズ(16進数)]\r\n[データ]\r\n` という形式で送られる。
3. 終端の合図: `0\r\n\r\n` という空のチャンク（サイズ0）を送ることで、「これですべて完了」と伝える。
この「0チャンク」こそが、コネクションを維持したままメッセージの終了を告げるための重要なシグナルです。
—
2. 実務で役立つデバッグと検証手法
机上の空論で終わらせないために、手元の環境でその挙動を見てみましょう。
curlで生パケットを覗く
まずは、サーバーがチャンクをどう送っているか、ヘッダー込みで観察するのが一番の近道です。
-v オプションでヘッダーを確認
実際にチャンクが送られているか一目瞭然です
curl -v http://example.com/api/stream
レスポンスヘッダーに `Transfer-Encoding: chunked` があり、ボディが `5\r\nHello\r\n…` のように続いていれば成功です。
Pythonでの受信処理（requestsライブラリ）
API開発者がよくやるミスが、チャンクデータを一括で読み込もうとしてメモリを食いつぶすことです。ストリーミングとして処理するなら、こう書きます。
import requests
url = “http://example.com/api/stream”
with requests.get(url, stream=True) as r:
# チャンクごとに処理することで、巨大なデータも安全に扱える
for chunk in r.iter_content(chunk_size=1024):
if chunk:
print(f”受信データサイズ: {len(chunk)} bytes”)
—
3. インフラエンジニアが知るべき「落とし穴」
現場のトラブルシューティングにおいて、この仕様が原因となる「ハマりどころ」がいくつかあります。
Proxyやロードバランサーの介在
最も多いのが、途中のNginxやロードバランサーがチャンクを「バッファリング」してしまうケースです。
- 症状: サーバーはストリーミングしているはずなのに、クライアントには一気にデータが届く（タイムラグが発生する）。
- 対策: Nginxの場合、`proxy_buffering off;` を設定して、バッファリングを無効化する必要があります。
Nginxの設定例：ストリーミングAPIを通す際の定石
location /api/ {
proxy_pass http://backend_upstream;
proxy_buffering off; # これを忘れるとChunkedの恩恵が台無しになる
proxy_http_version 1.1; # HTTP/1.1を強制する
}
Content-Lengthとの競合
RFC 7230において、`Transfer-Encoding` と `Content-Length` は共存できません。どちらかが優先されたり、あるいは両方あることでサーバーが混乱して「不正なリクエスト」とみなすケースがあります。設計時には、「チャンクを使うならContent-Lengthは絶対に書かない」と心に刻んでください。
—
最後に：ネットワークを俯瞰する視点
Chunked Transfer Encodingは、単なるデータの小分けではありません。「待機時間」を減らし、リアルタイム性を担保するための非常に洗練されたプロトコル設計です。
もし運用中に「レスポンスが途中で切れる」という相談を受けたら、まずは「0チャンク（終端）が正しく届いているか」をパケットキャプチャで確認してみてください。多くのケースで、中継ノードによるバッファリングや、タイムアウト設定が原因であることがわかります。
通信の「終わり」を正しく定義すること。それは、安定したAPIを作るための第一歩です。今日の知識が、あなたの現場でのトラブル解決に役立つことを願っています。
コメント