TCP and UDP — study guide

Two ways to send — TCP and UDP

Almost everything two computers say to each other travels in one of two delivery styles, and the difference between them is a genuine engineering tradeoff, not a ranking.

TCP (Transmission Control Protocol) is connection-oriented. Before any real data moves, the two sides run a short three-step greeting called the handshake — like starting a phone call: you ask "can you hear me?", they answer "yes — can you hear me?", you say "yes", and only then does the real conversation begin. Once both sides agree the line is live, TCP numbers every byte, confirms every delivery, and quietly re-sends anything that gets lost. You get a reliable, ordered stream, and you pay for it in time and bookkeeping.

UDP (User Datagram Protocol) skips the greeting entirely. It wraps your data in a datagram, sends it, and moves on — no connection, no confirmation, no retry. It is as close to raw speed as the network offers, and it makes you no promises at all.

The model on this page lets you step through the TCP handshake one packet at a time, then fire a single UDP datagram for contrast. Every part of it — each packet, port, and state badge — can be clicked to explain itself.

Client and server — who speaks first

The two ends of a connection are not equals, and the asymmetry is the whole point. The server sits and waits: it has announced, in effect, that anyone who wants a particular service can reach it at a particular port, and it holds that door open indefinitely. The client is the one who wants something right now, so the client always makes the first move.

That first move is what the handshake choreographs. The client sends the opening packet, the server answers, and the client confirms — after which the roles relax and either side may send data. Client and server describe who initiated, not who is more important: your laptop is a client when it fetches a web page and could be a server five minutes later when another machine connects to something it runs.

Ports — many conversations, one machine

An IP address gets a packet to the right machine, but a machine runs many programs at once, and each of them may be holding its own conversations. Ports solve this: every TCP or UDP packet carries a source port and a destination port, each a number from 0 to 65535, and the operating system uses them to hand each arriving packet to the right program — like mailboxes in an apartment building: the street address gets a letter to the right building, and the apartment number gets it to the right door.

Servers use well-known ports so clients can find them without asking: 443 for HTTPS, 80 for plain HTTP, 53 for DNS. Clients do the opposite — the operating system assigns them a temporary, so-called ephemeral port (like the 51600 in this model) for the duration of one conversation. That is why the model shows different numbers on each side: the server port is a public address, the client port is a return envelope.

SYN — asking to talk

The handshake opens with the client sending a small packet whose SYN flag is set. SYN is short for synchronize, and the packet carries no user data at all. It is a pure request: I would like a connection, and here is the starting number I will use to count my bytes.

That starting number is the initial sequence number, chosen effectively at random for each new connection. Everything TCP later guarantees — ordering, loss detection, retransmission — hangs off this count, so the very first thing each side must do is tell the other where its numbering begins.

Sending the SYN also moves the client into the SYN_SENT state: it has spoken, and now it waits. If no answer ever comes back, the client re-sends the SYN a few times with growing pauses and eventually gives up — which is exactly what a connection timeout is.

SYN-ACK — heard you, hear me?

When the listening server receives a SYN, it answers with a single packet doing two jobs at once, which is exactly what its name says. The ACK half acknowledges the client: I received your request, and I have recorded the number you count from. The SYN half is the server making the same request in the other direction: here is the starting number I will use for the bytes I send to you.

This matters because a TCP connection is two independent streams — client to server and server to client — and each needs its own agreed starting count. Folding the server's acknowledgment and its own synchronize into one SYN-ACK packet is why the whole handshake needs only three packets instead of four.

Sending it moves the server into the SYN_RECEIVED state: it has answered one specific client and is holding a half-open slot for it, waiting for the final confirmation before the connection counts as real.

ACK — the line is live

The third packet closes the loop. The client acknowledges the server's SYN-ACK, confirming it received the server's starting number, and with that both sides have heard the other and been heard — the definition of an established connection.

Why is this third step needed at all? Because after two packets the knowledge is lopsided: the server has answered, but it cannot know whether its answer arrived. The final ACK is the client telling it so. Three messages is provably the minimum for two parties on an unreliable network to each know the other can both send and receive.

The client typically considers the connection open the moment it sends this ACK, and real requests often ride out immediately behind it. When the ACK lands, the server promotes its half-open slot to a full connection, and from here on the handshake machinery disappears — every later packet uses the same acknowledgment scheme, but now carrying actual data.

Connection state — what each side believes

A TCP connection is not a wire; it is an agreement, and each side tracks its half of the agreement in a small state machine. The badges in the model show the states this concept needs: CLOSED (no conversation, and none expected), LISTEN (the server holding the door open for anyone), SYN_SENT (the client has asked and awaits an answer), SYN_RECEIVED (the server has answered one client and holds a half-open slot), and ESTABLISHED (both sides confirmed — data may flow).

Notice that during the handshake the two sides are usually in different states, because each has seen a different subset of the packets. State only ever changes when a packet arrives or is sent, which is what makes the stepper honest: every click that moves a packet is exactly one state transition somewhere.

The full TCP state machine has more entries covering how connections close and time out, but this ladder — CLOSED to LISTEN to the handshake pair to ESTABLISHED — is the load-bearing part, and it is the vocabulary tools like netstat and ss print when you ask a real machine what it is doing.

UDP — skip the ceremony

The last packet in the model is the entire UDP story. No handshake came before it, no acknowledgment follows it, and neither side changed state — because with UDP there is no state to change. A program says send this, the datagram leaves, and the sender immediately moves on, like dropping a postcard in a mailbox: quick and cheap, but nobody tells you whether it arrived.

What UDP gives up is everything TCP spends the handshake setting up: delivery is not confirmed, order is not promised, and a lost datagram is simply gone unless the application itself notices and re-sends. What it gains is the absence of all that machinery — no round trip before the first byte, no per-connection memory on either machine, and one packet where TCP needs several.

That is why UDP is not a broken TCP but a different contract: it hands the reliability decisions up to the application, which may have better ideas about which losses matter than the transport ever could.

When each one wins

Choose by asking one question: what should happen when a packet is lost? If the answer is it must be delivered anyway, in order, you want TCP. Web pages, file downloads, email, database traffic and ssh sessions all pick TCP, because a missing chunk makes the whole thing wrong, and waiting for a re-send is the correct behavior.

If the answer is forget it, newer data has already replaced it, you want UDP. A lost frame of a video call or a stale position update in a game is worthless by the time it could be re-sent; re-delivering it would only delay the packets that still matter. DNS lookups pick UDP for a different reason: the exchange is one tiny question and one tiny answer, so the handshake would cost more packets than the conversation itself.

The pattern to keep: TCP buys correctness with time, UDP buys time by dropping guarantees, and well-known systems sit exactly where you would predict — with the interesting middle ground (like QUIC, which builds TCP-style reliability on top of UDP) proving it really is a spectrum of choices, not a fight with a winner.