HTTP Chunked transfer encodingの各チャンクサイズの決定方法は?

Question

HTTP Chunked transfer encodingの各チャンクサイズは、どのように決定されるのでしょうか?
各サイトの例示を見る限り、チャンクサイズに上限は無く、適当に決めても問題ないようですが…

Answer 1

参考URL: Content-Length header V.S. chunked encoding

【静的なコンテンツ】
【動的に生成されるサイズの小さなコンテンツ】

Content-Length: xxx の計算が容易なため、（TCPレベルで見たときの）通信が1回で済むこちらを使うべきでしょう。 Transfer-Encoding: Chunked の出る幕はありません。

【動的に生成されるサイズの大きなコンテンツ】
【無限に流れるストリーミングコンテンツ】

サイズが大きい場合、全ての生成が終わるまで待っていては効率が悪いです。また、無限なストリーミングでは永遠に終わらないため、逐次 Transfer-Encoding: Chunked で返していくしかありません。

例えばTwitterのストリーミングAPIは、(無圧縮の場合は) 1チャンクあたり1イベント/1ツイート/1リスト というキリのいい分割が為されています。意味のまとまり に着目する場合はこのように特に迷うことは何も無いでしょう。

問題となる例は、ニコ生配信などのケースですよね。こういうメディアデータなどは一概にどこかで分割出来る訳でもなく、サーバ側・クライアント側・通信回線のあらゆる要素に影響されてくると思います。これに関しては自分もまだ勉強中の身なので、直球の回答をすることは出来ません、すいません…

Comments

[ngyuki]

最近だと Server-Sent Events も「無限に流れるストリーミング」なので Chunked だったと思います

[sounisi5011]

何となく、Content-LengthよりもHTTP Chunked transfer encodingのほうが最適と思い込んでいましたが、実際は特殊な用途で利用するべき仕様なのですね。
携帯電話でも非対応の環境が存在することを考えると、利用するべきではないかもしれません。

http://tilfin.hatenablog.com/entry/20080723/1216791007

ありがとうございます、また新しい知識を得ることが出来ました。