
Neqo, an Implementation of QUIC Written in Rust - enz
https://github.com/mozilla/neqo/
======
pcr910303
For people like me who wondered what QUIC was:

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.

~~~
tialaramex
>> 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.

~~~
the8472
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.

~~~
tialaramex
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.

------
kbumsik
So it's made by Mozilla. It is going to the implementation of HTTP/3 in
Firefox?

~~~
enz
Yes, I think this is the plan.

------
rapsey
A third rust QUIC implementation. They all have their own crypto lib. Neqo
with NSS, Quiche with BoringSSL and Quinn with rustls.

~~~
thombles
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?

~~~
dochtman
Disclaimer: one of Quinn's maintainers.

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.

------
The_rationalist
Are there any HTTP 3 benchmarcks?

------
jmpeax
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.

~~~
jon-wood
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.

~~~
jmpeax
"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.

