经过一番折腾，现总结一下listen的参数backlog。
PS：服务端环境：ubuntu12.04。客户端无所谓：我mac os x 10.7。
先$ man listen看看，里面有一段话：
If the backlog argument is greater than the value in /proc/sys/net/core/somaxconn, then it
is silently truncated to that value; the default value in this file is 128. In kernels
before 2.4.25, this limit was a hard coded value, SOMAXCONN, with the value 128.
$ sudo vi /proc/sys/net/core/somaxconn可以看linux的SOMAXCONN值,我的是128。修改为256就不错了貌似。。。
再传一张图，unp卷1里的(注意，下面这图未完成连接队列的状态应该是SYN_RECV，可能人家写错了)：
好，现在总结下我服务端调用listen的情况：
（注意：不要在同一个机器上测试，我怀疑同一个机器下没有经历三次握手。我在ubuntu12.04下同时跑客户端和服务端程序时就发现无论backlog设为多少，“已完成连结队列”都一直上涨根本没有停止，“未完成连结队列”在10左右摇摆.）
当传参backlog的值< somaxconn时，已完成连结队列的数量最多就是backlog的值。未完成连结队列数量在10左右摇摆。
当传参backlog的值 >= somaxconn时，已完成连结队列的数量最多就是somaxconn。未完成连结队列数量同上。
结论噢：在ubuntu12.04上，backlog的值就是已完成连结队列的值，此值受限于somaxconn。
最后，给出察看服务端两队列的值的脚本(脚本里的4333是我服务端程序的端口值)：
#!/bin/sh
echo "已建立连结队列里套接字的数量"
while [ "1" = "1" ]
do
netstat -nat | grep ESTABLISHED | grep 4333 | wc -l
sleep 2
done
#!/bin/sh
echo "未建立连结队列里套接字的数量"
while [ "1" = "1" ]
do
netstat -nat | grep SYN_RECV | grep 4333 | wc -l
sleep 2
done
顺便说一下，listen函数不是阻塞式的，它只是告诉内核打开某端口监听，真正“监听”的是内核，而不是我们的服务端程序。
listen把第一个参数套接字转换成监听套接字。