gQUIC Support & the Road to HTTP/3

The nature of internet communication and its requirements are changing fast.  Mobile devices in particular require different approach to handling connections That’s why there’s always a need for never-ending improvements.

Our devs prepared a new functionality you can enable in your account right now. We’ll go through what it is all about, benefits and improvements you can expect from it, and future developments we have in store for you.

But first, let’s have a look at the terms we’ll be working with.

TCP

Transmission Control Protocol takes care of data loss and makes sure the packets arrive in the intended order, providing reliability and error-check.

For instance, you would go with TCP if you want a reliable connection where occasional lag or delay is fine.

UDP

Communication over UDP doesn’t sort packets by itself. It requires an additional layer. User Datagram Protocol is a lightweight protocol that sits on top of IP and offers fast performance. It’s typically used for fast-paced games, where packet ordering is not an explicit issue and both client and server can send data independently.

UDP can be faster by up to 50% in certain types of applications, because it does not “care” whether a packet is received – it doesn’t require SYN/ACK.

That being said, UDP is not ideal for general internet communication and this is where QUIC comes into place. It adds certain functionalities that solve the ordering issue and much more.

HTTP

HTTP is one of the major applications that typically run on TCP. More on this later on.

gQUIC (Quick UDP Internet Connections)

Protocol made by Google. It works with Chrome and was originally designed for transmission of HTTP/2 frames. It gave the incentive to standardize a new transport protocol called QUIC. This is the protocol we currently support, and which you can enable in your Control Panel.

IETF QUIC

General transport protocol built on top of UDP. Capable of carrying any type of higher layer data. This version is currently not supported by any browser. However, we’re ready to enable it for your CDN the moment it arrives.

HTTP/3

The implementation of IETF QUIC to transport HTTP forms a new application protocol – HTTP/3. It’s also the first application that’ll make use of QUIC and the features it brings. It’s still in early stages and we’ll make sure to deploy it as soon as a stable version hits browsers support.

The IEFT in collaboration with many other organisations and individuals have already done a great deal of work to improve the current design of gQUIC and to standardise HTTP/3. The main changes happen behind the scenes. For instance, one of the most significant changes was encryption negotiation, especially during a handshake.

A Bit of Internet history – the Road to HTTP/3

HTTP 1.0 brought request and response headers back in 1996 allowing multiple file types such as HTML, images and text.

HTTP 1.1 arrived a year later with general performance improvements, caching capabilities, range requests and pipelining – sending multiple requests in a single connection.

After that, it took whole 18 years to deliver the most up to date version 2.0. It’s been 4 years since HTTP/2 was published as RFC but its support still has a long way to go. In fact, it’s only used by approximately 35% of websites. HTTP/2 is using TCP and while it brings some improvements, it’s still an old protocol that simply doesn’t fit in today’s rapid technological progress. The most significant change in how we use the internet came in the form of smartphones and other personal devices. For instance, switching from Wi-Fi to mobile networks is a big deal. Right now a device needs to establish a new connection each time it changes network.

The major improvements that HTTP/2 brought to the table are:

• Multiplexing
• Using one connection for parallel transfers
• Being a binary protocol
• Header compression
• Server push

There was also Google’s SPDY which laid the groundwork for HTTP/2. It’s been deprecated in favour of HTTP/2 but it can work as an analogy of the development of QUIC and HTTP/3.

You can argue that gQUIC is for HTTP/3 what SPDY used to be for HTTP/2. A young form of a growing internet protocol that lays the foundation for the grown-up version – HTTP/3.

A young form doesn’t mean useless, it’s quite the opposite actually. gQUIC presents the perfect opportunity for developers and internet enthusiasts to prepare for the upcoming change. You can enable it in Chrome to gain the performance boost in HTTP/2 connections.

You can also monitor it in Chrome via an extension called HTTP Indicator. It will show you which protocol the site you’re browsing on supports.

General Benefits of QUIC

There are great minds behind the QUIC development trying to improve our user experience. And they brought some notable changes to the new protocol, such as improved multiplexing, reduced latency, better and faster encryption and much more.

