QUIC
QUIC rebuilds reliable, multiplexed transport on top of UDP so one lost packet stops blocking unrelated streams.
QUIC is a transport protocol, originally from Google and now an IETF standard, that provides TCP-like reliability and ordering but is built on UDP instead of being a peer to it. The motivating problem is head-of-line blocking: over a single TCP connection carrying multiple logical streams (as HTTP/2 does), one lost packet stalls all of them until it's retransmitted, because TCP only knows about one ordered byte stream, not the independent streams multiplexed inside it. QUIC gives each stream its own sequencing, so a lost packet on stream A never blocks stream B from being delivered to the application.
QUIC also folds the transport and TLS handshakes into one round trip instead of two sequential ones (TCP's three-way handshake, then a separate TLS negotiation on top), and it can often resume a previous connection with zero additional round trips at all — meaningful savings on high-latency or lossy mobile networks where every round trip counts. Because QUIC runs in userspace over UDP rather than in the kernel like TCP, it can also evolve faster: shipping a new congestion-control algorithm is a library update, not an OS update.
It underlies HTTP/3, which is effectively "HTTP semantics over QUIC" the way HTTP/2 was "HTTP semantics over TCP with multiplexing." Connection migration is one of its more distinctive features: a QUIC connection is identified by a connection ID rather than by the traditional IP-and-port tuple, so a phone can switch from Wi-Fi to cellular mid-download without dropping the connection, something TCP has no clean way to express.
The cost is CPU: encrypting and processing every packet in userspace is more work than the kernel's optimized TCP stack, which is part of why adoption took years even after the spec stabilized.
See also5
TCP and UDP
TCP guarantees ordered, reliable delivery at the cost of latency; UDP delivers packets fast with no such promise.
Networks & Distribution8 connections
HTTP2 and HTTP3
Two successive rewrites of HTTP's transport layer, each solving the previous version's head-of-line blocking at a different layer.
Web Platform6 connections
Latency and Jitter
Latency is how long a packet takes; jitter is how much that time varies — and the second often matters more.
Networks & Distribution6 connections
Streaming Response
Delivering a response incrementally as it is produced rather than all at once when complete.
Networks & Distribution17 connections
DNS over HTTPS
DNS over HTTPS wraps DNS lookups in encrypted HTTPS requests, hiding query contents from anyone but the resolver.
Networks & Distribution4 connections
Linked from4
- DNS over HTTPSNetworks & Distribution
DNS over HTTPS wraps DNS lookups in encrypted HTTPS requests, hiding query contents from anyone but the resolver.
- HTTP2 and HTTP3Web Platform
Two successive rewrites of HTTP's transport layer, each solving the previous version's head-of-line blocking at a different layer.
- Latency and JitterNetworks & Distribution
Latency is how long a packet takes; jitter is how much that time varies — and the second often matters more.
- TCP and UDPNetworks & Distribution
TCP guarantees ordered, reliable delivery at the cost of latency; UDP delivers packets fast with no such promise.