1、綜合實驗設計指導書20014010-31 韓文君一、實驗名稱：網絡流量監測及分析二、實驗目的：1、觀察網絡中出現的各種數據包的結構，封裝格式，掌握數據包的分析方法。通過分析數據包格式，結合網絡課程所學知識，達到驗證所學，學以致用的目的。2、了解流量監測的基本方法和采樣統計分析過程；掌握流量監測中的采樣方法，包括選擇監測采樣技術，如何設置采樣點，選擇采樣時間以及采樣數據存儲區大小的設定等3、分析監測到的網絡流量，并做出分析報告。通過從不同的角度對數據進行分析，得到實驗結論和利用網絡知識解釋分析流量變化原因。例如，可從以下角度：數據鏈路層：廣播、單播，分析廣播風暴；報文長度，分析各種長度報文所占比

2、例，計算報文平均長度等。網絡層：源和目的；分析內外網進出流量，分析焦點節點流量比例及變換情況；分析ICMP報文，網絡開銷比例等。傳輸層：分析面向連接協議與面向無連接協議的使用情況。應用層：分析各種典型應用的使用情況。主要的分析方法可以用到：流量隨時間變化曲線，及對高峰低谷數據的分析；分析各成分在流量中的比例，及隨時間變化曲線等；求平均值及比較各成分均值。三、實驗要求1、實驗者在了解實驗目的后，自行設計監測計劃，和按計劃取得數據。自己制定數據分析方法和分析角度，得出實驗結論。2、完成至少4種類型的數據包的分析，列出每個字段的含義。除了給出該字段的數值外，還要指出字段值表達了怎樣的信息。3、做出全

3、天數據總流量變化圖。4、至少從3種不同角度對流量進行分析。5、完成整個監測計劃中每天流量變化的比較分析分析的重點不是各項統計數據本身，實驗者需要完成對這些數據值的大小、關系、變化趨勢等方面的進行分析和評價，進一步得出網絡流量特點的結論，并嘗試揭露形成相應特點的原因。四、實驗原理1、設置監測點在網絡中不同的位置設置監測點，監測結果和結論將有很大差別。如在網絡內設置監測點可以觀察網內通信的情況，在網間設置檢測點則主要觀察數據進出網絡的情況。由于監測目標的子網內采用了交換機，網內監測將很難觀察通信情況，本設計將主要觀察網間通信，將監測點設置在通信學院二級子網與校園主干網相接的線路上。校園主干網通信學

4、院二級子網RouterBay 350監測點2、網絡監測方法：（1）利用HUB進行監測：集線器（HUB）本質上是一個多端口中繼器，即從任何一個工作站傳輸的數據都被HUB接收，并在其他所有端口上轉發。我們可以利用集線器的這種總線特性，在監測點放置一個集線器，集線器上的兩個端口分別接被監測線路的兩端，利用第三個接口，接入監測機，觀察經過被監測線路上的數據。RouterBay 350監測機HUB利用集線器監測的主要缺點是：被監測線路傳輸速率為100Mbps，而集線器多工作在10Mbps，將使被監測線路降速；此外，如果監測機也在主動發送發送數據，將對被監測線路造成干擾。（2）防火墻方式可在監測機上設置兩

5、張網卡，分別接被監測線路兩端，在被監測線路上的數據就要經過監測機。該方式與防火墻的工作原理一樣。RouterBay 350監測機本方法的優點是可以工作在100Mbps，并保證所有的數據都能被監測到。但被監測線路受監測機性能影響很大，監測機即要緩存所有的數據，又要不斷轉發，如果監測機性能較低，將直接造成線路降速。（3）Monitor方式部分品牌的交換機具有Monitor功能，可以將某個端口的數據同時拷貝一份到映象端口。我們在本設計利用Bay350交換機的這項功能，將交換機上與通信學院連接的端口上進出的數據復制到監測端口，達到監測目的。RouterBay 350監測機Monitor本方法的優點是：

6、不會改變網絡拓撲，不對被監測線路造成影響。缺點是：僅有部分廠商的產品支持這一功能；在監測全雙工端口時，如果雙向數據流量之和超過100Mbps，則監測機將無法準確監測。3、監測機在監測機上將網卡的全接收功能打開，它可以接收所有數據并存盤和分析。監測機的內存大小和CPU的性能都會影響從網卡讀取數據的速度，一旦監測機無法及時從網卡讀取數據，將造成丟包，影響監測的準確性。但是不能為了節約內存而將采樣時間減小，如果采樣時間過小，如小于10秒，則樣本值并不能反映正確的流量。4、監測軟件：實驗中使用sniffer軟件來監測數據，該軟件還能對樣本進行初步的統計分析。實驗者可以充分利用軟件的統計功能獲得各項數據

