How TCP Establishes a Reliable Connection
When a client successfully makes a request to a server over the internet—loading a web page, calling an API, downloading a file—there’s a carefully choreographed exchange happening underneath. Most of the time, that exchange uses TCP (Transmission Control Protocol).
This article explains how TCP establishes a connection using the three-way handshake, what flags like SYN and ACK actually mean, and how this differs from UDP, which takes a very different (and much simpler) approach.
Why a Handshake Is Needed at All
Networks are unreliable by nature:
- Packets can be lost
- Packets can arrive out of order
- Packets can be duplicated
- The sender and receiver may have very different speeds
TCP is designed to provide the illusion of a reliable, ordered byte stream on top of this unreliable reality. Before any application data is sent, both sides need to agree on some basics:
- “Are you there?”
- “Are you ready?”
- “Where do we start counting bytes from?”
That’s what the handshake is for.
The TCP Three-Way Handshake
The TCP handshake consists of three packets exchanged between client and server.
1. SYN — “I want to talk”
The client initiates the connection by sending a packet with the SYN (synchronize) flag set.
This packet says:
- “I want to open a connection”
- “Here is my initial sequence number (ISN)”
Sequence numbers are crucial: TCP numbers every byte it sends. The ISN is a random starting point that helps:
- Detect old or duplicate packets
- Prevent certain classes of attacks
- Ensure both sides agree on where the stream begins
At this point, no application data is sent.
2. SYN-ACK — “I hear you, and I’m ready”
If the server is willing to accept the connection, it responds with a packet that has both flags set:
- SYN: “I also want to talk”
- ACK: “I acknowledge your SYN”
This packet includes:
- The server’s own initial sequence number
- An acknowledgment number equal to the client’s ISN + 1
That acknowledgment number means:
“I received everything up to (and including) your SYN.”
The server is now prepared to receive data—but it’s still waiting for confirmation that the client heard this response.
3. ACK — “Let’s go”
Finally, the client sends an ACK packet back to the server, acknowledging the server’s sequence number.
After this:
- Both sides know the connection is established
- Both sides know the starting sequence numbers
- Data transfer can begin immediately
At this point, the TCP connection is fully open.
What ACKs Really Do
After the handshake, TCP continues to use ACKs constantly.
Key ideas:
- ACKs are cumulative: “I’ve received everything up to byte N”
- Missing data is inferred by gaps, not explicit “loss” messages
- If an ACK doesn’t arrive in time, the sender retransmits
This is how TCP guarantees:
- Reliable delivery
- In-order data
- Flow control (not overwhelming the receiver)
- Congestion control (not overwhelming the network)
What the Receiver Does
Imagine the receiver expects byte 1000 next.
Packets arrive like this:
- Segment [1000–1499]
- Segment [2000–2499]
- Segment [1500–1999]
Step-by-step behavior:
No retransmission happens because nothing was actually lost.
When Retransmission Does Happen
Retransmission occurs only if the sender believes data is missing.
This happens when:
- A segment truly gets lost
- ACKs stop advancing
- The sender sees duplicate ACKs (usually 3)
- A retransmission timer expires
Example:
- Sender sends 1000–1499, 1500–1999, 2000–2499
- Receiver only gets 1000–1499 and 2000–2499
- Receiver keeps ACKing 1500
- Sender eventually retransmits 1500–1999
How UDP Is Different
UDP (User Datagram Protocol) takes a radically different approach.
There is:
- ❌ No handshake
- ❌ No connection state
- ❌ No ACKs
- ❌ No retransmission
- ❌ No ordering guarantees
A UDP sender just sends packets, and the receiver either:
- Gets them
- Gets them out of order
- Gets duplicates
- Or doesn’t get them at all
UDP has no concept of “old” packets in the protocol itself. If a delayed packet arrives late, UDP will happily deliver it to the application. It’s up to the application to decide:
- Whether to discard it
- Whether to reorder it
- Whether to request a resend
This makes UDP:
- Faster to start (no handshake)
- Lower latency
- Simpler
But also:
- Unreliable by default
- Unsafe for many use cases without extra logic
Why We Still Use Both
TCP is ideal when:
- Every byte matters
- Order matters
- Reliability matters
Examples: HTTP, HTTPS, databases, SSH
UDP is ideal when:
- Latency matters more than perfection
- Occasional loss is acceptable
- Old data is of little use
Examples: video calls, online games, DNS
Interestingly, many modern protocols (like QUIC) run over UDP but re-implement TCP-like reliability at the application layer—showing that the handshake and ACK concepts are fundamental, even when TCP itself isn’t used.
Summary
- TCP establishes reliability using a three-way handshake (
SYN → SYN-ACK → ACK)
- Sequence numbers and
ACKs ensure data is ordered, complete, and fresh
- Old or duplicate packets are safely ignored
- UDP skips all of this, delivering packets with no guarantees
- The choice between TCP and UDP is a tradeoff between reliability and latency
Understanding the handshake helps explain not just how connections succeed—but why they sometimes stall, timeout, or fail under load.