なぜHTTP/1.1の「Chunked転送」は、現代のWebでも死なないのか？
こんにちは。ネットワークの現場でパケットを追い続けて20年、ログの海を泳いできたシニアエンジニアです。
今日は、HTTP/1.1の屋台骨とも言える「`Transfer-Encoding: chunked`」について話をしましょう。「今さらHTTP/1.1の話かよ」と思うかもしれません。しかし、HTTP/2やHTTP/3が普及した現在でも、バックエンドのマイクロサービス間通信や、プロキシサーバーを経由する通信において、この「チャンク転送」の挙動を深く理解しているかどうかが、重大な障害の切り分け速度を分けるのです。
特に、動的コンテンツのストリーミングや、コンテンツ長が事前に確定できないAPIレスポンスにおいて、この仕組みは必須です。さあ、パケットレベルの深淵を覗いてみましょう。
—
1. なぜ「チャンク」が必要だったのか？
HTTP/1.0時代、サーバーはレスポンスを送る前に必ず`Content-Length`ヘッダーでサイズを伝える必要がありました。しかし、データベースのクエリ結果や、リアルタイムに生成されるログデータを返すとき、全データが揃うまでメモリに溜め込むのは非効率ですよね。
そこで登場したのが`Transfer-Encoding: chunked`です。これは、「全体サイズは分からないけれど、とりあえず小分け（チャンク）にして送るから、受け取った順から処理してくれ」というプロトコル上の合意です。
チャンク転送のパケット構造
実際の通信では、以下のような形式でデータが流れます。
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
4\r\n # 16進数でチャンクサイズを指定
Wiki\r\n # データ本体
5\r\n # 次のサイズ
pedia\r\n # データ本体
0\r\n # サイズ0は「転送終了」の合図
\r\n # 最終的な空行
重要なのは、「サイズ(16進数) + CRLF + データ + CRLF」というペアを繰り返す点です。最後にサイズが`0`のチャンクが送られてきた時点で、クライアントは「これにて通信終了」と判断します。
—
2. 実務で遭遇する「罠」とデバッグ手法
現場でよくあるのが、プロキシサーバー（Nginx等）やロードバランサーが、このチャンクを勝手にバッファリングしてしまう問題です。
「ストリーミングでレスポンスを返しているはずなのに、全部溜まってから一括で表示される」という相談を受けたら、まず疑うべきはレスポンスバッファリングの設定です。
Nginxでの無効化設定例
Nginxをリバースプロキシとして使う場合、ストリーミングを阻害しないように以下の設定を入れます。
location /api/stream {
proxy_pass http://backend_app;
# レスポンスを溜め込まず、即座にクライアントへ流す設定
proxy_buffering off;
proxy_cache off;
}
—
3. 実装の確認：curlでパケットを覗く
エンジニアとして、仕様書を信じる前に自分の目でパケットを見る習慣をつけましょう。`curl`を使えば、チャンクの区切りを視覚的に確認できます。
-v オプションでヘッダーと通信詳細を確認
curl -v http://your-api.example.com/stream
レスポンスヘッダーに`Transfer-Encoding: chunked`が含まれていることを確認し、レスポンスボディに16進数のサイズ文字が混ざっていないか見てください。もし混ざっていれば、それがチャンクの境界です。
—
4. Pythonで書く：チャンクを生成する側
サーバーサイドでチャンク転送を実装する場合、基本は「ジェネレーター」を使うのが鉄則です。
Flask等でのストリーミング実装イメージ
import time
def generate_data():
# チャンクごとにデータを生成して送出
for i in range(5):
yield f”Chunk number {i}\n”
time.sleep(1)
クライアントへのレスポンス
Transfer-Encoding: chunked はWebフレームワークが自動的に付与してくれる
return Response(generate_data(), mimetype=’text/plain’)
—
最後に：ネットワークエンジニアとしての視点
チャンク転送は、一見すると単なるデータの小分けですが、「通信の終了をContent-Lengthに頼らず、ストリームの終端コードで行う」という点が非常に強力です。
しかし、この構造を理解していないと、Keep-Aliveの挙動と組み合わさった時に「通信がいつまでも終わらない」あるいは「途中で切断される」というトラブルの原因になります。
特に、`0\r\n\r\n`の終了シーケンスが欠落しているレスポンスは、クライアント側で`Incomplete Chunked Encoding`エラーを引き起こします。もしログにこのエラーが出たら、サーバー側の書き込み処理が途中でクラッシュしていないか、あるいは途中でTCPセッションが強制切断されていないかを真っ先に疑ってください。
HTTPの仕様は、ただの「決まり事」ではありません。それは、データが正しく相手に届くための「呼吸の合わせ方」です。ぜひ、日々の開発でパケットの呼吸を感じてみてください。
それでは、また次の現場でお会いしましょう。質問があればいつでもどうぞ。
コメント