上一讲讲述了亚马逊云服务reset数据包导致了应用端灵异事件，那么本讲将详细描述reset具体是什么，什么时候触发的，与应用的关系，如何构造reset数据包？

1、reset数据包格式

TCP uses the RST (Reset) bit in the TCP header to reset a  TCP connection.

 在数据包里面，TCP Flags如果RST标记为1，则代表数据包为reset数据包，在wireshark中会数据包显示红色。

我们查看Linux源代码，TCP构造reset数据包的时候，只有TCP header信息，没有上层应用payload信息。

所以我们查看抓包文件里面的reset数据包，一般为Len=0。

但有的实现里面，还能包括payload信息，例如下图：

Payload长度为61，我们查看具体内容（下图）：

Payload信息描述了reset的具体原因，这种带有payload的信息一般在中间设备存在，Linux服务器TCP或者客户端TCP一般不会带有payload信息。

2、什么场景下会产生reset数据包？

 RFC官方是这么说的：

[if !vml]

详细信息如下图：

 从上面官方说法来说，只要sequence序列号在窗口范围，reset数据包就是有效的，这就意味着如果能够监听服务器方向过来的数据包，就可以轻松利用这些数据包的TCP sequence序列号去伪造reset数据包，进而可以达到攻击应用的目的。在TCP/IP协议设计里面，在安全方面存在着缺陷，很容易被人利用这一点去攻击服务器，也即reset攻击。

发送reset的场合，根据经验总结如下：

1.abort

2.第一次握手数据包遇到服务不存在，TCP发送reset数据包

3.非三次握手数据包到底服务器TCP，TCP通过连接信息去找相应的TCB，发现没有，则发送reset数据包给客户端

4.端拒绝接收数据

5.防火墙/路由器干扰

6.中间设备超时处理

7.reset攻击

8.操作系统清除连接资源（例如windows）

9.销毁TCP资源使用

 其中abort具体说明如下，由于一般很少被用户使用，不这不做过多介绍。

 下面我们以案例的方式讲述上面内容。

4、案例分析

4.1 服务不存在

4.2 路由器干扰

4.3 对端拒绝接收数据

4.4 中间设备超时处理

4.5 reset攻击

在能够监听数据包的场合，利用数据包里面的sequence序列号，构造出reset数据包并发送出去，使得大量正常连接异常被终结，引起应用混乱。

应该说reset数据包是互联网最具破坏性的数据包，轻松可以产生灵异问题。

4.6 操作系统清理TCP资源

4.7 销毁TCP资源

利用reset数据包，可以清理服务器端长久异常TCP状态，比如清理大量CLOSE_WAIT状态，这部分内容后续章节会有详细实验。

5、与应用的关系

下图展示了遇到reset数据包，TCP是如何反映的。

当TCP状态处于SYN_SENT，如果遇到reset，则会向上层应用报connection refused错误（ECONNREFUSED）。当TCP状态处于CLOSE_WAIT状态，TCP会向上层报pipe错误（EPIPE)。当TCP状态处于CLOSED状态，则不会做任何动作。其它情况下，都会向上层应用报connection

reset错误（ECONNRESET）。

6、如何构造reset数据包

要想成功构造reset数据包，需要满足如下条件：

[if !supportLists]1.     [endif]能够监听到TCP session会话

[if !supportLists]2.     [endif]构建sequence要正确

[if !supportLists]3.     [endif]tcp checksum要计算好

[if !supportLists]4.     [endif]绕开TCP从IP层或者数据链路层发送出去

具体如下图：