#15 HTTP3 and QUIC – Future Protocol

What is HTTP/3 – In Generic Terms

HTTP3 is the third version of the Hypertext Transfer Protocol (HTTP), previously known as HTTP-over-QUIC. QUIC (Quick UDP Internet Connections) was initially developed by Google and is the successor of HTTP/2. Companies such as Google and Facebook have already been  using QUIC to speed up the web.

Lookback how it got started with HTTP/3

HTTP/2 brought some serious improvements with non-blocking downloads, pipelining and server push which has helped us overcome some limitations of the underlying TCP protocol. It allowed us to minimize the number of request-response cycles and handshakes.

HTTP/2 made it possible to push more than one resource in a single TCP connection – multiplexing. We also got more flexibility in the ordering of static downloads, and our pages are now no longer constrained by a linear progression of the downloads.

HTTP/2 Push Feature

In practice, this means that now one large javascript resource does not necessarily equal a choke point for all the other static resources waiting their turn.

No pipelining vs pipelining (Image source: Wikipedia, Author Mwhitlock)

Header Pack Compression

Add to these things HTTP/2’s header HPACK compression and default binary format of data transfer, and we have, in many cases, a significantly more efficient protocol.

Major browser implementations made it a requirement for websites to implement encryption – SSL – to be able to reap the benefits of HTTP/2 – and sometimes this incurred a computation overhead that rendered speed improvements unnoticeable. There were even some cases where users reported slowdown after transitioning to HTTP/2.

While some of these issues are solved now, if we look at the entire protocol stack, we see that the primary constraint lies on a lower level than HTTP/2.

QUIC and HTTP/3

QUIC (Quick UDP Internet Connections) was first deployed by Google in 2012. It redefines boundaries of network layers, relying on lower-level UDP protocol, redefining handshakes, reliability features, and security features in “user-space,” avoiding the need for upgrading kernels of internet-wide systems.

HTTP/2 stack vs HTTP/3 stack

Just like with HTTP/2, an advancement which was spearheaded by Google’s SPDY or speedy, HTTP/3 will again build on these achievements. Struggling with downtime and WordPress problems?

While HTTP/2 did give us multiplexing, and mitigate head-of-line-blocking, it is constrained by TCP. You can use a single TCP connection for multiple streams multiplexed together to transfer data, but when one of those streams suffers a packet loss, the whole connection (and all its streams) are held hostage, so to say, until TCP does its thing (retransmits the lost packet).

This means that all the packets, even if they are already transmitted and waiting, in the buffer of the destination node, are being blocked until the lost packet is retransmitted. Daniel Stenberg in his book on http/3 calls this a “TCP-based head of line block.” He claims that, with 2% packet loss, users will do better with HTTP/1, with six connections to hedge this risk.

QUIC is not constrained by this. With QUIC building on the on connectionless UDP protocol, the concept of connection does not carry the limitations of TCP and failures of one stream do not have to influence the rest.

With a focus on UDP streams, QUIC achieves multiplexing without having to piggyback on one TCP connection. QUIC builds its connection on a higher level than TCP. New streams within QUIC connections are not forced to wait for the others to finish. QUIC connections also benefit from doing away with TCP handshake overhead, which reduces latency.

Folks at Cisco made an interesting video explaining TCP’s 3-way handshake.

While QUIC does away with TCP reliability features, it makes up for it above the UDP layer, providing retransmitting of packets, ordering and so on.

Google Cloud Platform introduced QUIC support for their load balancers in 2018 and saw an improvement in mean page load time by 8% globally, and up to 13% in regions where latency is higher.

Between Google Chrome, YouTube, Gmail, Google’s search and other services, Google was able to deploy QUIC on a nice chunk of the internet, without waiting for IETF. Google’s engineers claim that in 2017, 7% of the internet traffic was already conducted over QUIC.

Google’s version of QUIC was focused on just HTTP transport, using HTTP/2 syntax. People from IETF (those in charge of standardizing QUIC), decided that IETF version of QUIC should be able to transport more than just HTTP. For the time being, however, any work on non-HTTP protocols over QUIC is on hold.

One more thing IETF’s working group decided is that the standardized version is going to use TLS 1.3 encryption instead of Google’s custom solution. TLS 1.3, compared to the older versions, also contributes to protocol speed, as its handshakes require fewer roundtrips. 

Right now, Google continues to use its own version of QUIC in its product, while directing it’s development efforts toward the IETF standards. Most of the other internet players are building on top of the IETF version (the two differ in some other aspects beside encryption).

If we open Chrome Dev Tools, and load some of Google’s products, like Gmail, in the Protocol column of the Network tab, we will see a lot of resources being loaded via Google’s version of the QUIC protocol. This is also the case for Google’s products like Analytics, Google Tag Manager, etc.

Differences between HTTP/2 and HTTP/3

There are several differences between HTTP/2 and HTTP/3 but the main one is that HTTP/3 runs over a transport layer network protocol called QUIC that uses UDP as the transport layer protocol instead of TCP, resulting on performance and security improvements.

The table below shows some of the differences between HTTP/2 and HTTP/3:

Conclusion – Why HTTP/3 matters

1. HTTP/3 is the newest iteration of the HTTP protocol that’s designed to address some of the limitations of HTTP/2 in order to improve both the security (HTTPS is required) and performance (thanks to iQUIC) of the HTTP protocol.
2. Using HTTP/3 solves the TCP head-of-line blocking problem that was still present in HTTP/2, which should translate to perceived improvements for small, time-sensitive requests that are very common with API and mobile app traffic.
3. The main drawback of HTTP/3 today is high CPU usage both on the client and server sides — this consumption is more noticeable on the server side as most web servers monitor CPU and number of requests per second, while most clients do not. However, this overhead is expected to diminish over time as the technology evolves, just as when the web moved from HTTP to HTTPS. 
4. If you’re planning to implement HTTP/3, expect changes to come to the protocol until it is approved by the IETF. Until then, deploying it on Akamai will minimize rework as we continuously update the server-side code with new drafts of the protocol. 

Explore more at Teknonauts.com

Ashish Kumar Singal

Ashish is technology freak with around 11+ years of experience in IT Landscape. He started his journey as a device driver programmer in 2010. From that point he has evolved as a Mobility and IOT Architect, he completed his M.Tech from BITS Pilani as System Architect. He is working as Principal Architect at Oracle currently.