Connection reset by peer问题分析

  1. extremetable导出excel,弹出一个下载窗口,这时不点下载而点取消,则报下面的异常:
  2. ClientAbortException Caused by: java.net.SocketException: Connection reset by peer: socket write error
  3. 查了下TOMCAT的文档,解释如下:
  4. Wrap an IOException identifying it as being caused by an abort of a request by a remote client.
  5. 在BAIDU和GOOGLE上找了下原因,大概归结为:
  6. ClientAbortException: java.net.SocketException: Connection reset by peer: socket write error的原因是由于处理http连接时,正在输出内容时,用户关闭了IE,会出现一个"ClientAbortException",属于I/O处理中出现的一个异常,应用服务器应该会捕捉。
  7. Connection reset by peer的原因:
  8. 经常出现的Connection reset by peer: 原因可能是多方面的,不过更常见的原因是:
  9. ①:服务器的并发连接数超过了其承载量,服务器会将其中一些连接Down掉;
  10. ②:客户关掉了浏览器,而服务器还在给客户端发送数据;
  11. ③:浏览器端按了Stop
  12. 很多人都说是客户端造成的,没有办法控制,是个比较郁闷的问题。
  13. 但是,我担心的是:虽然前台没有任何出错的迹象,但是后台会记录这个异常,日志也会疯狂爆满,时间长了,肯定会DOWN掉的,还没找到好的解决办法
  14. resin有一个参数ignore-client-disconnect
  15. tomcat似乎没有
  16. 经常出现的Connection reset by peer: 原因可能是多方面的,不过更常见的原因是:①:服务器的并发连接数超过了其承载量,服务器会将其中一些连接Down掉;②:客户关掉了浏览器,而服务器还在给客户端发送数据;③:浏览器端按了Stop
  17. [10054] Connection reset by peer
  18.   Connection reset by peer is a tough one because it can be caused by so many things. In all cases, the server determines that the socket is no longer good and closes it from its side.
  19.   Read Error
  20.   Scenario: Mary couldn‘t make out what Joe was saying anymore, so she hung up rather than lose his messages (data).
  21.   A read error occurs when a server cannot successfully read from a user‘s client. Servers gather information from the client by text, setup, and other items.When the server receives an error when reading from a client, it then disconnects the user, resulting in a read error quit message.
  22.   Write Error
  23.   Scenario: Mary was trying to talk to Joe but didn‘t think she was getting through, so she hung rather than lose his messages (data).
  24.   A write error occurs when a server cannot successfully write to a user‘s client. When the server receives information, it usually responds with information of its own. When the server receives an error when writing to a client, it then disconnects the user, resulting in a write error quit message similar to the read error format.
  25.   Ping Timeout Error
  26.   Scenario: Mary, having been raised in a household with too many kids and always craving attention, keeps asking to make sure that Joe is still on the line and listening. If he doesn‘t reply fast enough to suit her, she hangs up.
  27.   Servers automatically ping users at a preset time. The reason for this is to ensure the client is still connected to the server. When you see "PING? PONG!" results in your status window, it means the server has pinged your client, and it has responded back with a pong to ensure the server that you are still connected. When this does not happen and you disconnect without the server‘s knowledge, the server will automatically disconnect the user when it does not receive a response, resulting in a ping timeout. Ping timeouts occur to EVERYONE.
  28.   Broken pipe Error
  29.   Scenario: Mary had picked up a sticky note with a message she needed to relay to Joe, but somehow between her hand and her mouth, the message got misplaced. Mary was trying to talk to Joe but didn‘t think she was getting through, so she hung up rather than lose his messages (data).
  30.   A broken pipe error occurs when the server knows it has a message but can‘t seem to use its internal data link to get the data out to the socket.
  31.   Miscellaneous
  32.   Scenario: Lots of other reasons; perhaps the operator broke in and gave Mary a message that made her doubt the validity of the call so she hung up

