【网络原理】TCP异常处理（二）：连接异常
目录
一. 由进程崩溃引起的连接断开
二. 由关机引起的连接断开
三. 由断电引起的连接断开
四. 由网线断开引起的连接断开
一. 由进程崩溃引起的连接断开
在一般情况下，进程无论是正常结束，还是异常崩溃，都会触发回收文件资源，关闭文件的操作（四次挥手）
也就是说即使进程崩溃了，但是操作系统内核还在运行，会执行后续的关闭行为（四次挥手）
进程崩溃，实际上和正常的四次挥手正常结束，没有区别，操作系统内核中保存着连接信息，完成后续的挥手过程
二. 由关机引起的连接断开
当执行关机操作，就会强制终止所有的进程（强杀进程），终止进程那么就会触发四次挥手
关机操作，不会立即杀死进程，而是有一个很短暂的过程，在这个过程中，会执行四次挥手，可能四次挥手执行完，也可能没有执行完，但是最起码能发送一个FIN数据报给服务器
1）完成四次挥手
如果在这个短暂的时间内，四次挥手执行完毕，那么客户端和服务器都能正确的删除保存的连接信息
2）只发送了FIN报文
如果客户端只发送了FIN报文，意味着告诉了对方，这边要结束了，服务器返回ACK报文，客户端接收不到，并且发送FIN报文，但是发送的FIN报文等不到ACK应答报文，服务器收不到ACK报文，肯定会进行重传（超时重传），当重传几次之后，发现还是接受不到，那么就会单方面释放连接信息
客户端关机清除了对端的连接信息，服务器持续接收不到ACK报文，单方面释放连接信息
三. 由断电引起的连接断开
由断电原因，电脑瞬间关机，肯定连发送FIN报文的机会都没有，这时候就要分类讨论
1）断电方是接收方
如果断电方是服务器，发送方在发送数据的时候，会发现接收方没有返回ACK应答报文，这时候会进入超时重传状态，重传几次之后，发现没有用，那么就会尝试“复位连接”（RST置为1），会清除原来TCP连接中的数据，重新尝试建立连接，多次尝试，没有用，最后彻底丢弃掉对方的信息
2）断电方是发送方
由于接收方本身就是处于阻塞等待，等待发送方发送数据，如果长时间没有接收到消息，接收方需要判断发送方是没有消息发送，还是挂了？如果挂了，还处于阻塞等待，就是浪费资源
所以如果长时间没有收到消息，接收方会发送一个“心跳包”，判断接收方的状态
心跳包：不携带载荷的特殊数据包，具有周期性的特点，如果没有返回ACK那么就认为挂了，本端也会尝试复位，如果没用会彻底丢弃对端信息
四. 由网线断开引起的连接断开
由于网线断开，客户端服务器都无法发送或接收任何数据包，这种情况就是断电两种情况的结合
这时候双方都会以为是自己的问题，都会尝试发送数据，但是都收不到ACK应答报文，都会进入超时重传状态，尝试几次，还是无法收到消息，会尝试复位连接，一直尝试没有用，最后会彻底丢弃掉对方的信息
TCP和UDP的应用场景？
- 如果追求可靠传输，那么首选TCP
- 如果传输的数据包很大，那么首选TCP
- 如果追求传输速率，对可靠性要求不高，那么首选UDP