問題タブ [deflate]

java.util.zip.Deflaterのdeflateメソッドを使用する場合、引数としてbyte []を指定する必要がありますが、そのbyte []はどのくらいの大きさに初期化する必要がありますか？圧縮されたデータが非圧縮のデータよりもさらに小さくなるという保証はないことを読みました。入力の特定の％を使用する必要がありますか？現在、入力の2倍の大きさにしています

Apache サーバー (mod_deflate) で gzip 圧縮を有効にした後、エンド ユーザーが非圧縮の応答よりも平均 200 ミリ秒遅く処理されていることが一貫してわかりました。

これは予想外だったので、テキスト/HTML 応答のみを圧縮するように圧縮ディレクティブを変更し、wireshark を起動して、圧縮前後のネットワーク ダンプを調べました。

これは、ネットワーク内のトラフィックが最小のGETに関する私の観察です。

圧縮前

圧縮後

圧縮が設定された後、ネットワーク上のトランザクション数が非圧縮よりも大幅に少ないことは明らかで理解できます。

ただし、圧縮されたデータ ユニットは、ソースから宛先への転送にはるかに長い時間がかかりました。

圧縮の追加作業には当然時間がかかるようですが、送信された各データが圧縮時に大幅に遅くなった理由を理解できません。

圧縮プロセスに関する私の理解は次のとおりです。

このスキームでは、3番目のステップは（応答の最初のセグメントの前のステップは、圧縮+応答であるため、より長い時間がかかりますが、私が想定した残りのチャンクは平均して等しいと仮定します非圧縮チャンクとしての時間ですが、そうではありません。

誰でも理由を教えてもらえますか...または、このシナリオを分析するためのより良い方法を提案してください。また、誰かが前後の比較を持っていますか...フィードバック/コメント/質問をいただければ幸いです

PHPでZIPファイルを作成するためのクラスを作成しています。サーバーで許可されていないことを前提としたZipArchiveの代替手段。それらの無料サーバーで使用するもの。

これはすでに機能しており、PHPでZIP構造を構築し、gzdeflate（）を使用して圧縮データを生成します。

問題は、gzdeflate（）ではファイル全体をメモリにロードする必要があり、クラスを32MBのメモリに制限して動作させたいということです。現在、16MBを超えるファイルを圧縮せずに保存しています。

データを16MBx16MBのブロックに圧縮する必要があると思いますが、2つのgzdeflate（）の結果を連結する方法がわかりません。

私はそれをテストしてきましたが、最後の16ビットでいくつかの計算が必要なようです、ある種buff->last16bits = (buff->last16bits & newblock->first16bits) | 0xfffe、それは機能しますが、すべてのサンプルに対してではありません...

質問：解凍せずに2つのDEFLATEDストリームを連結するにはどうすればよいですか？

WebコンテンツにDeflateとGZip圧縮を実装しています。.NET Framework DeflateStreamは非常に優れたパフォーマンスを発揮します（SharpZipLibほど圧縮されませんが、はるかに高速です）。残念ながら、それ（および私が知っている他のすべてのライブラリ）は、stream.WritePrecompressed（byte [] buffer）のような事前圧縮されたデータを書き込む関数を見逃しています。

この機能を使用すると、事前に圧縮されたブロックをストリームに挿入できます。これにより、この部分を圧縮するためのCPU負荷が軽減され、Webサーバーの合計スループットが向上する可能性があります。

これを実行できるマネージドライブラリはありますか？または、ComponentAceからZLIB.NETを超えてこれを行うための良い出発点はありますか？

2012 年 2 月 10 日更新:

zOompf は、まさにこのトピックに関する非常に徹底的な調査を完了しました。これは、以下の調査結果よりも優先されます。

2010 年 9 月 11 日更新:

このためのテスト プラットフォームが作成されました。

背景情報については、GZIP および DEFLATE (zlib) の HTTP 1.1 定義を参照してください。

