Linux Kernel 2.6，listen(5)，永不 accept，到底能建立成功多少个连接？

yecheng_110

Linux ubuntu 2.6.22-14-generic #1 SMP Tue Feb 12 02:46:46 UTC 2008 x86_64 GNU/Linux

netstat -nat | grep EST | grep 9999 | awk '$4=="127.0.0.1:9999"' |wc -l
一直是6
completed connection queue的长度应该是6
netstat -nat | grep SYN_RECV | grep 9999 | awk '$4=="127.0.0.1:9999"' |wc -l
这个最大是16
incomplete connection queue的长度可能是16
而且隔一段时间会变少然后再增加到16
这个时间应该就是a timeout of 75 seconds

netstat -nat | grep 9999 | awk '$5=="127.0.0.1:9999"'|wc -l
这个和第二段的代码保持一致的增加 比第二段代码的输出多1
就是多SYN_SENT这行

上一贴是unp上摘抄的内容
这是对照着的实验 应该和理论是吻合的

[ 本帖最后由 yecheng_110 于 2008-9-2 22:25 编辑 ]

cugb_cat

原帖由 yecheng_110 于 2008-9-2 21:34 发表
To understand the backlog argument, we must realize that for a given listening socket, the kernel maintains two queues :

1.An incomplete connection queue, which contains an entry for each SYN  ...

恩，这么回事啊

flw2

的 ddd

原帖由 flw 于 2008-9-2 18:25 发表
奇怪啊，为什么服务端是 SYN_RECV，客户端却是 ESTABLISHED 呢？

linux 2.6.26.3的结果如下，2.6.11貌似是一样的，估计版本之间没什么差别

这是linux判断是否超出backlog的方法
比如backlog 是5，那么真时的连接允许保持6条,sk_ack_backlog = 0为默认值
再第7次连接时才返回真（第一次为0，..第6次为5，5==5）
static inline int sk_acceptq_is_full(struct sock *sk)
{
        return sk->sk_ack_backlog > sk->sk_max_ack_backlog;
}

对于别的backlog类似，这可能是为了处理backlog == 0的情况(unp说对于0的解释不同实现不同，这就是linux的解释，至少允许1个连接)

为了说明情况我以backlog为1为例子，为5也一样，但是省的改flw给的c代码

当第一个connect来时，ok连接成功，sk_ack_backlog(0) > sk_max_ack_backlog(1) 不成立
第2个连接时，连接一样成功  sk_ack_backlog(1) > sk_max_ack_backlog(1) 不成立

到第3个时，full了，这个条件的判断是在收到connect发出3次握手中的第3个包，即ack包时检查的

代码如下

listen_overflow:         printk("%s %d: overflow\n", __func__, __LINE__);         if (!sysctl_tcp_abort_on_overflow) {             inet_rsk(req)->acked = 1;             return NULL;         }     embryonic_reset:         printk("%s %d: reset\n", __func__, __LINE__);         NET_INC_STATS_BH(LINUX_MIB_EMBRYONICRSTS);         if (!(flg & TCP_FLAG_RST))             req->rsk_ops->send_reset(sk, skb);         inet_csk_reqsk_queue_drop(sk, req, prev);         return NULL;

printk是我加的
代码我没有继续跟踪，但是很明显：

如果sysctl_tcp_abort_on_overflow为0 (默认值/proc/sys/net/ipv4/tcp_abort_on_overflow)是，那么只是是丢弃最后的ack包（当然客户端不会知道，这也是flw说的客户认为连接的原因，客户ack出去就连接完成了），后果和服务器没收到ack包是一样的，如果客户这个时候直接read,write，服务器可想而知，会重传syn-ack包，因为它“没收到”ack（即它还在等ack），事实是，即使客户不操作，服务器也会重发syn-ack，原因很简单，3次握手要完成

如果sysctl_tcp_abort_on_overflow不为0，那么直接rst了，当然connect不会知道，基于同样的理由,connect已经返回了，读写时就会知道被reset这个事实了


这些我想都是可以完全试验的，但是看代码以及printk，加上抓包，已经很明显了

flw2

真是感叹实现者的工作，丢弃ack的代价较小，内核期待用户马上accept，所以丢掉ack并不会导致连接断开,

我测试的结果就是来自flw的文件,connect代码加在bind前，注释掉后面的，看起来比unp提到linux2.4的结果少1
0-2
1-3

aoegiss

怒赞

flw

原帖由 flw 于 2008-9-2 18:25 发表
奇怪啊，为什么服务端是 SYN_RECV，客户端却是 ESTABLISHED 呢？

哦，应该是服务端已经给客户端发过 syn+ack 了，
因此客户端已经进入 established 了。
但是服务端因为 listen queue 满了，
所以仍然维持 syn_recv 状态。

timespace

以前用Solaris 10和Linux 2.6.9测试过backlog = 1的情况：
        Solaris 是典型的教科书实现，和UNPV1的描述是一致的，最大排队的连接和最大完成连接都是2，也就是完成两个连接后收到SYN时，服务端丢弃SYN，所以也没有回送SYN和ACK，最终就是客户端TIMEOUT
        Linux就和大家看到的类似，服务端有两个完成连接和一个SYN_RCVD状态的未完成连接，最大排队连接数为3而最大完成连接数为2，SYN_RCVD的连接等待ACK超时后，服务端又可以接收新的SYN，不过服务端始终都是SYN_RCVD，客户端是ESTABLISHED，周而复始。。。，模拟个TIMEOUT不容易啊

flw

嗯，果然和我想的是一样的。

system888net

此事虽早有定论,但还是要赞一下参与测试和思考发言的各位大拿的精神.

库鲁特

如何知道一个变量是什么类型？
如何知道分配的内存有多大？
如何知道 select 的 fd_set 里哪个句柄是无效的？
如何知道指针是不是有效的？