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

mouse2000

呵呵，通过这个帖子向版主们学习努力寻找问题答案的精神~！

FreeB_U

这个可以参考<tcp/ip协议详解（卷一）>

不同的系统对backlog值的理解是不一样的。。

BSD把 backlog*3/2  当作队列的的最大值（已建立链接的队列+未建立链接的队列）     

也就是说：如果backlog=5  那么最多可以有8个连接。。。（其它的系统未必遵循这个规则）


当然 。现在的 backlog可以设置的很大，，也就是我们可以编程时把它设置为一个很大的值，，但是系统并不会因为这样而使用这个值，
它会使用系统所支持的最大的值，，，可以在socket.h文件里看到最大值的定义

空灵静世

从tcpdump抓包的结果看,客户端每9秒建立两条连接,也就是服务器每9秒响应两条联接(以前在不同的机器上我抓包每3秒建立一条连接,今天不知道为什么抓不出来了)
抓包如下:
tcpdump -i lo port 9999 -r hw.tcp|grep 32790
reading from file hw.tcp, link-type EN10MB (Ethernet)
10:30:15.289296 IP 192.168.0.130.32790 > 192.168.0.130.9999: S 1650969640:1650969640(0) win 32767 <mss 16396,sackOK,timestamp 114528 0,nop,wscale 3>
10:30:18.288480 IP 192.168.0.130.32790 > 192.168.0.130.9999: S 1650969640:1650969640(0) win 32767 <mss 16396,sackOK,timestamp 117528 0,nop,wscale 3>
10:30:24.288311 IP 192.168.0.130.32790 > 192.168.0.130.9999: S 1650969640:1650969640(0) win 32767 <mss 16396,sackOK,timestamp 123528 0,nop,wscale 3>
10:30:24.288343 IP 192.168.0.130.9999 > 192.168.0.130.32790: S 1652955109:1652955109(0) ack 1650969641 win 32767 <mss 16396,sackOK,timestamp 123528 123528,nop,wscale 3>
10:30:24.288362 IP 192.168.0.130.32790 > 192.168.0.130.9999: . ack 1 win 4096 <nop,nop,timestamp 123528 123528>
10:30:27.686649 IP 192.168.0.130.9999 > 192.168.0.130.32790: S 1652955109:1652955109(0) ack 1650969641 win 32767 <mss 16396,sackOK,timestamp 126927 123528,nop,wscale 3>
10:30:27.686690 IP 192.168.0.130.32790 > 192.168.0.130.9999: . ack 1 win 4096 <nop,nop,timestamp 126927 126927,nop,nop,sack sack 1 {0:1} >
10:30:33.685473 IP 192.168.0.130.9999 > 192.168.0.130.32790: S 1652955109:1652955109(0) ack 1650969641 win 32767 <mss 16396,sackOK,timestamp 132927 126927,nop,wscale 3>
10:30:33.685509 IP 192.168.0.130.32790 > 192.168.0.130.9999: . ack 1 win 4096 <nop,nop,timestamp 132927 132927,nop,nop,sack sack 1 {0:1} >
10:30:45.686130 IP 192.168.0.130.9999 > 192.168.0.130.32790: S 1652955109:1652955109(0) ack 1650969641 win 32767 <mss 16396,sackOK,timestamp 144929 132927,nop,wscale 3>
10:30:45.686160 IP 192.168.0.130.32790 > 192.168.0.130.9999: . ack 1 win 4096 <nop,nop,timestamp 144929 144929,nop,nop,sack sack 1 {0:1} >
bash-3.00# tcpdump -i lo port 9999 -r hw.tcp|grep 32791
reading from file hw.tcp, link-type EN10MB (Ethernet)
10:30:24.288493 IP 192.168.0.130.32791 > 192.168.0.130.9999: S 1661414239:1661414239(0) win 32767 <mss 16396,sackOK,timestamp 123528 0,nop,wscale 3>
10:30:24.288509 IP 192.168.0.130.9999 > 192.168.0.130.32791: S 1661567750:1661567750(0) ack 1661414240 win 32767 <mss 16396,sackOK,timestamp 123529 123528,nop,wscale 3>
10:30:24.288523 IP 192.168.0.130.32791 > 192.168.0.130.9999: . ack 1 win 4096 <nop,nop,timestamp 123529 123529>
10:30:27.686663 IP 192.168.0.130.9999 > 192.168.0.130.32791: S 1661567750:1661567750(0) ack 1661414240 win 32767 <mss 16396,sackOK,timestamp 126927 123529,nop,wscale 3>
10:30:27.686700 IP 192.168.0.130.32791 > 192.168.0.130.9999: . ack 1 win 4096 <nop,nop,timestamp 126927 126927,nop,nop,sack sack 1 {0:1} >
10:30:33.685485 IP 192.168.0.130.9999 > 192.168.0.130.32791: S 1661567750:1661567750(0) ack 1661414240 win 32767 <mss 16396,sackOK,timestamp 132927 126927,nop,wscale 3>
10:30:33.685517 IP 192.168.0.130.32791 > 192.168.0.130.9999: . ack 1 win 4096 <nop,nop,timestamp 132927 132927,nop,nop,sack sack 1 {0:1} >
10:30:45.886100 IP 192.168.0.130.9999 > 192.168.0.130.32791: S 1661567750:1661567750(0) ack 1661414240 win 32767 <mss 16396,sackOK,timestamp 145129 132927,nop,wscale 3>
10:30:45.886148 IP 192.168.0.130.32791 > 192.168.0.130.9999: . ack 1 win 4096 <nop,nop,timestamp 145129 145129,nop,nop,sack sack 1 {0:1} >

