How QUIC protocol works

Author: mk
On: Sep 22, 2026

QUIC is the new protocol described in the document RFC 9000, a reliable Transport layer protocol that aims to improve the old TCP (Transmission Control Protocol) that is created in the 70s of the 20th century, but still runs the internet today.

Before explaining QUIC, we have to take a few steps back and go a bit deeper and see how the internet works under the hood, so you can understand more easily the benefits of QUIC, and why it is used in the NIOX project.
If you already know very well how protocols in the Transport and Application layer work, feel free to skip the first part of this article.

The foundation of the World Wide Web and HTTP

The old and legacy versions of HTTP: HTTP/0.9, HTTP/1, HTTP/1.1, and HTTP/2 are all based on TCP, to transfer reliable data, and preserve the integrity and order of data.

The internet is chaotic by default, to send a message, the data must be split into multiple packets first that will travel through different routes (Packet Switching), and then those packets will be reassembled together.
This is done because a single large block of data would clog the network, and would be impractical.

But multiple packets traveling in different paths have the following trade-offs:

This is where the TCP (protocol) comes in place, as the solution for both of the issues to reassemble the packets in order, and check their integrity, if a packet is missing (lost) or corrupted, the destination device will ask for the retransmission.

HTTP is primarily based on TCP to deliver the contents of a website, fonts, images, etc. correctly.

TCP Segments

Each TCP segment contains a fragment of the transferred data, it has its own header that follows a specific format described in the RFC 9293 document.

The following image represents a TCP segment.
Worth specifying that a bit is the smallest and atomic data representation in computer science, it is a single digit that can have two states (zero or one), they are commonly referred to with a lowercase b suffix to represent the amount of bits (for example: 192kbps, meaning 192 kilobits per second). Multiple bits can represent larger data, like a number or a letter.
A group of eight bits is defined as a Byte, commonly referred to with an uppercase B suffix (example: 10MB, 10 megabytes).

TCP segment and header format

Before sending segments, the host and server have to establish a connection, the TCP achieves it with a three-way handshake request that requires 3 roundtrips.

Security issues, SSL/TLS and HTTPS

The TCP itself does not cover the encryption process, which is a critical security component that prevents unauthorized actors from reading your data, including passwords, credit card information, etc.
In a few words, the segments are sent as clear text over the internet by default.

To mitigate this problem, an additional protocol is designed to encrypt text, and make data unreadable to unauthorized actors, known as SSL (Secure Sockets Layer), the latest version SSL 3.0 is described in the RFC 6101 document, but this protocol has critical security vulnerabilities, like the POODLE attack vulnerability, that allowed bad actors to decrypt data through MITM attacks (man-in-the-middle), described in the CVE-2014-3566, disclosed by Google security researchers in 2014 and nowadays SSL is deprecated and replaced with a newer protocol, TLS (Transport Layer Security), which some people mistakenly still refer to it as "SSL".

The TLS handshake is encrypted using asymmetric encryption keys with a specific algorithm, like the ECDHE algorithm.
Asymmetric encryption has two separate keys (think a key as a password with "random" characters with a specific length). The pair is commonly referred to as public key, which is publicly accessible, and private key which is kept secret, either key can be used to encrypt, with the other required to decrypt. It is impossible to decrypt data using the same key used for encryption, that's why it is called asymmetric encryption.
The way it works is interesting and complex, and won't be covered in this article; but in a few words, it's math magic :3
But secure asymmetric algorithms are computationally intensive and inefficient, so a symmetric cipher is used during the communication, like AES-256. In a symmetric encryption, the same key is used to both encrypt and decrypt data. Other math magic, like the Diffie-Hellman algorithm, is applied to secretly generate a symmetric key between the two hosts.

