今天，聊一个有趣的问题：拔掉网线几秒，再插回去，原本的TCP连接还存在吗？

可能有的同学会说，网线都被拔掉了，那说明物理层被断开了，那在上层的传输层理应也会断开，所以原本的TCP连接就不会存在的了。就好像，我们拨打有线电话的时候，如果某一方的电话线被拔了，那么本次通话就彻底断了。

真的是这样吗？

上面这个逻辑就有问题。问题在于，错误的认为拔掉网线这个动作会影响传输层，事实上并不会影响。

实际上，TCP连接在Linux内核中是一个名为structsocket的结构体，该结构体的内容包含TCP连接的状态等信息。当拔掉网线的时候，操作系统并不会变更该结构体的任何内容，所以TCP连接的状态也不会发生改变。

我在我的电脑上做了个小实验，我用ssh终端连接了我的云服务器，然后我通过断开wifi的方式来模拟拔掉网线的场景，此时查看TCP连接的状态没有发生变化，还是处于ESTABLISHED状态。

通过上面这个实验结果，我们知道了，拔掉网线这个动作并不会影响TCP连接的状态。

接下来，要看拔掉网线后，双方做了什么动作。

所以，针对这个问题，要分场景来讨论：

拔掉网线后，有数据传输；拔掉网线后，没有数据传输；

拔掉网线后，有数据传输

在客户端拔掉网线后，服务端向客户端发送的数据报文会得不到任何的响应，在等待一定时长后，服务端就会触发超时重传机制，重传未得到响应的数据报文。

如果在服务端重传报文的过程中，客户端刚好把网线插回去了，由于拔掉网线并不会改变客户端的TCP连接状态，并且还是处于ESTABLISHED状态，所以这时客户端是可以正常接收服务端发来的数据报文的，然后客户端就会回ACK响应报文。

此时，客户端和服务端的TCP连接依然存在的，就感觉什么事情都没有发生。

但是，如果如果在服务端重传报文的过程中，客户端一直没有将网线插回去，服务端超时重传报文的次数达到一定阈值后，内核就会判定出该TCP有问题，然后通过Socket接口告诉应用程序该TCP连接出问题了，于是服务端的TCP连接就会断开。

而等客户端插回网线后，如果客户端向服务端发送了数据，由于服务端已经没有与客户端相同四元祖的TCP连接了，因此服务端内核就会回复RST报文，客户端收到后就会释放该TCP连接。

此时，客户端和服务端的TCP连接都已经断开了。

那TCP的数据报文具体重传几次呢？

在Linux系统中，提供了一个叫tcp_retries2配置项，默认值是15，如下图：

这个内核参数是控制，在TCP连接建立的情况下，超时重传的最大次数。

不过tcp_retries2设置了15次，并不代表TCP超时重传了15次才会通知应用程序终止该TCP连接，内核还会基于「最大超时时间」来判定。

每一轮的超时时间都是倍数增长的，比如第一次触发超时重传是在2s后，第二次则是在4s后，第三次则是8s后，以此类推。

内核会根据tcp_retries2设置的值，计算出一个最大超时时间。

在重传报文且一直没有收到对方响应的情况时，先达到「最大重传次数」或者「最大超时时间」这两个的其中一个条件后，就会停止重传，然后就会断开TCP连接。

拔掉网线后，没有数据传输

针对拔掉网线后，没有数据传输的场景，还得看是否开启了TCPkeepalive机制（TCP保活机制）。

如果没有开启TCPkeepalive机制，在客户端拔掉网线后，并且双方都没有进行数据传输，那么客户端和服务端的TCP连接将会一直保持存在。

而如果开启了TCPkeepalive机制，在客户端拔掉网线后，即使双方都没有进行数据传输，在持续一段时间后，TCP就会发送探测报文：

如果对端是正常工作的。当TCP保活的探测报文发送给对端,对端会正常响应，这样TCP保活时间会被重置，等待下一个TCP保活时间的到来。如果对端主机崩溃，或对端由于其他原因导致报文不可达。当TCP保活的探测报文发送给对端后，石沉大海，没有响应，连续几次，达到保活探测次数后，TCP会报告该TCP连接已经死亡

所以，TCP保活机制可以在双方没有数据交互的情况，通过探测报文，来确定对方的TCP连接是否存活。

