TCP vs UDP: How They Differ and When to Use Each

TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) are the two transport-layer protocols that almost all internet traffic rides on top of. TCP trades speed for reliability — it establishes a connection, numbers every byte, and retransmits anything lost. UDP does none of that: it fires packets (“datagrams”) at a destination and moves on, leaving reliability, ordering, and congestion handling to whatever’s built on top of it, if anything.

How TCP works

TCP is connection-oriented. Before any data moves, the two sides perform a three-way handshake (SYN, SYN-ACK, ACK) to agree on starting sequence numbers and confirm both ends are reachable. Once connected:

• Ordering — every byte is numbered, so the receiver can reassemble data in the order it was sent even if packets arrive out of order.
• Reliability — the receiver acknowledges received segments; unacknowledged segments get retransmitted after a timeout.
• Flow control — a receive window tells the sender how much unacknowledged data it can have in flight, preventing a fast sender from overwhelming a slow receiver.
• Congestion control — TCP backs off its sending rate when it detects packet loss, which it treats as a signal of network congestion.

All of this happens transparently to the application — a program using TCP just writes bytes to a stream and trusts they’ll arrive intact and in order. The TLS handshake that secures HTTPS traffic runs on top of this TCP connection, adding its own negotiation on top of TCP’s.

How UDP works

UDP is connectionless. There’s no handshake, no acknowledgments, no retransmission, and no guaranteed ordering — a sender just addresses a packet and puts it on the wire. If it’s lost, corrupted, or arrives out of order, UDP itself does nothing about it; that’s left entirely to the application, if the application cares at all.

This sounds like a downgrade, but it’s a deliberate tradeoff. Skipping handshakes and acknowledgments means lower latency and less overhead per packet — valuable for anything where a late packet is worse than a dropped one.

TCP vs UDP at a glance

	TCP	UDP
Connection	Connection-oriented (handshake)	Connectionless
Ordering	Guaranteed	Not guaranteed
Reliability	Retransmits lost data	No retransmission
Speed/overhead	Higher overhead, added latency	Minimal overhead, lower latency
Congestion control	Built in	None (application’s responsibility)
Typical uses	Web, email, file transfer, APIs	DNS, streaming media, gaming, VoIP

When to use TCP

Anything where correctness matters more than latency belongs on TCP: loading a web page, calling a REST API, sending email, or transferring a file. If a single byte arrives wrong or out of order, the whole payload can be meaningless — a corrupted HTML response or a truncated file download isn’t something you can just shrug off. TCP’s retransmission and ordering guarantees mean the application layer never has to think about packet loss at all.

When to use UDP

UDP fits cases where a late arrival is effectively useless, so there’s no point paying the retransmission cost:

• Live video and voice calls — a retransmitted, delayed audio packet is worse than one dropped frame; the human ear or eye can tolerate a brief glitch better than added lag.
• Online gaming — position updates sent 20 times a second are stale before a retransmit could even complete; the next update supersedes the lost one anyway.
• DNS lookups — most DNS queries fit in a single small UDP packet, and if it’s lost the resolver just retries the whole query rather than needing TCP’s per-byte reliability. DNS does fall back to TCP for larger responses like zone transfers.
• Basic network diagnostics and lightweight protocols where the application implements its own thin reliability layer only where it actually needs one, instead of paying for TCP’s full guarantees everywhere.

Notably, HTTP/3 is built on top of UDP via the QUIC protocol, rather than TCP like HTTP/1.1 and HTTP/2. QUIC reimplements the reliability and congestion-control pieces it actually wants — but does so per-stream instead of per-connection, which avoids TCP’s head-of-line blocking, where one lost packet stalls every stream multiplexed over the same connection.

Where they sit in the stack

Both protocols live at the transport layer, sitting on top of IP (which handles addressing and routing) and below the application protocols that developers usually interact with directly. A load balancer or firewall often makes routing and filtering decisions based on which transport protocol and port a packet is using — UDP port 53 for DNS, TCP port 443 for HTTPS, and so on. If you want to see how IP addressing and subnets fit underneath both protocols, the free subnet calculator is a quick way to check CIDR ranges without doing the binary math by hand.

The takeaway

TCP and UDP solve the same basic problem — moving bytes from one machine to another — with opposite priorities. TCP spends overhead on a handshake, acknowledgments, and retransmission to guarantee ordered, reliable delivery, which makes it the right default for web traffic, APIs, and file transfer. UDP skips all of that for minimal latency and overhead, which makes it the right choice when a stale retransmission is worse than a dropped packet, as with live video, voice, gaming, and DNS. Neither is strictly “better” — the choice comes down to whether your application can tolerate loss, and whether it’s willing to build its own reliability logic on top when it can’t.