Why Does TCP Need a Three‑Way Handshake and a Four‑Way Teardown? A Deep Dive

What Is “Three‑Way Handshake, Four‑Way Teardown”

TCP is a connection‑oriented byte‑stream protocol; before any data is exchanged the client and server must establish a connection, which is achieved by exchanging three packets (SYN, SYN‑ACK, ACK). The connection is closed with a four‑step FIN/ACK exchange.

TCP Service Model

A TCP connection is identified by a 4‑tuple (source IP, source port, destination IP, destination port) and proceeds through three phases: establishment, data transfer, and termination. ACKs are cumulative, and the protocol provides reliable, ordered delivery using sequence numbers.

TCP Header

The header contains source and destination ports, a 32‑bit sequence number, an acknowledgment number, flags (SYN, ACK, FIN, RST), and a header‑length field measured in 32‑bit words (minimum 20 bytes, maximum 60 bytes). The SYN flag initiates a connection, FIN terminates it, and ACK confirms receipt.

State Transitions

The diagram shows the TCP state machine for the three‑way handshake and four‑way teardown, illustrating transitions such as LISTEN → SYN‑RCVD → ESTABLISHED → FIN‑WAIT‑1 → … → TIME‑WAIT.

Why Three Handshakes?

Each step confirms both the sending and receiving capabilities of the two parties: the first SYN proves the client can send; the SYN‑ACK proves the server can receive and send; the final ACK proves the client can receive the server’s response, ensuring a reliable bidirectional channel.

Four‑Way Teardown

When one side wishes to close, it sends a FIN; the peer acknowledges with ACK, then the peer sends its own FIN, which is finally ACKed. This four‑step process guarantees that all in‑flight data is delivered before the connection is fully closed.

Sequence Number Wraparound

Because the Initial Sequence Number (ISN) is a 32‑bit value, it eventually wraps around. TCP must compare sequence numbers correctly even after wraparound, which is typically done using signed arithmetic.

/** The next routines deal with comparing 32‑bit unsigned ints
 * and worry about wraparound (automatic with unsigned arithmetic). */
static inline int before(__u32 seq1, __u32 seq2){
    return (__s32)(seq1 - seq2) < 0;
}
#define after(seq2, seq1) before(seq1, seq2)

SYN‑Flood Attack and Mitigation

A SYN‑flood overwhelms a server by sending many SYN packets, forcing the kernel to allocate a TCB for each half‑open connection. Common defenses include limiting the SYN backlog, using SYN‑CACHE, SYN‑COOKIE, or a SYN‑PROXY firewall.

Connection Queues

The kernel maintains a half‑open (SYN‑RCVD) queue and a full‑open (ESTABLISHED) queue. When the half‑open queue exceeds max_syn_backlog, new SYNs are dropped or reset based on tcp_abort_on_overflow. When the full‑open queue is full, further ACKs may be ignored, causing the client to time out.

Practical Example: Redis Handshake Capture

Using tcpdump on a Redis server (port 6379) the following packets were captured:

Client sends SYN (seq = 4133153791).

Server replies SYN‑ACK (ack = 4133153792, seq = 4264776963).

Client sends ACK (seq = 4133153792, ack = 4264776964) – handshake complete.

Client sends PING command (payload “ping”).

Server replies PONG (payload “+PONG\r\n”).

Each packet’s IP and TCP headers were dissected to show sequence numbers, flags, and payload lengths.

Summary

The three‑way handshake and four‑way teardown are not merely textbook steps; they embody mechanisms for capability verification, reliable ordering, and graceful resource release. Understanding these processes reveals related concepts such as half‑open and full‑open queues, sequence‑number wraparound, and defenses against SYN‑flood attacks.

References

Redis packet‑capture analysis, TCP option documentation, sliding‑window explanations, backlog management articles, Linux kernel source snippets, and various networking tutorials.