
QUIC is HTTP 2 over UDP - johnhenry
https://daniel.haxx.se/blog/2017/01/26/quic-is-h2-over-udp/
======
Matthias247
QUIC is certainly interesting, but I can not agree with the headline. IMHO
HTTP over QUIC needs a very different implementation than HTTP/2 over TCP/SSL.
The majority of frame types and frame handling mechanisms are no longer needed
and even if they are, they will be used in other ways. That's similar to the
situation that HTTP/2 is not simply HTTP/1.1 over a multiplexing layer that
gets introduced on top of TCP but also a completely different thing, as the
multiplexing layer and the HTTP related mechanisms (header transmission,
compression, etc.) are tightly interacting there.

My current estimation is that webservers would need to have 3 completely
different implementations of the HTTP stack (for HTTP/1.1, HTTP/2 and
HTTP/QUIC), where only the most upper layer (interfaces for sending requests
and respones) can be shared, the remaining stuff will be very different.

------
rijoja
Sounds interesting but is it used anywhere?

~~~
johnhenry
It's actually enabled in Chrome right now:
[https://en.wikipedia.org/wiki/QUIC#Client_.28browser.29_supp...](https://en.wikipedia.org/wiki/QUIC#Client_.28browser.29_support).
If you're using Chrome and you visit chrome://net-internals/#quic, you may
notice that you're using it right now.

~~~
rijoja
Wow had no idea. But isn't TCP good enough? I guess I could google for a
benchmark but I am to lazy.

Because it's made for speed issues right?

~~~
johnhenry
I didn't know it was in active use either until I saw your question and
decided to research, so thanks!. Why do we need cars? Isn't my horse good
enough? :p It's simply a new, experimental technology that offers some
benefits over an older one. Yes, speed is one of the benefits, but there are
some other advantages listed here: [https://ma.ttias.be/googles-quic-protocol-
moving-web-tcp-udp...](https://ma.ttias.be/googles-quic-protocol-moving-web-
tcp-udp/)

~~~
sigil
Thanks for the explainer. This stood out:

> QUIC has implemented its own identifier for unique connections called the
> Connection UUID. It's possible to go from WiFi to LTE and still keep your
> Connection UUID, so no need to renegotiate the connection or TLS. Your
> previous connection is still valid.

This sounds more viable than Multipath TCP.

~~~
rijoja
Nice feature.

Also not relying on the rightfully conservative TCP standard, they can iterate
over new ideas. I thought the area should be thoroughly examined by now. But
they have another good idea:

Forward error correction. This is essentially RAID 5 on the network level.
This introduces an overhead of 10 % so one in tenth packages might be lost.
However this saves us from a costly roundtrip. My knowledge of networking is a
bit rusty but this is not implemented in TCP I suppose.

Anybody got any idea of when support for this will arrive to more mainstream
servers. Such as apache?

