TCP or UDP?

This is a debate you hear a lot these days, and though the question is valid it is also misleading. We discussed TCP in Chapter 3 when looking at the underlying motivations behind h2. To quickly recap, TCP is an IP datagram–based protocol that provides an agreed concept of a connection, reliability, and congestion control. These are the elements that allow TCP to be dependable and work consistently in a crowded internet. UDP (User Datagram Protocol), on the other hand, is much more basic. In this protocol datagrams (packets) are individual with no relation to any other UDP packet. There is no “connection,” no guarantee of delivery, and no ability to adapt to different network conditions. It is perfect for building simple protocols like DNS that have small individual queries and small responses.

In order to make an application based on UDP be something that our next generation web can be built upon, we need to implement the idea of a connection, introduce reliability, and have some sort of congestion control. In other words, we need to reimplement much of what TCP already give us. So, if at the packet level these two protocols are mostly similar, and given the fact that in order for UDP to be useful for browsers we need to reimplement much if not all of the TCP stack, what is the motivation for a move from TCP to UDP? Why not just make changes to TCP and be done with it?

The answer has to do with where TCP is implemented. Most modern operating systems have their TCP stack in the kernel. It was long ago placed there for performance reasons. Changing the kernel is difficult, however. It is not something that a developer of the next great browser can generally do on her own. Kernel changes come from the operating system vendor and require an OS update to take effect. Since updating an operating system is a very high-overhead task when compared to upgrading your browser, the inertia of such a change is large enough to make such changes few and far between. When you consider that in order to work properly, much of the infrastructure on the internet would have to be updated as well, you can see that though revising TCP may be possible, it is not terribly practical.

So why would someone want to essentially reimplement the TCP stack in user space based on UDP? The short answer is control. By moving the TCP stack into user space—for example, in the browser itself—the developer gets unprecedented control over the network stack and can rapidly develop, deploy, and iterate new versions as quickly as people can auto-update their browsers. This is the experimenter’s dream, and is the crux of the TCP versus UDP debate.

Thus the question should not be “TCP or UDP?” but rather “Kernel Space or User Space?” Keep that in mind the next time you hear someone extolling the virtues of one protocol over the other.

QUIC

Now that we have that debate out of the way we can intelligently discuss some of the technologies that are on the horizon, and even in use today.

One of the weaknesses of HTTP/2 is its reliance on popular TCP implementations. As discussed in “Inefficient use of TCP”, TCP connections are stuck in the cage of TCP slow start, congestion avoidance, and irrational reaction to missing packets. By placing all of the requests for all of the objects of a page on a single connection, you get the benefits of multiplexing, but you are vulnerable to the head of line blocking that can occur at the TCP level. A single TCP connection is still a great thing, but all great things can be improved upon.

QUIC, developed by Google, is an acronym for Quick UDP Internet Connection. QUIC takes HTTP/2, places it atop a user space resident UDP-based transport protocol (see “TCP or UDP?”), and folds in crypto, authentication, and other features to form a complete bundle of protocol goodness. Here is a description from the draft version of the RFC¹:

QUIC provides multiplexing and flow control equivalent to HTTP/2, security equivalent to TLS, and connection semantics, reliability, and congestion control equivalent to TCP.

That is quite an impressive list. HTTP/2 put great effort into keeping the underlying TCP mechanism in place. QUIC leaves those constraints behind and makes a good thing better. Newton summed up this type of progress in 1676 when he said:

If I have seen further, it is by standing on the shoulders of giants.

Sir Isaac Newton

QUIC has a number of important features that will help it pick up where h2 leaves off:

Out of order packet processing

With h2 if a packet is lost on a TCP stream, the entire connection stalls until the packet is resent and received. QUIC will allow the application layer to continue to receive and process packets from streams that were unaffected by the loss.

Flexible congestion control

QUIC’s congestion control is designed to be pluggable. This will make it extremely easy to experiment with new algorithms or even swap in different algorithms depending on real-time conditions.

Low connection establishment overhead

QUIC’s goal is to have a zero round-trip time (0-RTT) connection establishment, including encryption and authentication. Using today’s technologies (TCP and TLS 1.2) the minimum number of round-trips to establish a connection is three.

Authentication of transport details

TCP is vulnerable today to injection attacks and similar concepts that take advantage of its trusting nature. QUIC will authenticate the packet header, making such attacks significantly more difficult (if not impossible).

Connection migration

In a mobile and moving world, IP addresses may change during a long-lived connection. In a TCP world the connection will need to be broken down and reestablished. QUIC endeavors to make it possible to preserve connection semantics even when confronted by a moving client.

Though the RFC is not complete, a version of QUIC is available today in Chrome and many Google properties so you do not need to wait to try it out.

TLS 1.3

TLS (Transport Layer Security) is the Encryption and Authentication layer that HTTP/2 requires. Though it may feel that we only just moved to TLS 1.2, it is actually already approaching a decade since the RFC was published.² TLS 1.3 is currently in the works and as of March 2017 was at draft 19 of the RFC.³ It represents a significant cleanup of TLS 1.2 and most importantly for our discussion addresses some performance-enhancing features while it shores up the protocol.

The most significant proposed improvement in TLS 1.3 is a 1-RTT for new connection (down from 3-RTT), and a 0-RTT for resumed connections. This trend can be summarized as “Round-trips are bad, let’s eliminate them.”

HTTP/3?

Will there be an HTTP/3? If so, what will it be?

The answer to the first question is undoubtedly, “yes.” We are in a period of rapid experimentation and implementation of web protocols. Speed matters and has a direct effect on getting and retaining users on a website, which in turn has a direct effect on a site accomplishing its goals whether they be revenue generation, information dissemination, or human connection. In addition, implementors, web operators, and others are increasingly aware that though the internet may be a global phenomenon, internet access and quality vary greatly. Not everyone has a low-latency, high-bandwidth connection. That is all a grandiose way of saying that performance matters, and we will continue to work to approach the speed-of-light limitations of communications.

What will HTTP/3 be like is the more interesting question. HTTP/2 was inspired by the concepts in SPDY and used it as a starting point for its first draft. Will HTTP/3 do a similar thing with QUIC or will something new come along in the meantime that is better by all measures? We cannot say at this point, but it is fair to say that whatever coalesces into h3 will be faster, more reliable, more secure, and more resilient in more diverse internet conditions.

Summary

HTTP/2 is new. What that means is that the fun stuff is likely still to be discovered. We spent 20 years optimizing for HTTP/1—in fact, we built an industry around it. Some of the things that will feed into HTTP/3 are likely known, but it is probable that the best ideas are still out there to be discovered. Get out there and start using h2, push the boundaries, break things, learn—and when you are done, share. That is where HTTP/3 will come from.