net.ipv4.tcp_tw_recycle 与 网络连接失败

最近从公司内网使用线上应用，很多同事都反映时断时连的，抓包看不时会有连接失败的情况（奇怪的是总是卡住约11秒），但其实最终是会成功的，但由于客户端的超时都是10秒，所以表现出来的就是总是服务不可用，出了公司用4G之类的，就没有这个问题了。

在此之前为了解决HA服务器曾有大量TIME_WAIT的总是，我曾改过一些内核参数，不过在发现上述总是后，我都用注释或修改回原值的方式将改过的值恢复了，但总是依旧，MESSAGES里也没有任何报错，这样断断续续查了两天也没找到问题在哪。

晚上静下心来又查了一下关于SYSCTL的内容，发现确实还是与改过的值 net.ipv4.tcp_tw_recycle有关，由于在恢复设置时，我对这个值是用注释“恢复”的，所以其实并没有起作用，真正让其生效，还是要把其设置为0。

简单说，就是这个参数与LINUX内核的TIMESTAMP联合生效，导致内核会要求同源的请求必须TIMESTAMP递增，否则就会丢包。而由于我司可能有不同的设备同时访问线上服务，各个设备不同的TIMESTAMP就不可能是递增的，才导致了网络连接失败的情况(至于为什么是11秒，估计和建立连接及关闭连接的超时时间有关，明天再去试试)。

其实搜搜有很多人遇到过这一问题，但由于误以为注释掉就是改掉了，就没再向这个方向想，在查询资料时由于着急，也对很多知识一知半解才踩了坑。

在创业公司这一年真是挺锻炼人的，因为要考虑各种问题，也要在做事的同时不断的充实自己，压力还是山大的。所以决定还是重新开始写博客，把遇到的问题和了解的新知都记录下来，烂笔头总是有用的。

参考文章：

http://blog.csdn.net/caianye/article/details/38540867

http://www.cnblogs.com/lulu/p/4149312.html

更新一下，这个参数也并不是没用。

后来HA上的TW并不算太严重，但随着最近访问压力的增大，后端的NGINX上的TW问题反而凸显了再来，甚至导致HA认为无可用后端而报出了503错误，经过一番折腾，最终还是用 net.ipv4.tcp_tw_recycle 参数给解决了，为什么又通用了呢？因为作为入口的HA服务器，接受的是来自真实用户的请求，此时由于客户端情况的不同，会引发上面说到的问题，所以这个参数是很危险的。而对于作为内网中使用的服务器，所有可用资源都是有独立IP的服务器，所以不会出现同一服务器的请求TIMESTAMP不同的情况，所以就是安全的。通过打开RECYCLE参数，业务中对各资源（MYSQL,REDIS）的TIME_WAIT被及时回收，系统状态立即恢复了正常。

一直没解决这个问题的原因：

1，网上的解决方案鱼龙混杂，其实很多都是一知半解，并且可能使用场景完全不同，再或是他们自己也没发现隐藏的问题，在不了解原理的情况下，盲目跟风还是不行的。

2，另一个概念也一直没有明确：网络请求会占用服务器的端口，无论是收到的请求，还是发出的请求。我一直以为是HA到后端的请求占了端口，但实际绝大多数端口是被业务逻辑占用的。基础知识还是关键啊。