【TCP】Connection reset by peer 原因分析定位

无意中发现了一个巨牛的人工智能教程,忍不住分享一下给大家。教程不仅是零基础,通俗易懂,而且非常风趣幽默,像看小说一样!觉得太牛了,所以分享给大家。点这里可以跳转到教程。

背景

client和server通过websocket协议通信,长连接保活,server前有nginx做反向代理,client和server是多对多关系;

server端定时给client下发任务,client执行任务并将结果上报给server,client还会定时给server发送心跳保活连接。

现象

系统运行一段时间之后,nginx上error日志频繁报错,如下:

2020/04/15 18:02:51 [error] 374#0: *1917238 send() failed (104: Connection reset by peer) while proxying upgraded connection, client: 172.28.25.222, server: localhost, request: "GET /ws/358/5c5d8dafac7f4586a751ff4c68fb2999/websocket HTTP/1.1", upstream: "http://172.28.72.77:8899/ws/358/5c5d8dafac7f4586a751ff4c68fb2999/websocket", host: "172.28.72.114:8443"
2020/04/15 18:03:03 [error] 374#0: *1913375 send() failed (104: Connection reset by peer) while proxying upgraded connection, client: 172.28.25.214, server: localhost, request: "GET /ws/453/60c9a5af41374f9dbaad4d5444d25c96/websocket HTTP/1.1", upstream: "http://172.28.72.77:8888/ws/453/60c9a5af41374f9dbaad4d5444d25c96/websocket", host: "172.28.72.114:8443"

nginx端频繁重置连接,导致连接不可用,通信异常

分析

抓包

119是client,117是nginx

从图中看出client给服务端发送了很多 tcp zero window的包,说明客户端已经处理不过来了,告诉对端,不要给我发包了,我不行了;

同时,服务端会定期给客户端发送tcp keepalive链路保活的包,在发送多次zero window后仍然没有有效数据发送,服务端RESET关闭连接,导致服务异常;

在服务器netstat发现如下现象:

client客户端

[apprun@vhost18 ~]$ netstat -tnulpao|grep 443
tcp6  362708      0 172.28.72.119:63132     172.28.72.117:443       ESTABLISHED 32278/java           off (0.00/0/0)
tcp6       0      0 172.28.72.119:63192     172.28.72.117:443       ESTABLISHED 32278/java           off (0.00/0/0)

nginx server服务端

[apprun@newvhost02 ~]$ netstat -anop|grep 443
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      13307/nginx: worker  off (0.00/0/0)
tcp        0 108528 172.28.72.117:443       172.28.72.119:63132     ESTABLISHED 13308/nginx: worker  probe (0.16/0/0)

客户端recev-Q阻塞,表明客户端处理不过来,操作系统接收缓冲区阻塞,程序没有及时消费掉;

nginx服务端send-Q阻塞,不能及时发出去,表明下游程序收不过来,和上述客户端现象表现一致;

同时客户端的系统资源也很充裕,没有任何瓶颈。

解决

查看客户端处理代码逻辑,发现单线程处理,效率低下,改成异步线程池提交处理的方式,问题解决。

总结

linux操作系统的上述三个参数,跟此次现象有关:

net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 5

tcp_keepalive_time,在TCP保活打开的情况下,最后一次数据交换到TCP发送第一个保活探测消息的时间,即允许的持续空闲时间。默认值为7200s(2h)。

tcp_keepalive_intvl,保活探测消息的发送频率。默认值为75s。

发送频率tcp_keepalive_intvl乘以发送次数tcp_keepalive_probes,就得到了从开始探测直到放弃探测确定连接断开的时间,大约为11min。

tcp_keepalive_probes,TCP发送保活探测消息以确定连接是否已断开的次数。默认值为9(次)。

 

从上述抓包和操作系统三个参数配置,并没有通过包和操作系统参数值对应上,当时环境存在多个client和多个server,抓包数量有限,但是综合情况来看RESET应该是跟这三个操作系统参数有关,但本质原因还是客户端处理不过来,导致数据积压,TCP零窗口。

 

©️2020 CSDN 皮肤主题: 酷酷鲨 设计师:CSDN官方博客 返回首页