Timeout tcp connections linux

TCP Socket no connection timeout

I open a TCP socket and connect it to another socket somewhere else on the network. I can then successfully send and receive data. I have a timer that sends something to the socket every second. I then rudely interrupt the connection by forcibly losing the connection (pulling out the Ethernet cable in this case). My socket is still reporting that it is successfully writing data out every second. This continues for approximately 1hour and 30 minutes, where a write error is eventually given. What specifies this time-out where a socket finally accepts the other end has disappeared? Is it the OS (Ubuntu 11.04), is it from the TCP/IP specification, or is it a socket configuration option?

3 Answers 3

Pulling the network cable will not break a TCP connection(1) though it will disrupt communications. You can plug the cable back in and once IP connectivity is established, all back-data will move. This is what makes TCP reliable, even on cellular networks.

When TCP sends data, it expects an ACK in reply. If none comes within some amount of time, it re-transmits the data and waits again. The time it waits between transmissions generally increases exponentially.

After some number of retransmissions or some amount of total time with no ACK, TCP will consider the connection «broken». How many times or how long depends on your OS and its configuration but it typically times-out on the order of many minutes.

 tcp_retries2 (integer; default: 15; since Linux 2.2) The maximum number of times a TCP packet is retransmitted in established state before giving up. The default value is 15, which corresponds to a duration of approximately between 13 to 30 minutes, depending on the retransmission timeout. The RFC 1122 specified minimum limit of 100 seconds is typically deemed too short. 

This is likely the value you’ll want to adjust to change how long it takes to detect if your connection has vanished.

(1) There are exceptions to this. The operating system, upon noticing a cable being removed, could notify upper layers that all connections should be considered «broken».

Источник

How to Check TCP Timeout in Linux

The Kubernetes ecosystem is huge and quite complex, so it’s easy to forget about costs when trying out all of the exciting tools.

To avoid overspending on your Kubernetes cluster, definitely have a look at the free K8s cost monitoring tool from the automation platform CAST AI. You can view your costs in real time, allocate them, calculate burn rates for projects, spot anomalies or spikes, and get insightful reports you can share with your team.

Connect your cluster and start monitoring your K8s costs right away:

1. Overview

TCP (Transmission Control Protocol) ensures the reliability and transfer of data between the sender and the receiver. However, in some cases, the connection between two devices can become broken, resulting in a “timeout” error. In Linux, TCP timeouts are used to set an estimated time the system should wait for a response from the receiver before the connection is broken. Timeouts, if not set, default to 60 seconds.

In this tutorial, we go over the steps to check for TCP timeouts in Linux. Before we begin, it’s important to note that the specific steps may vary depending on our Linux version and the distribution you have installed.

2. What Is a TCP Timeout?

A TCP timeout in Linux refers to the time a system waits for a response to be acknowledged before the connection is terminated.

The TCP keepalive timeout prevents broken connections from being left open indefinitely. The default timeout value can be adjusted in the Linux kernel configuration.

3. How to Check TCP Timeouts

We can check TCP timeouts using the network tools as highlighted earlier or using file definitions by changing the value in the keep_alive_time. Let’s look at these options and more in extra detail.

Firstly, check the set timeout value.

The fastest way to get the timeout value is to use the current system timeout stored in the /proc/sys/net/ipv4/tcp_keepalive_time file. To check the value, we can open a terminal window and run the following command:

$ cat /proc/sys/net/ipv4/tcp_keepalive_time

This returns the number of seconds the operating system will wait for data to be acknowledged before closing the connection.

Secondly, we need to check the keepalive setting.

This controls the number of keepalive probes sent before the connection is closed. To check the value, we can run the following command:

$ cat /proc/sys/net/ipv4/tcp_keepalive_probes

The above command returns the number of keepalive probes sent before the connection is closed.

The interval between keepalive probes is also an important setting to check. This setting controls the amount of time between each keepalive probe. To check the value, we should run the following:

$ cat /proc/sys/net/ipv4/tcp_keepalive_intvl

This returns the amount of time in seconds between each keepalive probe.

4. Modifying the TCP keepalive

The TCP timeout value can be adjusted in Linux by modifying the relevant kernel parameters. There are several methods for adjusting TCP timeouts, including using the sysctl command and editing the relevant configuration files:

sysctl -w net.ipv4.tcp_keepalive_time=value

We can replace the value with the desired timeout value in seconds. This change will only persist until the next reboot. To make the change permanent, we can add the following line to the /etc/sysctl.conf file:

net.ipv4.tcp_keepalive_time=value

Finally, we apply the changes by running the following command:

It ensures all the changes get saved in the system for future use when handling other TCP connections.

5. Conclusion

In this tutorial, we looked at different ways to check for TCP timeouts in Linux using various system files. Understanding the duration of active connections and verifying the default timeout value can help us identify and resolve timeout issues in our network.

Источник

Linux TCP Connection timeout

I observe the TCP timeout from server to client. When TCP Three-way Handshake finished, and then the client does not anything for a long time. How many times will timeout TCP sessions? I consult the RFC 793 document, 3.8 Interfaces:

