被鹅厂面怕了!
扫描二维码
随时随地手机看文章
- 没有开启 keepalive;
- 一直没有数据交互;
- 进程崩溃;
- 主机崩溃;
- 如果对端程序是正常工作的。当 TCP 保活的探测报文发送给对端, 对端会正常响应,这样 TCP 保活时间会被重置,等待下一个 TCP 保活时间的到来。
- 如果对端主机崩溃,或对端由于其他原因导致报文不可达。当 TCP 保活的探测报文发送给对端后,石沉大海,没有响应,连续几次,达到保活探测次数后,TCP 会报告该 TCP 连接已经死亡。
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 有问题,然后通过 Socket 接口告诉应用程序该 TCP 连接出问题了。那具体重传几次呢?在 Linux 系统中,提供了一个叫 tcp_retries2 配置项,默认值是 15,如下图:这个内核参数是控制,在 TCP 连接建立的情况下,超时重传的最大次数。不过 tcp_retries2 设置了 15 次,并不代表 TCP 超时重传了 15 次才会通知应用程序终止该 TCP 连接,内核还会基于「最大超时时间」来判定。每一轮的超时时间都是倍数增长的,比如第一次触发超时重传是在 2s 后,第二次则是在 4s 后,第三次则是 8s 后,以此类推。内核会根据 tcp_retries2 设置的值,计算出一个最大超时时间。在重传报文且一直没有收到对方响应的情况时,先达到「最大重传次数」或者「最大超时时间」这两个的其中一个条件后,就会停止重传。最后说句。TCP 牛逼,啥异常都考虑到了