What you need to know about HTTP / 3

Contents

HTTP protocol.

HTTP / 3 is the next generation of the HTTP protocol. It is powered by QUIC, which replaces TCP at the transport layer and reduces the number of round trips a client must take to determine a connection.

What makes it better?

If you can't tell from the acronym “QUIC”, HTTP / 3 it's much faster.

HTTP is just part of OSI model, that powers the internet as we know it. Each layer of the model has a different purpose, with high-level APIs like HTTP located at the top (the application layer), down to the physical cables and connections that connect to routers:

HTTP is part of the OSI model

But there is a bottleneck in this model and, despite the new name, the HTTP standard itself is not the problem.

TCP (the transport layer) is the culprit here; was designed in the years 70 and, as such, it wasn't built to handle real-time communication very well. HTTP-over-TCP has reached its limit. Google and the rest of the tech space have been working on a replacement for TCP.

On 2012, Google created SPDY, a protocol that is based on TCP and solves many common problems. SPDY itself is deprecated, but parts of it made its way into HTTP / 2, which is currently using 40% from the web.

QUIC is a new standard, very similar to SPDY, but it is built on top of UDP instead of TCP. UDP is much faster than TCP, but in general it is less reliable since it does not have the same error checking and loss prevention as TCP. It is commonly used in applications that do not require packages to be in the exactly correct order, but they worry about latency (like live video calls).

QUIC remains reliable, but implements its error checking and reliability at the same time as UDP, so you get the best of both protocols. The first time a user connects to a QUIC-enabled site, will do it via TCP.

The main problem with TCP that QUIC fixes is header blocking. Once a connection is established between the server and the client, the server sends data packets to the client. If the connection is bad and a packet is lost, the client holds all received packets after that until the server retransmits the lost packet. HTTP / 2 solve this problem somehow, by allowing multiple transfers over the same TCP connection, but it's not perfect and may actually be slower than HTTP / 1 with high loss connections.

QUIC solves this problem and handles high-loss connections much better. The first Google tests showed improvements of around 15% in high latency scenarios and up to 30% improvements in video buffering on mobile connections. Because QUIC reduces the number of handshakes that must be performed, there will be latency improvements across the board.

Is it difficult to implement?

Although QUIC is a new standard, is based on UDP, which is already compatible almost everywhere. Will not require new kernel updates, what can be problematic for servers. QUIC should work out of the box on any system that supports UDP

HTTP-over-QUIC should be a direct replacement for HTTP-over-TCP once it is available. At the time of writing this post, Chrome supports QUIC, but it is disabled by default. You can enable it for testing by going to:

chrome://flags

and activating the flag “Protocolo QUIC experimental”. Firefox will add support later this fall, and with Edge moving to Chromium, they will also receive support soon.

At the server end, if you are using CloudFlare as your CDN, you can enable the option already in your panel, even though you won't have many clients using it until mobile browsers have it turned on by default. Quickly is actively working in support. Despite this, if you want to enable it on your web server, will have to wait a bit; early support for QUIC is scheduled to arrive throughout the nginx development cycle 1.17, but Apache support is not in sight yet.

Once nginx and Apache are updated to support it, adding QUIC to your web page or web application will be as simple as updating your web server and enabling the option. You will not have to make any changes to your application or your code, since everything is handled at the infrastructure level. Not here yet, but it will come very soon, and you will definitely want to enable it once it is supported by default.

Subscribe to our Newsletter

We will not send you SPAM mail. We hate it as much as you.