TCP vs UDP: Differences, Use Cases & QUIC

TCP vs UDP

Almost every application on the internet runs over one of two transport protocols. TCP (Transmission Control Protocol) gives applications a reliable, ordered stream of bytes: it sets up a connection, numbers every byte, retransmits what is lost, and slows down when the network is congested. UDP (User Datagram Protocol) gives applications independent datagrams with almost nothing added: no connection, no retransmission, no ordering — just a small header, port numbers, and a checksum.

Short verdict: use TCP when every byte must arrive in order and a little extra latency is acceptable — web pages, APIs, file transfers, databases, email. Use UDP when timeliness matters more than completeness, or when you need to build your own transport behavior — voice and video calls, games, DNS lookups, and modern protocols such as QUIC. In practice, most developers pick a higher-level protocol (HTTP, gRPC, WebRTC) and inherit the transport choice from it.

TL;DR

TCP: connection-oriented, reliable, ordered byte stream, with flow and congestion control.
UDP: connectionless, unreliable, unordered datagrams with an 8-byte header and message boundaries preserved.
TCP's reliability causes head-of-line blocking: one lost packet delays all data behind it.
TCP is a stream — applications must frame messages themselves; UDP preserves datagram boundaries but limits size.
UDP-based applications must handle loss, reordering, congestion, and MTU limits themselves.
QUIC (the transport under HTTP/3) runs over UDP and adds encryption, reliability, and independent streams.

Quick Example

Echo servers in Python show the difference in programming model. TCP accepts connections and reads a stream:

UDP has no connections — each datagram arrives on its own, with its sender's address:

With TCP, a 10 KB message might arrive over several recv calls, or two messages might arrive in one. With UDP, each recvfrom returns exactly one datagram — or nothing, if it was lost.

Core Concepts

Head-to-Head

How TCP Delivers Reliability

A connection begins with SYN, SYN-ACK, ACK. Every byte has a sequence number; the receiver acknowledges what it has received, and the sender retransmits unacknowledged data after timeouts or duplicate acknowledgments. Flow control keeps a fast sender from overrunning a slow receiver; congestion control reduces the sending rate when loss or delay signals a congested network. Connections close with FIN exchanges, leaving the closing side in TIME_WAIT briefly to absorb late packets.

Head-of-Line Blocking

Because TCP delivers bytes strictly in order, a single lost packet stalls everything behind it until the retransmission arrives — even data for unrelated requests multiplexed on the same connection, as in HTTP/2. For real-time media, data that arrives late is useless anyway, which is why voice and video prefer UDP.

Message Framing

TCP has no message boundaries. Applications define them: a length prefix, a delimiter such as a newline, or a protocol such as HTTP that specifies lengths. UDP preserves each datagram as a unit, but datagrams larger than the path MTU (typically about 1,500 bytes on Ethernet, less with tunnels) are fragmented or dropped, so UDP protocols keep datagrams small — QUIC uses roughly 1,200 bytes by default.

UDP's Responsibilities

Applications that use UDP must decide what to do about loss (ignore it, retransmit selectively, or use forward error correction), reordering (sequence numbers, jitter buffers), congestion (rate control to avoid flooding networks), and security. Protocols such as RTP for media, QUIC, and game networking libraries implement exactly these pieces.

QUIC: Reliability Built on UDP

QUIC implements a reliable, encrypted transport in user space on top of UDP. It combines the transport and TLS 1.3 handshakes (one round trip, or zero for resumed connections), carries independent streams so a loss in one stream does not block others, and supports connection migration when a phone switches from Wi-Fi to cellular. HTTP/3 runs on QUIC. Building on UDP let QUIC deploy through existing networks and evolve without operating system kernel changes. See HTTP/3 and QUIC.

Networks, NAT, and Firewalls

NAT and firewalls track TCP connections by their handshake and teardown. UDP "connections" are inferred from traffic and expire quickly, so long-lived UDP flows need keepalives.
Some restrictive networks block UDP except DNS; applications such as video conferencing fall back to TCP or TLS on port 443.
UDP amplification: services that answer small requests with large responses (open DNS resolvers, NTP monlist, Memcached) can be abused for DDoS attacks; rate-limit and restrict UDP services.

Best Practices

Let the Higher-Level Protocol Decide

Most applications should choose HTTP, gRPC, WebSockets, or WebRTC and inherit the right transport. Use raw TCP or UDP sockets only when you are building a protocol.

Frame Every TCP Message

Never assume one send equals one recv. Use length prefixes or a well-defined protocol to delimit messages.

Keep UDP Datagrams Below the MTU

Stay around 1,200 bytes or less unless you perform path MTU discovery, and handle loss explicitly.

Measure, Do Not Guess

Use ss, tcpdump, and Wireshark to see retransmissions, window sizes, and loss before tuning. See Packet Capture and Network Diagnostics.

Common Mistakes

Treating TCP as a Message Protocol

Large UDP Datagrams

Choosing TCP for Real-Time Voice

FAQ

What is the main difference between TCP and UDP?

TCP provides a reliable, ordered, connection-based byte stream with congestion control. UDP sends independent datagrams with no guarantees of delivery or order, and much less overhead.

Is UDP faster than TCP?

UDP has lower latency to start sending and avoids retransmission delays, so it often feels faster for real-time data. For bulk transfers, TCP's congestion control generally achieves high, fair throughput, and UDP applications must implement similar controls to behave well.

Why does DNS use UDP?

Most DNS queries and responses fit in a single small datagram, so UDP avoids handshake overhead. DNS falls back to TCP for large responses and zone transfers, and encrypted DNS often uses TCP or QUIC.

Why is HTTP/3 built on UDP?

To avoid TCP's head-of-line blocking and handshake latency while remaining deployable across existing networks. QUIC implements reliability, streams, and encryption itself on top of UDP.

Can UDP be reliable?

UDP itself is not, but applications can add reliability on top of it — acknowledgments, retransmission, ordering — as QUIC and many game and media protocols do, choosing exactly which guarantees they need.