被鹅厂面怕了！

Posted 2021-06-27 小林coding

上周有位读者找我说，他在面试腾讯的时候，遇到了这么个问题：

这个属于 TCP 异常断开连接的场景，这部分内容在我的「图解网络」还没有详细介绍过，这次就乘着这次机会补一补。

小林在 csdn 写了很多图解网络文章，共输出了 15万字 和画了 500 张图，有csdn的朋友建议我把图解网络文章整理成电子档，方便读者阅读。

那必须的呀，所以小林花了一段时间整理图解网络电子文档，效果如题：

大家可以作为面试突击的手册，现在开源给大家下载：点击下载图解网络 PDF

好了，继续今天的主题。

这个问题有几个关键词：

• 没有开启 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 状态，并不代表另一方的连接还一定正常。

那题目中的「进程崩溃」的情况呢？

我自己做了实验，使用 kill -9 来模拟进程崩溃的情况，发现在 kill 掉进程后，服务端会发送 FIN 报文，与客户端进行四次挥手。

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

---

以上就是对这个面试题的回答，接下来我们看看在「有数据传输」的场景下的一些异常情况：

• 第一种，客户端主机宕机，又迅速重启，会发生什么？
• 第二种，客户端主机宕机，一直没有重启，会发生什么？

客户端主机宕机，又迅速重启

在客户端主机宕机后，服务端向客户端发送的报文会得不到任何的响应，在一定时长后，服务端就会触发超时重传机制，重传未得到响应的报文。

服务端重传报文的过程中，客户端主机重启完成后，客户端的内核就会接收重传的报文，然后根据报文的信息传递给对应的进程：

• 如果客户端主机上没有进程监听该 TCP 报文的目标端口号，那么客户端内核就会**回复 RST 报文，重置该 TCP 连接*；
• 如果客户端主机上有进程监听该 TCP 报文的目标端口号，由于客户端主机重启后，之前的 TCP 连接的数据结构已经丢失了，客户端内核里协议栈会发现找不到该 TCP 连接的 socket 结构体，于是就会回复 RST 报文，重置该 TCP 连接。

所以，只要有一方重启完成后，收到之前 TCP 连接的报文，都会回复 RST 报文，以断开连接。

客户端主机宕机，一直没有重启

这种情况，服务端超时重传报文的次数达到一定阈值后，内核就会判定出该 TCP 有问题，然后通过 Socket 接口告诉应用程序该 TCP 连接出问题了，一般就是 ETIMEOUT 状态码。

那具体重传几次呢？

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

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

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

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

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

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

---

最后说句，TCP 牛逼，啥异常都考虑到了。