RST位就在TCP异常时出现 1.RST表示复位，用来异常的关闭连接，在TCP的设计中它是不可或缺的。就像上面说的一样，发送RST包关闭连接时，不必等缓冲区的包都发出去（不像上面的FIN包），直接就丢弃缓存区的包发送RST包。而接收端收到RST包后，也不必发送ACK包来确认。 2.TCP处理程序会在自己认为的异常时刻发送RST包。例如，A向B发起连接，但B之上并未监听相应的端口，这时B操作系统上的TCP处理程序会发RST包。 又比如，AB正常建立连接了，正在通讯时，A向B发送了FIN包要求关连接，B发送ACK后，网断了，A通过若干原因放弃了这个连接（例如进程重启）。网通了后，B又开始发数据包，A收到后表示压力很大，不知道这野连接哪来的，就发了个RST包强制把连接关了，B收到后会出现connect reset by peer错误。
产生RST的三个条件：
- 目的地为某端口的SYN到达，然而该端口上没有正在监听的服务器；
- TCP想取消一个已有的连接；
- TCP接收到一个根本不存在的连接上的分节；
情况一： 不运行服务端，直接运行客户端程序，可以看到客户端通过connect方法发起三次握手，发送完第一个SYN分节以后，收到来自服务端的RST分节；
情况二： （假设server和client 已经建立了连接，server调用了close, 发送FIN 段给client，此时server不能再通过socket发送和接收数据，此时client调用read，如果接收到FIN 段会返回0，但client此时还是可以write 给server的，write调用只负责把数据交给TCP发送缓冲区就可以成功返回了，所以不会出错，而server收到数据后应答一个RST段，表示服务器已经不能接收数据，连接重置，client收到RST段后无法立刻通知应用层，只把这个状态保存在TCP协议层。如果client再次调用write发数据给server，由于TCP协议层已经处于RST状态了，因此不会将数据发出，而是发一个SIGPIPE信号给应用层，SIGPIPE信号的缺省处理动作是终止程序）
当一个进程向某个已收到RST的套接字执行写操作时，（此时写操作返回EPIPE错误）内核向该进程发送一个SIGPIPE信号，该信号的默认行为是终止进程，因此进程必须捕获它以免不情愿地被终止； 当一个进程向某个已收到RST的套接字执行读操作时，（此时读操作返回ECONNRESET错误）
上述情况会因引发的问题
服务器主机进程终止或者崩溃后重启，客户端在不write的情况下不会知道，read会返回ECONNRESET错误或者超时； 解决 如果对端TCP发送一个FIN（对端进程终止），那么该套接字变为可读，并且read返回0； 如果对端TCP发送一个RST（对端主机崩溃并重新启动），那么该套接字变为可读，并且read返回-1，而errno中含有确切的错误码；
情况三
运行服务端，再运行客户端程序，客户端打印连接成功，if语句开头会休眠20秒，（服务端程序里面，接收一个连接以后就close套接字然后立马退出程序了）在这期间内再次打开服务端，等待客户端的读取数据的分节到达，然后返回一个RST分节给客户端，是因为TCP接收到一个根本不存在的连接上的分节；服务器主机崩溃后重启：它的TCP丢失了崩溃前的所有连接信息，因此服务器TCP对于所有收到的来自客户的数据分节响应一个RST；
RST*** 1.A和服务器B之间建立了TCP连接，此时C伪造了一个TCP包发给B，使B异常的断开了与A之间的TCP连接，就是RST***了
伪造后的目的： 1.假定C伪装成A发过去的包，这个包如果是RST包的话，毫无疑问，B将会丢弃与A的缓冲区上所有数据，强制关掉连接。 2.如果发过去的包是SYN包，那么，B会表示A已经发疯了（与OS的实现有关），正常连接时又来建新连接，B主动向A发个RST包，并在自己这端强制关掉连接。
如何进行伪装 源端口和序列号。 一个TCP连接都是四元组，由源IP、源端口、目标IP、目标端口唯，一确定一个连接A的源端口就不清楚了，因为这可能是A随机生成的。当然，如果能够对常见的OS如windows和linux找出生成source port规律的话，还是可以搞定的。
