李珊娜，安志強(qiáng)

(北京交通大學(xué) 信息中心，北京 100044)

0 引 言

IEEE 802.11協(xié)議是一種無線局域網(wǎng)協(xié)議，主要包括兩種類型，即獨(dú)立型網(wǎng)絡(luò)(以下簡稱ad hoc網(wǎng)絡(luò))和基礎(chǔ)型網(wǎng)絡(luò)(以下簡稱Sta-AP網(wǎng)絡(luò))。ad hoc網(wǎng)至少由兩個(gè)工作站直接通信組成，其中一個(gè)工作站負(fù)責(zé)接入點(diǎn)AP的工作，工作站間彼此可以直接通信，兩者間的距離必須在可以直接通信的范圍內(nèi)[1]；Sta-AP網(wǎng)至少包含一個(gè)接入點(diǎn)AP和一個(gè)工作站，接入點(diǎn)負(fù)責(zé)基礎(chǔ)型網(wǎng)絡(luò)所有的傳輸[2]。

該文主要介紹利用NS-3平臺仿真不同的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，通過調(diào)整AP數(shù)量、節(jié)點(diǎn)之間的距離、節(jié)點(diǎn)移動(dòng)速度等參數(shù)設(shè)置不同的網(wǎng)絡(luò)環(huán)境。實(shí)驗(yàn)主要設(shè)計(jì)模擬三個(gè)節(jié)點(diǎn)拓?fù)浣Y(jié)構(gòu)、五個(gè)節(jié)點(diǎn)拓?fù)浣Y(jié)構(gòu)、五個(gè)節(jié)點(diǎn)遠(yuǎn)距離拓?fù)浣Y(jié)構(gòu)、六個(gè)節(jié)點(diǎn)兩個(gè)AP拓?fù)浣Y(jié)構(gòu)的網(wǎng)絡(luò)環(huán)境，在每一種拓?fù)浣Y(jié)構(gòu)下對比Sta-AP網(wǎng)絡(luò)和ad hoc網(wǎng)絡(luò)的性能參數(shù)，得出一系列結(jié)論為現(xiàn)實(shí)網(wǎng)絡(luò)環(huán)境搭建提供輔助決策。

實(shí)驗(yàn)中利用Wireshark和NS3的FlowMonitor功能作為網(wǎng)絡(luò)性能分析手段，在網(wǎng)絡(luò)發(fā)送端節(jié)點(diǎn)上加載NS-3的OnOff應(yīng)用，產(chǎn)生發(fā)送數(shù)據(jù)包流量，在網(wǎng)絡(luò)接收端節(jié)點(diǎn)上加載NS-3的PacketSinkHelper應(yīng)用模擬接收數(shù)據(jù)包應(yīng)用。當(dāng)節(jié)點(diǎn)安裝ad hoc協(xié)議時(shí)，通過加載不同的路由協(xié)議和設(shè)置節(jié)點(diǎn)移動(dòng)參數(shù)比較其網(wǎng)絡(luò)性能差異情況，也驗(yàn)證了路由協(xié)議的部分特性，發(fā)現(xiàn)Wireshark和NS-3的FlowMonitor在特定情況下獲取網(wǎng)絡(luò)流量的區(qū)別，最終得出結(jié)論為FlowMonitor方法本身的局限性導(dǎo)致這樣的現(xiàn)象。

1 NS-3仿真平臺

NS-3是為網(wǎng)絡(luò)研究和教育而開發(fā)的網(wǎng)絡(luò)仿真平臺，它提供了一個(gè)分組數(shù)據(jù)網(wǎng)絡(luò)如何工作和運(yùn)行的模型，也為用戶提供了一個(gè)用于仿真實(shí)驗(yàn)的仿真引擎。NS-3使用經(jīng)典的Unix語言作為環(huán)境工具，在GNU/Linux平臺下開發(fā)，用C++語言實(shí)現(xiàn)，兼容時(shí)下流行的Python[3]。

NS-3仿真流程主要通過編寫網(wǎng)絡(luò)仿真腳本實(shí)現(xiàn)，根據(jù)實(shí)際仿真對象和仿真場景選擇相應(yīng)的仿真模塊，主要包括以下內(nèi)容：

(1)生成網(wǎng)絡(luò)節(jié)點(diǎn)[4]：NS-3中網(wǎng)絡(luò)節(jié)點(diǎn)是基本計(jì)算設(shè)備的抽象，節(jié)點(diǎn)由C++類中的Node類來描述，Node類提供了管理計(jì)算設(shè)備所需的各種方法，如網(wǎng)卡、應(yīng)用程序、協(xié)議棧等[5]。

