TIL: QUIC is like TLS over UDP

What is QUIC?

QUIC (Quick UDP Internet Connections) is a new(ish) protocol for developing applications on the internet. It aims to provide TLS-like encryption without the overhead of TCP.

What is TLS?

Briefly, TLS (Transport Layer Security) is the protocol that provides communication security to internet traffic. HTTPS is built on top of TLS. I won’t go in to the low level details here (I don’t know enough about them to speak credibly!), but it makes it very difficult for an attacker to read your web traffic.

What are TCP and UDP?

Here’s an overview of TCP and UDP to get you through the rest of this post¹. UDP and TCP are the primary Transport Layer² protocols of the internet. The internet uses encapsulation to send messages. That means the HTTP requests for this web page were wrapped up in a TCP request. (There’s a great diagram for this on the Wikipedia page.)

UDP is the unreliable but cheap protocol and TCP is the reliable but expensive version. UDP let’s you fire and forget a packet, but TCP will follow up and re-send packets if it recognizes they have not been received on the other end. Before QUIC, there has not been a standard to securely and reliably send UDP packets.

How is QUIC different from TCP and UDP?

The benefits of QUIC over UDP are essentially the same as the benefits of UDP (i.e. reliability & security if you include TLS).

The real question is what is the benefit of QUIC over TCP? This is summed up well in this IETF document, but I will highlight the pieces that stood out to me:

• QUIC’s ideal world has 0-RTT³ connection overhead.
• Multiplexed connections don’t get head of line blocking
  • In multiplexed TCP, if a single stream of data is blocked, all the streams are blocked. QUIC does not have this problem.
• Congestion control is in the application space instead of the kernel space.
  • Ideally this means iteration can happen at application speed rather than kernel speed. There’s a lot more thought that needs to go into releasing a new kernel version than needs to go into application level code.

Who is responsible for QUIC?

Jim Roskind from Google is responsible for QUIC’s initial design and implementation. It has since been submitted to a committee at IETF where work is being done to standardize it.

Here’s a brief time line:

• 2012 - initial implementation
• 2013 - public announcement
• 2015 - proposal for standardization submitted to IETF

Where is QUIC going?

QUIC has not settled on a standard yet. Researchers in Germany put out a paper evaluating how widespread QUIC support was. They found that less than 0.1% of domains were hosted on QUIC-enabled hosts. Additionally, they found 2.6 per cent and 9.1 per cent of all internet traffic was over QUIC. This is padded by Google which is serving most of its main sites traffic to Chrome over QUIC as can be seen in these slides. (I’m not sure if they’re doing the same for Firefox).

Just recently, there has been a lot of noise about DNS over HTTPS⁴. I found this surprising since I assumed you would send DNS over TLS rather than add the additional overhead of HTTP. However, one of the arguments put forward in a post about DNS over HTTPS is that if HTTP starts using QUIC, DNS over HTTPS will get the benefits for free. (There are a bunch of other reasons, you should definitely read that post.)

Questions and Comments

• I’m not 100% clear on how QUIC gets to avoid establishing a connection
• Is QUIC going to be the next version of TCP?
• What’s holding up the standardization of QUIC? Why is the protocol changing so rapidly?
• QUIC has a GOAWAY message. A little rude.

If you have any comments or suggestions for this post, find me on twitter: @paulcarletonjr.