HTTP/3: Come for the speed, stay for the security

Google’s campaign to nudge the web towards faster performance took a big step last month. Key personnel at the Internet Engineering Task Force (IETF) suggested basing the next version of a core protocol on technology that originated with the search giant.
The IETF is responsible for signing off many of the key standards underpinning the internet and the web. One of them is the hypertext transport protocol (HTTP), which is how browsers fetch web pages.
In 2013, Google introduced a new experimental protocol called Quick UDP Internet Connections (QUIC), that would make HTTP requests faster and more secure.
Google proposed the idea of running HTTP requests using QUIC in 2016. The IETF evolved the protocol, producing what amounts to its own version (sometimes called iQUIC, in contrast to Google’s gQUIC).
The IETF has been working on running HTTP over QUIC for a while. On 18 October, Mark Nottingham, chair of the HTTP and QUIC working groups, suggested that it was time to call that specification HTTP/3. This would, effectively, make it the next major version of HTTP, and it represents a significant change.

A QUIC-ker internet

QUIC seeks to make network connections faster by reducing the number of round trips that one computer has to make when downloading information from another over HTTP.
Round trips happen in HTTP requests because the client (typically the browser) has to establish a connection with the server. Think of it like asking a new work colleague for something. First, you have to introduce yourself, explaining who you are and what you do. Then you have to wait for them to greet you back and acknowledge you before you make your request. Later, after getting to know them, you could just pop your head round the door and say “hey, Derek, can I borrow that file?” And Derek would just hand it over because he knows you and trusts you. QUIC works the same way.

The protocol has some other tricks up its sleeve. One of them, drawing on earlier work in HTTP/2, uses multiple connections at once. It also estimates the bandwidth that connections will use in either direction in advance, to try and minimize congestion by spacing packet transmissions accordingly, and uses error correction to minimize retransmitting lost data.
QUIC also uses version 1.3 of the encryption and certification standard TLS, which became an official “proposed standard” of the IETF in August 2018.
Unlike HTTP/2, TLS 1.3 isn’t optional though. If you want the extra speed of HTTP/3 you’ll have to sign-up to the extra privacy and security of TLS 1.3 too.
One big step that Google took when designing QUIC was to abandon the core network mechanism for transporting traffic, known as the Transmission Control Protocol (TCP). This has been a staple for internet communications since the mid-1970s and has underpinned the web since its beginning. Instead, QUIC switched to the alternative User Datagram Protocol (UDP), which was designed for low latency communications. Effectively, UDP just concentrates on sending packets, avoiding the extra functions that TCP offers such as re-sending lost packets and reassembling packets in the correct sequence. This makes it faster.
The wish to move to UDP is the reason that Google didn’t continue with SPDY, an earlier protocol that it also proposed. This was a TCP-based protocol, also designed to make HTTP transmissions faster. This forms the basis for HTTP/2, ratified in 2015, but Google pulled support for it the same year after deprecating it.
Google estimates that traditional TCP-based HTTP requests take about 100ms because the client has to establish a connection with the server before it asks for anything. This gets worse when using TCP and TLS for extra security, taking up to 300ms. On a QUIC connection, it will initially take the same time as a TCP connection. When the client has spoken to the server before, it will take 0ms, because there will be no round trip. The server already knows who the client is, so there’s no need for an introduction.
The IETF draft for HTTP over QUIC was published on 24 October. Ratifying it will take time. If and when it happens, the whole world won’t suddenly move over to HTTP/3. However, those websites that do will be able to serve requests to compliant browsers more quickly and securely.