quinn-rs/quinn: A Pure-Rust QUIC Stack Split Into Three Crates

What Quinn solves, and who ends up depending on it

QUIC moves stream multiplexing, loss recovery and connection migration into the transport, below the application protocol. Implementing that from scratch means writing a state machine that survives reordering, packet loss and path changes, plus a TLS 1.3 handshake integrated into the transport. Quinn is one such implementation, written in Rust and described in the README as "a pure-Rust, async-compatible implementation of the IETF QUIC transport protocol". The project was founded by Dirkjan Ochtman and Benjamin Saunders as a side project in 2018, and the README states it has seen more than 30 releases since then.

The audience is narrower than "anyone who wants QUIC". You need a Rust service, you need streams or unreliable datagrams over UDP, and you are prepared to own the layer above the transport. Quinn gives you connections and streams, not HTTP semantics. That distinction matters because most people arrive at QUIC through HTTP/3, and Quinn is not an HTTP/3 server. It is the transport those servers are built on.

Three crates, one UDP socket, and a sans-I/O core

The repository is a Cargo workspace whose members are quinn, quinn-proto, quinn-udp, bench, perf, fuzz and docs/book. The README assigns each a role. quinn is the "high-level async API based on tokio" and is what most developers will use. quinn-proto is a "deterministic state machine of the protocol which performs no I/O internally", suitable for custom event loops and potentially a C or C++ API. quinn-udp provides "UDP sockets with ECN information tuned for the protocol".

That split is the interesting design decision. Because quinn-proto does no I/O, it can be driven by a test harness that feeds it packets directly, and the README says the quinn-proto test suite uses simulated IO for reproducibility and to avoid long sleeps in timing-sensitive tests. The same property is what makes a non-tokio integration possible: you supply the timer and the socket, the crate supplies the protocol.

The data flow at the top level is simple to state and easy to get wrong. One Quinn endpoint corresponds to a single UDP socket, no matter how many connections are in use. All connections share that socket's send and receive buffers, so a busy endpoint is one queue, not one queue per peer. The README's usage notes call this out directly: handling high aggregate data rates on a single endpoint can require a larger UDP buffer than most environments configure by default, and erratic latency or throughput over a stable link is the symptom to look for.

Installing Quinn and running the built-in example

Quinn is published on crates.io, and the README points to docs.rs for the API. The repository's getting-started section uses the workspace examples rather than a cargo add command, so the fastest way to see it work is to clone the repository and run the two examples from the workspace root. The first starts a server on the loopback address serving the current working directory. The README shows it taking a path argument:

cargo run --example server ./

The second fetches a file from that server. Note the https scheme and the port, both taken from the README:

cargo run --example client https://localhost:4433/Cargo.toml

The README describes the result: an HTTP 0.9 server on the loopback address serving the current directory, with the client fetching ./Cargo.toml. By default the server generates a self-signed certificate and stores it to disk, and the client finds and trusts it automatically. There is no separate certificate setup step for this example, which is why it is the right first run.

For a real dependency, the minimum supported Rust version is the constraint to check first. The README states a minimum supported Rust version of 1.80.0, and adds that the minimum for published releases of the crates will always be at least 6 months old at the time of release. The workspace Cargo.toml is stricter: it sets rust-version = "1.88.0" and edition = "2024" for the repository itself. If you are building from a checkout rather than from crates.io, the workspace figure governs.

Where Quinn stops: no HTTP/3, and TLS you configure yourself

Quinn deliberately does not ship an HTTP/3 implementation. Nothing in the README or the workspace member list provides one, so a team that wants an HTTP/3 endpoint is looking at Quinn as a dependency of something else, not as the thing to install. That is the single most common mismatch between what people expect from a QUIC library and what this one is.

Certificates are the second boundary. The README says Quinn clients validate the cryptographic identity of servers by default, which requires trusting some certificate authority, and suggests Let's Encrypt for servers plus default client configuration for many purposes. It then names the cases where that does not work: peer-to-peer, trust-on-first-use, deliberately insecure applications, and any case where servers are not identified by domain name. For those, arbitrary validation logic is implemented by customizing the rustls configuration, and the README points at the insecure_connection.rs example. The cryptography is pluggable, with a standard implementation backed by rustls and ring, and the workspace also lists aws-lc-rs and rustls-platform-verifier as dependencies, so backend choice is real work rather than a default you can ignore.

The third boundary is operational. The README warns that raising UDP buffer sizes may require elevated privileges or modified system configuration on some platforms, naming Linux as an example. If you cannot change those settings in your deployment, the fix for erratic throughput is not available to you.

quinn-proto against a tokio-bound stack

The realistic alternative depends on which layer you are replacing. If you want QUIC in Rust with a runtime-agnostic core, quinn-proto is the same project at a lower level, so it is not an alternative so much as a different entry point: you take on the event loop and the socket, and you get the protocol state machine with no I/O.

If you want a full HTTP/3 stack, the difference is architectural rather than a matter of taste. Quinn hands you connections and streams; an HTTP/3 layer on top of Quinn owns request framing, header compression and server push semantics. Choosing Quinn means accepting that you or another crate supplies that layer. Choosing an HTTP/3 server crate means accepting its transport decisions. The README's own framing supports this reading: the high-level crate is described as a tokio-based async API with examples, and the protocol crate as suitable for custom event loops and potentially a C or C++ API, which is a statement about where the project expects to be embedded.

Within the workspace, the bench and fuzz members are worth noting for a different reason. They exist as separate crates, so benchmarking and fuzzing are part of the repository rather than an afterthought bolted on in a test directory. The README also notes that setting the SSLKEYLOGFILE environment variable makes the quinn-proto tests emit UDP packets for inspection in protocol analyzers like Wireshark, and write NSS-compatible key logs for the client side of each connection.

Maintenance, licensing and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-22. Releases in the recent window include quinn-proto 0.11.18 alongside quinn 0.11.12 on 2026-09-14, quinn-udp 0.6.2 on 2026-09-06, and quinn-proto 0.11.17 on 2026-08-17. The three crates are versioned independently, which is the practical upgrade cost: quinn-proto and quinn-udp can move on their own schedules, and the patch-level churn in quinn-proto in particular means a lockfile will see frequent updates even when the high-level crate has not changed.

Licensing is dual. The README carries both a MIT badge and an Apache 2.0 badge, the repository root contains LICENSE-MIT and LICENSE-APACHE, and the workspace Cargo.toml declares license = "MIT OR Apache-2.0". The metadata supplied for the repository lists Apache-2.0 as the license; the files themselves say either. If your organisation has a policy about which of the two it accepts, read both files rather than the summary line. The README also asks commercial users to consider sponsoring the project through Open Collective, which is a request, not a licence term.

One thing the README does not document is a rollback or downgrade procedure for a bad release. There is no compatibility promise stated across minor versions, and the minimum-supported-Rust policy is the only forward-looking commitment the README makes.

Editorial conclusion

Adopt Quinn if you are building a Rust service that needs QUIC streams, datagrams or a custom transport and you are willing to assemble TLS, HTTP/3 and certificate handling yourself. Do not adopt it if you want an HTTP/3 server out of the box, if you cannot move to the workspace's Rust 1.88.0, or if you need the project to publish a compatibility promise across minor versions, which the README does not give. Verify three things first: which crate your code should depend on (quinn, quinn-proto or quinn-udp), whether your TLS backend choice matches what your deployment already trusts, and whether your platform lets the process raise SO_SNDBUF and SO_RCVBUF, since the README warns that some platforms require elevated privileges or modified system configuration for that.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. quinn-rs/quinn on GitHub
4. README
5. Releases