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