¿Cuál sería el mejor algoritmo de compresión para comprimir paquetes antes de enviarlos por cable? Los paquetes están codificados usando JSON. ¿LZW sería bueno para esto o hay algo mejor?Algoritmo de compresión para paquetes codificados JSON?
Creo que dos preguntas afectarán su respuesta:
1) ¿Qué tan bien se puede predecir la composición de los datos sin saber qué va a pasar en cualquier determinada ejecución del programa? Por ejemplo, si los paquetes tienen el siguiente aspecto:
{
"vector": {
"latitude": 16,
"longitude": 18,
"altitude": 20
},
"vector": {
"latitude": -8,
"longitude": 13,
"altitude": -5
},
[... et cetera ...]
}
- entonces probablemente obtener su mejor compresión mediante la creación de un diccionario no modificable de las cadenas de texto que siguen apareciendo en sus datos y reemplazar cada ocurrencia de una de las cadenas de texto con el índice del diccionario apropiado. (En realidad, si sus datos eran este regular, probablemente desee enviar solo los valores a través del cable y simplemente escribir una función en el cliente para construir un objeto JSON a partir de los valores si se necesita un objeto JSON.)
Si no se puede predecir cuales serán utilizados cabeceras, es posible que necesite usar LZW, o LZ77, o cualquier otro método que analiza los datos que ya ha pasado por encontrar los datos que se puede expresar en un especial forma compacta. Sin embargo ...
2) ¿Es necesario comprimir los paquetes por separado? Si es así, entonces LZW es definitivamente no el método que desea; no tendrá tiempo para construir su diccionario hasta un tamaño que proporcione resultados sustanciales de compresión al final de un solo paquete. La única posibilidad de obtener una compresión realmente importante en este escenario, en mi humilde opinión, es utilizar un diccionario codificado.
(Adición a todo lo anterior: como señala Michael Kohne, enviar JSON significa que probablemente está enviando todo el texto, lo que significa que está subutilizando el ancho de banda que tiene la capacidad de enviar una gama mucho más amplia de caracteres Está utilizando. Sin embargo, el problema de cómo empacar los caracteres que caen en el rango 0-127 en contenedores que tienen valores 0-255 es bastante simple y creo que se puede dejar como "un ejercicio para el lector", ya que ej.)
Ummm ... Corrígeme si me equivoco, pero si está implementando la compresión en el cable, entonces usted controla ambos extremos de la conexión, ¿verdad? En ese caso, si JSON es un protocolo demasiado gordo, ¿por qué no elegirías un protocolo de cable diferente que no sea tan grueso? Quiero decir, entiendo el atractivo de utilizar un estándar como JSON, pero si le preocupa el ancho de banda, entonces probablemente debería elegir un protocolo de conexión que no sea todo el texto.
"¿entonces probablemente debería elegir un protocolo de conexión que no sea todo el texto" por ejemplo? (+1 si nombra dos o más ;-) – tobsen
@tobsen [TCP] (http://tools.ietf.org/html/rfc793), [IP] (http://tools.ietf.org/html/ rfc791), [UDP] (http://tools.ietf.org/html/rfc768)? Pero aún así, toda la web usa HTTP desde hace años y nunca tuvo un problema ([SPDY] (http://www.chromium.org/spdy/spdy-whitepaper/) está en proceso). –
Además, con respecto al texto frente al binario ... compare el registro de Windows con el enfoque de Linux de texto completo y dígame qué es más rápido ... El texto no significa lento. –
Deje que el servidor web se comprima y el navegador se descomprima de forma nativa; gzip o desinflar.
No es un servidor web. El cliente es un programa Flash. – ryeguy
Gzip (algoritmo deflate) es bastante bueno en compresión, aunque como todos los buenos algoritmos de compresión, utiliza mucha CPU (3-5x tanto como la sobrecarga de json lectura/escritura en mi prueba).
Hay otros dos algoritmos de compresión JSON: CJson & HPack El HPack hace un muy buen trabajo, comparable a la compresión gzip.
Aquí es un breve ensayo sobre la capacidad de compresión de datos JSON original: El crimen data_geojson.json 72844By (Usted puede obtener el archivo aquí: https://github.com/lsauer/Data-Hub.El archivo se ha elegido al azar, pero no puede ser representativa de los datos promedio JSON)
excepto por zip todos los parámetros Archiver se fijaron a la ultra
* 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
Esto significa que la compresión es muy alta y beneficioso. Los datos JSON generalmente tienen una alta entropía. Según Wikipedia
La tasa de entropía de texto Inglés es de entre 1,0 y 1,5 bits por carta, [1] o tan bajo como 0,6 a 1,3 bits por carta, de acuerdo con estimaciones de Shannon basan en experimentos humanos
La entropía de los datos JSON suele estar muy por encima de eso. (En un experimento con 10 archivos JSON arbitrarios de aproximadamente el mismo tamaño, calculé 2.36)
¡No soy el único que sabe acerca de NanoZip! +1: D (pero nunca lo usaría en el cable jajaja) –
Para el ejemplo anterior, almacenar en SOA en lugar de formato AOS reduce mucho los datos. Descubrí que para muchos casos es un buen método de "compresión", pero depende de la aplicación específica si SOA es adecuado. – Chris
El consejo en 2 es confuso: ¿LZW todavía no es el método correcto incluso si cada paquete es grande? ¿Qué pasa si los paquetes no necesitan ser comprimidos por separado? También sería útil cualquier detalle o enlace sobre este empaque 0-255 en 0-127 –
Está empacando 0-127 en 0-255, y no al revés. ASCII utiliza bytes de 8 bits, pero los caracteres del texto estándar solo utilizan los 7 bits inferiores; los otros 128 caracteres, que configuran el bit más alto a 1, son caracteres de control. Para empacar los personajes, se toma cada octavo carácter y se dividen sus siete bits de datos entre los "bits altos" no utilizados de los 7 caracteres anteriores. – afeldspar