Connection reset by peer 全解

文章很长,而且持续更新,建议收藏起来,慢慢读!疯狂创客圈总目录 语雀版 | 总目录 码云版| 总目录 博客园版 为您奉上珍贵的学习资源 :


推荐:入大厂 、做架构、大力提升Java 内功 的 精彩博文

入大厂 、做架构、大力提升Java 内功 必备的精彩博文 秋招涨薪1W + 必备的精彩博文
1:Redis 分布式锁 (图解-秒懂-史上最全) 2:Zookeeper 分布式锁 (图解-秒懂-史上最全)
3: Redis与MySQL双写一致性如何保证? (面试必备) 4: 面试必备:秒杀超卖 解决方案 (史上最全)
5:面试必备之:Reactor模式 6: 10分钟看懂, Java NIO 底层原理
7:TCP/IP(图解+秒懂+史上最全) 8:Feign原理 (图解)
9:DNS图解(秒懂 + 史上最全 + 高薪必备) 10:CDN图解(秒懂 + 史上最全 + 高薪必备)
11: 分布式事务( 图解 + 史上最全 + 吐血推荐 ) 12:限流:计数器、漏桶、令牌桶
三大算法的原理与实战(图解+史上最全)
13:架构必看:12306抢票系统亿级流量架构
(图解+秒懂+史上最全)
14:seata AT模式实战(图解+秒懂+史上最全)
15:seata 源码解读(图解+秒懂+史上最全) 16:seata TCC模式实战(图解+秒懂+史上最全)

SpringCloud 微服务 精彩博文
nacos 实战(史上最全) sentinel (史上最全+入门教程)
SpringCloud gateway (史上最全) 分库分表sharding-jdbc底层原理与实操(史上最全,5W字长文,吐血推荐)

推荐:尼恩Java面试宝典(持续更新 + 史上最全 + 面试必备)具体详情,请点击此链接

尼恩Java面试宝典,32个最新pdf,含2000多页不断更新、持续迭代 具体详情,请点击此链接

在这里插入图片描述


1错误信息

Connection reset by peer

nginx的错误日志中会出现

Connection reset by peer) while reading response header from upstream, client: 1.1.1.1, server: 102.local, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000

日志查看方法

这个错误是在nginx的错误日志中发现的,为了更全面的掌握nginx运行的异常,强烈建议在nginx的全局配置中增加

error_log   logs/error.log notice;

这样,就可以记录nginx的详细异常信息。

2 原因一:连接已经被上游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的操作流程了,而不是接着收发数据。

  • 比如,当后端为php程序时,如果php运行较慢,并超出php-fpm.conf的request_terminate_timeout设置的秒数。request_terminate_timeout用于设置当某个php脚本运行最长时间,若超出php-fpm进程管理器强行中止当前程序,并关闭fastcgi和nginx的网络连接,然后nginx中就会出现Connection reset by peer的错误了。

也就是说,产生这个错误的原因是:php 程序的运行时间超出request_terminate_timeout设置的值。

在php-fpm环境下,在php的安装目录的etc/php-fpm.conf中有此值的设置项,可将其设置为0或更大的值。这样将php的request_terminate_timeout设置为较大的值或0,可减少因php脚本执行时行过长导致nginx产生Connection reset by peer错误。

  • 比如,当后端为java 程序时

java 的也类似,不能Java端主动关闭连接。 如果上游的tomcat 或者 netty 已经关闭连接, 那么nginx 肯定就是 Connection reset by peer

3 原因二:数据长度不一致

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

4 原因三: FastCGI 缓存小,timeout太小。

nginx的buffer太小,timeout太小。主要指php的环境,nginx如果要解析php脚本语言,就必须通过配置fastcgi模块来提供对php支持。

问题概述:图片bit 64生成数据流太大,导致小程序分享弹窗的二维码图片生成失败

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

fastcgi_buffer_size 128k;

fastcgi_buffers 4 128k;

fastcgi_busy_buffers_size 128k;

fastcgi_temp_file_write_size 128k;

后台报错:

img

排查:

Client------>nginx------->h5------>nginx---------->client

客户端通过h5的nginx页面点击,nginx反向代理到h5 [无异常]

h5通过客户端请求调取相应接口 [无异常]

接口返回数据通过nginx展示给客户端 [异常]

Ps: 图片通过bit 64解析生成返回给客户端,由于数据长度太长导致

解决方法:

调整nginx配置文件参数,修改后参数:

fastcgi_buffer_size 256k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;

先简单的说一下 Nginx 的 buffer 机制,对于来自 FastCGI Server 的 Response,Nginx 将其缓冲到内存中,然后依次发送到客户端浏览器。缓冲区的大小由 fastcgi_buffers 和 fastcgi_buffer_size 两个值控制。

比如如下配置:

fastcgi_buffers      8 4K;
fastcgi_buffer_size  4K;

fastcgi_buffers 控制 nginx 最多创建 8 个大小为 4K 的缓冲区,而 fastcgi_buffer_size 则是处理 Response 时第一个缓冲区的大小,不包含在前者中。所以总计能创建的最大内存缓冲区大小是 84K+4K = 36k。而这些缓冲区是根据实际的 Response 大小动态生成的,并不是一次性创建的。比如一个 8K 的页面,Nginx 会创建 24K 共 2 个 buffers。

当 Response 小于等于 36k 时,所有数据当然全部在内存中处理。如果 Response 大于 36k 呢?fastcgi_temp 的作用就在于此。多出来的数据会被临时写入到文件中,放在这个目录下面。同时你会在 error.log 中看到一条类似 warning。

显然,缓冲区设置的太小的话,Nginx 会频繁读写硬盘,对性能有很大的影响,但也不是越大越好,没意义,呵呵!

FastCGI缓冲设置主要参数

fastcgi_buffers 4 64k

这个参数指定了从FastCGI进程到来的应答,本地将用多少和多大的缓冲区读取,假设一个PHP或JAVA脚本所产生页面大小为256kb,那么会为其分配4个64kb的缓冲来缓存;若页面大于256kb,那么大于256kb的部分会缓存到fastcgi_temp指定路径中,这并非是个好办法,内存数据处理快于硬盘,一般该值应该为站点中PHP或JAVA脚本所产生页面大小中间值,如果站点大部分脚本所产生的页面大小为256kb,那么可把值设置为16 16k,4 64k等。

fastcgi_buffer_size=64k

读取fastcgi应答第一部分需要多大缓冲区,该值表示使用1个64kb的缓冲区读取应答第一部分(应答头),可以设置为fastcgi_buffers选项缓冲区大小。

fastcgi_connect_timeout=300

连接到后端fastcgi超时时间,单位秒,下同。

fastcgi_send_timeout=300

向fastcgi请求超时时间(这个指定值已经完成两次握手后向fastcgi传送请求的超时时间)

fastcgi_reAd_timeout=300

接收fastcgi应答超时时间,同理也是2次握手后。

5 原因四: proxy_buffer缓存小

原因就是请求的头文件过大导致502错误

解决方法就是提高头部的缓存

http{

client_header_buffer_size 5m;

 

location / {

  proxy_buffer_size 128k;
  proxy_busy_buffers_size 192k;
  proxy_buffers 4 192k;

  }

}


原因五:没有设置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 },

原因六:设置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

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/79956283t/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

回到◀疯狂创客圈

疯狂创客圈 - Java高并发研习社群,为大家开启大厂之门

posted @ 2020-11-18 18:35  疯狂创客圈  阅读(12148)  评论(0编辑  收藏  举报