接口访问服务器的网络超时问题记录
2022-06-27 20:51 第二个卿老师 阅读(896) 评论(0) 编辑 收藏 举报问题背景
最近大家测试环境偶尔会遇到服务器访问超时的问题,如下图:
用f12查看如下,服务端没有响应:
排除本地浏览器问题,我使用jmeter请求试试,巧的是还能重现,虽然时间不固定,如下
报错内容为连接超时,后面才知道这个报错是java应用的TCP连接超时错误,跟服务器使用什么语言没关系,而jmeter就是java写的。
------------------------------------------------------------------------------
于是按照常规解题思路,结合服务端架构,大概梳理网络请求链路。
客户端——>域名解析——>Nginx服务器——>zuul网关服务——>服务A——其他组件
按照链路一步步定位问题。(由于网络基础不扎实,着实绕了一些弯路,记录如下)
第一步
是域名解析问题吗?应该不是,域名解析只是个中介商,换个目的地的IP地址而已,而且请求大部分也是ok,几率不大,pass
第二步
是nginx服务器吗?直接查看日志/var/log/nginx/access.log与error.log,都没有报错信息。可能没有打印,再深入看看。
第三步
是zuul网关服务器吗?查看服务网关日志,不会也没打印吧!是的也没有打印。。。
那就奇怪了,难道网络请求没有到zuul网关。
第四步
都没有日志,难道是linux服务器的问题,记得之前压测调过内核参数,在/etc/sysctl.conf文件增加过下面三行参数。
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
是之前改动配置的影响吗?先还原去除试试,sysctl -p生效,再使用jmeter调用下,不过还是有超时请求。
第五步
难道是业务服务改动引起的吗?服务器这边没动,只能怀疑到业务服务上来了,记得后端最近修改了网关的验签,是不是网关拦截器出问题了。
于是让开发还原网关服务的改动,再试试,然并卵。。。(这时像个无头苍蝇)
第六步
难道是网络波动导致,试试内网测试,于是使用内网调用服务,一样走nginx,结果没遇到超时,如下图:
运维这边也怀疑是网络问题,所以为什么外网访问会偶尔出现超时呢?还是必现的!重要的是必现,我不信网络延时这么不稳定,而且之前也没出现过,继续搞!!!
终极方法
害,本来对网络这块不太熟,看来只能使用终极方案抓包了,既然jmeter有超时,那我就来抓包看看,下一个wairshark,变学边弄。
几番捕捉下来,发现客户端发出一个syn链接后,服务端没有响应,客户端还接连发了几个包,都没有响应,如下
时间也和jmeter的请求日志对得上,那么意思就是tcp握手都没建立好,所以jmeter就报连接超时了。
有线索后,百度了下,发现又回到之前的服务器tcp连接配置了,有文章说:使用命令查看netstat -s | grep reject,结果如下
发现被拒绝的连接一直在增加,也和抓包的现象一致。
cat /proc/sys/net//ipv4/tcp_tw_recycle --表示tcp连接中time_wait sockets的快速回收,centos7默认开启为1,修改为0则关闭 cat /proc/sys/net//ipv4/tcp_timestamps --主要用于tcp连接中RTT(Round Trip Time)的计算,有利于tcp性能提升,默认开启
这下现象对上了,于是修改参数:
echo "0" > /proc/sys/net/ipv4/tcp_tw_recycle --临时关闭tcp,重启后失效
再查看下连接情况。
暂时没有了,后面持续观察,该问题基本解决,实际原因为(参考文章):
很多公司都用LVS做负载均衡,通常是前面一台LVS,后面多台后端服务器,这其实就是NAT,当请求到达LVS后,它修改地址数据后便转发给后端服务器,但不会修改时间戳数据,对于后端服务器来说,请求的源地址就是LVS的地址,加上web端口会复用,所以从后端服务器的角度看,原本不同客户端的请求经过LVS的转发,就可能会被认为是同一个连接,加之不同客户端的时间可能不一致,所以就会出现时间戳错乱的现象,于是后面的数据包就被丢弃了,具体的表现通常是是客户端明明发送的SYN,但服务端就是不响应ACK,就是最开始抓包那种情况。
明明之前有猜到的,但心里没底,绕了一大圈又回到了原地。还是对基础不扎实啊,后面得好好补补!