After unplugging the network cable, does the original TCP connection still exist?

Hello everyone, I am Xiaolin.

Today, let’s talk about an interesting question: If you unplug the network cable for a few seconds and then plug it back in, will the original TCP connection still exist?

Some students may say that if the network cable is unplugged, it means that the physical layer is disconnected, and the upper transport layer should also be disconnected, so the original TCP connection will no longer exist. It is just like when we make a wired phone call, if one party's phone line is unplugged, then the call is completely disconnected.

Is this really the case?

The logic above is flawed. The problem is that people mistakenly believe that unplugging the network cable will affect the transport layer, but in fact it will not.

In fact, the TCP connection in the Linux kernel is a structure called struct socket, which contains information such as the status of the TCP connection. When the network cable is unplugged, the operating system will not change any content of the structure, so the status of the TCP connection will not change.

I did a small experiment on my computer. I connected to my cloud server using an ssh terminal. Then I disconnected the wifi to simulate the scenario of unplugging the network cable. At this time, the status of the TCP connection did not change and was still in the ESTABLISHED state.

From the above experimental results, we know that unplugging the network cable will not affect the status of the TCP connection.

Next, we need to see what actions both parties take after unplugging the network cable.

Therefore, for this problem, we need to discuss it in different scenarios:

• After unplugging the network cable, there is data transmission;
• After unplugging the network cable, there is no data transmission;

After unplugging the network cable, there is data transmission

After the client unplugs the network cable, the data packets sent by the server to the client will not receive any response. After waiting for a certain period of time, the server will trigger the timeout retransmission mechanism and retransmit the data packets that have not received a response.

If the client happens to plug the network cable back in while the server is retransmitting the message, since unplugging the network cable does not change the client's TCP connection status and it is still in the ESTABLISHED state, the client can normally receive the data message sent by the server, and then the client will send an ACK response message.

At this point, the TCP connection between the client and the server still exists, and it feels like nothing has happened.

However, if the client does not plug the network cable back in while the server is retransmitting the message, and the number of times the server retransmits the message reaches a certain threshold, the kernel will determine that there is a problem with TCP, and then tell the application through the Socket interface that there is a problem with the TCP connection, so the server's TCP connection will be disconnected.

After the client plugs the network cable back in, if the client sends data to the server, since the server no longer has a TCP connection with the same quadruple as the client, the server kernel will reply with a RST message, and the client will release the TCP connection after receiving it.

At this point, the TCP connections between the client and the server have been disconnected.

How many times does TCP retransmit datagrams?

In Linux system, there is a configuration item called tcp_retries2, the default value is 15, as shown below:

This kernel parameter controls the maximum number of timeout retransmissions when a TCP connection is established.

However, setting tcp_retries2 to 15 times does not mean that TCP will not notify the application to terminate the TCP connection until it has timed out and retransmitted 15 times. The kernel will also make a judgment based on the "maximum timeout".

The timeout period of each round increases exponentially. For example, the first timeout retransmission is triggered after 2 seconds, the second after 4 seconds, the third after 8 seconds, and so on.

The kernel will calculate a maximum timeout based on the value set by tcp_retries2.

When a message is retransmitted and no response is received from the other party, the retransmission will stop after reaching one of the two conditions, "maximum number of retransmissions" or "maximum timeout", and then the TCP connection will be disconnected.

After unplugging the network cable, there is no data transmission

For the scenario where there is no data transmission after the network cable is unplugged, it is also necessary to check whether the TCP keepalive mechanism is enabled.

If the TCP keepalive mechanism is not enabled, after the client unplugs the network cable and neither party is transmitting data, the TCP connection between the client and the server will remain in place.

If the TCP keepalive mechanism is enabled, after the client unplugs the network cable, even if neither party is transmitting data, TCP will send a detection message after a period of time:

• If the peer is working normally, when the TCP keep-alive detection message is sent to the peer, the peer will respond normally, so the TCP keep-alive time will be reset and wait for the next TCP keep-alive time to arrive.
• If the peer host crashes, or the peer is unreachable due to other reasons, when the TCP keepalive detection message is sent to the peer, but there is no response, after several consecutive keepalive detection times, TCP will report that the TCP connection has died.

Therefore, the TCP keep-alive mechanism can determine whether the other party's TCP connection is alive through detection messages when there is no data exchange between the two parties.

