HotShard
Absolute basics

TCP vs UDP

The two ways to send data across a network. One is a careful phone call. The other is a postcard.

Every request you send crosses the network as packets, and the network drops some of them. Something has to deal with that. Almost always it's one of two transport protocols. TCP sets up a connection, numbers every byte, and resends whatever gets lost, so the data arrives complete and in order. UDP just sends a packet and hopes it arrives. Choosing between them is the most basic trade-off in networking: reliability versus speed.

~6 min read

Start here: the network underneath drops things#

TL;DRthe 30-second version
  • Both protocols ride on IP, which only promises to try to deliver one packet. Packets get dropped, reordered, and duplicated.
  • TCP repairs all of that. A 3-way handshake, sequence numbers, acknowledgements, and retransmission give the receiver a complete, in-order byte stream. It also adds flow control and congestion control.
  • UDP adds almost nothing. No handshake, no acknowledgements, no ordering. Just ports and a checksum on top of IP, in an 8-byte header.
  • Use TCP when every byte must arrive (web pages, files, email, APIs). Use UDP when fresh beats complete (voice, video, games, DNS). HTTP/3 runs QUIC over UDP to get TCP's reliability without its stalls.

Underneath both protocols sits IP. Its whole job is to route one packet toward an address. That is all it promises. The packet may not arrive. Packets may arrive out of order, because they took different paths. A packet may even arrive twice. Routers drop packets when they get congested. IP is 'best effort', which is a polite way of saying 'no guarantees'.

You can't build most software on that directly. A file download with one dropped packet is a corrupted file. A web page with bytes out of order is gibberish. So something has to detect loss, resend, and put things back in order. That is the transport layer's job, and TCP is the protocol that does all of it.

