我用的是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
/home
mus/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