TCPkeepalive机制具体是怎么样的？

这个机制的原理是这样的：

定义一个时间段，在这个时间段内，如果没有任何连接相关的活动，TCP保活机制会开始作用，每隔一个时间间隔，发送一个探测报文，该探测报文包含的数据非常少，如果连续几个探测报文都没有得到响应，则认为当前的TCP连接已经死亡，系统内核将错误信息通知给上层应用程序。

在Linux内核可以有对应的参数可以设置保活时间、保活探测的次数、保活探测的时间间隔，以下都为默认值：

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

tcp_keepalive_time=7200：表示保活时间是7200秒（2小时），也就2小时内如果没有任何连接相关的活动，则会启动保活机制tcp_keepalive_intvl=75：表示每次检测间隔75秒；tcp_keepalive_probes=9：表示检测9次无响应，认为对方是不可达的，从而中断本次的连接。

也就是说在Linux系统中，最少需要经过2小时11分15秒才可以发现一个「死亡」连接。

图片

注意，应用程序若想使用TCP保活机制需要通过socket接口设置SO_KEEPALIVE选项才能够生效，如果没有设置，那么就无法使用TCP保活机制。

TCPkeepalive机制探测的时间也太长了吧？

对的，是有点长。

TCPkeepalive是TCP层（内核态）实现的，它是给所有基于TCP传输协议的程序一个兜底的方案。

实际上，我们应用层可以自己实现一套探测机制，可以在较短的时间内，探测到对方是否存活。

比如，web服务软件一般都会提供keepalive_timeout参数，用来指定HTTP长连接的超时时间。如果设置了HTTP长连接的超时时间是60秒，web服务软件就会启动一个定时器，如果客户端在完后一个HTTP请求后，在60秒内都没有再发起新的请求，定时器的时间一到，就会触发回调函数来释放该连接。

总结

客户端拔掉网线后，并不会直接影响TCP连接状态。所以，拔掉网线后，TCP连接是否还会存在，关键要看拔掉网线之后，有没有进行数据传输。

有数据传输的情况：

在客户端拔掉网线后，如果服务端发送了数据报文，那么在服务端重传次数没有达到最大值之前，客户端就插回了网线，那么双方原本的TCP连接还是能正常存在，就好像什么事情都没有发生。在客户端拔掉网线后，如果服务端发送了数据报文，在客户端插回网线之前，服务端重传次数达到了最大值时，服务端就会断开TCP连接。等到客户端插回网线后，向服务端发送了数据，因为服务端已经断开了与客户端相同四元组的TCP连接，所以就会回RST报文，客户端收到后就会断开TCP连接。至此，双方的TCP连接都断开了。

没有数据传输的情况：

如果双方都没有开启TCPkeepalive机制，那么在客户端拔掉网线后，如果客户端一直不插回网线，那么客户端和服务端的TCP连接状态将会一直保持存在。如果双方都开启了TCPkeepalive机制，那么在客户端拔掉网线后，如果客户端一直不插回网线，TCPkeepalive机制会探测到对方的TCP连接没有存活，于是就会断开TCP连接。而如果在TCP探测期间，客户端插回了网线，那么双方原本的TCP连接还是能正常存在。

除了客户端拔掉网线的场景，还有客户端「宕机和杀死进程」的两种场景。

第一个场景，客户端宕机这件事跟拔掉网线是一样无法被服务端的感知的，所以如果在没有数据传输，并且没有开启TCPkeepalive机制时，，服务端的TCP连接将会一直处于ESTABLISHED连接状态，直到服务端重启进程。

所以，我们可以得知一个点。在没有使用TCP保活机制，且双方不传输数据的情况下，一方的TCP连接处在ESTABLISHED状态时，并不代表另一方的TCP连接还一定是正常的。

第二个场景，杀死客户端的进程后，客户端的内核就会向服务端发送FIN报文，与客户端进行四次挥手。

所以，即使没有开启TCPkeepalive，且双方也没有数据交互的情况下，如果其中一方的进程发生了崩溃，这个过程操作系统是可以感知的到的，于是就会发送FIN报文给对方，然后与对方进行TCP四次挥手。

原文链接：https://mp.weixin.qq.com/s/Q7byo3-3c7P81XarTx2PYw作者：小林coding

如果觉得本文对你有帮助，可以转发关注支持一下