Why does TCP use a three-way handshake to establish a connection?
Interview preparation resource from Gate Smashers.
TCP uses a three-way handshake so that both endpoints establish a shared connection state, exchange and acknowledge each other’s initial sequence numbers, and verify that communication can proceed in both directions. The final ACK is necessary because the server must know that the client received the server’s SYN and initial sequence number before treating the connection as established.

What TCP must establish
TCP is a stateful, full-duplex byte-stream protocol. Before data transfer, each endpoint needs to create connection state and learn the peer’s initial sequence number so that bytes can be numbered, acknowledged, and reliably delivered.
The endpoints do not use the same initial sequence number. Each side chooses its own initial sequence number, and the handshake lets the other side acknowledge it.
Three handshake messages
The handshake supplies the required exchange and acknowledgments in three segments.
- SYN: The active opener sends a SYN containing its initial sequence number.
- SYN-ACK: The passive opener acknowledges the client’s SYN and sends a SYN containing its own initial sequence number.
- ACK: The active opener acknowledges the server’s SYN, confirming that it received the server’s sequence information.
Why two messages are insufficient
After sending a SYN-ACK, the server knows that the client initiated a connection and that the client’s initial sequence number was received. However, it does not yet know whether the client received the server’s SYN and initial sequence number.
The third message provides that confirmation. It allows the server to enter the established state only after the client has acknowledged the server’s SYN, avoiding premature allocation of a fully established connection for a request that may not have reached the client.
Protection against stale connection requests
The handshake also helps TCP distinguish a current connection attempt from delayed or duplicate segments from an earlier attempt. A stale SYN alone cannot complete a new connection, because the peer’s SYN must be acknowledged by the original initiator before the server regards the connection as established.
