1

Is it possible to pack and unpack websockets traffic frame by frame with GZIP?

We have a lot of websockets traff (real time quotes) that should be packed to reduce traffic, but I have no idea if it is even possible.

Prosto Trader
  • 3,471
  • 3
  • 31
  • 52
  • possible duplicate of [Could websocket support gzip compression?](http://stackoverflow.com/questions/11646680/could-websocket-support-gzip-compression) –  Feb 20 '14 at 15:38
  • I saw that question, but there is no answer. Proposition was submitted a YEAR ago to IETF but what happened since then? – Prosto Trader Feb 20 '14 at 15:48
  • 1
    you can deflate and base64 worst-case... js has lots of inflate()/deflate() tools available. You could also consider using CSV instead of JSON, which can reduce typical data object footprints a lot (no quotes, no key repeats). It recently saved me ~75% pushing calendar entries, where deflate yielded about 85% reduction on the same JSON. Considering that CSV is faster to build and unpack, i can live with that... – dandavis Feb 24 '14 at 07:20

2 Answers2

3

Per-message compression as per this draft is where things are going.

Browser support still stands at Chrome-only. Webkit seems to be in the works, but there is no telling when FF and IE will follow.

On the server side, there is e.g. an implementation of this in AutobahnPython (see example here).

Depending on what stack/environments you use for your project, this means that you can try WebSocket compression today.

(Full disclosure: I work for Tavendo, the project maintainer for the Autobahn WebSockets projects.)

Community
  • 1
  • 1
gzost
  • 2,375
  • 1
  • 18
  • 25
0

I use LZ-String to encode/decode JSON back and forth through sockets; a really slick JavaScript implementation of LZW compression.

Until people reach a standard on this, it's a great solution.

http://pieroxy.net/blog/pages/lz-string/index.html

It reduces text bandwidth an average of 10x and takes less than 1ms to decode a few kb.

Nick Steele
  • 7,419
  • 4
  • 36
  • 33