NetAnalyzer筆記之一. 開篇語

時間 2019-12-17

原文原文鏈接

第一次寫技術相關的博客，不足之處還請擔待並告知。數組

在開始以前，先簡單介紹一下NetAnalyzer, NetAnalyzer是一款集網絡數據採集、報文協議分析、統計、網絡流量監控於一體的網絡管理工具軟件，你能夠直接認爲NetAnalyzer就是中文（簡化）版的Wrishark，哈哈，有點夜郎自大了，不過不要在乎這些細節。緩存

接下來看看我在代碼中的一段註釋：安全

 1 /*
 2  * 項目開始時間：2011-09-17
 3  * 2.0發佈時間：   2011-10-04//揚帆起航
 4  * 2.1發佈時間：   2011-10-20//成長之旅
 5  * 2.1.3.10發佈時間： 2011-12-06//軟件發佈
 6  * 2.2.0.11發佈時間：2011-12-23 //三站點同時發佈
 7  *  2.4 擴展
 8  *  2.5 實用性
 9  *  2.8 普遍性
10  *  2.9 初步商業級別 
11  *  2.10 創建完整的軟件環境
12  * 做者：馮天文
13  *
14 */

注意，該項目是從2011年09月開始的，並且版本是從2.0開始，，這是爲何呢？且聽我慢慢道來，好久好久之前……網絡

1 NetAnalyzer以前的技術積累

剛學JAVA程序設計，由於老師的講解並非很完全，不少東西都須要本身去找資料學習，因而便找到了一些教學視頻，經過視頻來學習JAVA，在講到Socket通訊時，講解人就順便說了一些網絡傳輸數據包的問題，雖然本身是網絡專業，但本身只是大一的學生，好多東西都感受很高深，這也算是第一次接觸網絡抓包的概念。2010年下半年開始進入了大二，開始有了一點寫程序的功底，天天都樂此不疲的寫着一些小玩具，但歷來未曾作出一款值得炫耀的東西，這種狀態持續了很長一段時間。大概是在9月份左右，班上一位朋友偶然看到我在寫程序，因而讓我加入他們組去參加一個比賽，他當時正在找人，我絕不猶豫就答應了。就在國慶前夕，學院老師給出了幾個課題，有分形圖設計，有物聯網的，也有P2P對等交換技術的，固然還有網絡協議編程的，由於考慮到咱們本身的專業性，因而選擇了網絡協議編程，而且給每一個團隊分配一個指導老師，在與老師的談話中瞭解到，咱們暫時要作一個基於Winpacp的簡單網絡嗅探器。架構

1.1 最原始的數據採集程序

記得當時本身很興奮，由於當時聽起來，若是製做出這樣一款軟件的確有着很大的成就感。然而完事開頭難，雖然已經大二了，可是尚未開設關於網絡的專業課，因此一切關於網絡的概念都是零，因而發揚老傳統，在網上找相關的資料本身學習，國慶期間推掉了一切出行計劃，早晨早早就起來，從網絡基礎開始學習，由於知識觸及太廣了，不少都看的似懂非懂，然而本身仍是堅持下來，當假期結束後，已經有點頭緒了，而且學會簡單的使用一些網絡協議分析工具如：Wireshark，Sniffer等，並結合已經學到的知識，也能作一些簡單的協議分析了。app

貌似一切均可以開始了，因而開始去嘗試看Winpcap的開發文檔，記得當時看到的時候感受一團糟，示例代碼是用C寫的，其中不管函數名稱，仍是變量名稱都感受很彆扭，不過仍是大概能夠看得明白。首先天然是從獲取網卡的開始，那仍是比較短的示例代碼，按照文檔上面的提示，花了差很少兩天的時間才配置好環境，終於將那段代碼調試通，當網卡的信息顯示在那黑黑的控制檯上時，特別激動。框架

圖1.1網絡數據採集控制檯程序

