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.
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.
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.
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.
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.
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 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.
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.
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.
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.
QUIC makes great progress on so many different networking problems: head of line blocking, connection establishment latency, connection migration, multiplexing...