ネットワーク経由でパケットを送信する前に、パケットを圧縮するために使用する最適な圧縮アルゴリズムは何ですか? パケットは JSON を使用してエンコードされます。LZWはこれに適していますか、それとももっと良いものがありますか?
7 に答える
私は2つの質問があなたの答えに影響を与えると思います:
1)プログラムの特定の実行で何が起こるかを知らなくても、データの構成をどれだけうまく予測できますか?たとえば、パケットが次のようになっている場合:
{
"vector": {
"latitude": 16,
"longitude": 18,
"altitude": 20
},
"vector": {
"latitude": -8,
"longitude": 13,
"altitude": -5
},
[... et cetera ...]
}
-次に、データに表示され続けるテキスト文字列のハードコードされた辞書を作成し、テキスト文字列の各出現箇所を適切な辞書インデックスに置き換えることで、おそらく最高の圧縮が得られます。(実際、データがこれほど定期的である場合は、値だけをネットワーク経由で送信し、JSONオブジェクトが必要な場合は、値からJSONオブジェクトを構築する関数をクライアントに書き込むだけです。)
使用されるヘッダーを予測できない場合は、LZW、LZ77、またはすでに通過したデータを調べて、特にコンパクトな形式で表現できるデータを見つける別の方法を使用する必要があります。でも...
2)パケットは互いに別々に圧縮する必要がありますか?もしそうなら、LZWは間違いなくあなたが望む方法ではありません。単一のパケットの終わりまでに実質的な圧縮結果が得られるサイズまで辞書を構築する時間はありません。このシナリオで実際に大幅な圧縮が行われる唯一のチャンスであるIMHOは、ハードコードされた辞書を使用することです。
(上記のすべての補遺:Michael Kohneが指摘しているように、JSONを送信すると、おそらくすべてのテキストが送信されます。つまり、使用しているよりもはるかに広い範囲の文字を送信できる帯域幅を十分に活用していないことを意味します。 。しかし、0から127の範囲にある文字を、値0から255を保持するコンテナーにパックする方法の問題はかなり単純であり、彼らが言うように、「読者のための演習」として残すことができると思います。)
さらに2つのJSON圧縮アルゴリズムがあります。CJsonと HPackHPackは、gzip圧縮に匹敵する非常に優れた機能を果たします。
元の JSON データの圧縮率に関する短いテストは次のとおりです。平均的な JSON データの代表)
zip を除いて、すべてのアーカイバ パラメータはウルトラに設定されました
* cm/ nanozip:
> 4076/72844
[1] 0.05595519
* gzip:
> 6611/72844
[1] 0.09075559
* LZMA / 7zip
> 5864/72844
[1] 0.0805008
* Huffman / zip:
> 7382/72844
[1] 0.1013398
* ?/Arc:
> 4739/72844
[1] 0.06505683
これは、圧縮が非常に高く、有益であることを意味します。JSON データは一般的に高いエントロピーを持っています。ウィキペディアによると
人体実験に基づくシャノンの推定によると、英語のテキストのエントロピー率は、1 文字あたり 1.0 ~ 1.5 ビット[1]、または 1 文字あたり 0.6 ~ 1.3 ビットと低い値です。
多くの場合、JSON データのエントロピーはそれをはるかに上回ります。(ほぼ同じサイズの 10 個の任意の JSON ファイルを使用した実験では、2.36 と計算されました)
うーん...私が間違っている場合は修正してください。ただし、オンザワイヤ圧縮を実装している場合は、接続の両端を制御しますよね? その場合、JSON が太すぎるプロトコルである場合、それほど太くない別のワイヤ プロトコルを選択しないのはなぜでしょうか? つまり、JSON のような標準を使用することの魅力は理解していますが、帯域幅が気になる場合は、すべてがテキストではないワイヤ プロトコルを選択する必要があります。
Web サーバーで圧縮し、ブラウザーでネイティブに解凍します。gzip またはデフレートします。
Gzip (deflate アルゴリズム) は圧縮に優れていますが、すべての優れた圧縮アルゴリズムと同様に、多くの CPU を使用します (私のテストでは、json の読み取り/書き込みのオーバーヘッドの 3 倍から 5 倍)。