我用的是linux. 结论是 packet received by filter是tcpdump从内核中拿到的且匹配命令上行指定的过滤条件的包, packet captured是经由pcap_loop, 或 pcap_dispatch 或 pcap_next,把包交给回调处理过的包的数量。这两个数字的差值是tcpdump抓到的,还来不及处理的包。
下面是讨论的一些细节:
/////////////
tcpdump的最后输出. 592个包captured, 1184个包received by filter。。这个差值是不是表示有多少包tcpdump没来得及处理.
man tcpdump上写得好复杂,received by filter的数字取决于OS… 1. 包匹配不匹配命令行上指定的filter都算,如果匹配,有没有被tcpdump读出都算.. 2. 只有匹配命令行上指定的filter的包才算,有没有被tcpdump读出都算. 3. 只有匹配filter才算,只有被tcpdump读出才算.
我的理解是:如果是第3种,那captured的数字和received by filter的数字就是一样的。 第2种的差值表示tcpdump来不及处理的包数量,理想状态上差值能为0. 第1种情况,基本上总是有差值。
我猜测我用的linux上应该是第2种情况.
wangbin579() 10:18:54
应该是匹配的才算received by filter,但奇怪的是,为啥你的系统,captured怎么少?
wangbin579() 10:19:30
[root@hz0-12-157 ~]# tcpdump -i any tcp and port 36524 or 3306 -w all.pcap
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
10757 packets captured
11171 packets received by filter
334 packets dropped by kernel
wangbin579() 10:20:07
我们这边系统,基本可以认为packets received by filter=packets captured + packets dropped by kernel
siu¹ººººººº() 10:23:38
/homemus/tmp # time time tcpdump -i tunl0:1 -w tmp
tcpdump: listening on tunl0:1, link-type RAW (Raw IP), capture size 96 bytes
19508 packets captured
39021 packets received by filter
0 packets dropped by kernel
0.01user 0.02system 0:17.04elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+506minor)pagefaults 0swaps
real 0m17.139s
user 0m0.012s
sys 0m0.028s
wangbin579() 10:26:03
如果是差是丢包,那么通过查看抓包文件,应该能看出很多不完整的session
siu¹ººººººº() 10:28:46
我觉得差值是来不及写入磁盘的包.
siu¹ººººººº() 10:29:04
再研究看看了。。谢谢啦/..
wangbin579() 10:30:03
packets captured是pcap_loop所设置的回调函数所调用的,一旦调用回调函数,就用统计
wangbin579() 10:30:37
有可能内核态部分和用户态部分,速度上不匹配,有延迟导致的?
siu¹ººººººº() 10:32:33
我现在理解, received by filter是pcap库从内核中拿到的又匹配命令行上filter的包的数量, packets captured是经由pcap_loop, pcap_dispatch之类通过callback交付出去的包数量. 差值就是还没来得及处理的.
wangbin579() 10:32:48
17s,每秒也就2000多个,不算多,用户态程序应该来得及处理
wangbin579() 10:33:58
我这边系统很破,处理速度也比这个快,也没有来不及处理
wangbin579() 10:34:45
看看我的:
wangbin579() 10:34:47
[root@hz0-12-157 ~]# time tcpdump -i any tcp and port 36524 or 3306 -w 3306.pcap
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
294663 packets captured
295432 packets received by filter
693 packets dropped by kernel
real 0m17.676s
user 0m0.897s
sys 0m3.502s
wangbin579() 10:35:52
量比你大7倍多,也没有出现来不及处理啊,当然我的是物理机,3G内存,
siu¹ººººººº() 10:36:59
呃 那你觉得这个差值不是来不及处理的包么?。我觉得应该还是来不及处理的。我在想,可能是写到的磁盘文件系统是NFS之类的 ….我继续排查一下。
wangbin579() 10:37:43
有可能,我的是写入本地磁盘。
wangbin579() 10:37:58
你这种情况,我还是第一次碰到
siu¹ººººººº() 10:39:05
我先去运维那边了解下情况…多谢啦
wangbin579() 10:39:18
算涨见识了,还以为一般dropped by kernel为0就代表不丢包呢,居然还有你这种情况。
你可以看看抓包文件,session是不是很多不完整,如果不完整,你的推测是对的
siu¹ººººººº() 10:39:58
嗯。呵呵~~ 做IT,每天都会碰到挑战宇宙规律的现象。
siu¹ººººººº() 10:40:07
мe(~ o мe(632813052) 10:41:09
呵呵
wangbin579() 10:41:24
其实,网络方面的问题,最复杂了。
我现在已经陷入到网络的汪洋大海之中了,各种各样的问题都会有,而且没有尽头。
早知道如此,3年前我就不搞这一块了
siu¹ººººººº() 10:42:30
同感。写一点点代码,都非常难以调试。各种认为理所当然的假设,通通是bug的温床
@wangbin579 麻烦你在tcpdump前加个time,。。把输出贴出来。我好像看出问题来了。
[root@hz0-12-157 ~]# time tcpdump -i any tcp and port 36524 or 3306 -w 3306.pcap
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
294663 packets captured
295432 packets received by filter
693 packets dropped by kernel
real 0m17.676s
user 0m0.897s
sys 0m3.502s
wangbin579() 10:56:03
不是加了time了吗?
wangbin579() 10:57:15
[root@hz0-12-157 ~]# time time tcpdump -i any tcp and port 36524 or 3306 -w 3306.pcap
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
^C202061 packets captured
202523 packets received by filter
369 packets dropped by kernel
0.66user 2.50system 0:11.99elapsed 26%CPU (0avgtext+0avgdata 24208maxresident)k
0inputs+105656outputs (0major+660minor)pagefaults 0swaps
real 0m11.999s
user 0m0.661s
sys 0m2.506s
wangbin579() 10:57:26
加两个,结果如上
siu¹ººººººº() 10:59:29
问题找到的。我这边运行的tcpdump,根本就没有抢到cpu时间来处理.
wangbin579() 11:00:05
siu¹ººººººº() 11:00:06
Real 0m3.914s
User 0m0.008s
Sys 0m0.000s
跑了4秒钟,用户空间才抢到0.008秒,内核态几乎是0 ….
siu¹ººººººº() 11:00:25
那个差值确实是没有来得及处理的包的数量。
wangbin579() 11:00:41
奥,那你系统这么繁忙啊
siu¹ººººººº() 11:02:22
所以,解决了一个问题又会有新的颠覆宇宙规律的问题…系统负载很高,但cpu使用率很低。。
copyright ykyi.net