Думаю, на ваш ответ повлияют два вопроса:
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, довольно проста, и я думаю, что ее можно оставить как «упражнение для читателя», как они говорят .)