The TCP handshake, explained simply
Every time an app on your phone loads a page, two computers that have never spoken before manage to agree, in a fraction of a second, that they're ready to talk — and that neither one is a ghost. That quiet negotiation is called the TCP handshake, and it happens before a single byte of your actual data goes anywhere.
Why bother shaking hands at all
TCP (Transmission Control Protocol) promises something IP alone can't: that data arrives in order, without gaps, and without duplicates. To keep that promise, both sides need to agree on a few things up front — that the other side actually exists and is listening, and a starting point for counting the bytes they're about to send. The handshake is how they establish that shared starting point before either one commits to sending real data.
Step one: SYN
The client — say, your browser — sends a small packet with the SYN flag set ("synchronize"). It also picks a random starting number called a sequence number, essentially saying: "I'd like to talk, and I'll start counting my bytes from this number." No data rides along yet. This packet's only job is to announce intent and propose a starting point.
Step two: SYN-ACK
The server receives that SYN and replies with a packet carrying two flags at once: SYN-ACK. The ACK ("acknowledge") confirms it received the client's sequence number by echoing back that number plus one. The SYN half is the server doing the same thing back — it picks its own random sequence number and proposes it to the client. So this one packet does double duty: confirm receipt, and propose a starting point of its own.
Step three: ACK
The client acknowledges the server's sequence number the same way — echoing it back plus one — in a final ACK packet. Now both sides have exchanged and confirmed a starting sequence number, and both have proof the other side is actually alive and listening (not a dead address, not a firewall silently swallowing packets). The connection is officially open. This third packet can even carry the first bit of real data, since by this point there's nothing left to negotiate.
Why three steps, not two
Two messages would let the client know the server is there, but the server would still be guessing whether the client actually received its reply — it could be shouting into a connection nobody's listening to. The third message closes that gap: it's the client's proof, delivered to the server, that the handshake actually worked both ways. This is also why the pattern is often described as "SYN, SYN-ACK, ACK" — three messages, but really two round trips of confirmation folded into three packets.
What this buys you
Once the handshake finishes, both sides know exactly which byte number comes next, which is what lets TCP detect a dropped packet, reorder ones that arrive out of sequence, and resend anything that goes missing — all invisibly, underneath whatever app you're actually using. Closing a connection later uses a similar back-and-forth (with FIN instead of SYN), because hanging up politely turns out to matter just as much as saying hello.
The takeaway
Before your data can travel reliably, two computers spend three tiny packets just proving to each other that they're both really there and agreeing on where to start counting. It adds a small delay to every new connection, which is exactly the cost technologies like TLS session resumption and HTTP keep-alive exist to avoid paying twice.
This explainer was made with LineLapse — type a topic, get a hand-drawn video. Make your own →