HTTP/3 Replaces TCP with UDP to Boost Network Speed, Reliability

Getting the performance and security benefits of HTTP/2 for sites and services meant making architectural changes because it upended principles like sharding that had been used to improve web site performance; that may be why only around 35 percent of websites currently use HTTP/2.

HTTP/3 doubles down on that, offering very similar features but replacing TCP with UDP. This time more fundamental changes to networking infrastructure may be required to take advantage of the better performance over poor connections and mobile networks, but for most developers, the change will be transparent.

HTTP/3 is the third major version of the protocol and it includes TLS 1.3 and a new transport protocol called QUIC (Quick UDP Internet Connection); based on a 2013 protocol originally designed by Google, there are now multiple contributors and companies involved through the Internet Engineering Task Force (IETF).

Unreliable Is an Opportunity

Abandoning the TCP connections that HTTP has always used for UDP isn’t as strange a decision as it might seem. The U is sometimes expanded as “Unreliable” rather than User Datagram Protocol because it doesn’t give guarantees about message delivery or packet order. But with today’s networks, that’s actually an opportunity to improve performance for the multiplexed connections that HTTP/2 introduced. “With HTTP/3 we’re going to build a new reliable protocol on top of what is the same old unreliable internet,” John Graham-Cumming, chief technology officer of Cloudflare, told the New Stack.

HTTP/2  makes better use of network bandwidth by sending multiple HTTP requests over the same connection allowing applications to process requests concurrently. But these gains are realized only when the network is working perfectly. “You can maximize your throughput and bandwidth because TCP will work out the maximum speed it can go and all the parallel connections go at the fastest speed they can,” Graham-Cumming said.

That’s great until there’s a hiccup in the network connection, like network congestion or moving from one cell to another on the mobile network and a packet gets lost. “TCP guarantees that the order in which packets are sent is the order in which received by the app — so if you miss one, everything has to stop until that particular packet gets retransmitted. If you multiplex multiple requests onto a single TCP connection, then all those requests have to stop and wait even though the lost packet might affect only one of them.

This ‘head of line blocking problem is inherent to TCP and using UDP fixes it by allowing the application to control the retransmission of packets, Graham-Cumming explains. “It can say ‘that packet is missing but it only affects this one stream of data and the other streams of data can keep going’.” That makes QUIC more robust in poor network conditions.

The connection migration proposal for HTTP/3 could extend that robustness to moving between different networks, like from Wi-Fi to mobile broadband, which usually breaks the network connection because your IP address changes. “With this proposal, the identifier between you and the server would not be the IP address but an identifier within the protocol itself. That would allow you to restart the whole connection automatically on the new network, so you could go from Wi-Fi to a mobile connection seamlessly. Some of the assumptions of the original internet are that there are fairly fixed connections and we’re now moving into a very mobile heterogeneous world.”

HTTP/3 also integrates TLS directly, and the extra control that QUIC has over packet transmission has advantages here too, explains Graham-Cumming. “As things get sent across the internet they get broken into packets; within TLS there’s a concept of a buffer of data that gets transmitted. If you want to be really efficient, you want to line all these things up; here’s a request and I’m going to encrypt it and transmit it across the internet so it all gets received in one go and doesn’t get broken into smaller packets and some of those don’t get delayed. If you control all levels of this, if you just assume the internet is an unreliable way of sending packets, then you can control the order in which you send things, you can control how you encrypt them and how those encrypted blocks get transmitted.”

The initial connection to an HTTP server will be faster because HTTP/3 takes out one of the round trips that’s usually required to establish that connection securely explains says Mozilla principal engineer Martin Thomson, one of the editors of the QUIC specification.

“With TCP and TLS, a connection setup starts with a TCP handshake: client sends a SYN, server responds with SYN+ACK, client finalizes with ACK. Then there is a TLS handshake — which takes another similar three-message exchange — before any requests can be sent. QUIC compresses that to a single exchange most of the time. A key feature is 0-RTT which allows the client to send requests immediately; that’s an option with TCP and TLS but you still have to wait for the TCP handshake to finish.”

Secure by Default

Integrating TLS also improves security because authentication and encryption are provided by the networking protocol rather than by a higher-level protocol like TLS — and with TLS built into HTTP/3, using it isn’t optional either. “The industry is trying to move to having everything be secure by default,” notes Graham-Cumming. Instead of showing a lock when a site uses HTTPS, browsers now warn you when a site doesn’t have an encrypted connection. HTTP/3 and QUIC are another move in that direction.

“Much more of QUIC is encrypted,” explains Thomson. That includes metadata that attackers could try to use. “Aside from a few bits that help identify packets as QUIC packets, the only part of a QUIC packet that is unencrypted is an opaque identifier for the connection. That includes things that TCP and TLS can’t protect, like acknowledgments (‘I got 5 more bytes from you’).”

Thomson also argues that the encryption will actually simplify deploying QUIC. The complexity of deploying new protocols onto the firewalls, routers, NATs and other network devices that would need updating has stymied efforts to create new, more efficient transport protocols and delayed adoption of TLS 1.3 in browsers. “This is part of what makes it possible to deploy QUIC. The internet tends to interfere with new protocols, and encryption is what will protect QUIC from meddling.”

That’s another reason why UDP is a good choice, he maintains. “a new protocol can’t deploy directly on top of IP, like TCP or UDP can, because that requires too much of the internet to be updated. Consider the prospect of replacing or upgrading every router in every house that wants to use this new protocol. UDP is ideal in this case because it does so little. It’s very lightweight, and so allows us to build all the necessary pieces on top. The main downside for UDP is the small number of networks that have been shown to block or degrade UDP. In these rare cases, we have HTTP/2 to fall back on.”

When users visit a site, their initial connection will be over HTTP or HTTP/2 and the server will offer HTTP/3 as an alternative; browsers that understand the header offering that connection will remember it for the next visit but older browsers and devices will continue to use the older protocol. “We expect HTTP/2 and 1.1 to be around for a long time,” predicts Graham-Cumming.

Network Changes

HTTP/3 might have its name, but it’s still in development; Graham-Cumming suggests it will be a few months before the situation stabilizes. Although there are HTTP/3 endpoints available for test on services like Cloudflare, Facebook and Litespeed have demonstrated interoperability between their HTTP/3 implementations in November 2018, browsers and web servers don’t yet have support for HTTP/3 (beyond Chrome’s experimental support for Google’s original version of QUIC).

Once they do, service providers and hosting companies will follow, but older networking equipment may need to be updated. “NAT traversal for UDP is not as well developed as for TCP and some home routing devices make assumptions about what UDP is used for streaming video but not the web,” Graham-Cumming said.

If you host your own web servers, you’ll have more work to do, says Thomson. “Server admins will find that QUIC requires more than just software upgrades. Enabling UDP will require new support in networking and load balancing infrastructure.” Network operators may need to look into smarter layer 4 load balancing solutions that can be implemented in software, like Facebook’s Katran project.

But because HTTP/3 is designed to fix problems with HTTP/2, optimization you do for HTTP/2 like changes to domain sharding will apply automatically when it is available. And when it is, Graham-Cumming expects it to move the state of the web forward. “What we’re hoping for is faster downloads for the web, and for APIs. It should make the internet more reliable and faster, and hopefully, for developers, we get richer APIs and web applications because we can rely on the internet more because of this new protocol.”