第一篇：網絡連通性測試及網絡配置檢測實驗報告

實驗報告 一．實驗項目名稱:網絡連通性測試及網絡配置檢測 二．實驗環境: ⑴ 已建立得對等網;⑵

⑵與 Iｎterｎet 連接得局域網。

三．實驗目得與要求 ⑴掌握常用ＤOＳ網絡命令得用途及使用方法;⑵會使用常用ＤＯS 網絡命令對網絡進行檢測與配置。

四．實驗過程 1.使用 Ipcｏnfｉg 命令 1)Ipｃonfig 命令

２)Ipconｆｉｇ/all 命令

3）Ipｃｏnfiｇ／reneｗ [adａｐｔer］ 命令

4)Ｉpconｆig/ｒｅlease ［adａpter］ 命令

2、Pｉng 命令 １)pｉnｇ

ＩP 地址

命令

２)ping –t

命令

３)pｉｎg –l lengｔh 命令

4）ｐinｇ –n count 命令

５)ping 1２7、０、０、１命令

６）ｐiｎg ｌｏcalhost 命令

7)piｎg 本機 IP 命令

8)piｎg 網關 IＰ

命令

9）ｐinｇ

命令

3．Trａcert 命令 1)tracert –d 命令

2)tｒacｅｒt ＩP 命令

五．實驗總結 1、在實驗過程中,會出現一些錯誤操作。

1）在 ipconｆig 命令中,將 ipconfig/all 命令輸入成 ipcoｎfig all 命令,出現得結果錯誤。

2）在ｐing 命令遇到得問題。

在參數-ｎ ｃount 中,誤將 cｏunt 當做命令使用,其實就是將它代入為數字得，從而出現結果為:

后面將ｃoｕnt 輸入為數字,才得到正確得結果。

2、在操作其她命令得時候,都顯示正常。

第二篇：網絡管理—基于端口的認證管理配置 實驗報告

網絡管理實驗報告

—基于端口的認證管理配置

學院：計算機學院

班級：

姓名：

學號：

實驗二

基于端口的認證管理配置

【實驗目的】

1、熟練掌握IEEE802.1X的工作原理

2、熟悉AAA身份認證機制

3、掌握RADIUS服務器的配置

【預備知識】

1、AAA概念和基本原理

2、IEEE802.1X

3、配置交換機與RADIUS SERVER之間通訊

【實現功能】

實現LAN接入的安全身份認證。

【實驗拓撲】

PC1 192.168.0.44/24

RG-S2126G

192.168.0.2/24

RG-SAM Server

192.168.0.185/24

【實驗原理】

無線局域網技術標準自1997年公布以來，使人們能更方便、靈活、快捷地訪問網絡資源，擺脫了傳統有線網絡的線纜束縛，隨時隨地的訪問使用Internet網絡。手機、筆記本電腦等個人無線接入終端設備和無線組網設備因為價格不斷下降的大規模普及，越來越多的單位和家庭使用無線局域網進行組網，導致無線網絡安全問題日益凸顯。早期的無線局域網安全防范僅靠WEP協議[1]，即有線等效加密（Wired Equivalent Privacy）保護網絡的安全。由于無線電的開放性，以及WEP技術本身的缺陷導致它特別容易被竊聽和破解。根據資料顯示在一個繁忙的WEP無線網通過嗅探工具可以在短短的數分鐘內破解，并且現在大量的破解工具流傳于網絡并有相關專用設備出售，嚴重危害無線網絡的安全。因此WEP標準在2003年被 Wi-Fi Protected Access(WPA)淘汰，又在2004年由完整的 IEEE 802.11i 標準（又稱為 WPA2）所取代[2]。無線局域網802.11i標準中使用802.1x認證和密鑰管理方式保障無線網絡的安全性。盡管802.11i支持預WPA和WPA2加密下的共享密碼，但如果只使用預共享密碼保障校園網安全，可能面臨密碼外泄后，知道密碼的非授權用戶也能使用校園網絡的安全隱患。

所以校園無線網建設過程中建立一套安全可靠高效的用戶認證機制顯得尤為迫切。本文就在Windows系統平臺下使用免費Radius軟件TekRadius構建基于PEAP技術的Radius認證服務器，保護校園無線局域網的安全進行探討。802.1X概述

IEEE802.1X[3]是IEEE制定關于用戶接入網絡的認證標準，全稱是“基于端口的網絡接入控制”協議，早期802.1x標準僅為有線網設計，并廣泛應用于有線以太網中。最新版802.1X協議針對無線局域網的特點進行修訂，針對無線局域網的認證方式和認證體系結構進行了相關技術優化。IEEE 802.1X協議在用戶接入網絡之前運行，運行于網絡中的數據鏈路層，EAP協議RADIUS協議。

無線局域網中802.1X協議的體系結構包括三個重要的部分：客戶端系統、認證系統和認證服務器，無線局域網中802.1X的拓撲結構如圖1所示。

客戶端系統(Supplicant System)通常是一個用戶終端系統，在無線局域網中即為支持WiFi的筆記本電腦、手機等終端系統，該系統通常無需安裝第三方客戶軟件，windows XP系統內置了相關模塊，能夠發起并完成802.1x協議的認證過程。

認證系統(Authenticator System)即認證者，在無線局域網中就是無線接入點AP(Access Point)或路由器，在認證過程中起“轉發”作用。認證系統只是把客戶端發起的認證信息轉發到認證服務器完成相關認證。

認證服務器(Authentication Server System)通常為RADIUS服務器，在該服務器上存儲用戶名和密碼、訪問控制列表等相關用戶信息。在客戶端發起認證時，由認證服務器對客戶端用戶信息與儲存資料進行鑒別驗證，該申請者是否為授權用戶。PEAP協議

EAP可擴展認證機制(Extensible Authentication Protocol)是一個普遍使用的認證機制，它常被用于無線網絡或點到點的連接中。EAP不僅可以用于無線局域網，而且可以用于有線局域網，但它在無線局域網中使用的更頻繁。

