说到TCP协议，对于从事即时通讯/IM这方面应用的开发者们来说，再熟悉不过了。随着对TCP理解的越来越深入，很多曾今碰到过但没时间深入探究的TCP技术概念或疑问，现在是时候回头来恶补一下了。

有人认为，网线都被拔掉了，那说明物理层被断开，那么物理层之上的传输层肯定也会断开，所以原来的 TCP 连接自然也就不存在了。

上面这个逻辑是有问题的。

问题在于：错误的认为拔掉网线这个动作会影响传输层，事实上并不会影响！

实际上：TCP 连接在 Linux 内核中是一个名为 struct socket 的结构体，该结构体的内容包含 TCP 连接的状态等信息。

所以：当拔掉网线的时候，操作系统并不会变更该结构体的任何内容，所以 TCP 连接的状态也不会发生改变。

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

通过上面实验结果可以验证我的结论：拔掉网线这个动作并不会影响 TCP 连接的状态。

不过，这个答案还是有点笼统。实际上，我们应该在更具体的场景中来看待这个问题，答案才更准确一些。

这个具体场景就是：

1）当拔掉网线后，有数据传输时；

2）当拔掉网线后，没有数据传输时。

针对上面这两种具体的场景，我来更具体地来分析一下。

数据传输过程中，恰好又把网线插回去了

如果是客户端被拔掉网线后，服务端向客户端发送的数据报文会得不到任何的响应，在等待一定时长后，服务端就会触发TCP协议的超时重传机制，然而此时重传并不能得到响应的数据报文。

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

此时：客户端和服务端的 TCP 连接将依然存在且工作状态不会受到影响，给应用层的感觉就像什么事情都没有发生。

数据传输过程中，网线一直没有插回去

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

接下来，如果客户端再插回网线，如果客户端向服务端发送了数据，由于服务端已经没有与客户端匹配的 TCP 连接信息了，因此服务端内核就会回复 RST 报文，客户端收到后就会释放该 TCP 连接。

此时：客户端和服务端的 TCP 连接已经明确被断开，原本的这个连接也就不存在了。

刨根问底：TCP数据报文到底重传几次？

本着知其然更应知其所以然的精神，我们来刨根问底一下：TCP 的数据报文到底有重传几次呢？

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

不过 tcp_retries2 设置了 15 次，并不代表 TCP 超时重传了 15 次才会通知应用程序终止该 TCP 连接，内核还会基于“最大超时时间”来判定。即时通讯聊天软件app开发可以咨询蔚可云。

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

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

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

针对拔掉网线后，没有数据传输的场景，还得具体看看是否开启了 TCP KeepAlive 机制 。

1）如果没有开启 TCP KeepAlive 机制：

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

2）如果开启了 TCP KeepAlive 机制：

在客户端拔掉网线后，即使双方都没有进行数据传输，在持续一段时间后，TCP 就会发送KeepAlive探测报文。

根据KeepAlive探测报文响应情况，会有以下两种可能：

    1）如果对端正常工作：当探测报文被对端收到并正常响应， TCP 保活时间将被重置，等待下一个 TCP 保活时间的到来；

    2）如果对端主机崩溃或对端由于其他原因导致报文不可达：当探测报文发送给对端后，石沉大海、没有响应，连续几次，达到保活探测次数后，TCP 会报告该连接已经死亡。

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

TCP KeepAlive 机制的原理是这样的：

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

在 Linux 内核可以有对应的参数可以设置保活时间、保活探测的次数、保活探测的时间间隔。

以下是 Linux 中的默认值：

    net.ipv4.tcp_keepalive_time=7200

    net.ipv4.tcp_keepalive_intvl=75

    net.ipv4.tcp_keepalive_probes=9

解释一下：

    1）tcp_keepalive_time=7200：表示保活时间是 7200 秒（2小时），也就 2 小时内如果没有任何连接相关的活动，则会启动保活机制；

    2）tcp_keepalive_intvl=75：表示每次检测间隔 75 秒；

    3）tcp_keepalive_probes=9：表示检测 9 次无响应，认为对方是不可达的，从而中断本次的连接。

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

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