Why TCP’s Three‑Way Handshake and Four‑Way Teardown Matter for Reliable Networks

Introduction: Why You Must Understand TCP Handshakes and Teardowns

In the world of the Internet, TCP (Transmission Control Protocol) is the foundation of data transmission. Whether streaming short videos, gaming, browsing, emailing, or video calling, TCP ensures reliable delivery, and its three‑way handshake and four‑way teardown are the key mechanisms for establishing and terminating connections.

1. TCP Protocol: The "Reliability Guardian" of Network Communication

1.1 Core Characteristics of TCP

TCP is a connection‑oriented, reliable, byte‑stream transport‑layer protocol whose primary goal is to ensure accurate data delivery over unreliable networks.

Reliability : Uses sequence number, acknowledgment number and retransmission mechanism to guarantee no loss or reordering.

Full‑duplex communication : Both client and server can send and receive data simultaneously.

Flow control and congestion control :

Dynamically adjusts transmission rate to avoid network overload

.

1.2 TCP vs UDP

TCP : Suitable for scenarios requiring high reliability (e.g., file transfer, web page loading).

UDP : Suitable for real‑time scenarios (e.g., live video, online gaming).

2. Three‑Way Handshake: The "Trust Ceremony" for Establishing Connections

2.1 Handshake Process

The three‑way handshake proceeds as follows:

Client sends SYN

Client: "Hey server, I want to communicate!"

Generates initial sequence number (Seq=x).

Server responds with SYN‑ACK

Server: "Okay, I’m ready! My initial sequence number is y."

Acknowledges client’s SYN with Ack=x+1.

Client sends ACK

Client: "Received your y, let’s start communication!"

Acknowledges server’s SYN with Ack=y+1.

[客户端]            [服务器]
    |               |
    | 1. SYN=1, seq=x |-------->
    |               |
    |<-------- 2. SYN=1, ACK=1, seq=y, ack=x+1
    |               |
    | 3. ACK=1, ack=y+1 |-------->
    |               |

Analogy : The three‑way handshake is like a dating ritual—first message, reply, and final confirmation.

2.2 Why Three Steps?

(1) Vulnerability of Two‑Way Handshake

If only two steps were used, a delayed SYN could be retransmitted, causing the server to treat duplicate SYNs as separate connection requests, wasting resources (half‑open connections).

(2) Significance of Three‑Way Handshake

Bidirectional confirmation : Ensures both client and server can confirm each other's send/receive capabilities.

Prevents stale connections : Sequence numbers avoid old SYN packets interfering with new connections.

(3) Redundancy of Four‑Way Handshake

Three steps already achieve bidirectional confirmation; adding more steps only increases overhead.

3. Four‑Way Teardown: The "Farewell Ceremony" for Graceful Connection Closure

3.1 Teardown Process

The four‑way teardown proceeds as follows:

Client sends FIN

Client: "I have no more data, ending communication."

Sequence number Seq=u.

Server responds with ACK

Server: "Received, I know you have no data."

Ack=u+1; server may still send data.

Server sends FIN

Server: "I’m also ready to close the connection."

Sequence number Seq=v.

Client responds with ACK

Client: "Acknowledged, we officially end communication."

Ack=v+1, entering TIME‑WAIT state.

[客户端]            [服务器]
    |               |
    | 1. FIN=1, seq=u |-------->
    |               |
    |<-------- 2. ACK=1, ack=u+1
    |               |
    |               |<-------- Data transmission (possible)
    |               |
    |<-------- 4. FIN=1, seq=v, ack=u+1
    | 3. ACK=1, ack=v+1 |-------->
    |               |

Analogy : The four‑way teardown is like a breakup—mutual agreement followed by final confirmation.

3.2 Why Four Steps?

3.2.1 Full‑Duplex Closure Requirement

TCP allows both sides to send data simultaneously, so each direction must be closed separately.

First teardown closes the active sender’s channel; third teardown closes the passive sender’s channel.

3.2.2 Ensuring Data Transfer Completeness

The second ACK confirms the active side’s FIN, while the passive side may still have data to send.

The third and fourth steps ensure all remaining data is transmitted and acknowledged.

3.2.3 Role of TIME‑WAIT

After the fourth ACK, the client stays in TIME‑WAIT for 2 MSL to ensure any stray packets are discarded, preventing interference with future connections.

3.2.4 Why Not Three Steps?

With only three steps, the passive side could not confirm that its FIN was received, leading to inconsistent connection states.

4. TCP Reliability Mechanisms in Detail

4.1 Core Mechanisms

Sequence and Acknowledgment Numbers : Every byte has a unique sequence number; the receiver acknowledges the range received.

Timeout Retransmission : If an ACK is not received, the sender retransmits the packet.

Sliding Window : Dynamically adjusts the sending rate to avoid congestion.

4.2 Practical Scenario: HTTP vs WebSocket

HTTP : TCP‑based half‑duplex request‑response protocol, suited for short connections.

WebSocket : TCP‑based full‑duplex protocol, ideal for real‑time communication such as chat or stock feeds.

5. Limits of TCP Connections: How Many Can a Server Handle?

5.1 Theoretical Calculation

Memory limitation : Each TCP connection consumes ~3.15 KB (send/receive buffers of 1.5 KB each). An 8 GB memory server could theoretically support millions of connections.

Port limitation : Local port range (e.g., 1024‑65535) provides about 64 k ports, extendable with multiple IPs.

5.2 Practical Optimizations

TIME‑WAIT reuse : Enable net.ipv4.tcp_tw_reuse to reduce TIME‑WAIT count.

Connection pooling : Reuse long‑lived connections to avoid frequent handshakes.

Kernel parameter tuning : Adjust net.core.somaxconn and net.ipv4.tcp_max_syn_backlog to increase concurrency.

6. Summary: TCP’s "Love Philosophy" and Future Outlook

TCP’s three‑way handshake and four‑way teardown are the pillars of reliable communication: the handshake ensures trustworthy connection establishment, while the teardown guarantees graceful termination and data integrity. In high‑concurrency scenarios, mastering these mechanisms and tuning server settings is essential for building high‑performance systems.

Looking ahead, the rise of QUIC (a UDP‑based multiplexing protocol) may challenge TCP’s dominance, but its core principle—balancing reliability and efficiency—will remain a timeless theme in network communication.