PEAP受保護的可擴展身份驗證協議是由CISCO、微軟和RSA Security聯合提出的開放標準，是WPA2標準[4]中被正式采納的7類認證機制之一。并已被廣泛的運用在各種產品中，為網絡提供安全保障。它在設計上和EAP-TLS相似，但只需要通過服務器端的證書來建立一個安全的傳輸層安全通道（TLS）以保護用戶認證信息的安全。它分兩個階段進行：第一階段建立單項服務器認證的TLS隧道；第二階段在該隧道保護下，對客戶端進行EAP-MS-CHAPv2等基于EAP的方式認證。與EAP-TLS采用的雙向證書驗證方式相比，PEAP較好的在保障無線網絡安全性和認證系統的布署難度之間找到一個平衡點。在校園無線網絡訪問控制中應用基于PEAP技術認證802.1X，可以為無線局域網提供安全可靠的授權訪問控制解決方案。TekRadius系統安裝與配置

TekRADIUS是一個windows下使用的功能強大并免費的RADIUS 服務器軟件，使用微軟SQL數據庫作為支撐數據庫，支持EAP-MD5, EAP-MS-CHAP v2, PEAP(PEAPv0-EAP-MS-CHAP v2)等多種接入認證方式。安裝平臺

1)安裝SQL數據庫設置sa賬戶；Radius默認情況下以sa用戶訪問使用SQL數據庫。

2)安裝TekRadius軟件：從www.tmdps.cn=Servername /K:1024 /V:365 /S:1 /P:443”產生并獲取系統所需數字證書[6]，至此Radius服務器的配置完成。無線AP配置步驟

無線AP配置：登錄Dlink-615無線路由器，依次點擊“安裝→無線安裝→手動無線因特網安裝→設置無線模式為AccessPoint，SSID為WlanTest 安全模式設置為WPA2，密碼類型選擇AES，設置為EAP模式，802.1X中填寫服務器地址、認證端口及通信密碼（與Radius服務器相同）”。PC客戶端配置

在筆記本上打開無線網卡Atheros客戶端程序[7]點擊“配置文件管理→新建，填寫配置文件名，SSID為Wlan（與AP中相同）→點擊安全，設置安全項802.1X，類型設為PEAP（EAP-MSCHAPv2），然后點擊配置，選擇使用用戶名和密碼進行連接，設置用于登錄的用戶名和密碼，再點設置設置服務器域名和用戶名”，確定完成設置并啟用設置文件，筆記本通過驗證正常介入并訪問使用因特網。討論

經過上述的配置服務器數據庫中的合法用戶就可以在連接到無線網絡時，在WPA2保護的無線網絡中通過PEAP方式進行身份驗證，訪問使用Internet網絡。由于SQL數據庫的使用，可以方便的用戶數據管理備份等工作提高了管理效率，并解決了WEP保護下的無線網絡存在WEP密碼被暴力破解帶來的安全問題和使用預共享密碼接入網絡存在的共享密碼泄露可能帶來的網絡安全風險。

較好地解決了校園無線局域網的安全性問題，使得授權用戶訪問Internet網絡應用擺脫線纜的束縛更加方便并阻止非法用戶的入侵。由于應用的PEAP認證方式在服務器安裝數字證書大大的提高了無線局域網的安全性。

【實驗步驟】

1、交換機配置

第一步：查看交換機版本信息 驗證測試：

查看交換機版本信息：

Switch>show version System description

: Red-Giant Gigabit Intelligent Switch(S2126G)By

Ruijie Network System uptime

: 0d:0h:8m:40s System hardware version : 3.3 System software version : 1.5(1)Build Mar 3 2005 Temp System BOOT version

: RG-S2126G-BOOT 03-02-02 System CTRL version

: RG-S2126G-CTRL 03-05-02 Running Switching Image : Layer2 Switch> 第二步：初始化交換機配置

所有的交換機在開始進行配置前，必需先進行初始化，清除原有的一切配置，命令如下： Switch> Switch>enable Switch#delete flash:config.text Switch#reload …..!刪除配置

Switch#configure terminal!進入配置層 Switch(config)#

驗證測試：

使用命令show running-config命令查看配置信息，刪除原始配置信息后該命令的打印結果如下：

Switch#show running-config Building configuration...Current configuration : 318 bytes!version 1.0!hostname Switch vlan 1!end Switch# 第三步：

Switch#configure terminal Enter configuration commands, one per line.End with CNTL/Z.Switch(config)#ip default-gateway 192.168.0.1！!設置交換機默認網關，實現跨網段管理交換機

Switch(config)#interface vlan 1 Switch(config-if)#ip address 192.168.0.2 255.255.255.0 Switch(config)#exit Switch(config)#radius-server host 192.168.0.185 auth-port 1812！!指定RADIUS服務器的地址及UDP認證端口

Switch(config)#aaa accounting server 192.168.0.185！!指定記賬服務器的地址

Switch(config)#aaa accounting acc-port 1813

！!指定記賬服務器的UDP端口

Switch(config)#aaa authentication dot1x

！!開啟AAA功能中的802.1x認證功能 Switch(config)#aaa accounting

！!開啟AAA功能中的記賬功能 Switch(config)#radius-server key star

！!設置RADIUS服務器認證字 Switch(config)#snmp-server community public rw

！!為通過簡單網絡管理協議訪問交換機設置認證名（public為缺省認證名）并分配讀寫權限

Switch(config)#interface fastEthernet 0/！!實驗中將在4號接口啟動802.1x的認證 Switch(config-if)#dot1x port-control auto

！!設置該接口參與802.1x認證 Switch(config-if)#exit Switch(config)#exit Switch#write Building configuration...[OK] Switch#

2、交換機配置的截圖

2、安裝SQL server

3、使用軟件TekRADIUS進行用戶名和密碼管理

Radius Server維護了所有用戶的信息：用戶名、密碼、該用戶的授權信息以及該用戶的記帳信息。所有的用戶集中于 Radius Server管理，而不必分散于每臺交換機，便于管理員對用戶的集中管理。

Radius Server端：要注冊一個Radius Client。注冊時要告知Radius Server交換機的IP、認證的UDP端口若記帳還要添記帳的UDP端口）、交換機與Radius Server通訊的約定密碼，還要選上對該Client支持EAP擴展認證方式）。

交換機端：設置Radius Server的IP地址，認證（記帳）的UDP端口，與服務器通訊的約定密碼。

【實驗體會】

