HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelfā™§ 0
← Back to top all-time
cloudflare
quiche
Rust2019–2025
cloudflare / quiche

quiche

🄧 Savoury implementation of the QUIC transport protocol and HTTP/3

25Distinct people
28Mentions
0Explicit recommenders
12.9KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

🄧 Savoury implementation of the QUIC transport protocol and HTTP/3

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC Ā· Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year28 dated mentions

Observed mentions: 2019-01-23 10:39:51 UTC to 2025-12-16 18:53:19 UTC.

02468102019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 4 mentions; 3 submissions, 1 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC431
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC606
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC413
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC303
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC909
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
quiche is an implementation of the QUIC transport protocol and HTTP/3 as specified by the IETF. It provides a low level API for processing QUIC packets and handling connection state. The application is responsible for providing I/O (e.g. sockets handling) as well as an event loop with support for timers. For more information on how quiche came about and some insights into its design you can read a post on Cloudflare's blog that goes into some more detail. Who uses quiche? Cloudflare quiche powers Cloudflare edge network's HTTP/3 support. The cloudflare-quic.com website can be used for testing and experimentation. Android Android's DNS resolver uses quiche to implement DNS over HTTP/3. curl quiche can be integrated into curl to provide support for HTTP/3. Getting Started Command-line apps Before diving into the quiche API, here are a few examples on how to use the quiche tools provided as part of the quiche-apps crate. These are not suitable for production environments; see disclaimers and notes. After cloning the project according to the command mentioned in the building section, the client can be run as follows: $ cargo run --bin quiche-client -- https://cloudflare-quic.com/ while the server can be run as follows: $ cargo run --bin quiche-server -- --cert apps/src/bin/cert.crt --key apps/src/bin/cert.key (note that the certificate provided is self-signed and should not be used in production) Use the --help command-line flag to get a more detailed description of each tool's options. Configuring connections The first step in establishing a QUIC connection using quiche is creating a Config object: let mut config = quiche::Config::new(quiche::PROTOCOL_VERSION)?; config.set_application_protos(&[b"example-proto"]); // Additional configuration specific to application and use case... The Config object controls important aspects of the QUIC connection such as QUIC version, ALPN IDs, flow control, congestion control, idle timeout and other properties or features. QUIC is a general-purpose transport protocol and there are several configuration properties where there is no reasonable default value. For example, the permitted number of concurrent streams of any particular type is dependent on the application running over QUIC, and other use-case specific concerns. quiche defaults several properties to zero, applications most likely need to set these to something else to satisfy their needs using the following: set_initial_max_streams_bidi() set_initial_max_streams_uni() set_initial_max_data() set_initial_max_stream_data_bidi_local() set_initial_max_stream_data_bidi_remote() set_initial_max_stream_data_uni() Config also holds TLS configuration. This can be changed by mutators on the an existing object, or by constructing a TLS context manually and creating a configuration using with_boring_ssl_ctx_builder(). A configuration object can be shared among multiple connections. Connection setup On the client-side the connect() utility function can be used to create a new connection, while accept() is for servers: // Client connection. let conn = quiche::connect(Some(&server_name), &scid, local, peer, &mut config)?; // Server connection. let conn = quiche::accept(&scid, None, local, peer, &mut config)?; Handling incoming packets Using the connection's recv() method the application can process incoming packets that belong to that connection from the network: let to = socket.local_addr().unwrap(); loop { let (read, from) = socket.recv_from(&mut buf).unwrap(); let recv_info = quiche::RecvInfo { from, to }; let read = match conn.recv(&mut buf[..read], recv_info) { Ok(v) => v, Err(e) => { // An error occurred, handle it. break; }, }; } Generating outgoing packets Outgoing packet are generated using the connection's send() method instead: loop { let (write, send_info) = match conn.send(&mut out) { Ok(v) => v, Err(quiche::Error::Done) => { // Done writing. break; }, Err(e) => { // An error occurred, handle it. break; }, }; socket.send_to(&out[..write], &send_info.to).unwrap(); } When packets are sent, the application is responsible for maintaining a timer to react to time-based connection events. The timer expiration can be obtained using the connection's timeout() method. let timeout = conn.timeout(); The application is responsible for providing a timer implementation, which can be specific to the operating system or networking framework used. When a timer expires, the connection's on_timeout() method should be called, after which additional packets might need to be sent on the network: // Timeout expired, handle it. conn.on_timeout(); // Send more packets as needed after timeout. loop { let (write, send_info) = match conn.send(&mut out) { Ok(v) => v, Err(quiche::Error::Done) => { // Done writing. break; }, Err(e) => { // An error occurred, handle it. break; }, }; socket.send_to(&out[..write], &send_info.to).unwrap(); } Pacing It is recommended that applications pace sending of outgoing packets to avoid creating packet bursts that could cause short-term congestion and losses in the network. quiche exposes pacing hints for outgoing packets through the [at] field of the [SendInfo] structure that is returned by the send() method. This field represents the time when a specific packet should be sent into the network. Applications can use these hints by artificially delaying the sending of packets through platform-specific mechanisms (such as the SO_TXTIME socket option on Linux), or custom methods (for example by using user-space timers). Sending and receiving stream data After some back and forth, the connection will complete its handshake and will be ready for sending or receiving application data. Data can be sent on a stream by using the
Read the full README on GitHub

What Hacker News says

28 sources
Yeah, my naive implementation thought experiment was oriented towards a side channel brokered by the ssh connection using nginx and curl. Something like source opens nginx to share a file and tells sink via ssh to curl the file from source with a particular cert. However, I observed that curl [0] uses openssl' quic implementation (for one of its experimental implementations). Another backend for curl is Quiche [1] which has client and server components already, has the userspace crypto etc. It's a little confusing to me, but CloudFlare also has a project quiche [2] which is a Rust crate with a CLI to share and consume files. 0. https://curl.se/docs/http3.html 1. https://github.com/google/quiche/tree/main/quiche/quic 2. https://github.com/cloudflare/quiche
In High Performance SSH/SCP
It's more like Cloudflare forked nginx a long time ago, and is meanwhile in the very slow (like, decade-long) process of replacing it entirely. The Cloudflare Workers Runtimeāˆ—, for instance, is built directly around V8; it does not use nginx or any other existing web server stack. Many new features of Cloudflare are in turn built on Workers, and much of the old stack build on nginx is gradually being migrated to Workers. https://workers.dev https://github.com/cloudflare/workerd In another part of the stack, there is Pingora, another built-from-scratch web server focused on high-performance proxying and caching: https://blog.cloudflare.com/how-we-built-pingora-the-proxy-t... Even when using nginx, Cloudflare has rewritten or added big chunks of code, such as implementing HTTP/3: https://github.com/cloudflare/quiche And of course there is a
Read the rest
ton of business logic written in Lua on top of that nginx base. Though arguably, Cloudflare's biggest piece of magic is the layer 3 network. It's so magical that people don't even think about it, it just works. Seamlessly balancing traffic across hundreds of locations without even varying IP addresses is, well, not easy. I could go on... automatic SSL certificate provisioning? DDoS protection? etc. These aren't nginx features. So while Cloudflare may have gotten started being more-or-less nginx-as-a-service I don't think you can really call it that anymore. āˆ— I'm the tech lead for Cloudflare Workers.
In What is a CDN? How do CDNs work?
NGINX has an experimental QUIC branch [1], but in my experience it is buggy and currently has lower throughput than using Quiche [2] with NGINX. I do the latter for my fork of NGINX called Zestginx [3], which supports HTTP/3 amongst a bunch of other features. NGINX's QUIC implementation seems to also lack support for QUIC and or HTTP/3 features (such as Adaptive Reordering Thresholds and marking large frames instead of closing the connection). [1] : https://hg.nginx.org/nginx-quic [2] : https://github.com/cloudflare/quiche [3] : https://github.com/ZestProjects/Zestginx EDIT: A friend of mine who works at VK ("the Russian Facebook") informed me that they're helping out with the NGINX QUIC implementation which is nice to hear, as having a company backing such work does solidify the route a little.
In HTTP/3 Is Fast

Showing the 15 most recent of 28 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.