最近发现公司的app在高峰期超时严重.用wifi网络一直超时,但qq等却正常.换成手机卡网络正常.
起初以为是DNS解析问题.
后来抓包,发现DNS解析正常,可以得到正确的A记录.
但tcp retransmission严重.
因为app内使用了友盟等第三方库,他们的DNS,tcp握手均正常.
而我们的app却tcp retransmission严重.
后来找到一篇文章,照着修改了服务器配置...超时少了.
下面是转发文章内容
内网有一台APP服务器,接口是通过Nginx发布的。手机通过无线登陆APP，有时候提示连接超时。
无线路由器和APP服务器，是通过内网交换机连接的。应该不会超时啊，可能是路由器问题。
然后换了好几个路由器，小米mini,华硕RT-AC87U,TP-LINK WVR1750G
咨询厂商，测试了一下，当时超时的时候，访问百度视频什么的是正常的。路由器没有问题，可能是服务器问题。因为服务器是pc机主机，配置比较差，后来换成DELL R620，还是同样的问题。
因为公司周围有30几个无线，2.4G传输速度是450M,可能是无线干扰问题。
最后买了一个Nighthawk X6 R8000，2.4G传输速度是600M，发现还是有超时。
网上搜索资料nginx超时问题，优化了一些参数，发现还是有超时。
手机安装（Ping & DNS）软件，版本是2.3，用TCP Ping持续测试dts.xx.com，
大约1~2分钟，提示connection timed out，超时会持续一分钟。出现超时的时候，手机登陆APP，就会提示连接超时。
然后超时的时候，在服务器抓包
[root@localhost ~]#tcpdump -i eth0 -s0 -w a.cap
发现无线路由器向服务器发送了SYN请求包，但是没有得到服务器回应。
出现TCP Retransmission(TCP 包重传)
因为服务器开启了tcp_tw_recycle(为了支持高并发)
tcp请求回收，如果开了这个，那在默认60s内同一个ip包过来是会被回收的
网络过来的数据包的时间肯定是小于这个请求时间的，那么服务器就会认为他是无效的连接，就会拒绝连接，所以才会出现TCP包重传。
所以才会出现上面的现象，超时持续一分钟。
后来我把tcp_tw_recycle关了
vi /etc/sysctl.conf
设置为0，表示关闭
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_tw_recycle = 0
加载配置
[root@localhost ~]#sysctl -p
最后再次用TCP Ping测试，测试20分钟，没有出现连接超时。
APP刷新数据，也没有出现超时。
哎，解决这个问题，之前都是靠瞎猜的。分析问题没有层层刨析，搞了这么长时间，才搞定。
路由器只提供数据转发功能，只要转发了，它的任务就完成了。
应该是服务器问题，然后抓包，为什么服务器没有回应?
为什么出现TCP Retransmission(TCP 包重传)?
这样问题就越来越接近真相了，就好解决了，就好像福尔摩斯一样。
后来发现系统日志出现
Jun 19 11:13:45 127.0.0.1TCP: time wait bucket table overflow
那就只能增加net.ipv4.tcp_max_tw_buckets的值
net.ipv4.tcp_max_tw_buckets = 100000
加载配置
