netty新建连接并发数很小的case

双12之前的一个case，现在分享下，这个case的现象是当这个应用每秒新建40多个连接的时候，就会经常连接不上，这个应用时是基于netty的，按照我对netty的理解，这不太可能发生，可以来看看这个case解决的那个弯曲，总共折腾了4天，搞的这么弯曲和我有很大关系。

这个应用的背景先简单说一下，是一个提供给手机访问的应用，手机端app和这个应用时采用长连的方式，通讯这层是基于netty。

当时有同学给我反馈这个现象后，就登录到机器上看了看，按照以往经验，通常来说，新建连接并发数支撑的不够大有可能是两原因： 
1. 应用在netty建连接的过程中做了耗时的事； 
因此我先dump了应用的线程，看到一切正常，boss线程看起来非常空闲；

2. backlog太小； 
首先问了下开发代码里有没有设置过backlog，开发告诉我没设置过，于是我翻了下netty的源码确认下默认值，看到backlog的默认值为读取自系统的/proc/sys/net/core/somaxconn，于是查了下系统的这个值，确认系统的这个值已经是调整过的，设置为了2048，然后确认了系统上的tcp_max_syn_backlog是4096，也就是最后work的会是2048（为什么是这样具体可见 这篇文章 ），也就是说应该是够的。

用ss -s观察连接的状况，看到的是synrecv是0，也印证了上面的不是backlog的问题。

到这一步就彻底傻眼了，不知道该用什么方法排查了，于是开始一堆的google，看到的各种说解决新建连接并发低的解决办法，除了调整backlog外，主要是以下两种： 
1 关闭tcp_tw_recycle，尝试了（话说这里充分体现了”病急乱投医“的心态，其实我自己都不相信改这参数有用，但想着只是改下参数这种小代价的事，还是试试吧），没任何作用； 
2 关闭window scaling ，也尝试了，一样没任何作用；

查到这个阶段觉得自己已经无法理解了，于是求助了厂内内核团队对网络这块比较精通的同学，然后又求助了“神”，“神“帮忙看了会后，说主要的问题是现在是每epollWait唤醒一次，只建了一个连接，这导致在大量新建连接请求并发的时候，效率不够高，因此我翻了下代码，发现我本机上看到的代码不是这样的，我本机上看到的netty代码在epollWait唤醒后，是会尝试一直去accept的，但这个应用使用的netty确实不是这样，于是查了下应用的jar包库，发现里面有两个版本的netty（一个是3.2.1.Final，一个是3.6.3.Final），3.2.1确实是每次epollWait后就处理一个，于是通知开发同学把3.2.1去掉，满心期待的认为应该是好了，等开发更新好了后，自己也确认了一次epollWait唤醒后会连续处理很多个建立连接的请求，但悲催的还是没解决问题，具体的netty在这块的改造感兴趣的同学可以看看NioServerSocketPipelineSink这个类（重点看select唤醒后）…

到这步，就彻底郁闷了，话说其实到这步的时候我已经被这个问题困扰了2天多了，于是只好继续google，发现又有提到打开syn cookies的建议，于是尝试了下，竟然真的work了，打开了这个参数后新建连接的并发请求轻松超过100+了。

到此以为已经解决了，但很快开发给我反馈，整个集群开启了这个参数后，连接确实是能建上了，但客户端出现了发了请求后，等不到任何响应的现象，当时还不确定服务器端到底有没有收到请求，于是只好又先关闭了这个参数（话说这个我到现在都不明白为什么这个参数打开后，会出现发请求没响应的现象，求高人解答）。

尽管还是没解决，但毕竟有进展，有的进展就是打开了syn cookies后连接就能建上，而syn cookies只有在backlog满了后才会生效，那也就是说还是backlog满了，从kern的日志也能确认syn cookies确实是work了，到这步就觉得诡异了，明明netty用的默认值就是somaxconn，而每秒新建40多个连接，且boss线程还很空闲的情况下显然不应该出现backlog满的现象，这个时候仔细看了下本机查看的netty代码，才发现我看的是netty 4的代码，而应用用的是netty 3.6.3，悲催，赶紧把netty 3.6.3的代码捞下来看了，才发现在3.6.3里backlog的默认值处理时不一样的，在3.6.3里默认值是50，不是netty写的默认值，是java本身，50那估计真的不一定够，于是就通知开发在代码里先强制设置下backlog为1000。

在开发改代码的过程中，还有一个怀疑点想确认，就是既然是backlog满了，为什么看到的synrecv会是0呢，于是再用netstat -na | grep [port] | grep SYN_RECV -c统计了下，结果发现值基本一直是64，java层面默认设置的是50，linux会将这个值调整为大于这个值的2的n次幂的值，那也就是64，好吧，看到这就彻底可以确定真的是因为backlog太小了造成的（只是话说我不明白为什么ss -s统计出来的synrecv会是0呢，求高人解答）。

等开发改完代码重新发布后，稍微增加了点引流测试了下，轻松支撑每秒200+，客户端建立连接后发请求获取响应也完全ok，问题到此宣告解决。

题外话: 这应用之所以会比较容易出现较多的synrecv，主要是因为手机网络通常是不太稳定的，另外一个原因是这种对外的都很容易带来攻击，而当时刚好这个应用前面的一个用来防syn flood的由于有bug临时关闭了，所以问题暴露的比较明显。

从这个折腾了4天的case的排查过程，大家可以看到其实如果一开始我仔细确认过应用用的netty版本和我本机看的代码是不一致的话，估计很快就会排查出原因就是backlog值太小造成的，所以说折腾了这么多天其实也是自己造成的，这个告诉自己，以后排查问题的时候一定要对出现问题的应用所在的环境更加清楚的确认。

ps: 最后再多啰嗦几句，从这个case还能看到的是netty的版本其实在细节上是一直在改进的，就像这个case里的不同版本的netty在处理连接事件唤醒上，还有backlog的默认值上，所以我一直很强调，对于需要存活很多年的软件而言，选择一个使用范围较广的开源软件是非常重要的，如果自己开发，也许短期能超越，但放到三年、五年这样的范围来看，通常是很难和开源软件去抗衡的（原因是商业公司没多少人会专注在一个领域做三五年的，而开源界这样的人实在是多，说实话，这种case看过太多），所以如果觉得你能做的比开源软件好，还不如去帮助已有的（当然，如果这个领域目前完全没有什么使用面较广的、靠谱的，那自己做一个开源是挺好的），软件的可持续发展能力（除非是一次性软件、做的玩的或就玩个一两年的）是非常非常重要的。