因而馬不停蹄調試出了數據採集的控制檯程序。可是顯示的數據全是原始的數據，只是用十六進制的方式展現出來，若是隻是顯示出來並沒用多大的意義，我須要把這些數據保存下來，而且須要把這些信息分析出來，因而立刻改寫了程序將這些數據以文本的方式將獲取的網絡信息寫在文件中。而後使用C#作了一個字符串解析的工具，來分析這些數據，該解釋工具經過啓動進程的方式，啓動控制檯程序採集數據，並將其保存在文本文件中，而後再將文件加載入解釋器中，分別提取個字段進行分析。該解釋器，已經提取了以太網中三個字段的的數據：目標MAC，源MAC，上層協議類型等數據。函數

圖1.2被鄙視的文本解釋工具工具

當完成了這個工具，興致勃勃的讓老師看的時候，卻徹底被無情的鄙視了一通，然而我卻執拗的認爲這個小工具仍是有意義的，至少讓本身在數據採集設計上邁出了一大步。雖而後來作了不少數據採集的工具，但這個始終保留在本身寫的數據採集工具文件夾中。這個小工具的採集數據的程序是惟一用C寫的，也真正是按照本身理解的方式運做的。然而如今想來，這倒是當時的無奈之舉。由於學完的JAVA，感受在作Windows桌面程序，並非很好，因而自學了C#，這也能夠解釋我爲何會使用C#做解釋器的問題了。其實開始是想過使用C++經過MFC來製做的，但若是再從新去學習一門語言，入門可能不是難事，但若是要達到駕輕就熟的地步卻須要慢慢的積累，不假以時日是不可能的，而堅持本身作的原有的那個確定是不能夠的，整個又陷入了兩難境地。

1.2 SnifferSharp的發展

有一天，抱着試試看的心情，在網上找看看是否有有人提供相關的技術支持。因而發現了分裝了Winpcap的.Net類庫SharpPcap，該庫是將Winpcap提供的接口利用.Net技術進行了分裝，從而能夠直接在C#中應用。

接下來全部的開發都轉移到.Net平臺上了，而且立刻找到了開發者的開發文檔，雖然都是英文，不過花了幾天的時間總體仍是能夠看得懂的，文檔中提供了相關示例代碼，真是柳暗花明又一村，新一輪的編程立刻開始，不過有了上次的教訓，此次作就有必定的經驗了，而且有文檔的幫助，作起來也有了底氣，因而通過十幾天的構建終於第一個能夠稱之爲數據抓包軟件snifferSharp v0.5版本終於完成了，該軟件基於SharpPcap3.3版本，該軟件已經實現了

圖1.3 snifferSharp v0.5軟件

最初的目標，並且增長了協議的解析，軟件中設置專用的結構來提取數據包的協議字段，由於當時本身的知識層次的限制，因此只提取了一些簡單的字段進行分析，並將其顯示在一個文本框中，方便用戶使用，該種設計方式，曾對後來多款軟件的有很深的影響。由於使用過Sniffer pro 和Wrieshark其中有一個十六進制顯示的窗口，故而，在該軟件中也開闢了十六進制顯示窗口，程序提供了過濾表達式的配置功能，方便用戶捕獲特定的數據。在後來的軟件在該軟件上所列出的各類功能都變爲基礎配置。

固然該軟件中有不少不合理的設計，程序中用一個2百萬的數組來緩存捕獲的數據，這直接致使內存分配不合理，當時其實意識到這一點而已，仍是由於技術水平的問題，未使用動態數組。另外一個是由於UI配置與數據存儲之間是直接執行的，及數據在存儲完成以後，再提取數據包信息，其實後來除了NetAnalyzer2.0及其以後的全部版本都存在這個問題。在UI顯示，這是須要時間的，而這段時間內軟件將不能採集數據，這樣形成丟包率極大，而且數據提取採用循環等待方式，形成CPU消耗很大。還有一個很重要的問題就是，用於顯示採集數據的是WinForm中的ListView控件，每當用數據到來時，該控件都要重回，這也是形成丟包的重要緣由之一。

