Ethereal是一個開放源碼的網絡分析系統，也是是目前***的開放源碼的網絡協議分析器，支持Linux和windows平臺。Ethereal起初由Gerald Combs開發，隨后由一個松散的Etheral團隊組織進行維護開發。它目前所提供的強大的協議分析功能完全可以媲美商業的網絡分析系統，自從1998年發布最早的0.2版本至今，大量的志愿者為Ethereal添加新的協議解析器，如今Ethereal已經支持五百多種協議解析。

很難想象如此多的人開發的代碼可以很好的融入系統中；并且在系統中加入一個新的協議解析器很簡單，一個不了解系統的結構的新手也可以根據留出的接口進行自己的協議開發。這都歸功于Ehereal良好的設計結構。事實上由于網絡上各種協議種類繁多，各種新的協議層出不窮。一個好的協議分析器必需有很好的可擴展性和結構。這樣才能適應網絡發展的需要不斷加入新的協議解析器。

1 Ethereal的捕包平臺

網絡分析系統首先依賴于一套捕捉網絡數據包的函數庫。這套函數庫工作在在網絡分析系統模塊的***層。作用是從網卡取得數據包或者根據過濾規則取出數據包的子集，再轉交給上層分析模塊。從協議上說，這套函數庫將一個數據包從鏈路層接收，至少將其還原至傳輸層以上，以供上層分析。

在Linux系統中， 1992年Lawrence Berkeley Lab的Steven McCanne和Van Jacobson提出了包過濾器的一種的實現，BPF（BSD Packet Filter）。Libpcap是一個基于BPF的開放源碼的捕包函數庫。現有的大部分Linux捕包系統都是基于這套函數庫或者是在它基礎上做一些針對性的改進。

在window系統中，意大利人Fulvio Risso和Loris Degioanni提出并實現了Winpcap函數庫，作者稱之為NPF。由于NPF的主要思想就是來源于BPF，它的設計目標就是為windows系統提供一個功能強大的開發式數據包捕獲平臺，希望在Linux系統中的網絡分析工具經過簡單編譯以后也可以移植到windows中，因此這兩種捕包架構是非常現實的。就實現來說提供的函數調用接口也是一致的。

Ethereal網絡分析系統也需要一個底層的抓包平臺，在Linux中是采用Libpcap函數庫抓包，在windows系統中采用winpcap函數庫抓包

2層次化的數據包協議分析方法

取得捕包函數捕回的數據包后就需要進行協議分析和協議還原工作了。由于OSI的7層協議模型，協議數據是從上到下封裝后發送的。對于協議分析需要從下至上進行。首先對網絡層的協議識別后進行組包還原然后脫去網絡層協議頭。將里面的數據交給傳輸層分析，這樣一直進行下去直到應用層 
   Ip
    | \
  Tcp udp
  |   \
HTTP   TFTP

由于網絡協議種類很多，就Ethereal所識別的500多種協議來說，為了使協議和協議間層次關系明顯。從而對數據流里的各個層次的協議能夠逐層處理。Ethereal系統采用了協議樹的方式。上圖就是一個簡單的協議樹。如果協議A的所有數據都是封裝在協議B里的，那么這個協議A就是協議B是另外一個協議的兒子節點。

我們將***層的無結構數據流作為根接點。那么具有相同父節點的協議成為兄弟節點。那么這些擁有同樣父協議兄弟節點協議如何互相區分了？Ethereal系統采用協議的特征字來識別。每個協議會注冊自己的特征字。這些特征字給自己的子節點協議提供可以互相區分開來的標識。比如tcp協議的port字段注冊后。

Tcp.port=21就可以認為是ftp協議， 特征字可以是協議規范定義的任何一個字段。比如ip協議就可以定義proto字段為一個特征字。

在Ethereal中注冊一個協議解析器首先要指出它的父協議是什么。另外還要指出自己區別于父節點下的兄弟接點協議的特征。比如ftp協議。在Ethereal中他的父接點是tcp協議，它的特征就是tcp協議的port字段為21。