How TCP makes it reliable (and how UDP doesn't bother)#

To the application, TCP looks like a clean pipe. You write bytes in one end, and the same bytes come out the other end, in order, with nothing missing. Four mechanisms earn that.

Clientwants to sendServerlistening
SYN — “let’s talk; my seq starts at x”
SYN-ACK — “ok, my seq is y; got your x”
ACK — “great, got your y”
connection established
data, data, data…
ACKs — each chunk acknowledged

UDP skips all of it: the first packet is data. No setup, no ACK, no reply owed.

TCP's 3-way handshake: agreeing to talk before sending data
  1. Connection setup (the 3-way handshake). Before any data, the two sides exchange SYN, SYN-ACK, ACK. That proves both can send and receive, and each side announces its starting sequence number.
  2. Sequence numbers. TCP numbers every byte it sends. The receiver uses the numbers to put the stream back in order and to drop duplicates.
  3. Acknowledgements and retransmission. The receiver sends back ACKs that say 'I have everything up to byte N'. If the sender doesn't get an ACK in time, it resends the missing data.
  4. Flow control and congestion control. Flow control stops a fast sender from overrunning a slow receiver's buffer. Congestion control stops senders from overloading the network itself.

UDP does none of this. There is no handshake, so the first packet is data. There are no sequence numbers, no acknowledgements, no retransmission, no reordering, and no flow or congestion control. UDP adds two things to a raw IP packet: port numbers, so the data reaches the right application, and a checksum, so a corrupted datagram can be thrown away.

SenderTCPReceiverTCP
seq 1
ack 1
seq 2
seq 3
seq 3 arrives but can’t be delivered yet — gap at 2
timeout → retransmit
resend seq 2
ack 3 — gap filled, deliver 1,2,3 in order

With UDP, #2 is simply gone. The receiver gets #1 then #3 and has no idea #2 existed.

A lost segment: TCP detects and retransmits (UDP just loses it)
PredictAn app sends three UDP datagrams in order: A, B, C. The network delays B so it takes a longer path. What does the receiver get, and in what order?

Hint: UDP doesn't reorder, doesn't wait, and doesn't resend. What's left?

Most likely A, then C, then B. UDP hands each datagram up the moment it arrives and never waits for a straggler. If B had been dropped instead of delayed, the receiver would get A then C with no sign anything was missing. TCP would deliver A, B, C in order, because it holds C until B arrives or is resent. That holding is the ordering guarantee, and it's also where head-of-line blocking comes from.

The cost model: setup round-trips, header bytes, latency#

There's no Big-O here. The costs are round-trips, header bytes, and added latency. Three numbers capture most of the difference.

  • Setup cost. TCP's handshake delays the first data by about one round-trip time (RTT). TLS on top adds another 1 to 2 round-trips. UDP pays zero setup. The first packet is already your data.
  • Header overhead. A UDP header is 8 bytes: source port, destination port, length, checksum. A TCP header is at least 20 bytes, and up to 60 with options, because it carries sequence and acknowledgement numbers, a window size, and flags. That matters for tiny messages and is noise on a big download.
  • Latency under loss. This is the big one. With TCP, one lost packet stalls everything behind it until the retransmission arrives, which adds at least a round-trip of delay. With UDP, loss adds no latency. The next datagram is delivered right away, and the lost one is just absent.

If this comes up in an interview#

The one-linerTCP is connection-oriented, reliable, and ordered: a handshake, then a numbered byte stream with ACKs, retransmission, and congestion control. UDP is connectionless datagrams with no guarantees. TCP for every byte; UDP for fresh over complete.
When would you pick UDP over TCP?

Ask whether a late-but-correct byte is worth more than an on-time one. If yes (files, web pages, payments, email), TCP. If no (live video, voice, games, telemetry), UDP, because by the time TCP resent the lost audio frame the moment it described is already gone. DNS uses UDP for its tiny queries and falls back to TCP when the answer is too big for one datagram.

What is head-of-line blocking, and why does HTTP/3 run over UDP?

TCP delivers one ordered stream, so one lost segment blocks every byte behind it, even bytes that already arrived. HTTP/2 multiplexes many independent requests over one TCP connection, so one lost packet stalls all of them. QUIC (RFC 9000), the transport under HTTP/3, rebuilds reliability on top of UDP with independent streams. A lost packet only stalls the stream it belonged to. It also folds the TLS handshake into its own, so setup is 1-RTT, or 0-RTT when resuming.

Can you get reliability over UDP?

Yes, you build it. The application or a library adds its own sequence numbers, acknowledgements, and retransmission for the parts that need them, and leaves the rest fast. QUIC is this done well. Game engines and media protocols often do it partially: resend critical events, drop stale position updates.

Why does a one-byte TCP message still feel heavy?

It carries a 20-byte TCP header plus 20 for IP. Nagle's algorithm may hold a small write until earlier data is acknowledged, and the receiver may delay its ACK hoping to piggyback it on a reply. Together those can add tens of milliseconds to small request/response exchanges. Latency-sensitive apps set TCP_NODELAY to turn Nagle off.

TCP vs UDP at a glance
TCPUDP
ConnectionConnection-oriented (3-way handshake first)Connectionless (just send)
ReliabilityReliable — ACKs + retransmissionUnreliable — no ACKs, no resend
OrderingOrdered byte streamUnordered, independent datagrams
BoundariesStream (no message boundaries)Preserves message boundaries
Flow / congestion controlYes (sliding window + AIMD)No (app's responsibility)
Header size20 bytes min (up to 60)8 bytes, fixed
Setup latency~1 RTT before data (more with TLS)Zero — first packet is data
Latency under lossStalls (head-of-line blocking)None — lost packet just skipped
Use casesWeb/HTTP, files, email, SSH, databasesDNS, video/voice, games, QUIC/HTTP-3

Every TCP 'yes' costs latency and header bytes. Every UDP 'no' buys speed, at the price of guarantees you must supply yourself if you need them. A UDP app that skips congestion control can flood a network, so 'you're on your own' cuts both ways.

How each one fails
  • TCP, half-open connections. If one side vanishes without a proper close (a crash, a pulled cable), the other side can hold a connection that no longer exists. Keepalives and timeouts are how you notice and reclaim it.
  • UDP, silent loss and reordering. Datagrams vanish or arrive out of order with no notification. Any application that cares must add its own sequence numbers, acknowledgements, or forward error correction.
  • UDP, amplification floods. There is no handshake to prove the sender's address, so an attacker spoofs a victim's IP and gets UDP services like DNS and NTP to blast large replies at the victim. The same no-handshake property that makes UDP fast makes it easy to abuse.
  • Loss is normal, not rare. Congested routers drop packets as their normal way of saying 'slow down', and Wi-Fi and cellular links lose packets constantly. A UDP application that needs any reliability has to plan for loss from the start.
References & further reading
References
Up nextHTTP & APIs
RelatedClient ↔ ServerDNS Resolution← Back to the learning path

Feedback on this topic →