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