求助：linux下socket编程的backlog参数的问题【已解决】

hritian

原帖由 jiufei19 于 2009-7-3 17:37 发表
感谢hritian提醒，我又仔细观察了linux下backlog值和连接数目的关系，得到如下结论：

1、我是在服务器端抓的包

2、的确服务器是发送的syn+ack，不是syn。

3、当backlog为1时，完全正确3次握手的数目是 ...

我很奇怪，如果是服务器端要拒绝的话，应该是用reset，你的现象的问题是，没有收到客户端发送的ack包呀，这个不太对。


我造过这样一个网络情况，

服务器端发送了相隔XXms后又发送了一次syn+ack包，客户端回了。

[ 本帖最后由 hritian 于 2009-7-7 16:54 编辑 ]

nikeboysj

我们也碰到了类似的问题,当把backlog设为1时,后面的连接再也连接不上,抓包后,发现Server端不停的在发SYNC+ACK,而Client也一直在回ACK.
比较奇怪的是,LINUX的实现为何当未完成连接数目超过backlog后要回SYNC+ACK呢,而不是直接RESET掉呢?

aga-cn

我刚才又看了看TCP IP卷一的内容，楼主显然没有仔细的看完书中的内容，书中有说在不同的OS中实现有所有不同“Figure 18.23 shows the relationship between the backlog value and the real maximum number of queued connections allowed by traditional Berkeley systems and Solaris 2.2.” 书中有提到在BSD的实现中这个值永远比实际值要大一些。而且还有一点需要注意，书中还有一段这样的描述“Keep in mind that this backlog value specifies only the maximum number of queued connections for one listening end point, all of which have already been accepted by TCP and are waiting to be accepted by the application. This backlog has no effect whatsoever on the maximum number of established connections allowed by the system, or on the number of clients that a concurrent server can handle concurrently.” 也就是说这个值仅仅是一个TCP Server的队列值，不是TCP的队列值，修改这个值不影响系统中可以接受的并发的最大连接数。所以在DEBUG的过程中一定要注意这点)

jiufei19

回复 1# jiufei19

时隔这个帖子发出时间有2年了，当时因为还没有看到socket层面的源码，所以出现了这个帖子的问题，到今天我才看到reqsk_queue_alloc这个函数，而该函数中的如下代码基本说明了这个帖子的问题，在此贴出来，对2年前的问题做个了断。

  57     for (lopt->max_qlen_log = 3;
   58          (1 << lopt->max_qlen_log) < nr_table_entries;
   59          lopt->max_qlen_log++);

显然，这个syn queue队列的最小值的2的对数为3，即最小可以允许有8个syn被接收。
   

LEIHAOCS

回复 14# jiufei19
楼主真给力


   

316953425

回复 14# jiufei19


没明白楼主什么意思，怎么解决了服务器一致发syn ack的问题啊？

   

316953425

回复 15# LEIHAOCS
你明白楼主是什么意思了吗？
能给解释一下吗？


   

lx281

jiufei19 发表于 2012-06-03 15:40
回复 1# jiufei19

时隔这个帖子发出时间有2年了，当时因为还没有看到socket层面的源码，所以出现了这个 ...

我也看了源码，确实这段代码是这样的，但是我在centos6.5上测试发现，实际上排队等待accept的连接数是backlog + 1，有牛人能解惑的么

superheizai

楼主是好人，2年前的贴依然去结。大家关心的，为啥一直会返回sync+ack回去，我发现了答案。
在建连结束队列满的情况下，又有client发送ack回来的时候，tcp直接会把ack包丢掉。但是呢，这个处于sync_received状态的server端会一直等待ack回来(实际情况是，回来的ack包会被它一直丢弃)，有可能是因为它返回的sync+ack丢掉了，所以他会不停的返回sync+ack包回client端。重试次数的限制通过/proc/sys/net/ipv4/tcp_synack_retries设定。
资料参考如下：http://veithen.github.io/2014/01 ... works-in-linux.html