我在做pdf导出的时候针对大的文件下载过程中点关闭或下载前点取消按钮会报以上错误;先记录下来

Java代码

  1. 1,一般是有些客户端已关闭,一些线程因为延迟等原因觉察不到此连接已结束,继续等到到出错
  2. 2,客户端那里不停刷或一个访问/刷新没完成前再刷,要让这个无用的线程死掉
  3. 3,这个问题一般是客户端在连接还没有完全建立的时候就取消连接,比如用户按了浏览器上面的“停止”按钮,一般来说没有什么问题。但是如果频繁出现,就表示很多客户端连接到Apache服务器的响应时间太长了,可能是网络的问题或者服务器性能问题。
  4. 4, 这个问题一般是客户端在连接还没有完全建立的时候就取消连接,比如用户按了浏览器上面的“停止”按钮,一般来说没有什么问题。但是如果频繁出现,就表示很多客户端连接到Apache服务器的响应时间太长了,可能是网络的问题或者服务器性能问题
  5. 5,可能你的网络连接存在一些问题,你的数据传输的时候,可能由于时间等待的太久,但是server段设置的连接检验时间限制一定,那么就可能出现这种情况的!
  6. 6,不过更常见的原因是:
  7. 1:服务器的并发连接数超过了其承载量,服务器会将其中一些连接Down掉;
  8. 2:客户关掉了浏览器,而服务器还在给客户端发送数据;
  9. 3:浏览器端按了Stop;
  10. 4:服务器给客户端响应结果给防火墙拦截了。
  11. 7,我又查了一些资料,原因如下:
  12. 非程序问题,一般是由于与客户端连接中断所致,没有太有效的办法解决。但是可以通过系统调优等手段提高系统吞吐量,减少部分因延迟而中断的连接。
  13. 一般免费的Web Server,如Tomcat对长期积累的IO错误解决不完善,会导致迟缓,甚至挡掉。所以,如果你的网站(或系统)访问量较大或至少又一段时间集中访问量大,一定要留意这个问题,因为它可能会使你的系统停滞。
  14. 建议:1、提高系统性能 2、有条件的话换用商业WebServer如weblogic

第1个异常是java.net.BindException:Address already in use: JVM_Bind。该异常发生在服务器端进行new ServerSocket(port)(port是一个0,65536的整型值)操作时。异常的原因是以为与port一样的一个端口已经被启动,并进行监听。此时用netstat –an命令,可以看到一个Listending状态的端口。只需要找一个没有被占用的端口就能解决这个问题。

第2个异常是java.net.ConnectException: Connection refused: connect。该异常发生在客户端进行new Socket(ip, port)
操作时,该异常发生的原因是或者具有ip地址的机器不能找到(也就是说从当前机器不存在到指定ip路由),或者是该ip存在,但找不到指定的端口进行监
听。出现该问题,首先检查客户端的ip和port是否写错了,如果正确则从客户端ping一下服务器看是否能ping通,如果能ping通(服务服务器端
把ping禁掉则需要另外的办法),则看在服务器端的监听指定端口的程序是否启动,这个肯定能解决这个问题。

第3个异常是java.net.SocketException: Socket is closed,该异常在客户端和服务器均可能发生。异常的原因是己方主动关闭了连接后(调用了Socket的close方法)再对网络连接进行读写操作。

第4个异常是java.net.SocketException: (Connection reset或者Connect reset by peer:Socket write error)。该异常在客户端和服务器端均有可能发生,引起该异常的原因有两个,第一个就是如果一端的Socket被关闭(或主动关闭或者因为异常退出而引起的关闭),另一端仍发送数据,发送的第一个数据包引发该异常(Connect reset by peer)。另一个是一端退出,但退出时并未关闭该连接,另一端如果在从连接中读数据则抛出该异常(Connection reset)。简单的说就是在连接断开后的读和写操作引起的。