7、，實驗者重點需要完成對這些數據值的大小、關系、變化趨勢等方面的分析，以得出網絡流量特點的結論，并嘗試揭露形成相應特點的原因。五、實驗方法在選定的監測點；利用交換機的Monitor功能和監測軟件獲取監測數據；多次監測，進行采樣、統計、比較和分析。六、實驗進度安排總時間為兩星期，共10天。第一天，了解設計任務要求、熟悉實驗環境，分組及推選組長，制定監測計劃第二天，進行預監測，熟悉監測軟件第三天第七天，按計劃監測第八天第九天，完成實驗報告第十天，組織答辯。七、實驗數據記錄本次實驗采樣時間是2004-3-29上午8：30至12：10，中午休息時間未采樣，下午2：30至6：30，總采樣時間為8小時左右，

8、每隔5分鐘采樣一次，采樣得文件92個，每個文件大小為12M。上午10點之前每個文件采樣時間為1分30秒左右，可見上網的人比較少；10點以后采樣時間為40秒左右，說明上網的人開始增多；下午網絡流量增加，每個文件采樣時間縮短，30秒左右就可以采樣得到一個12M文件。八、實驗數據分析1）流量分析流量隨時間變化圖如下所示： 這是一天來數據總的流量變化圖，從圖中我們可以看出，網絡在第10個采樣點開始既9點15左右出現第一個小高峰，而后出現短暫回落，繼而繼續上升，分析原因可能是在辦公室和教研室上班的人逐漸增加，并都開始利用網絡所致。在10點50左右出現第2個小高峰，到了11點15左右網絡出現最高峰，到了1

9、1點50時網絡出現底峰，可能由于下班午餐的原因導致數據流量偏低。下午網絡流量在14點30左右開始迅速提升到一個最大值并保持在這一水平，起伏不是很大。17點5分左右網絡流量出現極大值，然后又迅速下降，分析原因可能是部分站點之間的通信已經完成，因此網絡流量驟減。到17點55再次出現峰值。分析原因可能是部分老師或研究生上完下午第二節課回到了教研室，開始使用網絡。而后網絡流量出現緩慢回落，可能因為大家都去吃飯的緣故。2）網絡利用率分析 總體來看，全天的網絡流量呈上升趨勢，到18點以后才略有減退。與網絡流量相關的一個參數便是網絡的平均利用率（如下圖所示），網絡的平均利用率計算公式為 平均利用率網絡流量/

10、網絡帶寬。 所以網絡的平均利用率應該和流量成正比，這也在上圖中基本反映出來。但是我們發現整個平均使用率的曲線和流量的曲線的變化程度并不是完全相同，這是因為我們將網絡帶寬是一個非常大的數字（100M），所以在除了這樣大的一個數據后，流量變化比較小的時間段的平均利用率的曲線將變的很平緩，而在流量變化很劇烈的時間段，平均利用率的曲線將變的非常陡峭。這就是兩張圖表出現一個差異的根本原因。3）通信主機源分析8：309：15此時正是網絡流量在上午的高峰期，通信還是主要集中在10：00此時的網絡流量不再是主要集中在2臺主機之間，而是由多臺主機之間的通信構成，這是的網絡流量也不如9：15分左右。我通過比較推測

11、，可能主要是因為4）對幾種重要報文類型的分析對從92個采樣點的分析來看，其主要使用的數據包類型有IP數據包，TCP、UDP數據包和ICMP數據包，下面對這四種數據包作一些分析： 在整個實驗過程中，我們可以觀察到IP和TCP報文占據了整個報文數量的決大多數。原因在于我們使用的是TCP/IP協議族。但是現在的網絡不太使用UDP協議，因為UDP是一個無連接、不可靠的運輸協議，所以我們可以從上圖中觀察到UDP報文只是占據了整個報文的一下部分。而面向連接、可靠的運輸協議TCP在這里就使用的非常多。而這里面很特別的現象是ICMP報文的異常波動。ICMP是為了補償IP協議缺少差錯控制和輔助機制而設計的一個協