The major change of them all is UDP. For instance, QUIC running on UDP allows streams of data to reach all endpoints independently of each other. That means a slow or lost packet does not slow down other requests.

In comparison, the TCP connection can be congested if any of the multiplexed data streams return an error.

Multiplexing

There used to be only one connection with one resource transfer in the early days.

Then HTTP pipelining came – an idea to transfer multiple resources over a single connection and send multiple requests without waiting for the response. However, the requests had to be served in the same order as they arrived. If one request was blocked, others had to wait, resulting in a head-of-line blocking (HOLB). This solution is not used anymore.

With HTTP/2, multiplexing over TCP allows to send multiple HTTP requests over a single connection and removes one type of HOLB. A browser will open up to 6 connections in parallel. More connections actually degrade the performance.

However, there’s another type of HOLB. If you lose one packet somewhere along the way, the communication needs to wait for the packet to be resent, causing a delay in the data transfer.

HTTP/3 is expected to solve the second HOLB as well. Since it sits on top of UDP, packets can be sent and received regardless of their order. This makes communication much more fluent.

Latency

Latency causes a lot of frustration when it comes to user experience. You want visitors on your website, and you want them to return. Have them wait one second or longer to interact with your page and they’re gone.

TCP with TLS require two additional round-trips to establish a secure connection which can take 200-300ms, depending on the distance – this estimate considers the distance between the UK and the USA.

That’s quite a delay. Add to it the possibility of losing a couple of packets sent over TCP and your users can get frustrated pretty quick.

Lower latency in QUIC is achieved mainly by using UDP, it’s generally a much faster protocol than TCP.

Regardless of all the efforts, we’re always limited by speed of light in terms of internet connection. We’re trying to get as close to it as possible.

Google report from August 2017 states that “on average, QUIC reduces latency of Google Search responses by 8.0% for desktop users and by 3.6% for mobile users. Furthermore, it reduces rebuffer rates of YouTube playbacks by 18.0% for desktop users and 15.3% for mobile users.” That’s already pretty solid.

0-RTT Handshakes

The adoption of 0-RTT (zero round-trip time) is at its beginnings, basically cutting the time necessary to establish (more precisely to re-establish) a connection to zero.

QUIC connections are expected to commonly use 0-RTT handshakes. That means clients can send data right away without waiting for a reply from the server.

Encryption

QUIC incorporates TLS 1.3 at the transport layer. Features of the new encryption are:

• Being comparable to running TLS over TCP
• IP spoofing protection
• Replay attack protection

Headers in TCP connection appear in plaintext and are in no way authenticated. This makes them unsecured.

QUIC packets, on the other hand, are always authenticated and the payload is fully encrypted. There are still some unencrypted parts but these are authenticated by the receiver afterwards. That makes the whole communication secure, either right in the beginning or later, to confirm that there hasn’t been any breach.

Forward Error Correction

This is being developed explicitly for QUIC. It could have been added to HTTP/2 but never was.

You’re preemptively sending additional data to avoid the need to re-transmit the packet. It’s a packet that corrects the missing packet. You’re sending more data to get a faster, more stable connection of a higher quality.

Easy Network Transition

Each QUIC packet has its own unique identifier. When you switch to a new network/connection you just inform the server that it’s you with a new IP and the connection will just continue. QUIC allows for a seamless transition without the need for a new handshake.

To Sum This Up

• You’re getting a button in your Control Panel to enable gQUIC in the proprietary version that can run at least in Chrome.
• IETF is working on a standardised version of QUIC that’ll run in all browsers.
• Once the IETF QUIC is ready, it’ll be used to transfer HTTP data and therefore HTTP/3 will emerge. We’ll also enable it for you once it’s supported in browsers.

If you want to learn more, make sure to check the QUIC documentation by IETF.

We’re hoping for a proper version of HTTP/3 to arrive later this year. CDN77 is very excited about this shift in internet communication. We look forward to future development possibilities, faster browsing and other major improvements.