Modernizing the internet with HTTP/3 and QUIC

As the internet’s protocols evolve, so too do our experiences using them. QUIC, the new transport protocol set to replace TCP, and HTTP/3, the HTTP version running atop QUIC, will start to see wide deployment in 2020. After more than six years of building, reframing, and refinement, HTTP/3 and QUIC are primed to modernize the internet in a number of ways: faster response times, greater accessibility worldwide, and setting the standard for built-in encryption, just to name a few. 

Coming soon, we will make HTTP/3 and QUIC available for customers to play with on the Fastly platform, ahead of its wider release, so you can get a taste of what’s to come and help shape where we’re headed. Please send us an email at if you’re interested in participating in our upcoming beta program. We are also launching a site that browsers and other clients can use to test for HTTP/3 connectivity: This site — inspired by the dancing kame that many of us have used for testing IPv6 connectivity — runs on Fastly’s HTTP/3 and QUIC servers (h2o and quicly). So, open a browser that you’d like to test, point it at, and see whether your communication uses HTTP/3.

As an editor in the IETF’s QUIC working group, I have been a huge proponent of HTTP/3 and QUIC, and I gave a talk about their potential at Fastly’s customer conference, Altitude NYC, back in November last year. I walked through why these are important to us at Fastly and why they should matter to our customers. Watch the talk in the video below, or read on to delve into some of the important features of QUIC that should make HTTP/3 interesting to our customers.

Hello, faster handshakes

Clients and servers begin their interaction with one another via transport and crypto handshakes. These establish that the two parties are ready to communicate, and set up the ground rules for doing so. TCP and TLS, the prevalent transport and crypto protocols, have to do their handshakes in order, which must occur before any data can be exchanged. This means that with TCP and TLS, an end user spends at least two round trips setting up communication before any web traffic can flow. That’s where QUIC comes in. QUIC collapses the transport and crypto handshakes together. As a result, only one round trip is necessary for setup before traffic can flow.


When re-establishing a connection to a known server, this can be reduced to one round trip with TCP and TLS version 1.3, but that is still a fair bit of time for the web: entire web pages finish transferring and loading in that amount of time. Under the same conditions with QUIC, web traffic goes out right away, without waiting for any setup time. This is what QUIC calls Zero Round-Trip Time or 0-RTT connection establishment, and we expect it to be a significant improvement in latency for our customers’ web pages and apps.


More secure communication 

Current web communication is secured to the extent possible by TLS, but this still leaves a fair amount of metadata visible to third parties. Specifically, all of the TCP header is visible, and this can leak a significant amount of information. See this exemplary work, which uses information in the TCP headers to detect what video on Netflix is being watched. TCP headers can also be — and often are — tampered with by third parties, while the communicating client and server are none the wiser.

Encryption and privacy are fundamental to QUIC’s design. All QUIC connections are protected from tampering and disruption, and most of the headers are not even visible to third parties.


Solving the “parking lot problem”

Picture this rather universal problem: as you leave work for the day and head to the parking lot, you pull up a map on your phone to see what traffic looks like on your way home. The map is slow to load because, though you’re still connected to your company’s WiFi, you’re too far away for it to be useful. To load the best route home, you have to turn off WiFi, allowing your phone to connect to your cellular network.

This is known as the parking lot problem, and we all experience some form of this problem during our everyday activities. Your mobile device is capable of speaking to multiple networks. But, for a variety of reasons, it does not quickly detect and switch if the one it is using right now is of terrible quality.

QUIC solves this with connection migration, a feature that allows your connection to the server to move with you as you switch networks. QUIC uses connection identifiers to make this possible: a server hands out these identifiers to a client within a connection. If the client moves to a new network and wishes to continue the connection, it simply uses one of these identifiers in its packets, letting the server know that the client wishes to continue communication but from a new network.

What else will QUIC change?

QUIC keeps flexibility for the future in mind, ensures that applications’ connections are confidential, and promises to provide better internet performance globally. These are all built into the protocol’s design. It’s exciting to think that, very soon, QUIC and HTTP/3 will be working quietly behind the scenes to make the internet better for everyone connected to it. Join us for the journey — email to raise your hand for our upcoming beta and be on the forefront of building the internet of tomorrow.

Jana Iyengar
VP, Product, Infrastructure Services

4 min read

Want to continue the conversation?
Schedule time with an expert
Share this post
Jana Iyengar
VP, Product, Infrastructure Services

Jana Iyengar is VP of Product for Infrastructure Services at Fastly, where he is responsible for the core hardware, software, and networking systems that constitute Fastly’s platform. Prior to this, he was a Distinguished Engineer at Fastly, where he worked on transport and networking performance, building and deploying QUIC and HTTP/3, and serving as editor of the IETF’s QUIC specifications. He chairs the IRTF’s Internet Congestion Control Research Group (ICCRG). Prior to Fastly, he worked on QUIC and other networking projects at Google, before which he was an Associate Professor of Computer Science at Franklin & Marshall College.”

Ready to get started?

Get in touch or create an account.