在网络连接中，经常会出现一些意外情况，导致TCP连接不能正常工作，对于这些意外情况，TCP内部有自己的解决方法

一.进程崩溃

        在网络通讯时可能会出现进程突然崩溃的情况，当进程崩溃后进程就没了，就会导致进程的进程控制块（PCB）也被摧毁，而进程控制块中的一个属性”文件描述符表“也就被释放了，文件描述符表中有Socket网卡文件，将Socket网卡文件释放后相当于调用Socket.close(),于是崩溃的这一方就发出FIN（结束报文段）请求断开连接，就进一步触发了四次挥手，此时连接就正常释放了，所以，进程崩溃的处理和进程正常退出的处理没有区别

        关于进程推荐看Java多进程(详细)，关于四次挥手推荐看网络连接（3次握手和4次挥手）

二.主机关机(正常步骤的关机)

        正常关机，就会先尝试摧毁所有的进程（强制终止进程），就和上面说的进程崩溃的处理方式一样，在触发四次挥手断开网络连接时，主机正在关机，所以可能四次挥手挥完了以后才关机，也有可能没有挥完就关机了

        但是四次挥手有没有挥完是没有问题的，因为即使四次挥手没有挥完，要关机的这个A设备的每个进程都会发送一个FIN（结束报文段）给网络连接的另一方B设备，此时接收到FIN（结束报文段）的B设备就会返回一个ACK（应答报文段）并且发送一个FIN（结束报文段），但是A设备可能已经关机了，所以不会返回ACK（应答报文段）给B设备，B设备没有收到A设备返回的ACK（应答报文段）就会触发超时重传，再进行多次重传都没有得到A设备返回的ACK（应答报文段）后，B设备就会单方面的断开连接（释放存储网络连接相关信息的内存）

三.主机掉电（拔电源，没有任何反应的时间）

根据掉电的一方正在发送数据还是接收数据，分为两种情况

        1.掉电的一方正在接收数据

        假设设备A正在发送数据给设备B，此时设备B突然断电。

        设备A发送数据过去以后，由于设备B已经断电，所以并不会接收到设备A发送的数据，也不会返回ACK（应答报文段）给 设备A，设备A在等待一段时间后仍然没有收到设备B返回的ACK（应答报文段）就会触发超时重传（关于超时重传推荐看出现丢包问题的情况以及解决方法），在多次重传以后还是没有接收到设备B返回的ACK（应答报文段）就会触发复位报文（RST），尝试重置连接，要是重置操作仍然失败，此时设备A就会单方面的断开连接（释放与设备B进行网络连接相关的内存数据）

        2.掉电的一方正在发送数据

        假设设备A正在发送数据给设备B，此时设备A突然断电。

        设备B就处于了一个尴尬的状态，因为设备B正在接收数据，突然设备A就不发送数据了，设备B也不知道设备A是一会发送数据还是一直都不发送数据了，所以就会进入阻塞等待。

        而这里就涉及到了一个”心跳包“的机制，设备B虽然是接收方，但也会周期性的发送一个不含任何业务数据(不含载荷)的TCP数据报给设备A,目的就是触发设备A返回ACK(应答报文段)给设备B，监测设备A是否正在正常工作，网络是否通畅

        要是设备B发送TCP数据报给设备A以后，没有收到设备A返回的ACK(应答报文段)就说明此时与设备A之间的网络连接已经出现问题了，设备B就会单方面的断开与设备A之间的网络连接。

        注意

        虽然TCP中已经有心跳包的支持了，但是还不够，往往需要在应用层，应用程序中重新实现心跳包（TCP心跳包，周期太长了，是分钟级别的）而在现在高并发的场景下，分钟级是远远不够的，需要秒级甚至毫秒级的心跳包，可以在更短的时间内，发现某个服务器出现问题

四.网线断开

        相当于主机断电的升级版本，假设在网线断开时，设备A正在给设备B发送数据

        1,设备A作为发送端，设备A的处理方式就和主机掉电时”掉电的一方正在发送数据“的处理方式相同

        2.设备B作为接收端，设备B的处理方式就和主机掉电时”掉电的一方正在接收数据“的处理方式相同