This is the first in a series of posts about this rapidly emerging transport protocol.
In this article we will explore how QUIC is different than TCP, which has been delivering reliable application connectivity for 40 years, and look at why it runs over UDP.
The Basics
QUIC is here. It has been for years. Sites like Google, YouTube, Facebook, and even Cloudflare support it. Now that it is a standard (yay RFC 9000!! Welcome to the world!) we expect that more and more services will make the leap to this new transport protocol.
Try this – open Wireshark, start a capture and navigate with Chrome to YouTube. Instead of TCP-based connections, you will see your screen fill with UDP-based QUIC.
Wait – UDP? Seriously? Isn’t that an unreliable, best effort, non-retransmitting protocol that critical applications tend to shy away from? Well, yes – but don’t let the bottom end of the transport layer fool you.
QUIC sits on top of UDP because every kernel in the world supports it. If QUIC was directly encapsulated within IP, we would need to slowly upgrade the stacks of every end user device to support this completely new protocol, which would tremendously delay its implementation.
Think of it this way – take the “smarts” of TCP, including the reliability, retransmission, and flow control process, and put all of that on top of UDP as a simple carrier. Basically, that is what QUIC does. Just like its TCP counterpart, QUIC establishes connections, handles acknowledgements, retransmits lost QUIC packets (more on that later) and has very similar congestion algorithms. It just uses UDP to get its foot in the door.
Then, if QUIC is kinda like TCP over UDP, then why do we need it? Why not just stick with TCP?
There are a few reasons, let’s boil them down to these three:
- Improved speed
- Increased security
- Better reliability
As we progress in this series we will go into detail on each of these points, but for now let’s take a look at them at a high level.
Improved speed:
In order to establish a connection and security, TLS/TCP requires at least two network roundtrips. Once the connection is in place, the application can send requests and receive replies. This means there is a minimum of three roundtrips before we get the first byte of application data.
QUIC shaves some time off this process. In the initial packet, QUIC establishes security. If the client and server have recently connected, QUIC can even send application data in the first packet. This means that in some cases, only one network roundtrip is needed before we get the first byte of data.
QUIC also establishes individual streams within the connection. If a packet is lost, only those streams that were impacted by the lost packet will be affected while we wait for the retransmission. This gets around the TCP head-of-line blocking problem, which we will detail on another post.
Security:
To help secure applications over TCP, TLS was designed to handle the encryption part of the puzzle. Rather than completely rewrite TCP to include built-in security, TLS takes the data from the application and keeps it secure end to end. As analysts, we still have full access to the TCP header and can get quite a bit of information about the application flow and any loss recovery.
QUIC embeds TLS 1.3 into its core function. After the first roundtrip, everything above UDP is encrypted. This protects even the QUIC headers from prying eyes and allows it to guarantee secure app delivery end to end.
Now, there are some definite downsides for analysis and troubleshooting. QUIC will make it much harder for Packet Heads to monitor and analyze from the raw packet level. Decryption will become necessary if we want to troubleshoot anything outside of initial roundtrip time, basic connection information, and general data flow.
Reliability:
Since QUIC is designed to handle retransmissions on a stream basis rather than a connection basis, it has shown better performance over lossy networks. Applications such as Uber have made the switch to QUIC, which has improved the experience of end users, especially in areas where signal quality is low.
QUIC was also designed to allow the connection to migrate across networks. If you start a YouTube video in your home on your phone and walk out to your car, the QUIC connection can continue even though the underlying network went from WiFi to LTE with new addressing and UDP port numbers. TCP struggled to make this jump reliably and seamlessly.
There we have the basics of QUIC. As we can see, it is much more than just a UDP stream. Since the standard has dropped, we should expect to see it roll out to support more and more web services in the coming months and years. Stay tuned to this series to learn more about how QUIC works!
Want some hands-on with QUIC? Check out my Protocol Deep Dive: QUIC course on Pluralsight. This course will take you through how to understand, analyze, and troubleshoot QUIC, with several decrypted trace files and labs to work through.
