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.<p>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. <a href="https://www.chromium.org/quic" rel="nofollow">https://www.chromium.org/quic</a>
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.<p>I think they backed off to a simpler model of just using small inside QUIC.<p>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.<p>(dreamer..)
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.
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..
And here's the (more modern) Noise-based nQUIC version:<p><a href="https://github.com/rot256/ninn" rel="nofollow">https://github.com/rot256/ninn</a>
Remember: <a href="https://blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobile-desktop/" rel="nofollow">https://blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobi...</a><p><i>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.</i>
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?
<a href="https://github.com/djc/quinn/blob/ce514af89a73f530e1366e79e5819008ef666648/quinn/src/platform/cmsg.rs" rel="nofollow">https://github.com/djc/quinn/blob/ce514af89a73f530e1366e79e5...</a>