1. What is QUIC?

QUIC was initially an acronym for Quick UDP Internet Connections. However, the document that establishes QUIC, RFC 9000 [1], doesn’t treat it as an acronym but as the official name of the protocol in its own right.

QUIC is a transport layer network protocol (a layer 4 protocol in the ISO / OSI model), initially developed by Google in 2012 [2], to improve page load times.

QUIC aspires to be the 21st-century replacement of TCP - which at the time of writing has been in use for 50 years, and most likely accounts for most of internet traffic.

QUIC raises to the challenge quite well. QUIC is the backbone of HTTP/3.

In 2020, Meta mentioned that over 75% of their internet traffic uses QUIC [3]. In 2023, Cloudflare assessed QUIC usage in around 30% of the requests they processed [4].

The adoption of QUIC seems to grow quickly…

Image of ISO / OSI stack

2. Why is QUIC built on top of UDP?

Being built on top of UDP, QUIC is recognized as a valid networking protocol by networking equipment and operating system kernels. This allows QUIC to be used without requiring updates to operating systems and network devices.

Take a look at the format of a UDP datagram, and observe how the minimalism of the UDP protocol makes it very suitable to build a protocol on top of it.

Image of UDP format

Right now, QUIC is implemented as a user-space networking protocol. Congestion control, packet recovery, and data ordering are all done in user-space.

QUIC support could also be implemented at the kernel level, but from my research, there doesn’t seem to be much interest in that, yet.

It can be argued that having a protocol as young as QUIC in user-space, rather than in the privileged kernel-space, offers two key advantages: the ability to quickly iterate and update the protocol and that of minimizing the security risks associated with its implementation.

Also if it were for QUIC to be implemented in the Linux kernel, one would also have to extend the POSIX socket API abstractization as it doesn’t fit QUIC as nicely as it fits other socket types.

3. How does QUIC differ from TCP?

Isn’t TCP perfect? A common definition is that TCP assures that all packets are received and that they are received in order. Well, the second part is more true than the first.

By the definition above, some people may be tempted to say that TCP is a solution for the The Two Generals’ Problem. It is not. It mitigates it only at one of the two ends. The Two Generals’ Problem is a classic problem in computer science about communication reliability between two parties over an unreliable network. If you’re unfamiliar with The Two Generals’ Problem, I suggest you watch a 2-minute extract from the video below.

A standard website has multiple resources: HTML files, CSS files, JavaScript files, images, etc.. For browsers to quickly load and render the websites, they need to receive these resources concurrently. Browsers nowadays usually employ 2 strategies: opening multiple TCP connections and using multiplexed TCP (HTTP/2).

TCP vs Multiplexed TCP diagram

In a multiplexed TCP connection, requests and responses can arrive in fragments, that can be concurrently processed. Multiplexed TCP also has the advantage of skipping the resource and setup latency (the TCP and TLS handshake, that has to take place before data can be transmitted) that spinning multiple simple TCP connections for each request would inflict.

However there’s a design issue with multiplexed TCP; as TCP receives data in the same order it was transmitted in, if a packet is lost, not only one but all response fragments are delayed. This is known as the HOL (Head Of Line) blocking issue.

QUIC supports multiple streams within the same connection. As each stream is completely independent of the other if a packet-loss occurs, all other streams continue to work as if nothing happened. QUIC removes the HOL blocking issue at the transport layer that TCP possesses.

Another important distinction is that while TCP uses the sliding window mechanism, where each ACKnowledgement confirms the receivement of a range of bytes, QUIC uses granular acknowledgments. Acknowledgments are sent for specific packets rather than ranges.

QUIC connection diagram

The differences don’t end here.

QUIC is a secure-by-default protocol, combining the transport layer and cryptographic handshake into a single round trip to reduce latency as shown in the figure below extracted from [5].

TCP & QUIC handshakes

In QUIC, the metadata is also encrypted; this should prevent protocol ossification by middle-boxes in the future, which was an obstacle in adopting TLS 1.3 [6].

And the last feature of QUIC that I wish to highlight is that each connection is uniquely identified by a connection ID, which can be used to resume communication from where it remained in the eventuality of an IP change, which can often happen on mobile devices, due to physical travel, thus minimizing interruptions.

Phone reconnecting from WiFi to GSM for internet

4. Closing notes

QUIC represents a significant step forward in the evolution of internet transport protocols.

Its goal of replacing TCP as the leading protocol may succeed in the near future, as major tech companies are rapidly adopting it for their services.

QUIC addresses many of the TCP limitations. The key advantages of it being:

  • having resumable connections
  • a smaller handshake
  • the lack of HOL blocking issue at its layer
  1. J. Iyengar and M. Thomson, RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport, May. 2021. [Online]. Available: https://datatracker.ietf.org/doc/html/rfc9000 [Accessed: Sep. 18, 2024].
  2. Chromium Project, QUIC, a multiplexed transport over UDP, [Online]. Available: https://www.chromium.org/quic/ [Accessed: Sep. 18, 2024].
  3. M. Joras and Y. Chi, How Facebook is bringing QUIC to billions, Oct. 21, 2020. [Online]. Available: https://engineering.fb.com/2020/10/21/networking-traffic/how-facebook-is-bringing-quic-to-billions/ [Accessed: Sep. 18, 2024].
  4. D. Belson and L. Pardue, Examining HTTP/3 usage one year on, Jun. 6, 2023. [Online]. Available: https://blog.cloudflare.com/http3-usage-one-year-on/ [Accessed: Sep. 18, 2024].
  5. G. Huston, Comparing TCP and QUIC, Nov. 3, 2022. [Online]. Available: https://blog.apnic.net/2022/11/03/comparing-tcp-and-quic/ [Accessed: Sep. 20, 2024].
  6. N. Sullivan, Why TLS 1.3 isn’t in browsers yet, Dec. 26, 2017. [Online]. Available: https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/ [Accessed: Sep. 18, 2024].