Content-Length ヘッダーとチャンク エンコーディング

Question

を設定するメリットとデメリットを比較検討しています。 Content-Length HTTP ヘッダーと、サーバーから [おそらく] 大きなファイルを返すチャンク エンコーディングの使用。永続的な接続を使用して HTTP 1.1 仕様に準拠するには、どちらか一方が必要です。の利点が分かりました Content-Length ヘッダーは次のとおりです:

• ダウンロード ダイアログに正確な進行状況バーを表示できる
• クライアントは、ファイルが取り込むには大きすぎるかどうかを事前に認識します。

欠点は、オブジェクトを返す前にサイズを計算する必要があることですが、これは必ずしも実用的ではなく、サーバー/データベースの使用率が増加する可能性があります。チャンク エンコーディングの欠点は、各チャンクとダウンロードの進行状況バーの前にチャンク サイズを追加する際のオーバーヘッドが小さいことです。何かご意見は？両方の方法について、私が思いつかなかった他の HTTP の考慮事項はありますか?

Answer 1

必ず Content-Length を使用してください。これによるサーバー使用率はほとんどなくなり、ユーザーにとってのメリットは大きくなります。

動的コンテンツの場合、圧縮応答サポートを追加するのも非常に簡単です (gzip）。これには出力バッファリングが必要であり、これによってコンテンツの長さが決まります。(ファイルのダウンロードや、すでに圧縮されたコンテンツ (音声、画像) の場合は実用的ではありません)。

のサポートの追加も検討してください。 部分的なコンテンツ/byte-range サービング - つまり、ダウンロードを再開する機能。 バイト範囲の例については、ここを参照してください。 (例は PHP で示されていますが、どの言語にも適用できます)。部分的なコンテンツを提供する場合は、Content-Length が必要です。

もちろん、これらは特効薬ではありません。ストリーミング メディアの場合、出力バッファリングや応答サイズを使用するのは無意味です。大きなファイルの場合、出力バッファリングは意味がありませんが、Content-Length とバイト サービングには非常に意味があります (失敗したダウンロードを再開することは可能です)。

個人的には、Content-Length がわかったときはいつでもそれを提供します。ファイルのダウンロードの場合、ファイルサイズを確認することはリソースの観点からは重要ではありません。結果：ユーザーには明確な進行状況バーが表示されます (また、gzip のおかげで動的ページのダウンロードが高速になります)。

Answer 2

コンテンツ長が事前にわかっている場合は、

、その後、私は確かにチャンクで送信する上で、それを好むだろう。ローカルディスクのファイルシステムで、またはデータベース内の静的ファイルの手段がある場合は、任意の自己尊敬のプログラミング言語とRDBMSは、事前にコンテンツの長さを取得する方法を提供します。あなたはそれを利用する必要があります。

コンテンツ長が事前に本当に予測不可能である場合は、

一方、（例えば、あなたの目的は一緒にいくつかのファイルを圧縮し、1として、それを送信する場合）、そしてチャンクでそれを送信すると、サーバーのメモリまたは書面でそれをバッファリングよりも速いかもしれ最初のローカルディスクのファイルシステムに。しかし、この実際に影響を受けるのは、ユーザーエクスペリエンスがマイナスのダウンロードの進行状況が不明であるため。せっかちは、ダウンロードを中止して沿って移動してもよい。

コンテンツの長さを知ることの別の利点は、予めダウンロードを再開することができることです。私はあなたのメインのプログラミング言語は、Javaであなたのポストの歴史の中で見ます。あなたは見つけることができますをrel="noreferrer">それを行い、Javaサーブレットの例。

Answer 3

コンテンツの長さ

の Content-Length ヘッダーはリクエスト/レスポンスボディのバイト長を決定します。指定を怠ると、 Content-Length ヘッダーに、HTTP サーバーが暗黙的に追加します。 Transfer-Encoding: chunked ヘッダ。の Content-Length そして Transfer-Encoding ヘッダーを一緒に使用しないでください。受信側では本体の長さが分からず、ダウンロードの完了時間を推定することもできません。を追加する場合は、 Content-Length ヘッダーが本文全体とバイト単位で一致していることを確認してください。ヘッダーが正しくない場合、受信者の動作は未定義です。

の Content-Length ヘッダーではストリーミングは許可されませんが、部分的なコンテンツの提供をサポートしたい大きなバイナリ ファイルの場合に便利です。これは基本的に、再開可能なダウンロード、一時停止されたダウンロード、部分的なダウンロード、およびマルチホーム ダウンロードを意味します。これには、と呼ばれる追加ヘッダーを使用する必要があります。 Range. 。このテクニックはと呼ばれます バイトサービング.

転送エンコーディング

の用法 Transfer-Encoding: chunked これにより、単一のリクエストまたはレスポンス内でストリーミングが可能になります。これは、データがチャンク化された方法で送信され、コンテンツの表現に影響を与えないことを意味します。

公式には、HTTP クライアントは次のようなリクエストを送信することを目的としています。 TE クライアントが受け入れる転送エンコーディングの種類を指定するヘッダー フィールド。これは常に送信されるわけではありませんが、ほとんどのサーバーはクライアントが処理できると想定しています。 chunked エンコーディング。

の chunked 転送エンコーディングは、HTTP 1.1 がデフォルトで true であると想定している永続的な TCP 接続を有効に活用します。

コンテンツエンコーディング

チャンク化されたデータまたは非チャンク化されたデータを圧縮することも可能です。これは実際には次の方法で行われます。 Content-Encoding ヘッダ。

注意してください。 Content-Length 後の体の長さに等しい Content-Encoding. 。これは、応答を gzip 圧縮した場合、圧縮後に長さの計算が行われることを意味します。長さを計算したい場合は、ボディ全体をメモリにロードできる必要があります (その情報が他の場所にない場合)。

チャンク エンコーディングを使用してストリーミングする場合、圧縮アルゴリズムはオンライン処理もサポートする必要があります。ありがたいことに、gzip はストリーム圧縮をサポートしています。コンテンツは最初に圧縮され、その後チャンクに分割されると思います。このようにして、チャンクが受信され、解凍されて実際のコンテンツが取得されます。逆の場合は、圧縮されたストリームを取得し、解凍するとチャンクが得られます。それは意味がありません。

一般的な圧縮ストリーム応答には次のヘッダーが含まれる場合があります。

Content-Type: text/html
Content-Encoding: gzip
Transfer-Encoding: chunked

意味的には、 Content-Encoding これは、最終クライアントまたは最終サーバーのみがコンテンツをデコードすることになることを意味します。中間のプロキシはコンテンツをデコードすることを想定していません。

中間のプロキシがコンテンツをデコードできるようにしたい場合、使用する正しいヘッダーは実際には Transfer-Encoding ヘッダ。HTTP リクエストが TE: gzip chunked ヘッダーがある場合、次のように応答するのは合法です Transfer-Encoding: gzip chunked.

ただし、これがサポートされることはほとんどありません。したがって、使用する必要があるのは Content-Encoding 今すぐ圧縮してください。

チャンク化 vs ストア&フォワード