(2)安裝網(wǎng)絡(luò)設(shè)備：不同的網(wǎng)絡(luò)類型有不同的網(wǎng)絡(luò)設(shè)備，網(wǎng)絡(luò)設(shè)備由C++中的NetDevice類來描述，NetDevice類提供管理連接節(jié)點(diǎn)和信道的各種方法，如CsmaNetDevice、WiFiNetDevice和PointToPointNetDe-vice等。

(3)安裝協(xié)議棧：NS-3網(wǎng)絡(luò)中一般是TCP/IP協(xié)議棧，依據(jù)網(wǎng)絡(luò)選擇具體協(xié)議棧，如是UDP還是TCP，選擇具體的路由協(xié)議(OLSR、AODV和Global等)，并為其配置相應(yīng)的IP地址。

(4)安裝應(yīng)用層協(xié)議：C++中用Application類來描述被仿真的應(yīng)用程序，這個(gè)類提供了管理仿真時(shí)用戶層應(yīng)用的各種方法。依據(jù)選擇的傳輸層協(xié)議選擇相應(yīng)的應(yīng)用層協(xié)議[6]。

通過以上網(wǎng)絡(luò)仿真腳本的編寫，完成網(wǎng)絡(luò)場景配置。由此可見，搭建NS-3網(wǎng)絡(luò)仿真場景和搭建實(shí)際網(wǎng)絡(luò)類似。實(shí)驗(yàn)中各種網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)的模擬都將采用上述過程和方法，熟練使用NS-3仿真流程尤為重要，可以參考官網(wǎng)的方法和實(shí)例。

2 性能分析工具

2.1 Wireshark

Wireshark是一個(gè)網(wǎng)絡(luò)封包分析軟件。網(wǎng)絡(luò)封包分析軟件的功能是擷取網(wǎng)絡(luò)封包，并顯示出最為詳細(xì)的網(wǎng)絡(luò)封包資料。Wireshark使用WinPCAP作為接口，直接與網(wǎng)卡進(jìn)行數(shù)據(jù)報(bào)文交換。使用Wireshark將得到大量的冗余數(shù)據(jù)包列表，使用捕捉過濾器和顯示過濾器會(huì)有助于在大量的數(shù)據(jù)中迅速定位所需信息。實(shí)驗(yàn)中著重分析Wireshark產(chǎn)生的pcap文件，它反映了網(wǎng)絡(luò)真實(shí)的交互過程及性能數(shù)據(jù)[7]。

2.2 FlowMonitor

FlowMonitor是為NS-3設(shè)計(jì)的網(wǎng)絡(luò)監(jiān)控功能，它自動(dòng)檢測網(wǎng)絡(luò)中所有的流，可以方便地收集存儲NS-3生成的網(wǎng)絡(luò)性能數(shù)據(jù)。NS-3提供了FlowMonitor-Help類，可以方便地創(chuàng)建FlowMonitor。它使用安裝在網(wǎng)絡(luò)節(jié)點(diǎn)中的探針來跟蹤節(jié)點(diǎn)交換的數(shù)據(jù)包，并進(jìn)行測量一些參數(shù)。數(shù)據(jù)包根據(jù)它們所屬的流進(jìn)行劃分，其中每個(gè)流根據(jù)探測器的特征定義，即包含協(xié)議、源地址、源端口、目的地址、目的端口的五元組。收集每個(gè)流的統(tǒng)計(jì)信息可以以XML格式導(dǎo)出，也可以直接訪問探針以請求關(guān)于每個(gè)流的特定統(tǒng)計(jì)數(shù)據(jù)。

3 仿真內(nèi)容與結(jié)果分析

在客戶端安裝相同的應(yīng)用產(chǎn)生網(wǎng)絡(luò)流量[8]，通過Wireshark和FlowMonitor來監(jiān)控服務(wù)器端每秒接收網(wǎng)絡(luò)包的數(shù)量。下面將分別介紹不同網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)下的實(shí)驗(yàn)結(jié)論。

3.1 三個(gè)節(jié)點(diǎn)網(wǎng)絡(luò)拓?fù)?/h3>

