QUIC is an entirely new protocol for the web developed on top of UDP instead of TCP.
UDP has the advantage that it is not dependent on the order of the received packets, hence non-blocking unlike TCP.
If QUIC is used, the TCP/TLS/HTTP2 stack is replaced to UDP/QUIC stack.
According to Wikipedia:
> As improving TCP is a long-term goal for Google, QUIC aims to be nearly equivalent to an independent TCP connection, but with much reduced latency and better SPDY-like stream-multiplexing support.
> If QUIC features prove effective, those features could migrate into a later version of TCP and TLS (which have a notably longer deployment cycle).
So basically, QUIC wants to combine the speed of the UDP protocol, with the reliability of the TCP protocol.
>> If QUIC features prove effective, those features could migrate into a later version of TCP and TLS (which have a notably longer deployment cycle).
When I searched for it, this text is not present in the Wikipedia article about QUIC though it presumably was present in some version as many _other_ sites on the Internet quote this sentence. Can you say where you actually saw it?
The reality is probably closer to, a successful QUIC will replace TCP (and TLS) in future protocols or, such protocols will give up and move to HTTP so as to take advantage of QUIC anyway.
One reason is as so often, middleboxes. The usual corporate cycle (new technology is embraced on a small scale because it avoids the overhead of management oversight, grows to become important to the business, importance means oversight imposed, major benefit of technology destroyed, rinse and repeat) injures the Internet in the form of middleboxes, so of course a technology is deployed with the purpose of undermining the middleboxes and that technology is QUIC.
Despite middleboxes TCP and TLS are still evolving. It is slow and painful compared to green field designs like QUIC, but it still happens.
Latency-based congestion controllers such as CTCP and BBR have gained adoption to better utilize long, fat pipes while keeping bufferbloat down. TFO was introduced to cut down the connection setup latency by 1 RTT if the endopints have seen each other before before. There is some noise about upstreaming MPTCP to linux which would then eventually make its way to android where it would be a big deal for seamless wifi/mobile transitioning.
TLS' evolution is self-evident from new versions including dramatically changed handshakes rolling out.
Sure, but that has the relationship wrong. TLS development can't realistically import work from QUIC because the relevant work already is TLS. The relationship between TLS and QUIC in such a system is mutual, like a clownfish and an anemone - each needs the other, QUIC is not just replacing TCP here, it's also dependant on TLS (in a way TCP obviously is no) because it offers TLS guarantees (e.g. forward secrecy) in QUIC itself, as well as guarantees TCP has like delivery order preservation.
QUIC needs a cryptographic setup mechanism. 99% of TLS is the cryptographic setup mechanism, and then 1% is "Now that we've agreed everything, here is how to send application data", QUIC doesn't need that 1% but it takes all the rest of TLS 1.3 straight out of the box.
A QUIC implementation can hypothetically end up negotiating TLS 1.4 (some future compatible TLS 1.3 upgrade) and that'll work out fine, the keys get generated and then just as with TLS 1.3 they are used to encrypt QUIC's native packets not a TLS application data layer.
> If QUIC is used, the TCP/TLS/HTTP2 stack is replaced to UDP/QUIC stack.
Not really. QUIC only covers transport and multiplexing, not the application protocol. E.g. http headers or h2's framing are not included. QUIC is closer to SCTP.
That's the original Google research/proposal. This implementation implements the IETF working group drafts, which started from Google's design but has drifted some ways off.
It uses UDP because the internet is broken and there no practical way to add a new layer 4 transport that won't be blocked, dropped, or deprioritized by misconfigured middlemen.
Arguably we should just have lower perf fallbacks for the broken nets so there would ve pressure to get them fixed. I think QUIC would have been in a good position to do this.
Serious question - can anyone explain how you would choose which of these to use? e.g. I'm aware that Quinn is tokio-based whereas Quiche is an async-agnostic state machine. Where does this one fit in?
Actually, Quinn is split up in two crates: quinn is the tokio-based async layer, but quinn-proto provides an async-agnostic state machine (and provides a trait-based abstraction over its use of rustls and ring).
Also, I think quiche and neqo are squarely aimed at serving their particular corporate goals, whereas quinn is really aimed at being a library for use in the Rust ecosystem. So far that has mostly been the tokio ecosystem, but that might change as the async/await story matures.
No description whatsoever of wtf Neqo is, nor wtf QUIC is... this must be some kind web library because every web developer is a narcissist that thinks nothing else but the web exists. Googling "QUIC"... yep, every time.
I don’t get the anger here. Quite simply if you don’t know what QUIC is then you probably don’t need a library which implements it, and so there’s not much point doing all the groundwork to explain that.
"All the ground work"... only needs a short sentence. Is it a graphics library? A parser? A command line tool? A sorting algorithm? A heat equation solver? Oh, it's a tcp library.
QUIC is an entirely new protocol for the web developed on top of UDP instead of TCP. UDP has the advantage that it is not dependent on the order of the received packets, hence non-blocking unlike TCP.
If QUIC is used, the TCP/TLS/HTTP2 stack is replaced to UDP/QUIC stack.
According to Wikipedia:
> As improving TCP is a long-term goal for Google, QUIC aims to be nearly equivalent to an independent TCP connection, but with much reduced latency and better SPDY-like stream-multiplexing support.
> If QUIC features prove effective, those features could migrate into a later version of TCP and TLS (which have a notably longer deployment cycle).
So basically, QUIC wants to combine the speed of the UDP protocol, with the reliability of the TCP protocol.