TCP的异常终止与RST报文

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报文，并关闭连接

• 处理半打开连接：服务器关闭或异常终止了连接，但客户端没有接收到FIN报文段（比如发送网络故障），此时客户端还维持着原来的连接，而服务器即使重启，也没有该连接的任何消息了。这就是半打开连接，维持连接的一方的状态就是半打开状态。这个时候如果客户端往这个连接中写数据，对方因为网络故障，一直没有响应，这个时候如果超时定时器超时了，那么就主动发送RST报文（之前的理解错了，理解为是服务器发送客户端RST报文，只是细细一想，服务器都没有网络了，怎么发？）

• 服务器主机关机：服务器进程会正常终止，init进程发送SIGKILL信号给服务器进程，这个时候服务器会主动发送FIN给客户端，这相等于正常的四次挥手，这里没有RST

• 服务器主机崩溃后重启：服务器重启后，所有的TCP连接丢失，这个时候客户端再发送来数据，服务器会认为不认识这个连接，响应一个RST（在第一条中已经说到），这个时候服务器端就可能响应大量的RST

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

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

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

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

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