Why Does an HTTP Request Involve Multiple TCP Handshakes? A Wireshark Deep Dive

Overview

The article analyzes a typical HTTP request using Wireshark, showing how the request relies on ICMP, ARP, and especially TCP, and explains the details captured in the packet trace.

Environment Preparation

A simple demo service that returns a string for HTTP requests is deployed on a server. The environment includes:

Response service demo

Client IP: 192.168.2.135

Server IP: 45.76.105.92

Capture tool: Wireshark

After deploying the demo, the service is accessed and captured with Wireshark.

Packet Capture Analysis

The capture shows one HTTP request/response pair, but many TCP packets are also present. The analysis focuses on these TCP packets.

A) Three‑Way Handshake

The first packet is a SYN from client port 60738 to server port 8081:

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

Key fields: 60738->8081: source port → destination port [SYN]: synchronization flag Seq: sequence number Win: TCP window size Len: payload length Mss: maximum segment size Ws: window scaling factor SACK_PERM: selective acknowledgment enabled

The TCP header diagram is shown to illustrate these fields.

Explanation of selected fields:

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

Len : length of the TCP segment, which in this case carries the HTTP payload.

Mss : negotiated maximum segment size, typically 1460 bytes.

Ws : window scaling factor; here Ws=256 expands the window to 260*256=66560 bytes.

SACK_PERM : enables selective acknowledgment to avoid unnecessary retransmissions.

After the handshake, the HTTP GET request is sent: GET /test HTTP/1.1 The server replies with HTTP/1.1 200 (text/html) and the client acknowledges.

B) Four‑Way Termination

Normally a TCP connection closes with four packets, but the capture shows only three because the server merged the ACK and FIN flags:

1) 60738 -> 8081 [FIN ACK] Seq=396 Ack=120 Win=66560 Len=0

This merged packet reduces the four‑step termination to three steps.

C) Keep‑Alive

HTTP persistent connections use the Keep‑Alive mechanism. In HTTP/1.1 it is the default, allowing the client to send periodic one‑byte packets to keep the connection alive:

The client sends Keep‑Alive packets, and the server acknowledges them, preventing firewalls or OS from dropping idle connections.

Summary

HTTP requests rely on TCP connections, which start with a three‑way handshake.

TCP window scaling and SACK improve throughput and reduce retransmissions.

Connection termination normally uses a four‑step handshake, but ACK and FIN can be merged into three steps.

HTTP Keep‑Alive sends periodic heartbeats to keep the connection alive and detect dead nodes quickly.