TCP的异常终止是相对于正常终止而言的。在正常情况下，TCP的正常终止都要发送FIN报文，在发送缓冲区中的数据全部发送完经历四次挥手的过程。

但在有些情况下，TCP双方在交互的时候可能出现一些意想不到的情况，导致TCP进行不能按正常的四次挥手来释放连接。如果此时不采取其他措施释放这个TCP连接的话，这个TCP连接就会一直存在，并且占用着系统的资源。于是我们就希望能够在有意向不到的情况发生的时候还可以释放我们的连接，TCP有专门针对这种情况的机制，就是RST报文机制。

发送RST报文的几种情况（几种异常终止的情况）

注意：RST报文并不需要得到对方的响应，仅仅是一个通知

某些情况下，TCP连接的一端会向另一端发送RST复位报文段，来通知对方关闭连接或重新建立连接

• 访问不存在的端口号或是处于TIME_WAIT状态的端口号：由于该端口号不可用，所以服务器发送一个RST报文段通知客户端尝试重新建立连接或是放弃连接。这种情况很常见，特别是服务器core dump之后重启之前连续出现RST的情况会经常发生

• 访问存在的端口号但是端口号上并没有进程在等待连接：客户端连接服务器时，如果服务器在指定的端口上并没有进程在等待连接（服务器进程并没有开启），那么服务器将发送RST响应给客户端。

• 请求超时：客户端在发送SYN请求建立连接的时候，在设置socket的时候设置了等待服务器响应的时间，如果超出了这个时间服务器才发过来SYN+ACK，那么这个时候客户端会任务这个连接已经超时，响应一个RST给服务器，而不是ACK

• 定时器超时：在我的另一篇博客中讲了TCP中的定时器，其中重传定时器，保活定时器，FIN_WAIT2定时器，在超出定时器能够重置的次数以及时间的上限仍然没有接收到对方发来的响应或者数据时，TCP就会认为定时器超时，于是设置定时器的一方主动发送RST报文，并关闭连接（注意这种情况与下面处理半打开连接的区别，这种情况的原因很可能是因为网络问题，报文丢失了，但是对端进程确是存在的，所以发送RST的往往是没有收到对端响应的一方，而半打开连接的对端机器往往进程不存在或是已经重启了，这个时候发送RST的是已经退出连接的一方 ）

• 处理半打开连接：服务器关闭或异常终止了连接，但客户端没有接收到FIN报文段（比如发送网络故障），此时客户端还维持着原来的连接，而服务器即使重启，也没有该连接的任何消息了。这就是半打开连接，维持连接的一方的状态就是半打开状态。这个时候如果客户端往这个连接中写数据，对方将回应一个RST报文段

• 主动异常终止连接：TCP提供了异常终止一个连接的方法，即给对方发送一个RST报文段。一旦发送了RST报文段，发送端所有排队等待发送的数据都将被丢弃（可以使用socket选项SO_LINGER来发送RST报文段，用于异常终止连接）​。

  异常终止连接对于应用程序有以下两个优点：

  • 丢弃所有待发数据并立即发送RST报文

    扫描二维码关注公众号，回复： 3095943 查看本文章

  • RST的接收方会区分另一端执行的异常关闭还是正常关闭

       有些应用开发者在设计应用系统时，主动利用RST报文快速释放已经完成数据交互的TCP连接，以提高业务交互的效率。所以不要认为异常终止就一定是不好的，反而它可能还会提高业务效率。