Three-Way Handshake
TCP Connection Setup (SYN, SYN-ACK, ACK)
The brief three-step greeting two devices exchange before TCP sends a single byte of real data. It guarantees both sides are ready and synchronised — and it quietly costs one round trip on every new connection.
The three-way handshake is how TCP establishes a connection before any application data is sent. Because TCP promises reliable, ordered delivery, both ends must first agree to talk and synchronise their starting sequence numbers. They do this with three messages — hence "three-way" — and only once the handshake completes does the actual data (a web page request, say) begin to flow.
The three steps
| Step | Message | Meaning |
|---|---|---|
| 1 | Client → Server: SYN | "I want to connect; here is my starting sequence number." |
| 2 | Server → Client: SYN-ACK | "Acknowledged; here is mine too." |
| 3 | Client → Server: ACK | "Acknowledged — let's begin." |
SYN is short for synchronise and ACK for acknowledge. After these three messages, both sides know the other is reachable and ready, and they have agreed on the sequence numbers used to keep data ordered and detect loss.
The latency cost
The handshake is fast on paper but it is not free: it takes roughly one full round trip before real data can move. On a connection with 20 ms latency that is a barely noticeable 20 ms, but to a server 300 ms away it is 300 ms of waiting per new connection, before the page even starts loading. Because a single web page often opens many connections, and a secure site then layers a TLS handshake on top, these setup round trips add up — and they are why high-latency links (like satellite) feel sluggish even when bandwidth is plentiful.
Why newer protocols cut it down
Reducing handshake round trips is a major theme in modern networking. TLS 1.3 trimmed its own handshake to a single round trip, and QUIC — the transport behind HTTP/3 — combines the connection and encryption setup so data can start flowing in as little as zero or one round trip, sometimes resuming instantly on a repeat visit. These designs exist precisely because the cumulative cost of setup round trips, including TCP's three-way handshake, is one of the biggest sources of "the web feels slow even on a fast connection."
Why UDP skips it
Not every protocol needs a handshake. UDP is connectionless: it fires packets off with no setup and no guarantee of delivery. That makes it start instantly and avoids the round-trip cost, which is exactly why real-time applications like online gaming and voice calls prefer it — for them, an occasional lost packet matters far less than the delay a handshake and retransmissions would add. TCP's handshake buys reliability; UDP trades that reliability away for speed.