Practical TCP Connection Reuse: Analyzing HTTP Keep-Alive Through Packet Capture

In modern web architecture, keep-alive connections have become a key technology for improving performance and reducing latency. This article uses real Wireshark packet capture data to fully restore a complete local loopback communication process, focusing on the analysis of the TCP connection reuse mechanism, helping developers truly understand the implementation and value of “keep-alive connections” in HTTP/1.1.

🌐 Background: A Typical Scenario of Local Loopback Communication

This packet capture records a complete TCP session occurring within the 192.168.1.100 local machine:

• • Client Port: 56464
• • Server Port: 42100

Although the communication occurs on the local machine, its protocol behavior is identical to that of remote communication—making it an ideal sample for observing and learning the TCP/HTTP interaction mechanism.

🔄 Breakdown of the Entire Communication Lifecycle

The entire session consists of six key stages, clearly demonstrating the establishment, reuse, and closure of the TCP connection:

1. 1. TCP three-way handshake to establish connection
2. 2. Client sends login request (POST)
3. 3. Server returns login response (HTTP 200, chunked transfer)
4. 4. Client initiates business request (GET)
5. 5. Server returns business data (HTTP 200, large data chunked)
6. 6. Server actively closes the connection (FIN)

🤝 Establishing TCP Connection: Standard Three-Way Handshake Process

Packet 4196: Client → Server [SYN]

• • Flags: SYN
• • Initial Sequence Number: Seq=0
• • Window Size: Win=65535
• • Negotiated Parameters: MSS=65495, WS=256, SACK_PERM

Packet 4197: Server → Client [SYN, ACK]

• • Acknowledges Client SYN: Ack=1
• • Server’s Initial Sequence Number: Seq=0

Packet 4198: Client → Server [ACK]

• • Acknowledges Server SYN: Ack=1
• • Client’s Sequence Number advances to: Seq=1

✅ At this point, the TCP connection is officially established, and application layer data transmission can begin.

🔐 Login Phase: HTTP POST Request and Chunked Response

Packet 4199: Client Sends Login Request

• • Method:<span>POST /api/v1/auth/login</span>
• • Content Type:<span>application/json</span>
• • Data Length: 306 bytes (including TCP header)
• • TCP Sequence Number advances: 1 → 263

Packet 4200: Server Acknowledges Receipt

• • Ack=263, indicating complete receipt of POST data

Packets 4263 + 4264: Server Chunked Response

• • Total Data Volume Approximately 697 bytes (minus TCP header)
• • Uses<span>[PSH, ACK]</span> flag to prompt the receiver to process immediately
• • Wireshark marks as “reassembled PDU”, requiring reassembly to parse the complete HTTP response

Packet 4266: Client Acknowledges Complete Receipt

• • Ack=698, confirming that the server has finished sending data

Key Point: At this point, the connection is not closed—providing a basis for connection reuse for subsequent requests.

📈 Business Phase: Core Reflection of Keep-Alive Connections

Packet 8772: Client Sends GET Request (10 seconds later)

• • Path:<span>GET /api/v1/event/1281</span>
• • Data Length: 596 bytes
• • TCP Sequence Number continues from 263 to 815

📌 This is direct evidence of a “keep-alive connection”: The client did not re-establish the TCP connection but instead reused the existing connection to send a new request. This is a typical manifestation of the Keep-Alive mechanism enabled by default in HTTP/1.1.

Packet 8773: Server Acknowledges Receipt of GET Request

Packets 9025 + 9026: Server Chunked Response of Large Data

• • Total Data Volume Approximately 1171 bytes
• • Sequence Number advances from 698 to 1825
• • Client confirms receipt completion in Packet 9028 (Ack=1825)

🚪 Connection Closure: Server Actively Initiates FIN

Packet 25086: Server Sends [FIN, ACK] (about 60 seconds later)

• • Indicates that the server has decided to close the connection
• • Possible Trigger Condition: Idle Timeout

Packet 25087: Client Acknowledges FIN

• • Ack=1826 (FIN occupies one sequence number)
• • Connection enters half-closed state

TCP + HTTP Session Timing Diagram

🔍 Technical Analysis: What is a “Keep-Alive Connection”?

In this communication, “keep-alive connections” are reflected in:

• • One TCP handshake, multiple HTTP request reuse The login request and business data request reused the same TCP connection, avoiding the overhead of repeated handshakes.
• • Reduced Latency, Increased Throughput Eliminating three-way handshakes (approximately 1.5 RTT) and slow start processes, especially enhances performance in short, high-frequency request scenarios (such as API calls, microservice communications).
• • Resource Optimization Reduces consumption of system resources such as port usage, connection table entries, and memory buffers.
• • Complies with HTTP/1.1 Default Behavior Unless explicitly specified with <span>Connection: close</span>, the connection remains open by default.

📊 Performance Comparison Illustration:

Scenario	TCP Handshake Count	Total RTT (Assumed)
Short Connection (new connection for each request)	2 times	3 RTT
Long Connection (reuse)	1 time	1 RTT

🌐 Analogous Understanding:

Imagine you are calling customer service:

• • The first time: you say, “I want to log in” → Customer service verifies → Replies “Login successful” ✅ (Packets 4199-4266)
• • Then youdon’t hang up, and 10 seconds later continue with, “Help me check event 1281” 📞 (Packet 8772)
• • Customer service continues to respond to you → Finally hangs up (Packet 25086)

When asking the second question, you do not need to make a second call (i.e., no need for a three-way handshake) because the first call has not ended!

Comparison of Connection Reuse in HTTP/2 and HTTP/3

Feature	HTTP/1.1	HTTP/2, HTTP/3
Connection Reuse	✅ Single connection serial reuse	✅ Single connection +Multiplexing (parallel)
Need for Multiple TCP	✅ Typically opens 6-8 connections	❌ Only requires 1 connection
Head-of-Line Blocking	✅ Yes (serial)	❌ No (streams independent)
Performance	Average	Higher (especially for many small files)

✅ Conclusion

This packet capture fully presents:

• • The entire lifecycle of a TCP connection from establishment to closure
• • The actual operating mechanism of “keep-alive connections” under HTTP/1.1
• • The underlying details of chunked data transmission and reassembly
• • The impact of server idle timeout strategies on connection management

For us, understanding keep-alive connections not only aids in performance tuning but is also essential knowledge for building high-availability, low-latency systems. In today’s world of increasingly popular cloud-native and microservice architectures, mastering connection reuse mechanisms means mastering the key to system efficiency.