第5个异常是java.net.SocketException: Broken pipe。该异常在客户端和服务器均有可能发生。在第4个异常的第一种情况中(也就是抛出SocketExcepton:Connect reset by peer:Socket write error后),如果再继续写数据则抛出该异常。前两个异常的解决方法是首先确保程序退出前关闭所有的网络连接,其次是要检测对方的关闭连接操作,发现对方关闭连接后自己也要关闭该连接。
http://bbs.csdn.net/topics/340021801
http://www.jb51.net/article/34888.htm


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的大小。 <%@ page buffer="100k"%>

常见网络异常(转自http://www.cnblogs.com/kaixin110/archive/2008/04/11/1148671.html):

第1个异常是java.net.BindException:Address already in use: JVM_Bind。该异常发生在服务器端进行new ServerSocket

(port)(port是一个0,65536的整型值)操作时。异常的原因是以为与port一样的一个端口已经被启动,并进行监听。此时用

netstat –an命令,可以看到一个Listending状态的端口。只需要找一个没有被占用的端口就能解决这个问题。

第2个异常是java.net.ConnectException: Connection refused: connect。该异常发生在客户端进行 new Socket(ip, port)

操作时,该异常发生的原因是或者具有ip地址的机器不能找到(也就是说从当前机器不存在到指定ip路由),或者是该ip存在

,但找不到指定的端口进行监听。出现该问题,首先检查客户端的ip和port是否写错了,如果正确则从客户端ping一下服务器

看是否能 ping通,如果能ping通(服务服务器端把ping禁掉则需要另外的办法),则看在服务器端的监听指定端口的程序是否

启动,这个肯定能解决这个问题。

第3个异常是java.net.SocketException: Socket is closed,该异常在客户端和服务器均可能发生。异常的原因是己方主动关

闭了连接后(调用了Socket的close方法)再对网络连接进行读写操作。

第4个异常是java.net.SocketException: (Connection reset或者 Connect reset by peer:Socket write error)。该异常

在客户端和服务器端均有可能发生,引起该异常的原因有两个,第一个就是如果一端的Socket被关闭(或主动关闭或者因为异

常退出而引起的关闭),另一端仍发送数据,发送的第一个数据包引发该异常 (Connect reset by peer)。另一个是一端退出

,但退出时并未关闭该连接,另一端如果在从连接中读数据则抛出该异常(Connection reset)。简单的说就是在连接断开后

的读和写操作引起的。

第5个异常是java.net.SocketException: Broken pipe。该异常在客户端和服务器均有可能发生。在第4个异常的第一种情况中

(也就是抛出SocketExcepton:Connect reset by peer:Socket write error后),如果再继续写数据则抛出该异常。前两个异

常的解决方法是首先确保程序退出前关闭所有的网络连接,其次是要检测对方的关闭连接操作,发现对方关闭连接后自己也要

关闭该连接。

客户端错误代码10053 Software caused connection abort(软件原因导致连接中断)

 
时间: 2024-08-04 09:57:52

Connection reset by peer问题分析的相关文章

connection reset by peer, socket write error问题分析

上次写<connection reset by peer, socket write error问题排查>已经过去大半年,当时把问题"敷衍"过去了. 但是此后每隔一段时间就会又想起来,baidu.google一番,可能也会再拉周围的人小讨论一下,然后无果而终.淡忘,想起,淡忘,又想起,挥之不去. 这个周末它又在脑海中浮现,这次总算理解了这个问题,答案就在一本买了很久的新书<HTTP权威指南>中.如果懒得看下面的啰嗦,可以去直接看书中的<4.7.4 正常关闭

ECS云主机SSH连接提示&ldquo;Connection reset by peer&rdquo;的解决办法和解决思路

三周前刚从上家公司换到新的公司,这家公司与上家公司相比对阿里云的云计算环境更加的依赖,使用的ECS实例和其他服务如SLB.RDS.OSS等更多了一个数量级.这篇文章的背景就是为了解决阿里云ECS云主机SSH连接的一个问题,从故障发现到故障排除到最后反思的一个详细过程.文章比较长,图片众多,建议有时间仔细阅读,没时间就阅读文末的"总结和反思"部分即可. 故障发现: 2017-05-23 下午17:00点前同事报告称GitLab所在的服务器访问出现异常.经查发现在公司内无法正常通过SSH连

CentOS7使用ssh不能登录,报错:Read from socket failed: Connection reset by peer

使用xshell登录CentOS7,不能登录,使用另外一台Linux主机,telent 22端口是同的,ssh连接报以下错误: Read from socket failed: Connection reset by peer 查看不能登录主机的日志 # cat /var/log/messages Dec 15 19:38:27 localhost dbus-daemon: dbus[874]: [system] Successfully activated service 'org.freed

recv() failed (104: Connection reset by peer) while reading response header from upstream

场景: 为了得到用户在线等信息,在客户端做了个ajax轮训: 于是问题就来了, 日志文件 [[email protected] web]# tail -f /data/log/nginx_error.log 2017/06/16 19:20:28 [error] 230555#0: *10228041 recv() failed (104: Connection reset by peer) while reading response header from upstream,client:

Android通过Http协议POST请求异常(Connection reset by peer)

上周遇到了一个Connection reset by peer 网络连接问题,为此,我找遍了中英文的一些网站,搜遍了能找的每个角落,发现了出现这种状况的原理,该java异常在客户端和服务器端都有可能发生,引起该异常的原因有: Connection reset by peer的常见原因: 1)服务器的并发连接数超过了其承载量,服务器会将其中一些连接关闭: 如果知道实际连接服务器的并发客户数没有超过服务器的承载量,则有可能是中了病毒或者木马,引起网络流量异常.可以使用netstat -an查看网络连

