ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

接口访问服务器的网络超时问题记录

2022-06-27 21:01:57  阅读:231  来源: 互联网

标签:网关 jmeter tw tcp 接口 服务器 超时


问题背景

最近大家测试环境偶尔会遇到服务器访问超时的问题,如下图:

 用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性能提升,默认开启
注:其中tcp time_wait依赖tcp_tw_recycle,开启tcp_tw_recycle会启用tcp time_wait的快速回收,这个参数不建议在NAT环境中启用,它会引起相关问题。

这下现象对上了,于是修改参数:

echo "0" > /proc/sys/net/ipv4/tcp_tw_recycle      --临时关闭tcp,重启后失效 

再查看下连接情况。

 暂时没有了,后面持续观察,该问题基本解决,实际原因为(参考文章):

很多公司都用LVS做负载均衡,通常是前面一台LVS,后面多台后端服务器,这其实就是NAT,当请求到达LVS后,它修改地址数据后便转发给后端服务器,但不会修改时间戳数据,对于后端服务器来说,请求的源地址就是LVS的地址,加上web端口会复用,所以从后端服务器的角度看,原本不同客户端的请求经过LVS的转发,就可能会被认为是同一个连接,加之不同客户端的时间可能不一致,所以就会出现时间戳错乱的现象,于是后面的数据包就被丢弃了,具体的表现通常是是客户端明明发送的SYN,但服务端就是不响应ACK,就是最开始抓包那种情况。  

明明之前有猜到的,但心里没底,绕了一大圈又回到了原地。还是对基础不扎实啊,后面得好好补补!

标签:网关,jmeter,tw,tcp,接口,服务器,超时
来源: https://www.cnblogs.com/qgc1995/p/16372752.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有