Ominpeek介紹
Ominpeek 官網: http://www.wildpackets.com
Ominpeek一款網絡抓包工具，或者說網絡協議分析工具。不是管是前端開發、后端開發或都測試人員。為了解數據是否正常的傳遞，經常會用到網絡數據包攔截軟件來進行分析。
Ominpeek 與我們常用的HttpWatch、Fildder 略有不同。HttpWatch 是基於瀏覽器的插件，攔截HTTP的數據包，而Ominpeek是基於網卡底層掃描的。計算機與外界的交流必經過網卡，也就是說它能拿檢測到一切經過網絡的數據。
Ominpeek 是由Wildpackets 公司研發的網絡掃描維護工具，其提供了高效的故障診斷和這定能力，這一特性能夠明顯縮減日常花費大量尋障和排障時間，使我們有精力去完善日常其他的工作以及學習更多的業務知識。它和Sniffer都是功能非常強大的協議分析工具。
界面介紹
了解一個工具從下載使用開始，所以我們先下載安裝一下。關於這款工具除了官網（官網下載要填寫注冊信息，這是我最討厭的），其它的下載地址還真不多。
WildPackets OmniPeek 4.1 下載地址： http://download.pchome.net/internet/tools/detail-33252.html
雖然這4.1版本的早已過時了，但對於我們新手來說，足矣！而且它體積也比最新版的也小了很多。
下載完成之后，安裝過程就不介紹了，對於windows下的軟件安裝一般一路NEXT都能成功安裝。安裝完成后打開軟件。下面以就是打開后的主界面。
網絡統計窗口
界面的左下角的網絡統計窗口有三個刻度盤與相應的數字顯示。
* 網絡使用率（用百分比的方式表示）
* 數據流量（每秒數據包）
* 誤差率（每秒的總誤差）
下表顯示歷史最大（紅線）和平均值（黃線）。
下面我們切換到“Value”選項卡，上表顯示以下信息：
持續時間：此參數顯示經過時間“小時：分鍾：秒：“自從你開始收集監測數據格式。
收到的數據包：此參數顯示收到的數據包從你開始收集監測統計。
接收的字節數：此參數顯示收到的字節從你開始收集監測統計。
組播：此參數顯示包處理多播地址從你開始收集監測統計。
廣播：此參數顯示的數據包廣播地址從你開始收集監測統計。
（注：如果此窗口被不小心關掉了，可以點擊工具欄上的“network statistics”按鈕打開。！）
個人日志窗口
界面的右下角：當程序啟動時，一個日志文件（稱為Peek.log）在Application Data文件夾中創建。
三種類型的事件會被寫入這個日志文件中。
* 程序的啟動或停止，或創建一個新的窗口捕捉。
* 在設置對話框中指定的事件。
* 活動指定發送的日志類型通知
窗口的第一行，用不同的圖標顏色顯示消息總數中的日志和故障的嚴重程度
Messages: 信息總數
白色i ：表示請求成功的信息。
綠色! ：表示輕微型提示（個人理解）
黃色! ：警告信息
紅色x ：錯誤信息
那么我們可以對這些日志做那些操作呢? （點擊某一條信息右鍵出現菜單）
保存登錄：選擇此選項將日志保存為一個文本文件（制表符分隔或逗號分隔值）。
打印日志：選擇此選項可打印的登錄窗口。要更改默認打印設置，選擇打印設置...從“文件”菜單上。
復制：選擇此選項復制單獨的行日志文件為制表符分隔的文本復制到剪貼板。
清除日志：選擇此選項可清除或清空日志文件。
最大日志文件大小：選擇此選項可打開一個對話框，您可以在其中輸入新的日志文件的最大尺寸，以千字節為單位（默認為4MB）。當達到限制時，將刪除舊的日志項，以騰出空間給新的。
自動滾屏：選擇此選項來切換日志的自動滾動功能。
（注：如果不小心關閉了這個窗口，可以點擊工具欄上的View Log 或菜單欄 View > Log Window）
創建一個數據捕捉
你可以在Start Page窗口上點擊“new capture”按鈕，或在菜單欄File > new..
這里可以設置捕獲的名稱，文件保存的位置等。
選擇你要通過哪個網卡進行捕捉，因為我的是筆記本，所以會有有線和無線兩個網卡。你可以用檢測無線網卡的方式，找到被別人設置屏蔽掉的無線信號，檢測誰在偷用你的無線網絡，或者別人無線網絡的加密方式進行破解等。
對於協議包的過濾規則，默認情況下所有協議都進行檢測抓取。
勾選下面協議類型，選擇左邊按鈕表示，只抓取選中的協議。選擇右邊按鈕表示，選中的協議從抓取的協議列表中去掉。
創建完成后，點擊數據捕捉窗口右上角的“Start Capture”按鈕。工具開始抓取所有經過網卡的數據包。點擊“Stop Capture”停止抓取。
Ominpeek能做哪些分析呢？
那么Ominpeek提供了哪些功能來快速的幫助我們對網絡問題進行故障診斷/定位。
1.主機排名，發現網絡中通信量最大的主機，對比故障現象與影響范圍。
2.協議排名，可以對監控的所有協議進行排名，找到使用最多的協議。
3.主機在使用的協議。查看某一主機在使用哪些協議。（在主機排名界面，雙擊某一主機，出現下表）
4. 通過PeerMap網絡分布圖了解主機會話的實時情況
5. 深入解碼分析。發現異常后，可以進行深入的解碼分析。
通過以上步驟可以很多容易發現瀏覽異常的主機，不正常的協議通信以及網絡中實際傳輸的內容。從某些角度來說，使用OmniPeek來做協議分析，真是殺雞用牛刀了。
常見協議分析
下面對一些經見的協議時行簡單的分析（我們在抓到的包中可以雙擊打開抓到的各種協議）：
幀、UDP協議
| Destination: 00:12:00:40:E9:FF | 目的的適配器的mac地址為00:12:00:40:E9:FF |
| Source: 00:E0:81:02:CB:F0Tyan:02:CB:F0 | 傳輸該幀到LAN上的適配器的mac地址為00:E0:81:02:CB:F0 |
| 協議標識域 Protocol Type: 0x0800 IP | 表明封裝協議是IP協議 |
TCP協議
我們都知道TCP協議信息傳遞（三次握手、四次揮手）
| 第一次握手 |
客戶端發送了第一個報文（從IP首部可以看出。202.204.122.236為本機ip） 三次握手的第一個報文 |
| 報文包括了源端口號（Source Port,隨機選擇）和目標端口號（Destination Port）,目標端口號為80，所以客戶端想要請求的服務為HTTP服務。報文還包含了ISN=900514470，客戶端還定義了它能從服務器端接收的MSS，第一個報文不包含ACK，TCP Flags中顯示No Ack. |
| 第二次握手 |
三次握手的第二個報文 |
| 服務器短發送了第二個報文 此報文附帶了SYN和ACK。這個報文有兩個目的：一是確認受到了第一個報文，ack號為905144471=上一個報文的ISN905144470+1服務器端也定義了客戶窗口的大小是wind :8192；二，這個報文也對服務器的報文段進行初始化，定義MSS大小為1448。 |
| 第三次握手 |
三次握手的第三個報文 |
| 它使用ACK標志和和確認字段來確認收到了第二個報文。ACK1302368427=第二個報文的isn值1302368427+1 |
| 第一次揮手 |
四次分手的第一個報文段 |
| 因為訪問的網站為門戶網站www.sina.com所以有很多報文信息，為了是環境更加純凈一點，所以插入了一個新的Filter，限定了本機器端的端口號4075與服務器相連的所有報文，經過篩選，所顯示的報文數量只有十條。 客戶端TCP發送第一個FIN報文段。可以從 圖 8 四次分手的第一個報文段 中看出來。FIN 字段顯示為1。 |
| 第二次揮手 |
四次分手的第二個報文段 |
| 服務器TCP發送第二個報文段。附帶了ACK和FIN，其中ACK1542437602=1542437601+1 |
| 第三次揮手 |
四次分手的第三個報文段 |
| 服務器TCP沒有更多的數據發送時就發送發送第三個報文段，FIN報文段。從圖中可以看TCP flag中出FIN字段的值為1. |
| 第四次揮手 |
四次分手的第四個報文段 |
| 客戶TCP發送第四個報文段，ACK報文段。Ack Number: 3739309153=3739309152+1 |
IP協議
| Version: 4 | 版本為IPv4 |
| Header Length: 5 ( 20 bytes) | IP題頭通常大小為20字節，該域值按照4字節的柏樹提供。分析器用4字節乘以該值得到正確的IP題頭長度值20字節 |
| Differentiated Services: %00000000 | 服務類型域。以便使不同類型的ip數據報能相互區別開來。 |
| Total Length: 60 | ip數據報的總長度（首部加上數據），該字段長為16bit |
| Identifier: 30612 | 與ip分片有關，同一個ip數據報分片成不同的數據報，Identifier是相同的。 |
| Fragment Offset: 0 ( 0 bytes) | 片位移為0 |
| Time To Live: 64 | 該數據報不會永遠在網絡中循環，每次經過一台路由器時，該字段減1。若TTL字段為0，則該數據報必須丟棄。 |
| Protocol: 1 ICMP - Internet Control Message Protocol | 該字段僅在數據報到大其最終目的地才會用到。該字段指明了IP數據報的數據部分應該 交給哪個運輸層的協議。 |
| Header Checksum: 0x77BA | 將首部中的每兩個字節當作一個數，用反碼運算對這些書求和 |
| Source IP Address: 202.204.122.2360A071DF18F2E4E6 |
源IP地址 |
| Dest. IP Address: 202.204.122.237 | 目的IP地址 |
| 數據字段：ICMP - Internet Control Messages Protocol | 數據字段也可以承載其他類型的數據，這個字段就承載了ICMP報文段。 |
HTTP 協議
http請求報文
| HTTP Command: GET | 當瀏覽器請求一個對象的時，使用GET方法 |
| URI: /img/baidu_logo.gif | 在URL字段填寫該對象的URL地址本報文中URL請求對象是/img/baidu_logo.gif |
| HTTP Version: HTTP/1.1 <CR> <LF> .. | 瀏覽器實的是HTTP/1.1版本協議 |
| Connection: Keep-Alive <CR> <LF> | 瀏覽器告訴服務器希望保活 |
| Host: www.baidu.com <CR> <LF> . | 定義了目標所在的主機。 |
| User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; InfoPath.2; CIBA) <CR> <LF> . |
定義用戶代理，即向服務器發送完被請求瀏覽器的類型。這里的瀏覽器類型是Mozilla/4.0 |
| Accept-Language: zh-cn <CR> <LF> . | 表示了如果服務器有這樣的對象的話，用戶想要得到該對象的zh-cn版本，否則使用服務器的默認版本。 |
http響應報文
| HTTP Version: HTTP/1.1 |
協議版本 |
| HTTP Status: 200 |
狀態碼 |
| HTTP Reason: OK <CR> <LF> . |
相應狀態信息，一切正常，即服務器已經找到並正在發送所請求的對象 |
| Server: Apache/1.3.27 <CR> <LF> |
表明該報文是由一個Apache WEB服務器產生的。 |
| Last-Modified: Wed, 30 Jul 2008 10:23:00 GMT <CR> <LF> |
對象創建或者左后修改的日期和時間 |
| Content-Length: 1489 <CR> <LF> |
表明了被發送對象的字節數 |
| Content-Type: image/gif <CR> <LF> <CR> <LF> .. |
表明了實體中的對象是gif圖像。 |
| Binary Data: (1130 bytes) |
報文的主體，即它包含了所請求的對象本身。 |
當然還有許多協議，如 FTP、SMTP\POP3 、DNS、ARP等很多協議。由於篇幅原因，不再詳細介紹了。
親！如果感覺本文還行，右下角點左噢！