A while ago, I had a closer look at HTTP/2 (from a 5G core network point of view), and how a client could detect during connection establishment if it can use this flavor of the protocol or not. The short answer to the question is that the client and the server use an extension parameter of the TLS protocol during the authentication and ciphering exchange. In the meantime, the world has moved on, and HTTP/3 has made it out of the starting gate and is already used in practice. Unlike previous versions of the HTTP protocol that use TCP, HTTP/3 is based on UDP and the new QUIC protocol, which implements TCP like flow control and a number of other improvements to speed up the simultaneous transfer of many different files that usually comprise a web page these days. And so I had the same question again: How does the browser detect that it can use HTTP/3, and, as a consequence UDP/QUIC, for a web page instead of TCP?
For a detailed introduction to HTTP/3 and QUIC, have a look at this fabulous three-part article series which goes into a lot of details of the whys and hows. So here’s my ‘long story short’ version with the main points: In the center of the whole endeavor, HTTP/3 and QUIC aim to speed-up page load times with two main features:
First, QUIC and HTTP/3 offer an elegant way to deal with potential ‘head of line’ blocking. If a TCP packet goes missing early on in the transmission, it can stall the transmission of all files a web page consists of. While TCP is only aware of a single byte stream, a QUIC connection can consist of several independent streams. If a TCP packet goes missing, all subsequent packets are buffered until the missing data is received. With QUIC, only the stream (i.e. the file) for which intermediate data is missing, is buffered, while all other streams just go ahead and deliver data to the application. This way, more parts of a web page can potentially be rendered, even if some files are still not delivered due to the missing intermediate packets waiting for retransmission.
Another feature that decreases page loading times is to combine the handshakes required for connection, authentication and ciphering activation. So far, this was a sequential process, i.e. a TCP connection setup required one round trip through the network, followed by two more round trips for TLS 1.2, or one round trip for TLS 1.3. QUIC combines these two handshakes into a single round trip! In other words, the connection is opened and authentication + ciphering is negotiated in one go!
And that’s the crux of the matter: How can the browser know that instead of TCP and HTTP/2, it can use UDP and HTTP/3 instead? The answer: Today, it can’t! The only way to find out that HTTP/3 and QUIC are available is to first establish a TCP + HTTP2 connection to the server. In the HTTP response header, the server can then tell the browser in the new ‘alternative service’ (alt-svc) parameter that it also supports HTTP/3 and QUIC. The screenshot above shows how Youtube signaled this to my browser when I had a go with Firefox. Firefox then goes ahead and opens a UDP/QUIC/HTTP3 connection for further content. Very nice!
As the article series I linked to above points out, there are standardization activities for new DNS record fields underway to signal QUIC/HTTP3 support during the DNS resolution phase. So once this is in place, clients can open UDP/QUIC/HTTP3 connections straight away. Let’s see how long it will take for this to be implemented in practice.