BlogNetwork SecuritySecurity
Blog • • 6 minute read

A Quick look at QUIC

Learn about QUIC (Quick UDP Internet Connection), a modern transport protocol that enhances internet speed, security and reliability by building on UDP. It integrates TLS 1.3 for faster handshakes, employs BBR for smarter congestion control, and uses multiplexed streams to eliminate head-of-line blocking. Seamless connection migration ensures uninterrupted connectivity, making QUIC a promising successor to TCP.

In this blog

  1. A quick rundown on QUIC 

 A quick rundown on QUIC 

QUIC is a modern internet transport protocol designed to make connections faster, more secure and reliable than traditional TCP, especially for today's web and mobile applications. 

 What is QUIC?

QUIC (Quick UDP Internet Connections) is a Layer 4 transport protocol that runs on top of UDP instead of TCP. It was originally created at Google by Jim Roskind around 2012 and standardized by the IETF as RFC 9000 in May 2021.

By building on UDP, QUIC avoids some of TCP's built-in overhead while still handling key tasks like reliable delivery and retransmission of lost packets. In practice, this means QUIC aims to replace TCP as the default way browsers and many applications communicate with servers, especially as web traffic and performance expectations keep growing. 

 Faster and stronger handshakes 

QUIC's handshake is both faster and stronger than TCP's because it natively incorporates TLS 1.3 into the transport, rather than layering encryption on afterward. Unlike TCP, which first performs the classic three-way handshake and then runs a TLS negotiation necessitating three round-trips, QUIC combines these steps so that cryptographic parameters and connection states are established together from the start. Modern TLS 1.3 features such as forward secrecy, robust cipher suites and streamlined key exchange are mandated with QUIC, while also ensuring that 0 and 1 RTT handshakes are enabled. 

 

The QUIC handshake also includes some measures to defend against DoS attacks targeting the handshake. Those measures are:

Address Validation: Verification that an entity that claims an address can receive packets at that address. Without address validation, endpoints cannot send more than three times the data received from an unvalidated address. This measure prevents amplification attacks. 

Retry Packet: The Retry packet is a token-exchange mechanism that allows servers to validate a client's IP address before performing expensive signature and key-exchange computations. This prevents server-side DoS attacks that overwhelm the server with connection requests.

Handshake Protection: Outside of dropping packets, on-path attackers cannot force handshake failure because handshake packets are protected with keys following the initial packet exchange.

Cryptographic Protection: Both initial and later handshake packets are encrypted with per-version, and TLS exchanged derived keys, respectively. 

Taken together, these features make QUIC's handshake make for a more secure and resilient foundation that TCP plus TLS. From the very first packet, QUIC reduces setup latency and the window that attackers must hijack connections, thanks to TLS 1.3 and its built-in defenses. 

 Smarter congestion control 

To prevent communication channels from becoming overloaded, TCP employs algorithms such as slow start, Reno, and Cubic to regulate data flow based on packet loss signals and RTT. That reactive behavior can underutilize available bandwidth or unnecessarily slow down transmission. Some of TCP's drawbacks are:

  1. TCP only reacts after congestion occurs, making it slow to respond and recover
  2. Packet loss can occur due to random network fluctuations rather than congestion. However, TCP will interpret the loss as congestion and unnecessarily slow down the transmission rate.
  3. TCP's congestion control does not scale efficiently in modern high-speed networks.

As high-speed, low-latency applications become increasingly prevalent, TCP's limitations can no longer be ignored, and QUIC's enhanced congestion control mechanisms become necessary. 

The main congestion control algorithm used by QUIC is Bottleneck Bandwidth and RTT (BBR). BBR works by estimating the bandwidth and RTT of a network path. Based on that estimate, BBR calculates a transmission rate to fully utilize available capacity without overloading the network. By continuously updating its estimates as conditions change, BBR enables QUIC to effectively utilize modern high-speed internet connections. 

QUIC further builds on its improvements over TCP by using packet-level acknowledgments rather than sequence-based acknowledgments. With this change, QUIC is more precise and timelier with its loss detection and retransmission strategies, preventing unnecessary slowdowns in network performance. When a packet acknowledgment is not received, some QUIC extensions optionally utilize a forward error correction mechanism that sends repair data alongside typical packets, allowing the receiver to rebuild some lost packets immediately, without having to wait for them to be resent, crucial for applications that demand low-latency. 

 Multiplexed streams without head-of-line blocking pain

TCP delivers bytes in a strict order within a connection. As a result of that, if a packet is delayed or lost, everything after it must wait, even if those later packets arrived on time, in a scenario called head-of-line blocking. This scenario can spiral out of control, where packets that were blocked by a lost packet end up blocking packets themselves. 

QUIC solves this issue by utilizing independent multiplexed streams inside of a single connection:

  1. Each stream provides its own ordered byte stream, and streams can be uni- or bidirectional
  2. A connection can have many streams at once, each with its own ordering and reliability state
  3. If a packet is lost, only the affected stream pauses while it waits for retransmission; other streams keep delivering data normally.

Multiplexed streams closely reflect how a modern webpage is built. A browser can put each image, script and API call on its own stream, so a delay in loading a large resource does not delay everything else on the page. This fine-grained separation gives devs more predictable performance and makes the overall experience smoother and more responsive. 

 Seamless migration

In a world always on the move, losing connection as you move between different IP addresses can be annoying, which is why QUIC's connection migration is a fantastic feature. 

QUIC supports seamless connection migration using stable connection IDs:

  1. After the handshake, the connection is primarily identified by its connection ID, not just IP and port.
  2. When the network path changes (from Wi-Fi to LTE), the client "probes" the new path and then shifts the existing connection to it.
  3. Stream, congestion control state, and encryption keys all carry over without a full reconnect or new handshake.

To the application, this transition is mostly invisible, avoiding stalls, renegotiations, and extra latency that would occur with TCP during an IP change. This feature is especially powerful for mobile and Wi-Fi-heavy environments. A video call running over QUIC will continue smoothly as a phone leaves a cafés Wi-Fi and switches to cellular. 

 The future is QUIC

QUIC is an obvious solution for the TCP pain points that we have been dealing with for years. Through its use of TLS 1.3, independent multiplexed streams, and support for seamless migration across changing networks, QUIC can address head-of-line blocking, slow setup, and congestion management issues we see with TCP. As QUIC's adoption grows, its benefits will only become more widespread.