Understanding TCP Keepalive Mechanism and Its Parameters

1. Simple Introduction to TCP Connection

A TCP connection is uniquely identified by a four‑tuple of source IP, source port, destination IP, and destination port; establishing the connection requires a three‑way handshake, and termination requires a four‑step handshake initiated by either side.

Even if no data is exchanged for a long time, a created TCP connection remains alive as long as both hosts stay up and IP addresses do not change, potentially persisting for hours, days, weeks, or longer.

2. Keepalive Mechanism

2.1 TCP Keepalive

The TCP keepalive mechanism (called TCP keepalive ) was designed to solve two problems: (1) to let both client and server know the peer’s status and decide whether to close a stale connection that cannot perform a graceful four‑step termination, and (2) to maintain a minimal data flow so that middleboxes (routers, firewalls) do not drop idle connections from their tables.

Keepalive is disabled by default; each side can enable it by setting the socket option SO_KEEPALIVE .

2.2 Implementation Principle

When a TCP connection is established and keepalive is enabled on one end, a timer starts. After the timer reaches zero (i.e., after tcp_keepalive_time seconds, reset on each data transmission), a keepalive probe packet is sent. The probe contains no data (or a meaningless byte) and the peer must be in one of four TCP states; the sender then reacts based on the peer’s response.

2.3 Three Important Parameters

1. tcp_keepalive_time – interval between the last data packet and the first keepalive probe (default 7200 s on Linux).

2. tcp_keepalive_probes – number of unanswered probes before the connection is considered dead (default 9).

3. tcp_keepalive_intvl – interval between successive probes after the first one (default 75 s).

Thus, the total time before a dead connection is detected on Linux is tcp_keepalive_time + (tcp_keepalive_probes * tcp_keepalive_intvl) = 7875 s (about 2 h 11 min 15 s).

2.4 Verification

To observe keepalive probes, we enable keepalive on an SSH server and adjust the parameters for a short test. For example, setting echo 20 > /proc/sys/net/ipv4/tcp_keepalive_time and reloading with sysctl -p makes the first probe appear after 20 s, which can be captured with Wireshark.

Further, by setting echo 10 > /proc/sys/net/ipv4/tcp_keepalive_intvl and echo 2 > /proc/sys/net/ipv4/tcp_keepalive_probes , and using iptables to drop the probe responses, we can simulate a scenario where the server never receives acknowledgments. The server then retransmits probes every 10 s and, after two unanswered probes, sends an RST to close the connection.

After the test, we clear the firewall rules with sudo iptables -F .

3. Drawbacks of Keepalive

1. Aggressive keepalive settings may close healthy connections during brief network glitches.

2. Keepalive generates unnecessary traffic.

4. Why Application Layer Still Needs Heartbeat

TCP keepalive only tells whether the TCP link is alive; it cannot detect whether the remote application is responsive or blocked. Moreover, proxies (e.g., HAProxy) operating above the transport layer may filter keepalive traffic, so application‑level heartbeats are still required.

5. Relationship Between TCP Keepalive and HTTP Keep‑Alive

HTTP Keep‑Alive is an application‑layer feature. In HTTP/1.0 the default is a short‑lived connection; each request opens a new TCP connection. Starting with HTTP/1.1, persistent connections are the default, indicated by the header Connection: keep-Alive , allowing multiple requests to reuse the same TCP connection.

Summary of Differences

1. HTTP Keep‑Alive keeps the underlying TCP connection alive longer to improve efficiency when multiple HTTP requests are made.

2. TCP KeepAlive probes the peer’s existence to detect dead TCP connections.

3. Because TCP is a bidirectional transport, an HTTP connection that has keep‑alive enabled cannot be initiated by the server; the client must start the communication.