connection reset by peer,Netty 出现 Connection reset by peer 异常的几个原因

connection reset by peer,Netty 出现 Connection reset by peer 异常的几个原因详细介绍

本文目录一览： 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：http://blog.csdn.net/alibo2008/article/details/45694845
多走一步：http://www.cnblogs.com/kaixin110/archive/2008/04/11/1148671.html

Connection reset by peer是什么意思

Connection
reset
by
peer
连接复位同行
例句
But
this
clock
can
be
reset
by
light.
但是这个钟可以被光重置。

Connection reset by peer 这是怎么回事

Connection reset by peer的意思是连接复位。
例句
1
Every connection that you make to the network is stamped with your IP address.
你每次连接到网络都会留下你的IP地址。
2
When you pick the database option, the next screen requests your connection information.
当选定数据库选项时，接下来的屏幕要求提供连接信息。
3
The RETAIN RATLC Bridge automates the connection between the two tracking systems'respective change requests.
RETAIN RATLC Bridge将两个追踪系统的各自变更请求之间的连接自动化。
4
Figure1 illustrates the connection from Business Events to Monitor using the message queue connector.
图1显示了使用消息队列连接器建立的从Business Events到Monitor的连接。
　　经常出现的Connection reset by peer: 原因可能是多方面的，不过更常见的原因是：①：服务器的并发连接数超过了其承载量，服务器会将其中一些连接Down掉；②：客户关掉了浏览器，而服务器还在给客户端发送数据；③：浏览器端按了Stop

【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

https://docs.oracle.com/javase/1.5.0/docs/guide/net/articles/connection_release.html

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

https://my.oschina.net/xionghui/blog/508758

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

http://lovestblog.cn/blog/2014/05/20/tcp-broken-pipe

对TCP重传的进一步认识

http://blog.sina.com.cn/s/blog_4d276ac901011ee7.html

https://www.cnblogs.com/YXBLOGXYY/p/14243259.html

Netty 出现 Connection reset by peer 异常的几个原因

最近使用 netty 过程中发现了几个比较细节的 Connection reset by peer 异常，做个笔记。

这个场景出现在用 Jedis ping 检测的场景，用完直接 close，服务端稳定出现 Connection reset by peer。

tcpdump 一下就很容易定位到问题所在，客户端收到 PONG 响应后直接发了一个 RST 包给服务端：

查看 Jedis 的源码发现 socket 有个比较特殊的配置 socket.setSoLinger(true, 0) 。

先看一下 man7/socket.7 的解释：

坦白说不是很明白啥意思。。。

最终在 stackoverflow 上找到一个比较容易理解的解释：

简而言之，设置 SO_LINGER(0) 可以不进行四次挥手直接关闭 TCP 连接，在协议交互上就是直接发 RST 包，这样的好处是可以避免长时间处于 TIME_WAIT 状态，当然 TIME_WAIT 存在也是有原因的，大部分评论都不建议这样配置。

这个场景有点儿微妙，首先得理解一下 tcp 的两个队列。

这篇文章讲得比较清楚： SYN packet handling in the wild

accept 队列满通常是由于 netty boss 线程处理慢，特别是在容器化之后，服务刚启动的时候很容易出现 CPU 受限。

为了模拟这个现象，我写了个示例程序 shichaoyuan/netty-backlog-test ，设置 SO_BACKLOG 为 1，并且在 accept 第一个连接后设置 autoRead 为 false，也就是让 boss 线程不再继续 accept 连接。

启动第一个 Client，可以正常连接，发送 PING，接收 PONG。

启动第二个 Client，也可以正常连接，但是没有收到 PONG：

可见这个连接创建成功了，已经在 Accept Queue 里了，但是进程没有 accept，所以没有与进程绑定。

启动第三个 Client，也可以正常连接，也没有收到 PONG：

与第二个连接一样。

启动第四个 Client，也可以正常连接，但是在发送 PING 后出现 Connection reset by peer：

这个连接在服务端并没有进入 accept queue，处于 SYN_RECV 状态，并且很快就消失了（因为 accept queue 已经满了，无法转入 ESTABLISHED 状态）。

抓包看一下：

