Quinn 0.2.0: QUIC protocol implementation in Rust | Hacker News Reader

Quinn 0.2.0: QUIC protocol implementation in Rust

github.com

207 pointswhoisnnamdi50 comments

I'm really excited about QUIC and Quinn because I think a lot of networking problems map on to the "many serial streams in parallel" model. QUIC libraries will make it easier to write those apps than plopping them on top of TCP, while getting better performance with lower latency.

QUIC makes great progress on so many different networking problems: head of line blocking, connection establishment latency, connection migration, multiplexing...

In case anyone else wasn't familiar with QUIC: it appears to be a Google-developed protocol that's similar to TCP+TLS+HTTP/2, but lower latency and with several other advantages, implemented on top of UDP. https://www.chromium.org/quic

The original version of QUIC was contributed to the IETF by Google, but at this point many people from outside of Google have contributed. Saying it is Google-developed is inaccurate at best if you're talking about recent drafts of the IETF spec.

Sure, but by far the biggest contributor to the project is Google and it should take some credit for it.

It will also become http/3 https://daniel.haxx.se/blog/2018/11/11/http-3/

Discussion about this is here:

https://news.ycombinator.com/item?id=18427795

It's worth emphasizing that QUIC is more general than a new transport for HTTP; it has wide ranging applications, due to being far more versatile than TCP.

I maybe have this wrong, but earlier versions of QUIC did PMTU like "tasting" of the viable MTU inside the protocol to get to big, from small. Thus, working around the external IP level pMTU blockers.

I think they backed off to a simpler model of just using small inside QUIC.

I kind of liked the former: one day we need to get rid of dependencies on small packets, and move to Jumbo in the wide.

(dreamer..)

The current draft encourages, but does not require, QUIC implementations to employ path MTU discovery along those lines; see https://quicwg.org/base-drafts/draft-ietf-quic-transport.htm... for details. Quinn doesn't yet have this implemented, but it would be pretty cool!

I really like the idea of having independent streams in a single connection. But for some applications I would like to have the ability to have unordered and optionally unreliable datagram channels in the same conmection as well. I have my own networking library that does this based on UDP, but I would rather spend my times on other things than maintaining that.

I've had a very similar question and asked it to the quinn authors. The response was that QUIC's way of creating/destroying channels is so lightweight that in order to get unordered-ness you can use ephemeral channels. As for unreliable-ness there is an extension to QUIC that isn't implemented yet. They then opened an issue after my inquiry: https://github.com/djc/quinn/issues/207

I believe SCTP would fill in for that use case. For server-server communications there shouldn't be a problem, but I recall there's issues with client support & firewall rules, and I don't know if that status on that has changed if you need that. I also recall there being SCTP over UDP, but you lose some features there.

SCTP over UDP is how WebRTC data channels get their configurable reliability and ordering.

I think the internet would have been a much better place if SCTP caught on 15 years ago. It solved so many problems way ahead of it's time. Ah well.

I looked into SCTP a bit. It seems to have a few quirks that puzzle me. E.g. the number of streams can be limited by what the underlying OS or other endpoint is willing to support. Not sure if that is what I want. I need to read a lot more to fully understand it.

