TCP连接的建立与backlog参数

1.问题描述

产品在启动的时候会建立driver和simulator之间（driver用以驱动simulator的行为以及相互传递信息）的TCP连接用以通信，而当开始跑业务的时候应用层立即抛出“connection lost”的错误，没法再继续跑业务。该问题同样是出现在产品RHEL版本从6.7升级到7.5后出现的。

起初发现该问题所在的环境是A，driver和simulator的部署如图1所示，两者之间连接关系是N:N，可是该问题在A上只能低概率出现。后来在环境B上则可以较高概率地出现，而问题复现的条件也一直没有摸索出来。环境A和B都是RHEL7.5的系统。

                                                                                                         图1

2.分析

我们尝试使用tshark工具抓取client端（driver）和server端（simulator）之间的数据包，也许我们可以看到他们它们怎样断开连接的，是谁先断开的等信息。以Server 1上的sim上的数据包为例，发现有多次TCP Retransmission以及Dup ACK，在开始跑业务的时候server给client端发送了RST消息，这会直接断掉连接；后来发现由于软件应用层的实现，之后driver client将会发送FIN消息给另外两个相连的simulator来断开连接，以图2中为例：

                                                                                                           图2

我们debug调试时发现在软件启动后在这些出现问题的连接中，仅仅有driver侧提示TCP连接建立成功（即gen_tcp:connect/3返回{ok, Socket}），而simulator侧并没有这样的提示。

根据数据包中的表现找到一篇文章：TCP/IP协议中backlog参数。

我们在simulator侧的代码中的listen函数找到了backlog参数（5），而其第一个参数是socket的file description；而Linux中对此参数的系统配置值是2048，调整这里的配置是没有效果的。增大listen函数的参数后的确解决了这个问题。

所以是因为accpt queue队列长度过小，服务端没有足够的能力去监听一定规模的连接请求，导致在TCP三次握手时有一部分TCP连接没有被放入全连接队列中（客户端的ACK消息相当于没有到达服务端），那么这些连接自始至终都没有被建立好，而作为客户端，gen_tcp:connect/3的执行是无法感知这一状况的。

3.思考

• 为何升级到RHEL7.5上时出现此问题？

我们没有寻求RHEL support的帮助，但根据Paul所说，大概是RHEL7.5上监听TCP连接建立将使用更长的时间片，而如果在该时间片内出现了上述的情况，系统也无法做出什么处理，系统只会继续处理下一个时间片（包含从连接请求池中获取的下一批），而这些连接请求将会永久“搁浅”。

• 为何环境A和环境B的表现不一致？

在两个环境中复现此问题的概率有较大差别，我们想这可能是因为A有28个核心来部署driver和simulator，而B有40个，考虑到部署策略，更多的核心数意味着系统在短时间内需要处理更多的TCP连接请求，而若依然使用RHEL6.7上的参数是有可能出现问题的。

4.更进一步

其实，在应用层上也可以引入一个略有改善的方案：TCP连接请求重发。在一定时间内如果TCP连接没有一次性建立成功，可以重新发送请求，当该请求被放入新的时间片中被重新处理时，应该是可以保证其被成功处理的。

不过严格说来这会降低效率，并且不是一个万全的方法。