這樣當一個端口為21的tcp數據流來到時。首先由tcp協議注冊的解析模塊處理，處理完之后通過查找協議樹找到自己協議下面的子協議，判斷應該由那個子協議來執行，找到正確的子協議后，就轉交給ftp注冊的解析模塊處理。這樣由根節點開始一層層解析下去。

由于采用了協議樹加特征字的設計，這個系統在協議解析上由了很強的擴展性，增加一個協議解析器只需要將解析函數掛到協議樹的相應節點上即可。

3 基于插件技術的協議分析器

所謂插件技術，就是在程序的設計開發過程中，把整個應用程序分成宿主程序和插件兩個部分，宿主程序與插件能夠相互通信，并且，在宿主程序不變的情況下，可以通過增減插件或修改插件來調整應用程序的功能。運用插件技術可以開發出伸縮性良好、便于維護的應用程序。它著名的應用實例有：媒體播放器winamp、微軟的網絡瀏覽器ie等。

由于現在網絡協議種類繁多，為了可以隨時增加新的協議分析器，一般的協議分析器都采用插件技術，這樣如果需要對一個新的協議分析只需要開發編寫這個協議分析器并調用注冊函數在系統注冊就可以使用了。通過增加插件使程序有很強的可擴展性，各個功能模塊內聚。

在協議分析器中新增加一個協議插件一般需要插件安裝或者注冊，插件初始化，插件處理3個步驟，下面以Ethereal為例進行分析如何利用插件技術新增加一個協議分析模塊。

Ethereal由于采用插件技術，一個新加入開發的程序員開發一種新的協議分析模塊的時候不需要了解所有的代碼，他只需要寫好這個協議模塊的函數后，寫一個格式為proto_reg_handoff_XXX的函數，在函數內調用注冊函數告訴系統在什么時候需要調用這個協議模塊。

比如
你事先寫好了一個名為dissect_myprot的協議解析模塊，它是用來解析tcp協議端口為250的數據。可以利用這些語句來將這個解析器注冊到系統中
proto_reg_handoff_myprot(void)
{
    dissector_handle_t myprot_handle;

    myprot_handle = create_dissector_handle(dissect_myprot,
      proto_myprot);
    dissector_add("tcp.port", 250, myprot_handle);
}
這段代碼告訴系統當tcp協議數據流端口為250的時候要調用dissect_myprot這個函數模塊。
在Ethereal中有一個角本專門來發現開發者定義的類式proto_reg_handoff_xxx這樣的注冊函數名，然后自動生成調用這些注冊函數的代碼。這樣開發者不需要知道自己的注冊函數如何被調用的。這樣一個新的協議分析模塊就加入到系統中了。

由于采用了插件方式，Ethereal良好的結構設計讓開發者只需要關系自己開發的協議模塊，不需要關心整個系統結構，需要將模塊整合進系統只需要寫一個注冊函數即可，連初始化時調用這個注冊函數都由腳本自動完成了。正是因為有很好的體系結構，這個系統才能夠開發出如此多的協議解析器

盡管Ethereal是目前***的開放源碼的網絡分析系統，但Ethereal仍然有一些可以改進的地方，一個優秀的網絡分析器，盡可能的正確分析出數據協議和高效的處理數據是兩個重要的指標。在協議識別方面Ethereal大多采用端口識別，有少量協議采用內容識別。

這就讓一些非標準端口的協議數據沒有正確解析出來。比如ftp協議如果不是21端口的話，Ethereal就無法識別出來，只能作為tcp數據處理。另外對于內容識別式。Ethereal是將所以內容識別的函數組成一張入口表。每次協議數據需要內容識別時，按字母順序逐個調用表里的每個識別函數。

比如對于識別yahoo massanger協議。主要是看數據前幾個字節是不是’ymsg’.由于協議名為y開頭。所以當識別出協議時已經把所有內容識別函數調用了一遍。這些都是由于Ethereal沒有實現tcp協議棧，無法做到流級別的識別。導致在協議識別方面有點缺陷。