HTTP/3 and QUIC: What, Why, and What’s Next

Thank you to the organizers for inviting me to speak with you about HTTP/3 and QUIC.

And thank you all for joining me here.

Over the next 20 minutes, I will give you a high-level overview of the HTTP/3 and QUIC protocols, which you may have heard about in various places, but if you haven't that's all right.

You don't know details.

That's all right.

I will talk about what these protocols are, and I will also give you a sense for where they are in terms of the world of standardization, deployment and implementation.

So let's get started.

I'm going to start off with a very quick overview of the history of QUIC.

So QUIC started as an experiment.

Basically it was an experimental protocol at Google which was deployed starting in 2014.

And this was primarily used between Google servers and Chrome at the time.

And then mobile applications later on as well.

And it showed significant performance improvements as a result of which it became about 35% of Google's egress traffic.

This is just the amount of adoption that happened within Google pretty rapidly.

And it was useful.

Quite significantly beneficial to applications and therefore it became an effort at the IETF to modularize, standardize this protocol by involving a large number of vendors and companies and other folks in the industry to take this experiment from an experimental in -house protocol to a standardized protocol that could be used by many folks, all folks on the internet.

Now a quick preview and good news hot off the press.

The QUIC RFCs were just published.

And so that is absurdly exciting news and I'll talk about that towards the end of this talk.

Now let's get into the details of QUIC, and HTTP/3 themselves.

So what is QUIC?

Again, an overview, QUIC is basically a new transport protocol.

And this is something that's basically like TCP.

TCP is the existing web transport protocol that we know and love.

But QUIC is built for the needs of today's internet and the modern web.

An example, one small example is that it combines transport and crypto handshakes.

And this is with the intent of reducing or eliminating handshake latency, because latency has become very important now as compared to decades ago when TCP was designed.

So that's what we've got here.

This is QUIC is a new transport protocol.

QUIC is UDP-based because UDP works through most networks.

But also because UDP does not offer very much in terms of services, QUIC ends up having to recreate a lot of what TCP already builds on top of UDP.

This includes things such as loss recovery, condition control, and so on.

So this is all built into QUIC.

However work has been to learn from TCPs mistakes from TCP's experience and make it so that quick is better than TCP in these ways.

And finally, QUIC has encryption baked in.

All the data and metadata of QUIC are protected and it uses TLS 1.3, for key negotiation.

So that in a nutshell is QUIC.

Now onto HTTP/3.

What is HTTP/3?

It is simply HTTP over QUIC.

So basically we know HTTP/2, we love HTTP/2.

There are features in HTTP/2 that we use, but HTTP/2 runs on top of TCP.

It is actually tied.

The protocol is tied to TCP.

So when we want to change the protocol underneath HTTP/2, to be QUIC, we need to change the mapping as well.

What is HTTP/3?

HTTP/3 is simply HTTP over QUIC We know HTTP/2.

We love HTTP/2.

And it offers us services that we want to use.

And however HTTP/2 is tied to TCP.

The protocol itself is tied to TCP and to move those HTTP services onto QUIC, we need to change the wire format.

And that is what HTTP/3 is, it's simply HTTP Services such as request multiplexing, header compression, push, things like that.

But running on top of QUIC.

That is a small exception.

Is that that priorities is not there, but this is basically also being dropped in HTTP/2.

And as being redesigned for both of these, but effectively, HTTP/3 is designed to have feature parity with HTTP/2, but runs over Q UIC . Pictorially, this is how it looks.

So this is our web stack, the TCP web stack that basically has HTTP/1 & HTTP/2 running on top of TLS that runs on top of TCP on top of IP- or internet.

And here's what the QUIC stack looks like.

That has HTTP/3 assume that offers the same services as HTTP/2.

But that runs on top of QUIC, that runs on top of UDP.

Now, QUIC and TLS in this case, are doing a dance here, they're working together with each other and they're tied at the hip.

It's not a strictly layered composition here.

QUIC uses TLS 1.3 and TLS uses QUIC as well to carry its messages.

So there's a simple way to think about this would be that QUIC and TLS are tied at the hip and you can't simply remove TLS and expect QUIC to operate.

It won't.

So that's how this looks and then the TLS and QUIC marriage is important because assures you that QUIC and TLS, QUIC was built with encryption in mind and is built to work with TLS and encryption as a protocol.

So this is all fine and good.

This is what the protocols are, and this is how we built them, but why should you care?