相比上次實驗，這次實驗更加復雜。盡管是在小組的互動與合作下，本次實驗還是沒有成功。原因是實驗要求的環境較多，對 TekRADIUS軟件的使用不是很熟悉短時間內無法完全掌握它的原理及應用，導致在使用軟件TekRADIUS進行配置時，創建數據庫和表時不成功，最后的4步驟“設置服務參數、配置用戶組和用戶、增加Client客戶端、安裝證書”無法完成，而且實驗時間也到了，電腦也自動關機了，無法再進行下去了，我們就這樣結束了實驗。從課程的內容來看，本次實驗十分重要，獨立完成實驗內容是對我們很好的一次鍛煉，沒有全面完成它，但是課后我對802.1X配置的相關知識做了一次更深的了解。

一、802.1x協議起源于802.11協議，后者是標準的無線局域網協議，802.1x協議的主要目的是為了解決無線局域網用戶的接入認證問題。現在已經開始被應用于一般的有線LAN的接入。為了對端口加以控制，以實現用戶級的接入控制。802.1x就是IEEE為了解決基于端口的接入控制（Port-Based Access Control）而定義的一個標準。1、802.1X首先是一個認證協議，是一種對用戶進行認證的方法和策略。2、802.1X是基于端口的認證策略（這里的端口可以是一個實實在在的物理端口也可以是一個就像VLAN一樣的邏輯端口，對于無線局域網來說個“端口”就是一條信道）3、802.1X的認證的最終目的就是確定一個端口是否可用。對于一個端口，如果認證成功那么就“打開”這個端口，允許文所有的報文通過；如果認證不成功就使這個端口保持“關閉”，此時只允許802.1X的認證報文EAPOL（Extensible Authentication Protocol over LAN）通過。

二、802.1X的認證體系分為三部分結構：

Supplicant System，客戶端(PC/網絡設備)Authenticator System，認證系統

Authentication Server System，認證服務器

三、認證過程

1、認證通過前，通道的狀態為unauthorized，此時只能通過EAPOL的802.1X認證報文；

2、認證通過時，通道的狀態切換為authorized，此時從遠端認證服務器可以傳遞來用戶的信息，比如VLAN、CAR參數、優先級、用戶的訪問控制列表等等；

3、認證通過后，用戶的流量就將接受上述參數的監管，此時該通道可以通過任何報文，注意只有認證通過后才有DHCP等過程。

第三篇：通信網絡實驗報告

通信網絡實驗報告

實驗一 隱終端和暴露終端問題分析

一、實驗目的1、2、3、4、了解無線網絡中的載波檢測機制；

熟悉節點的傳輸范圍、沖突干擾范圍、載波檢測范圍和噪聲干擾范圍的概念； 了解載波檢測接入體制中存在的隱終端問題和暴露終端問題； 結合仿真實驗分析載波檢測無線網絡中的隱終端問題和暴露終端問題。

二、實驗結果

Node: 1, Layer: AppCbrClient,(0)Server address: 2 Node: 1, Layer: AppCbrClient,(0)First packet sent at [s]: 0.000000000 Node: 1, Layer: AppCbrClient,(0)Last packet sent at [s]: 99.990000000 Node: 1, Layer: AppCbrClient,(0)Session status: Not closed Node: 1, Layer: AppCbrClient,(0)Total number of bytes sent: 5120000 Node: 1, Layer: AppCbrClient,(0)Total number of packets sent: 10000 Node: 1, Layer: AppCbrClient,(0)Throughput(bits per second): 409600 Node: 2, Layer: AppCbrServer,(0)Client address: 1 Node: 2, Layer: AppCbrServer,(0)First packet received at [s]: 0.007438001 Node: 2, Layer: AppCbrServer,(0)Last packet received at [s]: 99.999922073 Node: 2, Layer: AppCbrServer,(0)Average end-to-end delay [s]: 0.739902205 Node: 2, Layer: AppCbrServer,(0)Session status: Not closed Node: 2, Layer: AppCbrServer,(0)Total number of bytes received: 4975616 Node: 2, Layer: AppCbrServer,(0)Total number of packets received: 9718 Node: 2, Layer: AppCbrServer,(0)Throughput(bits per second): 398078 Node: 3, Layer: AppCbrClient,(0)Server address: 4 Node: 3, Layer: AppCbrClient,(0)First packet sent at [s]: 0.000000000 Node: 3, Layer: AppCbrClient,(0)Last packet sent at [s]: 99.990000000 Node: 3, Layer: AppCbrClient,(0)Session status: Not closed Node: 3, Layer: AppCbrClient,(0)Total number of bytes sent: 5120000 Node: 3, Layer: AppCbrClient,(0)Total number of packets sent: 10000 Node: 3, Layer: AppCbrClient,(0)Throughput(bits per second): 409600 Node: 4, Layer: AppCbrServer,(0)Client address: 3 Node: 4, Layer: AppCbrServer,(0)First packet received at [s]: 0.003058001 Node: 4, Layer: AppCbrServer,(0)Last packet received at [s]: 99.993058001 Node: 4, Layer: AppCbrServer,(0)Average end-to-end delay [s]: 0.003119031 Node: 4, Layer: AppCbrServer,(0)Session status: Not closed Node: 4, Layer: AppCbrServer,(0)Total number of bytes received: 5120000 Node: 4, Layer: AppCbrServer,(0)Total number of packets received: 10000 Node: 4, Layer: AppCbrServer,(0)Throughput(bits per second): 409612

三、實驗結果分析

通過仿真結果可以看出，節點2無法收到數據。由于節點3是節點1的一個隱終端，節點1無法通過物理載波檢測偵聽到節點3的發送，且節點3在節點2的傳輸范圍外，節點3無法通過虛擬載波檢測延遲發送，所以在節點1傳輸數據的過程中，節點3完成退避發送時將引起沖突。

四、思考題

1、RTS/CTS能完全解決隱終端問題嗎？如果不能，請說明理由。

從理論分析上看，RTS/CTS協議似乎可以完全解決數據鏈隱藏終端問題，然而在實際網絡中并非如此，尤其是在AdHoc 網絡中。以節點為中心，存在發送區域和干擾區域。在發送區域內，在沒有干擾的情況下，數據包可正常收發；該區域的大小由站點的功率等參數確定，可視為定值。干擾區域是相對于接受節點而言的，在該區域內，節點可以受到來自非相關節點發送的數據的干擾，造成沖突、丟包。RTS/CTS對隱藏終端問題的屏蔽實際上是建立在兩區域相等的基礎上的，即所有的隱藏終端都位于接受節點發送范圍內。此中假設并不成立，干擾區域與收發節點間距有關。

