Hacker News Reader

Comment by Ameo | Hacker News Reader

I've been running Cloudflare's implementation of HTTP3/QUIC called Quiche[1] on my server's NGINX for over a year. It powers several websites and has served hundreds of millions of responses. It was a little weird to set up, but I've not encountered any issues with it so far.

It will be interesting to see how their native implementation compares.

[1] https://github.com/cloudflare/quiche/tree/master/nginx

View on HN

NGINX has now an own QUIC implementation? I have to look again.

Implementing QUIC seems no fun and there are almost no implementations. Almost everybody claiming HTTP/3 support uses Quiche under the hood for QUIC (besides some outliers and AWS who are one of the very small group of orgs who have their own QUIC lib). I was under the impression NGINX kept building on the current foundations with Quiche.

ASP Net Core can use QUIC. It uses MsQuic library and libmaquic.

Oh, right! There is also MS. I've forgot to mention their lib as I'm not working with any MS technologies. Apologies.

IIS is still waiting for it, you have to run some esoteric commands to try it out and it doesn't reliably function.

Well, it's not ready for prime time:

https://interop.seemann.io/

A more or less full list of implementations is here:

https://github.com/quicwg/base-drafts/wiki/Implementations

But I personalty would have qualms with all the C implementations. Crypto and very complex protocols are nothing one should implement in C, imho. This cries for disaster. And what's left, especially in an usable state, is quite underwhelming currently.

Higher level libs / frameworks like Java's Netty and Rusts Hyper chose Quiche for QUIC.

The only other ready to use libs I've found were AIOQUIC for Python and quic-go. Those are also the only ones with a working WebTransport feature currently.

Looking on the above linked inter-op tables MS will need some time to catch up. QUIC is indeed complex.

I think you’re understating how many quic implementations exist. Google, Apple, F5, Facebook, Fastly, Cloudflare, Microsoft, AWS all have separate implementations servicing significant production traffic, most of them open source. That doesn’t even count the smaller, language-specific implementations. Searching for quic interop tests is a good way to discover the various implementations.

We really, REALLY need a "standard" QUIC API, this thing is getting out of hand IMHO.

This was called for. QUIC is UDP based, and shifts the burden of implementing stuff like congestion control into userspace. There are already plenty different congestion control algorithms in the (linux-)kernel for TCP so you can expect a myriad of different implementations (and configurations) in QUIC - but this time on a per-program level.

I do understand that, but I'd still like a "common" basic API for those people that just want to transmit data efficiently from point A to point B. If QUIC is harder than TCP, people will just stick to that instead of switching to QUIC. I don't say we need a SOCKET_QUIC, but it would be nice to have at least a way to open a connection that's similar on every library.

Ah yes, the waylandification of a protocol.

Reply on news.ycombinator.com