feat(websocket): only consume necessary bytes

[KhafraDev]

Refs: #1811

Before, for every parsing stage, we would concatenate every buffer, even if we only needed to read the first few bytes (for most cases). Now, we can consume n bytes from the buffers, removing them & handling the total length. This simplifies the logic quite a bit and should improve performance (although there aren't any benchmarks to confirm this).

ws implements something similar:
https://github.com/websockets/ws/blob/fb1dfd217861757d60c1d02c6e66b4da3630cc93/lib/receiver.js#L94-L131

[codecov-commenter]

Codecov Report

Base: 87.27% // Head: 87.27% // Decreases project coverage by -0.00% ⚠️

Coverage data is based on head (1cc2f6a) compared to base (860c261).
Patch coverage: 75.67% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1812      +/-   ##
==========================================
- Coverage   87.27%   87.27%   -0.01%     
==========================================
  Files          66       66              
  Lines        5792     5799       +7     
==========================================
+ Hits         5055     5061       +6     
- Misses        737      738       +1     

Impacted Files	Coverage Δ
lib/websocket/receiver.js	76.35% <73.52%> (+0.29%)	⬆️
lib/websocket/constants.js	100.00% <100.00%> (ø)
lib/websocket/websocket.js	42.16% <100.00%> (ø)
lib/fetch/body.js	96.53% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[lpinca]

Can you add the copyright notice? ByteParser is a slightly modified copy of ws Receiver.

FWIW Receiver is exposed by ws for third party usage.

const { Receiver } = require('ws');

[KhafraDev]

Sure, although none of the code is copied directly from ws. Everything was written by hand, which is probably the reason it took so long to get right (and the reason there are still bugs). Since both use Writable node streams, there's going to be overlap with how some things are handled, but if I did copy code anywhere, I would have left a copyright notice already.

Obviously ws was a big inspiration and a good library to base another implementation of because it's much older and much more used.

[lpinca]

There are so many similarities here and in a0094a4 that I think it is deserved even if ws Receiver was used only as a reference. You could add something along the lines "This code was adapted from XXX released under the MIT license". It is the only requirement of the MIT license.

Extending stream.Writable is a good choice for a future permessage-deflate implementation where decompression is asynchronous and might be slower than incoming data. At the moment, without permessage-deflate, extending stream.Writable is only unnecessary overhead as everything is synchronous.

[KhafraDev]

I've added a notice, let me know if there's anything else!

[lpinca]

That's ok, thanks. If you think no notice should be added and want to remove it, feel free to do that, I won't get in the way anymore.

[KhafraDev]

No, you deserve recognition - without your help the last week, there's no way I'd have as good of an understanding of websockets, and undici's implementation, without ws, would be incomplete and full of bugs. A notice is the least I can do, all things considered.