第一次寫技術相關的部落格，不足之處還請擔待并告知。
在開始之前，先簡單介紹一下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等，并結合已經學到的知識，也能做一些簡單的協定分析了。
貌似一切都可以開始了，于是開始去嘗試看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、GB2312、UTF-8、Unicode等字元編碼方式，在最新版本中增加了MD5消息摘要功能，可分别對字元串和檔案進行摘要資訊提取。
圖1.12 編碼工具
對一些共享使用的元件這裡隻是用過濾表達式配置視窗說明，該元件并不能獨立執行，需要加載在其他工具之上，它隻提供資料通信接口，與調用方式，該配置視窗提供兩種方式，直接輸入方式和填寫方式，直接輸入方式，适合于熟悉Winpcap過濾表達式格式的人員，這樣可以寫出功能複雜的過濾表達式，在界面上提供了表達式設定規則的連結，對于不懂的使用者也可以直接學習使用。而填寫方式則适合入門級人員，通過幾個選項，輸入指定的一些參數，則可自動生成表達式，使用友善，但隻能生成簡單是表達式，但可以滿足一般需求。在完成後點選“确定”按鈕，系統開始自動檢查表達式是否符合規範。不是則提示使用者重新設定，如果是則傳入需要的位置，并将該表達式做曆史記錄，以供下次使用，而表達式輸入框對一些關鍵字進行了着色處理，通過不同顔色标示不同的原語，防止設定出錯和友善出錯檢查。
圖1.13 過濾表達式配置
關于NetAnalyzer的簡介到此為止，然而則僅僅是序章。而我們也僅僅觸及其冰山一角。在上面的介紹中，主要側重了系統的整體的部分，再後來介紹了一些工具元件等，也隻是停留在表面上而已，雖然現在人們越來越注重使用者體驗，但作為一款給專業人員使用的軟體，更應該注重的是效率與可用性。在後面的講解中我們将逐漸将這些功能的實作方式展示出來，進而在原理上深入MetAnalyzer。
總結
“玉不磨，不成器”，軟體開發更是如此，在網絡資料采集工具開發過程中，從概念到一個影響，再到一個原始實體，最後到一個完整的軟體，并非朝夕之功，在大約一年半的時間中，自己全身心投入，不斷的改進，不斷的尋找解決方案，也許進展緩慢，但是至少每次在自己手中産生的工具都比上一個強，這就是進步。其實不是這次硬逼着自己寫這本書，自己還真不知道自己盡力了如此之多的困難，如果當時沒那麼高的熱情去投入其中或滿足于現狀，也許就沒有後續的版本，更沒有這本書的産生。
NetAnalyzer而今已經是2.9的版本，而上一次的釋出是2014年的9月份，功能相比當時已經豐富了很多，能力也強大了很多，但是更新也越來越慢了，再從2013年6月大學畢業之後隻釋出了兩個簡單的版本，也許是工作的忙碌，也許是隻是少了那份狂熱的追求，以至于現在雖然有很多想法，卻也隻停留在想象之中，而馬上2015年的9月也來了，特地發一個系列去紀念一下那年的熱情。