12、議，為IP層提供差錯報告和查詢，使得IP層上的傳輸能夠盡量的可靠。在一個穩定的，正常使用的網絡中，我們應該觀察到ICMP報文的數量應該為一個比較穩定的值。但是，我們可以在上圖中看到ICMP的數量出現了異常波動，在8：35分出現了一個高峰。這是什么原因呢？我將在下面對這個問題進行詳細的分析。在8：35這個采樣點上，我們可以觀察到ICMP報文的數量遠遠大于其他時間。這是一個非常奇怪的現象，因為在正常的網絡中ICMP的報文數量應該處于一個相對比較平穩的狀況。于是我們利用SNIFFER軟件打開我們采樣得到的數據包，對里面的數據進行分析。4）對幾種數據包進行分析a） 對HTTP（超文本傳輸協議）數據包進

13、行分析：HTTP是主要用在萬維網上存取數據的協議。此協議傳送數據的形式可以是普通正文、超文本、音頻、視頻，等等。它被稱作超文本傳送協議是因為它的效率可以從一個文檔迅速跳到另一個文檔的超文本環境。HTTP的思想非常簡單。客戶給服務器發送請求，它與郵件看起來相似，服務器向客戶機發送相應，看起來象郵件回答，請求和報文攜帶的數據形式類似于MIME格式的信件。b） 對ARP（地址解析協議）報文進行分析：ARP的作用是把邏輯地址映射為物理地址，使用單播和廣播物理地址。任何時候當主機或路由器需要找出另一個主機或路由器在此網羅上的物理地址時，它久發送一個ARP查詢分組。這個分組包括發送站的物理地址和IP地址，

14、以及接收站的IP地址。因為發送站不知道接收站的物理地址，查詢就在網c） 對UDP（用戶數據報協議）報文進行分析：TCP/IP協議族為運輸層指定了兩個協議：UDP和TCP。我先討論UDP。UDP是無連接的，不可靠的運輸協議。它提供進程到進程的通信，沒有給IP服務添加任何負擔。同時，它還完成非常有限的差錯檢驗。該協議非常簡單，開銷非常小。由圖可以看出UDP用戶數據報共有如下的字段：1 源端口號：這是在源主機上運行的進程使用的端口號，它有16位長。圖中的源端口號是306012 目的端口號：這是在目的主機上運行的進程使用的端口號，它也是16位長。圖中的目的端口號為974。3 長度：這是一個16位字段，

15、它定義了用戶數據報的總長度，首部加上數據，圖中長度為111。根據軟件的分析我們看出，在數據報中指定的數據報長度比實際收到的數據報長度要大。因此我們懷疑該數據報在傳輸過程中出錯了。4 檢驗和：這個字段用來檢驗整個用戶數據報出現的差錯。此處檢驗和為AB56，經檢驗無法進行證實，因此確信該數據報傳輸過程中有一部分數據丟失了。5 最后一行給出了該UDP報文的大小為86字節，而實際應該收到的數據應該為103個字節。d） 對TCP（傳輸控制協議）報文進行分析：TCP是面向連接的，可靠的傳輸協議。它工作于傳輸層。傳輸層具有幾種責任。一種責任就是創建進程到進程（程序到程序）的通信，TCP使用端口號來完成這種通

16、信。另一種責任就是在運輸層提供流控制和差錯控制機制，TCP使用滑動窗口協議來完成流控制，它使用確認分組、超時和重傳來完成差錯控制。由圖可以看到TCP報文的源端口和目的端口分別為1187和21（因此這實際上是主機在請求一個FTP服務）。然后給出了序號，然后是首部長和保留和特殊字段，窗口大小為65535，檢驗和為408B，下面是選項及補充字段。1 源端口地址：這是一個16位的字段，它定義了在主機中發送該報文段的應用程序的端口號（1187）。2 目的端口地址：這是一個16位的字段，它定義了在主機中接收該報文段的應用程序的端口號（21）。3 序號：這個32位的字段定義了一個數，它指派給本報文段數據的第一個字節（20EB3186）。4 確認號：這個32位的字段定義了源進程期望從對方接收的報文段的序號，如果報文段的接收端成功的接收了對方發來的序號X，它將確認號定義為X+1（Ox00000000,表示還沒有接受到對發發來的報文）。5 首部長度：這個4字段指出TCP首部共有多少個4字節字。（7）6 保留：這個6字段保留為今后使用。7 其他：有定義控制和窗口大小和緊急指針和選項。九、實驗結論l 網絡流量隨時間變化很大，清晨的流量最小，中午和下午的流量較大。研究生普遍來教研室較晚，中午十二點流量也維持在較高的水平上是因為他們在走的時候沒有關電腦，而