TCP is the default for anything that must arrive intact and in order; the kernel handles retransmission, ordering, flow control, and congestion control for you. UDP is the right base when you would rather handle loss yourself than pay for head-of-line blocking — real-time media, DNS, and modern protocols like QUIC all build on it.
These are not competitors so much as two different contracts with the network. TCP promises a reliable ordered stream and hides the messy parts. UDP promises almost nothing and hands you the raw datagram. The choice is really a question of who should own reliability: the kernel, or your application.
Quick takes
If you're…
You are moving files, loading web pages, or running an API→TCPLoss and reordering would corrupt the payload; TCP handles both transparently.
You are carrying live voice or video→UDPA late packet is useless; retransmitting it only adds jitter. Drop and move on.
You send small request/response pairs like DNS lookups→UDPOne datagram each way avoids a three-way handshake per query.
You need ordered delivery across many logical streams→TCPTCP guarantees order — though all streams share one connection and one HoL queue.
You want to build your own reliability and congestion control→UDPQUIC, WireGuard, and game netcode all do exactly this on top of UDP.
You are behind restrictive middleboxes or firewalls→TCPTCP on 443 traverses almost everything; UDP is more often blocked or rate-limited.
Connection-oriented. A three-way handshake (SYN, SYN-ACK, ACK) establishes state on both ends before any data flows, and a four-way teardown closes it.
UDP
Connectionless. Each datagram is independent; there is no handshake and no shared state to set up or tear down.
core
Reliability
edge: TCP
TCP
Guaranteed delivery via sequence numbers, acknowledgements, and retransmission of lost segments.
UDP
None. Lost, duplicated, or reordered datagrams are the application’s problem to detect and handle.
core
Ordering
edge: TCP
TCP
Bytes are delivered to the application in the exact order sent.
UDP
No ordering guarantee; datagrams can arrive in any order.
core
Head-of-line blocking
edge: UDP
TCP
A single lost segment stalls everything behind it until it is retransmitted — painful when multiplexing many streams over one connection (HTTP/2).
UDP
No HoL blocking; a lost datagram never holds up the next one.
features
Flow & congestion control
edge: TCP
TCP
Built in: a receive window for flow control plus congestion control (CUBIC, BBR) that backs off under loss.
UDP
None by default. Applications that flood UDP without their own pacing can cause congestion collapse.
ops
Header & overhead
edge: UDP
TCP
20-byte minimum header, plus connection state and handshake round-trips before data.
UDP
8-byte header, no handshake — the lightest standard transport.