TCP系列09—连接管理—8、TCP Reset

        我们在介绍TCP头的时候，提到过其中有个RST标志位。当一个TCP报文中这个标志位打开的时候，我们叫做reset包(严格的说应该叫做reset段，但是很多时候段包帧并不加以区分)或者简单称呼为reset、RST。通常reset的产生是由于一个异常包导致，reset一般会导致TCP连接的快速断开。产生reset的几种常见的情形如下

1. 向一个未打开的端口发送连接请求

2. 应用程序主动终止一个连接

3. 应用程序还没有接收缓存中的数据，连接被提前关闭

4. TWA(TIME-WAIT Assassination)
   

5. 半开连接的情况下发送数据

注意我们这里是描述的reset产生的一些场景(而且是部分场景)，在具体reset的产生原因上可能会有重复，比如第1、4、5都可以认为是对端没有打开相对应的TCP端口。

一、向一个未打开的端口发送连接请求

        reset产生的一个常见的原因是，在一个未打开的端口发送连接请求。这里未打开的端口是指没有应用程序在监听这个端口等待连接。

如下图wireshark抓包，再不开启server情况下，没有应用程序监听9877端口，当client连接9877端口的时候就会产生reset消息。

注意我截图中的系列号，在这个截图中我设置了wireshark显示绝对系列号(前面文章截图显示的都是相对系列号)，因为SYN包中的ACK标志没有置位，ack number字段无效(实际是以0填充的)，所以在reset中的seq=0,ack则为SYN包中的seq+1(因为SYN标志和FIN标志在逻辑上占1byte)。一个reset包如果要被TCP endpoint接收，ACK标志必须置位且ack number落在有效的窗口区间内(窗口相关知识后面细讲)。这帮助阻止了一个简单的reset攻击(RFC5961)，否则攻击者可以通过伪造源IP地址、源端口号构造一个reset消息来中断TCP连接。

二、应用程序主动通过reset消息终止一个连接

        应用程序可以通过socket API接口设置主动reset一个TCP连接，这种情况下的连接中断过程称为abortive release。之前我们介绍过的四次挥手之类的通过FIN终止连接的过程我们称呼为orderly release。在abortive release情况下，reset包的发送端缓存的待发送数据都会直接丢弃，接收端接收到reset后也可以知道是对端主动abort了这个tcp连接。

        wireshark截图如下，注意client发送reset后，并不会引起server回应ACK之类的消息。

可以看到RST消息的seq正好是对端期望接收的seq，按照RFC5961要求，非SYN_SENT状态下，接收端需要判断RST消息的系列号seq为正好为自己期望接收的seq，才会认为这个RST消息有效。如果RST的系列号seq落在接收窗口内但不是期望的seq时候，接收端需要发送challenge ACK，如果落在接收窗口外则会直接丢弃这个RST消息。(实际上challenge ACK也会引起RST，详见RFC5961,此处不做介绍。)

三、应用层还没有读取完接收缓存中的数据，连接被提前关闭

       当TCP接收端缓存中还有缓存数据而没有被应用层接收，但是应用层直接关闭TCP连接时候就会产生reset，如下图wireshark抓包所示，连接建立后client向server发送10bytes的数据，server应用层并没有读取这10bytes的数据而是直接关闭tcp连接就会产生reset。

四、TWA(TIME-WAIT Assassination)

        TCP在TIME-WAIT状态下的时候，如果接收到reset包，它可能会提前结束TIME-WAIT状态，这种行为即叫做TIME-WAIT Assassination(TWA)，数据包的流程如下图所示

为了避免TIME-WAIT状态提前被reset结束，一些系统的TCP实现在TIME-WAIT状态下不会响应rst消息。linux则可以通过net.ipv4.tcp_rfc1337设置TCP在TIME-WAIT下是否响应reset，如果设置tcp_rfc1337为0，在TIME-WAIT下如果接收到reset则会直接关闭tcp连接，而不会等到2MSL超时。

五、半开连接的情况下发送数据

        关于半开连接我们前面已经进行了介绍，同时wireshark抓包中也有对应的reset的展示，此处不再介绍。

来自为知笔记(Wiz)

转载于:https://www.cnblogs.com/lshs/p/6038500.html