1. Introduction

A TCP connection between two sockets tends to remain going for a while even if one of the sockets dies or the communication channel goes down. In most cases, the connection keeps for so long that it seems there’s no timeout.

In this tutorial, we’ll study why this happens and how we can control this behavior.

2. Why Does This Happen?

TCP is designed to provide reliable transmission of data. To that end, it creates a connection between the two communicating parties.

Thus, it must ensure that it sends all data even if there is a momentary failure in the communication channel or one of the parties. To perform this, TCP has a mechanism for acknowledging receipt of data and retransmitting data whenever needed.

Moreover, even in case of failures, TCP needs to keep the connection alive until it’s sure that one of the parties to the communication has died (or is inaccessible). This is a classic case that TCP can keep the connection active for a long time.

3. How Can We Control the Connection Timeout?

In practice, the TCP connection timeout for these cases isn’t controlled by just one parameter but by multiple ones. Therefore, we’ve two types of parameters: global operating system and socket. Let’s see the parameters involved and how they work.

The system-wide TCP parameters may vary for each operating system. In Linux, we can access them by files in the directory /proc/sys/net/ipv4/. Hence, these parameters are /proc interfaces. The table below describes the /proc interfaces that are related to the TCP connection timeout:

Rendered by QuickLaTeX.com

The combination of these parameters defines the actual connection timeout. So by default, if the connection is idle, it will take about 2 hours and 11 minutes to close. In other words, this will be the time after the socket waits 7200 seconds before it starts sending probes, and then sends 9 probes every 75 seconds.

The activation of this keep-alive behavior will only occur if the TCP socket has the SO_KEEPALIVE option enabled. The table below describes this and other socket options.

Rendered by QuickLaTeX.com

Note that if we set TCP_KEEPIDLE, TCP_KEEPINTVL, and TCP_KEEPCNT, their values will overwrite the values of tcp_keepalive_time, tcp_keepalive_intvl, and tcp_keepalive_probes, respectively.

Also, if the connection is busy, the socket will continue trying to send data until it reaches the limit set in TCP_USER_TIMEOUT. But if TCP_USER_TIMEOUT isn’t enabled, the socket will drop the connection when it has made all the attempts defined in tcp_retries2.

We can change this behavior by setting different values for the mentioned parameters.

The same information on Windows Systems can be found in the Tcpip\Parameters and Socket Options documentation.

4. Conclusion

In this article, we studied why TCP sometimes keeps the connection for so long that there seems to be no timeout. We learned that this behavior can be changed through multiple operating systems and socket parameters.

Comments are open for 30 days after publishing a post. For any issues past this date, use the Contact form on the site.