• Connection reset by peer 全解

    知识铺垫

    疯狂创客圈 《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;

    后台报错：

    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高并发研习社群，为大家开启大厂之门
  • 相关阅读:
    Python-操作符与基本数据类型
    初识Python
    HDU 1166 敌兵布阵(线段树求sum)
    HDU 1754 I Hate It(线段树求max)
    HDU 1176 免费馅饼
    HDU 1466 计算直线的交点数
    HDU 1506 Largest Rectangle in a Histogram(最大矩形面积)
    AYOJ 单词接龙(搜索)
    AYOJ 传球游戏(递推)
    AYOJ 方格取数(多进程DP)
  • 原文地址：https://www.cnblogs.com/crazymakercircle/p/14001467.html
Copyright © 2020-2023  润新知