Does the original TCP connection still exist if the network cable is unplugged for a few seconds and then plugged back in?
Some students may say that if the network cable is unplugged, it means that the physical layer is disconnected, so the transport layer above should also be disconnected, so the original TCP connection will not exist. It's like when we make a wired phone call, if one party's phone line is unplugged, the call is completely disconnected.
In fact, this understanding is incorrect, and the logic above is flawed. The problem lies in the incorrect assumption that unplugging the network cable will affect the transport layer, which is not the case.
In reality, the TCP connection in the Linux kernel is a structure called struct socket, which contains information about the state of the TCP connection. When the network cable is unplugged, the operating system does not change any content of this structure, so the state of the TCP connection does not change.
You can simulate the scenario of unplugging the network cable by establishing a TCP connection with a remote server using SSH and then disconnecting the local network. You can then use the following command to view the status of the TCP connection:
# linux
# netstat: https://wangchujiang.com/linux-command/c/netstat.html
# or ss: https://wangchujiang.com/linux-command/c/ss.html
#
# grep: https://wangchujiang.com/linux-command/c/grep.html
sudo netstat -anp tcp | grep tcp | grep [dst_ip]
# windows
# netstat: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netstat
# or TCPView: https://learn.microsoft.com/en-us/sysinternals/downloads/tcpview
#
# findstr: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/findstr
netstat -anp tcp | findstr [dst_ip]
Now, we know that unplugging the network cable does not affect the state of the TCP connection. It mainly depends on what actions are taken by both parties after unplugging the network cable. To address this issue, we need to discuss different scenarios based on whether there is data transmission after unplugging the network cable.
Unplugging the network cable with data transmission#
When the network cable is unplugged on the client side, the server's data packets sent to the client will not receive any response. After a certain period of time, the server will trigger the mechanism of "timeout retransmission" to retransmit the data packets that did not receive a response.
If the client plugs the network cable back in during the server's retransmission process, the client can still receive the data packets sent by the server normally. Since unplugging the network cable does not change the client's TCP connection state and it remains in the ESTABLISHED state, the client will send an ACK response packet. 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 during the server's retransmission process and the server's retransmission of packets reaches a certain threshold after a certain number of attempts, the kernel will determine that the TCP connection is problematic. It will then inform the application program through the Socket interface that the TCP connection is in trouble, and the server's TCP connection will be disconnected. When the client plugs the network cable back in and sends data to the server, the server's kernel will reply with an RST packet because it no longer has a TCP connection with the same four-tuple as the client. The client will then release the TCP connection. At this point, both the client and the server's TCP connections have been disconnected.
Q: How many times will TCP data packets be retransmitted?
A: In the Linux system, there is a configuration item called tcp_retries2 (/proc/sys/net/ipv4/tcp_retries2), with a default value of 15. This kernel parameter controls the maximum number of retransmissions during TCP connection establishment.
However, setting tcp_retries2 to 15 does not mean that TCP will notify the application program to terminate the TCP connection only after 15 retransmissions. The kernel will calculate a timeout based on the value set by tcp_retries2 (if tcp_retries2 = 15, then the calculated timeout = 924600 ms). If the retransmission interval exceeds this timeout, it is considered to have exceeded the threshold, and the TCP connection will be terminated.
During the process of timeout retransmission, the timeout for each round (RTO) increases exponentially. For example, if the initial RTO is 200 milliseconds, then the second round RTO is 400 milliseconds, and the third round RTO is 800 milliseconds, and so on.
RTO is calculated based on RTT (round-trip time) for a packet. If the RTT is large, the calculated RTO will also be large, and after several rounds of retransmission, it will quickly reach the timeout value mentioned above.
For example, if tcp_retries2 is set to 15 and the RTT is relatively small, the initial RTO will be close to the lower limit of 200ms. This means that it will take 924.6 seconds to notify the upper layer (i.e., the application program) that the TCP connection has been disconnected. The relationship between the RTO growth for each round is shown in the following table:
Unplugging the network cable without data transmission#
In the scenario where the network cable is unplugged without any data transmission, it depends on whether the TCP keepalive mechanism is enabled.
If the TCP keepalive mechanism is not enabled, when the network cable is unplugged on the client side and neither party performs any data transmission, the TCP connection between the client and the server will remain active.
However, if the TCP keepalive mechanism is enabled, when the network cable is unplugged on the client side and neither party performs any data transmission, after a certain period of time, TCP will send probe packets: