Decoding HTTP Requests with Wireshark: Handshake, TCP Options, and Keep‑Alive Explained

In this article we use a packet‑capture tool (Wireshark) to examine how an HTTP request is transmitted over a TCP connection.

Environment preparation

A simple demo service is deployed on a server (IP 45.76.105.92) and accessed from a client (IP 192.168.2.135) using Wireshark to capture the traffic.

After starting the demo, the captured packets show one HTTP request and many TCP packets.

Three‑way handshake (A)

The first packet is a SYN from the client to the server:

192.168.2.135:60738 --> 45.76.105.92:8081 [SYN] Seq=0 Win=64240 Len=0 Mss=1460 Ws=256 SACK_PERM=1

This is the TCP three‑way handshake. The SYN flag initiates the connection, and the fields are:

Port numbers : source --> destination.

SYN : synchronization flag.

Seq : sequence number.

Win : advertised window size.

Len : payload length (0 for SYN).

Mss : maximum segment size.

Ws : window scaling factor.

SACK_PERM : selective acknowledgment permitted.

The TCP header structure is illustrated below:

Key field explanations

Win : the maximum number of bytes the receiver can accept; default maximum is 64 KB (2^16).

Len : length of the data segment; for the HTTP request it represents the size of the HTTP payload.

Mss : negotiated maximum segment size, typically 1460 bytes.

Ws : window scaling factor; the effective window is Win * Ws. In the capture the client advertises Win=260 and Ws=256, giving an effective window of 66560 bytes.

SACK_PERM : enables selective acknowledgments to avoid unnecessary retransmissions.

HTTP request flow

The captured sequence of packets (simplified) is:

1) 60738 -> 8081 [SYN] ...
2) 8081 -> 60738 [SYN,ACK] ...
3) 60738 -> 8081 [ACK] ...
4) 60738 -> 8081 GET /test HTTP/1.1
5) 8081 -> 60738 [ACK] ...
6) 8081 -> 60738 HTTP/1.1 200 (text/html)
7) 60738 -> 8081 [ACK] ...

Steps 1‑3 constitute the TCP three‑way handshake, step 4 is the HTTP GET request, step 6 is the HTTP response, and steps 5 and 7 acknowledge the request and response.

Four‑step termination (B)

Normally a TCP connection closes with four packets (FIN, ACK, FIN, ACK). In this capture the server merges the ACK and FIN, resulting in only three packets:

8) 60738 -> 8081 [FIN ACK] ...
9) 8081 -> 60738 [FIN ACK] ...

The merged packet combines the acknowledgment of the previous data with the FIN flag, effectively reducing the termination to three steps.

Keep‑Alive (C)

HTTP/1.0 introduced optional persistent connections via the Keep-Alive header, while HTTP/1.1 makes persistent connections the default. Keep‑Alive sends periodic heartbeat packets to:

Detect dead peers quickly.

Prevent idle connections from being closed by firewalls or the OS.

The captured Keep‑Alive packets are shown below:

Each Keep‑Alive packet carries a single byte payload, and the server replies with an ACK.

Summary

HTTP relies on TCP; the initial connection uses the TCP three‑way handshake.

TCP options such as window scaling, MSS, and SACK improve performance and reliability.

Connection termination normally uses four packets, but ACK and FIN can be merged, yielding a three‑packet termination.

HTTP Keep‑Alive maintains persistent connections by sending periodic heartbeat packets, reducing latency for subsequent requests.