The IETF has renamed HTTP over QUIC, HTTP/3
HTTP/3 is here, kind of. On Monday the IETF revealed it would be renaming the HTTP-over-QUIC experimental protocol as HTTP/3. HTTP-over-QUIC is an HTTP rewrite that replaces TCP with QUIC. We’ll get into what that means a little more later.
If this seems a bit premature, it’s not entirely out of line with how the IETF historically operates. Just like TLS 1.3 was rolled out before every website had even switched to TLS 1.2 (though by August the vast majority have) and SHA-3 is already established despite the fact SHA-2 came into use just a few years ago. So, despite the fact just 31.2% of the top ten-million websites are even using HTTP/2, HTTP/3 is already on the horizon.
Already 1.2% of the top 10-million support QUIC. That’s about 120,000 sites.
So, what is HTTP-over-QUIC – or I guess now it’s HTTP/3 – and what does this new protocol mean for the SSL/TLS industry?
Let’s hash it out…
What is HTTP/3 (a.k.a. HTTP-over-QUIC)
HTTP-over-QUIC is an experimental Google protocol that is an HTTP rewrite that swaps in QUIC for the standard TCP that has traditionally been at the heart of the internet.
TCP is the Transmission Control Protocol, along with IP (Internet Protocol) it has been one of the basic rules defining the internet for years. It’s old enough that it has a three-digit RFC number. That’s an IETF joke, TCP was defined in 1981. TCP is a connection-oriented protocol, it is meant to provide error-free data transmission and it governs how data is broken down into packets and disseminated to the other end of the connection.
Unfortunately, the error-free transmission feature is a double-edged sword because it can add latency to a connection. It has to ensure that it receives every packet and it runs check-sum hashes to verify this. Briefly, hashing is a one way function that helps to verify authenticity. If the data has all arrived as intended the hash value produced by the check-sum will match the known hash value. If not, TCP will make the party on the other end of the connection send it again.
QUIC is an acronym for Quick UDP Internet Connections. That begets the question, what is UDP? UDP is the User Data Protocol. The best way to explain this is to go back to the error-free transmission we just discussed with TCP. UDP is another connection protocol, but it doesn’t provide for error-free transmission. Instead it facilitates a connection (sort of) that is low latency on account of the fact it tolerates some data loss.
It might be illuminating to apply this to real life. TCP is ubiquitous, the vast majority of traffic across the internet is TCP. And that’s a good fit for situations where data fidelity is important. When you see a video buffering on YouTube or you get the pinwheel on Netflix while a show loads—that’s a TCP connection. Your device is essentially saying, “I need to catch up on this data before continuing.”
Where UDP is preferable is when you need to send a constant stream of real-time data and latency is not going to be acceptable. A few obvious contexts would be Voice over IP (VoIP), video messaging applications like Skype and video-gaming networks. In this case, UDP just throws a constant stream of data at the party on the other end of the connection and if some gets missed the data will eventually catch up. This is called best effort.
QUIC is an experimental protocol designed by Google. That may seem odd, but Google’s SPDY eventually became HTTP/2, so this is not unprecedented, either. QUIC is essentially Google’s attempt at rewriting TCP, it combines HTTP/2, TCP, UDP and Transport Layer Security (TLS) amongst others. The goal is for QUIC to replace both TCP and UDP. It’s encrypted by default, which means it’s faster and more secure than its predecessors. This is largely due to the fact that it uses TLS 1.3 (RFC 8446) and leverages its improved single round-trip handshake and zero-round-trip resumption feature.
Another substantial gain for QUIC is improved congestion control and loss recovery. Packet sequence numbers are never reused when retransmitting a packet. This avoids ambiguity about which packets have been received and avoids dreaded retransmission timeouts. As a result, QUIC outshines TCP under poor network conditions, shaving a full second off the Google Search page load time for the slowest 1% of connections. These benefits are even more apparent for video services like YouTube. Users report 30% fewer rebuffers when watching videos over QUIC. This means less time spent staring at the spinner and more time watching videos.
While initially only Google’s servers were supporting HTTP-over-QUIC, earlier this year Facebook added support, too.
What does this mean for the SSL/TLS Industry?
In terms of how this plays with the current SSL/TLS ecosystem, it won’t have that much of a direct impact on the use of digital certificates as TLS is baked right into the protocol and authentication will still need to be handled by trusted certificate authorities and PKI.
The biggest positive that may come from HTTP/3 is that it will pressure websites into supporting TLS 1.3 faster than they may have otherwise.
But, that still may not be for a while given that less than a third of the internet is even using HTTP/2 and we still have a small segment of stragglers clinging to HTTP (as well as a few people willing to die on that hill).
So HTTP/3 is here… sort of.
As always, leave any comments or questions below…