A collection of different web transport implementations.
Provides low and high level abstractions to dispatch frames, as such, it is up to you to implement Stream with any desired logic or use any of the built-in strategies through the selection of features.
```rust use wtx::{ Stream, rng::Rng, web_socket::{ FrameBufferVec, FrameMutVec, FrameVecMut, compression::NegotiatedCompression, OpCode, WebSocketClientOwned } };
pub async fn handleclientframes(
fb: &mut FrameBufferVec,
ws: &mut WebSocketClientOwned
See the examples directory for more suggestions.
All the fuzzingclient/fuzzingserver tests provided by the Autobahn|Testsuite project are passing and the full reports can found at https://c410-f3r.github.io/wtx.
The "permessage-deflate" extension, described in RFC-7692, is the only supported compression format and is backed by the fastest compression library available at the current time, which is "zlib-ng". It also means that a C compiler is required to use such a feature.
There are mainly 2 things that impact performance, the chosen runtime and the number of pre-allocated bytes. Specially for servers that have to create a new WebSocket instance for each handshake, pre-allocating a high number of bytes for short-lived or low-transfer connections can have a negative impact.

If you disagree with any of the above numbers, feel free to checkout wtx-bench to point any misunderstandings or misconfigurations. A more insightful analysis is available at https://c410-f3r.github.io/thoughts/the-fastest-websocket-implementation/.
¹ monoio and tokio-uring are slower because owned vectors need to be created on each read/write operation.
² embassy is supported but there isn't a std example for measurement purposes.