netstat、SYN_RECV 和 tcp中的坚持定时器

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

留下评论

邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据