在以後的幾天裏立刻完成了snifferSharp v1.0版本，有了前一版本的鋪墊，本次並無在原有的基礎上改變什麼，只是增長了流量監控功能，在該軟件中，添加了本身開發的Chart組件，在NetAnalyzer2.X的版本中依然使用該組件，固然，這個儀表盤已經徹底被取代了，而整個組件也由原來的一個，發展爲11種，方便各類應用。而在snifferSharp v1.5中針對ListView影響數據採集速度的問題，將程序設置爲在捕獲數據包的時候先不在界面顯示，當單擊按鈕中止時，再開始在UI顯示。此方法相似於Sniffer Pro的處理方式。然而該種方法雖然對數據採集有必定的幫助，但若是採集數據過多，則不得不等待數據的緩慢的在UI上顯示。反而不利於數據的即時處理，因而用戶不得不花更多的時間去等待數據的解析。

圖1.4 snifferSharp v1.0軟件

圖1.5 snifferSharp v1.5軟件

1.3 CSniffer的構建

經過snifferSharp系列版本的設計，整個網絡數據採集工具的基礎架構已經呈現出來，然而伴隨而來的總體的表現不盡人意。須要從新架構，包括數據存，UI回顯等不少急須要處理的問題。因而本身放棄了繼續開發snifferSharp的計劃，轉而構建了一個全新的數據採集軟件系統，這就是CSniffer。該系列軟件只出了一個版本，可是，在本身數據採集軟件開發過程當中卻有着很是重要的意義，由於該種設計方案，包括設計思想，UI設計，在NetAnalyzer中能夠找它到影子。

圖1.6 CSniffer軟件a 數據採集界面

爲了配合該版本的各類特性，Chart組件進行了一次很大的更新，在該軟件中使用的指針指示器，流量走勢圖，數據報文統計圖都源於本次的更新。固然這些僅僅是表面的文章，真正改變的是其內部的架構，本次使用的動態數組來存儲數據，這樣軟件在內存分配方面或擴展方面都有了一次飛躍，而採用數據採集、協議分析、報文統計等操做獨立於UI的方式，更利於數據的快速處理，從而有效的提升了軟件的效率，也提高了軟件的可用性。

圖1.6 CSniffer軟件b 協議分析界面

圖1.6 CSniffer軟件C 報文統計界面

本次還增長了對用於層載荷數據的恢復，其實這也是一次實驗而已，然而當看到效果是，仍是有點小成就。這項功能，在後來幾經修改後也成了基本配置，到此爲止。再後來的NetAnalyzer開發中都有跡可循了。

對於本次的開發雖然是全新的架構，然而依然擺脫不了那些根深蒂固的問題，數據採集效率雖有所提高，但是空間依然很小。並且在設計中，依然使用了原有軟件的協議分析結構，因此報文首部解析，如以往同樣，總體表現平平。

本次設計的另外一個創新點，就是增長了報文類型分佈統計功能。可是由於該功能的增長反而更加影響了軟件採集數據的效率，可是該功能仍是被保留下來了。由於總會有辦法來處理的。這也成爲後來NetAnalyzer着重要解決的問題之一。

至此NetAnalyzer以前的全部本身製做的網絡數據採集軟件所有介紹完成了，事實上包括測試等各類數據採集軟件不止這些，由於在製做過程當中或修改或刪除，只保留了比較典型的幾款，也算是比較典型的的幾款做爲NetAnalyzer發展路上的奠定者。事實上世界上全部的事情都是從無到有，再從有到經典，「不積跬步，無以致千里；不積小流，無以成江海。」若是沒有以上這些軟件的支撐，本身獨立設計NetAnalyzer恐怕只是紙上談兵的事情。從開始感受高深莫測，到完成一個不是程序的程序，由原來漏洞百出，到一個能夠構成完總體系的框架，以致於如今我須要編寫相關的說明來輔助管理整個系統，這不僅是軟件的發展，更是本身的技術的提高，認識的飛躍。站在今天的角度上，感受之前的軟件確實有很多瑕疵紕漏，並且整個程序都談不上設計，再看看如今完成的NetAnalyzer感受是盡善盡美。也許有一天再回過頭來看看如今的軟件是，也許和如今看之前的程序同樣吧。也許這樣會顯得很悲觀，可是隻有看到程序軟件的不足，纔是真正的進步，也纔有發展的空間。

2 NetAnalzer的開始

