nginx android app 慢网络请求超时

最近遇到了android 在慢网络下面请求服务器报

java.net.SocketException: recvfrom failed: ECONNRESET (Connection reset by peer)java.net.SocketTimeoutException: failed to connect to mobile2.itanzi.com/120.27.142.146 (port 80) after 15000msjava.net.SocketTimeoutException: timeoutjava.net.UnknownHostException: Unable to resolve host "mobile2.itanzi.com": No address associated with hostname

而ios 不存在这个问题，一直没有搞懂什么原因，总以为是android 的原因

netstat -an |grep 'ESTABLISHED' |grep 'tcp' |wc -l243

一个 tcp_tw_recycle ，为了支持高并发，开启了这个，也就是tcp请求回收，如果开了这个，那在默认60s内同一个ip包过来是会被回收的，而游戏网络很多都是经过多层代理网络的，代理网络过来的数据包的时间肯定是小于这个请求时间的，那么服务器就会认为他是无效的连接，就会拒绝连接，所以才会出现TCP包重传，基于实践是检查理论的唯一标准，那就试着改吧

vim /etc/sysctl.confnet.ipv4.tcp_tw_reuse = 0net.ipv4.tcp_tw_recycle = 0

网上查了一下：

tcp_tw_reuse、tcp_tw_recycle 使用场景及注意事项

linux TIME_WAIT 相关参数:

net.ipv4.tcp_tw_reuse = 0    表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭net.ipv4.tcp_tw_recycle = 0  表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭net.ipv4.tcp_fin_timeout = 60  表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间（可改为30，一般来说FIN-WAIT-2的连接也极少）

注意：

- 不像Windows 可以修改注册表修改2MSL 的值，linux 是没有办法修改MSL的，tcp_fin_timeout 不是2MSL 而是Fin-WAIT-2状态.

- tcp_tw_reuse 和SO_REUSEADDR 是两个完全不同的东西

1. tw_reuse，tw_recycle 必须在客户端和服务端timestamps 开启时才管用（默认打开）

2. tw_reuse只对客户端起作用，开启后客户端在1s内回收

3. tw_recycle 对客户端和服务器同时起作用，开启后在3.5*RTO 内回收，RTO 200ms~ 120s 具体时间视网络状况。

　　内网状况比tw_reuse 稍快，公网尤其移动网络大多要比tw_reuse 慢，优点就是能够回收服务端的TIME_WAIT数量

对于客户端

1. 作为客户端因为有端口65535问题，TIME_OUT过多直接影响处理能力，打开tw_reuse 即可解决，不建议同时打开tw_recycle，帮助不大。

2.tw_reuse 帮助客户端1s完成连接回收，基本可实现单机6w/s请求，需要再高就增加IP数量吧。

3. 如果内网压测场景，且客户端不需要接收连接，同时tw_recycle 会有一点点好处。

4. 业务上也可以设计由服务端主动关闭连接

对于服务端

1. 打开tw_reuse无效

2. 线上环境tw_recycle不要打开

服务器处于NAT 负载后，或者客户端处于NAT后（这是一定的事情，基本公司家庭网络都走NAT）；

　公网服务打开就可能造成部分连接失败，内网的话到时可以视情况打开；

像我所在公司对外服务都放在负载后面，负载会把timestamp 都给清空，好吧，就算你打开也不起作用。

3. 服务器TIME_WAIT高怎么办

不像客户端有端口限制，处理大量TIME_WAIT Linux已经优化很好了，每个处于TIME_WAIT 状态下连接内存消耗很少，

而且也能通过tcp_max_tw_buckets =262144配置最大上限，现代机器一般也不缺这点内存。

下面像我们一台每秒峰值1w请求的http 短连接服务，长期处于tw_buckets 溢出状态，

tw_socket_TCP 占用70M, 因为业务简单服务占用CPU 200% 运行很稳定。

对于客户端

对于服务端

更多相关文章

随机推荐