Алгоритм сжатия пакетов в кодировке JSON?

StackOverflow https://stackoverflow.com/questions/395505

  •  23-08-2019
  •  | 
  •  

Вопрос

Какой алгоритм сжатия лучше всего использовать для сжатия пакетов перед их отправкой по сети?Пакеты кодируются с использованием JSON.Подойдет ли LZW для этого или есть что-то лучше?

Это было полезно?

Решение

Думаю, на ваш ответ повлияют два вопроса:

1) Насколько хорошо вы можете предсказать состав данных, не зная, что произойдет при каждом конкретном запуске программы?Например, если ваши пакеты выглядят так:

{
    "vector": {
        "latitude": 16,
        "longitude": 18,
        "altitude": 20
    },
    "vector": {
        "latitude": -8,
        "longitude": 13,
        "altitude": -5
    },
    [... et cetera ...]
}

- тогда вы, вероятно, получите наилучшее сжатие, создав жестко закодированный словарь текстовых строк, которые продолжают появляться в ваших данных, и заменив каждое вхождение одной из текстовых строк соответствующим индексом словаря.(На самом деле, если ваши данные были этот обычно, вы, вероятно, захотите отправить только значения по сети и просто напишите в клиенте функцию для создания объекта JSON из значений, если объект JSON необходим.)

Если вы не можете предсказать который будут использоваться заголовки, вам может потребоваться использовать LZW, или LZ77, или другой метод, который просматривает уже прошедшие данные, чтобы найти данные, которые они могут выразить в особенно компактной форме.Однако...

2) Нужно ли сжимать пакеты отдельно друг от друга?Если да, то LZW определенно нет желаемый метод;у него не будет времени построить свой словарь до размера, который обеспечит существенные результаты сжатия к концу одного пакета.ИМХО, единственный шанс получить действительно существенное сжатие в этом сценарии — это использовать жестко закодированный словарь.

(дополнение ко всему вышесказанному:как отмечает Майкл Коне, отправка JSON означает, что вы, вероятно, отправляете весь текст, а это означает, что вы недостаточно используете полосу пропускания, которая позволяет отправлять гораздо более широкий диапазон символов, чем вы используете.Однако проблема упаковки символов, попадающих в диапазон 0–127, в контейнеры, содержащие значения 0–255, довольно проста, и я думаю, что ее можно оставить как «упражнение для читателя», как говорится.)

Другие советы

Есть еще два алгоритма сжатия JSON: СиДжейсон и HPackHPack выполняет очень хорошую работу, сравнимую со сжатием gzip.

Эммм... Поправьте меня, если я ошибаюсь, но если вы реализуете сжатие по сети, то вы контролируете оба конца соединения, верно?В этом случае, если JSON слишком толстый протокол, почему бы вам просто не выбрать другой проводной протокол, который не такой толстый?Я имею в виду, что понимаю привлекательность использования такого стандарта, как JSON, но если вас беспокоит пропускная способность, то вам, вероятно, следует выбрать проводной протокол, который не является полностью текстовым.

Пусть веб-сервер сжимает, а браузер распаковывает самостоятельно;gzip или сдуть.

Вот короткий тест на сжимаемость оригинала данных JSON:Crime-data_geojson.json 72844by (вы можете получить файл здесь: https://github.com/lsauer/Data-Hub .Файл был выбран случайным образом, но не может отражать средние данные 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,0 до 1,5 бит на букву, [1] или всего от 0,6 до 1,3 бита за букву, согласно оценкам Шеннона на основе экспериментов человека

Энтропия данных JSON часто намного превышает это значение.(В эксперименте с 10 произвольными файлами JSON примерно одинакового размера я вычислил 2,36)

Gzip (алгоритм дефляции) довольно хорош при сжатии, хотя, как и все хорошие алгоритмы сжатия, он использует много ресурсов процессора (в 3-5 раз больше, чем накладные расходы на чтение/запись json в моем тестировании).

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top