三個(gè)節(jié)點(diǎn)組成等邊三角形的拓?fù)浣Y(jié)構(gòu)，如圖1所示，每個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)都將同時(shí)安裝Sta-AP和ad hoc協(xié)議。其中n0作為發(fā)送端節(jié)點(diǎn)，n2為接收端節(jié)點(diǎn)，n0節(jié)點(diǎn)上安裝由OnOffHelper類生成的OnOff應(yīng)用，通過監(jiān)測n0至n2的網(wǎng)絡(luò)流量得出實(shí)驗(yàn)結(jié)論。

圖1 三個(gè)節(jié)點(diǎn)拓?fù)浣Y(jié)構(gòu)

當(dāng)n0和n2之間的距離小于294米時(shí)，從圖2中得出結(jié)論ad hoc性能更好一些；當(dāng)n0和n2之間的距離等于294米時(shí)，三角形高度等于255米時(shí)，模擬ad hoc和Sta-AP協(xié)議，n2每秒接收的數(shù)據(jù)包都為0；當(dāng)距離不變，三角形高度調(diào)整為50米時(shí)，Sta-AP協(xié)議下n2每秒接收的數(shù)據(jù)包為107個(gè)，而ad hoc協(xié)議下n2每秒接收的數(shù)據(jù)包仍為0個(gè)。由此可見，當(dāng)超過一定距離范圍時(shí)，Sta-AP表現(xiàn)的更好。

圖2 不同距離時(shí)每秒接收包的數(shù)量

既然超過一定距離時(shí)Sta-AP表現(xiàn)更好，嘗試在當(dāng)n0和n2之間的距離等于294米時(shí)，三角形高度等于50米時(shí)加載路由協(xié)議，可以發(fā)現(xiàn)加載AODV協(xié)議[9]時(shí)ad hoc表現(xiàn)的更好，加載OLSR協(xié)議時(shí)[10]，Sta-AP表現(xiàn)更好。

3.2 五個(gè)節(jié)點(diǎn)網(wǎng)絡(luò)拓?fù)?/h3>

五個(gè)節(jié)點(diǎn)可以互相通信，每個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)都將安裝Sta-AP或ad hoc協(xié)議，當(dāng)節(jié)點(diǎn)安裝ad hoc協(xié)議時(shí)，同時(shí)也加載路由協(xié)議。結(jié)構(gòu)如圖3所示。實(shí)驗(yàn)中兩條鏈路將產(chǎn)生網(wǎng)絡(luò)傳輸流量，第一條為n0作為發(fā)送端節(jié)點(diǎn)，n2為接收端節(jié)點(diǎn)；第二條為n3作為發(fā)送端節(jié)點(diǎn)，n4為接收端節(jié)點(diǎn)。n0、n3節(jié)點(diǎn)上安裝由OnOffHelper類生成的OnOff應(yīng)用，通過監(jiān)測兩條鏈路的網(wǎng)絡(luò)流量得出實(shí)驗(yàn)結(jié)論。

圖3 五個(gè)節(jié)點(diǎn)拓?fù)浣Y(jié)構(gòu)

從圖4、圖5的實(shí)驗(yàn)結(jié)果可以發(fā)現(xiàn)，無論AP節(jié)點(diǎn)是靜止還是移動(dòng)，ad hoc模式下接收包的數(shù)量總是Sta-AP模式的兩倍。

通過分析Wireshark產(chǎn)生的pcap抓包文件可以解釋上述結(jié)論的原因。通過比較Sta-AP和ad hoc模式下一個(gè)包的傳輸時(shí)間，發(fā)現(xiàn)ad hoc模式下n0到n2用時(shí)0.004 449 s，Sta-AP模式下n0到n2用時(shí)0.008 898 s，所以ad hoc模式下接收包的數(shù)量總是Sta-AP模式的兩倍。Sta-AP模式下n0節(jié)點(diǎn)要先連接n1(AP節(jié)點(diǎn))傳輸用時(shí)0.004 449 s，然后n1再連接到n2傳輸用時(shí)0.004 449 s，所以累計(jì)就是0.008 898 s。因此，這也是這種網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)下ad hoc模式比Sta-AP模式性能更勝一籌的原因。

圖4 AP靜止時(shí)每秒接收包的數(shù)量

圖5 AP移動(dòng)時(shí)每秒接收包的數(shù)量

3.3 五個(gè)節(jié)點(diǎn)遠(yuǎn)距離的網(wǎng)絡(luò)拓?fù)?/h3>

