TCP vs UDP: What's the Difference and When to Use Which?

TCP is a reliable, ordered, connection-based protocol: every byte arrives, in order, or the connection reports an error — which is why the web, email, and file transfers all run on it. UDP is a fast, connectionless protocol with no delivery guarantees: packets may arrive out of order or not at all, which is fine for live video, voice calls, gaming, and DNS lookups where speed matters more than perfection. The default choice is TCP; reach for UDP only when low latency matters more than perfect delivery.

The core difference in one table

Both protocols sit on top of IP and add port numbers so multiple applications can share one machine — that shared foundation is covered in the TCP/IP protocol suite reference. Everything above that layer differs, and the table below is the comparison worth memorizing.

The mental shortcut: TCP behaves like a phone call — you dial, confirm the other end hears you, then talk with constant acknowledgment — while UDP behaves like postcards: you send them off and hope, with no confirmation. Neither is "better"; they optimize opposite ends of the reliability-latency tradeoff.

How TCP guarantees delivery

TCP's reliability comes from three mechanisms working together. First, the three-way handshake (SYN, SYN-ACK, ACK) establishes a connection so both sides agree on sequence numbers before any data moves. Second, every segment carries a sequence number and the receiver sends acknowledgments; anything unacknowledged after a timeout gets retransmitted, and duplicates are discarded. Third, flow control (the sliding window) and congestion control (slow start, backoff) pace the sender to what the receiver and the network can actually handle.

This machinery sits at the transport layer of the stack — layer 4 in the OSI model — and it is exactly what makes HTTP reliable enough to build on: when a web API documents retries and backoff, as in the agent-friendly HTTP checklist, it is adding application-level resilience on top of TCP's transport-level guarantees. The price is latency: handshakes add round trips, retransmissions stall the stream behind one lost packet (head-of-line blocking), and congestion backoff deliberately slows down. On a clean fast network you never notice; on lossy mobile links you feel every mechanism kick in.

Why UDP is faster, and when that wins

UDP strips transport down to ports, a length, and a checksum: no handshake, no acknowledgments, no retransmission, no ordering, no congestion control. A DNS lookup completes in a single request-response round trip, which is why name resolution feels instant. A video call drops a late frame rather than freezing the picture to wait for it — retransmitting a 200-millisecond-old video packet is pointless because the moment has passed.

One modern twist: QUIC, the foundation of HTTP/3, runs a TCP-like reliable stream on top of UDP — keeping UDP's handshake-free start and per-stream independence while adding back reliability where it matters. If "UDP but reliable" sounds contradictory, QUIC is the existence proof that the layers can be rearranged.

Ports: how applications share both protocols

TCP and UDP have separate port spaces, so TCP port 53 and UDP port 53 are different channels that happen to share a number. Most services use one protocol, but some — DNS famously — use both: UDP for normal queries, TCP for zone transfers and oversized responses. Well-known ports are worth recognizing on sight:

For the full listing with descriptions, see the common network ports reference. When debugging connectivity, always check the protocol too: a firewall rule opening TCP 53 does nothing for UDP-based DNS, and nc -u versus plain nc chooses which half of the stack you are testing.

FAQ: is UDP faster than TCP?

Is UDP faster than TCP? Per packet, marginally — smaller headers, no acknowledgment traffic. The real speed difference is behavioral: UDP never waits for retransmissions or handshake round trips, so on lossy or distant networks it feels dramatically faster. On a clean local network transferring a file, TCP's throughput is essentially identical because the mechanisms rarely trigger.

Do I need to choose? Most of my work is HTTP. Then TCP (or QUIC, for HTTP/3) already chose for you, correctly. The choice matters when you design a networked application or protocol: default to TCP unless you can name the specific latency requirement that reliability would break. "It needs to be fast" is not that requirement — measurements showing retransmission delays hurting your use case are.

Can I make UDP reliable myself? Yes, and many protocols do: add sequence numbers, acknowledgments, and retries at the application layer and you have reinvented the reliable parts of TCP. That is a reasonable choice when you need reliability plus something TCP cannot give — like independent streams without head-of-line blocking — but it is a real engineering project, not a weekend tweak. Prefer QUIC or an existing library over hand-rolling it.