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.

Image of the Fastly logo

The State of HTTP/3 and QUIC

Jana Iyengar
[email protected]
©2019 1 Confidential

A QUIC history

A QUIC history

Experimental HTTPS transport at Google, deployed starting 2014
Between Google services and Chrome / mobile apps

> 35% of Google's egress traffic (> 7% of Internet)
Improved Youtube and Search performance

IETF QUIC working group formed in Oct 2016
Modularize and standardize QUIC
(RFCs were published just weeks ago!)


Is a new transport protocol
built for needs of today’s Internet and the modern web
not what TCP was built for
combines transport and crypto handshakes for latency

Is UDP-based, because UDP gets through most networks
QUIC re-creates TCP services from scratch
(loss recovery, congestion control, flow control, etc.)

Has encryption baked in, data/metadata are protected
uses TLS/1.3 for key negotiation



Has feature-parity with HTTP/2
request multiplexing, header compression, push

… except for priorities
which is being dropped in HTTP/2 by HTTP working group
a common scheme is being devised for HTTP/2 and /3

Table of a stack of four layers labelled: (from top to bottom):

Image of two parallel stacks, each with four layers which are united by a common row at the base. The base layer is labelled: IP On the left stack, the layers are labelled (ascending from top):

On the right stack, the layers are labelled (ascending from top):
TLS 1.3
The TLS 1.3 layer is embedded within the QUIC layer, and the QUIC layer is shaded red to delineate it from the other layers which are all shaded in yellow

Why should you care?

Low latency
eliminates latency of new connections to recently visited sites
eliminates head-of-line blocking in TLS and TCP

Low-latency handshake

First connection to server

Image of a diagram labelled:TCP + TLS/1.3

The diagram shows two parallel lines labelled: client and server A series of diagonal lines zigzags between the client and the server representing Response, Fin Request, Hello. Cert, Fin, Hello, SYN/ACK, SYNThe area between Response and Fin, Request represents data, and the area encompassing the rest of the sequence represents the handshake

Low-latency handshake

First connection to server

Image of a side by side diagram labelled:TCP + TLS/1.3 and QUIC

The diagram compares the server connection sequences under TCP+TLS/1.3 and QUIC. Both diagrams show two parallel lines labelled: client and server A series of diagonal lines zigzags between the client and the server representing Response, Fin Request, Hello. Cert, Fin, Hello, SYN/ACK, SYNThe area between Response and Fin, Request represents data, and the area encompassing the rest of the sequence represents the handshake. In the QUIC diagram, TLS and QUIC do the handshake simultaneously, as opposed to the two rounds of time spent in handshake in the TCP +TLS/1.3 diagram

Why should you care?

Low latency
eliminates latency of new connections to recently visited sites
eliminates head-of-line blocking in TLS and TCP

Encrypted transport
encryption and privacy are fundamental to QUIC
connections protected from tamper and disruption most of the headers not even visible to third parties

Resilient connections
connection migration fixes "parking lot" problem

Encrypted transport


Image diagram of a traditional HTTP with TLS/TCP stack. The base layer represents the application data (HTTP headers and payload) and is quite large. A small bar reading: length is inset in the base. Next up is a layer delineated into: type, version, and length. Above that is (options). Above options are checksum and urgent pointer. Above checksum is hlen and flags; above urgent pointer is window. Above this layer is acknowledgement number, above that is sequence number, and the top layer represents the source port and destination port.

The same diagram stack from the prior slide, here with the base layer or application data blocked out, and the 'length' inset as well as the following 'type', 'version', and 'length' layer shaded in grey. These areas represent the HTTP encrypted areas that are visible but not changeable by third-parties

Screenshot of a recent study titled: "Identifying HTTPS-Protected Netflix Videos in Real-Time" by Andew Reed and Michael Kranch

Published in CODASPY'17

Zoom image of a pull quote from the above study noting that:

we developed a system that can report the Netflix video being delivered by a TCP connection using only the information provided by TCP/IP headers
Published in CODASPY'17

Encrypted transport



Side by side Image diagrams of a traditional HTTP with TLS/TCP stack compared with an HTTP/QUIC stack. The QUIC diagram has less layers. It shares the top source/destination port layer with the earlier stack, but skips the 'sequence number' and 'acknowledgement number' layers and instead goes straight to 'length' and 'checksum', which here correspond with 01SRRRKPP and (dest connection id). These are informed by the 'packet number' layer underneath, and the base layer still represents the application data, (HTTP headers and payload)

