TCP协议：拔掉网线后， 原本的 TCP 连接还存在吗？

问题描述

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

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

真的是这样吗？

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

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

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

图1

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

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

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

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

场景1：拔掉网线后，有数据传输

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

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

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

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

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

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

        问题来了：那 TCP 的数据报文段具体重传几次呢？

        在 Linux 系统中，内核提供了一个 tcp_retries2 系统变量，默认值是 15。

1. # cat /proc/sys/net/ipv4/tcp_retries2

2. 15

3. # sysctl -a|grep tcp_retries2

4. net.ipv4.tcp_retries2 = 15

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

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

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

图2  超时重传时间

•  RTO(Retransmission Time-Out，超时重传时间)

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

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

【参考链接】TCP协议-TCP超时重传机制

场景2：拔掉网线后，没有数据传输

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

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

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

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

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

TCP keepalive 机制具体是怎么样的？

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

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

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

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

• tcp_keepalive_time=7200：表示保活时间间隔是 7200 秒（2小时），也就是 2 小时内如果没有任何数据交互的活动，则会启动保活机制；
• tcp_keepalive_intvl=75：表示每次检测间隔 75 秒；
• tcp_keepalive_probes=9：表示如果连续检测 9 次均无响应，则认为对端是不可达的，从而结束本次TCP连接。

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

tcp_keepalive_time + (tcp_keepalive_intvl * tcp_keepalive_probes) = 7200 + (75 * 9) = 7875秒（2 小时 11 分 15秒）

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

在socket网络编程中，需要设置一个socket选项 SO_KEEPALIVE，才能开启keepalive机制。代码描述如下：

1. keepAlive = 1;

3. setsockopt(listen_fd, SOL_SOCKET, SO_KEEPALIVE, &keepAlive, sizeof(keepAlive));

 【参考链接】TCP协议-长连接和短连接

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

对的，是有点长。

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

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

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

图3  HTTP保活机制

总结

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

• 有数据传输的情况：

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

• 没有数据传输的情况：

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

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

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

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

第二个场景，杀死客户端的进程后，客户端主机的操作系统内核就会向服务器端发送 FIN 报文端，与客户端进行四次挥手，然后释放 TCP 连接。

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

参考

拔掉网线后， 原本的 TCP 连接还存在吗？