netstat是一个查看网络状况的非常给力的工具，这里介绍一个不常用的选项：
-o, –timers
Include information related to networking timers.
如果添加-o选项，结果为：
我们发现，多出了一些信息，那么多出来的这些信息有什么用吗？man了一下netstat，知道这里是定时器，此外也并没有什么有用的说明。
我想，既然是定时器，应该与 SYN_RECV 状态持续的时间有关系，怎么才能够证明呢？
首先，先祭出一个非常有用的工具： nc ； nc是个好东西，可以做server也能做client； 更加凑巧的是nc做server时，listen的backlog是为1的：
backlog为1 将非常有利于我们做这个实验； 关于backlog的说明：
backlog通常称为“积压值”；“积压值”说明的是TCP监听的端点已被TCP接受（established的状态）而等待应用层接受（使用-p参数时看到的pid列为’-‘）的最大连接数。
下面你讲看到，虽然nc设置的backlog为1，但是，排队的连接数却不是1，而是2；一般来讲：
积压值和最大排队的连接数有如下关系：
扯远了，赶快回来…
1. 使用nc做一个server
nc -l 10.71.6.21 12345
2. 从另一台机器上去连接该server
nc 10.71.6.21 12345 & // 写四遍就行了
在server端可以使用netstat来观察如下：
至于括号中的数字，我们再观察一个图：
我每次查看那个不能被立即接受的连接，括号中的数字都是变的，而且和等待的时间长短是有关系的；第一列数字是从某个数字开始递减的，递减到0，则第二列数字加1；然后第一列数字继续从一个新的数值开始递减，就这样一直等下去，直到客户端超时。新的数字的取值按照指数避让算法计算出来的。
关于定时器的知识可以参考《tcp/ip详解》
关于SYN_RECV 状态：
当server收到syn后，server端的连接的状态变为SYN_RECV，这时候：
1. 可能server还没有回复了syn-ack
2. 也可能server已经回复了syn-ack
3. 还可能server不仅回复了syn-ack，而且还收到了client的ack（这种情况属于不符合规范的实现）
情况1： 如果状态持续时间太长，需要查看 netstat -sn| grep overflow 是否变化
情况2： 一般可能是client太远了
情况3： 应用进程可能忙不过来了，可以查看 netstat -anop | grep -i established | wc -l ，可能太多了
一般来讲，如果netstat -anop | grep -i established| awk ‘{if($7 == "-") print $0}’| wc -l 不是太大，就没有什么问题