The QUICk brown fox jumps over the lazy dog
- 5 minutes read - 1016 wordsThe fast alternative to TCP+TLS
What is QUIC?
The Quick UDP Internet Connection (QUIC) protocol is an encrypted connection protocol operating on the Layer 4 - Transport Layer of the OSI model.
Developed at Google around 2012, it has only been adopted as a standard by IETF in 2021.
The current and widely used solution of HTTPS using TLS is built is on top of the TCP protocol. The TCP handshake and the TLS handshake need to be completed to establish a path to communicate between a server and a client. As a result, multiple rounds trips to initiate a connection and negotiate the encryption parameters are required - two at the very least, depending on the TLS version used.
Note: you can observe the TLS handshake in the next section
To fasten this process, the QUIC protocol drops the needs for a TCP handshake as it operates over UDP but also manages to share the initial encryption info and exchange of keys in the initial handshake. This reduces the latency to the first valuable data exchange between a client and a server making QUIC at least twice as fast to establish encrypted connections.

As opposed to TCP, UDP is a connectionless protocol making it technically unreliable for communication - there is no sequence number, no ack numbers, etc. However, QUIC handles completing re-transmissions after identifying data loss
Beyond connection establishment latency, further highlighted benefits are:
Connection migration
A TCP connection is characterized by source/destination IP address and source/destination port while QUIC connections are id’ed using a 64 bits connection ID. Hence, when a client changes IP adress eg. moving out of wi-fi and switching to cellular network, QUIC continues to use the same connection ID with the new IP without interrupting any in-flight requests,
Multiplexing without head-of-line blocking
While TCP sees connections as a stream of bytes, in case of packet loss no streams on the HTTP connection can progress until the packet is retransmitted and received. Using QUIC, lost packets for an individual stream only impact that specific stream,
Let’s also note without diving into details: improved congestion control & forward error connection.
Researches have been carried out to quantify QUIC performance at scale - links available in the references section.
Is it actually in use?
According to w3techs.com as of February 2025, 8.5 % of all websites use QUIC.
In 2025, Google reported that about half of all requests from Chrome to Google’s servers were served over QUIC. Furthermore, Meta reported in a 2020 post than more than 75% of its internet traffic used QUIC over HTTP/3.
You can find QUIC network by looking for UDP traffic over ports 80 and 443 - eg.
tcpdump -i any udp and dst host leane.dev and port 443
In the below example, even though HTTP+TLS has been used, you can notice h3 being advertised in the header < alt-svc: h3=":443";ma=60;.
curl -I -v https://leane.dev
* Trying 137.220.67.174:443...
* Connected to leane.dev (137.220.67.174) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/cert.pem
* CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
* ALPN: server accepted h2
* Server certificate:
* subject: CN=leane.dev
* start date: Feb 8 14:16:33 2025 GMT
* expire date: May 9 14:16:32 2025 GMT
* subjectAltName: host "leane.dev" matched cert's "leane.dev"
* issuer: C=US; O=Let's Encrypt; CN=R11
* SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://leane.dev/
* [HTTP/2] [1] [:method: HEAD]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: leane.dev]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.4.0]
* [HTTP/2] [1] [accept: */*]
> HEAD / HTTP/2
> Host: leane.dev
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/2 200
HTTP/2 200
< server: nginx/1.27.3
server: nginx/1.27.3
< date: Tue, 11 Feb 2025 10:39:11 GMT
date: Tue, 11 Feb 2025 10:39:11 GMT
< content-type: text/html
content-type: text/html
< content-length: 6817
content-length: 6817
< last-modified: Mon, 10 Feb 2025 20:11:56 GMT
last-modified: Mon, 10 Feb 2025 20:11:56 GMT
< etag: "67aa5d8c-1aa1"
etag: "67aa5d8c-1aa1"
< accept-ranges: bytes
accept-ranges: bytes
< x-unique-id: 9f2d62f9-82e1-44db-997b-72dc290701ff
x-unique-id: 9f2d62f9-82e1-44db-997b-72dc290701ff
< x-xss-protection: 1; mode=block
x-xss-protection: 1; mode=block
< x-content-type-options: nosniff
x-content-type-options: nosniff
< x-frame-options: sameorigin
x-frame-options: sameorigin
< referrer-policy: strict-origin-when-cross-origin
referrer-policy: strict-origin-when-cross-origin
< cache-control: public
cache-control: public
< alt-svc: h3=":443";ma=60;
alt-svc: h3=":443";ma=60;
<
* Connection #0 to host leane.dev left intact
Running the same command while explicitly attempting HTTP/3 shows QUIC being used.
curl -I -v --http3 https://leane.dev
* Host leane.dev:443 was resolved.
* IPv6: (none)
* IPv4: 137.220.67.174
* Trying 137.220.67.174:443...
* QUIC cipher selection: TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_CCM_SHA256
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* subjectAltName: host "leane.dev" matched cert's "leane.dev"
* Verified certificate just fine
* Connected to leane.dev (137.220.67.174) port 443
* using HTTP/3
* [HTTP/3] [0] OPENED stream for https://leane.dev/
* [HTTP/3] [0] [:method: HEAD]
* [HTTP/3] [0] [:scheme: https]
* [HTTP/3] [0] [:authority: leane.dev]
* [HTTP/3] [0] [:path: /]
* [HTTP/3] [0] [user-agent: curl/8.6.1-DEV]
* [HTTP/3] [0] [accept: */*]
> HEAD / HTTP/3
> Host: leane.dev
> User-Agent: curl/8.6.1-DEV
> Accept: */*
>
< HTTP/3 200
HTTP/3 200
< server: nginx/1.27.3
server: nginx/1.27.3
< date: Tue, 11 Feb 2025 10:28:42 GMT
date: Tue, 11 Feb 2025 10:28:42 GMT
< content-type: text/html
content-type: text/html
< content-length: 6817
content-length: 6817
< last-modified: Mon, 10 Feb 2025 20:11:56 GMT
last-modified: Mon, 10 Feb 2025 20:11:56 GMT
< etag: "67aa5d8c-1aa1"
etag: "67aa5d8c-1aa1"
< accept-ranges: bytes
accept-ranges: bytes
< x-unique-id: 66dac3b7-2f50-4991-a1e1-470005e1319f
x-unique-id: 66dac3b7-2f50-4991-a1e1-470005e1319f
< x-xss-protection: 1; mode=block
x-xss-protection: 1; mode=block
< x-content-type-options: nosniff
x-content-type-options: nosniff
< x-frame-options: sameorigin
x-frame-options: sameorigin
< referrer-policy: strict-origin-when-cross-origin
referrer-policy: strict-origin-when-cross-origin
< cache-control: public
cache-control: public
< alt-svc: h3=":443";ma=60;
alt-svc: h3=":443";ma=60;
<
* Connection #0 to host leane.dev left intact
References
- Auvik
- Google - Quick at 10,000 feet
- The QUIC Transport Protocol: Design and Internet-Scale Deployment
- How quick is QUIC?
- Speed Matters for Google Web Search