QUIC

QUIC is a transport-layer protocol — a set of rules for how data travels across the network between two devices. It runs over UDP and bundles two things that used to be separate into one mechanism: reliable data transport and encryption (TLS 1.3). As a result, you no longer set up the connection (TCP) and the encryption layer (TLS) separately. The IETF standardized QUIC in 2021 in RFC 9000 (the transport itself), RFC 9001 (the TLS integration), and RFC 9002 (loss detection and congestion control). Its main use is HTTP/3 (RFC 9114), the version of the web protocol that runs on QUIC. Google originally designed QUIC as “gQUIC”; the IETF version differs from that early form at the protocol level.

How does QUIC work?

QUIC does not replace UDP — it runs on top of it and adds what UDP alone lacks: connection identification, reliable delivery, congestion control, and encryption. Data travels in QUIC packets wrapped inside UDP datagrams. Inside those packets are smaller chunks (frames) that belong to independent streams (streams), each with its own number (a stream ID).

The key features:

• One combined connection-and-encryption setup. Traditionally, devices first establish a TCP connection and only then negotiate TLS encryption. QUIC does both at once, in a single exchange. This cuts the time to set up an encrypted connection to a single round trip (1-RTT), and to zero when resuming an earlier session (0-RTT).
• Many independent streams at once. A single QUIC connection carries many separate data streams. If a packet is lost, only the stream it belonged to is affected — the rest keep moving without interruption.
• Connection ID. A connection is labeled with its own Connection ID rather than an IP address and port. That lets it survive a network change — for example, when a phone switches from Wi-Fi to cellular. This is the connection migration mechanism.
• Its own loss detection and congestion control. QUIC handles resending lost data and avoiding network overload (with algorithms such as NewReno, CUBIC, BBR) on its own. It does this in user space — inside the application rather than the operating-system kernel — which makes it easier to evolve and improve than TCP.

How does QUIC solve head-of-line blocking?

Head-of-line blocking is when one lost piece holds up everything queued behind it. In HTTP/2, many streams share a single TCP connection, and TCP delivers data strictly in order. So if just one segment is lost, delivery of all streams waits until it is resent. QUIC keeps streams independent: each has its own ordering, so a loss in one does not block the others. This removes the blocking at the transport level — though similar delays can still happen higher up, at the application level (e.g., dependencies between HTTP requests).

How does QUIC differ from TCP + TLS?

• Where it runs: QUIC runs over UDP, inside the application; TCP is built into the operating-system kernel.
• Encryption: in QUIC, encryption (TLS 1.3) is part of the protocol — not only the data but most of the transport header is encrypted. In the TCP+TLS model, encryption is a separate layer above a cleartext TCP header.
• Connection setup: QUIC merges the connection and encryption setup (1-RTT, or even 0-RTT on resumption); TCP+TLS needs a TCP handshake first, then a TLS handshake.
• Multiple streams: QUIC runs independent streams with no transport-level head-of-line blocking; HTTP/2 over TCP is susceptible to it.
• Network change: a Connection ID lets QUIC survive a network change; a TCP connection is tied to its address and port, so it breaks when the address changes.

QUIC, HTTP/3, and port 443

HTTP/3 is simply the web protocol running on QUIC, and it is QUIC’s most important use. But QUIC is a general-purpose protocol — it can also carry other things (e.g., DNS over QUIC or MASQUE). QUIC traffic typically uses UDP/443 — the same port number as ordinary HTTPS over TCP. A browser usually learns about HTTP/3 support from the Alt-Svc header on an HTTP/1.1 or HTTP/2 connection, or from the DNS HTTPS record (RFC 9460), then tries to switch to QUIC. If QUIC is unavailable or blocked, it falls back to TCP.

Why is QUIC a challenge for security and network visibility?

By design, QUIC encrypts much more than TCP+TLS. That is good for privacy but harder on the tools that monitor and analyze traffic (DPI, IDS/IPS, NDR). They see less than they would with plain TCP:

• Encrypted transport headers. Most connection information (including packet numbers) is encrypted. Passive tools cannot read connection state the way they can from a cleartext TCP header. What stays visible is mainly the header of the first packets (e.g., the Connection ID and version number).
• Often no visible server name (SNI). The TLS 1.3 setup is hidden inside encrypted Initial packets, and combined with Encrypted Client Hello (ECH) the server name disappears from cleartext traffic entirely. Classic hostname-based analysis then stops working.
• Harder break-and-inspect. QUIC does not give in to the same techniques for peeking at encrypted traffic as TCP+TLS. It needs a dedicated approach, and often a proxy that terminates the connection on the organization’s side.
• UDP/443 is harder to identify. QUIC traffic is hard to tell apart from other UDP traffic by port alone, and the lack of connection state (as in TCP) makes session tracking harder for firewalls.
• 0-RTT risk. Data sent in 0-RTT mode is not fully protected against replay, so it should be limited to operations that are safe to repeat (idempotent ones).

For SOC/NDR teams, this means a change of approach: instead of looking inside the traffic, you analyze its metadata and behavior. What matters is flow data (volumes, timing, packet-size distribution), recognizing QUIC by its distinctive traits (analyzing fields in the Initial packets), anomaly detection, and — where acceptable — terminating QUIC connections at a controlled proxy. Some organizations deliberately block UDP/443 to force a fallback to HTTP/2 over TCP and keep their existing visibility — at the cost of QUIC’s performance gains.

Learn more

• UDP Protocol — QUIC runs over UDP instead of TCP.
• Latency (Opóźnienie) — QUIC reduces connection setup latency compared with TCP.
• Scrubbing Center — QUIC traffic may be inspected or filtered in scrubbing centers.
• Protocol Attack — QUIC can be a target of protocol attacks that exploit transport behavior.
• JA3 / JA4 Fingerprinting — QUIC uses TLS, so JA3/JA4-style fingerprinting may help identify clients.
• Encrypted Traffic Analysis (ETA) — QUIC encrypts most metadata, making encrypted traffic analysis relevant.
• TCP Protocol — QUIC is an alternative transport protocol to TCP.
• Reflection Attack — QUIC services can be abused in reflection attacks if misconfigured.