When TCP was invented in the 1970s, I don’t think anyone ever expected that we would still be using it 50 (!) years later. But here we are.
TCP has evolved over the decades, and was augmented with various features pertaining to reliable data transfer, flow control, congestion control, and more, but many researchers and practitioners (myself included) feel that TCP might be nearing the end of the road. Since TCP’s inception, the Internet has become crucial for society, but TCP is unfortunately not keeping up with the ever increasing demands.
The encouraging news is that there is a leading candidate to replace the TCP, which could enable Internet transport to continue evolving and solve many of the problems plaguing the Internet. Specifically, there is much excitement around a protocol called QUIC as a possible replacement for TCP. Whether that excitement is justified we’ll explore in later posts; in this post we will look at why QUIC was created and who is using it.
What is QUIC?
QUIC is a new general-purpose, secured (although there is some debate about this which we'll explore in later posts), multiplexed transport-layer network protocol. It aims to become the successor to TCP, which is currently the main transport protocol used for data delivery across the Internet. The protocol was developed by Jim Roskind, then an employee at Google, in 2012, and was announced publicly in 2013.
In 2015, QUIC was submitted to the Internet Engineering Task Force (IETF) for standardization, but it took six years - until May 2021 - for the IETF to release the first standardized version of QUIC, which was termed RFC 9000. At the same time, a standardized version of HTTP/3, which utilizes QUIC, was also released.
QUIC incorporates a number of TCP-like properties, as well as TLS encryption, layering them within the application space on top of a UDP transport.
Why is there a need for QUIC?
TCP has served valiantly for decades, but it might be reaching the end of its relevance. It was designed for wired internet that had nothing like the size and scope of today’s wireless web, and it’s clear to many experts that it can’t keep up. QUIC aims to make the web faster, more efficient, more secure, and most important, evolvable.
Until QUIC came along, the main alternative to TCP was UDP. In a nutshell, TCP provides reliable internet delivery where the delivery of the data is guaranteed, but UDP offers faster but not reliable delivery. QUIC aims to marry the best features of TCP with UDP transport layers.
The main limitations of TCP include:
TCP defines only 40 bytes of optional bits, and those are almost fully populated. As a result, there’s practically no room for new features.
Many middleboxes (e.g. firewalls) assume that TCP packets will be structured a certain way. If the packet differs too much from their expectations, it will be rejected or delayed, which makes it all but impossible for the protocol to evolve.
TCP is implemented on the Kernel, so any update to TCP transport needs to go through new Kernel revision. For some corporations with legacy infrastructure, it could take years to adopt new features.
Because TCP is a transport layer and encryption (i.e. TLS) isn’t built in, it has to be added on top. The result is that it takes a long time to establish a secure connection, and that some data sent through TCP, such as packet headers, aren’t encrypted, opening up vulnerabilities to security breaches.
The goal is for QUIC and HTTP/3 to be utilized together to replace the combination of HTTP/1 or 2 and TCP, as well as resolving some known issues of the TCP protocol.
How QUIC resolves the challenges of TCP
First and foremost, the pragmatic decision to build QUIC on top of UDP is a significant benefit. UDP is widely deployed across the internet, removing the need to define a transport layer from scratch, for which implementation might take decades.
In contrast with TCP, UDP has much less overhead, making it faster, simpler, and more efficient. However it has one major drawback, namely its lack of reliability. UDP can’t guarantee the delivery of every packet sent through the protocol or that they will be delivered to the recipient in the correct order.
QUIC takes the features of TCP, builds them on top of UDP, and adds more features besides. TCP is the transport layer, with TLS and HTTP2 above it on the app layer. QUIC is formally implemented on the user space, but in practical terms, it includes both the app layer and the transport layer mechanism. As such, it aims to replace the TCP transport layer.
Using UDP as its baseline, QUIC has TLS encryption built in, combined with the reliability-related features from TCP alongside it. QUIC is further implemented in the application layer, which is the user space. As a result, you can make lots of modifications without needing to update a Kernel.
Who is using QUIC?
As a general-purpose transport protocol, QUIC is usable for many internet-based workflows, but its first step in deployment was to shift web browsing to QUIC, since one of its immediate benefits is for HTTPS based web browsing.
Because QUIC in its implementation as a TCP successor works only with HTTP/3, both clients and website hosts need to support it in order to be able to use the protocol. This has proven an obstacle to widespread adoption, since only a few websites utilize HTTP/3. According to W3Techs, as of Oct 2, around 35% of the websites are still using HTTP/1. Around 45% have migrated to HTTP/2 , while only approximately 20% are using HTTP/3 and QUIC.
By the middle of 2021, QUIC accounted for 12% of internet traffic. The first and most notable QUIC adoptee was Google (not surprisingly, since it was developed by a Google employee). Google owns servers, apps, services, and clients within its own ecosystem, so the company could easily prove a concept and move numerous apps to the new framework. 30% of Youtube traffic has already transitioned to QUIC.
Facebook was the next site to switch, and it has already migrated over 75% of its traffic to QUIC. Both the Facebook and Instagram mobile apps are already using QUIC to its fullest extent.
However, that’s more or less where QUIC adoption has ended for now. Very little Microsoft traffic uses the protocol, and among streaming video, only YouTube and Facebook Live support QUIC, yet streaming video is close to 80% of the web traffic, which are mostly still TCP based. Giants like Netflix and Amazon Prime don’t use QUIC. However, Microsoft is inclined to shift their VPN offering from TCP to QUIC.
Ecosystems that currently support QUIC include:
Browsers: Chrome (by default); Edge, Firefox, Safari, and other browsers use TCP by default but have QUIC as an option.
Apps: all mobile apps from Google, such as Gmail and YouTube; Facebook apps; Uber.
Servers/CDNs: Akamai, Microsoft, Apple, Google, Cloudflare, Fastly, Caddy, and NetApp. Some of these CDNs use QUIC as a proof of concept, but almost all of their traffic still uses TCP.
Web Servers: LiteSpeed,H20, Ngnix and Apache.
Load balancers: LiteSpeed and F5 BIG-IP.
Community projects: libquic, which is based on chromium implementation, and reverse proxy -- a Docker image acting as a reverse proxy server.
Programming languages: Go (quic-go), Quic.NET (C#)
As you can see, the web-based infrastructure is starting to come round to QUIC, but QUIC is not the default in most cases and some of the big players still do not support QUIC.
Why is it taking so long to roll out QUIC?
QUIC is still a new standard aiming to redesign a lot of aspects of the internet, and standardization of such a multitude of features takes time. Even though QUIC was first submitted for standardization in 2013, it wasn’t released until May 2021, so it still is not fully supported by the different ecosystems.
The extended gap between the first announcement of QUIC and its official standardization led different vendors to develop their own versions of the protocol. They each took a certain QUIC release and based their version upon it, but their foundation isn’t the same as the final and official QUIC protocol. As a result, there are lots of flavors of QUIC floating around, some of which don’t support the full mandatory features of the official release, and it will take time for the different vendors to align their versions to the 2021 release. We see the transition to the standardized QUIC in its early stages, for example Google, which implemented its own flavor gQUIC, is migrating to the IETF released version of QUIC.
That said, there are still many challenges facing broader QUIC adoption, among them its acceptance by enterprise security regulation, the requirement for supporting TCP fallback and the fact that the spec is still quite basic. We will explore some of these challenges in more detail in later blog posts.
QUIC has potential for internet delivery
QUIC aims to fix a lot of problems of TCP, which, after all, was designed for a different internet era and can no longer keep up with today’s internet, and to make the internet more secure, responsive and evolvable. It’s worth remembering that we’re still in the early stages of its deployment, and the next few years will tell whether it will actually fulfill its mission to become the TCP successor. The potential of QUIC is even broader than just a TCP replacement as we see also some standardization initiatives of QUIC over real time protocol (SRT, RTP) which might create the ability of QUIC to replace real time communication protocols used in video conferencing and cloud gaming such as WebRTC
About Compira Labs
Compira Labs is a pioneer in ML-powered content delivery. Its software only solution can easily upgrade any CDN to deliver best-in-class QoE even in the most challenging last-mile networks. Compira Labs’ solution can dramatically improve user experience for latency-sensitive and bandwidth-hungry Internet services such as live and on-demand video streaming, game downloads etc. It is available for both HTTP/TCP and HTTP/3/QUIC delivery methods.