Why Static Servers Still Generate TIME_WAIT: Understanding HTTP Keep-Alive

Origin

During a group discussion we used ab to test a server that only serves static files and does not interact with any other system, yet we observed a large number of TIME WAIT states.

In TCP, the side that sends the first FIN packet enters TIME WAIT, while the side that sends the final FIN enters CLOSE WAIT. In this scenario the server is the active closer, which leads us to the HTTP keep‑alive mechanism.

Analysis

For HTTP keep‑alive to work, the server must support it and the client must send the appropriate Connection header.

Example request with Connection: close:

GET /? HTTP/1.1
Accept: */*
Cache-Control: no-cache
Connection: close
Host: 127.0.0.1
User-Agent: Apache-HttpClient/4.3.2 (java 1.5)
Accept-Encoding: gzip,deflate

Packet capture shows that after the server finishes responding it immediately sends a FIN packet, actively closing the connection.

Example request with Connection: keep-alive and Keep-Alive: 5:

GET /? HTTP/1.1
Accept: */*
Cache-Control: no-cache
Connection: keep-alive
Keep-Alive: 5
Host: 127.0.0.1
User-Agent: Apache-HttpClient/4.3.2 (java 1.5)
Accept-Encoding: gzip,deflate

In this case the server does not send a FIN immediately. After about 5 seconds—the value of the Keep-Alive header—the client sends a FIN packet, closing the connection. The Keep-Alive header therefore specifies how many seconds the client should keep the connection alive.

We performed tests with the server’s keepalive timeout set to 65 seconds, then to 0, and observed the behavior under different client header configurations.

When the client sends Connection: close, the server always closes the connection immediately after responding.

When the client sends Connection: keep-alive with Keep-Alive: 5, the server keeps the connection open for roughly 5 seconds before sending its own FIN.

When the server’s keepalive timeout is set to 3 seconds and the client requests keep-alive with Keep-Alive: 5, the server closes the connection after about 3 seconds, demonstrating that the shorter of the two timers wins.

Conclusion

Key takeaways about HTTP keep‑alive:

The Connection header controls whether the client enables keep‑alive ( keep-alive) or disables it ( close).

The Keep-Alive header tells the client how many seconds to keep the connection open.

When keep‑alive is enabled, whichever side reaches the keep‑alive timeout first sends a FIN packet to actively close the connection.