Why Does One HTTP Request Trigger Multiple TCP Handshakes? Wireshark Deep Dive

Overview

The article uses Wireshark to capture a simple HTTP request to a demo service and analyses the underlying TCP/IP packets, which is a common interview topic.

Environment Preparation

A minimal demo HTTP server is deployed on a server (IP 45.76.105.92) with client IP 192.168.2.135. Wireshark is used as the packet capture tool.

Packet Capture Analysis

A) Three‑Way Handshake

The first three packets correspond to the TCP SYN, SYN‑ACK and ACK steps. The SYN packet contains fields such as source and destination ports, sequence number, window size, MSS and WS (window scaling) option.

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

Explanation of each field: 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=1: selective acknowledgment enabled

The TCP header diagram is shown below.

B) Four‑Way Termination

Normally a TCP connection is closed with four packets (FIN, ACK, FIN, ACK). In the captured trace the server merges the ACK and FIN of the second side, resulting in only three packets.

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

This demonstrates that the FIN and ACK can be combined, turning a four‑step termination into a three‑step one.

C) Keep‑Alive

HTTP/1.1 uses persistent connections by default. The client periodically sends a one‑byte Keep‑Alive packet; the server replies with an ACK, keeping the connection alive and allowing quick detection of dead peers.

Conclusion

HTTP requests rely on TCP, which performs a three‑way handshake and a four‑way termination (which may be merged). Window scaling and SACK improve performance, while Keep‑Alive maintains persistent connections and detects failures.