-
疯狂创客圈 经典图书 : 《Netty Zookeeper Redis 高并发实战》 面试必备 + 面试必备 + 面试必备 【博客园总入口 】
-
疯狂创客圈 经典图书 : 《SpringCloud、Nginx高并发核心编程》 大厂必备 + 大厂必备 + 大厂必备 【博客园总入口 】
-
入大厂+涨工资必备: 高并发【 亿级流量IM实战】 实战系列 【 SpringCloud Nginx秒杀】 实战系列 【博客园总入口 】
知识铺垫
疯狂创客圈 《SpringCloud Nginx 高并发核心编程》Java 工程师/ 架构师 必备【链接 】
1错误信息
Connection reset by peer
nginx的错误日志中会出现
1 | 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的全局配置中增加
1 | 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模块添加以下参数配置:
1 2 3 4 5 6 7 | 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配置文件参数,修改后参数:
1 2 3 4 | 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 两个值控制。
比如如下配置:
1 2 | 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错误
解决方法就是提高头部的缓存
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | 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这个问题
通过修改源代码已经解决了该问题
1 2 3 4 5 6 7 8 9 10 11 12 | 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即可。
修改之后的代码如下:
1 2 3 4 5 6 7 8 9 10 11 12 | 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
回到?疯狂创客圈?
t/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高并发研习社群,为大家开启大厂之门