from:http://blog.csdn.net/dog250/article/details/52502623?ref=myread

一直以来，提到这个话题，大家更多的关注的是tcpdump抓包本身的性能，比如能不能应付几十万的pps，能否在万兆网络上自运自如...我们现在知道，这些问题的答案都是否定的，即“不能”！因此你应该去关注netmap高性能抓包方案以及DPDK这样的东西...

但本文不谈这些，本文谈的是被抓取数据包以外的东西，即tcpdump对那些未被命中抓包规则的数据包性能的影响。

接口和实现

不得不说，有的时候一些教诲是错的。比如说关注接口而不关注实现。信奉此信条的，不知踩了多少坑。对于tcpdump而言，你可能只需要关注tcpdump可以抓包就好了，而不必去关注tcpdump是怎么抓包的。事实上，对于tcpdump是怎么抓包的细节，我敢肯定大多数人，包括一些老资格的高级工程师都是不知道的，大多数情况下，很多人只是知道某个接口可以完成某件事情，对于完成该事情的能力上限却没有任何认知。
        在编程中我们也经常遇到这种事，比如Java中有HashMap，大多数人根本不管这个HashMap是怎么实现的，只知道它是一个高效的查询容器，Set了一个Value后，便可以通过其Key在任意时间Get出来，悲哀的是，即便在性能攸关的场景中，很多人还会无条件调用该接口，然后就出现了一个必须加班到深夜才可以排除的故障。我们知道，性能攸关的场景要求你对每一个步骤都了如指掌，这就站在了“关注接口而不是关注实现”的反面！
        然而，有人说“关注接口而不是关注实现”就一定正确吗？没有！这只是在软件工程某个领域的某个细节上是正确的，可以快速开发和迭代，对于训练熟练工是好的，但是对于像我这样的人，那显然是不够的。这也是我没有掌握也没兴趣掌握各种“框架”的本质原因吧。
        我来说一下我遇到过的事情。
        2011年，我遇到一个性能问题，最终的瓶颈是nf_conntrack，过滤的项目太多了，但是抛开这个具体场景不说，如果你的iptables规则设置太多了，也会影响性能，这需要你对iptables的执行机制有充分的理解。
        2013年，再次遇到一个性能问题，CPU，eth0网卡满载的情况下，pps急剧下降，后来发现是eth1网卡疯了导致，不断的up/down，导致路由表不断更新，我说这个eth1状态更新有问题，然而别的程序员却并不买账，eth1怎么可能影响eth0呢？想想也是哦...后来“只关注接口”的程序员试图默默重现该问题，写了一个脚本不断up/down这个eth1，然后观察eth0的变化，结果没有重现，我后来之处了问题所在：在模拟重现的过程中，你们的路由项加的太少了，加入10万条路由试试！问题的关键不在eth1的up/down，而是其up/down导致的路由表更新的锁操作。排查该问题，需要你对路由查找的算法，路由表更新的锁操作有充分的理解，只了解路由表的增删改查接口以及网卡的up/down接口是没有用的。
        近日，我被要求在10万级pps(来自百万级的IP地址)不衰减的情况，同步执行tcpdump抓取特定数据包。预研阶段我认为瓶颈可能会在BPF Filter，因为几年前我曾经研究过它的执行细节，按照线性过滤的执行规则，这明显是一个O(n)算法，且还要受到CPU Cache抖动的影响....高速网络中任意的O(n)操作都会指数级拉低性能！于是我考虑采用HiPAC多维树匹配代替BPF，最终由于耗时久，动作场面大讨论没通过而作罢。本着数据说话的原则，还是花了两天时间来验证tcpdump一下子过滤几千个IP地址是不是真的影响性能，结果是，和料想的一样，真的影响性能。

感官的印象

我不想通过iperf，netperf，hping3之类的玩意儿来验证，因为这些都是基于socket的，万一在数据发送端遇到协议栈的瓶颈，就很悲哀，因此，我试图通过一种绕开发送端协议栈的发包方案，这样显然可以节省几乎一半的排查工作量。感谢有pktgen！
以下是发包脚本：

[plain] view plaincopy

modprobe pktgen
echo rem_device_all >/proc/net/pktgen/kpktgend_0
echo max_before_softirq 1 >/proc/net/pktgen/kpktgend_0
echo clone_skb 1000 >/proc/net/pktgen/lo
echo add_device eth2 >/proc/net/pktgen/kpktgend_0
echo clone_skb 1000 >/proc/net/pktgen/eth2
echo pkt_size 550 >/proc/net/pktgen/eth2
echo src_mac 00:0C:29:B0:CE:CF >/proc/net/pktgen/eth2
echo flag IPSRC_RND >/proc/net/pktgen/eth2
echo src_min 10.0.0.2 >/proc/net/pktgen/eth2
echo src_max 10.0.0.255 >/proc/net/pktgen/eth2
echo dst 1.1.1.1 >/proc/net/pktgen/eth2
echo dst_mac 00:0C:29:A9:F3:DD >/proc/net/pktgen/eth2
echo count 0 >/proc/net/pktgen/eth2
echo pkt_size 100 >/proc/net/pktgen/eth2
echo start >/proc/net/pktgen/pgctrl

以上脚本运行在机器A上，在与其直连的机器B上用sysstat来观察：
sar -n DEV 1
然后在机器B上执行下面的脚本：

[plain] view plaincopy

# 此例子中，我仅仅是启2个tcpdump，每一个过滤600个IP地址，而已！循环参数可以任意调。
i=0
j=0
k=0
for ((k=1;k<2;k++)); do
src='tcpdump -i any src '
for ((i=1;i<30;i++)); do
for ((j=20;j<50;j++)); do
temp=$src" 192.$k.$i.$j or src"
src=$temp
done
done
src=$src" 192.168.11.11 -n"
echo $src
$src &
done

然后，sar的输出结果变化了吗？什么原因导致的呢？

PS：当然上面的pktgen发包方式是我默默做的，在实际中，我还是要使用程序员认可的东西，比如iperf，netperf，hping3之类低效的东西。我并不否认iperf，netperf，hping是好东西，我只是觉得它们在这个测试场景中大材小用了。

tcpdump抓包的架构

上一节的测试我希望看到此文的人自己去测试，这样感官印象更深刻些，不然太多的结果贴图，难免有凑篇幅之嫌了。

本节，我给出目前tcpdump底层pcap的抓包原理，如下图所示：

这是标准的libpcap/tcpdump的结构，一个串行的，同步的抓包结构，当然，也许你已经接触过DPDK，netmap等，这些当然比libpcap/tcpdump更加优秀，但是面临的问题是开发周期太长，以netmap为例，如果你想用它最高效的模式，那就要牺牲对传统协议栈的兼容，反之，如果你想不patch驱动，不编译内核就能用，那你得到的也仅仅是一个兼容PACKET套接字的libpcap/tcpdump的兼容方案。

另外，上述流程图中的很多细节我并没有叙述，比如缓冲区的组织形式，是使用copy还是mmap等等，但是这并不阻碍我们对其的理解，在微秒，甚至毫秒级的BPF开销下，内存操作开销真的不算什么了。
        总之，和之前遇到的iptables，路由表等问题一样，抓包也是一个有其能力极限的机制，它是好东西，但不要指望它在哪里都能帮你的忙-如果不是帮倒忙的话！
        我们来看一下高性能网络上的一些数据包分析的方案。比如在汇聚层，甚至核心层，我要是想对数据包进行审计，该怎么办？用tcpdump吗？....可以这么说，这个层次上，同步的抓包几乎是不可能的，一般都是使用端口镜像的方式，然后在另一台机器上去处理，这台专门处理数据包审计的机器一般都是众核机器，超多的CPU，超高的并行并发处理能力，当然，这是需要花钱的，这也是一种负责人的做法，另外一种不负责任的做法是什么呢？是类似tcpdump的做法，完全串行同步处理，这样会慢，但慢不是问题，问题是一定不能漏，这种思维其实是错误的，特别是在基于统计的互联网络上，任何事情都不精确，任何事情都不绝对。
        在网络上，80%就是全部！

tcpdump抓包对性能的影响相关推荐

zt:tcpdump抓包对性能的影响
https://blog.csdn.net/dog250/article/details/52502623 一直以来,提到这个话题,大家更多的关注的是tcpdump抓包本身的性能,比如能不能应付几十万 ...
Linux基础急速入门：用 TCPDUMP 抓包
简介 tcpdump是一个用于截取网络分组,并输出分组内容的工具.凭借强大的功能和灵活的截取策略,使其成为类UNIX系统下用于网络分析和问题排查的首选工具 tcpdump 支持针对网络层.协议.主机. ...
tcpdump抓包分析 https://www.01hai.com/note/av263669
转:tcpdump抓包分析(强烈推荐) 内容预览: 转自:https://mp.weixin.qq.com/s?__biz=MzAxODI5ODMwOA==&mid=266...~ .,表示没 ...
Wireshark抓包以及tcpdump抓包
tcpdump抓包命令 tcpdump 的抓包保存到文件的命令参数是-w xxx.cap 抓eth1的包 tcpdump -i eth1 -w /tmp/xxx.cap,.cap文件可以用wiresh ...
tcpdump抓包，并保存为文件
首选介绍一下tcpdump的常用参数 tcpdump采用命令行方式,它的命令格式为: tcpdump [ -adeflnNOpqStvx ] [ -c 数量 ] [ -F 文件名 ] [ -i 网络接 ...
tcpdump抓包分析(强烈推荐)
https://blog.csdn.net/wojiuguowei/article/details/102475262 1 起因前段时间,一直在调线上的一个问题:线上应用接受POST请求,请求bod ...
转：tcpdump抓包分析(强烈推荐)
时间:2017-11-13 19:50:17 阅读:26788 评论:0 收藏:0 [点我收藏+] 标签:部分 cpp 序列客户类型增 ...
关于fi dd ler 手机抓包网卡地址地址_大年别闲着，跟我来学tcpdump抓包
快过年了,首先祝福大家新年好,猪年吉祥,阖家团圆,万事如意!在吃喝玩乐睡之余是不是还觉得很闲?很闲?别慌,不怕的,正好可以利用这段时间学点技术提升自己,今天虫虫就给大家奉上新年技术第一波,tcpdum ...
服务器专栏——服务器抓包-tcpdump抓包
文章目录 1.确认服务器网卡有IP地址: 2.服务器抓包-tcpdump抓包命令 1.确认服务器网卡有IP地址: linux系统:ifconfig,查看网卡ip 1.如果网卡没有ip则不能使用含有此网 ...

tcpdump抓包对性能的影响

接口和实现

感官的印象

tcpdump抓包的架构

tcpdump抓包对性能的影响相关推荐

最新文章

热门文章