「データがいつ終わるか分からない」を解決する：Transfer-Encoding: chunked の深淵
ネットワークエンジニアとして現場に立っていると、時に「正解」よりも「泥臭い仕様」と向き合う時間の方が長くなるものだ。HTTP/1.1の標準機能である `Transfer-Encoding: chunked` は、まさにその代表例と言える。
「コンテンツ長が事前に分からないなら、とりあえず小分けにして投げ続け、最後に『終わったよ』と合図を送ればいいじゃないか」
一見すると乱暴なこの仕組みが、なぜWebの黄金期を支え、現代のAPI設計においても避けて通れないのか。今日は、パケットレベルの挙動から実装の勘所まで、現場の視点で紐解いていこう。
—
なぜ「Content-Length」ではダメなのか
Webサーバがレスポンスを返すとき、理想は `Content-Length: 1024` のように、ボディのサイズを事前にヘッダーで伝えることだ。クライアントはこれを見て、「お、1KB受信すればいいんだな」と準備できる。
しかし、現実はそう甘くない。
- 動的生成: DBからストリーミングでデータを流し込む場合、最終的なサイズは生成が終わるまで分からない。
- 負荷分散: プロキシサーバーがデータを加工しつつ転送する場合、一度メモリに全データをバッファリングするのはメモリ資源の無駄だ。
そこで登場するのが `Transfer-Encoding: chunked` だ。「全体のサイズは教えない。その代わり、断片（チャンク）単位で送るから、受け取った分から処理してくれ」というプロトコル上の知恵である。
—
チャンク転送の「文法」を解剖する
チャンク転送の通信シーケンスは、極めてシンプルかつ厳格だ。データは以下の形式で送られる。
1. チャンクサイズ (16進数): この塊が何バイトかを示す。
2. CRLF: 区切り文字。
3. チャンク本体: 指定したバイト数のデータ。
4. CRLF: 次のチャンクへの繋ぎ。
これを繰り返したのち、最後に `0` というサイズと `CRLF` を送ることで、「これにて通信終了」と宣言する。これが終端チャンク (0-chunk) だ。
実際のパケット構成（イメージ）
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
5\r\n # 16進数で5バイト
Hello\r\n # データ本体
6\r\n # 16進数で6バイト
World\r\n # データ本体
0\r\n # 0バイトで終了を通知
\r\n # 最後に空行を入れて完了
—
実装とデバッグ：現場で使えるTIPS
理論だけでは現場のトラブルは防げない。ここでは、実際にチャンク転送を扱う際のコードとデバッグ術を紹介する。
1. curl で挙動を可視化する
まずは、相手のサーバーがチャンク転送で返してきているかを確認しよう。`-v` オプションをつけてヘッダーを確認するのが鉄則だ。
-v でヘッダーを確認し、データの中身を覗く
curl -v http://example.com/api/stream
レスポンスヘッダーに `Transfer-Encoding: chunked` があり、`Content-Length` が存在しなければ、チャンク転送が正常に機能している証拠だ。
2. Pythonでの送信側実装（簡易例）
サーバー側で動的にデータを生成する場合、以下のように記述する。
import time
def generate_chunks():
# チャンク形式で送信するためのジェネレーター
data = [“接続完了\n”, “処理中…\n”, “完了！\n”]
for chunk in data:
# サイズを16進数に変換して、チャンク形式で出力
size = hex(len(chunk.encode(‘utf-8’)))[2:]
print(f”{size}\r\n{chunk}\r\n”)
time.sleep(1)
print(“0\r\n\r\n”) # 終端チャンク
実際の通信路にはこのストリームを流し込む
3. 注意点：プロキシとKeep-Alive
現場でよく遭遇するハマりポイントが「プロキシによるバッファリング」だ。
NginxやHAProxyなどのリバースプロキシを通す際、設定によってはレスポンス全体をバッファに貯め込んでからクライアントに送ってしまうものがある。これでは「リアルタイム性」というチャンク転送の恩恵が台無しだ。
Nginxでチャンク転送をバッファリングさせない設定例
proxy_buffering off;
proxy_request_buffering off;
この設定を忘れると、APIのストリーミングレスポンスが「一気に届く」という怪奇現象が発生する。トラブルシューティングの際は、まずプロキシがバッファリングしていないかを疑うのが定石だ。
—
最後に：なぜ今、この技術を知るべきか
HTTP/2やHTTP/3が普及した現在でも、バックエンドのマイクロサービス間通信や、プロキシサーバーの内部処理では、依然としてHTTP/1.1のチャンク転送が現役だ。
「なぜデータが途切れるのか？」「なぜプロキシを通すとレスポンスが遅延するのか？」
これらの問いに対する答えの多くは、この16進数で書かれた「チャンクのサイズ表記」の中に隠されている。プロトコルの基本に立ち返る力こそが、複雑なクラウドインフラを制御するための最強の武器になるはずだ。
明日、通信が詰まったら。ぜひ `tcpdump` や `Wireshark` で、その `0\r\n` を探し出してほしい。そこには、ネットワークの生きた呼吸が感じられるはずだ。
コメント