The TLS protocol has to make a few more roundtrips to establish a TLS connection before we can start sending encrypted data. The host will verify the TLS certificate from a trusted CA (Certificate Authority).
Certificates are related to the PKI (Public Key Infrastructure).
This is a large topic and won't be explained in this article, but if you're interested, it's still related to the NIOX project, so an article will be written about that specifically, and once it's published the link will appear here.

TLS has 4 major versions, but the ones that are used today are TLS 1.2 and TLS 1.3, the older ones are deprecated.
TLS 1.2 takes 2 roundtrips to establish a connection, meanwhile TLS 1.3 optimizes the process and takes only one roundtrip.

Once the connection is established, we can transmit data securely with TCP. In the HTTP context, this is the process that enables HTTPS (HTTP Secure). The same concept applies to a few other Application layer protocols as well, like the FTP (File Transfer Protocol), which transmits unencrypted data by default, unless TLS is configured on top of it, then it becomes FTPS.

TCP vs UDP

So far we have seen that TCP allows sending and receiving data in order, with integrity check, but on the other hand, we have the UDP (User Datagram Protocol) described in RFC 768, which is much faster and lightweight compared to TCP, it doesn't require any initial handshake to establish a connection.
The UDP (protocol) sends fragments of data in datagrams, but it doesn't guarantee the order of arrival, and also missing or corrupted datagrams are discarded by default; unlike in TCP, where the device has to ask for retransmission.

To make it clear, TCP is slow but reliable, often used to transfer every single Byte of information correctly, like uploading a file to the server. And UDP is fast but doesn't care about the order and integrity of data, and it's often used in VoIP calls, online streaming, WebRTC, etc.

QUIC and HTTP/3

Whenever TCP is used, every time we need a new connection, we have to go through the three-way handshake for the TCP and then establish a TLS connection in addition to another handshake, and it is very inefficient.

This is where QUIC comes in place, as described at the beginning, the protocol was designed to improve TCP.
QUIC is built on top of UDP, but implements its own system to deliver reliable data more efficiently.

On a first connection, QUIC combines the transport and TLS handshake into a single roundtrip. On reconnecting, cached session data can let it skip the handshake entirely, known as 0-RTT.

QUIC also wraps TLS 1.3, making it impossible to establish an unencrypted connection, even from the very first handshake packet. That means in the future, HTTP without a TLS certificate, which very few websites still run today, will completely disappear; right now, they are just strongly shadowed by search engines like Google Search, and every mainstream browser flags HTTP-only websites as unsafe.

So HTTP/3 is the brand new version of HTTP that entirely relies on QUIC. Platforms like YouTube and many other websites, including our websites (NIOX, Space-F, Woxell, etc.), already support HTTP/3, fully or partially.

TCP uses sockets to identify a connection. A socket is just an IP address and Port pair used to identify which device or network is the destination, or which device or network is making the request, and it also identifies which program or protocol is used for that specific request, for example, HTTPS has the port 443 by default.
This works well, except when a network change occurs; when it happens, the hosts won't be able to recognize each other anymore, and they are forced to close the connection.
The QUIC protocol instead creates a pair of unique CIDs (Connection IDs), to identify each session, so, even if a host changes network, for example, a phone switches from Wi-Fi to LTE, the connection will still be alive.

In addition, QUIC also supports Stream Multiplexing, meaning it can open multiple streams of data, for example, in an online game, streams for real-time player movement, live chat, and leaderboard updates can run in parallel, independently of each other, if one stream stalls, it won't block the others, unlike in TCP.

The downsides of QUIC

Because QUIC is a relatively recent protocol, standardized in May 2021, many systems don't support it yet. It has a fair amount of CPU overhead, since it isn't implemented directly in most kernels, it's implemented in user space instead.
0-RTT introduces a new vulnerability: it can be subject to replay attacks, where a client's initial request could potentially be captured and resent by an attacker before the full handshake completes.
In addition, because every UDP datagram is encrypted and hard to inspect, firewalls may block the connection by default.
But these are temporary side effects. As adoption grows, QUIC will become widely supported and better integrated over time.