【tcp】关于 connection reset、connection reset by peer

我们先熟悉一下 tcp 三次握手和四次挥手：

RST的标志位，这个标识为在如下几种情况下会被设置，以下是我了解的情况，可能还有更多的场景，没有验证：

1. 当尝试和未开放的服务器端口建立tcp连接时，服务器tcp将会直接向客户端发送reset报文；

2. 双方之前已经正常建立了通信通道，也可能进行过了交互，当某一方在交互的过程中发生了异常，如崩溃等，异常的一方会向对端发送reset报文，通知对方将连接关闭；

3. 当收到TCP报文，但是发现该报文不是 已建立的TCP连接列表 可处理的，则其直接向对端发送reset报文；

4. ack报文丢失，并且超出一定的重传次数或时间后，会主动向对端发送reset报文释放该TCP连接。

“ Connection reset by peer ”和“ Connection reset” 是有区别的：

服务器返回了“RST”时，如果此时 客户端 正在从Socket套接字的 输出流 中 读数据 则会提示Connection reset”；

服务器返回了“RST”时，如果此时 客户端 正在往Socket套接字的 输入流 中 写数据 则会提示“Connection reset by peer”。

“connection reset by peer”和”broken pipe”出现的场景：

1）往一个对端已经close的通道写数据的时候，对方的tcp会收到这个报文，并且反馈一个reset报文。

当收到reset报文的时候，继续做 select读数据 的时候就会抛出Connect reset by peer的异常。

2）当第一次往一个对端已经close的通道写数据的时候会和上面的情况一样，会收到reset报文。

当再次 往这个socket写数据 的时候，就会抛出Broken pipe了 。

根据tcp的约定，当收到reset包的时候，上层必须要做出处理，调用将socket文件描述符进行关闭，其实也意味着pipe会关闭，因此会抛出这个顾名思义的异常。

Orderly Versus Abortive Connection Release in Java

关于 Connection reset原因分析和解决方案

从tcp原理角度理解Broken pipe和Connection Reset by Peer的区别

对TCP重传的进一步认识

如何解决connection reset by peer

Connection reset by peer的常见原因：

1、服务器的并发连接数超过了其承载量，服务器会将其中一些连接关闭；   如果知道实际连接服务器的并发客户数没有超过服务器的承载量，则有可能是中了病毒或者木马，引起网络流量异常。可以使用netstat -an查看网络连接情况。

2、客户关掉了浏览器，而服务器还在给客户端发送数据。

3、浏览器端按了Stop。这两种情况一般不会影响服务器。但是如果对异常信息没有特别处理，有可能在服务器的日志文件中，重复出现该异常，造成服务器日志文件过大，影响服务器的运行。可以对引起异常的部分，使用try...catch捕获该异常，然后不输出或者只输出一句提示信息，避免使用e.printStackTrace();输出全部异常信息。

4、防火墙的问题。如果网络连接通过防火墙，而防火墙一般都会有超时的机制，在网络连接长时间不传输数据时，会关闭这个TCP的会话，关闭后在读写，就会导致异常。 如果关闭防火墙，解决了问题，需要重新配置防火墙，或者自己编写程序实现TCP的长连接。实现TCP的长连接，需要自己定义心跳协议，每隔一段时间，发送一次心跳协议，双方维持连接。

5、JSP的buffer问题。JSP页面缺省缓存为8k，当JSP页面数据比较大的时候，有可能JSP没有完全传递给浏览器。这时可以适当调整buffer的大小。

Connection reset by peer 这是怎么回事

经常出现的Connection reset by peer: 原因可能是多方面的，不过更常见的原因是：①：服务器的并发连接数超过了其承载量，服务器会将其中一些连接Down掉；②：客户关掉了浏览器，而服务器还在给客户端发送数据；③：浏览器端按了Stop

"connection reset by peer"报错是什么意思？

connection reset by peer：连接被对方重设是服务器向客户传输数据时由于超负荷、网络中断、防火墙影响或未按规定关闭网络时导致的问题。 出现该错误，重启即可。要避免该错误，需要在程序退出前关闭所有网络。

具体含义

表明你在对一个对端socket已经关闭的的连接调用write或send方法，在这种情况下，调用write或send方法后，对端socket便会向本端socket发送一个RESET信号，在此之后如果继续执行write或send操作，就会得到错误描述为connection reset by peer。

状况原理

该java异常在客户端和服务器端都有可能发生，引起该异常的原因有两个：

1、如果一端的插座被关闭（或主动关闭，或因为异常退出而引起的关闭），另一端仍发送数据，发送的第一个数据包引发该异常（同级重置连接）。

2、一端退出，但退出时并未关闭该连接，另一端如果在从连接中读数据则抛出该异常（重新连接）。

原因分析

具体的分析可以结合TCP的"四次握手"关闭。TCP是全双工的信道，可以看作两条单工信道，TCP连接两端的两个端点各负责一条。当对端调用close时，虽然本意是关闭整个两条信道，但本端只是收到FIN包。按照TCP协议的语义， 表示对端只是关闭了其所负责的那一条单工信道，仍然可以继续接收数据。也就是说， 因为TCP协议的限制，一个端点无法获知对端的socket是调用了close还是shutdown。

对于一个TCP连接，如果对端执行close操作，则会向本端发送一个FIN分节，这时候读本端socket会返回0，我们就知道对方已经关闭了连接，通常这时候我们会在本地调用close来主动关闭本端连接。但如果对方socket已经执行了close的操作，本端socket还继续在这个连接上写数据，就会触发对端socket发送RST报文，按照TCP的四次握手原理，这时候本端socket应该也要开始执行close的操作流程了，而不是接着发数据。

Connection reset by peer的常见原因和解决方法：

1.服务器的并发连接数超过了其承载量，服务器会将其中一些连接关闭；如果知道实际连接服务器的并发客户数没有超过服务器的承载量，则有可能是中了病毒或者木马，引起网络流量异常。

解决方法：可以使用netstat -an命令查看网络连接情况。

2.客户关掉了浏览器，而服务器还在给客户端发送数据；

3.浏览器端按了Stop；这两种情况一般不会影响服务器。但是如果对异常信息没有特别处理，有可能在服务器的日志文件中，重复出现该异常，造成服务器日志文件过大，影响服务器的运行。

解决方法：对引起异常的部分，使用try...catch捕获该异常，然后不输出或者只输出一句提示信息，避免使用e.printStackTrace();输出全部异常信息。

4.防火墙的问题；如果网络连接通过防火墙，而防火墙一般都会有超时的机制，在网络连接长时间不传输数据时，会关闭这个TCP的会话，关闭后在读写，就会导致异常。

解决方法：如果关闭防火墙，解决了问题，需要重新配置防火墙，或者自己编写程序实现TCP的长连接。实现TCP的长连接，需要自己定义心跳协议，每隔一段时间，发送一次心跳协议，双方维持连接。

5.JSP的buffer问题。JSP页面缺省缓存为8k，当JSP页面数据比较大的时候，有可能JSP没有完全传递给浏览器。

解决方法：这时可以适当调整buffer的大小。

参考资料

CSDN：

多走一步：