3 releases

0.10.5 May 24, 2024
0.10.4 May 6, 2024
0.10.3 May 3, 2024

#2 in #quinn

Download history 149/week @ 2024-04-29 378/week @ 2024-05-06 1688/week @ 2024-05-13 1850/week @ 2024-05-20 915/week @ 2024-05-27 1690/week @ 2024-06-03 687/week @ 2024-06-10

5,385 downloads per month
Used in 10 crates (5 directly)


21K SLoC

Quinn fork for iroh

Quinn is a pure-rust, async-compatible implementation of the IETF [QUIC][quic] transport protocol.

This is a fork incorporating some changes for use in iroh. The aim is to contribute back any generally useful changes into upstream Quinn, so it is strongly discouraged to use this fork directly.

Git branches

The default branch for this repo is the iroh-0.10.x branch. This branch tracks the quinn-rs:0.10.x upstream branch, which is the release branch for the Quinn 0.10 series of releases.

The main branch is kept as an identical copy of quinn-rs:main though is probably behind on commits.


QUIC transport protocol implementation

QUIC is a modern transport protocol addressing shortcomings of TCP, such as head-of-line blocking, poor security, slow handshakes, and inefficient congestion control. This crate provides a portable userspace implementation. It builds on top of quinn-proto, which implements protocol logic independent of any particular runtime.

The entry point of this crate is the Endpoint.

About QUIC

A QUIC connection is an association between two endpoints. The endpoint which initiates the connection is termed the client, and the endpoint which accepts it is termed the server. A single endpoint may function as both client and server for different connections, for example in a peer-to-peer application. To communicate application data, each endpoint may open streams up to a limit dictated by its peer. Typically, that limit is increased as old streams are finished.

Streams may be unidirectional or bidirectional, and are cheap to create and disposable. For example, a traditionally datagram-oriented application could use a new stream for every message it wants to send, no longer needing to worry about MTUs. Bidirectional streams behave much like a traditional TCP connection, and are useful for sending messages that have an immediate response, such as an HTTP request. Stream data is delivered reliably, and there is no ordering enforced between data on different streams.

By avoiding head-of-line blocking and providing unified congestion control across all streams of a connection, QUIC is able to provide higher throughput and lower latency than one or multiple TCP connections between the same two hosts, while providing more useful behavior than raw UDP sockets.

Quinn also exposes unreliable datagrams, which are a low-level primitive preferred when automatic fragmentation and retransmission of certain data is not desired.

QUIC uses encryption and identity verification built directly on TLS 1.3. Just as with a TLS server, it is useful for a QUIC server to be identified by a certificate signed by a trusted authority. If this is infeasible--for example, if servers are short-lived or not associated with a domain name--then as with TLS, self-signed certificates can be used to provide encryption alone.


~234K SLoC