「「Gzip」は gzip 形式で、「deflate」は zlib 形式です。生の deflate 圧縮データ形式との混同を避けるために、おそらく 2 番目のものを「zlib」と呼ぶべきでした。HTTP 1.1 RFC 2616 は正しく「deflate」転送エンコーディングに関する RFC 1950 の zlib 仕様に基づいているため、RFC 1951 の deflate 仕様に従って生の deflate データを誤って生成または予期するサーバーとブラウザの報告があり、最も顕著なのは Microsoft 製品です。 zlib 形式を使用した転送エンコーディングは、より効率的なアプローチになります (実際 、zlib 形式が設計された目的はまさにそれです)。)、「gzip」転送エンコーディングを使用する方が、HTTP 1.1 作成者側の不幸な名前の選択により、おそらくより信頼性が高くなります。" (ソース: http://www.gzip.org/zlib/zlib_faq.html )

それで、私の質問: zlib ラッパー (または gzip など) なしで RAW deflate データを送信した場合、生の deflate を理解できない最新のブラウザー (IE6 以降、FF、Chrome、Safari など) はありますか?圧縮データ (HTTP 要求ヘッダー「Accept-Encoding」に「deflate」が含まれていると仮定)?

Deflate データは常に GZIP よりも数バイト小さくなります。

これらすべてのブラウザーがデータを正常にデコードできる場合、zlib の代わりに RAW deflate を送信することにはどのような欠点がありますか?

2010 年 9 月 11 日更新:

このためのテスト プラットフォームが作成されました。

POSTリクエストフォームデータをGzipで圧縮した場合、HTTPサーバーはそれを解凍しますか、それとも他の方法（サーバー->クライアント）でのみ機能しますか？

誰かが私を悩ませている問題に光を当てることができるのだろうか：

圧縮解凍テストクラスを作成しています。それをテストするために、データセットをメモリストリームにシリアル化し、圧縮し、解凍して結果を比較しています。

圧縮は問題ありませんが、非圧縮はそれが汚れに当たる場所です。これは解凍機能です。

サイズ65536のバッファを使用すると、解凍されたストリームは、圧縮されていない場合よりも常に1バイト少なくなります。

今、これは私が戦っている2番目の問題に私をもたらします。一部のバッファサイズでは、抽出する圧縮データがまだ残っている場合でも、uncompressStream.Readは0を返します。

このような場合、deflateStream.Read（s）はdo {}ループで1回だけ実行され、バッファサイズを1バイト増やすと、バッファサイズに等しい非圧縮ストリームが返されます（欠落しているバイトを除く）。

65536のバッファサイズの出力:(元の非圧縮データは207833です）

189544のbuffersize（コードがタンクに入るいくつかのマジックナンバー）

また、バッファサイズ65536の3番目の読み取りに注意してください。例：bytesRead：[58472]バッファにまだデータが残っているので、明らかにこれも65536である必要がありますか？

どんなアイデアでも大歓迎です。

tia

• ジャコ

apache deflate モジュールを使用して、アプリケーションから送信された Excel スプレッドシートを圧縮しようとしています。サイト対応ファイルに次の行を追加しました。

しかし、応答データを大きくしているようです???

モジュールなしでfirebugを使用して、アプリケーションからxlsスプレッドシートをダウンロードし、100Kbのデータをダウンロードしました。ファイルシステム上のファイルサイズも予想どおり100Kbでした。上記の方法で deflate モジュールを有効にしてプロセスを繰り返したところ、ダウンロードされたデータ量は 295Kb?? でした。しかし、ファイルシステムに保存すると、ファイルはまだ100Kbしかありませんでした。

実験として、保存した xls ファイルを手動で gzip し、20Kb に圧縮しました。

ここで何が間違っていますか？

deflate の使用 (Firebug の出力):

deflate なし (Firebug 出力):

現在、次のコードを使用して、urllib2 で gzip された応答を解凍しています。

収縮した応答も処理しますか、それとも収縮した応答を処理するために別のコードを書く必要がありますか?