Cloudflare Just Made QUIC Development Actually Usable
Cloudflare open-sourced tokio-quiche, the battle-tested async library that powers millions of HTTP/3 requests per second in production. Here's why it matters for infrastructure engineers.
Cloudflare announced on November 6th that they're open-sourcing tokio-quiche, their async QUIC library that's been quietly handling millions of HTTP/3 requests per second in production. This isn't vaporware—it's the same code powering Apple's iCloud Private Relay and Cloudflare's own next-generation Oxy proxies.
If you've ever tried to integrate a sans-io library into production, you know the pain. You get a beautiful state machine and zero help actually wiring it to the network. tokio-quiche solves that problem for QUIC.
The Problem With Sans-IO Libraries
Cloudflare originally released quiche six years ago as a sans-io QUIC and HTTP/3 implementation. Sans-io is a design pattern where the library implements protocol logic without making any assumptions about how you'll do I/O. In theory, this makes it portable across any runtime or environment.
In practice, it means you're on your own to figure out UDP socket management, connection routing, event loops, and async integration. That's a lot of plumbing for what should be straightforward: "I want to handle QUIC connections."
According to Cloudflare's blog post, this barrier kept teams from adopting HTTP/3 even when they wanted to. "Integrating sans-io libraries into applications is an error-prone and time-consuming process," the team wrote. So they built the glue layer they needed internally, battle-tested it for years, and are now shipping it to the rest of us.
What You Actually Get
The tokio-quiche library, available on crates.io since October 15th, combines quiche with Tokio's async runtime. The integration isn't trivial—internally it uses an actor model with dedicated tasks for packet routing and per-connection I/O workers.
The architecture is cleaner than you'd expect. An InboundPacketRouter owns the receiving half of the UDP socket and routes datagrams by connection ID to per-connection channels. Each connection gets its own IoWorker actor that drives the quiche state machine while managing the interplay between transport and application logic.
For HTTP/3 specifically, tokio-quiche ships an H3Driver that transforms quiche's raw HTTP/3 events into higher-level async streams. This is what you'd build yourself anyway, except Cloudflare already did the work and proved it at scale.
Battle-Tested At Scale
The "proven in production" claim isn't marketing. This library powers:
MASQUE is particularly interesting—it's a protocol for tunneling arbitrary TCP and UDP traffic over QUIC connections. Cloudflare chose to migrate from WireGuard to MASQUE, which tells you something about their confidence in the stack.
The team reports that tokio-quiche handles "millions of HTTP/3 requests per second with low latency and high throughput." That's not a benchmark on a laptop—that's production traffic on edge infrastructure.
The Actor Model Trade-Off
Under the hood, tokio-quiche uses Tokio's actor pattern: small tasks with internal state communicating via message passing over channels. This is a natural fit for async-ifying sans-io libraries because both models deal with exclusive access to state and message-based communication.
The sans-io library wants "messages" (raw byte buffers), the actor sends and receives structured data, and tokio-quiche provides the translation layer. It's conceptually elegant, though actors add complexity if you're debugging or trying to understand the control flow.
Cloudflare promises upcoming blog posts on their actor patterns, UDP GRO/GSO optimizations, and Tokio task cooperation budgeting. If you're building high-performance network services, those details matter.
More Than Just HTTP/3
While HTTP/3 is the obvious use case, QUIC is a general-purpose transport protocol. tokio-quiche exposes an ApplicationOverQuic trait that abstracts the execution of application protocols over QUIC.
This means you could build:
Cloudflare's own h3i debugging tool uses a non-HTTP/3 implementation of ApplicationOverQuic, showing the trait is genuinely useful beyond the HTTP/3 happy path.
What's Still Missing
Cloudflare is clear that tokio-quiche is a foundation, not a complete framework. The README includes example server and client event loops, but you'll still write some boilerplate.
The team plans to release "easy-to-use HTTP client and server abstractions" in the future—the same high-level APIs that power Oxy and WARP internally. They're also teasing "a completely new service that's handling millions of RPS with tokio-quiche," though details are sparse.
If you need production-ready HTTP/3 servers today, you're still building on primitives. But those primitives are significantly better than starting from scratch.
Why This Matters
HTTP/3 adoption has been slower than it should be. The protocol offers real benefits—faster connection establishment, better handling of packet loss, improved multiplexing—but the implementation complexity has been a barrier.
Cloudflare's move here is strategic. As they note, "Cloudflare alone embracing HTTP/3 is not of much use if others wanting to interact with our products and systems don't also adopt it." By lowering the barrier to entry, they're accelerating ecosystem adoption of protocols they've bet on.
For infrastructure engineers, this is a practical gift. You get a production-proven library from a team that operates at massive scale, with the Rust safety guarantees you want in network code. The documentation acknowledges the rough edges, and the roadmap shows they're committed to ongoing development.
If you're building anything that touches QUIC—whether that's an HTTP/3 server, a custom VPN, or something more exotic—tokio-quiche just became your starting point. Check it out on crates.io and judge for yourself whether it's ready for your use case.
The code is there. The battle scars are documented. Now we'll see what the ecosystem builds with it.