一、服务端进程崩溃，客户端会发生什么？
TCP 的连接信息是由内核维护的，所以当服务端的进程崩溃后，内核需要回收该进程的所有 TCP 连接资源，于是内核会发送第一次挥手 FIN 报文，后续的挥手过程也都是在内核完成，并不需要进程的参与，所以即使服务端的进程退出了，还是能与客户端完成 TCP四次挥手的过程。
二、服务端主机宕机后，客户端会发生什么？
当服务端的主机突然断电了，这种情况就是属于服务端主机宕机了。当服务端的主机发生了宕机，是没办法和客户端进行四次挥手的，所以在服务端主机发生宕机的那一时刻，客户端是没办法立刻感知到服务端主机宕机了，只能在后续的数据交互中来感知服务端的连接已经不存在了。
因此，我们要分两种情况来讨论：
1、服务端主机宕机后，客户端会发送数据；
2、服务端主机宕机后，客户端一直不会发送数据；
服务端主机宕机后，如果客户端会发送数据
在服务端主机宕机后，客户端发送了数据报文，由于得不到响应，在等待一定时长后，客户端就会触发超时重传机制，重传未得到响应的数据报文。
当重传次数达到达到一定阈值后，内核就会判定出该 TCP 连接有问题，然后通过 Socket 接口告诉应用程序该 TCP 连接出问题了，于是客户端的 TCP 连接就会断开。
那 TCP 的数据报文具体重传几次呢？在 Linux 系统中，提供了一个叫 tcp_retries2 配置项，默认值是 15。这个内核参数是控制在 TCP 连接建立的情况下，超时重传的最大次数。
服务端主机宕机后，如果客户端一直不发数据
在服务端主机发送宕机后，如果客户端一直不发送数据，那么还得看是否开启了 TCP keepalive 机制 （TCP 保活机制）。
如果没有开启 TCP keepalive 机制，在服务端主机发送宕机后，如果客户端一直不发送数据，那么客户端的 TCP 连接将一直保持存在，所以我们可以得知一个点，在没有使用 TCP 保活机制，且双方不传输数据的情况下，一方的 TCP 连接处在 ESTABLISHED 状态时，并不代表另一方的 TCP 连接还一定是正常的。
而如果开启了 TCP keepalive 机制，在服务端主机发送宕机后，即使客户端一直不发送数据，在持续一段时间后，TCP 就会发送探测报文，探测服务端是否存活：
1）如果对端是正常工作的。当 TCP 保活的探测报文发送给对端, 对端会正常响应，这样 TCP 保活时间会被重置，等待下一个 TCP 保活时间的到来。
2）如果对端主机崩溃，或对端由于其他原因导致报文不可达。当 TCP 保活的探测报文发送给对端后，石沉大海，没有响应，连续几次，达到保活探测次数后，TCP 会报告该 TCP 连接已经死亡。
所以，TCP keepalive 机制可以在双方没有数据交互的情况，通过探测报文，来确定对方的 TCP 连接是否存活。
注意，应用程序如果想使用 TCP 保活机制，需要通过 socket 接口设置 SO_KEEPALIVE 选项才能够生效，如果没有设置，那么就无法使用 TCP 保活机制。
三、总结
1、如果「服务端挂掉」指的是「服务端进程崩溃」，服务端的进程在发生崩溃的时候，内核会发送 FIN 报文，与客户端进行四次挥手。
2、但是，如果「服务端挂掉」指的是「服务端主机宕机」，那么是不会发生四次挥手的，具体后续会发生什么？还要看客户端会不会发送数据？
1）如果客户端会发送数据，由于服务端已经不存在，客户端的数据报文会超时重传，当重传总间隔时长达到一定阈值（内核会根据 tcp_retries2 设置的值计算出一个阈值）后，会断开 TCP 连接；
2）如果客户端一直不会发送数据，再看客户端有没有开启 TCP keepalive 机制？
a.如果有开启，客户端在一段时间没有进行数据交互时，会触发 TCP keepalive 机制，探测对方是否存在，如果探测到对方已经消亡，则会断开自身的 TCP 连接；
b.如果没有开启，客户端的 TCP 连接会一直存在，并且一直保持在 ESTABLISHED 状态。
原文网站如下：xiaolincoding.com，原文内容详细，在此摘抄记录。