tcpdump抓包对性能的影响
生活随笔
收集整理的這篇文章主要介紹了
tcpdump抓包对性能的影响
小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.
from:http://blog.csdn.net/dog250/article/details/52502623?ref=myread
一直以來，提到這個(gè)話題，大家更多的關(guān)注的是tcpdump抓包本身的性能，比如能不能應(yīng)付幾十萬的pps，能否在萬兆網(wǎng)絡(luò)上自運(yùn)自如...我們現(xiàn)在知道，這些問題的答案都是否定的，即“不能”！因此你應(yīng)該去關(guān)注netmap高性能抓包方案以及DPDK這樣的東西...
??????? 但本文不談這些，本文談的是被抓取數(shù)據(jù)包以外的東西，即tcpdump對那些未被命中抓包規(guī)則的數(shù)據(jù)包性能的影響。接口和實(shí)現(xiàn)
不得不說，有的時(shí)候一些教誨是錯(cuò)的。比如說關(guān)注接口而不關(guān)注實(shí)現(xiàn)。信奉此信條的，不知踩了多少坑。對于tcpdump而言，你可能只需要關(guān)注tcpdump可以抓包就好了，而不必去關(guān)注tcpdump是怎么抓包的。事實(shí)上，對于tcpdump是怎么抓包的細(xì)節(jié)，我敢肯定大多數(shù)人，包括一些老資格的高級工程師都是不知道的，大多數(shù)情況下，很多人只是知道某個(gè)接口可以完成某件事情，對于完成該事情的能力上限卻沒有任何認(rèn)知。??????? 在編程中我們也經(jīng)常遇到這種事，比如Java中有HashMap，大多數(shù)人根本不管這個(gè)HashMap是怎么實(shí)現(xiàn)的，只知道它是一個(gè)高效的查詢?nèi)萜?#xff0c;Set了一個(gè)Value后，便可以通過其Key在任意時(shí)間Get出來，悲哀的是，即便在性能攸關(guān)的場景中，很多人還會無條件調(diào)用該接口，然后就出現(xiàn)了一個(gè)必須加班到深夜才可以排除的故障。我們知道，性能攸關(guān)的場景要求你對每一個(gè)步驟都了如指掌，這就站在了“關(guān)注接口而不是關(guān)注實(shí)現(xiàn)”的反面！
??????? 然而，有人說“關(guān)注接口而不是關(guān)注實(shí)現(xiàn)”就一定正確嗎？沒有！這只是在軟件工程某個(gè)領(lǐng)域的某個(gè)細(xì)節(jié)上是正確的，可以快速開發(fā)和迭代，對于訓(xùn)練熟練工是好的，但是對于像我這樣的人，那顯然是不夠的。這也是我沒有掌握也沒興趣掌握各種“框架”的本質(zhì)原因吧。
??????? 我來說一下我遇到過的事情。
??????? 2011年，我遇到一個(gè)性能問題，最終的瓶頸是nf_conntrack，過濾的項(xiàng)目太多了，但是拋開這個(gè)具體場景不說，如果你的iptables規(guī)則設(shè)置太多了，也會影響性能，這需要你對iptables的執(zhí)行機(jī)制有充分的理解。
??????? 2013年，再次遇到一個(gè)性能問題，CPU，eth0網(wǎng)卡滿載的情況下，pps急劇下降，后來發(fā)現(xiàn)是eth1網(wǎng)卡瘋了導(dǎo)致，不斷的up/down，導(dǎo)致路由表不斷更新，我說這個(gè)eth1狀態(tài)更新有問題，然而別的程序員卻并不買賬，eth1怎么可能影響eth0呢？想想也是哦...后來“只關(guān)注接口”的程序員試圖默默重現(xiàn)該問題，寫了一個(gè)腳本不斷up/down這個(gè)eth1，然后觀察eth0的變化，結(jié)果沒有重現(xiàn)，我后來之處了問題所在：在模擬重現(xiàn)的過程中，你們的路由項(xiàng)加的太少了，加入10萬條路由試試！問題的關(guān)鍵不在eth1的up/down，而是其up/down導(dǎo)致的路由表更新的鎖操作。排查該問題，需要你對路由查找的算法，路由表更新的鎖操作有充分的理解，只了解路由表的增刪改查接口以及網(wǎng)卡的up/down接口是沒有用的。
??????? 近日，我被要求在10萬級pps(來自百萬級的IP地址)不衰減的情況，同步執(zhí)行tcpdump抓取特定數(shù)據(jù)包。預(yù)研階段我認(rèn)為瓶頸可能會在BPF Filter，因?yàn)閹啄昵拔以?jīng)研究過它的執(zhí)行細(xì)節(jié)，按照線性過濾的執(zhí)行規(guī)則，這明顯是一個(gè)O(n)算法，且還要受到CPU Cache抖動(dòng)的影響....高速網(wǎng)絡(luò)中任意的O(n)操作都會指數(shù)級拉低性能！于是我考慮采用HiPAC多維樹匹配代替BPF，最終由于耗時(shí)久，動(dòng)作場面大討論沒通過而作罷。本著數(shù)據(jù)說話的原則，還是花了兩天時(shí)間來驗(yàn)證tcpdump一下子過濾幾千個(gè)IP地址是不是真的影響性能，結(jié)果是，和料想的一樣，真的影響性能。
感官的印象
我不想通過iperf，netperf，hping3之類的玩意兒來驗(yàn)證，因?yàn)檫@些都是基于socket的，萬一在數(shù)據(jù)發(fā)送端遇到協(xié)議棧的瓶頸，就很悲哀，因此，我試圖通過一種繞開發(fā)送端協(xié)議棧的發(fā)包方案，這樣顯然可以節(jié)省幾乎一半的排查工作量。感謝有pktgen！??????? 以下是發(fā)包腳本：
[plain] view plaincopy
sar -n DEV 1
然后在機(jī)器B上執(zhí)行下面的腳本：
[plain] view plaincopy
然后，sar的輸出結(jié)果變化了嗎？什么原因?qū)е碌哪?#xff1f;
PS：當(dāng)然上面的pktgen發(fā)包方式是我默默做的，在實(shí)際中，我還是要使用程序員認(rèn)可的東西，比如iperf，netperf，hping3之類低效的東西。我并不否認(rèn)iperf，netperf，hping是好東西，我只是覺得它們在這個(gè)測試場景中大材小用了。
tcpdump抓包的架構(gòu)
上一節(jié)的測試我希望看到此文的人自己去測試，這樣感官印象更深刻些，不然太多的結(jié)果貼圖，難免有湊篇幅之嫌了。??????? 本節(jié)，我給出目前tcpdump底層pcap的抓包原理，如下圖所示：
這是標(biāo)準(zhǔn)的libpcap/tcpdump的結(jié)構(gòu)，一個(gè)串行的，同步的抓包結(jié)構(gòu)，當(dāng)然，也許你已經(jīng)接觸過DPDK，netmap等，這些當(dāng)然比libpcap/tcpdump更加優(yōu)秀，但是面臨的問題是開發(fā)周期太長，以netmap為例，如果你想用它最高效的模式，那就要犧牲對傳統(tǒng)協(xié)議棧的兼容，反之，如果你想不patch驅(qū)動(dòng)，不編譯內(nèi)核就能用，那你得到的也僅僅是一個(gè)兼容PACKET套接字的libpcap/tcpdump的兼容方案。
??????? 另外，上述流程圖中的很多細(xì)節(jié)我并沒有敘述，比如緩沖區(qū)的組織形式，是使用copy還是mmap等等，但是這并不阻礙我們對其的理解，在微秒，甚至毫秒級的BPF開銷下，內(nèi)存操作開銷真的不算什么了。??????? 總之，和之前遇到的iptables，路由表等問題一樣，抓包也是一個(gè)有其能力極限的機(jī)制，它是好東西，但不要指望它在哪里都能幫你的忙-如果不是幫倒忙的話！
??????? 我們來看一下高性能網(wǎng)絡(luò)上的一些數(shù)據(jù)包分析的方案。比如在匯聚層，甚至核心層，我要是想對數(shù)據(jù)包進(jìn)行審計(jì)，該怎么辦？用tcpdump嗎？....可以這么說，這個(gè)層次上，同步的抓包幾乎是不可能的，一般都是使用端口鏡像的方式，然后在另一臺機(jī)器上去處理，這臺專門處理數(shù)據(jù)包審計(jì)的機(jī)器一般都是眾核機(jī)器，超多的CPU，超高的并行并發(fā)處理能力，當(dāng)然，這是需要花錢的，這也是一種負(fù)責(zé)人的做法，另外一種不負(fù)責(zé)任的做法是什么呢？是類似tcpdump的做法，完全串行同步處理，這樣會慢，但慢不是問題，問題是一定不能漏，這種思維其實(shí)是錯(cuò)誤的，特別是在基于統(tǒng)計(jì)的互聯(lián)網(wǎng)絡(luò)上，任何事情都不精確，任何事情都不絕對。
??????? 在網(wǎng)絡(luò)上，80%就是全部！
總結(jié)
以上是生活随笔為你收集整理的tcpdump抓包对性能的影响的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： elasticsearch资源汇总
- 下一篇： 视频直播技术详解（0）开篇