the three-way handshake

Before two people start an important conversation, they often confirm the line works: 'Can you hear me?' — 'Yes, can you hear me?' — 'Yes.' Now both know that each can hear the other, in both directions. TCP opens every connection with exactly this little ritual, called the three-way handshake. It's how the two ends agree to talk and get their bookkeeping in sync before any real data flows.

It takes three segments. First the initiator (say, your browser) sends a SYN segment — SYN means 'synchronize' — carrying its randomly chosen initial sequence number, call it x. The server replies with a SYN-ACK: it sets both the SYN flag (offering its own initial sequence number y) and the ACK flag (acknowledging x+1, meaning 'I heard your SYN, ready for your byte x+1'). Finally the initiator sends an ACK acknowledging y+1. After these three messages, both sides know the other's starting sequence number and that the path works both ways, and data transfer can begin (often the very next segment carries real data).

Why it matters: the handshake is what turns TCP from a one-shot send into a synchronized, reliable conversation — it establishes both ends' willingness to communicate and their initial sequence numbers in one round trip before data. Two honest points: it adds one round-trip-time of startup delay, which is why protocols like QUIC and TCP Fast Open work to shrink or skip it. And it is not authentication — completing a handshake proves only that something at the other address answered, not who they are; that's TLS's job. Its SYN step is also the target of the SYN-flood attack.