TCP Three-Way Handshake

The three-way handshake culminates in the client's final ACK segment—a deceptively simple packet that carries enormous significance. This third message transforms a tentative, half-open connection into a fully ESTABLISHED bidirectional communication channel.

Until this ACK arrives, the server sits in a vulnerable SYN_RECEIVED state: resources allocated, sequence number proposed, but no confirmation that the client is still alive and ready to communicate. The final ACK delivers that confirmation, triggering the last state transition and enabling the flow of application data.

The final ACK of the three-way handshake serves a single but critical purpose: confirming to the server that the client received the SYN-ACK. This confirmation is essential for several reasons:

1. Validating Bidirectional Communication:

After the SYN-ACK, we know:

• ✓ Client → Server works (the SYN arrived)
• ✓ Server → Client works (the SYN-ACK arrived)
• ✗ Server doesn't know its SYN-ACK arrived until ACK confirms it

The final ACK completes the validation loop, proving both directions are functional.

2. Acknowledging the Server's ISN:

The SYN-ACK contained the server's Initial Sequence Number. Without an acknowledgment, the server can't be sure the client knows where to expect the server's first data byte. The ACK's acknowledgment number (server's ISN + 1) confirms this.

3. Releasing the Server from SYN_RECEIVED:

While in SYN_RECEIVED, the server has committed resources but can't transfer data. The ACK transitions the server to ESTABLISHED, enabling data transfer and freeing it from the handshake's vulnerability window.

The Acknowledgment Semantics:

In the final ACK:

Acknowledgment Number = Server's ISN + 1

Just as the server's SYN-ACK acknowledged the client's SYN (client_ISN + 1), the client's ACK acknowledges the server's SYN-ACK (server_ISN + 1). This symmetry is elegant and intentional:

The final ACK is typically the simplest packet in the handshake—often just a TCP header with no data and no options. Let's examine its structure:

Key Observations:

1. Flags = 0x10 (ACK only) — Unlike the SYN-ACK which had both flags set (0x12), the final ACK has only the ACK flag. The binary representation: 0001 0000 = 0x10.

2. Sequence Number = Client's ISN + 1 — The SYN consumed sequence number ISN. The next sequence number (for data or control) is ISN + 1. Even though this pure ACK carries no data, the sequence field indicates where data would start.

3. No Options (Typically) — Option negotiation is complete. The final ACK usually carries no options, resulting in a minimal 20-byte header. Some implementations may include Timestamps if negotiated.

4. Window Update — The window size reflects the client's current receive buffer availability. This is the first 'real' window advertisement since the handshake is completing.

The final ACK triggers the last state transition in connection establishment. However, the timing is subtly different for client and server:

Client's Perspective:

The client transitions to ESTABLISHED when it sends the final ACK, not when it's confirmed received. From the TCP state machine:

SYN_SENT → (receive SYN-ACK, send ACK) → ESTABLISHED

This means the client enters ESTABLISHED before the server does. The client can immediately start sending data (though it may be buffered until the three-way handshake completes).

Server's Perspective:

The server transitions to ESTABLISHED when it receives the final ACK:

SYN_RECEIVED → (receive ACK) → ESTABLISHED

Until this ACK arrives, the server remains in the vulnerable half-open state.

The Asymmetry Matters:

The client enters ESTABLISHED half an RTT before the server. This has practical implications:

1. Client can send data immediately — Data sent after the ACK may arrive at the server before the ACK does. The server will buffer this data until it enters ESTABLISHED.

2. Connection accept timing — The application's accept() call returns only when the connection reaches ESTABLISHED. Server-side timers measuring 'time to first byte' should account for this.

3. Error handling — If the ACK is lost and the server eventually times out, the client thinks the connection is open while the server has abandoned it. Keepalives or data transmission will eventually detect this.

The ESTABLISHED State:

Once ESTABLISHED, both sides can:

• Send and receive application data
• Acknowledge received data
• Perform flow and congestion control
• Eventually close the connection gracefully

One of TCP's elegant optimizations is the ability to piggyback data on acknowledgment segments. The final handshake ACK is no exception—application data can (and often should) be included.

Why Piggyback Data?

Without piggybacking:

Client: SYN
Server: SYN-ACK
Client: ACK (empty)         ← Packet #3
Client: DATA (GET /index.html)  ← Packet #4

With piggybacking:

Client: SYN
Server: SYN-ACK  
Client: ACK + DATA (GET /index.html)  ← Packet #3 with data

Piggybacking saves one packet, reducing latency and network overhead.

The Piggybacked ACK Structure:

When data is included, the segment looks like:

Flags: 0x18 (PSH + ACK)
Sequence Number: Client_ISN + 1
Acknowledgment: Server_ISN + 1
Data: Application payload (e.g., HTTP request)

Notice the PSH (Push) flag is typically set along with ACK, telling the receiver to deliver data to the application promptly rather than buffering.

Example: HTTP Request on Final ACK:

The final ACK, like any packet, can be lost in transit. This creates an interesting asymmetry: the client believes the connection is ESTABLISHED while the server remains in SYN_RECEIVED.

The Lost ACK Scenario:

Recovery Mechanism:

1. Server retransmits SYN-ACK — After a timeout (typically ~3 seconds initially), the server sends another SYN-ACK since it hasn't received the expected ACK.

2. Client responds to duplicate SYN-ACK — When the ESTABLISHED client receives a SYN-ACK, it knows the server hasn't received the ACK. It retransmits the ACK (this is idempotent and safe).

3. Recovery succeeds — The retransmitted ACK reaches the server, completing the handshake.

If Client Sends Data:

Interestingly, if the client sends data before the ACK recovery:

1. Client sends ACK + data (or just data with ACK flag)
2. ACK is lost, data reaches server
3. Server receives data segment with ACK flag set
4. Server sees ACK = Server_ISN + 1, transitioning to ESTABLISHED
5. Connection recovered without explicit ACK retransmission

This is why the server's SYN-ACK retransmit timer is important—it provides a fallback when the client's first acknowledgment is lost but no data follows immediately.

The server must carefully validate the incoming ACK to prevent attacks and ensure it corresponds to the correct half-open connection.

ACK Validation Checks:

Security Implications:

ACK Flooding Attack: An attacker sends many ACK packets with random acknowledgment numbers, hoping to match half-open connections and complete handshakes for spoofed IPs. Defenses:

• Cryptographic ISN generation makes guessing server's ISN infeasible
• Rate limiting on ACK acceptance
• SYN cookies (which don't have vulnerable SYN_RECEIVED state)

RST Attack (Connection Reset Attack): An off-path attacker who guesses the sequence and acknowledgment numbers can send a RST to tear down connections. This is why cryptographic ISN matters—it makes sequence space unpredictable.

SYN Cookie ACK Validation: When SYN cookies are active, the ACK validation is different:

1. Server computes expected cookie value from ACK - 1
2. Validates cookie against stored secret key and connection parameters
3. If valid, creates TCB and enters ESTABLISHED
4. If invalid, drops the ACK (no RST, to avoid being an amplifier)

When the final ACK transitions a connection to ESTABLISHED, the operating system must notify the listening application. This involves the accept queue—a kernel data structure holding completed connections waiting for the application to accept them.

The Two Queues:

Modern TCP implementations maintain two queues for incoming connections:

Connection Lifecycle through Queues:

SYN arrives → SYN Queue entry created → SYN-ACK sent
                     ↓
              ACK arrives
                     ↓
SYN Queue entry removed → Accept Queue entry created → ESTABLISHED
                                    ↓
                          Application calls accept()
                                    ↓
                          Connection socket returned

What Happens When Accept Queue Is Full:

If the accept queue is full when a connection completes:

The default Linux behavior (ignoring the ACK) allows the connection to complete once the application catches up and frees accept queue space.

Let's examine an actual final ACK packet from a network capture, including one with piggybacked data:

Analysis of Pure ACK:

1. Flags = 0x010 — Only ACK flag set, no SYN, no PSH
2. Sequence = 1 (relative) — Client's ISN was 0 (relative), consumed by SYN, so next is 1
3. Acknowledgment = 1 (relative) — Server's ISN was 0 (relative), +1 for SYN-ACK acknowledgment
4. Header Length = 20 bytes — Minimal header, no options
5. Segment Length = 0 — No data payload
6. Time since handshake start — ~25ms total, ~12ms for this leg (half RTT)

Final ACK with Piggybacked Data:

The three-way handshake imposes a fundamental latency cost on every TCP connection. Understanding this cost is critical for performance optimization, especially for short-lived connections.

The 1.5 RTT Cost:

From the client's perspective:

T=0:      Send SYN
T=RTT/2:  Receive SYN-ACK, send ACK, enter ESTABLISHED
T=RTT:    ACK reaches server, server enters ESTABLISHED

The client can begin sending data at T=RTT/2 (1.5 RTT after the very first packet if we count the server receiving and processing). For the first useful response, we need:

Time to first byte (client sends request):
  = 1 RTT (handshake SYN → client established) + 0 (piggybacked request)
  = 1 RTT

Time to first response byte:
  = 1 RTT (request sent) + RTT/2 (server processes) + RTT/2 (response arrives)
  = 2 RTT minimum

Implications for Modern Web:

A typical web page loads dozens of resources. If each requires a new TCP connection:

• 20 resources × 100ms RTT = 2 seconds just in handshakes
• Plus actual data transfer time
• Plus TLS handshake (another 1-2 RTT for HTTPS)

Optimizations:

We've comprehensively examined the final ACK—the segment that completes TCP's three-way handshake and enables reliable communication. Let's consolidate the essential knowledge:

What's Next:

With the three-way handshake complete—SYN, SYN-ACK, ACK—the connection is ESTABLISHED. But this is just the mechanism. In the next page, we'll step back and examine connection establishment as a holistic process: the complete state machine, simultaneous open scenarios, connection timeouts, and how the handshake interacts with the operating system's socket API.