在完成了CSniffer以後，準備要接着進入第二個版本的時候，小組須要一款抓包軟件來完成課題。因而就中止了對CSniffer的開發，而進入正是進入了一個新的開發階段。若是按照軟件工程的角度，如本身這般亂來確定是不能夠的，說是一個新的開發階段，實際上就是重建一個解決方案，簡單完成了界面設計就急急忙忙開始了編碼，並無進行完整的設計分析，所幸整個過程已經輕車熟路了，立刻就完成了基礎編碼，並且整個軟件仍是比較簡單因此用了查不到一個禮拜的時間就完成了軟件的設計，本次設計使用了大量的新技術，而且設計出了NetAnalyzer的標準UI，規定了必需要提供的窗口布局位置，並且採用分頁方式分別展現軟件的主界面與數據處理界面，基本上把CSniffer中實現的四個頁面的內容放置在兩個頁面內，增長了版面的利用率。

圖1.7 NetAnalyzer1.3 a 主界面

圖1.7 NetAnalyzer1.3 b 數據處理界面

相對於UI設計，此次更注重性能的提高，首先天然考慮的是網絡數據採集效率的問題，在以前的軟件中，這始終是一個沒法逾越的鴻溝。然而本次軟件設計很大程度上已經解決了該問題，本次數據獲取由原來一直使用的循環監聽方式變爲事件觸發通知方式，這樣在沒有數據報文到來的狀況下，整個系統開銷減少，當有數據當來，則通知對應的數據存儲結構提取數據，這樣使數據保存更爲靈活，其餘線程調用數據時也不會有太大的影響。在界面顯示方面該軟件摒棄了沖毀頻率極高的ListView控件，改成緩衝很小的控件。NetAnalyzer1.X版本的採用分層方式，數據採集於數據分析並不在同一個界面，當數據採集完成以後，將其提交給協議分析界面，不事後來發現，在該界面顯示數據的同時，主界面也在同步顯示數據，後來發現是由於傳值是應用類型的問題，因此在第二版本中取消了該種方式。

圖1.8 NetAnalzyer1.3數據採集界面

本次另外一個特色就是完善了載荷數據的提取，提供了不一樣編碼方式的轉換，考慮到該軟件應用於網絡層與傳輸層，因而並無花更多的時間去處理應用層協議的數據提取功能。本次數據包分析依然使用最初的分析結構，可是對其中的結構作了一些調整，使其更加符合協議中的分佈。

NetAnalyzer的第一個版本是在2011年1月初作的，後來陸續作了一點小修改，直至9月一直在使用該版本，而在功能方面，近乎少的可憐，其實在此期間一直打算從新構建NetAnalyzer但一直停留在頭腦中。後來從新設計念頭是由於假期在和老師作項目的時候，發現本身的一些軟件設計方法，有很大的問題，如：急於編碼，不作前期分析，軟件層次模糊，數據抽象能力不夠等。這也讓本身意識到軟件開發的真正意義。

在9月份中旬開始了NetAnalyzer第二版的前期設計，在總結了上個版本的基礎上，規劃了架構方式，本次使用組件方式來處理處理不一樣的任務。固然此次仍是沒有寫文檔，只是作了一點小小的規劃就開始，這也是後來整個軟件愈來愈很差維護的緣由。過再後來的設計中逐步又分離出了了一些組件，從而下降了資源的佔用率。並將某些組件製做爲獨立的工具，供系統外直接調用，如流量監控工具，編碼轉換工具，應用層協議配置工具等，而對於一些組件則須要在不一樣的工具中或主系統中被調用，因此將這些也以組件的方式分離出來，供給不一樣的工具使用，如：過濾表達式配置對話框，異常信息發送對話框等。

圖1.9 NetAnalyzer2.2主界面

圖1.10 NetAnalyzer2.2 數據分析界面

而事實上，目前已經實現的好多功能並不在開始設計的計劃以內，然而隨着時間的積累，與本身對種種需求的分析，故不斷的增長了相關的功能，在軟件工程中，在開始製做軟件的時候是要作需求分析，然而本身由於並沒用這樣的條件，故所增長的功能都只是本身使用的過程當中而逐漸發現的，其實曾經在製做版本中增長了用戶留言功能，以方便用戶回傳本身的想法，然然後來在考慮到安全問題，便放棄了（後面會講到），固然在最新的版本中已經解決了安全問題。

