TCP has three fundamental problems that can't be fixed by tuning:

1. Head-of-line blocking: TCP guarantees in-order delivery. If a multiplexed HTTP/2 connection loses one packet from stream A, streams B, C, and D all stall until that packet is retransmitted. The streams are independent logically but share one TCP connection, and TCP doesn't know about streams.

2. Handshake overhead: TCP requires a 3-way handshake. Add TLS on top, and you need 2-3 round trips before the first byte of application data can flow. On mobile networks with 100ms RTT, that's 200-300ms of pure overhead on every new connection.

3. Ossification: TCP is implemented in operating system kernels and manipulated by middleboxes (firewalls, NATs, load balancers) worldwide. Deploying TCP protocol changes takes years because every OS and middlebox needs updating.

Google built QUIC to solve all three. It runs on top of UDP, which middleboxes pass through without modification, and reimplements reliability, congestion control, and encryption in user space. HTTP/3, the next version of HTTP, uses QUIC as its transport. As of 2026, over 30% of web traffic uses QUIC.

QUIC = UDP + reliability + encryption + multiplexing

Per-stream independence is the killer feature. In QUIC, each HTTP stream has its own flow control and loss recovery. If stream A loses a packet, only stream A stalls. Streams B, C, and D continue receiving data uninterrupted. This completely eliminates the head-of-line blocking that plagues HTTP/2 over TCP.

Connection migration: TCP connections are identified by the source IP, source port, destination IP, and destination port. If your phone switches from WiFi to cellular, the IP changes, and the TCP connection dies. QUIC uses a connection ID instead. The connection survives network switches smoothly, critical for mobile users.

Zero-RTT resumption: If a client has previously connected to a server, QUIC can send application data with the very first packet, zero round trips of latency. The server caches cryptographic parameters from the previous connection and uses them to decrypt the early data.

Performance gains (real-world measurements):

• Google Search: 8% reduction in latency on desktop, 3.6% on mobile
• YouTube: 15% reduction in rebuffering
• Google Maps: 50% faster map tile loading

Trade-offs:

• CPU overhead: QUIC runs in user space, not kernel. Encryption and packet processing costs more CPU than kernel TCP. At very high throughput, this matters. Cloudflare benchmarked QUIC at roughly 3.5x the CPU cost of TCP+TLS for the same traffic volume.
• UDP blocking: Some corporate networks and countries block or rate-limit UDP. QUIC implementations include a fallback to TCP when UDP is unreachable. Google Chrome tries QUIC first, then falls back within 300ms.
• Debugging: Wireshark can't decode QUIC packets easily because everything is encrypted (including most header fields). You need qlog format and tools like qvis for debugging. Standard tcpdump is mostly useless.
• Maturity: QUIC libraries (quiche, msquic, ngtcp2) are production-ready but still evolving. The RFC was finalized in 2021 (RFC 9000), so the ecosystem is about five years old compared to TCP's four decades.