Permessage-deflate calls zlib flush with wrong flush level

[joux3]

I started wondering why very similar packets didn't compress better. Turns out the Node.js API for zlib is a tad bit misleading: the kind of flush needs to be specified when calling flush even if it's been specified in the options (see https://nodejs.org/api/zlib.html#zlib_zlib_flush_kind_callback).

This pull requests calls flush with the correct level and adds a test that checks that the compression actually makes similar packets smaller.

Note: I gave this only a very preliminary testing. Please do testing across more browsers before even considering merging.

[JacksonTian]

It seems OK.

[BenV]

Would be great to get this merged, we also noticed the poor compression ratio.

[BenV]

I'm not against that, but in this case I think Z_SYNC_FLUSH is "correct", it doesn't quite make sense to restart the compression for each packet, if that is the desired behavior it can be controlled with the server/client context takeover options, right?

Note that the flush level (https://nodejs.org/api/zlib.html#zlib_zlib_flush_kind_callback) is not the same as the compression level. I was actually thinking of doing a pull for configuring the compression level this weekend, as we would like to change ours to fastest.

More on the flush modes can be found here: http://www.bolet.org/~pornin/deflate-flush.html, in particular: A full flush degrades the compression efficiency since it removes sequence sharing opportunities for the next 32 kB of data

[lpinca]

@joux3 can you please rebase this?

[joux3]

Done @lpinca. Further review for the Sender.test.js is needed, I just changed the asserts as the actual byte counts changed after my fix. I'm not familiar enough with the codebase and WebSocket framing to verify if that is indeed OK.

[lpinca]

I merge this, it should be easy to revert/fix if we find that something isn't working as expected.

[lpinca]

Thanks!