實驗二 無線局域網DCF協議飽和吞吐量驗證

一、實驗目的

1、了解IEEE 802.11 DCF 協議的基本原理。

2、理解網絡飽和吞吐量的概念。

3、通過仿真對DCF協議飽和吞吐量的二維馬爾可夫鏈模型進行驗證。

二、實驗結果

Node: 1, Layer: AppCbrClient,(4)Server address: 55 Node: 1, Layer: AppCbrClient,(4)First packet sent at [s]: 0.000000000 Node: 1, Layer: AppCbrClient,(4)Last packet sent at [s]: 99.990000000 Node: 1, Layer: AppCbrClient,(4)Session status: Not closed Node: 1, Layer: AppCbrClient,(4)Total number of bytes sent: 5120000 Node: 1, Layer: AppCbrClient,(4)Total number of packets sent: 10000 Node: 1, Layer: AppCbrClient,(4)Throughput(bits per second): 409600 Node: 1, Layer: AppCbrClient,(3)Server address: 54 Node: 1, Layer: AppCbrClient,(3)First packet sent at [s]: 0.000000000 Node: 1, Layer: AppCbrClient,(3)Last packet sent at [s]: 99.990000000 Node: 1, Layer: AppCbrClient,(3)Session status: Not closed Node: 1, Layer: AppCbrClient,(3)Total number of bytes sent: 5120000 Node: 1, Layer: AppCbrClient,(3)Total number of packets sent: 10000 Node: 1, Layer: AppCbrClient,(3)Throughput(bits per second): 409600 Node: 1, Layer: AppCbrClient,(2)Server address: 53 Node: 1, Layer: AppCbrClient,(2)First packet sent at [s]: 0.000000000 Node: 1, Layer: AppCbrClient,(2)Last packet sent at [s]: 99.990000000 Node: 1, Layer: AppCbrClient,(2)Session status: Not closed Node: 1, Layer: AppCbrClient,(2)Total number of bytes sent: 5120000 Node: 1, Layer: AppCbrClient,(2)Total number of packets sent: 10000 Node: 1, Layer: AppCbrClient,(2)Throughput(bits per second): 409600 Node: 1, Layer: AppCbrClient,(1)Server address: 52 Node: 1, Layer: AppCbrClient,(1)First packet sent at [s]: 0.000000000 Node: 1, Layer: AppCbrClient,(1)Last packet sent at [s]: 99.990000000 Node: 1, Layer: AppCbrClient,(1)Session status: Not closed Node: 1, Layer: AppCbrClient,(1)Total number of bytes sent: 5120000 Node: 1, Layer: AppCbrClient,(1)Total number of packets sent: 10000 Node: 1, Layer: AppCbrClient,(1)Throughput(bits per second): 409600 Node: 1, Layer: AppCbrClient,(0)Server address: 51 Node: 1, Layer: AppCbrClient,(0)First packet sent at [s]: 0.000000000 Node: 1, Layer: AppCbrClient,(0)Last packet sent at [s]: 99.990000000 Node: 1, Layer: AppCbrClient,(0)Session status: Not closed Node: 1, Layer: AppCbrClient,(0)Total number of bytes sent: 5120000 Node: 1, Layer: AppCbrClient,(0)Total number of packets sent: 10000 Node: 1, Layer: AppCbrClient,(0)Throughput(bits per second): 409600 Node: 51, Layer: AppCbrServer,(0)Client address: 1 Node: 51, Layer: AppCbrServer,(0)First packet received at [s]: 0.003056858 Node: 51, Layer: AppCbrServer,(0)Last packet received at [s]: 99.995493030 Node: 51, Layer: AppCbrServer,(0)Average end-to-end delay [s]: 0.351972641 Node: 51, Layer: AppCbrServer,(0)Session status: Not closed Node: 51, Layer: AppCbrServer,(0)Total number of bytes received: 5102592 Node: 51, Layer: AppCbrServer,(0)Total number of packets received: 9966 Node: 51, Layer: AppCbrServer,(0)Throughput(bits per second): 408219 Node: 52, Layer: AppCbrServer,(1)Client address: 1 Node: 52, Layer: AppCbrServer,(1)First packet received at [s]: 0.006449537 Node: 52, Layer: AppCbrServer,(1)Last packet received at [s]: 99.998965709 Node: 52, Layer: AppCbrServer,(1)Average end-to-end delay [s]: 0.355584451 Node: 52, Layer: AppCbrServer,(1)Session status: Not closed Node: 52, Layer: AppCbrServer,(1)Total number of bytes received: 5102592 Node: 52, Layer: AppCbrServer,(1)Total number of packets received: 9966 Node: 52, Layer: AppCbrServer,(1)Throughput(bits per second): 408233 Node: 53, Layer: AppCbrServer,(2)Client address: 1 Node: 53, Layer: AppCbrServer,(2)First packet received at [s]: 0.010001809 Node: 53, Layer: AppCbrServer,(2)Last packet received at [s]: 99.992000125 Node: 53, Layer: AppCbrServer,(2)Average end-to-end delay [s]: 0.358534977 Node: 53, Layer: AppCbrServer,(2)Session status: Not closed Node: 53, Layer: AppCbrServer,(2)Total number of bytes received: 3926016 Node: 53, Layer: AppCbrServer,(2)Total number of packets received: 7668 Node: 53, Layer: AppCbrServer,(2)Throughput(bits per second): 314112 Node: 54, Layer: AppCbrServer,(3)Client address: 1 Node: 54, Layer: AppCbrServer,(3)First packet received at [s]: 0.013774900 Node: 54, Layer: AppCbrServer,(3)Last packet received at [s]: 0.773715844 Node: 54, Layer: AppCbrServer,(3)Average end-to-end delay [s]: 0.184107930 Node: 54, Layer: AppCbrServer,(3)Session status: Not closed Node: 54, Layer: AppCbrServer,(3)Total number of bytes received: 22016 Node: 54, Layer: AppCbrServer,(3)Total number of packets received: 43 Node: 54, Layer: AppCbrServer,(3)Throughput(bits per second): 1761 Node: 55, Layer: AppCbrServer,(4)Client address: 1 Node: 55, Layer: AppCbrServer,(4)First packet received at [s]: 0.017127686 Node: 55, Layer: AppCbrServer,(4)Last packet received at [s]: 0.777148630 Node: 55, Layer: AppCbrServer,(4)Average end-to-end delay [s]: 0.187729553 Node: 55, Layer: AppCbrServer,(4)Session status: Not closed Node: 55, Layer: AppCbrServer,(4)Total number of bytes received: 22016 Node: 55, Layer: AppCbrServer,(4)Total number of packets received: 43 Node: 55, Layer: AppCbrServer,(4)Throughput(bits per second): 1761

