大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。
Jetbrains全系列IDE稳定放心使用
我们知道TCP建立连接的时候需要三次连接，TCP释放连接的时候需要四次挥手，在这个过程中，出现了很多特殊的标志报文段，例如SYN ACK FIN，在TCP协议中，除了上面说了那些标志报文段之外，还有其他的报文段，如PUSH标志报文段以及今天需要重点讲解的RST报文段。
RST：（Reset the connection）用于复位因某种原因引起出现的错误连接，也用来拒绝非法数据和请求。如果接收到RST位时候，通常发生了某些错误；
发送RST包关闭连接时，不必等缓冲区的包都发出去，直接就丢弃缓冲区中的包，发送RST；接收端收到RST包后，也不必发送ACK包来确认。
“Connection reset”的原因是服务器关闭了Connection[调用了Socket.close()方法]。大家可能有疑问了：服务器关闭了Connection为什么会返回“RST”而不是返回“FIN”标志。原因在于Socket.close()方法的语义和TCP的“FIN”标志语义不一样：发送TCP的“FIN”标志表示我不再发送数据了，而Socket.close()表示我不在发送也不接受数据了。问题就出在“我不接受数据” 上，如果此时客户端还往服务器发送数据，服务器内核接收到数据，但是发现此时Socket已经close了，则会返回“RST”标志给客户端。当然，此时客户端就会提示：“Connection reset”。
产生RST报文的几种情景
- 目的地为某端口的SYN到达，然而该端口上没有正在监听的服务器；
客户端发起三次握手，发送完第一个SYN分节之后，收到来自服务器的RST分节（个人理解，分节就是报文段？）。
RST分节的内容：如果收到的是ACK报文，RST取ACK报文的ACK序列号为RST报文的SEQ；如果报文不是ACK报文，RST的SEQ为0且ACK字段为收到的报文SEQ+报文长度；
- 请求超时
一个客户端连接服务器，connect返回-1并且error=EINPROGRESS。 直接telnet发现网络连接没有问题。ping没有出现丢包。用抓包工具查看，客户端是在收到服务器发出的SYN之后就莫名其妙的发送了RST。
这是为什么呢？
原因就是请求超时了。
有89、27两台主机。主机89向主机27发送了一个SYN，表示希望连接8888端口，主机27回应了主机89一个SYN表示可以连接。但是主机27却很不友好，莫名其妙的发送了一个RST表示我不想连接你了。
后来经过排查发现，在主机27上的程序在建立了socket之后，用setsockopt的SO_RCVTIMEO选项设置了recv的超时时间为100ms。而我们看上面的抓包结果表示，从主机89发出SYN到接收SYN的时间多达110ms。（从15:01:27.799961到15:01:27.961886， 小数点之后的单位是微秒）。因此主机27上的程序认为接收超时，所以发送了RST拒绝进一步接收数据。
- 想取消一个已存在的连接
操作系统接收到的来自TCP连接中的每一个字节，我都会让应用程序接收到。如果应用程序不接收怎么办？发送RST。
打开一个socket然后连接一个服务器并发送5000个字节。刚才我们看服务器的代码，每次只接收4096个字节，那么就是说客户端发送的剩下的4个字节服务端的应用程序没有接收到，服务器端的socket就被关闭掉，这种情况下会发生什么状况呢，还是抓包看一看。
前三行就是TCP的3次握手，从第四行开始看，客户端的49660端口向服务器的9877端口发送了5000个字节的数据，然后服务器端发送了一个ACK进行了确认，紧接着服务器向客户端发送了一个RST断开了连接。
如果想提前关闭一个连接，就需要发送RST报文段。
- 客户端在服务端已经关闭掉socket之后，仍然在发送数据。
假设server和client 已经建立了连接，server调用了close(Socket.close()方法的语义和TCP的“FIN”标志语义不一样：发送TCP的“FIN”标志表示我不再发送数据了，而Socket.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信号，该信号的默认行为是终止进程，因此进程必须捕获它以免不情愿地被终止；**
- TCP接收到一个根本不存在的连接上的分节；
TCP接收到一个根本不存在的连接上的分节；服务器主机崩溃后重启：它的TCP丢失了崩溃前的所有连接信息，因此服务器TCP对于所有收到的来自客户的数据分节响应一个RST；
总结出现RST报文的场景：
1.connect一个不存在的端口；
2.向一个已经关掉的连接send数据；
3.向一个已经崩溃的对端发送数据（连接之前已经被建立）；
4.close(sockfd)时，直接丢弃接收缓冲区未读取的数据，并给对方发一个RST。这个是由SO_LINGER选项来控制的；
5.a重启，收到b的保活探针，a发rst，通知b。发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/187150.html原文链接：https://javaforall.net
