Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Because everything comes down the same connection brotli/zstd can give you 1000-8000x compression ratios.

Isn't this also the case by default for HTTP/2 (or even just HTTP/1.1 `Connection: keep-alive`)?

> The server is in control. I can batch updates.

That's neat! So you keep a connection open at all times and just push an update down it when something changes?



So even though HTTP/2 multiplexes each request over a single TCP connection, each HTTP connection is still compressed separately. Same with keep alive.

The magic is brotli/zstd are very good at streaming compression thanks to forward/backward references. What this effectively means is the client and the server share a compression window for the duration of the HTTP connection. So rather than each message being compressed separately with a new context, each message is compressed with the context of all the messages sent before it. What this means in practice is if you are sending 140kb of divs on each frame, but only one div changed between frames, then the next frame will only be 13bytes because the compression algorithm basically says to the client "you know that message I sent you 100ms ago, well this one is almost identical apart from this one change". It's like a really performant byte level diffing algorithm, except you as the programmer don't have to think about it. You just re-render the whole frame and let compression do the rest.

In these demos I push a frame to every connected client when something changes at most every 100ms. What that means, it effectively all the changes that happen in that time are batched into a single frame. Also means the server can stay in charge and control the flow of data (including back pressure, if it's under to much load, or the client is struggling to render frames).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: