被鹅厂面怕了！
上周有位读者找我说，他在面试鹅厂的时候，遇到了这么个问题：
这个属于 TCP 异常断开连接的场景，这部分内容在我的「图解网络」还没有详细介绍过，这次就乘着这次机会补一补。
这个问题有几个关键词：
没有开启 keepalive；
一直没有数据交互；
进程崩溃；
主机崩溃；
我们先来认识认识什么是 TCP keepalive 呢？
这东西其实就是 TCP 的保活机制，它的工作原理我之前的文章写过，这里就直接贴下以前的内容。
如果两端的 TCP 连接一直没有数据交互，达到了触发 TCP 保活机制的条件，那么内核里的 TCP 协议栈就会发送探测报文。
如果对端程序是正常工作的。当 TCP 保活的探测报文发送给对端, 对端会正常响应，这样 TCP 保活时间会被重置，等待下一个 TCP 保活时间的到来。
如果对端主机崩溃，或对端由于其他原因导致报文不可达。当 TCP 保活的探测报文发送给对端后，石沉大海，没有响应，连续几次，达到保活探测次数后，TCP 会报告该 TCP 连接已经死亡。
所以，TCP 保活机制可以在双方没有数据交互的情况，通过探测报文，来确定对方的 TCP 连接是否存活。
注意，应用程序若想使用 TCP 保活机制需要通过 socket 接口设置 SO_KEEPALIVE 选项才能够生效，如果没有设置，那么就无法使用 TCP 保活机制。
知道了 TCP keepalive 作用，我们再回过头看题目中的「主机崩溃」这种情况。
在没有开启 TCP keepalive，且双方一直没有数据交互的情况下，如果客户端的「主机崩溃」了，会发生什么。
如果客户端主机崩溃了，服务端是无法感知到的，在加上服务端没有开启 TCP keepalive，又没有数据交互的情况下，服务端的 TCP 连接将会一直处于 ESTABLISHED 连接状态，直到服务端重启进程。
所以，我们可以得知一个点。
在没有使用 TCP 保活机制，且双方不传输数据的情况下，一方的 TCP 连接处在 ESTABLISHED 状态时，并不代表另一方的 TCP 连接还一定是正常的。
那题目中的「进程崩溃」的情况呢？
我自己做了个实验，使用 kill -9 来模拟进程崩溃的情况，发现在 kill 掉进程后，服务端会发送 FIN 报文，与客户端进行四次挥手。
所以，即使没有开启 TCP keepalive，且双方也没有数据交互的情况下，如果其中一方的进程发生了崩溃，这个过程操作系统是可以感知的到的，于是就会发送 FIN 报文给对方，然后与对方进行 TCP 四次挥手。
以上就是对这个面试题的回答。
这面试题其实在变相考察 TCP 保活机制的作用。
接下来我们看看在「有数据传输」的场景下的一些异常情况：
第一种，客户端主机宕机，又迅速重启，会发生什么？
第二种，客户端主机宕机，一直没有重启，会发生什么？
客户端主机宕机，又迅速重启
在客户端主机宕机后，服务端向客户端发送的报文会得不到任何的响应，在一定时长后，服务端就会触发超时重传机制，重传未得到响应的报文。
服务端重传报文的过程中，刚好客户端主机重启完成，这时客户端的内核就会接收重传的报文，：
如果客户端主机上没有进程监听该 TCP 报文的目标端口号，由于找不到目标端口，客户端内核就会回复 RST 报文，重置该 TCP 连接；
如果客户端主机上有进程监听该 TCP 报文的目标端口号，由于客户端主机重启后，之前的 TCP 连接的数据结构已经丢失了，客户端内核里协议栈会发现找不到该 TCP 连接的 socket 结构体，于是就会回复 RST 报文，重置该 TCP 连接。
所以，只要有一方重启完成后，收到之前 TCP 连接的报文，都会回复 RST 报文，以断开连接。
客户端主机宕机，一直没有重启
这种情况，服务端超时重传报文的次数达到一定阈值后，内核就会判定出该 TCP 有问题，然后通过 Socket 接口告诉应用程序该 TCP 连接出问题了。
那具体重传几次呢？
在 Linux 系统中，提供了一个叫 tcp_retries2 配置项，默认值是 15，如下图：
这个内核参数是控制，在 TCP 连接建立的情况下，超时重传的最大次数。
不过 tcp_retries2 设置了 15 次，并不代表 TCP 超时重传了 15 次才会通知应用程序终止该 TCP 连接，内核还会基于「最大超时时间」来判定。
每一轮的超时时间都是倍数增长的，比如第一次触发超时重传是在 2s 后，第二次则是在 4s 后，第三次则是 8s 后，以此类推。
内核会根据 tcp_retries2 设置的值，计算出一个最大超时时间。
在重传报文且一直没有收到对方响应的情况时，先达到「最大重传次数」或者「最大超时时间」这两个的其中一个条件后，就会停止重传。
最后说句。
TCP 牛逼，啥异常都考虑到了