[ 本帖最后由 空灵静世 于 2008-10-31 11:14 编辑 ]

linternt

原帖由 flw 于 2008-9-2 17:52 发表

先试试吧。可能和你想的不一样。

我们写的服务程序，几分钟就死了，垃圾！

LDAP这样连一会也就完蛋了！一千多点的时候，基本就响应特别慢了！

空灵静世

我更正上之前说的,当syn_recv没有开始退出之前,服务器会延迟9秒对客户端的syn进行回应(紧跟的下一条连接是及时回应),但当有syn_recv开始有退出的时候是延时三秒回应
三秒回应抓包如下:
tcpdump port 9999 -r hw7.tcp | grep 55145
reading from file hw7.tcp, link-type EN10MB (Ethernet)
11:33:35.354033 IP pc-200805111531.unimassystem.com.55145 > 192.168.0.130.9999: S 766929119:766929119(0) win 5840 <mss 1460,sackOK,timestamp 74113887 0,nop,wscale 2>
11:33:38.353957 IP pc-200805111531.unimassystem.com.55145 > 192.168.0.130.9999: S 766929119:766929119(0) win 5840 <mss 1460,sackOK,timestamp 74116887 0,nop,wscale 2>
11:33:38.354004 IP 192.168.0.130.9999 > pc-200805111531.unimassystem.com.55145: S 1149964455:1149964455(0) ack 766929120 win 5792 <mss 1460,sackOK,timestamp 226608 74116887,nop,wscale 3>
11:33:38.354272 IP pc-200805111531.unimassystem.com.55145 > 192.168.0.130.9999: . ack 1 win 1460 <nop,nop,timestamp 74116887 226608>
11:33:42.153595 IP 192.168.0.130.9999 > pc-200805111531.unimassystem.com.55145: S 1149964455:1149964455(0) ack 766929120 win 5792 <mss 1460,sackOK,timestamp 230408 74116887,nop,wscale 3>
11:33:42.153842 IP pc-200805111531.unimassystem.com.55145 > 192.168.0.130.9999: . ack 1 win 1460 <nop,nop,timestamp 74120688 230408,nop,nop,sack sack 1 {0:1} >
11:33:48.152723 IP 192.168.0.130.9999 > pc-200805111531.unimassystem.com.55145: S 1149964455:1149964455(0) ack 766929120 win 5792 <mss 1460,sackOK,timestamp 236408 74120688,nop,wscale 3>
11:33:48.152932 IP pc-200805111531.unimassystem.com.55145 > 192.168.0.130.9999: . ack 1 win 1460 <nop,nop,timestamp 74126688 236408,nop,nop,sack sack 1 {0:1} >
11:34:00.350861 IP 192.168.0.130.9999 > pc-200805111531.unimassystem.com.55145: S 1149964455:1149964455(0) ack 766929120 win 5792 <mss 1460,sackOK,timestamp 248608 74126688,nop,wscale 3>
11:34:00.351157 IP pc-200805111531.unimassystem.com.55145 > 192.168.0.130.9999: . ack 1 win 1460 <nop,nop,timestamp 74138888 248608,nop,nop,sack sack 1 {0:1} >
bash-3.00# tcpdump port 9999 -r hw7.tcp | grep 55146
reading from file hw7.tcp, link-type EN10MB (Ethernet)
11:33:38.354339 IP pc-200805111531.unimassystem.com.55146 > 192.168.0.130.9999: S 775886579:775886579(0) win 5840 <mss 1460,sackOK,timestamp 74116888 0,nop,wscale 2>
11:33:41.354160 IP pc-200805111531.unimassystem.com.55146 > 192.168.0.130.9999: S 775886579:775886579(0) win 5840 <mss 1460,sackOK,timestamp 74119888 0,nop,wscale 2>
11:33:41.354205 IP 192.168.0.130.9999 > pc-200805111531.unimassystem.com.55146: S 1152059511:1152059511(0) ack 775886580 win 5792 <mss 1460,sackOK,timestamp 229609 74119888,nop,wscale 3>
11:33:41.354549 IP pc-200805111531.unimassystem.com.55146 > 192.168.0.130.9999: . ack 1 win 1460 <nop,nop,timestamp 74119888 229609>
11:33:45.552521 IP 192.168.0.130.9999 > pc-200805111531.unimassystem.com.55146: S 1152059511:1152059511(0) ack 775886580 win 5792 <mss 1460,sackOK,timestamp 233808 74119888,nop,wscale 3>
11:33:45.552894 IP pc-200805111531.unimassystem.com.55146 > 192.168.0.130.9999: . ack 1 win 1460 <nop,nop,timestamp 74124087 233808,nop,nop,sack sack 1 {0:1} >
11:33:51.551634 IP 192.168.0.130.9999 > pc-200805111531.unimassystem.com.55146: S 1152059511:1152059511(0) ack 775886580 win 5792 <mss 1460,sackOK,timestamp 239808 74124087,nop,wscale 3>
11:33:51.551956 IP pc-200805111531.unimassystem.com.55146 > 192.168.0.130.9999: . ack 1 win 1460 <nop,nop,timestamp 74130087 239808,nop,nop,sack sack 1 {0:1} >
11:34:03.549851 IP 192.168.0.130.9999 > pc-200805111531.unimassystem.com.55146: S 1152059511:1152059511(0) ack 775886580 win 5792 <mss 1460,sackOK,timestamp 251808 74130087,nop,wscale 3>
11:34:03.550073 IP pc-200805111531.unimassystem.com.55146 > 192.168.0.130.9999: . ack 1 win 1460 <nop,nop,timestamp 74142088 251808,nop,nop,sack sack 1 {0:1} >
bash-3.00#

空灵静世

猜测下内核的做法:内核延时3秒后试图对客户端回应的时候监查syn_recv队列有无变化,有变化,发回应的syn,无变化则再等3秒,直到9秒,但为什么接下来的却能及时回应呢?

chenzhanyiczy

这个问题，要看内核的实现，不同的实现有不同的效果，可以参考unp，一般总的连接数是己连接数（经过TCP三次握手的）的1.5倍

hightman

client看到的是Established是不是因为您的服务器打开了syncookie之类(或PF中的syn-proxy)

寂寞不

listen(int sockfd ,int  backlog);
backlog 能监听的客户端的个数，比如：
listen( sfd , 20);
我一般用20(想多一点可以多线程或者多进程)，
就是说我监听的最多只有 20个，比如有 25 个客户同时请求链接！
那就只有 20 个客户握手成功(成功后排队等待处理)。剩下的5个就被抛弃。

如果处理器能力很强大！那就不用考虑backlog直接 =20。

rong_bo

这个帖子有价值。