I'm going to address this in a little bit of detail, and I'm going to give you three reasons why you should care.

I'll start with the first one-latency.

At a high level, QUIC seeks to eliminate latency in various ways, in ways that it can control them.

And the first way that it tries to eliminate latency is by reducing the latency of new connections to sites.

So let's look at this in just a bit more detail here.

Here's what a TCP connection, a first TCP connection to a site looks like, to a server, looks like.

There are two rounds of times that are spent in handshake the first one a TCP handshake followed by a TLS handshake, after which application data, web data, can be transferred over this.

With QUIC, remember that I told you that QUIC and TLS are tied at the hip in some ways.

So what that means is that we are able to leverage the fact that they can work together.

And we do the handshake together.

So QUIC and TLS handshake happened together in the same amount of time, followed by application data.

That saves us one round-trip time in the handshake.

On a subsequent connection to the server, TLS offers you the ability to combine application data with the TLS handshake.

And that means we are able to reduce in the TCP world, on subsequent connections to the same server it is possible to reduce the handshake overhead by one round-trip time.

That still means you're still left with one roundtrip time.

In QUIC, however, again, because of transport and TLS handshakes are combined, that ends up becoming combined with the application data as well.

And we are able to transmit application data from the get-go avoiding all round-trip time overhead of the handshake.

So that's basically your elimination of handshake latency that you get in QUIC, and QUIC, also a limits head of line blocking.

Without getting into the detail here.

I will simply say that is, the use of streams in QUIC gives you the ability to avoid head of line blocking that is present and prevalent in TCP and TLS.

The second benefit that you get for using QUIC is that it is fundamentally as a part of earlier and encrypted transport.

It is primary privacy and encryption are fundamental to quick and connections are effectively predicted from tamper and disruption.

And most of the headers are not visible to anybody, but the two end points that are part of the communication.

So why is this important?

Let's look at this and just a bit more detail here.

So with the traditional web stack, this is what your headers look like, your HTTP headers, your TLS headers, your TCP headers are in this diagram here - of which when you run it in HTTPS, which is encrypted with TLS, basically, you're able to encrypt a chunk of the data and some of them are the greater part here is visible to third-parties, but are tamper-proof, which means that third-parties cannot change them.

But there's a big chunk of the header that is still available, visible and can be modified by third parties.

So is this a problem?

Isn't your data still protected?

The HTTP stuff is still encrypted.

It is not visible and it's still protected isn't it?

Well, it depends on the context, how much you can leak with the stuff that's already available.

For example, a recent study showed that you can just from observing traffic on the wire identify Netflix videos from an HTTPS stream.

And this is merely by looking at the TCP headers.

So TCP headers leak information.

They do leak information, whether they can be used effectively or not is dependent on the context.

And as evident here, they can be quite effectively used.

So yes, it does, metadata does matter and QUIC headers which look like this- this includes the UDP header, as well as the quick header and payload, basically in QUIC, we encrypt as much of it as we possibly can.

We have to leave some of it visible.

But that's still tamper-proof and there's some of them are the UDP headers we can't predict because quick runs on top of UDP.

And so that's still visible and modifiable by the network.

However, QUIC encrypts as much of the header as is possible.

That's the second big benefit that you get with using QUIC.

And finally, the third big benefit is that QUIC makes your connections more resilient.

What do I mean by this?

I'll give you two ways in which QUIC improves connection resiliency.

The first one is connection migration.

You may be, everybody's familiar with the parking lot problem, even if you don't call it that, the problem is this.

Basically you are sitting at home connected via wifi to a server, and then as you move out of the house you start to lose wifi signal, and with it, your TCP connection dies.

So when you move from wifi to a cellular network, you effectively have changed your client's IP address.

And with that, you've lost your TCP connection.

QUIC, however, allows you to move your connection across IP addresses.

And as a result, your connection moves with you even as you change your connectivity.

And applications will seamlessly get this kind of migration because QUIC offers it to applications seamlessly.

This is one way in which.

QUIC improves connection resiliency.

The second way in which QUIC improves connection resiliency is by improving general performance.

And I'll say loss recovery here specifically, but in general, QUIC improves performance of connections over poor networks or connections that are traditionally considered to be of bad quality.

Let me give you some data here, to show what I mean.

Like I told you earlier when Google deployed the version of its internal version of QUIC, the experimental version of QUIC, that basically showed large improvements for applications and Google published some data in 2017, showing the improvements.

