The QUIC Protocol — An Introduction

Internet technologies have been evolving for ages. Starting from simple email protocols like SMTP, POP, and HTTP to media consumption protocols like DASH. Every protocol has a goal in mind and is implemented to achieve such a goal.

The transport layer protocols User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) have existed for ages. Adding to this list is the newly introduced IETF QUIC Protocol.

The layer 4 protocols UDP and TCP had different purposes, UDP being the fastest delivery and TCP being the reliable delivery service. Until now, applications had to choose between the fastest and the most reliable service. QUIC aims and does bring the reliability close to the fastest.

Google has been working on its version of the QUIC Protocol, GQUIC, since 2014. It is by this time, internet users would have felt that Google Chrome browser is faster than Firefox or Internet Explorer. It is because Google was experimenting with new technologies, and GQUIC was one among them. GQUIC was supported by all the Google services and Google’s browser, Google Chrome. This led to a visible change in the browsing speed between other browsers that were using TCP and Chrom using GQUIC.

Now, enough about GQUIC. The IETF QUIC, as suggested by the Internet Engineers Task Force (IETF), is a more adapted version of QUIC. Google and many other IETF members from Mozzila, Fastly, sn3rd, etc., after many discussions that lasted 3–4 years, came up with the first version of the IETF QUIC protocol adapted from GQUIC.

The QUIC protocol is built on top of the UDP Protocol layer. This is a feature because, unlike when a new transport layer is introduced, it takes years to be adopted by everyone worldwide; QUIC protocol can be adapted immediately. All the middleboxes that support UDP will be able to work to transmit the QUIC packets to the destination, increasing the adaptability of QUIC. Now, all the major browsers and major web services support QUIC.

QUIC builds on the connection-less UDP Protocol layer and adds reliability, congestion control, and loss detection to the connection. The TCP connection relied on the IP address (a unique address given to your network interface). Hence, whenever the network is switched, which happens a lot in the mobile internet world — WiFi to 5G, then back to WiFi etc.), the connection is terminated, and a new connection is started in the case of TCP.

A QUIC connection doesn’t depend on this IP Address; it depends on a unique connection ID. Hence, the connection can migrate easily even when a network switch occurs. This leads to faster connection even in poor network locations.

QUIC has many more advantages like it inherently supports TLS 1.3 for added security. Even the initial handshake packets obfuscate the information in the payload and a few header fields using an encryption algorithm whose key depends on the connection ID.

QUIC is a protocol worth exploring and adapting; the internet is changing and moving to a better state. Read more about QUIC in the IETF RFCs 8999, 9000, 9001, and 9002.