通過設(shè)置n0到n2之間、n3到n4之間不同的遠(yuǎn)距離長度如600米、1 500米、3 000米，比較ad hoc模式和Sta-AP模式的性能，如圖6所示。每個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)都將安裝Sta-AP或ad hoc協(xié)議，當(dāng)節(jié)點(diǎn)安裝ad hoc協(xié)議時(shí)，同時(shí)也加載路由協(xié)議。

圖6 節(jié)點(diǎn)速度變化后的性能

實(shí)驗(yàn)中設(shè)置除了n1節(jié)點(diǎn)外的節(jié)點(diǎn)一直都在移動(dòng)，比較n1節(jié)點(diǎn)靜止和移動(dòng)狀態(tài)下，兩個(gè)協(xié)議的性能。

實(shí)驗(yàn)結(jié)果發(fā)現(xiàn)不管中間節(jié)點(diǎn)n1靜止還是移動(dòng)，ad hoc模式都比Sta-AP模式性能更好。隨著距離的增加，增加節(jié)點(diǎn)的移動(dòng)速度時(shí)，無論是ad hoc模式還是Sta-AP模式，服務(wù)端收到的包都在增加。

3.4 六個(gè)節(jié)點(diǎn)兩個(gè)AP的網(wǎng)絡(luò)拓?fù)?/h3>

這個(gè)場景選取n0、n1為兩個(gè)AP節(jié)點(diǎn)，n2、n3為客戶端節(jié)點(diǎn)，負(fù)責(zé)發(fā)送數(shù)據(jù)包，n4和n5為服務(wù)端節(jié)點(diǎn)，用于接收數(shù)據(jù)包。左側(cè)的n2、n3連接n0即AP1(SSID=wifi1)，右側(cè)n4、n5連接n1即AP2(SSID=wifi2)，AP1和AP2之間用有線連接起來，每個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)都將安裝Sta-AP或ad hoc協(xié)議。實(shí)驗(yàn)中兩條鏈路產(chǎn)生網(wǎng)絡(luò)傳輸流量，第一條flow1為n3作為發(fā)送端節(jié)點(diǎn)，n5為接收端節(jié)點(diǎn)，第二條flow2為n2作為發(fā)送端節(jié)點(diǎn)，n4為接收端節(jié)點(diǎn)。拓?fù)浣Y(jié)構(gòu)如圖7所示。

圖7 六個(gè)節(jié)點(diǎn)兩個(gè)AP的網(wǎng)絡(luò)拓?fù)?/p>

//創(chuàng)建使用P2P鏈路的兩個(gè)節(jié)點(diǎn)n0和n1，每一個(gè)節(jié)點(diǎn)安裝點(diǎn)到點(diǎn)的網(wǎng)絡(luò)設(shè)備，在它們之間有一個(gè)點(diǎn)到點(diǎn)的信道。兩個(gè)設(shè)備被配置在一個(gè)有2 ms傳輸延時(shí)的信道上，以5 Mbps的速率傳輸數(shù)據(jù)[11]。

NodeContainer p2pNodes;

p2pNodes.Create (2);

PointToPointHelper pointToPoint;

pointToPoint.SetDeviceAttribute("DataRate",StringValue ("5Mbps"));

pointToPoint.SetChannelAttribute("Delay",StringValue ("2ms"));

NetDeviceContainer p2pDevices;

p2pDevices = pointToPoint.Install (p2pNodes);

//創(chuàng)建左側(cè)無線自組網(wǎng)節(jié)點(diǎn)n2和n3，并將n0作為AP1節(jié)點(diǎn)。AP1是個(gè)雙模節(jié)點(diǎn)，安裝有Sta-AP和PointToPoint兩個(gè)網(wǎng)絡(luò)設(shè)備。

NodeContainer leftAdhocNodes;

leftAdhocNodes.Create(2);

leftAdhocNodes.Add(p2pNodes.Get(0));

//創(chuàng)建右側(cè)無線自組網(wǎng)節(jié)點(diǎn)n4和n5，并將n1作為AP2節(jié)點(diǎn)。AP2是個(gè)雙模節(jié)點(diǎn)，安裝有Sta-AP和PointToPoint兩個(gè)網(wǎng)絡(luò)設(shè)備。

NodeContainer rightAdhocNodes;

rightAdhocNodes.Create(2);

rightAdhocNodes.Add(p2pNodes.Get(1));

//NS3缺省的設(shè)置是802.11a采用的頻段，實(shí)驗(yàn)中設(shè)置為802.11b協(xié)議。

WifiHelper wifi;

wifi.SetStandard(WIFI_PHY_STANDARD_80211b);

