QUIC! HTTP/3 is Coming!
By: Charith De Silva
Tags: Http3, Internet, Network, Quic, Web

Shane T. McCoy [Public domain], via Wikimedia Commons

https://commons.wikimedia.org/wiki/File:Special_forces_gatling_gun.jpg

When I say it’s coming, what I mean is that it’s already here. As a matter of fact, it’s been around for a while now. I guess that’s how QUIC HTTP/3 is, here even before it is here. Ok, so it’s still experimental, but most of the trailblazers like Google, Facebook, Mozilla have already adopted it and have being using it for a while now.

So what’s the big deal with HTTP/3? It’s just another version of HTTP. Wrong, this is the first version of HTTP purpose-built for the interactive & mobile internet, I feel. See, the earlier versions were increments or enhancements over HTTP/1.0 (HTTP/0.9 never really existed, I think ?). To very quickly recap the history of HTTP, before going over to the future:

HTTP/1.0, when you access a site, you ended up with a static page, however, the whole site is not usually loaded in one go. with HTTP/1.0, each new resource (picture, css, etc…) loaded required a new connection, this required connection closing and opening every time. with SSL/TLS this became very expensive

HTTP/1.1, now we are entering the interactive era, limitation of 1.0 was solved using persistent connections. the connection stays open unless explicitly closed. this allowed multiple requests to be made using the same connection (pipelining). As great as the improvement was, it had a problem as well, when the requests were hitting the same destination and the resource was not available or delayed. this caused a Head of line blocking (HOL). The workaround was again, to use multiple connections, back to square one, dot zero.

HTTP2, Again focused on using a single connection. The connection was split into multiple streams, each stream can carry multiple messages, and each message split into frames (Binary Frames). Frames can be sent without being blocked (multiplexing) and they are assembled at the destination. Although framing solved the issues of HTTP/1.1, multiple streams waiting for the same resource, still caused an issue, which was solved by stream prioritization. Streams can be assigned a priority to avoid multiple streams competing for the same resource. However this was considered to be rather complicated.

As you can see, it has been a-patchy (see what I did there?) journey for HTTP. Also, all HTTP versions thus far have been based on TCP, and security was optional (HTTP/HTTPS). HTTP/3 However, is based on UDP (In respect of time I’m going to assume everyone knows the difference between TCP & UDP), Yep, UDP, does the title picture make sense now? And security is no longer optional. HTTP/3 does not exist in a non-secure form.

Is anyone confused about QUIC & HTTP/3?. QUIC, Quick UDP Internet Connections, is an alternative to TCP, It was built on UDP to be faster than TCP and to have a low operating overhead. QUIC was built by Google, and Chrome used QUIC since 2013 to communicate with their services. HTTP/3 uses QUIC instead of TCP for communication. It also implements TLS1.3 encryption, eliminating the bolted-on security model used by HTTP(S). Initially it was called HTTP-over-QUIC.

Before we proceed, let me give you a taste of what we are dealing with here.

HTTP/2 vs HTTP/3

Focus on the highlighted values. Do I have your attention now? What I’m using here is a very simple REST API written in Go¹ fronted by nginx². The API generates a random output of about 100KB. If you look at the values above, the biggest difference is in the connection time. (You can find all the scripts I used in this article at https://github.com/charith26/quic-test)

The reason for the performance improvement is in the way a connection is established in QUIC over TCP.

The figure on the left represents how a TCP/TLS connection is setup. Note the number of round trips needed before the application and server can start communicating.

QUIC has a rather different approach to this. It starts by the client sending an incomplete (inchoate) CHLO with a random connection ID. The server rejects it along with the Diffie-Hellmann Public Value (PUBS), certificate server info (CRT), a signature value generated using the server’s private key, server identifier (SCID), and a source-address token (token). Now the client has enough information to send an encrypted message to the server (Complete CHLO + Data), the complete CHLO will contain clients Key info. With this, the server will authenticate the client and respond (SHLO + Data). This is the 1-RTT (Round Trip Time) flow. Once authenticated, the client can communicate using the 0-RTT flow.

The significance of the 0-RTT flow is that, once authenticated (1-RTT), QUIC allows the usage of the same security credentials eliminating the requirement for a new handshake, which is time-consuming. Only after an inactive period (timeout), should the connection authenticate again.

Apart from the improvements in the connection establishment and security aspect, QUIC also addresses head of line blocking (HOL) to a certain extent. In TCP, if a packet fails, all the remaining packets are held up until the erroneous packet is retransmitted (this called HOL). The workaround was to set up a new connection, which was self-defeating since we are going back to multiple connections to load a single page. In QUIC, HTTP streams can be mapped to quick transport streams, which share the same connection eliminating the need for a new handshake.

Connection Migration is a pretty neat little trick QUIC will be bringing to the party. In TCP, the connection is bound to source and destination IP addresses. Remember the connection ID and token involved when setting up a QUIC connection from above, a QUIC connection is based on these values, hence allowing to change the source and destination IPs without affecting the connection. This will be particularly important when a mobile device is switching between a cellular network and wifi. Imagine walking to a location where you have already used wifi while downloading a file on you cellular network, with connection migration, your download will continue, uninterrupted, over the wifi network.

HTTP over TCP was more or less built for the wired network, not for the more unstable, spike-prone wireless networks. Having ad-hoc spikes causes congestion, and to be able to handle congestion, TCP employees a congestion control algorithm, which in turn can become the problem itself, i.e. bufferbloat. QUIC employs a pluggable interface for congestion control algorithms. This allows rapid development and experimentation with new algorithms. QUIC sitting on the application layer makes it easier to roll out new features and fixes.

In summary, I’m sure folks were as excited as I am now when HTTP/2 came out, that’s how tech is. QUIC, HTTP/3 boasts a plethora of major and minor improvements over current versions of HTTP and TCP. Only time will validate the impact of the improvements. There is still very little public information on the production use of QUIC and it’s capability in load handling. However, the early adopters doesn’t seem to be slowing down and that is a promising trend. One thing that stands out to me more than anything else is the fact that it is open source which means it will be owned by the community and will continue to improve over time. And since it partly sits on the application layer, will make it easier to continuously improve.