Hello, I’m Brother Tongo.

Today, we talk about an interesting question: unplug the network cable for a few seconds, then plug back in, the original TCP connection still exist?

Maybe some students will say that the network cable is unplugged, that means the physical layer is disconnected, that in the upper transport layer should also be disconnected, so the original TCP connection will not exist. It’s like when we make a landline call, if one of us gets disconnected, the call is dead.

Is it really so?

This logic is flawed. The problem is that the act of unplugging the cable is wrongly thought to affect the transport layer, which it does not.

In fact, a TCP connection in the Linux kernel is a structure called a struct socket, which contains information such as the state of the TCP connection. When the network cable is removed, the operating system does not change anything about the structure, so the state of the TCP connection does not change.

I did a small experiment on my computer. I connected my cloud server with SSH terminal, and then I simulated the scenario of unplugging the network cable by disconnecting the wifi. At this time, I checked the TCP connection status remained unchanged and was still in ESTABLISHED state.

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

Next, want to see after unplugging the network cable, both sides did what action.

Therefore, for this problem, there are different scenarios to discuss:

  • After removing the network cable, data is transmitted.
  • After the network cable is removed, no data is transmitted.

After the network cable is removed, data is transmitted

After the client removes the network cable, the server does not receive any response to the data packets it sends to the client. After waiting for a certain period of time, the server triggers the timeout retransmission mechanism to retransmit the data packets that do not receive any response.

If the client plugs the network cable back in during packet retransmission on the server, the TCP connection status of the client does not change after the network cable is removed, and the CLIENT is still in the ESTABLISHED state. Therefore, the client can normally receive data packets from the server, and then the client sends an ACK 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 back the network cable during the retransmission of packets on the server and the number of retransmission times on the server times out reaches a certain threshold, the kernel determines that the TCP connection is faulty and tells the application program through the Socket interface that the TCP connection is faulty. The TCP connection on the server is then disconnected.

After the client reinserts the network cable, if the client sends data to the server, the server kernel replies with an RST message. After receiving the RST message, the client releases the TCP connection.

At this point, the TCP connection between the client and server is disconnected.

How many times does TCP retransmit data packets?

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

This kernel parameter controls the maximum number of timeout retransmissions in the case of a TCP connection being established.

However, tcp_retries2 being set 15 times does not mean that TCP timeout retransmits 15 times before the application is notified to terminate the TCP connection, the kernel also determines based on the “maximum timeout time”.

Each round of timeout increases in multiples, such as 2s after the first timeout retransmission, 4s after the second timeout retransmission, 8s after the third round, and so on.

The kernel calculates a maximum timeout based on the value set to TCP_retries2.

When packets are retransmitted and no response is received, the TCP connection is disconnected after either of the two conditions (Maximum retransmission times or Maximum Timeout period) is reached.

After the network cable is removed, no data is transmitted

If no data is transmitted after the network cable is removed, you need to check whether the TCP Keepalive mechanism is enabled.

If the TCP Keepalive mechanism is not enabled, the TCP connection between the client and the server persists after the client removes the network cable and no data is transmitted.

If the TCP Keepalive mechanism is enabled, TCP sends probe packets after the client removes the network cable, even if no data is transmitted between the client and the client.

  • If the peer end is working properly. When a TCP keepalive probe packet is sent to the peer end, the peer end responds normally. In this case, the TCP keepalive time is reset and the TCP keepalive time is waiting for the next TCP keepalive time.
  • If the peer host crashes or packets are unreachable due to other reasons. After the TCP keepalive probe packet is sent to the peer end, no response is received. When the keepalive probe number reaches several times, TCP reports that the TCP connection is dead.

Therefore, the TCP keepalive mechanism detects packets to check whether the TCP connection of the peer party is alive without data interaction.

What is the TCP Keepalive mechanism?

The mechanism works like this:

Define a time period, in this time period, if there is no link related activities, mechanism of TCP keep alive will start, every once in a time interval, sending a probe packets, the detecting data packet contains very little, if several continuous detecting messages are not getting response, argues that the current TCP connection is dead, The system kernel notifies the upper-layer application of the error message.

