Introduction
Because TCP is connection-oriented, both endpoints must agree to communicate and synchronize their initial sequence numbers before any application data flows. This setup process is called the three-way handshake, and it is unique to TCP - UDP, being connectionless, has no equivalent step and simply starts sending datagrams.
Cricket analogy: Before a match, both captains must meet for the toss and agree on terms; TCP's three-way handshake is that same mandatory agreement step, while UDP is like a street cricket game that just starts bowling without any formal toss.
Explanation
The handshake consists of exactly three segments. First, the client sends a SYN (synchronize) segment to the server, proposing an initial sequence number, for example seq=x. Second, the server responds with a SYN-ACK segment: it acknowledges the client's SYN by setting ack=x+1, and simultaneously proposes its own initial sequence number, seq=y. Third, the client responds with an ACK segment, setting ack=y+1 to acknowledge the server's sequence number. At this point both sides have confirmed they can send and receive, and have agreed on starting sequence numbers, so the connection is considered established (ESTABLISHED state) and application data can flow.
Cricket analogy: The handshake is like the toss: the visiting captain calls 'heads' (SYN, proposing seq=x), the home captain confirms hearing it and calls back their choice (SYN-ACK, ack=x+1, seq=y), and the visiting captain acknowledges the result (ACK, ack=y+1) before play begins.
The handshake exists specifically because TCP promises reliable, ordered delivery: sequence numbers are how TCP tracks which bytes have been sent and acknowledged, so both sides must agree on a starting point before anything else can be reliably tracked. UDP makes no such promises, so it needs no handshake and no sequence-number negotiation - a UDP sender can transmit a datagram to a receiver that has never communicated with it before, with no setup phase at all.
Cricket analogy: The handshake exists because a match needs an agreed starting over count and field settings before the first ball is bowled, just as TCP needs agreed sequence numbers before reliable delivery; a friendly backyard game (UDP) just bowls without any such agreement.
Example
# Simplified trace of a TCP three-way handshake with concrete sequence numbers
# 1. Client -> Server: SYN, seq=1000
# "I want to connect; my initial sequence number is 1000."
# 2. Server -> Client: SYN-ACK, seq=5000, ack=1001
# "I acknowledge your seq 1000 (expecting byte 1001 next);
# my own initial sequence number is 5000."
# 3. Client -> Server: ACK, ack=5001
# "I acknowledge your seq 5000 (expecting byte 5001 next)."
# Connection is now ESTABLISHED; application data can flow starting
# from seq=1001 (client) and seq=5001 (server).Analysis
Each acknowledgment number is the peer's sequence number plus one, because SYN and FIN flags each consume one sequence number even though they carry no application data. This is why the server's ACK in step 2 is x+1 rather than x, and the client's ACK in step 3 is y+1 rather than y. Only after all three segments are exchanged do both sides know: (a) the other side is reachable and willing to communicate, and (b) what sequence number to expect next. This is exactly why the handshake is TCP-specific - it is the mechanism that bootstraps TCP's reliability and ordering guarantees. UDP has no sequence numbers to synchronize and no connection state to establish, so it skips this process entirely.
Cricket analogy: Just as a bowler's practice run-up before the over doesn't count as a delivery but still uses time, the SYN and FIN flags consume a sequence number even though they carry no application data, which is why the acknowledgment is always one more than the proposed number.
Key Takeaways
- The handshake is SYN (client, seq=x) -> SYN-ACK (server, seq=y, ack=x+1) -> ACK (client, ack=y+1).
- SYN and FIN flags each consume one sequence number, which is why acknowledgments are x+1 and y+1.
- The handshake synchronizes initial sequence numbers, which TCP needs to track reliable, ordered delivery.
- UDP has no equivalent handshake because it is connectionless and makes no reliability/ordering guarantees.
- After the handshake completes, the connection is in the ESTABLISHED state and application data can flow.
Practice what you learned
1. What is the correct order of segments in the TCP three-way handshake?
2. If the client's initial SYN has seq=1000, what acknowledgment number will the server's SYN-ACK contain?
3. Why does UDP not perform a three-way handshake?
4. What TCP connection state is reached immediately after the three-way handshake completes successfully?
Was this page helpful?
You May Also Like
TCP vs UDP
Compare TCP and UDP across reliability, ordering, connection state, overhead, and typical use cases.
TCP Flow and Congestion Control
Distinguish TCP's receiver-driven flow control from its network-driven congestion control mechanisms.
Ports and Sockets
Understand port number ranges and how a socket, the pairing of an IP address and port, identifies a network endpoint.
Transport Layer Basics
Learn how the transport layer provides process-to-process delivery between applications running on different hosts.