What is QUIC? Everything You Need to Know

When I hear QUIC, my immediate reaction is, “The QUICk brown fox jumps over the lazy dog.” That sentence has been ingrained in me since my first typing classes decades ago! I doubt the creators of QUIC were going for this type of reaction when they put together the name… but the good news is that this isn’t an article on typing.

What is the QUIC protocol?

QUIC, as defined by the Internet Engineering Task Force (IETF), is an encrypted connection-oriented protocol that operates at the Transport Layer, or Layer 4, in the OSI model. While only formally adopted as a standard by the IETF in May 2021, its roots date back nearly a decade.

In 2012, engineers at Google originally developed the Quick UDP Internet Connections protocol as an experiment to improve the performance of Google’s web applications. While QUIC was originally an acronym, the official standard in RFC 9000 describes QUIC as a name, not an acronym. Personally, I think Quick UDP Internet Connections is helpful for immediate context, but I have to remind myself that the name is, in fact, just QUIC.

In one word, the motivation behind the development of QUIC is speed. In contrast to HTTPS leveraging TLS, which is built on top of the TCP protocol, QUIC is built on top of UDP. This comes with one clear advantage: the time to the first valuable communication drops significantly.

TCP, being connection-oriented, must perform a three-way handshake to initiate any connection. After this, encryption parameters must be negotiated for TLS. Only then does the data the user was looking for actually start flowing. This means that it takes multiple round trips just to establish a path for two devices to communicate. This results in latency for the user. In a world where every piece of information is a click away, speed is everything, so reducing latency is critical.

Since QUIC uses UDP, there is no need to complete a complex handshake to establish the first connection. The protocol includes initiating encryption, and the exchange of keys, in the initial handshake process. It takes only one round trip to establish a path for communication.

And while UDP itself is a connectionless protocol, and therefore technically unreliable (meaning that packets can get lost), QUIC handles identifying lost data and completing re-transmissions to ensure a seamless user experience.

What’s QUIC used for?

The need for a protocol like QUIC is obvious, at least in hindsight. When TCP, HTTP, and SSL / TLS became the standards for web traffic, they were the best protocols available at that time. They were, however, all built independently of each other. Meaning that HTTP was built to use TCP, and operated independently. TCP doesn’t care what type of traffic it carries.

This is a great model to create a stack of independent protocols that can each evolve and improve at their own pace, but it does create inefficiencies. In the example we discussed previously, TCP must complete its three-way handshake before TLS can start establishing encryption parameters. Not so efficient.

By examining the logical path that data must flow down the OSI model, developers were able to identify some of these inefficiencies and optimize QUIC to do one thing really well. And the timing on this couldn’t be better (or rather, what’s taken so long to define this as a standard!) as the amount of web traffic is ever-increasing.

The adoption of QUIC has been rising. At the time of writing this post (late 2021), only about 5.9% of websites support QUIC. However, some big names have really gotten behind it. The majority of Google’s web traffic is now QUIC. Facebook has also jumped in, claiming that over 75% of their traffic is along the new protocol.

Why have these companies gone all in? It goes beyond just the benefits we’ve discussed so far on initial latency. There’s also a benefit of multiplexing. While the HTTP/2 protocol does allow multiple HTTP streams to share a single TCP connection, there is still a problem with packet loss. Since TCP is a connection-oriented protocol and needs to recover the lost data, any packet loss on any of the multiplexed streams would lead to all streams on that connection becoming blocked until that loss is recovered. It’s like being on a highway, and one person tapping the brakes in a single lane, and all lanes come to a halt.

QUIC resolves this issue by enabling each lane to keep running independently. UDP is indifferent to the lost packets. The protocol has defined the retransmission parameters, and enables the retransmission of data in just one stream, as opposed to blocking all streams. So there’s no slowing down in other lanes.

There are a few other benefits, but the last key one I’ll touch on is the portability of a session between connections, or connection migration. Portable devices are ubiquitous now, so it’s quite often that you’ll start a session on your mobile device on your home Wi-Fi network, and then head out into the world and the phone will switch over to the cellular 4G or 5G network. QUIC has been designed to handle these changes in a client IP address, leveraging a unique connection ID for that session.

What are the network management and security implications?

We’ve established that overall, QUIC is a good thing, especially from the end user’s perspective. However, it’s just as important to recognize how QUIC can impact the effectiveness of tools network and security admins use in a world where QUIC makes up the majority of the traffic.

First, is traffic visibility. Assuming you allow QUIC on your network (which we’ll talk about in a minute), you’ll want visibility into the traffic, data, and applications that are in use. Much of the infrastructure we use today to get this visibility is built on HTTP inspection (for cleartext traffic) and TLS inspection (for encrypted traffic) to identify applications in use. Under QUIC, this is no longer an option. You’ll have to look at alternate ways to identify the applications in use. Tools like Auvik TrafficInsights aim to classify data without doing deep packet inspection.

Second, is network optimization. If you’ve properly optimized your network, QUIC will make good use of it. Since QUIC uses a multi-stream approach to sending traffic, it makes effective use of available bandwidth. There’s a built-in traffic controller that will identify if there’s network congestion, and will actively respond by tuning the throughput rate. This is definitely an advantage, compared to the change in traffic visibility, which by many is perceived as the trade-off.

Should you leverage QUIC in your network?

The truth to the question is that you probably already are. Given the number of large organizations that have pushed a lot of their traffic to QUIC, I can say with almost 100% certainty that there is likely QUIC traffic passing through your network today. That is unless you’ve explicitly blocked it.

You can easily find QUIC in your network by looking for UDP traffic over ports 80 and 443. Alternatively, if you have an application-aware firewall, you can look in the application logs. For Auvik users, you’ll already see QUIC as an application classification in TrafficInsights, under Encrypted Traffic. Here in my lab network, you’ll see a few devices leveraging QUIC—primarily accessing Google and Facebook services.

Given the reduction in visibility around data leaving the network via QUIC, one obvious question is: should you disable it? The short answer is, “It depends.” There will be no immediate impact on your end users, as most websites will default back to HTTP over TLS and TCP if QUIC is not available. Over the medium and longer term, though, more web traffic will be moving to QUIC, so disabling it is only a short-term solution.

If you’re concerned about the lack of visibility tools available for QUIC traffic, it’s better to disable it. You have many options to do so. Most browsers support straight-up disabling the QUIC protocol. You can also block UDP ports 80 and 443 on your network or endpoint firewall. Or, if you have an application-aware firewall, you can block the QUIC application. To be sure, I’d suggest doing all of these if you’d like to absolutely restrict the use of QUIC in your network.

---

Looking for more visibility into your network traffic? Try Auvik for FREE for 14 days.