Master TCP Handshakes: The Simplest Guide to 3‑Way and 4‑Way Connections

TCP Three‑Way Handshake and Four‑Way Termination (Beginner‑Friendly Guide)

1. Prerequisite Knowledge

TCP protocol features:

Connection‑oriented: a dedicated channel is established before communication.

Reliable transmission: acknowledgments guarantee data delivery.

Full‑duplex: both sides can send data simultaneously.

Flow control: sliding‑window mechanism.

Congestion control: slow‑start algorithm.

2. Key Terminology

SYN : Synchronize flag, used to initiate a connection.

ACK : Acknowledgment flag, confirms receipt of data.

FIN : Finish flag, signals connection release.

SEQ : 32‑bit sequence number, ensures ordered delivery.

ACK number : Expected next sequence number (SEQ+1).

State codes : e.g., SYN_SENT, ESTABLISHED, etc., describe TCP states.

3. Three‑Way Handshake (Connection Establishment)

Scenario simulation: Imagine a phone call – first you say “Hello?”, the other replies “Can you hear me?”, then you confirm “I can hear you”.

Technical steps:

Client>>Server: SYN=1, SEQ=X   // client enters SYN_SENT
Server>>Client: SYN=1, ACK=1, SEQ=Y, ACK=X+1   // server enters SYN_RCVD
Client>>Server: ACK=1, SEQ=X+1, ACK=Y+1   // both enter ESTABLISHED

First Handshake (SYN)

Client sends SYN packet.

Client state becomes SYN_SENT.

Second Handshake (SYN+ACK)

Server returns a packet with both SYN and ACK set.

Server state becomes SYN_RCVD.

Third Handshake (ACK)

Client sends ACK packet.

Both sides enter ESTABLISHED state.

High‑frequency interview question: Why three handshakes?

Prevent stale connections : avoids old SYN packets causing erroneous connections.

Synchronize initial sequence numbers : ensures both ends can send/receive correctly.

Avoid resource waste : the server allocates resources only after the second handshake, mitigating SYN‑flood attacks.

4. Four‑Way Handshake (Connection Release)

Scenario simulation: Ending a call – you say “I’m done, hang up”, the other acknowledges, then says “I’m done too”, and finally both hang up.

First Termination (FIN)

Active closer sends FIN.

State becomes FIN_WAIT_1.

Second Termination (ACK)

Passive side returns ACK.

Passive side enters CLOSE_WAIT (half‑close).

Active side moves to FIN_WAIT_2 after receiving ACK.

Third Termination (FIN)

Passive side sends its own FIN after all data is sent.

State becomes LAST_ACK.

Fourth Termination (ACK)

Active side acknowledges the final FIN.

Passive side closes the connection after receiving this ACK.

High‑frequency interview question: Why four terminations?

Half‑close feature : FIN only stops the sender; the receiver may still have data to send.

ACK delay : Separating FIN and ACK avoids state confusion caused by delayed packets.

Reliable termination : TIME_WAIT ensures the final ACK reaches the peer and old duplicate segments expire.

5. Key Supplementary Knowledge

1. TIME_WAIT Details

Duration : 2 × MSL (Maximum Segment Lifetime). Linux default MSL = 60 s, so TIME_WAIT = 120 s.

Core purpose :

Guarantee the last ACK reaches the peer.

Allow old duplicate segments to expire in the network.

2. Abnormal Situations

Handshake packet loss : timeout retransmission (SYN retries controlled by /proc/sys/net/ipv4/tcp_syn_retries).

FIN loss : retransmit FIN until ACK received or timeout.

Server process crash : client data triggers RST reset.

Network interruption : TCP Keepalive heartbeat detection.

6. Practical Packet Capture (Wireshark Demo)

Three‑way handshake:
1 0.0000 192.168.1.2 → 192.168.1.3 TCP [SYN] Seq=0
2 0.0008 192.168.1.3 → 192.168.1.2 TCP [SYN, ACK] Seq=0 Ack=1
3 0.0010 192.168.1.2 → 192.168.1.3 TCP [ACK] Seq=1 Ack=1

Four‑way termination:
4 5.1234 192.168.1.2 → 192.168.1.3 TCP [FIN, ACK] Seq=1 Ack=1
5 5.1235 192.168.1.3 → 192.168.1.2 TCP [ACK] Seq=1 Ack=2
6 5.2345 192.168.1.3 → 192.168.1.2 TCP [FIN, ACK] Seq=1 Ack=2
7 5.2346 192.168.1.2 → 192.168.1.3 TCP [ACK] Seq=2 Ack=2

7. Frequently Asked Questions

Q1: What is a SYN‑flood attack?

Attackers forge massive SYN packets to exhaust server resources, filling the half‑connection queue and preventing legitimate requests.

Q2: Why can't we use a three‑way termination?

TCP is full‑duplex; both directions must be closed properly, requiring four steps.

Q3: How to handle excessive CLOSE_WAIT states?

Usually caused by applications not calling close(); check code to ensure sockets are properly closed.

Q4: How to optimize TIME_WAIT?

Adjust kernel parameter net.ipv4.tcp_tw_reuse.

Use SO_REUSEADDR socket option.

Prefer long‑lived connections.