enet (http://enet.bespin.org) is pretty nice, but unfortunately it suffers from narrow adoption, lack of progress on things like ipv6 support and biggest of them all, a standardization or even documentation of the protocol at a byte level.

Other than Google, who uses QUIC in production?

Fastly: https://github.com/h2o/quicly

Facebook: https://github.com/facebook/proxygen/issues/127#issuecomment...

Cloudflare: https://blog.cloudflare.com/head-start-with-quic/

Akamai: https://developer.akamai.com/blog/2018/10/10/introducing-qui...

One more missing

https://www.litespeedtech.com/products/litespeed-web-server/...

With the rise of HTTP/3, soon just about everyone will with time.

I for one am super excited to start using this library in trust-dns. Just need to find the time: https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-05

While working on IPFS we found out that good multiplexers are hard to find. Currently we use QUIC as one of possible multiplexers. This is also good news for rust-ipfs implementation.

Yes, Akamai offers QUIC support on some CDN products. (Note: I work at Akamai)

Deps that include the CDN product Spotify uses?

My company is on Google Cloud, and by default our load balancers are set up to offer QUIC negotiation.

Facebook

apple does for a few things

The problem is not so much the browser implementation, but rather the server software and network infrastructure like proxies and firewalls. I already ran into problems with Http 2 or websockets in some cases. QUIC being UDP can only exacerbate these issues..

I hear ya, but I'm hopeful this will improve over the next few years as QUIC gets used more in the wild. It really does bring some nice advantages.

UDP protocols will be more and more common in the future, people specially security need to change the way the think about UDP.

And here's the (more modern) Noise-based nQUIC version:

https://github.com/rot256/ninn

I don't know why you got downvoted, there is a paper about nQUIC [3], "Noise" here refers to the Noise Protocol[1] and its Rust implementation[2]:

[1] http://www.noiseprotocol.org/

[2] https://docs.rs/snow/0.4.2/snow/

[3] https://eprint.iacr.org/2019/028

> I don't know why you got downvoted

I imagine it got downvoted because it claims an old fork of the same code is "more modern" because it implements the must less capable Noise as a basis for QUIC rather than TLS.

We have something akin to CADT in protocol security where a certain type of person gets very excited about whatever new shiny thing they're convinced will fix everything and so they want to see it replace everything else immediately, no questions asked. Recently that's Noise.

Good news for people actually doing serious security engineering with Noise: In a few years these people will move on to whatever new thing is hot and leave you behind. Bad news: They will say everything you've done is crap when they do.

I mean the protocol is the more modern version.

Less capable as in "fewer ways to hit yourself in the foot by forcing you to use secure cryptosystems", then sure.

WhatsApp and Wireguard have been using Noise for a couple of years now.

And here is a light introduction: https://cryptologie.net/article/467/quic-noise-nquic/

ninn is a fork of a much older, much less functional version of Quinn.

I have a plan for making the security protocol fully pluggable in Quinn, so that we can easily support things like Noise.

Remember: https://blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobi...

In fact, our experiments showed that QUIC always consumes more than half of the bottleneck bandwidth, even as the number of competing TCP flows increases.

Are there any numbers out there how often 443 udp is blocked on wifis?

Why would this port be blocked?

On public wifis they might not want you to do anything weird, so they block everything except "web ports", i.e. 80,443/tcp

And dns 53/udp otherwise you do not get far.

Sometimes that's blocked too, you're forced to use the local DNS server, which is the only one authorized to access port 53/udp out.

Because nobody needed it for a legitimate reason up to now.

is GQUIC going to be supported by Envoy any time soon?

A reusable library in C would be more useful.

You could put a C inferface on top of this. Especially the quinn-proto is suitable for this, as it does no IO on its own.

Tangential point... is it accurate for the project to describe itself as a "pure-Rust implementation of the QUIC protocol" when it uses platform dependent unsafe code? https://github.com/djc/quinn/blob/ce514af89a73f530e1366e79e5...

All Rust programs call out to platform-dependent unsafe code sooner or later in the form of the standard library. Otherwise, you wouldn't be able to allocate memory or do any I/O whatsoever.

Sometimes the standard library doesn't expose functionality you want, like the capability to read/write the ECN bits of your UDP packets, so you have to bind some syscalls yourself. The capability to do this is one of Rust's core strengths, and it does not compromise a program's rustiness any moreso than calling a wrapper around write to print "Hello, world!" does.

Any systems language has to deal with unsafe code at some level, the big difference to C is that is explicit and not present at every statement that has to deal with memory access.

That's still Rust code.

(And speaking as an outsider, arguments about purity seem like the last thing Rust needs.)

Knowing whether something just links in a C library and adds a wrapper, and how thick that wrapper around it is useful in knowing how ergonomic the API will be, and how easy it is to cross target.

For example, if you want to run on musl with a statically linked libc, then a library which is just a wrapper around a C shared library which depends on glibc is a non starter.

Reply on news.ycombinator.com