三、實驗結果分析

各發送節點發包間隔較大，當網絡中發送節點較少時，網絡還未飽和。逐漸往網絡中增加負載，網絡總吞吐量逐漸增大，之后，網絡吞吐量逐漸趨向于平穩，此時，網絡即達到了飽和狀態。

四、思考題

1、總結IEEE 802.11DCF協議飽和吞吐量和哪些因素有關。

任選一個時隙，網絡中有節點在發送數據的概率 當有節點在發送數據包時，數據包發送成功的概率 數據包發送成功和發送失敗所需的時間

2、為什么在數據包長度較長時，采用RTS/CTS模式更合理？

“隱藏終端”多發生在大型單元中（一般在室外環境），這將帶來效率損失，并且需要錯誤恢復機制。當需要傳送大容量文件時，尤其需要杜絕“隱藏終端”現象的發生。

實驗三 動態源路由協議路由選擇驗證

一、實驗目的1、2、了解DSR路由協議的優缺點。

理解DSR路由協議中路由發現過程和路由維護過程。

3、掌握DSR路由協議性能的仿真分析方法。

二、實驗結果 Time(s): 1.000001000, Node: 1, Route path: 2 Time(s): 2.000001000, Node: 1, Route path: 2 Time(s): 3.000001000, Node: 1, Route path: 2 Time(s): 4.000001000, Node: 1, Route path: 2 Time(s): 5.000001000, Node: 1, Route path: 2 Time(s): 6.000001000, Node: 1, Route path: 2 Time(s): 7.000001000, Node: 1, Route path: 2 Time(s): 8.000001000, Node: 1, Route path: 4-2 Time(s): 9.000001000, Node: 1, Route path: 4-2 Time(s): 10.000001000, Node: 1, Route path: 4-2 Time(s): 11.000001000, Node: 1, Route path: 4-2 Time(s): 12.000001000, Node: 1, Route path: 4-2 Time(s): 13.000001000, Node: 1, Route path: 4-2 Time(s): 14.000001000, Node: 1, Route path: 4-2 Time(s): ***0, Node: 1, Route path: 4-2 Time(s): 16.000001000, Node: 1, Route path: 4-2 Time(s): 17.000001000, Node: 1, Route path: 4-2 Time(s): 18.000001000, Node: 1, Route path: 4-2 Time(s): 19.000001000, Node: 1, Route path: 4-2 Time(s): 20.000001000, Node: 1, Route path: 4-2 Time(s): 21.000001000, Node: 1, Route path: 4-2 Time(s): 22.000001000, Node: 1, Route path: 4-2 Time(s): 23.000001000, Node: 1, Route path: 4-2 Time(s): 24.000001000, Node: 1, Route path: 4-2 Time(s): 25.000001000, Node: 1, Route path: 4-2 Time(s): 26.000001000, Node: 1, Route path: 4-2 Time(s): 27.000001000, Node: 1, Route path: 4-2 Time(s): 28.000001000, Node: 1, Route path: 4-2 Time(s): 29.000001000, Node: 1, Route path: 4-2 Time(s): 30.000001000, Node: 1, Route path: 4-2 Time(s): 31.000001000, Node: 1, Route path: 4-2 Time(s): 32.000001000, Node: 1, Route path: 4-2 Time(s): 33.000001000, Node: 1, Route path: 4-2 Time(s): 34.000001000, Node: 1, Route path: 4-2 Time(s): 35.000001000, Node: 1, Route path: 4-2 Time(s): 36.000001000, Node: 1, Route path: 4-2 Time(s): 37.000001000, Node: 1, Route path: 4-2 Time(s): 38.000001000, Node: 1, Route path: 5-4-2 Time(s): 39.000001000, Node: 1, Route path: 5-4-2 Time(s): 40.000001000, Node: 1, Route path: 5-4-2 Time(s): 41.000001000, Node: 1, Route path: 5-4-2 Time(s): 42.000001000, Node: 1, Route path: 5-4-2 Time(s): 43.000001000, Node: 1, Route path: 5-4-2 Time(s): 44.000001000, Node: 1, Route path: 5-4-2 Time(s): 45.000001000, Node: 1, Route path: 5-4-2 Time(s): 46.000001000, Node: 1, Route path: 5-4-2 Time(s): 47.000001000, Node: 1, Route path: 5-4-2 Time(s): 48.000001000, Node: 1, Route path: 5-4-2 Time(s): 49.000001000, Node: 1, Route path: 5-4-2 Time(s): 50.000001000, Node: 1, Route path: 5-4-2 Time(s): 51.000001000, Node: 1, Route path: 5-4-2 Time(s): 52.000001000, Node: 1, Route path: 5-4-2 Time(s): 53.000001000, Node: 1, Route path: 5-4-2 Time(s): 54.000001000, Node: 1, Route path: 5-4-2 Time(s): 55.000001000, Node: 1, Route path: 5-4-2 Time(s): 56.000001000, Node: 1, Route path: 5-4-2 Time(s): 57.000001000, Node: 1, Route path: 5-4-2 Time(s): 58.000001000, Node: 1, Route path: 5-4-2 Time(s): 59.000001000, Node: 1, Route path: 5-4-2 Time(s): 60.000001000, Node: 1, Route path: 5-4-2 Time(s): 61.000001000, Node: 1, Route path: 5-4-2 Time(s): 62.000001000, Node: 1, Route path: 5-4-2 Time(s): 63.000001000, Node: 1, Route path: 5-4-2 Time(s): 64.000001000, Node: 1, Route path: 5-4-2 Time(s): 65.000001000, Node: 1, Route path: 5-4-2 Time(s): 66.000001000, Node: 1, Route path: 5-4-2 Time(s): 67.000001000, Node: 1, Route path: 5-4-2 Time(s): 68.000001000, Node: 1, Route path: 3-2 Time(s): 69.000001000, Node: 1, Route path: 3-2 Time(s): 70.000001000, Node: 1, Route path: 3-2 Time(s): 71.000001000, Node: 1, Route path: 3-2 Time(s): 72.000001000, Node: 1, Route path: 3-2 Time(s): 73.000001000, Node: 1, Route path: 3-2 Time(s): 74.000001000, Node: 1, Route path: 3-2 Time(s): 75.000001000, Node: 1, Route path: 3-2 Time(s): 76.000001000, Node: 1, Route path: 3-2 Time(s): 77.000001000, Node: 1, Route path: 3-2 Time(s): 78.000001000, Node: 1, Route path: 3-2 Time(s): 79.000001000, Node: 1, Route path: 3-2 Time(s): 80.000001000, Node: 1, Route path: 3-2 Time(s): 81.000001000, Node: 1, Route path: 3-2 Time(s): 82.000001000, Node: 1, Route path: 3-2 Time(s): 83.000001000, Node: 1, Route path: 3-2 Time(s): 84.000001000, Node: 1, Route path: 3-2 Time(s): 85.000001000, Node: 1, Route path: 3-2 Time(s): 86.000001000, Node: 1, Route path: 3-2 Time(s): 87.000001000, Node: 1, Route path: 3-2 Time(s): 88.000001000, Node: 1, Route path: 3-2 Time(s): 89.000001000, Node: 1, Route path: 3-2 Time(s): 90.000001000, Node: 1, Route path: 3-2 Time(s): 91.000001000, Node: 1, Route path: 3-2 Time(s): 92.000001000, Node: 1, Route path: 3-2 Time(s): 93.000001000, Node: 1, Route path: 2 Time(s): 94.000001000, Node: 1, Route path: 2 Time(s): 95.000001000, Node: 1, Route path: 2 Time(s): 96.000001000, Node: 1, Route path: 2 Time(s): 97.000001000, Node: 1, Route path: 2 Time(s): 98.000001000, Node: 1, Route path: 2 Time(s): 99.000001000, Node: 1, Route path: 2

