(tcpdump抓包丢失问题.doc

1 近日用tcpdump抓包，发现有大量的丢包出现(packets dropped by kernel), 如下： tcpdump -i eth0 dst port?1234 and udp -s 2048 -X -tt a.pack 264 packets captured3043 packets received by filter2706 packets dropped by kernel 丢包原因： 经过google以及分析，造成这种丢包的原因是由于libcap抓到包后，tcpdump上层没有及时的取出，导致libcap缓冲区溢出，从而 覆盖了未处理包，此处即显示为dropped by kernel，注意，这里的kernel并不是说是被linux内核抛弃的，而是被tcpdump的内核，即libcap抛弃掉的，上层监听到 1234端口的server可以正常的获取数据。 解决方法： 根据以上分析，可以通过改善tcpdump上层的处理效率来减少丢包率，下面的几步根据需要选用，每一步都能减少一定的丢包率 1.最小化抓取过滤范围，即通过指定网卡，端口，包流向，包大小减少包数量 2. 添加-n参数，禁止反向域名解析 tcpdump -i eth0 dst port?1234 and udp -s 2048 -n -X -tt a.pack 大多数情况这样就可以解决了 可以通过改善tcpdump上层的处理效率来减少丢包率 3. 将数据包输出到cap文件 tcpdump -i eth0 dst port?1234 and udp -s 2048 -n -X -tt? -w a.cap 用了这一步，基本上所有的网络server都可以搞定了 4. 用sysctl修改SO_REVBUF参数，增加libcap缓冲区长度 这一步是绝招了，由于设计内核参数修改，尽量不要使用，要用了不行，那就没办法了 ^_^ 通过tcpdump抓包时，结束后tcpdump会给出如下统计信息：　　1552 packets captured　　1586 packets received by filter　　34 packets dropped by kernel　　　 　其中“captured”的计数指的是应用层捕获到的数据，“received by filter”和“dropped by kernel”的计数由内核维护，应用层通过getsockopt来获取。收到一个包，“received by filter”会加1，如果sock的接收buffer被填满时，则把这个数据包丢弃，将“dropped by kernel”加1。　　if (atomic_read(sk-sk_rmem_alloc) + skb-truesize = (unsigned)sk-sk_rcvbuf){　　 spin_lock(sk-sk_receive_queue.lock);　　 po-stats.tp_drops++;　　 spin_unlock(sk-sk_receive_queue.lock);　　}　　通过调节/proc/sys/net/core/rmem_default和/proc/sys/net/core/rmem_max能够改变sk_rcvbuf的大小。　　　　正常“captured”加上“dropped by kernel”应该等于“received by filter”的大小，有的时候出现不等的情况应该是还有一些数据包在sk_rcvbuf中，还没有被应用层收到的原因。tcpdump做pcap丢包一直用tcpdump做pcap，忽然从某一天开始做的pcap稍微大一点，就开始丢包，给出的哦信息大概是”xxxx packets dropped by kernel”，可能出问题的也就是vmware/linux kernel/libpcap/tcpdump，这里边的每一个我都经常升级，太复杂了，不知道是哪个引入的问题。 于是就一直得过且过，大文件就凑合着在windows上用wireshark。今天实在是想搞清楚怎么回事，就仔细看了一下。 仔细想想，首先排除vmware的问题，因为所有网络程序都正常工作，没有理由vmware或者tcp/ip本身出问题。所以大概就只是libpcap和 tcpdump的问题。 搜到一篇文 章，大概的意思就是是因为内核skb的buffer太小，tcpdump还没有来得及取下一个包，这个就已经被内核里边来的下边的包给覆盖掉了。 试着改了一下还是不行，那看来不是内核缓存的问题，应该就是libpcap或者tcpdump取包比较慢。 起了GUI用wireshark抓了一下，NND也是正常的，那就只可能是tcpdump的问题了。 仔细看了