//初始化WIFI信道和物理層

YansWifiPhyHelper wifiPhy = YansWifiPhyHelper::Default ();

//設(shè)置傳輸損耗模型[12]

wifiPhy.Set("EnergyDetectionThreshold",DoubleValue(-80));

wifiPhy.Set("CcaMode1Threshold",DoubleValue(-81));

YansWifiChannelHelper wifiChannel;[13]

wifiChannel.SetPropagationDelay("ns3::ConstantSpeedPropagationDelayModel");

wifiChannel.AddPropagationLoss("ns3::FriisPropagationLossModel");

wifiPhy.SetChannel (wifiChannel.Create ());

//分別為左側(cè)和右側(cè)節(jié)點(diǎn)裝載Wifi協(xié)議

WifiMacHelper wifiMac;

wifiMac.SetType ("ns3::AdhocWifiMac");

NetDeviceContainer leftdevices = wifi.Install (wifiPhy,wifiMac,leftAdhocNodes);

NetDeviceContainer rightdevices = wifi.Install (wifiPhy,wifiMac,rightAdhocNodes);

//設(shè)置移動(dòng)模型，讓節(jié)點(diǎn)n2、n3、n4、n5移動(dòng)起來[14]

mobility.SetMobilityModel ("ns3::RandomWaypointMobilityModel","Speed",StringValue(speedConstantRandom VariableStream.str ()),

"Pause",StringValue (pauseConstantRandomVariableStream.str ()), "PositionAllocator", PointerValue (taPositionAlloc));

mobility.SetPositionAllocator (taPositionAlloc);

mobility.Install(leftAdhocNodes.Get(0));

mobility.Install(leftAdhocNodes.Get(1));

mobility.Install(rightAdhocNodes.Get(0));

mobility.Install(rightAdhocNodes.Get(1));

//設(shè)置移動(dòng)模型，讓節(jié)點(diǎn)n0、n1移動(dòng)起來

Ptr positionAlloc =

CreateObject ();

positionAlloc ->Add(Vector(200,100, 0));

positionAlloc ->Add(Vector(2800,100, 0));

mobility.SetPositionAllocator(positionAlloc);

mobility.SetMobilityModel("ns3::ConstantPositionMobilityModel");

mobility.Install(p2pNodes);

//實(shí)驗(yàn)中使用OnOff模式模擬產(chǎn)生流量，設(shè)置n2向n4節(jié)點(diǎn)發(fā)送流量，設(shè)置On狀態(tài)下的速率和發(fā)包大小

OnOffHelper onoff1("ns3::UdpSocketFactory", InetSocketAddress (rightAdhocInterfaces.GetAddress(0),45));

onoff1.SetAttribute ("PacketSize", UintegerValue (packetSize));

onoff1.SetAttribute ("DataRate", StringValue ("3000000bps"));

onoff1.SetAttribute("OnTime",StringValue("ns3::ConstantRandomVariable[Constant=1]"));

onoff1.SetAttribute("OffTime",StringValue("ns3::ConstantRandomVariable[Constant=0]"));

//將n2設(shè)置為發(fā)送數(shù)據(jù)包節(jié)點(diǎn)

ApplicationContainer app1=onoff1.Install(leftAdhocNodes.Get(0));

app1.Start(Seconds (var->GetValue (m_dataStart, m_dataStart + 1)));

app1.Stop (Seconds (800.0))

//實(shí)驗(yàn)中使用PacketSinkHelper模擬接收數(shù)據(jù)包，將n4設(shè)置為接收數(shù)據(jù)包節(jié)點(diǎn)。

PacketSinkHelper sink2 ("ns3::UdpSocketFactory", InetSocketAddress (rightAdhocInterfaces.GetAddress(0),45));

ApplicationContainer app2=sink2.Install(rightAdhocNodes.Get(0));

app2.Start(Seconds (var->GetValue (m_dataStart, m_dataStart + 1)));

app2.Stop (Seconds (800.0));

//實(shí)驗(yàn)中使用 FlowMonitorHelper監(jiān)控各個(gè)節(jié)點(diǎn)的流量

FlowMonitorHelper flowmon;

Ptr monitor=flowmon.Install(allNodes);

NS_LOG_INFO ("Run Simulation.");

Simulator::Stop(Seconds(800.0));

Simulator::Run ();

monitor->CheckForLostPackets();

Ptr classifier = DynamicCast (flowmon.GetClassifier());