Encrypted transport



Side by side Image diagrams of the traditional HTTP with TLS/TCP stack compared with an HTTP/QUIC stack, this time with both having the lower application data layers blacked out and on the QUIC version showing the packet number layer also blacked out. On the QUIC version, the 01SRRRKPP and (dest connection id) layer is shaded in grey. These represent the layers that QUIC encrypts, which are all but the unpredictable UDP headers (that can't be predicted as QUIC runs on top of UDP)

Why should you care?

Low latency
eliminates latency of new connections to recently visited sites
eliminates head-of-line blocking in TLS and TCP

Encrypted transport
encryption and privacy are fundamental to QUIC
connections protected from tamper and disruption most of the headers not even visible to third parties

Resilient connections
connection migration fixes "parking lot" problem

Connection migration

Cartoon image of a child looking at a smartphone. A bidirectional arrow labelled: Wifi connects the image of the child to an image of a server

Connection migration

Repeat image from the last slide with the child and the server, now with a second figure (a woman in office attire looking at a smartphone) positioned underneath the other two images to form a triangle. A bidirectional arrow labelled: Cellular connects the server to the second figure, and a dotted arrow points from the child to the woman. This represents that when moving from a wifi to a cellular network, TCP dies and the connection is lost, such as in an underground carpark. But QUIC allows you to move your connection across IP addresses, therefore it moves with you so you don't lose connection

Google’s early deployment (gQUIC) showed large improvements for YouTube and Google Search

Google’s Early Deployment

Image of a column graph showing data from Google's early deployment of QUIC in South Korea. The y-axis of the graph shows percentage reduction in increments from 0 to 25%. Four columns charted on the x-axis represent (from left to right): Search Latency on Desktop reduced by 1%, Search Latency on Mobile reduced by less than 1%. Youtube Rebuffers on Desktop reduced by 0%, and Youtube Rebuffers on Mobile reduced by 10%


Google’s Early Deployment

Image of the same column graph from prior slide but this time with comparative data from the USA in dark blue columns beside the South Korean data in pale blue. The USA data shows that: Search Latency on Desktop reduced by 2.5%, Search Latency on Mobile reduced by 2%, Youtube Rebuffers on Desktop reduced by 4.5%, and Youtube Rebuffers on Mobile reduced by 12.5%


Google’s Early Deployment

Image of the same column graph from prior two slides, this time including comparative data from the India in yellow columns beside the USA (in dark blue) and South Korean (in pale blue) data. The India data shows that: Search Latency on Desktop reduced by 12.5%, Search Latency on Mobile reduced by 5.1%, Youtube Rebuffers on Desktop reduced by 22%, and Youtube Rebuffers on Mobile reduced by 20%


Why should you care? (architectural)

Userspace transport
offers control to application developers
enables architecture exploration, e.g., in datacenter settings

Deployment agility of new features
ossification protection with versioning, encryption, GREASEing
e.g., DATAGRAMs, for realtime media

Substrate for next wave of Web and Internet technologies
MASQUE, WebTransport

Current State

QUIC is now RFC 9000! (w/ RFCs 9001, 9002, 8999)
HTTP/3 is blocked by unrelated docs; expected soon

Apple, Facebook, Fastly, Firefox, F5, Google, Microsoft …

Many server and client deployments
Google, Facebook
(can test HTTP/3 and QUIC today at Fastly!)


Available for most users, can also manually enable

Uses Chrome's networking stack, including QUIC and HTTP/3
Enabled by default for a small fraction of Dev and Canary
Can also manually enable

Available in nightly build, which can be manually enabled

Experimental feature, which can be manually enabled.


Apple iOS and macOS:
Experimental, can be manually enabled in iOS 14, macOS Big Sur

Microsoft Windows:
Separate implementation of HTTP/3 and QUIC
Used by the IIS web server
Piloted for internal online services like M365

Google Android:
No current plan for platform support
Android applications use Chrome’s networking stack (cronet)

QUIC and HTTP/3 are here!

Start moving your properties onto HTTP/3 TODAY!