And these improvements is divided.

The graph that I'm showing you here is basically on the x-axis is simply showing you various metrics various applications and metrics and the y-axis shows you percentage reduction, which means that if these metrics are latency metrics, latency, or rebuffer metrics, both of each reducing them means that it's better.

So more is better on this graph.

But this is in South Korea, where the connectivity is really good.

The round trip times are low and loss rates are low.

When you get to a country like the US, which has slightly worse connectivity, you start to see that QUIC offers more improvements.

The improvements that you see for using QUIC for users in a place like the US such as higher roundtrip times, higher loss rates is more.

But it is when you get to a country like India, where the roundtrip times are much larger and the loss rates are much higher that you see the bulk of the benefit.

So this shows that as networks get of poorer quality, become poorer in quality QUIC is able to help.

So this is a this is what I meant by QUIC improves network resiliency in connections over bad networks.

In addition to these immediate benefits that you get for doing QUIC in terms of performance, and as I said, transport improvements, so to speak there are also higher level evolutionary or architectural benefits that are available for using QUIC.

And these are important.

So I'm going to walk through just a few of them here.

At a high level QUIC is designed to be a userspace transport.

Now this doesn't mean that QUIC cannot be run in kernel space.

All it means is that we've designed QUIC to be available and usable and buildable, so to speak in userspace.

And that's actually, most implementations right now are running in userspace.

Why does this matter?

It matters because it gives application developers control, more control.

In terms of the evolution of implementations, in terms of how to tune implementations to their needs and so on.

And it also enables architectural exploration.

It makes architectural exploration easier.

For example, how do you use QUIC in data center settings, for example.

How can you, how can you change the transport to be different and do different things in other settings?

It makes it easier to do those kinds of explorations.

QUIC is also built to to have agility.

Now this is not guaranteed, but at the same time, we've tried to bake in mechanisms such as versioning, encryption and greasing to make it so that new features can be deployed rapidly in QUIC.

We are already seeing this happen.

For example, datagrams for QUIC is a new feature and it has shows a lot of promise and that's already starting to happen there.

And finally at an ecosystem and sort of infrastructure level, we believe that QUIC is poised to become a substrate for a new wave of internet and web innovations.

We're already seeing this happen with MASQUE and WebTransport, and we believe that this is going to continue happening.

This is all, this is basically my pitch, so to speak for HTTP/3 and QUIC.

But where is the world right now?

The world is actually in a very good place.

With the with the idea of QUIC, like I said earlier, just as of the last week of May, 2021, which is like just weeks ago QUIC became an RFC.

It's now published as RFC 9,000 with in the suite of other RFCs that support it.

HTTP/3 will be published soon.

There are several implementations, already, many vendors independently have been building QUIC for years now.

and and there are many deployments already in place.

The biggest deployments are Google and Facebook right now, but that's changing dramatically and rapidly.

However Google and Facebook already have deployed QUIC for a majority of their traffic.

I'll make a pitch here for our implementation and deployment at Fastly.

As a Fastly customer, you can test HTTP/3 today, if you want at Fastly.

But as I said earlier this is something as you may have noticed as well, that this is something that requires both clients and servers to change.

This is basically a protocol that needs both ends to change.

QUIC and HTTP/3 both require both ends to speak the same language.

So we need not just servers, but also clients to speak this.

So what is the client state of the world?

Browsers-actually-it's available in browsers for the most part.

Slightly different degrees in terms of what's default on, in, in different browsers.

Chrome, for example, is default on right now for almost all users.

It just closed because it uses Chromes networking stack and it should be there soon.

Firefox and Safari are building their own stacks, and it's still a little bit raw there, but that's also moving rapidly, that state of the world is changing rapidly.

Browsers are getting there.

In terms of platforms, it's a little bit more of a mixed bag.

There's - it's available as an experimental platform feature in Apple platforms.

In Microsoft, in Windows it's available as again the implementation is a separate implementation and it is already being piloted for internal use at Microsoft.

For Android, it's not clear what the plan is.

At the moment there is no platform support on Android, but applications that are running on Android can use the Chrome networking stack, which is available as a library called 'cronet' to use QUIC on Android platforms.

That's all I've got for you.

I will leave you with two key takeaways.

The first one is that after a lot of years of work QUIC and HTTP/3 are finally here and they are rapidly getting deployed.

So if you have a Web property, consider moving it onto HTTP/3 today.

Thank you so much, folks.