std::map stats=monitor->GetFlowStats();

//監(jiān)控各個(gè)節(jié)點(diǎn)的流量并輸出

for (std::map::const_iterator i=stats.begin();i!=stats.end();++i)

{

Ipv4FlowClassifier::FiveTuplet=classifier->FindFlow(i->first);

//監(jiān)控flow1的流量并輸出發(fā)送包和接收包的數(shù)量

if ((t.sourceAddress == "10.1.2.2" && t.destinationAddress == "10.1.3.2" && t.destinationPort==45))

{

std::cout<<"Flow"<first<<"protocol"<

ess<<"->"<

std::cout<<"Ap1-Sta1 transmitted packets:"<second.txPackets<<" ";

std::cout<<"Ap2-Sta1 received packets:"<second.rxPackets<<" ";

}

//監(jiān)控flow2的流量并輸出發(fā)送包和接收包的數(shù)量[15]

else if ((t.sourceAddress == "10.1.2.1" && t.destinationAddress == "10.1.3.1" && t.destinationPort==45))

{

std::cout<<"Flow "<first<<" protocol"<"<

std::cout<<"Ap1-Sta2 transmitted packets:"<second.txPackets<<" ";

std::cout<<"Ap2-Sta2 received packets:"<second.rxPackets<<" ";

}

實(shí)驗(yàn)結(jié)果表明(見圖8)，如果客戶端節(jié)點(diǎn)不安裝任何路由協(xié)議，將不會(huì)發(fā)送任何數(shù)據(jù)包，安裝路由協(xié)議后，將有數(shù)據(jù)流量產(chǎn)生。當(dāng)所有節(jié)點(diǎn)都靜止時(shí)，ad hoc模式比Sta-AP模式性能更好，當(dāng)除了兩個(gè)AP節(jié)點(diǎn)靜止其他所有節(jié)點(diǎn)都移動(dòng)時(shí)，尤其是遠(yuǎn)距離時(shí)，Sta-AP模式性能更好。當(dāng)兩個(gè)AP共用一個(gè)信道時(shí)，彼此有干擾發(fā)生。

圖8 不同信道數(shù)量的傳輸性能

3.5 FlowMonitor和Wireshark的區(qū)別

當(dāng)選擇六個(gè)節(jié)點(diǎn)兩個(gè)AP的拓?fù)浣Y(jié)構(gòu)，選擇 802.11b協(xié)議模擬時(shí)，通過FlowMonitor和Wireshark監(jiān)測流量的差距很大。起初分析是由于FlowMonitor的參數(shù)MaxPerHopDelay引起的，這個(gè)參數(shù)設(shè)置每一跳的最大延時(shí)，缺省值為10秒，如果超過最大延時(shí)將被認(rèn)為丟包。但當(dāng)分析Wireshark的pcap抓包文件，發(fā)現(xiàn)每一跳的延時(shí)都沒有超過10秒。

圖9 802.11a協(xié)議下的FlowMonitor流量監(jiān)測

將802.11b協(xié)議換作802.11a協(xié)議重復(fù)模擬上述現(xiàn)象時(shí)，發(fā)現(xiàn)通過FlowMonitor和Wireshark監(jiān)測流量的差距很小，如圖9所示。使用Wireshark監(jiān)測flow1接收包數(shù)為217個(gè)，flow2接收包數(shù)為4 479個(gè)；使用FlowMonitor監(jiān)測flow1接收包數(shù)為158個(gè)，flow2接收包數(shù)為4 476個(gè)。由此推斷FlowMonitor方法本身的局限性導(dǎo)致這樣的現(xiàn)象。

4 結(jié)束語

該文主要研究了通過NS-3平臺仿真不同網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，充分比較ad hoc模式和Sta-AP模式性能情況。利用Wireshark和FlowMonitor監(jiān)測分析數(shù)據(jù)包，得出一系列實(shí)驗(yàn)結(jié)果，為搭建真實(shí)網(wǎng)絡(luò)環(huán)境提供依據(jù)。Ad hoc模式提供有限的無線傳輸范圍，傳輸速度是Sta-AP模式的兩倍。Sta-AP模式必須要連接有線網(wǎng)，可以拓展無線網(wǎng)的范圍，但是傳輸速度也減少一半，因?yàn)樗枰ㄙM(fèi)時(shí)間傳輸信號到AP而不是直接發(fā)送到目的節(jié)點(diǎn)。FlowMonitor方法本身的局限性導(dǎo)致。