What Actually Happens During a TCP Handshake

Every reliable connection on the internet starts with a short negotiation, and almost every mysterious connectivity problem leaves its fingerprints there. Understanding the three messages involved is the difference between guessing at a firewall rule and reading the answer out of a capture.

Three messages, one agreement

The client sends a SYN, announcing an initial sequence number and the options it supports. The server answers with a SYN-ACK, acknowledging the client's number and proposing its own. The client replies with an ACK, and both sides now agree on where the conversation starts. Reference material on the exchange is plentiful — the protocol notes at the networking explainers here are a reasonable place to start — but the sequence itself is short enough to memorise.

What travels alongside those flags matters as much as the flags. Window scaling, selective acknowledgement, maximum segment size and timestamps are all negotiated here and cannot be renegotiated later. A middlebox that strips an option during setup will quietly degrade throughput for the life of the connection.

Reading failure modes

SYN with no response at all — traffic is being dropped silently, usually by a firewall
SYN answered by RST — something is actively refusing the port, often nothing listening
Repeated SYNs with growing gaps — the client retrying at exponential backoff
Handshake completes, then immediate RST — the application accepted and rejected you

That distinction between a drop and a reset is the single most useful diagnostic in the set. A silent drop points at policy; a reset points at a process.

Why round trips are expensive

The handshake costs one full round trip before any payload moves, and a TLS negotiation adds more on top. Over a 150-millisecond path, setup alone eats a substantial fraction of what users perceive as load time. This is why connection reuse, keep-alives and protocols that fold setup into fewer round trips exist. The savings are not theoretical — they are the whole reason those features were designed.

Practical takeaway

When something will not connect, capture the first four packets before touching anything else. They tell you whether the problem is reachability, policy, or the application itself, and they take ten seconds to collect. Most of the time the rest of the investigation is unnecessary.