The Linux kernel has corresponding parameters to set the keepalive time, number of keepalive probes, and interval of keepalive probes. The default values are as follows:

net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_keepalive_intvl=75  
net.ipv4.tcp_keepalive_probes=9
Copy the code
  • Tcp_keepalive_time =7200: indicates that the keepalive time is 7200 seconds (2 hours). If there is no activity related to the connection within 2 hours, the keepalive mechanism is enabled
  • Tcp_keepalive_intvl =75: indicates that each detection interval is 75 seconds.
  • Tcp_keepalive_probes =9: indicates that no response is detected for nine times and the peer party is considered unreachable and the current connection is interrupted.

This means that on Linux, it takes at least 2 hours, 11 minutes and 15 seconds to discover a “dead” connection.

Note that applications that want to use TCP keepalive need to set the SO_KEEPALIVE option through the socket interface to take effect. If this option is not set, TCP keepalive cannot be used.

TCP Keepalive takes too long to detect.

Yeah, it’s a little long.

TCP Keepalive is implemented in the TCP layer (kernel mode). It is a back-pocket solution for all TCP based programs.

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

For example, Web services software typically provides the keepalive_timeout parameter to specify the timeout period for HTTP long connections. If the timeout period for HTTP long connections is set to 60 seconds, the Web service software starts a timer. If the client does not initiate a new HTTP request within 60 seconds, the timer expires and a callback function is triggered to release the connection.

conclusion

After the client removes the network cable, the TCP connection status is not affected. Therefore, after removing the network cable, whether the TCP connection will still exist depends on whether there is data transmission after removing the network cable.

There is data transmission:

  • After the client unplugs the network cable, if the server sends data packets, the client reinserts the network cable before the retransmission times on the server reach the maximum, and the original TCP connection between the two sides still exists as if nothing happened.
  • After the client removes the network cable, if the server sends data packets and the number of retransmission times reaches the maximum before the client reinserts the network cable, the server disconnects the TCP connection. After the client reinserts the network cable, the client sends data to the server. Because the server disconnects the TCP connection with the same quad as the client, the client sends an RST packet. After receiving the RST packet, the client disconnects the TCP connection. At this point, both TCP connections are disconnected.

No data transfer:

  • If the TCP Keepalive mechanism is not enabled on both ends, the TCP connection between the client and the server persists after the client removes the network cable.
  • If the TCP Keepalive mechanism is enabled on both ends, the TCP Keepalive mechanism detects that the TCP connection is not alive and disconnects the TCP connection if the client does not reinsert the network cable after the client removes it. If the client inserts the network cable during THE TCP probe, the original TCP connection can still exist.

In addition to the scenario in which the client removes the network cable, there are two scenarios in which the client breaks down and kills the process.

In the first scenario, the client downtime cannot be sensed by the server, just like removing a network cable. Therefore, if there is no data transmission and TCP Keepalive is not enabled, the TCP connection on the server will remain in the ESTABLISHED state until the server restarts.

So, we have a point. If the TCP keepalive mechanism is not used and no data is transmitted, the TCP connection between one party and the other party is in the ESTABLISHED state, but the TCP connection between the other party is still normal.

In the second scenario, after the client process is killed, the client kernel sends a FIN packet to the server and waves the client four times.

Therefore, even if TCP Keepalive is not enabled and data is not exchanged between the peer and the peer, if the peer process breaks down, the operating system can detect the process and sends a FIN packet to the peer and waves the peer TCP four times.

Finished!

—- I’m the splitter —-

I in zhihu output * * 20 article graphic network series, up to 15 w words, words and hand draw the figure of a total of 500 copies, * * gain the recognition and support of many readers, running many readers appreciate me, said my graphic network help to them in the interview, many people got the ali, tencent, bytes, etc companies Offer.

To help you read, I have compiled the graphic network into a PDF, which you can download as an open source guide to face base assault:

300 page illustrated web PDF download!