从客户端视角来看连接确实是建成功了，有一个比较特殊的地方在三次握手之后，服务端又向客户端发送了一个 [S.]，客户端回复了一个 [.]，这个交互看起来不影响连接。

服务端后来销毁了连接，而客户端还认为连接是 ESTABLISHED 的，发送 PING 消息，服务端自然得回复一个 RST。

PS：我在 Windows 10 的 WSL2 中实验这种场景是建连接超时，可能不同的操作系统或 linux 版本对这个交互的过程处理不同，在此不进行进一步测试了。

以上，这个故事告诉我们判断连接是否可用，建成功之后应该发个心跳包测试一下。

网络连接错误[10054][10054：Connection reset by peer] 是什么意思

你中了sougua的病毒，这个流氓软件具备自动升级功能
看你有没有这个服务c:\windows\system32\svchost.exe
-k
bits32
这个服务在后台定期升级sogua的工具条,非常可恶.禁用该服务,然后重新启动后干掉之,删除服务可以使用微软的windows
service
install/remove
wizard.
在检查c:\windows\system32下,发现两个可以的dll文件:
sqq32.dll
和
qmgr32.dll
在安全模式再干掉这两个文件,现在应该差不多了吧
连接被重置：Connection reset by peer
出现这个现象可能是：
1.服务器的并发连接数超过了其承载量，服务器会将其中一些连接Down掉，你的就在down掉的氛围内；
2.你关掉了一些程序，而服务器还在给客户端发送数据；

FTP上传网页时提示错误： Connection reset by peer为什么？怎么解决呢 ？

①、可能是连接数达到了最大,无法进行连接.
②、可能是此网站的登陆需要使用用户名和密码,不支持匿名登陆!
③、或者是对方防火墙级别设置过高,阻止了你的连接!
出现如此提示的话，你的上传是失败的，这是由于你的同一个ftp帐户在同时有两人或多人用它登陆这一ftp服务器导致的，只要不要同时登陆一般就没事了。

如何解决connection reset by peer

Problem Description: Error: "-27780: read to host failed: [10054] Connection reset by peer"
The user gets the following error messages during replay of a Web script:
"Error -27780: read to host

failed: [10054] Connection reset by peer"

"Error -27790: Failed to read data from server

"

Diagnosis: The client sends a POST request to the server and gets a response with HTTP status 200, connection close and redirection using both JS code and meta-refresh. There is no content-length, so the client is supposed to decide when to close the connection. Internet Explorer closes the connection before sending the request to the redirection URL. But, LoadRunner does not; later the server closes the connection, and the result is the error message.

--------------------------------------------------------------------------------

Solution: Use web_set_sockets_option ("CLOSE_KEEPALIVE_CONNECTIONS", "1")

Add the following step after the POST step:

web_set_sockets_option("CLOSE_KEEPALIVE_CONNECTIONS", "1");

This step closes all the open connections, and as a result, LoadRunner stops waiting for the rest of the response of the redirection.

答案其实一样，打开socket后记得关。

如何解决：druid-connection reset by peer：socket write error

同一个地址，每次只能使用一个连接，你创建了一个连接，获取到了以后判断是否null，只要这一步完成，连接的资源又被释放回连接池，你没有sleep，直接再回去获取，也是获取到一个的啦，因为再你获取新的一个连接资源的时候上一次的已经被释放回去

如何解决connection reset by peer

1、问题描述：
客户端每隔30秒被服务端断开连接，报错java.io
.IOException: Connection reset by peer，导致短信提交异常，服务端连接数不断增加
2、问题分析：
查看应用程序发现连接无异常程序报错导致连接断开，查看激活测试消息发现，客户端发送激活测试消息，服务端收不到，分析可能存在激活测试消息丢失导致服务端主动断开连接，查看服务器sysctl.conf网络配置无问题，进一步分析使用外网不走lvs集群部署的服务端进行测试，能收到激活测试消息不会断开连接，使用生产lvs集群部署的cmpp服务端应用每隔30秒都会主动断开，分析可能为lvs配置导致激活测试消息收不到，查看lvs配置，发现默认配置了tcp_timeout = 10 tcpfin_timeout = 10，导致每30秒发送的激活测试消息连接超时收不到
3、问题处理：
修改lvs配置tcp_timeout = 10 tcpfin_timeout = 10去掉这2个参数，问题解决