nginx错误分析 `104: Connection reset by peer`

故障描述 应用从虚拟机环境迁移到kubernetes环境中,有些应用不定时出现请求失败的情况,且应用没有记录任何日志,而在NGINX中记录502错误.我们查看了之前虚拟机中的访问情况,没有发现该问题. 基础信息 # 请求流程 client --> nginx(nginx-ingress-controller) --> tomcat(容器) # nginx版本 $ nginx -V nginx version: nginx/1.15.5 built by gcc 8.2.0 (Debian 8.

ssh远程报错ssh_exchange_identification: read: Connection reset by peer

ssh远程登录报错: [[email protected] ~]$ ssh     198.44.241.34 ssh_exchange_identification: read: Connection reset by peer 初步原因锁定: 1-服务器防火墙限定, 2-是否达到ssh的最大连接数,超过之后会服务器端会拒绝新的连接,直到有新的连接释放出来 3-/etc/hosts.allow和/etc/hosts.deny配置文件限定ip登录 解决方案: 1 firewall-cmd --l

Connection reset by peer 的常见原因:

Connection reset by peer的常见原因: 1)服务器的并发连接数超过了其承载量,服务器会将其中一些连接关闭: 如果知道实际连接服务器的并发客户数没有超过服务器的承载量,则有可能是中了病毒或者木马,引起网络流量异常.可以使用netstat -an查看网络连接情况. 2)客户关掉了浏览器,而服务器还在给客户端发送数据: 3)浏览器端按了Stop: 这两种情况一般不会影响服务器.但是如果对异常信息没有特别处理,有可能在服务器的日志文件中,重复出现该异常,造成服务器日志文件过大,影响

CentOS7 yum的一次报错&quot; 14: curl#56 - &quot;Recv failure: Connection reset by peer&quot; &quot;

1.故障现象 [[email protected] src]# yum update Loaded plugins: fastestmirror, langpacks Could not retrieve mirrorlist   7&arch=x86_64&repo=os&infra=stock error was 14: curl#56 - "Recv failure: Connection reset by peer" One of the configu