Visualizing TCP Handshake and Teardown with Wireshark: A Step-by-Step Guide

Introduction

TCP three-way handshake and four-way termination are essential knowledge for developers and interviewees, forming the basis for optimizing web program performance. This article uses Wireshark to capture packets and illustrate the detailed process.

Three-way Handshake

Based on the diagram below, each arrow represents one handshake.

First handshake

The client sends a SYN (J) packet to the server and waits for an ACK reply, entering SYN‑SENT state.

Second handshake

The server receives the SYN(J) packet and returns an ACK(J+1) packet together with its own SYN(K) packet, then waits for the client’s ACK, entering SYN‑RECEIVED state.

Third handshake

After the client receives the server’s ACK(J+1) and SYN(K), it sends an ACK(K+1) packet back. The server receives this ACK and both sides move to ESTABLISHED state, completing the handshake.

Why three handshakes?

In the first exchange, A (client) confirms to B (server) that both can send and receive.

In the second exchange, B confirms to A that it can receive, but B still does not know its own sending capability, requiring a third exchange.

In the third exchange, A confirms to B that its sending capability is fine.

Wireshark verification

Wireshark captures show the three TCP requests before an HTTP request can be made.

First request: client sends SYN with sequence number 0.

Second request: server sends SYN and ACK, sequence 0, ack 1.

Third request: client sends ACK with sequence 1, ack 1.

Four-way Teardown

Using the diagram below, we analyze the TCP four-way termination.

First step

Client sends FIN(M) packet, entering FIN‑WAIT‑1 state, indicating no more data to send.

Second step

Server receives FIN(M) and replies with ACK(M+1), entering CLOSE‑WAIT; client moves to FIN‑WAIT‑2.

Third step

Server sends FIN(N) to client, requesting connection close, entering LAST‑ACK.

Fourth step

Client receives FIN(N), enters TIME‑WAIT, sends ACK(N+1); server receives it and enters CLOSE, and the client eventually also enters CLOSE after the timeout.