The timeout, if present, permits the caller to set up a timeout for all data submitted to TCP. If data is not successfully delivered to the destination within the timeout period, the TCP will abort the connection.
The present global default is five minutes

The following is the captured packet connection, More than 10 minutes have passed and there is no TCP disconnection. Am I misunderstanding somewhere? OS: Ubuntu 20 The following is my test code. Client Code:

#include #include #include int main(int argc, char *argv[]) < int socket_desc; struct sockaddr_in server; socket_desc = socket(AF_INET, SOCK_STREAM, 0); if(socket_desc == -1)< printf("Socket failed\n"); >server.sin_addr.s_addr = inet_addr("192.168.88.88"); server.sin_family = AF_INET; server.sin_port = htons(8888); if(connect(socket_desc, (struct sockaddr *)&server, sizeof(server)) <0)< printf("Connect failed\n"); >else < printf("Connected\n"); while(0); // When connected, do not anything. return 0; >

#include #include #include int main(int argc, char *argv[]) < int socket_desc, new_socket, c; struct sockaddr_in server; socket_desc = socket(AF_INET, SOCK_STREAM, 0); if(socket_desc == -1)< printf("Socket failed\n"); >server.sin_addr.s_addr = INADDR_ANY; server.sin_family = AF_INET; server.sin_port = htons(8888); if(bind(socket_desc, (struct sockaddr *)&server, sizeof(server)) <0)< printf("bind failed\n"); >listen(socket_desc, 5); c = sizeof(struct sockaddr_in); new_socket = accept(socket_desc, (struct sockaddr *) &client, (socklen_t *) &c); if (new_socket < 0)< printf("Accept failed\n"); >else < printf("Accept\n"); while(1); // When accept , do not anything. >return 0; > 

Источник

Overriding the default Linux kernel 20-second TCP socket connect timeout

Whatever language or client library you’re using, you should be able to set the timeout on network socket operations, typically split into a connect timeout, read timeout, and write timeout.

However, although you should be able to make these timeouts as small as you want, the connect timeout in particular has an effective maximum value for any given kernel. Beyond this point, higher timeout values you might request will have no effect — connecting will still time out after a shorter time.

The reason TCP connects are special is that the establishment of a TCP connection has a special sequence of packets starting with a SYN packet. If no response is received to this initial SYN packet, the kernel needs to retry, which it may have to do a couple of times. All kernels I know of wait an increasing amount of time between sending SYN retries, to avoid flooding slow hosts.

All kernels put an upper limit on the number of times they will retry SYNs. On BSD-derived kernels, including Mac OS X, the standard pattern is that the second SYN will be second 6 seconds after the first, then a third SYN 18 seconds after that, then the connect times out after a total of around 75 seconds.

On Linux however, the default retry cycle ends after just 20 seconds. Linux does send SYN retries somewhat faster than BSD-derived kernels — Linux supposedly sends 5 SYNs in this 20 seconds, but this includes the original packet (the retries are after 3s, 6s, 12s, 24s).

The end result though is that if your application wants a connect timeout shorter than 20s, no problem, but if your application wants a connect timeout longer than 20s, you’ll find that the default kernel configuration will effectively chop it back to 20s.

Changing this upper timeout limit is easy, though it requires you to change a system configuration parameter and so you will need to have root access to the box (or get the system administrators to agree to change it for you).

The relevant sysctl is tcp_syn_retries , which for IP v4 is net.ipv4.tcp_syn_retries .

Be conservative in choosing the value you change it to. Like BSD, the SYN retry delays increase in time (albeit doubling rather than tripling), so a relatively small increase in the number of retries leads to a large increase in the maximum connect timeout. In a perfect world, there would be no problem with having a very high timeout because applications’ connect timeouts will come into play.

However, many applications do not set an explicit connect timeout, and so if you set the kernel to 10 minutes, you’re probably going to find something hanging for ages sooner or later when a remote host goes down!

I recommend that you set it to a value of 6, 7, or at most 8. 6 gives an effective connect timeout ceiling of around 45 seconds, 7 gives around 90 seconds, and 8 gives around 190 seconds.

To change this in a running kernel, you can use the /proc interface:

# cat /proc/sys/net/ipv4/tcp_syn_retries 5 # echo 6 > /proc/sys/net/ipv4/tcp_syn_retries

Or use the sysctl command:

# sysctl net.ipv4.tcp_syn_retries net.ipv4.tcp_syn_retries = 5 # sysctl -w net.ipv4.tcp_syn_retries=6 net.ipv4.tcp_syn_retries = 6

To make this value stick across reboots however you need to add it to /etc/sysctl.conf :

net.ipv4.tcp_syn_retries = 6

Most Linux installations support reading sysctls from files in /etc/sysctl.d , which is usually better practice as it makes it easier to administer upgrades, so I suggest you put it in a file there instead.

(I see no reason you’d want to reduce this sysctl, but note that values of 4 or less all seem to be treated as 4 — total timeout 9s.)

Источник