三、實驗結果分析

仿真過程中路由表變化：2，4-2，5-4-2，3-2，2。當節點[1]在節點[2]的傳輸范圍內時，節點[1]和[2]之間直接通信，不需要中間節點。隨著節點[1]的移動，節點[1]離開節點[2]的傳輸范圍并漸漸遠離，最后又逐漸靠近。在節點[1]離開節點[2]的傳輸范圍，節點[1]和[2]需要通過中間節點來通信，而且節點[1]離節點[2]越遠，需要的中間節點越多。

第四篇：網絡經濟學實驗報告

山東建筑大學 商學院·實驗報告

課程名稱： 網絡經濟學 班 級： 電子商務111 學生姓名： 學 號： 成 績：

指導教師： 吳 學 霞 所屬學期： 2013 － 2014 學年第 1 學期

實驗一 網絡外部性原理運用

實驗目的

理解網絡條件下外部性的新特點。實驗內容

搜集資料，選取網絡經濟下的一個企業案例，分析網絡外部性對網絡產品供給和需求的影響。

實驗過程

1.網絡正外部性分析

由于此時網絡經濟的社會價值大于個人價值,社會價值曲線在個人價值曲線之上。此時的最適量體現在社會價值需求曲線與個人成本供給曲線的交叉點并大于供需曲線一般的均衡量(市場量)。由此可見,網絡的正外部性使得微軟公司的股東們在獲得較高個人收益的同時,擴散了相應的生產率效益,并取得利他的社會效果———體現為:在互聯網中的經濟單位所采取的生產或消費行為,使得整個行業或社會上某些群體無需更多的付出,以極低的成本就能得到好處,共享資源。

2.網絡負外部性分析

但是,網絡的負外部性也同時并存,不可忽視。如互聯網的通用標準及微軟等在市場上占主導地位的公司所帶來的一些負面壟斷效應,以及由于互聯網的蝶狀領結結構(見圖2),信息在互聯網中多向流動、大容量文件的頻繁上傳和下載所出身的網絡擁堵,都體現為負外部性的特征。

同時,負外部性還體現在:由于互聯網信息的快速傳遞,不需要太高的技術要求,黑客(Hacker)借助現成的軟件就可以肆意進攻互聯網,甚至局域網。木馬和病毒更新速度極快,使得殺毒軟件防不勝防,屢屢造成巨大的經濟損失。仍以微軟為例,微軟公司發布的第六期“微軟安全研究報告”顯示,隨著軟件公司改善了操作系統的安全性,目前第三方應用軟件已成為惡意軟件的主要攻擊目標,2008年下半年發現的漏洞中有90 %涉及到應用軟件[10 ]。

圖3 表示了網絡負外部性造成社會成本曲線在供給成本曲線之上,這兩條曲線的差別反映了由于網絡壟斷、網絡擁堵以及黑客的存在所帶來的外部成本。此時網絡的最適量同樣體現在社會價值需求曲線與個人成本供給曲線的交叉點,但小于供需曲線一般的均衡量(市場量)。網絡負外部性的存在,使得網絡經濟的社會成本大于個人成本。

實驗二 正反饋原理運用

實驗目的

了解正反饋原理在網絡經濟中的運用。實驗內容

上網查找網站，以具體行業發展舉例說明正反饋原理的具體應用。實驗過程

應用正反饋機制理論分析我國風險投資業初期發展模式中的機制性問題

總體而言，我國風險投資整個行業運作存在不規范的特點。目前，行業仍處于繼續探索的初期發展階段。自1985年9月我國第一家專營高技術風險投資的全國性金融公司--中國新技術創業投資公司（簡稱“中創”）成立至今，我國風險投資業經歷了二十世紀80年代的早期探索階段、90年代的風險基金創立階段、90年代末本世紀初的加速發展階段。1998年3月“政協一號”提案激起了國內發展風險投資的熱潮。據中國科技金融協會1999年7月統計，中國的風險投資公司已有九十二家，有七十四億元的投資能力。據維欣風險投資發展研究中心1999年12月調查[文獻4]，我國風險投資機構已超過200家，運營資本超過200億元。但是，我國風險資本的80%來源于政府財政撥款，政府出資創建風險投資基金或公司支持國內風險投資公司的生存和發展，這種主導模式本質上是以政府行為代替市場行為，構成當前我國風險投資業發展的最大弊端。

