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 不是太大，就没有什么问题

发布时间: 9年前【Linux】105人已围观【返回】【回到顶端】

转载：个人转载请注明文章出处 "www.itarticle.cc-IT技术类文章收集&分享"。

很赞哦！ (1)