Connection reset by peer (秒懂)
疯狂创客圈 经典图书 : 《Netty Zookeeper Redis 高并发实战》 面试必备 + 面试必备 + 面试必备 【博客园总入口 】
疯狂创客圈 经典图书 : 《SpringCloud、Nginx高并发核心编程》 大厂必备 + 大厂必备 + 大厂必备 【博客园总入口 】
入大厂+涨工资必备: 高并发【 亿级流量IM实战】 实战系列 【 SpringCloud Nginx秒杀】 实战系列 【博客园总入口 】
知识铺垫
疯狂创客圈 《SpringCloud Nginx 高并发核心编程》Java 工程师/ 架构师 必备【链接 】
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;
后台报错:
排查:
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/79956283
回到◀疯狂创客圈▶
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
回到◀疯狂创客圈▶
Connection reset by peer (秒懂)相关推荐
- Tomcat:Connection reset by peer: socket write error
Connection reset by peer: socket write error错误分析及解决 Connection reset by peer: socket write error错误分析 ...
- connection reset by peer问题总结及解决方案
找遍了 中英文网站,翻遍了能找的角落,发现了出现故障的原因和原理,及改如何处理,这里记录下,希望能帮助到有需要的小伙伴,少走点弯路, 以上就整理内容: connection reset by peer ...
- Connection reset by peer原理解析
"Connection reset by peer"代表什么? "Connection reset by peer"表示当前服务器接受到了通信对端发送的TCP ...
- 【Nignx】 nginx启动http服务,报错 curl: (56) Recv failure: Connection reset by peer
背景 docker 启动的nginx 服务,容器内端口80,映射到容器外8080,通过 curl -L -I http://xxxx:8080 报错 curl: (56) Recv failure: ...
- fatal: unable to access ‘‘: TCP connection reset by peer
fatal: unable to access '': TCP connection reset by peer 3.20有用按照 只对github.com git config --global h ...
- 阿里云ECS——Linux连接错误[Read from socket failed: Connection reset by peer]解决方案
问题描述 改变了系统权限 chmod 777 -R /后,SSH连接错误[Read from socket failed: Connection reset by peer]. 主要是改变了/etc/ ...
- ab apr_socket_recv: Connection reset by peer 错误解决
来源:http://blog.csdn.net/largetalk/article/details/7337102 在ubuntu 11.04上的ab(apache-utils)有些问题, 在并发数稍 ...
- CentOS7: How to resolve curl#56 - Recv failure: Connection reset by peer
注意这个问题报错显示也可以是: curl:(56)Recv failure:连接被对方重设 Issue: When you execute Yum installation or update, yo ...
- ES报错:Connection reset by peer 解决经历
http://nicethemes.cn/news/txtlist_i28391v.html 这次来分享一下ES报错:java.io.IOException: Connection reset by ...
最新文章
- 特殊用户邮箱附件大小设置
- centos 7 samba 回收站
- C++ string详解
- 如何通过其他主机查看Apahce服务器的运行状态
- CCIE-LAB-SDN-第三篇-SD-WAN
- 汉诺塔计算移动次数和消耗体力
- 软件测试--接口流程化测试
- sql server 事务_SQL Server事务概述
- amd u盘安装linux mint,安装Linux Mint 20后需要做的13件事
- 字节跳动自研重度游戏;中国移动前董事长谈飞信失败;Linux 5.3-rc3 发布 | 极客头条...
- ASP.NET取用户浏览器IP地址等信息
- java 博客系统 tale_Java 博客系统 Tale
- 聚类——层次聚类(Hierarchical Clustering)
- [论文笔记]DistilBERT, a distilled version of BERT: smaller, faster, cheaper and lighter
- 【渝粤题库】广东开放大学 管理会计 形成性考核
- 5 python 页面说明_Python爬虫爬取网易云的音乐
- golang批量修改文件名称
- MySQL数据库高级SQL语句【进阶查询、null值、数据库正则、数据库运算符、连接查询(内连接、左外连接、右外连接)】
- 开水果店的水果怎么保鲜,新手开水果店水果保鲜方法
- A40I工控主板(SBC-X40I)CAN接口测试