QUIC(k) HTTP/3

Is it really a “new” protocol?

HTTP/3 isn’t a new protocol, in fact it is being developed for quite some time and you’re probably using it if you use Google services, but it was named QUIC.

Please take a look the following image where we are accessing Google Drive (Gmail also works and many other Google services), using Google Chrome:

You can notice in the “Protocol” column that QUIC is already being used in multiple requests. It isn’t new!

If you would like to understand more details about the protocol itself please check out our blogpost about HTTP alternatives. However, to quickly summarise QUIC it is a transport protocol based on Datagrams (UDP) instead of TCP, which aims to be secure and reliable. It was created by Google and later adopted by IETF, which added some relevant inputs to the protocol.

If you’re interested in understanding the main differences from the Google and IETF versions, check out “What’s Changed?” section of “What’s Happening with QUIC” blogpost from IETF.

Avoid the confusion

There are three different things that one can be talking in respect to QUIC:

• QUIC transport layer aims to replace TCP / UDP protocols. Find more in the QUIC draft.
• HTTP over QUIC aims to make use of HTTP/2 application layer with QUIC transport protocol premises. Find more in the HTTP over QUIC draft from IETF.
• Other applications over QUIC (e.g WebRTC over QUIC).

What happened now was that IETF decided to call HTTP/3 the HTTP over QUIC protocol.

Quoting Mark Nottingham in IETF mailing list discussion:

(…) in those discussions, a related concern was identified; confusion between QUIC-the-transport-protocol, and QUIC-the-HTTP-binding. I and others have seen a number of folks not closely involved in this work conflating the two, even though they’re now separate things.

To address this, I’d like to suggest that — after coordination with the HTTP WG — we rename our the HTTP document to “HTTP/3”, and using the final ALPN token “h3”. Doing so clearly identifies it as another binding of HTTP semantics to the wire protocol — just as HTTP/2 did — so people understand its separation from QUIC.‍

H3 was confirmed in the IETF 103 meeting. Further meetings information and QUIC protocol details can be found in the QUIC working group page.

What does it mean for my project?

Well… if you just updated your project to use HTTP/2, you probably noticed that it took some time to be implemented in Node.js (or other languages/platforms). QUIC (or HTTP/3) is still being developed at IETF, so just have a look into the QUIC draft and HTTP over QUIC draft and don’t worry that much for now.

Node.js

If you want to be adventurous you can try the existing implementations (all work in progress and not production ready). For Node.js there is quic, which still uses a version similar to Google but plans to map IETF draft, and quicker, which is being created by an university in Belgium, but at the time of this writing was using a Node.js 8.6.0.

Recently an issue about QUIC support was created on the Node.js repository. Some questions that may arise are “If Node.js added HTTP/2 module to the core, shouldn’t QUIC (HTTP/3) be added too?” and “Should the HTTP/2 implementation be adapted to match both HTTP/2 and HTTP/3 cases?”.

The promise from the Node.js TSC is to start taking a look at HTTP/3 in January, 2019, which matches the dates given by IETF. One of the most interesting things on this thread was asking people “what are the top three compelling features of the protocol that make it essential?”. The answers are worth to look at!

The three top features for me are:

• 0-RTT. If the client already has the server configuration from a previous connection, it could reduce the handshake process to 0-RTT and start sending data.
• Connection ID, which is a random value created in the first message sent by the client. This is an important value because if you access a webpage using WIFI and suddenly change to mobile data, the same connection is used. This is a huge improvement over TCP where connections are IP dependent.
• Stream multiplexing, which allow head-of-line blocking elimination. If a packet from a stream is lost, only that stream is affected and not the entire connection (we can still have head-of-line blocking on a stream, but the impact is completely different as having it on the entire connection).

Where can I find more information?

• Alternatives to HTTP! blogpost
• Draft RFC for QUIC from Google
• QUIC Crypto file from Google
• QUIC draft from IETF
• HTTP over QUIC draft from IETF
• The road to QUIC blogpost by Cloudfare
• HTTP/3 blogpost by Daniel Stenberg

That’s all for now! I’m pretty excited to see where QUIC is going to find its space to reduce latency and improve our day-to-day connections.