經驗證明，風險投資業初期發展的關鍵問題應當是如何正確引導風險投資業沿著適宜的軌道逐漸發展壯大。從15年發展歷程看，我國風險投資業這一步走得很累。按照生命周期理論，風險投資業的發展要經歷起步、發展、成熟、衰退或者進入高一層次的生命周期循環。新事物的起步和發展階段需要有一種很好的動力機制能夠保證它從微小逐漸壯大發展，否則，新事物就會消失，或者即使勉強存在也會處于混亂狀態。

從系統動力學的角度看，就是要找到一種起自我強化作用的正反饋機制，使風險投資業在這種正反饋中完成起步和發展。因此，國內風險投資業發展緩慢的根本原因是我們沒有找

到合適的正反饋動力機制。所以，目前的任務就是盡快找到這種正反饋動力機制。事實證明，我國風險投資業在發展之初，存在概念性的錯誤理念，建立的機制不能形成有效的正反饋，相反，在組建之后陷入了一種惡性循環中。這可以用圖3-1說明。各級政府直接進入風險投資業，提供風險資本，這在我國會產生什么結果呢？參照圖3-1，a階段--政府作為風險資本的第一提供者參與風險投資，以此為基本出發點，對我國現行的風險投資方式進行深入分析。

由于保險公司、民間資金、大企業大財團等仍不敢貿然進入風險投資業，各級地方政府只好用財政撥款組建第一批風險基金（圖3-1中的b階段），地方政府成為基金的股東代表（實際股東應為納稅人）。風險基金的管理和經營又由誰負責呢？仍然是由政府指定人選掌管基金。正是這種政府具有最高決策權的模式為今后風險投資的順利運行埋下了隱患，根本體現在它提供了尋租機會。

實驗三 網絡產品市場結構分析

實驗目的

掌握市場結構類型，學會判斷具體行業的市場結構。實驗內容

選取市場集中度指標，針對具體網絡行業搜集資料，進行市場結構類型分析。實驗過程

視頻網站是指依靠網絡視頻播放技術，讓用戶在互聯網上在線瀏覽、發布和分享視頻作品的網站。目前國內的視頻網站還處在成長期，網站的盈利模式較為單一，絕大多數利潤來自廣告收入，這是將網站流量轉化為收入的最直接有效的方式。廣告收入的高低基本由網站流量所決定，這導致了視頻網站的收視份額與該網站的廣告市場份額高度一致。即使未來有更多的盈利模式出現，廣告收入仍然會是視頻網站綜合收入的主力軍。因此，視頻網站廣告市場集中度能夠間接地反映出整個行業的競爭狀況。

視頻網站廣告市場集中度測度分析

市場集中度是用于表示在特定產業或市場中，賣者和買者具有怎樣的相對的規模結構的指標。由于市場集中度是反映特定市場的集中程度的指標，所以它與市場中壟斷力量的形成密切相關。產業組織理論把市場集中度作為考察市場結構的首要因素。

根據搜集到的數據測算出2010年第一和第三季度、2011年第一和第三季度以及2012年第一和第三季度這6個季度里中國視頻網站廣告市場集中度CR1、CR4、CR8和CR10，以此分析在我國視頻網站廣告市場集中度的狀況以及發展變化趨勢。

從2010到2012年的6個季度里，中國網絡視頻廣告市場集中度表現出如下特征： 第一，從整體來看，我國的視頻網站廣告市場集中度較高，屬于寡占型的市場結構。從2010到2012年，我國視頻網站廣告市場集中度CR4、CR8和CR10的最小值分別為48.8%、71.0%、79.3%，最大值分別為61.6%、83.5%、89.4%，極差分別為12.8%、12.5%、10.1%。數值整體偏高，表明我國視頻網站廣告市場集中度較高。按照貝恩的市場結構分類標準，屬于寡占Ⅲ型的市場結構，這是處于產業發展初期的媒介的共性。

第二，從變化來看，我國的視頻網站行業市場集中度變化幅度不大。從2010到2012年，CR4、CR8和CR10的最小值和最大值的極差分別為12.8%、12.5%、10.1%。雖有一定變化，但變化幅度并不大。其中2010年第一季度到2011年第一季度的市場集中度呈現上升趨勢，在2011年第一季度達到最高，從2011年第一季度到2012年第三季度又呈現出下降的趨勢。

由此可見，自2011年第一季度視頻網站行業發生了一系列變化，明顯地影響了視頻網站廣告市場集中度。

第三，排名靠前的幾家視頻網站的廣告市場集中度較高。在統計的6個季度中CR4平均大于50%，表明排名前4的視頻網站實力較為雄厚且市場份額較為穩定。排名第一的優酷網，除了2010年第一季度外，CR1一直保持在20%以上。雖然近兩年來行業競爭加劇，優酷網的優勢稍有減弱，但仍然保持著業界“領頭羊”的位置。

視頻網站廣告市場集中度的影響因素分析

“內容為王”是傳媒界熟知的理念之一。這一理念也適用于視頻網站行業，網絡視頻的內容是決定視頻網站廣告市場集中度的最主要的因素。在國內視頻網站發展的初期，因為最早發展起來的幾個視頻網站主要是借鑒YouTube的運營模式，內容以原創為主，所以原創內容的數量一度成為各大視頻網站競相追逐的對象。以優酷網、土豆網為代表的建立較早的視頻網站，在發展初期就積累了數量龐大的原創內容，因此它們在后來的競爭中擁有先發制人的優勢。

隨著視頻網站行業這幾年來的發展，原創的視頻已經不能滿足用戶的需求，影視劇資源越來越成為各大視頻網站競爭的“王牌”。影視劇版權爭奪戰一度出現混亂的局面，版權價格經歷了單集售價在一年多之間從1萬元到150萬元瘋狂暴漲的情況，一時間各大視頻網站紛紛“砸錢”高價購買首播權。這種惡性競爭把電視劇的版權價格越抬越高，導致只有市場份額排名靠前的視頻網站才有經濟能力購買影視劇版權。這一狀況導致視頻網站之間的流量差距進一步拉大，廣告收入也隨之拉大。網絡視頻廣告市場集中度越來越高，并在2011年達到了頂峰。

