Support no-masking extension

[xim]

I am working with software that has a number of websocket clients ; some on the local machine over local sockets, some over SSL tunnels, some over TCP, etc.

For the clients running in a secure context, I wouldn't mind saving a few CPU cycles by skipping the standard websocket masking. What I want is perfectly covered by a draft RFC, and I was wondering if this would be interesting to Boost.Beast.

I could try to make a PR at some point, but won't bother if there's no interest in the feature from core developers. =)

https://datatracker.ietf.org/doc/draft-damjanovic-websockets-nomasking/

[ashtum]

Thanks for the suggestion. Clients can also use websocket::stream::secure_prng to disable the secure PRNG. Performance measurements are needed to determine how much gain is achievable by completely disabling masking and whether it is worthwhile.

Additionally, the referenced RFC is still a draft, so introducing a feature that breaks the current standard may not be advisable.

[xim]

I did some benchmarking to compare boost::beast websocket performance inside our application framework. There is some overhead in the framework itself, so this isn't a raw comparison of boost::beast performance.

I ran the tests in three configurations, doing the benchmark 20 times and selecting the best.

1. non-patched beast, secure PRNG
2. non-patched beast, non-secure PRNG
3. patched beast that doesn't mask

Timings came out (server and client on the same low-end embedded platform, transferring 100 MB of messages)

1. 2776ms
2. 2771ms
3. 2161ms

I did some less-rigorous testing on x86, and there all three appear to fall within 3% of each other. Surprisingly, on x86 the PRNG change giving sligthly more gain than the no-masking.

So it appears that a no-masking extension could make sense in scenarios where you are CPU constrained.

[xim]

Re

introducing a feature that breaks the current standard may not be advisable

Yeah, when the extension is negotiated, I guess we'd be ignoring some MUSTs in the current rfc. It would have to be opt-in on both server and client, at least...