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

问题背景

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

 用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，就是最开始抓包那种情况。　　

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