Connection Establishment: The Complete Process

We've examined each segment of the three-way handshake in isolation: SYN, SYN-ACK, and ACK. Now it's time to step back and see connection establishment as a complete process—a carefully choreographed dance between two endpoints that creates a reliable, bidirectional communication channel from nothing.

This page integrates our knowledge into a unified understanding of how connections are born. We'll trace the complete state machine, see how the socket API maps to protocol events, explore edge cases like simultaneous open and connection timeouts, and understand what happens when things go wrong.

TCP is a finite state machine—at any moment, each endpoint is in exactly one of 11 possible states. Connection establishment involves transitions through a subset of these states, from CLOSED to ESTABLISHED.

The Connection Establishment States:

State Transitions:

The canonical three-way handshake follows these transitions:

Client (Active Open):

CLOSED → [send SYN] → SYN_SENT → [receive SYN-ACK, send ACK] → ESTABLISHED

Server (Passive Open):

CLOSED → [listen()] → LISTEN → [receive SYN, send SYN-ACK] → SYN_RECEIVED → [receive ACK] → ESTABLISHED

Visual Representation:

TCP distinguishes between two types of connection initiation based on which side acts first:

Active Open (Client): The host initiates the connection by sending a SYN. This is called 'active' because the application takes action to establish the connection.

Passive Open (Server): The host waits for incoming connections. This is 'passive' because the application simply prepares to accept connections without initiating them.

Simultaneous Active Open:

An unusual but valid scenario: both sides perform active open at the same time. Neither waits for an incoming connection—both send SYN to each other simultaneously.

Host A: CLOSED → [send SYN to B] → SYN_SENT
Host B: CLOSED → [send SYN to A] → SYN_SENT

Host A: SYN_SENT → [receive SYN from B, send SYN-ACK] → SYN_RECEIVED
Host B: SYN_SENT → [receive SYN from A, send SYN-ACK] → SYN_RECEIVED

Host A: SYN_RECEIVED → [receive SYN-ACK] → ESTABLISHED
Host B: SYN_RECEIVED → [receive SYN-ACK] → ESTABLISHED

The result is a valid ESTABLISHED connection. This is rare in practice because it requires both sides to know each other's address and initiate connection simultaneously.

Applications interact with TCP through the socket API—a set of system calls that abstract the complexity of the protocol. Understanding how API calls map to handshake events is essential for application debugging.

Server-Side Socket API Sequence:

Client-Side Socket API Sequence:

Let's trace a complete connection establishment with precise timing, showing the interplay between TCP protocol events and application behavior.

Scenario: Client connects to a web server (RTT = 50ms)

Key Timing Observations:

1. Client connect() blocks for ~100ms (2× one-way latency = 1 RTT)

2. Server accept() returns at 150ms — half an RTT after client considers connection established

3. First data can flow at 100ms — client can piggyback data on ACK immediately

4. Total handshake time: 1.5 RTT — SYN to server (0.5 RTT) + SYN-ACK to client (0.5 RTT) + ACK to server (0.5 RTT)

With Data Piggybacking:

If client sends HTTP request with the ACK:

Time 100ms: Client sends ACK + "GET /index.html HTTP/1.1..."
Time 150ms: Server receives ACK+Request, begins processing
Time 150+X: Server sends response
Time 200+X: Client receives first response byte

Total time to first response byte: ~200ms + processing time

Not every connection attempt succeeds. TCP must handle scenarios where packets are lost, the server is unreachable, or the connection is refused. Different failure modes have distinct behaviors.

Timeout Scenarios:

SYN Retransmission:

When a SYN receives no response, TCP retransmits with exponential backoff:

Attempt 1: SYN sent at T=0
Attempt 2: SYN retransmit at T=1s (if no SYN-ACK)
Attempt 3: SYN retransmit at T=3s (1 + 2)
Attempt 4: SYN retransmit at T=7s (1 + 2 + 4)
Attempt 5: SYN retransmit at T=15s (1 + 2 + 4 + 8)
Attempt 6: SYN retransmit at T=31s (1 + 2 + 4 + 8 + 16)
Timeout: connect() fails at T=63s (varies by OS)

Linux default: tcp_syn_retries = 6 (approximately 127 seconds total timeout) This can be tuned per-socket or system-wide.

Application-Level Timeout Strategies:

# Python example: setting socket timeout
import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.settimeout(5.0)  # Fail if connect takes > 5 seconds

try:
    sock.connect(("server.example.com", 443))
except socket.timeout:
    print("Connection timed out after 5s")
except ConnectionRefusedError:
    print("Connection refused (server sent RST)")
except OSError as e:
    print(f"Connection failed: {e}")

Application timeouts are typically 5-30 seconds—much shorter than TCP's default ~127 seconds.

When both hosts simultaneously attempt to establish a connection to each other, TCP handles this gracefully through a four-message handshake (though it's really two SYNs crossing each other, then two SYN-ACKs).

Simultaneous Open Sequence:

The Key Insight:

When a host in SYN_SENT receives a SYN (not SYN-ACK), it recognizes this as simultaneous open. Instead of being confused, it:

1. Notes the peer's ISN from the incoming SYN
2. Sends a SYN-ACK (combining its own SYN with acknowledgment of peer's SYN)
3. Transitions to SYN_RECEIVED
4. Waits for peer's SYN-ACK to complete the handshake

Why This Works:

The SYN-ACK from each side serves as both:

• Acknowledgment of the peer's SYN (the ACK part)
• Retransmission of our own SYN (the SYN part, redundant but harmless)

Once each side receives the peer's SYN-ACK, both ISNs have been acknowledged, and both can transition to ESTABLISHED.

Connection establishment is a particularly vulnerable phase for TCP. The protocol must handle untrusted input while allocating resources, creating opportunities for attacks.

Attack Surface During Handshake:

Defense Mechanisms: