Great question—this is a super common gotcha when building long-lived TCP clients and servers, especially in Linux environments. Let’s break this down clearly, covering both the TCP protocol spec and practical implementation details:

First, let’s get back to basics: the TCP protocol itself does not define a built-in timeout for idle connections. From a pure protocol perspective, an ESTABLISHED TCP connection will stay alive indefinitely as long as neither end sends a FIN/RST packet, and no critical link failures (like ICMP unreachable messages) are detected. TCP is designed to maintain connections even through long periods of inactivity—there’s no "automatic disconnect" baked into the standard.

Here’s where theory meets reality: yes, idle connections can (and often will) get dropped, but not by TCP itself. The culprits are usually intermediate network devices:

• Routers, NAT gateways, and firewalls all maintain connection state tables to route traffic. These tables have limited resources, so most devices will automatically purge idle TCP connections after a certain window (often anywhere from 5 minutes to a few hours, depending on the device configuration).
• When this happens, the connection becomes a "half-open" state: both your client and server still think the connection is active, but any subsequent data send will fail (usually with a ECONNRESET or timeout error).

Additionally, some operating systems have default TCP keepalive settings enabled (though Linux disables it by default), which can trigger a disconnect if the idle period exceeds system thresholds.

Absolutely—Linux provides several socket options to customize how your TCP connections handle inactivity. Let’s cover the most useful ones:

1. TCP Keepalive (System-Level Connection Probing) #

TCP keepalive is a standardized way to periodically send small probe packets to verify if the connection is still alive. It’s disabled by default, so you need to enable it and configure its parameters via setsockopt:

First, enable keepalive:

int optval = 1;
// Enable SO_KEEPALIVE on the socket
if (setsockopt(sockfd, SOL_SOCKET, SO_KEEPALIVE, &optval, sizeof(optval)) == -1) {
    perror("setsockopt SO_KEEPALIVE");
    // Handle error
}

Then configure the keepalive timing parameters (Linux-specific):

int keepidle = 300;    // Start sending probes after 5 minutes of inactivity
int keepintvl = 60;    // Send a probe every 60 seconds if no response
int keepcnt = 5;       // Send 5 probes total before declaring the connection dead

setsockopt(sockfd, IPPROTO_TCP, TCP_KEEPIDLE, &keepidle, sizeof(keepidle));
setsockopt(sockfd, IPPROTO_TCP, TCP_KEEPINTVL, &keepintvl, sizeof(keepintvl));
setsockopt(sockfd, IPPROTO_TCP, TCP_KEEPCNT, &keepcnt, sizeof(keepcnt));

If the remote end doesn’t respond to any of the probes, the kernel will automatically close the socket and notify your application with an error.

2. SO_RCVTIMEO / SO_SNDTIMEO (Per-Operation Timeouts) #

These options control timeouts for individual recv() or send() system calls, not the connection itself. They’re useful if you want your application to detect inactivity and take action (like sending a heartbeat or closing the connection) instead of waiting indefinitely:

Example of setting a 10-second receive timeout:

struct timeval timeout;
timeout.tv_sec = 10;
timeout.tv_usec = 0;

if (setsockopt(sockfd, SOL_SOCKET, SO_RCVTIMEO, &timeout, sizeof(timeout)) == -1) {
    perror("setsockopt SO_RCVTIMEO");
    // Handle error
}

Now, if recv() waits 10 seconds without receiving any data, it will return -1 with errno set to EAGAIN or EWOULDBLOCK (for non-blocking sockets) or EINPROGRESS (for blocking sockets). Your application can then use this signal to send a heartbeat check or initiate a disconnect.

3. Application-Level Heartbeats #

For maximum flexibility, many developers implement custom application-level heartbeats. This involves sending small, periodic "ping" packets between client and server. If one end doesn’t receive a heartbeat within a configured window, it explicitly closes the connection.

This approach is often preferred over TCP keepalive because:

• You can include business context in the heartbeat (e.g., status updates)
• It’s not dependent on system-wide TCP settings
• It works consistently across different network environments

内容的提问来源于stack exchange，提问作者Abruzzo Forte e Gentile