What exactly does the TCP keepalive mechanism do?

The principle of this mechanism is as follows:

Define a time period. During this period, if there is no connection-related activity, the TCP keep-alive mechanism will start to work. At every time interval, a probe message will be sent. The probe message contains very little data. If several consecutive probe messages are not responded to, the current TCP connection is considered to be dead, and the system kernel will notify the upper-level application of the error information.

In the Linux kernel, there are corresponding parameters to set the keep-alive time, the number of keep-alive detections, and the time interval of keep-alive detections. The following are the default values:

 net .ipv4 .tcp_keepalive_time = 7200
 net .ipv4 .tcp_keepalive_intvl = 75
 net .ipv4 .tcp_keepalive_probes = 9

• tcp_keepalive_time=7200: indicates that the keepalive time is 7200 seconds (2 hours), that is, if there is no connection-related activity within 2 hours, the keepalive mechanism will be activated
• tcp_keepalive_intvl=75: means each detection interval is 75 seconds;
• tcp_keepalive_probes=9: means that if there is no response after 9 detections, the other party is considered unreachable and the connection is terminated.

That is to say, in Linux system, it takes at least 2 hours, 11 minutes and 15 seconds to find a "dead" connection.

picture

Note that if an application wants to use the TCP keepalive mechanism, it needs to set the SO_KEEPALIVE option through the socket interface for it to take effect. If it is not set, the TCP keepalive mechanism cannot be used.

Is the TCP keepalive mechanism detection time too long?

Yes, it is a bit long.

TCP keepalive is implemented at the TCP layer (kernel mode). It is a fallback solution for all programs based on the TCP transport protocol.

In fact, our application layer can implement a detection mechanism by itself, which can detect whether the other party is alive in a relatively short time.

For example, web service software generally provides a keepalive_timeout parameter to specify the timeout of HTTP persistent connections. If the timeout of HTTP persistent connections is set to 60 seconds, the web service software will start a timer. If the client does not initiate a new request within 60 seconds after completing the last HTTP request, the callback function will be triggered to release the connection when the timer expires.

Summarize

When the client unplugs the network cable, it does not directly affect the TCP connection status. Therefore, whether the TCP connection still exists after unplugging the network cable depends on whether data is transmitted after unplugging the network cable.

In case of data transmission:

• After the client unplugs the network cable, if the server sends a datagram, and the client plugs the network cable back in before the server retransmission count reaches the maximum value, the original TCP connection between the two parties can still exist normally, as if nothing happened.
• After the client unplugs the network cable, if the server sends a datagram, before the client plugs the network cable back in, the server will disconnect the TCP connection when the number of retransmissions reaches the maximum. After the client plugs the network cable back in, it sends data to the server. Because the server has disconnected the TCP connection with the same quadruple as the client, it will return a RST message, and the client will disconnect the TCP connection after receiving it. At this point, the TCP connection between both parties is disconnected.

No data transfer:

• If neither side has the TCP keepalive mechanism enabled, then after the client unplugs the network cable, if the client does not plug it back in, the TCP connection status between the client and the server will remain.
• If both parties have enabled the TCP keepalive mechanism, then after the client unplugs the network cable, if the client does not plug it back in, the TCP keepalive mechanism will detect that the other party's TCP connection is not alive, and will disconnect the TCP connection. If the client plugs the network cable back in during the TCP detection period, the original TCP connection between the two parties can still exist normally.

In addition to the scenario where the client unplugs the network cable, there are two other scenarios where the client "crashes and kills the process".

In the first scenario, the client crash is just like unplugging the network cable, which is not perceived by the server. Therefore, if there is no data transmission and the TCP keepalive mechanism is not enabled, the server's TCP connection will remain in the ESTABLISHED connection state until the server restarts the process.

Therefore, we can know one point. When the TCP keep-alive mechanism is not used and both parties do not transmit data, when one party's TCP connection is in the ESTABLISHED state, it does not mean that the other party's TCP connection is still normal.

In the second scenario, after the client process is killed, the client kernel will send a FIN message to the server and wave to the client four times.

Therefore, even if TCP keepalive is not enabled and there is no data exchange between the two parties, if the process of one party crashes, the operating system can sense this process and will send a FIN message to the other party, and then perform TCP handshakes four times with the other party.

over!