第二版本的NetAnalyzer已經徹底脫離了抓包軟件的概念，按如今的構建結構，整個能夠稱之爲系統環境。由於本次的設計除了最初目標的網絡數據採集，協議分析等，增長流量監控，後臺數據採集，編碼轉換等一系列輔助工具，對於流量監控，雖然曾經出現過，可是，在本次的設計中，流量監控已經成了一個獨立的體系，隨着流量記錄文件的加入，該工具已經能夠獨立使用了。

圖1.11網絡流量監控工具

經過文件方式記錄網絡狀態，則須要專用的文件解釋器處理相關的數據，由於解釋器與流量監控工具大同小異故在此不作截圖。

另外一個能夠獨立使用的工具則是編碼轉換工具，給工具在一開始只是爲了輔助主系統完成TCP重組以後處理轉換載荷數據編碼問題而設立的工具。再後來屢次斟酌下最終以獨立工具的方式提供使用，而在主系統中則是經過提供接口而啓動傳值的。這樣能夠方便不一樣狀況使用。該工具提供了Base64 、URL、HTML、等編碼與解碼方法，而且提供ASCII、GB23十二、UTF-八、Unicode等字符編碼方式，在最新版本中增長了MD5消息摘要功能，可分別對字符串和文件進行摘要信息提取。

圖1.12 編碼工具

對一些共享使用的組件這裏只是用過濾表達式配置窗口說明，該組件並不能獨立執行，須要加載在其餘工具之上，它只提供數據通訊接口，與調用方式，該配置窗口提供兩種方式，直接輸入方式和填寫方式，直接輸入方式，適合於熟悉Winpcap過濾表達式格式的人員，這樣能夠寫出功能複雜的過濾表達式，在界面上提供了表達式設置規則的連接，對於不懂的用戶也能夠直接學習使用。而填寫方式則適合入門級人員，經過幾個選項，輸入指定的一些參數，則可自動生成表達式，使用方便，但只能生成簡單是表達式，但能夠知足通常需求。在完成後點擊「肯定」按鈕，系統開始自動檢查表達式是否符合規範。不是則提示用戶從新設置，若是是則傳入須要的位置，並將該表達式作歷史記錄，以供下次使用，而表達式輸入框對一些關鍵字進行了着色處理，經過不一樣顏色標示不一樣的原語，防止設置出錯和方便出錯檢查。

圖1.13 過濾表達式配置

關於NetAnalyzer的簡介到此爲止，然而則僅僅是序章。而咱們也僅僅觸及其冰山一角。在上面的介紹中，主要側重了系統的總體的部分，再後來介紹了一些工具組件等，也只是停留在表面上而已，雖然如今人們愈來愈注重用戶體驗，但做爲一款給專業人員使用的軟件，更應該注重的是效率與可用性。在後面的講解中咱們將逐步將這些功能的實現方式展現出來，從而在原理上深刻MetAnalyzer。

總結

「玉不磨，不成器」，軟件開發更是如此，在網絡數據採集工具開發過程當中，從概念到一個影響，再到一個原始實體，最後到一個完整的軟件，並不是朝夕之功，在大約一年半的時間中，本身全身心投入，不斷的改進，不斷的尋找解決方案，也許進展緩慢，可是至少每次在本身手中產生的工具都比上一個強，這就是進步。其實不是此次硬逼着本身寫這本書，本身還真不知道本身盡力瞭如此之多的困難，若是當時沒那麼高的熱情去投入其中或知足於現狀，也許就沒有後續的版本，更沒有這本書的產生。

NetAnalyzer而今已是2.9的版本，而上一次的發佈是2014年的9月份，功能相比當時已經豐富了不少，能力也強大了不少，可是更新也愈來愈慢了，再從2013年6月大學畢業以後只發布了兩個簡單的版本，也許是工做的忙碌，也許是隻是少了那份狂熱的追求，以致於如今雖然有不少想法，卻也只停留在想象之中，而立刻2015年的9月也來了，特意發一個系列去記念一下那年的熱情。