TCP vs QUIC
QUIC (RFC 9000) was designed by Google and standardized by the IETF as a modern replacement for TCP in latency-sensitive applications. QUIC moves transport logic to user space (no kernel changes needed to deploy improvements), integrates TLS 1.3 into the handshake (1 RTT from scratch), and multiplexes streams independently so packet loss on one stream doesn't block others. TCP's design is baked into every OS kernel – QUIC runs over UDP, making it deployable without OS updates.
TCP is a kernel-managed transport with a 50-year design. QUIC is a user-space transport over UDP that redesigns TCP's reliability, congestion control, and TLS integration from scratch – solving TCP's head-of-line blocking, slow connection setup, and inability to migrate across IPs. QUIC is the transport behind HTTP/3.
| Feature | TCP | QUIC |
|---|---|---|
| Protocol layer | Transport layer (L4), kernel-managed | Application layer over UDP, user-space implementation |
| Connection setup | 3-way handshake + TLS: 2–3 RTT | Integrated TLS 1.3: 1 RTT; resumption: 0-RTT |
| Multiplexing | Single byte stream – no native multiplexing | Multiple independent streams – loss isolated per stream |
| HOL blocking | Severe – entire connection stalls on lost segment | None – each stream has independent loss recovery |
| TLS integration | Separate – TLS layered on top of TCP | Built-in – TLS 1.3 is part of the QUIC handshake |
| Connection migration | Not supported – tied to 4-tuple (src IP/port, dst IP/port) | Supported – connection ID survives NAT rebinding and IP change |
| Congestion control | Kernel-managed (CUBIC/BBR) – hard to update | User-space – pluggable; can deploy new algorithms without kernel update |
| Header overhead | 20 bytes minimum | ~20 bytes (short header) to ~1200 bytes (long header with token) |
| Middlebox compatibility | Universal – firewalls, NATs, proxies know TCP | Variable – UDP 443 blocked by some firewalls (~5% of connections) |
| Deployability | Requires OS kernel support and patch cycle | User-space library – deployable in app without OS changes |
| RFC | RFC 9293 | RFC 9000 |
When to use TCP
TCP remains the right choice for non-HTTP workloads: database connections, SSH, SMTP, file transfer, and any protocol where the existing TCP ecosystem (libraries, tooling, firewall rules) matters more than latency optimization. TCP is universally supported with zero compatibility risk.
When to use QUIC
QUIC is the correct choice for HTTP/3 (the primary use case), real-time applications that benefit from 0-RTT resumption and connection migration, mobile applications where users switch between Wi-Fi and cellular, and any latency-sensitive workload over lossy or high-latency networks. Google uses QUIC for ~50% of its traffic.
Common Mistakes
- Using QUIC for raw TCP replacement outside of HTTP/3 – QUIC's API is stream-based but different from BSD sockets. Most applications should use HTTP/3 rather than raw QUIC directly.
- Blocking UDP 443 on firewalls without providing HTTP/2 fallback – this breaks HTTP/3 for affected users. Always pair QUIC with Alt-Svc and HTTP/2 fallback.
- Assuming QUIC eliminates all latency – 0-RTT data can be replayed. Only use 0-RTT for safe, idempotent requests (GET). POST/PUT/DELETE should use 1-RTT.
- Forgetting that QUIC encrypts connection metadata – unlike TCP, the QUIC packet number space and connection IDs are encrypted, which affects traffic analysis tools that relied on TCP sequence numbers.
FAQ
Is QUIC just TCP over UDP?
It implements similar features (reliable delivery, flow control, congestion control) but with per-stream semantics and integrated TLS 1.3. The key architectural difference is that QUIC's reliability is stream-scoped, not connection-scoped – eliminating head-of-line blocking. QUIC also redesigns the handshake to combine transport and TLS into a single 1-RTT exchange.
Can QUIC be used for non-HTTP protocols?
Yes. QUIC is a general-purpose transport. WebTransport uses QUIC for browser-based bidirectional communication. DNS over QUIC (DoQ, RFC 9250) uses QUIC for encrypted DNS queries. However, most QUIC deployments today are HTTP/3 because that's where the tooling, CDN support, and browser implementation are.
Does QUIC make TLS optional?
No – QUIC mandates TLS 1.3. Cleartext QUIC does not exist in the standard. This is a deliberate design choice: encrypting the transport layer prevents middlebox ossification (the problem where TCP extensions couldn't be deployed because middleboxes would break on unrecognized options).