精华内容
下载资源
问答
  • [261]Connection reset by peer的常见原因及解决办法

    万次阅读 多人点赞 2018-07-07 13:35:48
    1,如果一端的Socket被关闭(或主动关闭,或因为异常退出而 引起的关闭),另一端仍发送数据,...2,一端退出,但退出时并未关闭该连接,另一端如果在从连接中读数据则抛出该异常(Connection reset)。 简单的...

    1,如果一端的Socket被关闭(或主动关闭,或因为异常退出而 引起的关闭),另一端仍发送数据,发送的第一个数据包引发该异常(Connect reset by peer)。

    Socket默认连接60秒,60秒之内没有进行心跳交互,即读写数据,就会自动关闭连接。

    2,一端退出,但退出时并未关闭该连接,另一端如果在从连接中读数据则抛出该异常(Connection reset)。

    简单的说就是在连接断开后的读和写操作引起的。

    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的大小。

    第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(软件原因导致连接中断)

    参考:https://blog.csdn.net/candyguy242/article/details/25699727
    http://www.360doc.com/content/13/0722/10/11220452_301678390.shtml

    rabbitMQ连接断开问题

    猜测:pika客户端没有及时发送心跳,连接被server断开

    一开始修改了heartbeat_interval参数值, 示例如下:

    def test_main():
        s_conn = pika.BlockingConnection(
            pika.ConnectionParameters('127.0.0.1', 
                heartbeat_interval=10,
                socket_timeout=5,
                credentials=pika.PlainCredentials(USER, PWD)))
        # ....
    

    去看它的api,看到heartbeat_interval的解析:

    :param int heartbeat_interval: How often to send heartbeats.
                                      Min between this value and server's proposal
                                      will be used. Use 0 to deactivate heartbeats
                                      and None to accept server's proposal.
    

    按这样说法,应该还是没有把心跳值给设置好。上面的程序期望是10秒发一次心跳,但是理论上发送心跳的间隔会比10秒多一点。所以艾玛,我应该是把heartbeat_interval的作用搞错了, 它是指超过这个时间间隔不发心跳或不给server任何信息,server就会断开连接, 而不是说pika会按这个间隔来发心跳。 结果我把heartbeat_interval值设置高一点(比实际发送心跳/信息的间隔更长),比如上面设置成60秒,就正常运行了。

    如果不指定heartbeat_interval, 它默认为None, 意味着按rabbitMQ server的配置来检测心跳是否正常。
    如果设置heartbeat_interval=0, 意味着不检测心跳,server端将不会主动断开连接。但实际上设置heartbeat=0,并不起作用,这个心跳值时间间隔是由server端控制的,可以参考我的这篇文章就知道原因了,https://blog.csdn.net/xc_zhou/article/details/84033841。

    究竟该如何彻底解决,这个问题也困扰我了好久,下面给出解决方法

    import threading,time
    
    #开启一个线程,每隔20s,执行一次心跳
     def timesleep(n):
         for i in range(n):
             time.sleep(20)
             # heartbeat=0,意味着不检测心跳,server端将不会主动断开连接。但是并不起作用,
             # process_data_events 方法,类似 heartbeat 操作,可以保持与 rabbitmq 的通信。
             # 在执行长时间任务时,定时调用 process_data_events 方法,就不会丢失连接
             self.connection.process_data_events()
     message_thread = threading.Thread(target=timesleep, args=(3600*24,))
     message_thread.start()
    

    如还有问题,请看下篇文章,也许会帮到你

    pika missed heartbeats from client timeout 60s 的问题

    展开全文
  • Connection reset

    2020-12-28 14:05:28
    java.lang.RuntimeException: java.net.SocketException: Connection reset at org.czentral.util.stream.Feeder.feedTo(Feeder.java:78) at org.czentral.minirtmp.MiniRTMP$Worker.run(MiniRTMP.java:95) ...
  • Connection Reset

    2020-12-27 15:47:08
    java.net.SocketException: Connection reset" errors when accessing resources through the proxy. The problematic connections happen when running an "await e.Ok(System.Text.Encoding.UTF8.GetBytes...
  • ConnectionReset

    2015-02-05 10:48:00
    ConnectionReset The connection was reset by the remote peer. http://stackoverflow.com/questions/1434451/what-does-connection-reset-by-peer-mean It's fatal. The remote server has sent you a RST ....

    ConnectionReset The connection was reset by the remote peer.

     

    http://stackoverflow.com/questions/1434451/what-does-connection-reset-by-peer-mean

    It's fatal. The remote server has sent you a RST packet, which indicates an immediate dropping of the connection, rather than the usual handshake.

    This bypasses绕开 the normal half-closed state transition过渡,转变

    "Connection reset by peer" is the TCP/IP equivalent of slamming砰地关上;猛力抨击 the phone back on the hook. 
    It's more polite than merely仅仅 not replying, leaving one hanging. 
    But it's not the FIN-ACK expected of the truly polite TCP/IP converseur. 
     

    This can happen if the other side crashes and then comes back up,

     

    This means that a TCP RST was received and the connection is now closed.

    This occurs when a packet is sent from your end of the connection but the other end does not recognize the connection;

    it will send back a packet with the RST bit set in order to forcibly强制地 close the connection.

     

    This can happen if the other side crashes and then comes back up, or if it calls close() on the socket while there is data from you in transit运输,

    and is an indication to you that some of the data that you previously sent may not have been received.

     

    It is up to you whether that is an error;

    if the information you were sending was only for the benefit of the remote client then it may not matter that any final data may have been lost.

    However you should close the socket and free up any other resources associated with the connection.

     

    基础概念

    RST packet

    RST packet is sent either in the middle of the 3-way handshake when the server rejects the connection or is unavailable OR in the middle of data transfer when either the server or client becomes unavailble or rejects further communication without the formal 4-way TCP connection termination process.

     

     

    转载于:https://www.cnblogs.com/chucklu/p/4274192.html

    展开全文
  • ConnectionResetError: [Errno 54] Connection reset by peer' error, not quite sure why. I am using the Paper Trading API. Any help would be really appreciated</p><p>该提问来源于开源项目:...
  • connectionreseterror: [errno 104] connection reset by peer 也有可能单纯是要访问的网址写错了

    connectionreseterror: [errno 104] connection reset by peer

    也有可能单纯是要访问的网址写错了

    展开全文
  • Nginx: 104: Connection reset by peer 错误

    万次阅读 2019-04-08 15:27:00
    最近Nginx反向代理遇到了“104: Connection reset by peer”错误,google了一下,这里记录一下。 1 错误原因:检查链接是否已经close。 upstream发送了RST,将连接重置。 errno = 104错误表明你在对一个对端...

          最近Nginx反向代理遇到了“104: Connection reset by peer”错误,google了一下,这里记录一下。

    本文根据众多互联网博客内容整理后形成,引用内容的版权归原始作者所有,仅限于学习研究使用。

    1 错误原因:检查链接是否已经close。

           upstream发送了RST,将连接重置。

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

           如果对方socket已经执行了close的操作,本端socket还继续在这个连接上收发数据,就会触发对端socket发送RST报文。按照TCP的四次握手原理,这时候本端socket应该也要开始执行close的操作流程了,而不是接着收发数据。

    2 可能原因

    2.1 链接已经断开

         这个应该是最根本的原因。

    2.2 数据长度不一致

         发送端和接收端事先约定好的数据长度不一致导致的,接收端被通知要收的数据长度小于发送端实际要发送的数据长度。

    2.3 Nginx缓存小,timeout太小。

    nginx的buffer太小,timeout太小。

    nginx http模块添加以下参数配置:

    client_header_buffer_size 64k;
    large_client_header_buffers 4 64k;
    client_body_buffer_size 20m;
    fastcgi_buffer_size 128k;
    fastcgi_buffers 4 128k;
    fastcgi_busy_buffers_size 256k;
    gzip_buffers 16 8k;
    proxy_buffer_size 64k;
    proxy_buffers 4 128k;
    proxy_busy_buffers_size 256k;
    
    keepalive_timeout 240;
    fastcgi_connect_timeout 600;
    fastcgi_send_timeout 600;
    fastcgi_read_timeout 600;
    
    proxy_connect_timeout 600s;
    proxy_send_timeout 1200;
    proxy_read_timeout 1200;

    2.3 没有设置keepalive

          ngx_http_upstream_check_module这个模块,在使用tcp检测后端状态时,只进行了TCP的三次握手,没有主动断开这个连接,而是等待服务端来断开。当后端是nginx或者tomcat时(linux上),超时后后端会发fin包关闭这个连接。这个错误日志recv() failed (104: Connection reset by peer)是在后端为IIS的情况下抛出的,抓包发现IIS并不会发fin包来断开链接,而是在超时后发RST包重置连接,所以导致了这个问题。
          从这个问题也反应出ngx_http_upstream_check_module这个模块还是需要完善下检测机制的,如果是在检测后端状态后主动关闭这个连接,应该就不会出现connect reset这个问题

    通过修改源代码已经解决了该问题
    static ngx_check_conf_t ngx_check_types[] = {
    { NGX_HTTP_CHECK_TCP,
    ngx_string("tcp"),
    ngx_null_string,
    0,
    ngx_http_upstream_check_peek_handler,
    ngx_http_upstream_check_peek_handler,
    NULL,
    NULL,
    NULL,
    0,
    1 },

    将最后一行的1改为0即可,根据数据结构分析可得知,这个1代表启用keepalived,所以客户端才不会主动断开连接,因为这是tcp的端口连通性检查,不需要keepalived,将其改为0禁止keepalived即可。

    修改之后的代码如下:
    static ngx_check_conf_t ngx_check_types[] = {
    { NGX_HTTP_CHECK_TCP,
    ngx_string("tcp"),
    ngx_null_string,
    0,
    ngx_http_upstream_check_peek_handler,
    ngx_http_upstream_check_peek_handler,
    NULL,
    NULL,
    NULL,
    0,
    0 },

    2.4 设置lingering_close 

          即使你禁用了 http keepalive,nginx 仍然会尝试处理 HTTP 1.1 pipeline 的请求。你可以配置 
    lingering_close off 禁用此行为,但这不是推荐的做法,因为会违反 HTTP 协议。见 

         http://nginx.org/en/docs/http/ngx_http_core_module.html#lingering_close 

    3 nginx快速定位异常

    错误信息

    错误说明

    "upstream prematurely(过早的) closed connection"

    请求uri的时候出现的异常,是由于upstream还未返回应答给用户时用户断掉连接造成的,对系统没有影响,可以忽略

    "recv() failed (104: Connection reset by peer)"

    (1)服务器的并发连接数超过了其承载量,服务器会将其中一些连接Down掉; 

    (2)客户关掉了浏览器,而服务器还在给客户端发送数据; 

    (3)浏览器端按了Stop

    "(111: Connection refused) while connecting to upstream"

    用户在连接时,若遇到后端upstream挂掉或者不通,会收到该错误

    "(111: Connection refused) while reading response header from upstream"

    用户在连接成功后读取数据时,若遇到后端upstream挂掉或者不通,会收到该错误

    "(111: Connection refused) while sending request to upstream"

    Nginx和upstream连接成功后发送数据时,若遇到后端upstream挂掉或者不通,会收到该错误

    "(110: Connection timed out) while connecting to upstream"

    nginx连接后面的upstream时超时

    "(110: Connection timed out) while reading upstream"

    nginx读取来自upstream的响应时超时

     

    "(110: Connection timed out) while reading response header from upstream"

    nginx读取来自upstream的响应头时超时

    "(110: Connection timed out) while reading upstream"

    nginx读取来自upstream的响应时超时

    "(104: Connection reset by peer) while connecting to upstream"

    upstream发送了RST,将连接重置

    "upstream sent invalid header while reading response header from upstream"

    upstream发送的响应头无效

    "upstream sent no valid HTTP/1.0 header while reading response header from upstream"

    upstream发送的响应头无效

    "client intended to send too large body"

    用于设置允许接受的客户端请求内容的最大值,默认值是1M,client发送的body超过了设置值

    "reopening logs"

    用户发送kill  -USR1命令

    "gracefully shutting down",

    用户发送kill  -WINCH命令

    "no servers are inside upstream"

    upstream下未配置server

    "no live upstreams while connecting to upstream"

    upstream下的server全都挂了

    "SSL_do_handshake() failed"

    SSL握手失败

    "ngx_slab_alloc() failed: no memory in SSL session shared cache"

    ssl_session_cache大小不够等原因造成

    "could not add new SSL session to the session cache while SSL handshaking"

    ssl_session_cache大小不够等原因造成

     

    参考:

    https://github.com/alibaba/tengine/issues/901

    https://my.oschina.net/u/1024107/blog/1838968

    https://blog.csdn.net/zjk2752/article/details/21236725

    http://nginx.org/en/docs/http/ngx_http_core_module.html#lingering_close

    https://blog.csdn.net/crj121624/article/details/79956283

     

    请我喝咖啡

    如果觉得文章写得不错,能对你有帮助,可以扫描我的微信二维码请我喝咖啡哦~~哈哈~~

     

    展开全文
  • <div><p>After <code>tcp.read_coils()</code> function, when I run the command <code>tcp.send_message()</code> I get the error - <code>ConnectionResetError: [Errno 104] Connection reset by peer</code>....
  • <div><p>I've been disconnected a couple of times now, when I tried..., ConnectionResetError(104, 'Connection reset by peer'))</code></p>该提问来源于开源项目:michael-lazar/rtv</p></div>
  • ConnectionResetError

    2021-01-11 00:32:19
    2018-07-23 17:57:15 WARNING: Attempt 2 at connecting failed: ConnectionResetError: 2018-07-23 17:57:15 WARNING: Attempt 3 at connecting failed: ConnectionResetError: 2018-07-23 17:57:15 WARNING: ...
  • ConnectionResetError: [Errno 104] Connection reset by peer </code></pre> <h1>16 handled the ConnectionClosed exceptions, however streaming and writing Bitmex data has caused the following error ...
  • It serves quite well but I seldom found <code>ConnectionResetError(104, 'Connection reset by peer'))</code> in the log file. The complete error is: <pre><code> 2018-10-05 11:19:40,904 ERROR ...
  • <div><ul><li>huawei p20</li><li>Name: uiautomator2 ..., ConnectionResetError(104, 'Connection reset by peer'))</li></ul>该提问来源于开源项目:openatx/uiautomator2</p></div>
  • Connection reset by peer

    2021-01-04 07:07:56
    Sep 22 16:55:19 ssl-fe01 bud[1981]: client 0x1135e260 on frontend closed because: uv_read_start(client) cb returned -104 (connection reset by peer) Sep 22 16:55:40 ssl-fe01 bud[1981]: client 0x1135...
  • , ConnectionResetError(104, 'Connection reset by peer'))</code> randomly. I can't replicate it. What's the correct way to handle this? I'm not totally sure what it means– it seems...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 10,970
精华内容 4,388
关键字:

connectionreset