各位做維護的同事經常會聽到用戶對網速太慢的抱怨，但是網速慢的原因有很多，比如軟件設置不當，網絡設備故障，物理鏈路問題，感染病毒等，而單單從用戶的故障描述里面很難有進一步的發現，所以也許大家一時也不知道從何下手。 　　
　　Sniffer是一個非常好的流量分析工具，利用它我們可以實際了解到當前網絡中正在發生的具體流量，并且通過Sniffer的專家系統以及進一步對數據包的解碼分析，我們可以很快的定位網絡故障，確認網絡帶寬的瓶頸，在故障發生前及時消除網絡隱患，這樣能給我們日常的維護工作帶來很大的方便，也使得我們的維護工作處于主動地位，不會再只有接到用戶故障投訴后才能處理故障，在時間和效率上都不能很好的讓用戶滿意。下面是借助Sniffer對我某地市分公司出口流量做的一個簡單的流量分析，沒有什么很深的技術含量，也并不需要太深的專業知識，希望能對大家日常的維護工作有一定啟發。 分析目標：了解目前帶寬實際利用率，檢查有無網絡隱患。 分析方法： 在核心交換機上做端口鏡像，利用sniffer抓包。 測試時間：2005.5.17 10:00～10：10 測試地點：中心機房 抓包開始時間：5.17 10:20 抓包持續時間：16s 數據包個數：88865 平均帶寬利用率：7％ 1，首先我們了解一下網絡中協議的分布情況，通過sniffer的Protocol Distribution功能可以直觀的看到當前網絡流量中協議分布圖： 從上面可以很明顯看出，HTTP應用流量最大占63％，其次就是NetBios流量占35％。 了解協議分布情況以后，我們再找到網絡中流量最大的主機，因為流量越大也就意味著對網絡的影響也就越大，利用sniffer的Host Table的餅視圖功能可以容易的找到流量最大的機器，如下圖所示： 可以看到219.72.238.88，219.72.237.201這兩臺主機在目前我們網絡內部流量較大，分別占16.52%和15.97％。進一步利用HostTable功能的Outline視圖，可以發現這兩個地址流量的90％都是HTTP流量，如下圖所示： 我們可以從上圖注意到，219.73.238.88這個主機上行流量要明顯小于下行的流量，而219.72.237.201這個主機則是上行流量明顯大于下行流量，通過確認219.72.238.88為一臺Web服務器，219,72,237,201則是其他公司托管我在我公司的一臺服務器，所以到這一步我們就可以大致知道這兩個主機當前正在進行的網絡活動。 　　同時我們要注意的就是每個地址的收發包數量是否正常，即是否收發之間存在較大差異，如果只收不發或者只發不收，那很可能就意味著這個主機的當前流量有異常（例如受到SYN***），我們可以進一步通過sniffer提供的Decode功能對捕獲的數據包進行解碼，來分析具體的數據包內容。比如我們通過定義一個過濾器來查看上面兩個地址的具體數據流量,如下圖所示： 我們可以看到在這些HTTP應用里面，TCP的三次握手都很完整，排除了惡意的SYN***行為，都是正常的HTTP流量。 　　附:也許從這次的例子看不出有什么異常，實際上在大部分的情況下一旦網絡出現異常，可以在第一時間直觀的通過HostTable功能找到問題的根源。 　　2，查看sniffer的專家系統，發現存在大量的Local Routing（本地路由）告警，sniffer中對此告警的解釋為：Two DLC stations on the same segment are communicating via a router. Packets are being transmitted via the router rather than directly from one DLC station to the other（大致意思是兩個屬于同一網段的主機之間通過路由器通信，數據包通過路由器發送而不是直接在兩主機間轉發）。并提示可能原因為路由表設置不當。(如下圖所示) 通過查看告警來源，發現流量均為來自私網地址的139端口連接，通過sniffer的Protocol Distribution的Packet排序可以看出Netbios協議流量占所有流量的80％，即當前網絡中80％的數據包都是Netbios協議數據包。如下圖所示： 很明顯出現這種現象是不正常的，我們可以在所捕獲的數據包里定義過濾器，選擇只查看Netbios協議，進一步了解具體的數據包內容（如下圖所示）： 發現存在大量網內的私網地址發起的139端口連接請求，而且全都是TCP的SYN請求，TCP的三次握手只有一次，很可能受到了SYN***。數據包大小都是62字節，而且每個數據包之間發送間隔都在1ms內，排除人為發起TCP請求的可能。通過觀察數據包的源，目的IP地址，發現源地址很分散，目的地址均為實際并不存在的IP地址，但根據我公司IP地址規劃都屬于某地市分公司私網地址段。根據流量的特征，初步判斷為私網用戶感染蠕蟲病毒，病毒通過139端口與大量虛假IP地址建立連接，造成網絡中存在大量短數據包，嚴重降低網絡運行效率。 同時我們還發現當前網絡對每一個TCP連接請求進行不斷的重傳，直到TTL值過期之后才被丟棄。通過跟蹤查看某個地址的重傳數據包，發現一個奇怪的現象：
上面兩幅截圖是Sniffer捕獲的172.17.60.126對172.17.46.14發起TCP連接請求的兩個數據包，可以看到在數據包的網絡層里面有兩個選項：Identification，Time to live（TTL）。Identification是用來唯一標識主機發出的每個數據包的，正常情況下每個數據包的ID都不一樣，而TTL是用來限制數據包在網絡中經過的跳數的，每經過一跳TTL值就減1，直到TTL值為0的時候數據包就被丟棄，主要是防止當網絡中出現環路時數據包的循環傳送。而在上圖可以看到，這兩個數據包的Identification是一樣，只是TTL值相差1。這就表示這兩個數據包實際上是同一個數據包（因為ID一樣），只不過被發出去以后又被送回來了。到了這里，我們可以初步懷疑是否出現了路由環路。 進一步在中心機房嘗試tracert172.17.46.14這個IP地址跟蹤路由，發現路由在中心機房交換機和地市交換機之間形成環路，數據包在環路不斷往返，直到TTL值過期才被丟棄。 通過查看中心機房交換機路由表，發現配置了靜態路由，將172.17.44.0/22這段地址指向了地市分公司交換機，而在分公司交換機配置的私網地址池里面只配置了172.17.44.0/23，并沒有包括172.17.46.0這段地址，所以在里面找不到對應的路由，故將流量通過默認路由又傳回至中心機房，從而形成環路。檢查針對其他網段的異常流量時同樣出現這種情況。所以，當感染蠕蟲病毒的機器與大量實際并不存在的地址建立139連接時，借助靜態路由設置不當的漏洞，這些數據包在網絡中循環傳送，消耗了大量網絡帶寬，降低了網絡的運行效率。 更多資料請登陸中國協議分析網論壇[url]www.cnpaf.net[/url]查看。所以針對以上流量分析，我們可以得出以下結論： ⑴目前網絡中存在大量中毒機器，并且正在試圖通過局域網感染其他主機，最好能及時通知客戶做殺毒處理，消除網絡隱患。 ⑵出于安全方面的考慮，建議拒絕基于139端口的流量。 ⑶中心機房交換機上需要更改靜態路由，取消路由環路。
　　二，總結 上面的文章只是一個拋磚引玉，其實Sniffer還有很多強大的功能，希望大家能在平時多多使用，互相交流經驗，進一步提高我們的日常維護工作效率。本文出自 51CTO.COM技術博客

轉載于:https://blog.51cto.com/tonyjcch/235953

總結

以上是生活随笔為你收集整理的借助Sniffer分析网络流量的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。