2012年以來，隨著視頻播放技術的不斷發展和創新，也有一些中小型的視頻網站以及個別大型視頻網站依靠技術升級贏得部分廣告市場份額，使網絡視頻廣告集中度進一步降低。例如部分視頻網站推出的高清模式，以視頻質量的高低尋求產品的差異化，既滿足了帶寬不夠的用戶，又滿足了喜歡高清晰度視頻的用戶。

實驗四 網絡經濟下的企業競爭策略分析

實驗目的

掌握網絡經濟下的企業競爭策略分析。實驗內容

要求學生在學習網絡經濟中企業競爭策略理論的基礎上，選取一定的案例進行詳細的分析，進一步理解網絡經濟下企業競爭策略的新特點。

實驗過程

公路客運企業應對鐵路競爭的策略

公路運輸與鐵路作為兩種重要的運輸形式，兩者間的競爭是必然的、不可避免的。與鐵路相比，公路運輸成本高，舒適性、安全性、及時性不夠。國際金融危機暴發后，國家為拉動經濟加大了鐵路建設的投入力度，這對本來就處于競爭劣勢的公路運輸企業而言可謂是雪上加霜。公路運輸企業如何應對鐵路的競爭？

一、公路客運面臨的機遇與困難

機遇：由于現有鐵路承載能力有限，鐵路提速又給道路客運班線帶來了轉機，概括起來有幾個有利因素：一是鐵路班次少，加上鐵路速度上去了，中途站點?？繙p少，這就給公路客運帶來了商機。二是在管理上，鐵路每個站的配客量在年初制定，不可變更。客流低時成本高，客流高時運不完。三是鐵路提速后，一些車站不能?？?。

困難：（1）經營主體散。自運輸市場全面放開后，由于市場準入標準太低，經營主體較多，經營者素質參差不齊，運輸市場呈現混亂、分散的無序競爭狀態。

（2）硬件投入不足。由于多種原因，不少公路運輸企業對站場改造、車輛更新步伐緩慢，導致旅客乘、候車條件不佳，服務質量難以保證，使公路運輸競爭力下降。

（3）軟環境建設滯后。由于種種原因，不少運輸企業人員素質不高、職工隊伍老化，管理水平低下制約了公路運輸企業的發展。

二、公路客運業發展的對策

對于挑戰與機遇并存的公路客運市場，應該對經營策略進行理性的選擇，把握機遇，勇于應對挑戰，努力做強做優公路客運業。1.實施品牌戰略，提高服務水平

（1）全力推進道路客運班車公司化改造工作，從根本上杜絕承包經營服務質量不高，安全營運缺少保障的弊端。

（2）必須制定規范的服務標準，以旅客滿意為宗旨，在實踐中不斷總結、修正管理制度，使其日趨完善。

（3）要不斷豐富服務內涵，增設售票網點、與郵政網點聯網售票，實行電話訂票、送票上門、網上售票、自助購票等，讓旅客在最短的時間內購買到車票。

（4）要建立一支高素質的職工隊伍。必須重視對駕駛員和服務人員的教育和培訓。2.采用差異化競爭策略，拓展經營空間

要充分發揮公路客運的優勢，適度發展火車未開通或與火車不同線的長途、超長途班線，穩步發展和鞏固中長途班線，大力發展短途班線。按不同線路情況努力提高車輛檔次，提高企業信譽，提升企業形象。3.近靠鐵路站點，巧借東風分流

應采取積極措施，巧借東風，向鐵路站點靠近，公路和鐵路客運站的距離越短越好，既方便長途列車下車旅客的中轉換乘，也有利于發揮公路客運班次密度高的優勢，爭取與鐵路復線班次的客源。同時也方便短途旅客換乘長途列車，形成與鐵路良性、互補的競爭，共同創造良好的客運環境。

4.整合資源，推動公路客運行業發生質的轉變

客運企業間可通過線路置換、出資收購、兼并、資產重組或多元參股組建跨企業的客運專線公司，以消除惡性競爭和內耗，提升服務，創樹客運品牌，提升道路客運業綜合競爭力和公共服務能力。

5.狠抓管理，提升核心競爭力

一是加強網絡和信息化建設，掌握第一手客源信息，合理調度，不斷提高工作質量和效率。二是運輸企業應積極實施科學管理，建設節約型企業，減少消耗，降低成本，努力做到增收節支。三是圍繞運輸主業，拉長產業鏈，發展壯大汽車燃潤料和配件供應、修理業、駕培業等產業。

6.重視發揮行業管理部門和行業協會作用，努力營造公平、公正的競爭環境

行業管理部門應認真履行職責，在市場準入、市場監管等方面發揮應有的作用，積極維護運輸市場秩序，打擊非法營運，規范業戶經營行為，超前做好站點的規劃布局，使公路運輸市場管而不死、活而不亂、競爭有序，并在客運企業資產重組、資源整合等工作方面，做好政策引導、牽線搭橋工作。

第五篇：實驗報告：網絡管理

實驗名稱：網絡管理

課程名稱：計算機網絡

學生信息：07計算機班 郭文（2007114046）

實驗時間：2010年6月6日

實驗目的：

理解網絡管理的概念

利用網絡管理軟件進行實踐

實驗原理：

網絡管理包括對硬件、軟件和人力的使用、綜合與協調，以便對網絡資源進行監視、測試、配置、分析、評價和控制，這樣就能以合理的價格滿足網絡的一些需求，如實時運行性能、服務質量等。網絡管理常簡稱為網管。

實驗內容：

通過使用網絡管理軟件PcAnywhere實現網絡管理。

實驗器材：

服務器一臺、客戶機四臺（已連接）、管理軟件PcAnywhere。

實驗步驟：

1.客戶端的安裝：

根據PcAnywhere安裝說明，將客戶端安裝到服務器上。

2.服務端的安裝：

根據PcAnywhere安裝說明，將服務端安裝到客戶機上。

3.PcAnywhere設置：

按照PcAnywhere的使用說明書，對客戶端與服務器分別進行設置。

4.軟件測試：

使用客戶端連接服務器，進行控制管理。

實驗結果：

連接測試正常，各項功能良好。