TCP vs UDP: reliable or fast, pick one

Load a web page and you expect every byte of it to arrive, in order, with nothing missing. Drop a frame on a video call and nobody stops the call to redo it. Same internet, same packets, two completely different rules for what "delivered" even means. That difference is TCP versus UDP, and picking the right one is one of the first real design decisions anyone building a networked app has to make.

What a packet-switched network gets you for free (and what it doesn't)

The last lesson covered how data travels as individual packets, each routed independently, with no guarantee they arrive in order or arrive at all. That's IP's whole job, and it stops there on purpose. IP alone can't tell you if a packet got lost. It can't tell you if two packets arrived in the wrong order. It just moves data and shrugs.

Something has to sit on top of IP and decide what to do about that. That's the transport layer, and you almost always pick between two protocols: TCP and UDP.

TCP: reliable, ordered, and it costs you a handshake

TCP, the Transmission Control Protocol, turns that unreliable packet stream into something that behaves like a solid connection. Before either side sends any real data, they run a three-way handshake to agree the connection exists:

Three messages, no application data yet, just both sides agreeing a connection exists and picking starting sequence numbers. That sequence number is what makes reliability possible: TCP numbers every byte it sends, so the receiving side can detect a gap (something's missing, ask for it again) or reorder packets that arrived out of sequence. If an acknowledgment doesn't come back in time, TCP assumes the packet was lost and resends it automatically. None of this is visible to your application code. You write to a socket and TCP handles the bookkeeping underneath.

This is why loading a web page, downloading a file, or sending an email uses TCP. None of those tolerate missing pieces. A web page with a randomly missing paragraph of HTML, or a downloaded zip file missing 40 bytes somewhere in the middle, is just broken.

The cost is round trips. That handshake has to finish before any real data moves, and every lost packet later means a wait for a retransmission. On a slow or congested network, this adds up. It's also why the next lesson on TLS matters so much: TLS runs its own handshake on top of TCP's, so an HTTPS connection pays for two negotiations before a single byte of your actual request goes out.

UDP: fast, and reliability is your problem now

UDP, the User Datagram Protocol, skips almost all of that. There's no handshake. No sequence numbers. No automatic retransmission. You send a packet, called a datagram, and it either arrives or it doesn't, and UDP will never tell you which happened. It's the network equivalent of shouting something across a room. Fast, no setup required, and no guarantee anyone caught it.

That sounds worse in every way, until you consider what happens on a video call. Say Maya is on a video call and one video frame's packet gets lost. With TCP's rules, the connection would pause, wait for that frame to be retransmitted, and only then let the next frame through, even though by the time it arrives it's already old news. Maya doesn't want a perfectly complete video stream delivered three seconds late. She wants the most current frame available right now, and she'd rather the app just skip the dropped one and move on to the next. UDP lets an app do exactly that, because nothing in the protocol forces it to wait.

That's why UDP shows up under DNS lookups (a single small request and response, not worth the overhead of a handshake), video and voice calls, and online games, where a slightly stale position update is worse than useless. Applications that need some reliability on top of UDP build it themselves, tuned to what actually matters for that use case. HTTP/3, covered in a later lesson, does exactly this: it runs over UDP but adds its own reliability layer, one designed specifically to avoid a problem TCP has when packets get lost.

The trade-off in one sentence

TCP guarantees delivery and order, at the cost of setup time and the possibility of waiting on a retransmission. UDP guarantees neither, in exchange for sending data with essentially no overhead. Neither one is "better." They're solving different problems, and most of the internet's core services, DNS, HTTP, video calls, all pick deliberately based on which failure mode they can tolerate.

Everything so far, DNS, the connection itself, has been about getting bytes from one machine to another reliably (or fast). The next lesson is about what's actually inside those bytes once a TCP connection is open: the request and response format that makes the web work. On to HTTP: the request and response contract.