tcpdump抓包对性能的影响
生活随笔
收集整理的這篇文章主要介紹了
tcpdump抓包对性能的影响
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
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
sar -n DEV 1
然后在機器B上執行下面的腳本：
[plain] view plaincopy
然后，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抓包对性能的影响的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： elasticsearch资源汇总
- 下一篇： 视频直播技术详解（0）开篇