Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky

Za´padoˇceska´ univerzita v Plzni Fakulta aplikovanyćh vˇed Katedra informatiky a vy´poˇcetn´ı techniky

Bakal´ aˇ rsk´ a pr´ ace Mˇ eˇ ren´ı v´ ykonnosti s´ıt’ov´ ych zaˇ r´ızen´ı

Plzeˇ n 2013

Jaroslav Pouzar

Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem bakaláˇrskou práci vypracoval samostatnˇe a v´ yhradnˇe s pouˇzit´ım citovan´ ych pramen˚ u. V Plzni dne 8. kvˇetna 2013 Jaroslav Pouzar

Abstract One of the main objectives of this work is to find and compare existing tools or applications which are commonly used for testing the performance of network devices and to analyze their usage in possible testing scenarios. There are also discussed the issues of designing testing scenarios using these tools. This theses continues by performing the tests previously designed and finally links to the sum up capabilites of measuring tools already available. Based on the results and experience gained I am going to build my own testing utility. This application should meet suggested measuring tool requirements and provide suitable results for evaluating the appropriateness of deployment home or office networking devices.

Abstrakt Jedn´ım ze základn´ıch c´ıl˚ u této práce je vyhledat a porovnat existuj´ıc´ı nástroje a aplikace, které se bˇeˇznˇe pouˇz´ıvaj´ı pro testován´ı v´ ykonu s´ıt’ov´ ych zaˇr´ızen´ı a analyzovat jejich pouˇzit´ı v moˇzn´ ych testovac´ıch scénáˇr´ıch. Práce se dále vˇenuje problematice navrhován´ı testovac´ıch scénáˇr˚ u pomoc´ı tˇechto nástroj˚ u. Na základˇe dosaˇzen´ ych v´ ysledk˚ u a z´ıskan´ ych zkuˇsenost´ı s testován´ım se chystám vytvoˇrit vlastn´ı testovac´ı nástroj. Funkcionalita tohoto nástroje by mˇela vycházet ze z´ıskan´ ych zkuˇsenost´ı s prac´ı s dostupn´ ymi nástroji. Vytvoˇren´ y program by mˇel podporovat rozhodován´ı pˇri posouzen´ı vhodnosti nasazen´ı s´ıt’ov´ ych zaˇr´ızen´ı do konkrétn´ıch provozn´ıch prostˇred´ı.

Obsah ´ 1 Uvod 2 Teoretick´ aˇ c´ ast 2.1 Seznámen´ı s dostupn´ ymi testovac´ımi nástroji 2.2 Moˇznosti zjiˇstˇen´ ych testovac´ıch nástroj˚ u . . 2.3 Popis vybran´ ych testovac´ıch nástroj˚ u . . . . 2.4 Vybraná testovaná zaˇr´ızen´ı . . . . . . . . . . 2.5 Návrh a proveden´ı testovac´ıch scénáˇr˚ u . . . ´ 2.6 Uprava zamˇeˇren´ı testovac´ıch scénáˇr˚ u . . . .

1

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

2 . 2 . 2 . 5 . 10 . 11 . 16

3 Realizaˇ cn´ı ˇ c´ ast 3.1 Návrh testovac´ı aplikace . . . . . . . . . . . . . . . . 3.2 Realizace testovac´ı aplikace . . . . . . . . . . . . . . 3.3 Návrh testovac´ıch scénáˇr˚ u pro aplikaci . . . . . . . . 3.4 Realizace test˚ u na vybran´ ych zaˇr´ızen´ıch . . . . . . . 3.5 Porovnán´ı aplikace s vybran´ ymi existuj´ıc´ımi nástroji

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

19 19 20 25 30 41

4 Z´ avˇ er 42 4.1 Posouzen´ı vhodného nasazen´ı s´ıt’ov´ ych prvk˚ u . . . . . . . . . 42 4.2 Zhodnocen´ı z´ıskan´ ych informac´ı a pˇr´ınos˚ u aplikace . . . . . . . 43 A Namˇ eˇ ren´ e hodnoty

47

B Uˇ zivatelsk´ a dokumentace 54 B.1 Prerekvizity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 B.2 Ovládán´ı aplikace . . . . . . . . . . . . . . . . . . . . . . . . . 54

´ 1 Uvod Téma této práce vzniklo na základˇe potˇreb ovˇeˇren´ı skuteˇcného v´ ykonu domác´ıch s´ıt’ov´ ych zaˇr´ızen´ı. Nˇekterá tato zaˇr´ızen´ı vykazuj´ı pˇri standardn´ıch konfigurac´ıch velmi v´ yznamn´ y pokles pˇrenosové rychlosti nebo zv´ yˇsenou latenci odpovˇed´ı na poˇzadavky odeslané do internetu. Pˇredmˇetem této práce je proto v´ yvoj vlastn´ı testovac´ı aplikace urˇcené k mˇeˇren´ı parametr˚ u datov´ ych tok˚ u pˇres s´ıt’ová zaˇr´ızen´ı nasazená pˇreváˇznˇe v domác´ıch podm´ınkách nebo na nekritick´ ych segmentech poˇc´ıtaˇcové s´ıtˇe.

Abych z´ıskal potˇrebné znalosti a zkuˇsenosti z této problematiky, mus´ım se nutnˇe nejprve zab´ yvat pr˚ uzkumem dostupn´ ych a pouˇz´ıvan´ ych mˇeˇr´ıc´ıch nástroj˚ u, kter´ ymi lze parametry s´ıt’ové infrastruktury mˇeˇrit. Následnˇe se budu zab´ yvat navrhován´ım testovac´ıch scénáˇr˚ u se zapojen´ım vybran´ ych zaˇr´ızen´ı a proveden´ım test˚ u s vyuˇzit´ım dostupn´ ych nástroj˚ u. Namˇeˇrené hodnoty budou poté vyhodnoceny a interpretovány. Diskutována bude i informaˇcn´ı hodnota proveden´ ych test˚ u.

Po vyhodnocen´ı z´ıskan´ ych poznatk˚ u budou formulovány jasné poˇzadavky na vyv´ıjenou aplikaci. Pro aplikaci bude nutné navrhnout vhodné testovac´ı scénáˇre a provést mˇeˇren´ı s vyhodnocen´ım v´ ysledk˚ u.

1

2 Teoretická ˇcást 2.1

Sezn´ amen´ı s dostupn´ ymi testovac´ımi n´ astroji

Vyhledáván´ı jsem zahájil pr˚ uzkumem v´ıce ˇci ménˇe znám´ ych internetov´ ych magaz´ın˚ u [Schön(2012)], [Higgins(2010a)], kde autoˇri recenzuj´ı nová s´ıt’ová zaˇr´ızen´ı urˇcená pro pouˇzit´ı v domác´ım prostˇred´ı. Zde jsem se zaj´ımal o metodiky a nástroje, jaké autoˇri recenz´ı pˇri testován´ı a mˇeˇren´ı pouˇz´ıvaj´ı.

Nebylo v m´ ych silách se detailnˇe seznámit se vˇsemi dostupn´ ymi programy, protoˇze (jak jsem zjistil) nástroj˚ u zamˇeˇren´ ych na generován´ı/mˇeˇren´ı s´ıt’ového provozu jsou k dispozici des´ıtky. Pˇri procházen´ı dokumentac´ı a vlastn´ıch testech jednotliv´ ych program˚ u jsem sledoval, jestli jsou placené nebo neplacené, jakou maj´ı v´ ysledky vypov´ıdaj´ıc´ı hodnotu, jestli poskytuj´ı v´ ystup v´ ysledk˚ u zpracovan´ y do grafické podoby (tj. pro uˇzivatele pˇrehlednˇejˇs´ı), jak aktivn´ı ˇ je komunita, která nástroj vyv´ıj´ı. Casto jsem se setkal s velice zaj´ımav´ ymi projekty, které mˇe oslovily netradiˇcn´ı nab´ıdkou funkc´ı (napˇr´ıklad generován´ı provozu dle statistick´ ych model˚ u v programu NetSpec [Jonkman(2012)]), ale jejich v´ yvoj bohuˇzel skonˇcil pˇred nˇekolika lety. Závˇerem mého pr˚ uzkumu tak bylo zjiˇstˇen´ı, ˇze profesionáln´ı nástroje zab´ yvaj´ıc´ı se touto problematikou jsou jiˇz témˇeˇr v´ yhradnˇe placené - napˇr. IxChariot [Ixia(2012)]. Tyto nástroje nab´ızej´ı detailnˇejˇs´ı konfiguraci protokol˚ u na vyˇsˇs´ıch vrstvách, poskytuj´ı propracované grafické uˇzivatelské prostˇred´ı, disponuj´ı jiˇz pˇredpˇripraven´ ymi testovac´ımi scénáˇri a umoˇzn ˇuj´ı podrobnˇejˇs´ı anal´ yzu a zpracován´ı pˇreneseného datového toku.

2.2

Moˇ znosti zjiˇ stˇ en´ ych testovac´ıch n´ astroj˚ u

Po pr˚ uzkumu dostupn´ ych testovac´ıch nástroj˚ u jsem sestavil pˇrehled d˚ uleˇzit´ ych a uˇziteˇcn´ ych test˚ u mˇeˇren´ı s´ıt’ov´ ych parametr˚ u:

2

Teoretická ˇcást

Moˇznosti zjiˇstˇených testovac´ıch nástroj˚ u

Mˇ eˇ ren´ı maxim´ aln´ı propustnosti – metodika testu se odv´ıj´ı od pouˇzitého protokolu 4.vrstvy ISO/OSI modelu. Pˇri tomto testu je generován maximáln´ı moˇzn´ y provoz, kter´ y je následnˇe pˇrenáˇsen pˇres testované zaˇr´ızen´ı. U 1 protokolu TCP se mˇeˇr´ı skuteˇcnˇe dosaˇzená rychlost pˇrenosu, kterou reguluj´ı TCP congestion avoidance algoritmy [Allman et al.(2009)Allman, Paxson ” Blanton], jeˇz sv´ ymi zásahy zamezuj´ı navázané relaci v pˇret´ıˇzen´ı pˇrenosov´ ych kapacit dostupné linky. Protokol TCP jako takov´ y zajiˇst’uje pak spolehlivost 2 doruˇcen´ı odeslan´ ych zpráv. UDP protokol naopak nebrán´ı odes´ılateli odeslat vˇetˇs´ı mnoˇzstv´ı dat, neˇz s´ıt’ová infrastruktura mezi komunikuj´ıc´ımi stanicemi skuteˇcnˇe zvládne pˇrenést. Proto je nutné bˇehem testu na stranˇe pˇr´ıjemce detekovat pˇr´ıpadnou ztrátu odeslan´ ych datagram˚ u a jako maximáln´ı propustnost s´ıt’ové cesty mezi 2 zaˇr´ızen´ımi bereme takov´ y maximáln´ı datov´ y proud, jenˇz ztrat´ı po cestˇe jen minimáln´ı procento odeslan´ ych datov´ ych jednotek resp. u ´spˇeˇsnˇe pˇrenese vˇsechny pakety, které odes´ılatel odeslal. Nástrojem pro testován´ı maximáln´ı kapacity linky v pˇr´ıpadˇe pouˇzit´ı obou ze zm´ınˇen´ ych protokol˚ u m˚ uˇze b´ yt program iperf.

Replikace re´ aln´ eho provozu – s´ıt’ov´ y provoz je generován s´ıt’ov´ ymi zaˇr´ızen´ımi resp. aplikacemi, programy a procesy, jeˇz pracuj´ı na pozad´ı bˇeˇz´ıc´ıho operaˇcn´ıho systému nebo pˇr´ımo interaguj´ı s uˇzivatelem a potˇrebuj´ı si pro svou ˇcinnost vymˇen ˇovat data s jin´ ym zaˇr´ızen´ım. Protokoly zprostˇredkovávaj´ıc´ı takovou komunikaci maj´ı r˚ uznou podobu a nároˇcnost na pˇripojenou linku. To samé plat´ı o s´ıt’ov´ ych toc´ıch, jeˇz jsou velmi specifické a mohou se napˇr´ıklad liˇsit ve velikosti datov´ ych jednotek ˇci frekvenci vymˇen ˇován´ı ˇr´ıd´ıc´ıch a datov´ ych zpráv. Replikace provozu funguje na principu odchycen´ı uskuteˇcnˇené s´ıt’ové komunikace. Tu uloˇz´ıme do souboru standardizovaného formátu a m˚ uˇzeme upravit hlaviˇcky jednotliv´ ych protokol˚ u a komunikaci se stejnou ˇci upravenou rychlost´ı zopakovat a vyslat znovu na s´ıt’. Jedn´ım z dostupn´ ych program˚ u, kter´ ym lze takové pˇrehrán´ı provozu uskuteˇcnit, je Tcpreplay. Tento nástroj funguje na principu injekce paket˚ u [Wikipedia(2013)] mezi TCP/IP zásobn´ık a vrstvu OS [Tcpreplay(2013)]. Smysl testu pak spoˇc´ıvá v pozorován´ı chován´ı s´ıt’ov´ ych zaˇr´ızen´ı a datov´ ych tok˚ u, kdy se testuje, zda je konkrétn´ı s´ıt’ová infrastruktura schopna pˇrenést urˇcit´ y objem komunikace v daném ˇcase a to bez pozorovan´ ych ztrát. 1 2

Transmission Control Protocol User Datagram Protocol

3


Moˇznosti zjiˇstˇených testovac´ıch nástroj˚ u

Mˇ eˇ ren´ı latence – latenci oznaˇcujeme jako zpoˇzdˇen´ı (ve vˇetˇsinˇe pˇr´ıpad˚ u udáváno v milisekundách), které uplyne mezi odeslán´ım paketu z jednoho s´ıt’ového zaˇr´ızen´ı a pˇr´ıjmem téhoˇz paketu druh´ ym zaˇr´ızen´ım. Tehdy mluv´ıme o one-way“ latenci neboli jednosmˇerném zpoˇzdˇen´ı. V praxi je vˇsak uˇziteˇcnˇejˇs´ı ” znát dobu, za kterou se nám vrát´ı odpovˇed’ od odeslán´ı poˇzadavku. Takov´ y ˇcasov´ y u ´sek bychom oznaˇcili jako two-way“(obousmˇernou) latenci, obecnˇe ” známou jako RTT3 . Pro mˇeˇren´ı RTT pouˇz´ıváme sadu protokol˚ u z rodiny 4 ICMP .

Sledov´ an´ı kvality – Jitter, pojem nˇekdy znám´ y sp´ıˇse jako Packet Delay ” 5 Variation“ je jedn´ım z ukazatel˚ u QoS a v souvislosti s n´ım mluv´ıme o kol´ısán´ı latenc´ı s´ıtˇe. S´ıt’ s konstantn´ı dobou odezvy má hodnotu jitter rovnou 0 a vypov´ıdá o stavu, kdy ˇcasová prodleva mezi libovoln´ ymi 2 odeslan´ ymi pakety je shodná s ˇcasovou prodlevou, s jakou jsou tyto pakety doruˇceny pˇr´ıjemci. V souvislosti s odchylkou mluv´ıme o disperzi paket˚ u nebo naopak o shlukován´ı. [Demichelis – Chimento(2002)Demichelis, Chimento] V´ yskyt tˇechto jev˚ u je velmi neˇza´douc´ı napˇr´ıklad bˇehem pˇrenosu hlasov´ ych sluˇzeb. Pˇr´ıklad rozptylu: V ˇcase t0 odeˇsle stanice A paket P1 stanici B, v ˇcase t0 +10ms odes´ılá stanice A paket P2 stanici B. Stanice B v ˇcase t0 +20ms pˇrij´ımá paket P1 v ˇcase t0 +35ms paket P2. Mezi odeslán´ım P1 a P2 uplynulo 10ms, stanice B registruje rozd´ıl 35-20=15ms. Pˇr´ıklad shlukov´ an´ı: V ˇcase t0 odeˇsle stanice A paket P1 stanici B, v ˇcase t0 +10ms odes´ılá stanice A paket P2 stanici B. Stanice B v ˇcase t0 +20ms pˇrij´ımá paket P1 v ˇcase t0 +25ms paket P2. Mezi odeslán´ım P1 a P2 uplynulo 10ms, stanice B registruje rozd´ıl pouze 25-20=5ms.

Mˇ eˇ ren´ı spolehlivosti – v souvislosti s jiˇz od návrhu nespolehliv´ ym pˇrenosem dat na bázi protokolu UDP mluv´ıme o ztrátovosti paket˚ u. Klient v praxi nem˚ uˇze ovlivnit rychlost, jakou k nˇemu server odes´ılá proud – stream“ ” UDP datagram˚ u (napˇr´ıklad televizn´ı vys´ılán´ı). Záleˇz´ı tedy na s´ıt’ov´ ych prvc´ıch a kapacitách pˇrenosov´ ych linek po cestˇe od serveru ke klientovi, zda kaˇzd´ y jednotliv´ y paket dosáhne svého c´ıle. V praxi m˚ uˇze nastat, ˇze zdroj UDP streamu vys´ılá datagramy tak rychle, ˇze smˇerovaˇc na trase nemus´ı b´ yt schopen vˇsechny pakety v reálném ˇcase smˇerovat a zaˇcne urˇcitou ˇca´st provozu 3

Round Trip Time Internet Control Message Protocol 5 Quality of Service 4

4


Popis vybraných testovac´ıch nástroj˚ u

zahazovat. Takov´ y jev má pak velmi nepˇr´ızniv´ y v´ ysledek na kvalitu sluˇzby, kterou server poskytuje. V pˇr´ıpadˇe televizn´ıho vys´ılán´ı m˚ uˇze napˇr´ıklad docházet k v´ ypadk˚ um obrazu/zvuku. Jako mˇeˇr´ıc´ı nástroj ztrátovosti paket˚ u lze vyuˇz´ıt napˇr´ıklad zm´ınˇen´ y iperf.

Mˇ eˇ ren´ı maxim´ aln´ıho poˇ ctu spojen´ı – snahou tohoto testu je zjistit, kolika relac´ım je umoˇznˇeno ve velmi krátkém ˇcasovém intervalu navázat spojen´ı pˇres testované zaˇr´ızen´ı. Test provádˇej´ı 2 stanice, kdy jedna figuruje jako klient, kter´ y generuje a odes´ılá poˇzadavky ze zadaného rozsahu port˚ u na server, jenˇz obratem odpov´ıdá, aby potvrdil klientovi, ˇze je spojen´ı funkˇcn´ı. Pro tento test se pouˇz´ıvá z d˚ uvod˚ u rychlosti protokolu UDP, proto si nesm´ıme zamˇen ˇovat v´ yˇse zm´ınˇen´ y pojem relace s TCP relac´ı. Relacemi v tomto kontextu rozum´ıme napˇr´ıklad záznamy v NAT6 tabulce smˇerovaˇce.

2.3

Popis vybran´ ych testovac´ıch n´ astroj˚ u

Iperf - Velmi ˇcasto zmiˇ novan´ y a pouˇz´ıvan´ y CLI nástroj a to zejména d´ıky tomu, ˇze je zdarma a poskytuje moˇznosti základn´ıho testován´ı s´ıtˇe. Program podporuje klient-server architekturu a je kromˇe mˇeˇren´ı maximáln´ıho datového toku schopen evidovat ztrátovost paket˚ u pˇri UDP proudu, mˇeˇrit jitter a generovat/zachytávat multicastov´ y provoz. Program umoˇzn ˇuje zápis v´ ysledk˚ u test˚ u do textového souboru, ale nepodporuje grafickou vizualizaci z´ıskan´ ych v´ ysledk˚ u. Posledn´ı verze (2.0.5) byla vydána a uveˇrejnˇena na oficiáln´ıch stránkách projektu na portále v ˇcervenci 2010. [Sourceforge(2010)]

JPerf – Jedná se o nástroj s grafick´ ym ovládac´ım rozhran´ım, které má za u ´kol zpˇrehlednit a usnadnit uˇzivateli ovládán´ı v´ yˇse zm´ınˇené utility iperf, nebot’ právˇe ta je jádrem této aplikace. GUI zajiˇst’uje spuˇstˇen´ı nástroje iperf se zadan´ ymi parametry a následnˇe zobrazuje v´ ysledky z´ıskané z mˇeˇren´ı do grafu um´ıstˇeného v rámci okna aplikace a umoˇzn ˇuje ukládat testovac´ı konfigurace pro budouc´ı opˇetovné pouˇzit´ı. Jde o multiplatformn´ı nástroj napsan´ y v jazyce JAVA.

6

Network Address Translation

5



Obrázek 2.1: Mˇeˇr´ıc´ı nástroj JPerf pˇri bˇehu JMeter – nástroj urˇcen´ y pro testován´ı aplikac´ı, nikoliv pro mˇeˇren´ı parametr˚ u pˇrenos˚ u. P˚ uvodn´ım zamˇeˇren´ım byl zac´ılen na webové aplikace, pozdˇeji se rozrostl o dalˇs´ı protokoly (FTP7 , LDAP8 , databáze, shell skripty, poˇstovn´ı protokoly). V pˇr´ıpadˇe proveden´ı testu ve scénáˇri, kde je s´ıt’ová infrastruktura nejslabˇs´ım ˇclánkem tj. v´ ykon serveru a klienta pˇrevyˇsuje kapacitu spojovac´ı linky (vˇcetnˇe aktivn´ıch zaˇr´ızen´ı v cestˇe), lze vyuˇz´ıt tento nástroj jako simulátor generuj´ıc´ı reáln´ y s´ıt’ov´ y provoz a namˇeˇrené hodnoty datového toku bychom za urˇcit´ ych okolnost´ı mohli povaˇzovat jako hodnoty prahové – na daném spoji maximáln´ı. Reáln´ ym s´ıt’ov´ ym provozem rozum´ıme takov´ y, kter´ y bychom byli schopni zachytit pˇri bˇeˇzném provozu na testované lince. Zm´ınˇen je zde, protoˇze jak se pozdˇeji v realizaˇcn´ı ˇca´sti ukáˇze, bude v´ ysledná aplikace vycházet z p˚ uvodn´ı idey tohoto nástroje.

Btest – proprietárn´ı nástroj integrovan´ y do kaˇzdého zaˇr´ızen´ı v´ yrobce MikroTik. To je tak schopné provádˇet jednoduch´ y zátˇeˇzov´ y test pro zvolen´ y konkrétn´ı zvolen´ y smˇer (download x upload) nebo oba smˇery najednou. Podporuje UDP i TCP relace a velkou v´ yhodou je moˇznost proveden´ı tohoto testu mezi jak´ ymikoliv dvˇema MikroTik zaˇr´ızen´ımi, nebot’ vˇsechny tyto prvky disponuj´ı nástrojem btest (kaˇzdé zaˇr´ızen´ı m˚ uˇze p˚ usobit jako klient nebo server). 7 8

File Transfer Protocol Lightweight Directory Access Protocol

6



Obrázek 2.2: Vizualizace hodnot jednoduchého http testu v grafickém prostˇred´ı programu JMeter

Obrázek 2.3: MikroTik Bandwidth Test – konfiguraˇcn´ı rozhran´ı 7



Obrázek 2.4: MikroTik Bandwidth Test – vizualizace namˇeˇren´ ych hodnot Max-session-tool – na obsluhu velmi jednoduch´ y CLI nástroj, pouˇz´ıvan´ y napˇr´ıklad v testech domác´ıch zaˇr´ızen´ı. Program má serverovou a klientskou ˇcást, pˇriˇcemˇz klient ve velmi krátkém ˇcasovém u ´seku odes´ılá UDP pakety ze ˇsirokého rozsahu port˚ u na IP adresu protˇejˇsku, kter´ y je v topologii za testovan´ ym s´ıt’ov´ ym prvkem. Vstupn´ımi parametry je na serverové stranˇe IP adresa a prvn´ı ˇc´ıslo portu, na kterém má server naslouchat a na klientovi zadáváme IP adresu, port serveru a prvn´ı ˇc´ıslo portu, ze kterého klient zaˇcne odes´ılat. Princip mˇeˇren´ı hodnoty je takov´ y, ˇze pˇri vyprˇsen´ı timeoutu n-tého spojen´ı urˇc´ıme maximáln´ı poˇcet konkurentn´ıch spojen´ı, které je zaˇr´ızen´ı stoj´ıc´ı v cestˇe schopno obslouˇzit, jako hodnotu n-1. [Higgins(2010b)] Zdrojové a c´ılové porty se bˇehem testu inkrementálnˇe o jedniˇcku zvyˇsuj´ı. Bˇehem tohoto mˇeˇren´ı by nemˇela b´ yt pˇripojena do topologie ˇzádná dalˇs´ı aktivn´ı s´ıt’ová zaˇr´ızen´ı a z hostitelsk´ ych zaˇr´ızen´ı by nemˇela odcházet ˇza´dná dalˇs´ı komunikace.

Webserver stress tool 7 - tento nástroj je, jak jiˇz samotn´ y název napov´ıdá, primárnˇe urˇcen pro simulaci reálného prostˇred´ı a testován´ı/záznam chován´ı webov´ ych server˚ u pod zátˇeˇz´ı. Program nahrazuje aktivity uˇzivatelského webového prohl´ıˇzeˇce a zaznamenává u ´daje o délce vyˇr´ızen´ı poˇzadavku. Pomoc´ı tohoto nástroje jsem simuloval aktivity typu prohl´ıˇzen´ı webu a za t´ımto u ´ˇcelem pouˇzil pouze takové weby, o kter´ ych se domn´ıvám, ˇze maj´ı natolik silnou hw strukturu, ˇze mohu vylouˇcit pokles v´ ykonnosti serveru na základˇe mého testován´ı. Typicky www.seznam.cz, www.idnes.cz, www.novinky.cz, www.blesk.cz atd.

Pˇri konfiguraci testu se vyplˇ nuje seznam URL, jeˇz maj´ı b´ yt navˇstˇevovány/proklikávány virtuáln´ımi uˇzivateli, vol´ı se testovac´ı prohl´ıˇzeˇc a nastavuj´ı parametry jako ˇcetnost klik˚ u, délka testu. Plná verze programu je po8



skytována za u ´platu, zat´ımco verze Free trial“ nab´ız´ı totoˇzné funkce, ale ” pouze omezené mnoˇzstv´ı virtuáln´ıch uˇzivatel˚ u na 10 a frekvenci kliknut´ı 1 uˇzivatele nejv´ıce 1 krát za 5 sekund. [Paessler(2013)] Tato omezen´ı mˇe vˇsak nelimituj´ı, protoˇze v c´ılovém prostˇred´ı jen zˇr´ıdkakdy bude v´ıce jak 10 uˇzivatel˚ u soubˇeˇznˇe prohl´ıˇzet webové stránky a ˇcetnost kliku v prohl´ıˇzeˇci 1x za 5s na jednoho uˇzivatele se mi jev´ı jako dostaˇcuj´ıc´ı (720 zobrazen´ ych stránek za hodinu).

V´ ystupem z proveden´ ych mˇeˇren´ı je obsáhl´ y HTML report s celkov´ ymi statistikami, kolik dat bylo kter´ ym uˇzivatelem pˇreneseno a jak´ y objem s´ıt’ového provozu byl po dobu testu spotˇrebován. Jistˇe nejzaj´ımavˇejˇs´ım u ´dajem je vˇsak graf zobrazuj´ıc´ı dobu vyˇr´ızen´ı poˇzadavku(doba od kliku na odkaz po naˇcten´ı stránky) v pr˚ ubˇehu bˇehu testu. Jako ilustraˇcn´ı pˇr´ıklad pˇrikládám obrázky 2.5 a 2.6

Obrázek 2.5: 10 uˇzivatel˚ u, 1 web: http://www.idnes.cz, kaˇzd´ y uˇzivatel 1 zobrazen´ı za 5 sekund

9


Vybraná testovaná zaˇr´ızen´ı

Obrázek 2.6: 10 uˇzivatel˚ u, 1 web: http://m.idnes.cz – mobiln´ı verze portálu idnes.cz, kaˇzd´ y uˇzivatel 1 zobrazen´ı stránky za 5 sekund IxChariot - profesionáln´ı, placen´ y nástroj urˇcen´ y pro testován´ı parametr˚ u spojen´ı mezi 2 s´ıt’ov´ ymi zaˇr´ızen´ımi. Podle dokumentace a specifikace [Jonkman(2012)] se jedná o ideáln´ı nástroj testován´ı s velkou m´ırou komplexity test˚ u. Umoˇzn ˇuje volbu generován´ı provozu na u ´rovni aplikaˇcn´ıch protokol˚ u. Bohuˇzel jsem nemohl vyzkouˇset ani testovac´ı verzi tohoto sw, nebot’ i k tomu je nutné m´ıt aktivn´ı u ´ˇcet na portálu firmy, kter´ y je vˇsak podm´ınˇen zakoupen´ım alespoˇ n jednoho kusu HW od této spoleˇcnosti nebo jej´ıch partner˚ u.

2.4

Vybran´ a testovan´ a zaˇ r´ızen´ı

Smˇ erovaˇ ce: • Asus WL500G • Cisco 2801 • Edimax BR6204WG • Linksys WRT150N • Mikrotik RouterBoard RB532 10


Návrh a proveden´ı testovac´ıch scénáˇr˚ u

Pˇ rep´ınaˇ ce: • Ovislink FSH8PS • Cisco 3560

2.5

N´ avrh a proveden´ı testovac´ıch sc´ en´ aˇ r˚ u

Po u ´vodn´ım pr˚ uzkumu vybran´ ych nástroj˚ u jsem sestavil nˇekolik obecn´ ych testovac´ıch scénáˇr˚ u pro nástroj iperf. Motivem byla snaha se s nástrojem bl´ıˇze seznámit a z´ıskat z proveden´ ych mˇeˇren´ı data, která bych mohl pozdˇeji porovnat s v´ ysledky jin´ ych (podobnˇe zamˇeˇren´ ych) program˚ u. Obrázky zapojen´ı s´ıt’ov´ ych zaˇr´ızen´ı jsem vypracovával v simulaˇcn´ım programu Cisco Packet Tracer 5.3.3, jehoˇz pouˇzit´ı je mi jako studentovi s´ıt’ové akademie pˇri ˇ k dispozici. ZCU 1) Testované zaˇr´ızen´ı:

Smˇerovaˇc

Reˇzim zaˇr´ızen´ı:

NAT

Sledované parametry:

Rychlost TCP pˇrenosu, server => klient

Schéma scénáˇre:

Obrázek 2.7

Obrázek 2.7:

11



2) Testované zaˇr´ızen´ı:

Smˇerovaˇc


ROUTING




Obrázek 2.8

Obrázek 2.8: 3) Testované zaˇr´ızen´ı:

Smˇerovaˇc


BRIDGE




Obrázek 2.9

Obrázek 2.9:

12



4) Testované zaˇr´ızen´ı:

Smˇerovaˇc


ROUTING


ztrátovost UDP paket˚ u


Obrázek 2.10

Obrázek 2.10: 5) Testované zaˇr´ızen´ı:

pˇrep´ınaˇc nebo LAN rozhran´ı smˇerovaˇc˚ u


nedefinováno




Obrázek 2.11

Obrázek 2.11:

13



Reˇzim NAT

TCP window size 56kB 112kB ROUTING 56kB 112kB BRIDGE 56kB 112kB

Uˇziteˇcná rychlost 69,6 Mb/s 93,5 Mb/s 69,9 Mb/s 93,8 Mb/s 70,3 Mb/s 94,2 Mb/s

Tabulka 2.1: Srovnán´ı pˇrenosov´ ych rychlost´ı jednotliv´ ych reˇzim˚ u

QoS UDP packet size Ztrátovost Vypnuto 1500Byte 0% 6000Byte 15,2 % Zapnuto 1500Byte 0% 6000Byte 43,4 % Tabulka 2.2: Vliv funkce QoS na ztrátovost UDP paket˚ u

Komunikace TCP window size Klient1-Server1 56kB 112kB Klient2-Server2 56kB 112kB

Uˇziteˇcná rychlost 72,6 Mb/s 91,5 Mb/s 71,4 Mb/s 93,2 Mb/s

Tabulka 2.3: Pˇrenosové rychlosti v závislosti na velikosti TCP window size

14



Vyhodnocen´ı proveden´ ych test˚ u Testovac´ı scénáˇre 1,2,3,4 jsem realizoval se smˇerovaˇcem RouterBoard RB532. Pro scénáˇr ˇc.5 jsem pouˇzil s´ıt’ov´ y pˇrep´ınaˇc Ovislink FSH8PS. Z´ıskaná data jsou v tabulkách 2.1, 2.2 a 2.3. Z namˇeˇren´ ych hodnot v tabulce 2.1 soud´ım, ˇze zmˇena reˇzimu zaˇr´ızen´ı nemá v´ yznamn´ y vliv na pˇrenosovou rychlost testovac´ıho vzorku dat. Jako mnohem zásadnˇejˇs´ı se jev´ı velikost parametru TCP window size neboli mnoˇzstv´ı dat, které m˚ uˇze jedna strana odeslat bez ˇcekán´ı na potvrzen´ı druhé strany [Jacobson et al.(1992)Jacobson, Braden Borman]. Po zvˇetˇsen´ı pa” rametru z 56kB na 112kB m˚ uˇzeme pozorovat zv´ yˇsen´ı rychlosti témˇeˇr aˇz k praktickému maximu spojen´ı typu FastEthernet. V tabulce 2.2 lze pozorovat vliv QoS funkce na protékaj´ıc´ı datové pˇrenosy. Dle v´ ysledk˚ u je pro standardn´ı velikosti UDP datagram˚ u (tj. do 1500Byte) v´ ykon smˇerovaˇce dostateˇcn´ y, nebot’ ani pˇri rychlosti 30Mbps nezahod´ı jedin´ y datagram. Pˇri pouˇzit´ı tzv. jumbo paket˚ u smˇerovaˇc jiˇz nest´ıhá smˇerovat vˇsechny pakety a docház´ı ke ztrátám. Po zapnut´ı jednoduché QoS, která pakety pouze znaˇckuje na základˇe zdrojové adresy docház´ı ke znatelnému zv´ yˇsen´ı ztrátovosti. V´ ysledky z´ıskané z testovac´ıho scénaˇre ˇc.5 potvrdily pˇr´ıˇcinu niˇzˇs´ıch pˇrenosov´ ych rychlost´ı u pˇredchoz´ıch scénáˇr˚ u. Sn´ıˇzen´ı hodnoty parametru TCP window size se projevilo poklesem pˇrenosové rychlosti. Namˇeˇrené hodnoty jsou um´ıstˇeny do tabulky 2.3.

15


2.6

´ Uprava zamˇeˇren´ı testovac´ıch scénáˇr˚ u

´ Uprava zamˇ eˇ ren´ı testovac´ıch sc´ en´ aˇ r˚ u

Zhodnocen´ı z´ıskan´ ych poznatk˚ u Provedené testy jsem vyuˇzil k seznámen´ı se s metodikou testován´ı a konfigurac´ı MikroTik zaˇr´ızen´ı. Pˇri navrhován´ı dalˇs´ıch testovac´ıch scénáˇr˚ u se budu snaˇzit brát v u ´vahu, ˇze primárn´ı provozn´ı oblast´ı s´ıt’ového zaˇr´ızen´ı je prostˇred´ı v domácnostech nebo menˇs´ıch firmách. Takové zaˇr´ızen´ı by mˇelo b´ yt schopno: • Pˇrenáˇset rychle a spolehlivˇe data mezi zaˇr´ızen´ımi v rámci LAN • Zachovat kvalitu hlasového hovoru (VOIP) i bˇehem vyˇsˇs´ıho zat´ıˇzen´ı • Zahazovat minimáln´ı mnoˇzstv´ı UDP provozu (napˇr. online hry, stream pro TV) • Pracovat v reˇzimu NAT bez znatelné ztráty v´ ykonu

N´ avrh skupiny testovac´ıch protokol˚ u Provoz generovan´ y testovac´ı aplikac´ı by mˇel b´ yt sv´ ym sloˇzen´ım podobn´ y reálnému provozu, abychom byli schopni odhalit pˇr´ıpadné chyby nebo zhorˇsenou kvalitu s´ıt’ov´ ych sluˇzeb, které maj´ı pro uˇzivatele skuteˇcn´ y v´ yznam. Pro dalˇs´ı testován´ı jsem proto vybral nˇekolik nejpouˇz´ıvanˇejˇs´ıch protokol˚ u. Kaˇzd´ y z tˇechto protokol˚ u je charakteristick´ y sv´ ym chován´ım, velikost´ı komunikaˇcn´ıch jednotek a frekvenc´ı komunikace, nároˇcnost´ı na specifické parametry pˇrenosové soustavy a interaktivitou s lidskou ˇcinnost´ı.

Pˇri v´ ybˇeru testovan´ ych protokol˚ u jsem vycházel ze studie [Schulze – Mochalski(2009)Schulze, Mochalski] nˇemecké spoleˇcnosti Ipoque GmbH, která se specializuje na monitorován´ı a optimalizace datov´ ych tok˚ u dneˇsn´ıho internetu. Zm´ınˇená studie analyzuje zastoupen´ı pouˇzit´ı znám´ ych internetov´ ych protokol˚ u v 8 vybran´ ych regionech svˇeta za rok 2008 a 2009. Celkov´ y vzorek analyzovan´ ych pˇrenesen´ ych dat ˇc´ıtá velikost 1,3 PetaByte. Zaujala mne zde tabulka znázorˇ nuj´ıc´ı pod´ıly jednotliv´ ych tˇr´ıd internetov´ ych protokol˚ u na celkovém pˇreneseném objemu. Z n´ı vypl´ yvá, ˇze nejv´ıce dat je pˇreneseno P2P9 9

Peer to Peer

16



protokoly. Jak se ale v práci m˚ uˇzeme dále doˇc´ıst, pouze 15-20% uˇzivatel˚ u pˇripojen´ ych k internetu vyuˇz´ıvá k datov´ ym pˇrenos˚ um skupiny tˇechto protokol˚ u.

Obrázek 2.12: Procentuáln´ı pod´ıl komunikaˇcn´ıch protokol˚ u na celkovém objemu pˇrenesen´ ych dat

Druhou nejpouˇz´ıvanˇejˇs´ı sadou protokol˚ u je webová sada a tedy hlavnˇe HTTP. Varianta zabezpeˇcené komunikace HTTPS tvoˇrila dle studie pod´ıl jednotek procent. Následuje pˇrenos audio a video médi´ı a hlasov´ ych sluˇzeb. Tabulku uzav´ıraj´ı takzvané standardn´ı protokoly - FTP, SMTP, DNS, POP, IMAP. Pod touto prac´ı jsou podepsáni pánové Hendrik Schulze a Klaus Mochalski. [9]

Vybrané protokoly, jejichˇz kvalita komunikace bude pˇredmˇetem mˇeˇren´ı vyv´ıjené aplikace, jsou: • HTTP – prohl´ıˇzen´ı webu • FTP – pˇrenos soubor˚ u • TELNET – interaktivn´ı komunikace 17



• UDP stream – hry, rádio, televize Zvolené parametry jsou pak v jednotliv´ ych testech: • HTTP – doba potˇrebná k naˇcten´ı stránky • FTP – rychlost pˇrenosu (obˇema smˇery) • TELNET – prodlevy v odezvˇe, v´ ypadky spojen´ı • UDP stream – ztrátovost paket˚ u

Testovac´ı nástroj by mˇel ideálnˇe obsahovat grafické rozhran´ı.

Bˇehem pr˚ uzkumu a práce s testovac´ımi nástroji jsem neobjevil takov´ y program, kter´ y by byl zdarma dostupn´ y a vyhovoval v´ yˇse navrhnut´ ym poˇzadavk˚ um. O jejich naplnˇen´ı se proto budu snaˇzit v rámci vyv´ıjené aplikace v realizaˇcn´ı ˇcásti bakaláˇrské práce.

18

3 Realizaˇcn´ı ˇcást 3.1

N´ avrh testovac´ı aplikace

Poˇ zadavky na aplikaci Poˇzadavky na funkcionality mˇeˇr´ıc´ı aplikace vycház´ı ze závˇer˚ u pˇredchoz´ıch proveden´ ych mˇeˇren´ı. Hlavn´ım motivem tvorby vlastn´ı aplikace je vytvoˇren´ı takového nástroje, kter´ y umoˇzn ˇuje pˇrenáˇset data s vyuˇzit´ım skuteˇcn´ ych a v praxi pouˇz´ıvan´ ych protokol˚ u aplikaˇcn´ı vrstvy ISO/OSI modelu. C´ılem nen´ı sestrojit generátor náhodn´ ych dat ani aplikaci na reprodukci odchyceného provozu. S´ıt’ov´ a architektura a topologie zapojen´ı Schéma s´ıt’ové komunikace pˇri bˇehu v´ıce instanc´ı aplikace v rámci s´ıtˇe bude realizováno ve formátu klient-server a to v pomˇeru 1:N. Jeden server bude schopen najednou vyˇrizovat poˇzadavky od v´ıce klient˚ u. Klienti budou m´ıt na starost konfiguraci, spouˇstˇen´ı a zaznamenáván´ı v´ ysledk˚ u test˚ u – mˇeˇren´ı. Pˇred spuˇstˇen´ım testu mus´ı b´ yt navázáno ˇr´ıd´ıc´ı spojen´ı mezi klientem a serverem. To poskytne klientovi moˇznost poˇzádat server o spuˇstˇen´ı sluˇzeb (daemon˚ u) pˇred samotn´ ym zahájen´ım testu. Server má naopak moˇznost klientovi oznámit pˇr´ıpadn´ y chybov´ y stav poˇzadované sluˇzby, na kter´ y mus´ı b´ yt klient schopen reagovat napˇr. nezahájen´ım testu urˇcitého protokolu nebo kompletnˇe celé testové sady. Klient bude spouˇstˇet v jednom okamˇziku najednou vˇzdy celou sadu test˚ u, pˇriˇcemˇz kaˇzd´ y test (protokol) pobˇeˇz´ı ve vlastn´ım vláknˇe. V pˇr´ıpadˇe, kdy klient provád´ı v´ıce iterac´ı skupiny test˚ u, ˇceká se pˇred zahájen´ım následuj´ıc´ı iterace vˇzdy na dokonˇcen´ı vˇsech test˚ u aktuáln´ı iterace. Podporovan´ e protokoly Aplikace bude vyuˇz´ıvat nejpouˇz´ıvanˇejˇs´ı protokoly aplikaˇcn´ı vrstvy, aby generovan´ y s´ıt’ov´ y tok odpov´ıdal skuteˇcn´ ym datov´ ym pˇrenos˚ um. U kaˇzdého protokolu budou zvoleny sledované parametry, které vypov´ıdaj´ı o kvalitˇe sluˇzby. U kaˇzdého protokolu bude vhodnˇe zvolena odpov´ıdaj´ıc´ı metrika mˇeˇren´ı. Mˇeˇr´ıc´ı nástroj bude schopen generovat a obsluhovat poˇzadavky postavené na protokolu HTTP, FTP, TELNET a zachytávat proud UDP paket˚ u.

19

Realizaˇcn´ı ˇcást

Realizace testovac´ı aplikace

Programovac´ı jazyk Za u ´ˇcelem multiplatformn´ıho nasazen´ı aplikace jsem se rozhodl o jej´ım v´ yvoji v jazyce JAVA bez vyuˇzit´ı utilit tˇret´ıch stran ve formˇe r˚ uzn´ ych binárn´ıch soubor˚ u. Veˇskerou funkcionalitu aplikace budou pokr´ yvat JAVA bal´ıky a knihovny. Grafick´ e rozhran´ı Pro uˇzivatelsky pˇr´ıvˇetivˇejˇs´ı ovládán´ı by mˇela aplikace disponovat grafick´ ym rozhran´ım, kde bude moˇzné nastavit vˇsechny parametry a sledovat pr˚ ubˇeˇzné v´ ysledky mˇeˇren´ı. Form´ at v´ ystupu a uloˇ zen´ı namˇ eˇ ren´ ych dat Namˇeˇrené hodnoty a v´ ysledky test˚ u mus´ı b´ yt moˇzno uloˇzit pro pˇr´ıpadnou anal´ yzu, porovnán´ı ˇci dalˇs´ı zpracován´ı. Pˇri práci s jin´ ymi mˇeˇr´ıc´ımi nástroji jsem ocenil moˇznost sledovat aktuálnˇe namˇeˇrené hodnoty. Ideáln´ım stavem je um´ıstˇen´ı grafu generovaného v reálném ˇcase (nebo periodicky se obnovuj´ıc´ım) do okna aplikace.

3.2


V´ yvojov´ e prostˇ red´ı V´ yvojov´ ym prostˇred´ım pro JAVA aplikaci jsem si zvolil NetBeans. Framework pouˇzit´ y pro v´ yvoj grafického rozhran´ı nástroje je SWING. Architektura a vzhled aplikace Na poˇcátku v´ yvoje testovac´ı aplikace jsem se musel rozhodnout, zda budu vytváˇret 2 aplikace, kdy jedna bude plnit funkci serveru a druhá klienta nebo pouze jednu aplikaci, kdy bude uˇzivatel moci zvolit roli vhodn´ ym pˇrep´ınaˇcem. Pro jednoduˇsˇs´ı distribuci, obsluhu, mobilitu a na základˇe osobn´ıch pozitivn´ıch zkuˇsenost´ı s druhou zm´ınˇenou moˇznost´ı jsem vybral variantu s volbou klient/server aˇz po spuˇstˇen´ı aplikace. Kaˇzdá spustitelná verze aplikace tak m˚ uˇze v testovac´ıch scénáˇr´ıch plnit obˇe dvˇe role (ne v jeden okamˇzik). Pˇri rozdˇelen´ı na klientskou a serverovou ˇca´st bylo tˇreba zvolit, která ˇcást bude m´ıt ˇr´ıd´ıc´ı funkci, pomoc´ı n´ıˇz bude uˇzivatel konfigurovat parametry testu 20



a sb´ırat v´ ysledky. Zároveˇ n mi nepˇriˇslo vhodné, aby uˇzivatel musel provádˇet konfiguraci plánovaného testu na obou stranách s´ıt’ové topologie. Pro lepˇs´ı simulaci reálného prostˇred´ı a vˇernˇejˇs´ıch charakteristik datov´ ych tok˚ u jsem musel zajistit, aby vˇsechny druhy test˚ u bˇeˇzely souˇcasnˇe. Kaˇzd´ y test ve svém vláknˇe. Za u ´ˇcelem udrˇzen´ı homogenity testu bˇehem jednotliv´ ych iterac´ı jsem pak musel implementovat vláknovou synchronizaci. Zvolen´ ym synchronizaˇcn´ım prvkem je bariéra, která slouˇz´ı k tomu, ˇze kaˇzdé vlákno po skonˇcen´ı iterace ˇceká, aˇz budou hotovy vˇsechny testy. Po dosaˇzen´ı bariéry vˇsemi vlákny jsou testy puˇstˇeny do dalˇs´ıho cyklu.

Obrázek 3.1: Znázornˇen´ı komunikace klientsk´ ych vláken (modˇre) se serverovou ˇca´st´ı aplikace (ˇcervenˇe) Konfiguraˇcn´ımu rozhran´ı jsem chtˇel dát uˇzivatelsky pˇr´ıjemnou podobu, a proto je aplikace plnˇe ovladatelná z grafického prostˇred´ı bez nutnosti dohledávat v dokumentaci potˇrebné parametry ˇci pˇrep´ınaˇce. Moˇznou nev´ yhodou ovládán´ı skrze grafické rozhran´ı vˇsak m˚ uˇze b´ yt v nˇekter´ ych konfiguraˇcn´ıch poloˇzkách nedostateˇcn´ y rozsah hodnot pro nároˇcnˇejˇs´ı testovac´ı scénáˇre. Popis metodik jednotliv´ ych test˚ u Pro popis funkcionality a moˇznost´ı aplikace oznaˇcuji jako klientskou stranu 21



aplikace tu instanci spuˇstˇeného programu, ve které bylo pˇred spuˇstˇen´ım zvolen reˇzim klient“. Tato aplikace poskytuje konfiguraˇcn´ı a v´ ystupn´ı rozhran´ı ” provádˇen´ ych test˚ u a sestavuje konfiguraˇcn´ı zprávu, která obsahuje poˇzadavky na spuˇstˇen´ı konkrétn´ıch sluˇzeb s nakonfigurovan´ ymi parametry a je odes´ılána serverové stranˇe. Analogicky plat´ı totéˇz pro serverovou stranu aplikace a volbu server“. Toto oznaˇcen´ı má za u ´ˇcel zjednoduˇsit orientaci v popisu ” testovac´ıch scénáˇr˚ u. FTP test Tento typ testu vyuˇz´ıvá protokol FTP, s jehoˇz pomoc´ı m˚ uˇzeme zjistit skuteˇcnou pˇrenosovou kapacitu s´ıt’ového spojen´ı. Serverová strana aplikace spouˇst´ı za pomoci extern´ı knihovny FTP server jako sluˇzbu na klientovi pˇredem známém portu. Pokud se serverové stranˇe aplikace nepodaˇr´ı sluˇzbu rozbˇehnout nebo se napˇr´ıklad nezdaˇr´ı otevˇr´ıt pˇredem domluven´ y TCP port, je o této skuteˇcnosti klientovi odeslána zpráva a uˇzivatel je o této skuteˇcnosti upozornˇen v´ ypisem v konzoli v serverové i klientské stranˇe aplikace. V pˇr´ıpadˇe, kdy se serveru podaˇr´ı sluˇzbu u ´spˇeˇsnˇe spustit, je následnˇe nakonfigurován testovac´ı u ´ˇcet sluˇzby, jehoˇz pˇrihlaˇsovac´ı u ´daje jsou vˇsem klient˚ um pˇredem známy. Klientská ˇca´st aplikace se za pomoci extern´ı knihovny pˇripoj´ı na spuˇstˇen´ y FTP server a do koˇrenového adresáˇre zaháj´ı pˇrenos vzorového souboru. Vzorov´ y soubor (sample file) je soubor vybran´ y v konfiguraˇcn´ı záloˇzce test˚ u v konfiguraˇcn´ı moˇznosti Sample file path. Po u ´spˇeˇsném odeslán´ı souboru spoˇc´ıtá aplikace pr˚ umˇernou pˇrenosovou rychlost dat v kbps a tu uloˇz´ı mezi z´ıskané v´ ysledky do databázového souboru a bezprostˇrednˇe zahajuje stahovac´ı fázi testu. Bˇehem této fáze klient stahuje p˚ uvodnˇe odeslan´ y vzorov´ y soubor. Doba, jenˇz uplyne bˇehem datového pˇrenosu je opˇet pouˇzita pro v´ ypoˇcet pr˚ umˇerné rychlosti a v´ ysledek je uloˇzen do tabulky s v´ ysledky. V pˇr´ıpadˇe, kdy FTP server souˇcasnˇe obsluhuje nˇekolik klientsk´ ych testovac´ıch aplikac´ı, je ˇzádouc´ı, aby kaˇzd´ y klient pouˇzil jin´ y název pˇrenáˇseného souboru a to z toho d˚ uvodu, aby klienti bˇehem testu nemohli navzájem pˇrepisovat tent´ yˇz soubor. Staˇzené a nahrané soubory nejsou bˇehem mˇeˇren´ı ani po jeho skonˇcen´ı odstranˇeny ze souborového systému. Lze tak pozdˇeji napˇr´ıklad ovˇeˇrit, ˇze se soubor podaˇrilo pˇrenést bez chyby. Aplikace komunikuje protokolem FTP v pasivn´ım reˇzimu. HTTP test Tento test zahrnuje simulaci skuteˇcného datového pˇrenosu pomoc´ı http protokolu a souˇcasnˇe mˇeˇr´ı uplynul´ y ˇcas bˇehem pˇrenosu vˇsech poˇzadovan´ ych datov´ ych vzork˚ u. Webová sluˇzba je spuˇstˇena na základˇe poˇzadavku v pˇrijaté

22



konfiguraˇcn´ı zprávˇe na domluveném portu a ukonˇcuje se pˇri zavˇren´ı aplikace. V pˇr´ıpadˇe testovac´ıho scénáˇre s v´ıce klienty je spuˇstˇena pouze jedna instance webového serveru, která obsluhuje poˇzadavky vˇsech http klient˚ u. Mˇeˇren´ı, zpracován´ı a ukládán´ı v´ ysledk˚ u obstarává klientská strana. Pro tento typ testu je nutné, aby mˇela serverová ˇcást aplikace pˇr´ıstup k pˇripraven´ ym, s aplikac´ı dodávan´ ym, datov´ ym vzork˚ um - Obrázek 3.2. Jedná se o kopie nˇekolika tituln´ıch stránek vybran´ ych web˚ u vˇcetnˇe obrázk˚ u, skript˚ u a css soubor˚ u potˇrebn´ ych pro offline zobrazen´ı kompletn´ı stránky ve webovém prohl´ıˇzeˇci. Tato data jsou poskytována webov´ ym serverem na serverové stranˇe aplikace bˇehem provádˇeného http testu.

Obrázek 3.2: Ukázka souborové struktury webové sluˇzby aplikace Uˇzivatel má pˇri konfiguraci http testu moˇznost upravovat jeho rozsah v´ ybˇerem pˇr´ısluˇsné sady vzork˚ u z konfiguraˇcn´ı nab´ıdky na klientské stranˇe aplikace. UDP test Reprezentantem UDP provozu je proud datagram˚ u. Ty jsou generovány na serverové stranˇe ve zvolené velikosti a s uˇzivatelem zadanou frekvenc´ı. Stejnˇe tak lze nastavit délku trván´ı UDP proudu. Klientská strana naslouchá na domluveném portu, zpracovává pˇr´ıchoz´ı datagramy, poˇc´ıtá a následnˇe ukládá absolutn´ı poˇcet a po pˇrepoˇctu i procento paket˚ u, jeˇz nedorazilo na ˇ klient˚ uv s´ıt’ov´ y interface v ohraniˇceném ˇcase. Casov´ y limit pro tento test se poˇc´ıtá z hodnoty zadané v konfiguraˇcn´ım rozhran´ı a pˇripoˇcte se +500ms. 23



To je doba, kdy server jiˇz nevys´ılá, ale klient jeˇstˇe pˇrij´ımá a zpracovává pˇr´ıchoz´ı pakety zpoˇzdˇené pˇrenosem po s´ıti. UDP stream má pˇredstavovat multimediáln´ı audio/video sluˇzby, u nichˇz je kladen d˚ uraz na rychlé doruˇcen´ı s pokud moˇzno co nejmenˇs´ı ˇcasovou prodlevou TELNET test Pro potˇreby mˇeˇren´ı latence linky a simulaci interaktivity zadáván´ı pˇr´ıkaz˚ u na vzdálen´ y terminál jsem navrhl test, ve kterém klientská stanice inicializuje na zaˇcátku kaˇzdé iterace TCP spojen´ı na serverem vystaven´ y port. Pro kaˇzdého pˇripojeného klienta je na serveru vytvoˇreno nové vlákno, aby nedocházelo k ˇcasov´ ym prodlevám pˇri vyˇrizován´ı odpovˇed´ı na pˇrijaté poˇzadavky. Poˇzadavky generuje s uˇzivatelem zadanou frekvenc´ı klientská strana a server po jejich pˇrijet´ı okamˇzitˇe odpov´ıdá zprávou s jasnˇe dan´ ym formátem. Charakteristika tohoto s´ıt’ového spojen´ı se podobá aplikaˇcn´ımu telnet protokolu, odkud pocház´ı název testu. Pˇri tomto testu se mˇeˇr´ı ˇcasy, které uplynou mezi odeslán´ım poˇzadavku a pˇrijet´ım pˇr´ısluˇsné odpovˇedi. Hodnoty jsou pak ukládány do 2 tabulek. Do jedné se ukládaj´ı latence vˇsech poˇzadavk˚ u. Do druhé pak jiˇz jen pr˚ umˇerná hodnota zpoˇzdˇen´ı, vypoˇctená ze vˇsech zpráv iterace. Na obrázku 3.3 je zobrazena ˇcást zachycené komunikace mezi klientem a serverem. Hodnoty ve sloupci Time jsou ˇcasy mezi zachycen´ım jednotliv´ ych paket˚ u na s´ıt’ovém rozhran´ı stroje s aktivn´ı klientskou ˇca´st´ı aplikace.

Obrázek 3.3: Ukázka zachycené komunikace mezi klientskou a serverovou ˇcást´ı aplikace v pr˚ ubˇehu TELNET testu Pˇred zaˇca´tkem mˇeˇren´ı odes´ılá klient serveru konfiguraˇcn´ı zprávu. Ten t´ım tak dostane informaci o tom, které testy jsou poˇzadovány a jaké sluˇzby je tˇreba na serveru pro klienta pˇr´ıpadnˇe potˇreba nakonfigurovat a spustit. Ukl´ ad´ an´ı a zpracov´ an´ı dat Aplikace pr˚ ubˇeˇznˇe bˇehem testu zapisuje z´ıskané hodnoty z provádˇen´ ych 24


Návrh testovac´ıch scénáˇr˚ u pro aplikaci

test˚ u do tabulek databázového souboru formátu sqlite s názvem test.db“ za ” pomoci JDBC1 spojen´ı. Tento soubor se primárnˇe vytváˇr´ı pˇri prvn´ım spuˇstˇen´ı testu s libovolnou konfigurac´ı. Pokud jiˇz v adresáˇri soubor s takov´ ym názvem existuje, tak se tento pouˇzije s t´ım, ˇze pˇred samotn´ ym vkládán´ım nov´ ych/namˇeˇren´ ych hodnot jsou nad pˇr´ısluˇsnou tabulkou volány DDL2 pˇr´ıkazy DROP & CREATE. Reprodukce mˇ eˇ ren´ı s identickou konfigurac´ı Pˇri v´ yvoji aplikace byla snaha parametrizovat délku a rozsah testu na základˇe vstupn´ıch dat zvolen´ ych uˇzivatelem. Proto lze s velmi velkou m´ırou pˇresnosti vytvoˇrit s pouˇzit´ım stejného HW vybaven´ı nezávisle konfigurované testy tak, ˇze je m˚ uˇzeme pozdˇeji za pˇredpokladu pouˇzit´ı stejn´ ych testovac´ıch zaˇr´ızen´ı (tj. tˇech, které se z´ uˇcastn´ı testu v roli klient nebo server, ale nejsou pˇredmˇetem testován´ı) a shodn´ ych vstupn´ıch parametrech, povaˇzovat za totoˇzné. Dosaˇzené v´ ysledky tˇechto test˚ u poté má smysl mezi sebou vzájemnˇe porovnávat.

3.3

N´ avrh testovac´ıch sc´ en´ aˇ r˚ u pro aplikaci

Z d˚ uvodu zachován´ı pˇrehlednosti v navrhnut´ ych testovac´ıch scénáˇr´ıch a v´ ysledc´ıch budeme pouˇz´ıvat pro oznaˇcen´ı testovan´ ych s´ıt’ov´ ych zaˇr´ızen´ı následuj´ıc´ı zkratky: • Asus = ASUS WL500G • Cisco = Cisco 2801 • Cisco 3560 = Cisco 3560 • Edimax = EdimaxBR6204WG • Linksys = Linksys WRT150N • Routerboard = RouterBoard RB532 1 2

Java Database Connectivity Data Definition Language

25



Následuj´ıc´ı testovac´ı scénáˇre byly realizovány v s´ıt’ové laboratoˇri UI505 na Západoˇceské univerzitˇe. Testovac´ı aplikace byla spuˇstˇena na tamn´ıch laboratorn´ıch desktopov´ ych poˇc´ıtaˇc´ıch.

26



Sc´ en´ aˇ r 1) Testovaná zaˇr´ızen´ı:

2x GigabitEthernet NIC (Klient & Server)


Spojen´ı stanic kˇr´ıˇzen´ ym UTP kabelem


Rychlost stahován´ı a odes´ılán´ı pˇres FTP protokol


Obrázek 3.4

Poznámka:

Zakonˇcen´ı s´ıt’ového kabelu pro GigabitEthernet demonstruje obrázek 3.5

Obrázek 3.4:

Obrázek 3.5: Schéma zapojen´ı kˇr´ıˇzeného kabelu pro GigabitEthernet zdroj: http://www.svetsiti.cz Sc´ en´ aˇ r 2)

Obrázek 3.6:

27



Testovaná zaˇr´ızen´ı:

Asus, Cisco, Edimax, Linksys, RouterBoard


NAT


Rychlost stahován´ı a odes´ılán´ı pˇres FTP protokol.


Obrázek 3.6

Poznámka: Sc´ en´ aˇ r 3) Testovaná zaˇr´ızen´ı:



NAT


ˇ potˇrebn´ Cas y k pˇrenosu vˇsech prvk˚ u www stránek


Obrázek 3.7

Poznámka:

Obrázek 3.7: Sc´ en´ aˇ r 4) Testovaná zaˇr´ızen´ı:


Reˇzimy zaˇr´ızen´ı:

NAT, BRIDGE,ROUTING


Vliv reˇzimu na datov´ y tok protokolu FTP


Obrázek 3.8

Poznámka:

28



Obrázek 3.8: Sc´ en´ aˇ r 5) Testovaná zaˇr´ızen´ı:

Asus, Cisco, Edimax, RouterBoard


NAT


FTP, HTTP, TELNET, STREAM


Obrázek 3.9

Poznámka:

Budeme pozorovat, jak budou jednotlivá zaˇr´ızen´ı reagovat na velikou zátˇeˇz tvoˇrenou smˇes´ı datov´ ych tok˚ u s r˚ uznou charakteristikou

Obrázek 3.9: Sc´ en´ aˇ r 6)

Obrázek 3.10:

29


Realizace test˚ u na vybraných zaˇr´ızen´ıch

Testovaná zaˇr´ızen´ı:

Asus, Edimax, Cisco 3560


defaultn´ı nastaven´ı


pˇrenosové rychlosti protokolu FTP


Obrázek 3.10

Poznámka:

3.4

Realizace test˚ u na vybran´ ych zaˇ r´ızen´ıch

Nyn´ı se podrobnˇeji pod´ıváme na namˇeˇrené hodnoty a provedeme jejich srovnán´ı. Sc´ en´ aˇ r 1) Toto mˇeˇren´ı slouˇz´ı k ovˇeˇren´ı, ˇze klientská a serverová stanice jsou pro testován´ı v´ ykonovˇe dostateˇcné. Spojen´ı stanic je realizováno UTP kˇr´ıˇzen´ ym kabelem - viz obr. 3.5. Komunikace protokolu FTP tak neprocház´ı ˇzádn´ ym s´ıt’ov´ ym prvkem.

Obrázek 3.11: Graf FTP testu - rychlost stahován´ı a odes´ılán´ı dat

30



Sc´ en´ aˇ r 2) V tomto testu prob´ıhala komunikace pomoc´ı FTP protokolu skrze zaˇr´ızen´ı, jeˇz pracovalo v reˇzimu NAT. Pouˇzit´ı toho reˇzimu je typické na hraniˇcn´ıch prvc´ıch v domácnostech a to jednak z d˚ uvodu bezpeˇcnostn´ıch (jedná se o pˇrirozen´ y firewall brán´ıc´ı ciz´ım zaˇr´ızen´ım proniknout na s´ıt’ové prvky v lokáln´ı s´ıti), ale pˇredevˇs´ım z d˚ uvodu nedostatku voln´ ych veˇrejn´ ych IPv4 adres [Huston(2013)]. V pr˚ ubˇehu mˇeˇren´ı vykazovala vˇsechna zaˇr´ızen´ı stabiln´ı rychlosti ve smˇeru od serveru ke klientovi. V opaˇcném smˇeru byly v´ ysledky rozkol´ısanˇejˇs´ı. Namˇeˇrené hodnoty udávaj´ı skuteˇcnou pr˚ umˇernou pˇrenosovou rychlost FTP protokolu. Skuteˇcn´ y datov´ y tok, kter´ y bychom namˇeˇrili na spojovac´ım médiu tak bude po pˇripoˇcten´ı hlaviˇcek vˇsech hlaviˇcek pouˇzit´ ych protokol˚ u niˇzˇs´ıch vrstev samozˇrejmˇe vyˇsˇs´ı. V testu dominoval Cisco smˇerovaˇc s rychlostmi pˇresahuj´ıc´ımi 90Mbps v obou smˇerech. Nejh˚ uˇre si vedl RouterBoard s 35-45 Mbps. Ostatn´ı zaˇr´ızen´ı se rychlostnˇe pohybovala nad zm´ınˇen´ ym RouterBoardem, v rozmez´ı 45-70Mbps. Cisco smˇerovaˇci se v tomto testu ˇza´dné zaˇr´ızen´ı v´ ykonovˇe nepˇribl´ıˇzilo. Namˇeˇrené hodnoty jsou zaneseny do graf˚ u na obrázc´ıch 3.12 a 3.13.

Obrázek 3.12: Graf FTP testu - rychlost stahován´ı dat

31



Obrázek 3.13: Graf FTP testu - rychlost odes´ılán´ı dat Sc´ en´ aˇ r 3) Po FTP testu jsem provedl s totoˇzn´ ymi smˇerovaˇci test, ve kterém klient se serverem komunikoval protokolem http a s´ıt´ı se pˇrenáˇsely soubory tvoˇr´ıc´ı dohromady repliku skuteˇcn´ ych webov´ ych stránek, jak byly zveˇrejnˇeny viz obr.3.2. Vˇsechna zaˇr´ızen´ı opˇet pracovala v reˇzimu NAT. Bˇehem testu se mˇeˇrila doba, za jakou klient dostane od serveru vˇsechny prvky webov´ ych stránek. Pro test byla zvolena kompletn´ı sada pˇripraven´ ych stránek. Celková velikost soubor˚ u vˇsech 8 stránek ˇc´ıtá pˇribliˇznˇe 8MB. I pˇres relativnˇe mal´ y objem pˇrenáˇsen´ ych dat ukázaly v´ ysledky mˇeˇren´ı velké rozd´ıly v celkov´ ych ˇcasech. Nejlepˇs´ıch hodnot dosáhl Cisco smˇerovaˇc. U nˇej se ˇcas iterace pohyboval mezi 4-5 sekundami. U smˇerovaˇce znaˇcky Edimax se pˇri 3. iteraci objevil problém s navazován´ım TCP spojen´ı. Klient se dostal do stavu, kdy odes´ılal TCP SYN pakety, na které nepˇricházela odpovˇed’. Tento stav trval des´ıtky sekund, neˇz pˇriˇsel prvn´ı SYN ACK paket od serveru a pokraˇcovalo se v testu. Pr˚ ubˇeh tohoto testu s Edimax zaˇr´ızen´ım jsem sledoval v konzoli klientské aplikace a ve chv´ıli, kdy jsem zpozoroval delˇs´ı neˇcinnost, jsem za pomoci systémového pˇr´ıkazu netstat zjistil, ˇze poˇcet navázan´ ych TCP spojen´ı stanice je 164. To v˚ ubec nen´ı vysoké ˇc´ıslo, a proto mˇe toto zjiˇstˇen´ı pˇrekvapilo. Identické chován´ı smˇerovaˇce se opakovalo kaˇzdou 3. iteraci a v tomto testu tak mezi ostatn´ımi smˇerovaˇci naprosto propadlo. Podobné problémové chován´ı pˇri navazován´ı TCP relac´ı jako mˇel smˇe32



rovaˇc Edimax vykazoval i Asus, ale s frekvenc´ı kaˇzdou 10. iteraci a doba vzpamatován´ı u nˇej byla cca o polovinu kratˇs´ı viz obr.3.14. S´ıt’ové prvky RouterBoard a Linksys stabilnˇe dosahovaly ˇcasu iterace 6-7 respektive 7-10 sekund. Pro srovnán´ı jsem do grafu pˇridal i test proveden´ y na gigabitovém spojen´ı 2 stanic laboratoˇre.

Obrázek 3.14: Graf HTTP testu - doba pˇrenosu soubor˚ u

Obrázek 3.15: Ukázka zachycené komunikace - chybˇej´ıc´ı TCP SYN pakety Sc´ en´ aˇ r 4)

33



Obrázek 3.16: Srovnán´ı pˇrenosov´ ych rychlost´ı smˇerem ke klientovi v závislosti na operaˇcn´ım reˇzimu zaˇr´ızen´ı MikroTik RouterBoard RB532

Obrázek 3.17: Srovnán´ı pˇrenosov´ ych rychlost´ı smˇerem od klienta v závislosti na operaˇcn´ım reˇzimu zaˇr´ızen´ı MikroTik RouterBoard RB532

34



T´ımto testovac´ım scénáˇrem jsem zjiˇst’oval a porovnával v´ ykonovou nároˇcnost jednotliv´ ych operaˇcn´ıch reˇzim˚ u mezi 2 s´ıt’ov´ ymi porty typu FastEthernet na zaˇr´ızen´ı RouterBoard RB532. Podle oˇcekáván´ı jsem dosáhl nejlepˇs´ıch v´ ysledk˚ u v reˇzimu bridge. S´ıt’ov´ y provoz v ten moment nen´ı zat´ıˇzen smˇerovac´ım rozhodován´ım a dalˇs´ımi operacemi typick´ ymi pro 3. a vyˇsˇs´ı vrstvu ISO/OSI modelu [MikroTik(2013)]. Nejvˇetˇs´ı u ´bytek pˇrenosové rychlosti byl pozorovateln´ y pˇri smˇerován´ı s pˇrekladem adres – NAT.

35



Sc´ en´ aˇ r 5) Testovac´ı scénáˇr, ve kterém jsou bˇehem iterace v jeden okamˇzik paralelnˇe spuˇstˇeny vˇsechny testy, má vystavit testované zaˇr´ızen´ı maximáln´ımu zat´ıˇzen´ı. M˚ uˇzeme pak sledovat charakteristiky datov´ ych tok˚ u pouˇzit´ ych s´ıt’ov´ ych protokol˚ u. V´ ysledkem proveden´ ych test˚ u je následuj´ıc´ı rozbor: Cisco 2801 – rychlost pˇrenosu dat FTP protokolem byla sn´ıˇzena ve smˇeru od serveru ke klientovi kv˚ uli souˇcasnému sd´ılen´ı kapacity spoje s proudem UDP datagram˚ u, jehoˇz objem ˇcinil cca 4Mbps. I pˇresto se pˇrenosové rychlosti obou tˇechto test˚ u v souˇctu pˇribliˇzovaly maxima FastEthernet spojen´ı. Na testu http protokolu se zátˇeˇz projevila prodlouˇzen´ım iterace v pr˚ umˇeru o 71,3% viz tab. A.6 oproti samostatnˇe bˇeˇz´ıc´ımu http testu. Stále se vˇsak jedná o v´ yraznˇe nejlepˇs´ı hodnoty mezi ostatn´ımi zaˇr´ızen´ımi. Po celou dobu mˇeˇren´ı se latence simulovaného telnet spojen´ı pohybovala na u ´rovni jednotek ms. Edimax BR6204WG – Toto zaˇr´ızen´ı vykázalo druh´ y nejlepˇs´ı v´ ysledek v rychlosti odes´ılán´ı dat protokolem FTP. V opaˇcném smˇeru toku dat ale doˇslo v 18.iteraci k pˇreruˇsen´ı navázané relace a stahován´ı bylo zruˇseno. U http testu se opˇet se projevily problémy s navazován´ım TCP relac´ı jako v pˇr´ıpadˇe samostatného testu viz obr.3.15. Bˇehem mˇeˇren´ı se zaˇr´ızen´ı pot´ ykalo s kol´ısav´ ymi odezvami telnet spojen´ı v rozmez´ı 1-12ms a s drobn´ ymi ztrátami paket˚ u UDP proudu v ˇra´du jednotek procent. ASUS WL-500G – Smˇerovaˇc si vedl velmi dobˇre v rychlosti stahován´ı pˇri FTP testu s namˇeˇren´ ymi hodnotami mezi 40 a 50Mbps viz obr. 3.18. Naopak v odes´ılán´ı testovac´ıho vzorku za ostatn´ım zaˇr´ızen´ımi zaostával s ˇ rychlostmi nepˇresahuj´ıc´ımi 20Mbps viz obr 3.19. Casov´ yu ´sek potˇrebn´ y pro pˇrenos vˇsech dat pomoc´ı http protokolu byl v pˇr´ıpadˇe tohoto plného zat´ıˇzen´ı o 139% delˇs´ı. Latence se pohybovala v ˇra´dech stovek milisekund a poˇcet ztracen´ ych datagramov´ ych jednotek protokolu UDP se kol´ısavˇe vyˇsplhal aˇz pˇres 10% viz obr. 3.22 RouterBoard RB532 – RouterBoard stabilnˇe dosahoval pˇri FTP testu pˇrenosov´ ych rychlost´ı okolo 30Mbps. V http testu trvala iterace konstantnˇe pˇribliˇznˇe 13 sekund, coˇz znamená nár˚ ust proti nezat´ıˇzenému testu o 112%. Stále je to vˇsak druh´ y nejlepˇs´ı v´ ysledek. Odezvy telnet relace byly bˇehem testu s nˇekolika málo v´ yjimkami 5-6ms a ztrátovost paket˚ u se pohybovala v ˇra´du jednotek.

36



Obrázek 3.18: Graf FTP testu pˇri souˇcasném bˇehu vˇsech test˚ u - rychlost stahován´ı dat

Obrázek 3.19: Graf FTP testu pˇri souˇcasném bˇehu vˇsech test˚ u - rychlost odes´ılán´ı dat

37



Obrázek 3.20: Graf HTTP testu pˇri souˇcasném bˇehu vˇsech test˚ u - doba pˇrenosu soubor˚ u

Obrázek 3.21: Graf TELNET testu pˇri souˇcasném bˇehu vˇsech test˚ u - pr˚ umˇerná odezva TCP spojen´ı

38



Obrázek 3.22: Graf UDP stream testu pˇri souˇcasném bˇehu vˇsech test˚ u - poˇcet nepˇrijat´ ych paket˚ u Sc´ en´ aˇ r 6) V´ ysledky tohoto scénáˇre na obrázc´ıch 3.23 a 3.24 demonstruj´ı, ˇze parametry datového pˇrenosu v rámci LAN rozhran´ı smˇerovaˇc˚ u jsou srovnatelné s v´ ysledky pˇri pouˇzit´ı pˇrep´ınaˇce. Tabulky s namˇeˇren´ ymi hodnotami jsou pˇriloˇzeny v pˇr´ıloze.

39



Obrázek 3.23: Graf FTP testu - rychlost stahován´ı dat

Obrázek 3.24: Graf FTP testu - rychlost odes´ılán´ı dat

40


3.5

Porovnán´ı aplikace s vybranými existuj´ıc´ımi nástroji

Porovn´ an´ı aplikace s vybran´ ymi existuj´ıc´ımi n´ astroji

Iperf Nejprve bych se chtˇel vˇenovat srovnán´ı testovac´ı aplikace s testovac´ım nástrojem iperf. FTP test realizované mˇeˇr´ıc´ı aplikace má plnit funkci detekce maximáln´ıho datového toku. Jin´ ymi slovy v´ ystupem je informace o uˇziteˇcném zat´ıˇzen´ı TCP protokolu (tzv. payload) bˇehem pˇrenosu. Iperf umoˇzn ˇuje nastavit velikost TCP window size, podporuje v´ıcevláknovou komunikaci mezi klientem a serverem a je na rozd´ıl od mˇeˇr´ıc´ı aplikace schopen pˇrenáˇset data v multicast s´ıt’ovém reˇzimu. I pˇres ˇsirˇs´ı paletu moˇznost´ı jeˇz lze v nástroji iperf nakonfigurovat, se domn´ıvám, ˇze je pro srovnán´ı v´ ykonnosti 2 zaˇr´ızen´ı v´ yhodnˇejˇs´ı vycházet z mˇeˇren´ı parametr˚ u protokolu, kter´ y bude v praxi pouˇz´ıván a jehoˇz pˇr´ıpadné chyby v pˇrenosu maj´ı pˇr´ım´ y vliv na uˇzivatelské pohodl´ı. Jako d˚ ukaz mohou poslouˇzit rozd´ılné v´ ysledky z testovac´ıho scénáˇre viz. 3.16 a 3.17 proti hodnotám v tabulce 2.1. Pro kompletn´ı anal´ yzu a sledován´ı charakteristik datov´ ych tok˚ u bych tak doporuˇcil zkombinovat v´ yhody obou zmiˇ novan´ ych nástroj˚ u. ´ cel pouˇzit´ı tohoto nástroje je test v´ JMeter Uˇ ykonnosti bˇeˇz´ıc´ı sluˇzby na serveru. JMeter nepodporuje spouˇstˇen´ı instanc´ı testovan´ ych sluˇzeb, jako se dˇeje u realizované mˇeˇr´ıc´ı aplikace (FTP server, web server, UDP stream). Dalˇs´ım v´ yznamn´ ym rozd´ılem je, ˇze jde pouze o klienta, kter´ y nab´ız´ı podstatnˇe v´ıce moˇznost´ı testován´ı vˇcetnˇe podpory v´ıce paraleln´ıch vláken. Pouˇz´ıt vˇsak tento nástroj za u ´ˇcelem mˇeˇren´ı v´ ykonnosti s´ıt’ového zaˇr´ızen´ı lze pouze za pˇredpokladu, kdy máme jistotu, ˇze je testované zaˇr´ızen´ı nejslabˇs´ım ˇclánkem v ˇretˇezci zaˇr´ızen´ı(jejich s´ıt’ov´ ych rozhran´ı) a voln´ ych kapacit pˇrenosov´ ych linek mezi klientem a serverem.

41

4 Závˇer 4.1

Posouzen´ı vhodn´ eho nasazen´ı s´ıt’ov´ ych prvk˚ u

Na základˇe v´ ysledk˚ u realizovan´ ych mˇeˇren´ı vytvoˇrenou testovac´ı aplikac´ı m˚ uˇzeme diskutovat nad vhodn´ ym nasazen´ım zaˇr´ızen´ı do provozn´ıho prostˇred´ı. Z v´ ysledk˚ u vypl´ yvá, ˇze smˇerovaˇc Cisco 2801 je v´ ykonovˇe dostateˇcn´ y ve vˇsech testovan´ ych smˇerech. Nebál bych se tak jeho nasazen´ı do role hraniˇcn´ıho prvku pro vˇetˇs´ı s´ıt’ovou infrastrukturu ˇc´ıtaj´ıc´ı klidnˇe i des´ıtky s´ıt’ov´ ych prvk˚ u a uˇzivatel˚ u. Domn´ıvám se tak na základˇe v´ ysledk˚ u provedeného zátˇeˇzového testu, pˇri kterém se v´ yraznˇe nezhorˇsil ˇzádn´ y ze sledovan´ ych parametr˚ u datov´ ych tok˚ u. Smˇerovaˇc ASUS WL500G bych nedoporuˇcil pˇripojovat u ISP(zkratka), jenˇz nab´ız´ı pˇripojen´ı do internetu o rychlosti v ˇra´du des´ıtek Mbps. Pokud bychom tak totiˇz uˇcinili a smˇerovaˇc zat´ıˇzili pˇrenosy aplikaˇcn´ıch protokol˚ u, byli bychom nepˇr´ıjemnˇe pˇrekvapeni zhorˇsen´ım odezvy do internetu, delˇs´ı dobou naˇc´ıtán´ı webov´ ych stránek pˇri bˇeˇzném prohl´ıˇzen´ı a moˇzn´ ymi v´ ypadky hlasov´ ych a video sluˇzeb. U zaˇr´ızen´ı Edimax BR6204WG jsem objevil pomˇernˇe závaˇzn´ y problém s n´ızk´ ym limitem navázan´ ych TCP spojen´ı. Nedoporuˇcoval bych proto, aby tento s´ıt’ov´ y prvek fungoval jako v´ ychoz´ı brána do internetu pro v´ıce souˇcasnˇe pracuj´ıc´ıch uˇzivatel˚ u. V takovém pˇr´ıpadˇe m˚ uˇze popsan´ y jev vˇsechny potrápit. S´ıt’ov´ y prvek RouterBoard RB532 patˇr´ı mezi starˇs´ı a v souˇcasnosti jiˇz nepodporované modely v´ yrobce Mikrotik. Jeho nasazen´ı do domác´ıho provozu vˇsak nic nebrán´ı. V testech zaˇr´ızen´ı nedosahovalo nejlepˇs´ıch hodnot, zato ale stabiln´ıch a bez v´ ykyv˚ u. S menˇs´ı pravdˇepodobnost´ı tak m˚ uˇze nastat situace, kdy jeden uˇzivatel zat´ıˇz´ı nároˇcn´ ymi datov´ ymi pˇrenosy tento prvek do takové m´ıry, aby v´ yznamnˇe ovlivnil ostatn´ı pˇripojené uˇzivatele v lokáln´ı s´ıti.

42

Závˇer

4.2

Zhodnocen´ı z´ıskaných informac´ı a pˇr´ınos˚ u aplikace

Zhodnocen´ı z´ıskan´ ych informac´ı a pˇ r´ınos˚ u aplikace

Bˇehem práce na tomto projektu jsem se seznámil s testovac´ımi nástroji pouˇz´ıvan´ ymi pro mˇeˇren´ı parametr˚ u poˇc´ıtaˇcov´ ych s´ıt´ı. Vyzkouˇsel jsem si navrhnout a provést nˇekolik testovac´ıch scénáˇr˚ u s nˇekolika vybran´ ymi nástroji a na základˇe v´ ysledk˚ u proveden´ ych mˇeˇren´ı navrhnout vlastn´ı mˇeˇr´ıc´ı aplikaci. Abych mohl navrˇzenou aplikaci realizovat, musel jsem se seznámit s frameworkem SWING a nauˇcit se pracovat s vlákny v prostˇred´ı JAVA. Vytvoˇrená aplikace nab´ız´ı kompaktn´ı nástroj pro simulaci datov´ ych tok˚ u vybran´ ych protokol˚ u a disponuje jednoduch´ ym ovládán´ım. M˚ uˇze tak snadno slouˇzit ˇsirˇs´ımu publiku v pomoci pˇri základn´ı diagnostice s´ıt’ov´ ych zaˇr´ızen´ı. Aplikaci proto z tohoto hlediska hodnot´ım jako pˇr´ınosnou a vyuˇzitelnou. Popis ovládán´ı se nacház´ı v pˇr´ıloze a dokumentace pak na pˇriloˇzeném CD.

43

Seznam zkratek a slovn´ıch v´ yraz˚ u TCP UDP Latence RTT ICMP Qos NAT P2P

Transmission Control Protocol, protokol 4.vrstvy ISO/OSI modelu User Datagram Protocol, protokol 4.vrstvy ISO/OSI modelu Zpoˇzdˇen´ı ke kterému dojde pˇri pˇrenosu dat s´ıt´ı Round Trip Time, ˇcas mezi odeslán´ım signálu a pˇrijet´ım potvrzen´ı Internet Control Message Protocol Quality of Service Network Address Translation Peer to peer, typ s´ıt’ové architektury

44

Literatura [Allman et al.(2009)Allman, Paxson Blanton] ALLMAN, M. – PAXSON, ” V. – BLANTON, E. TCP Congestion Control. RFC 5681 (Draft Standard), September 2009. Dostupné z: http://www.ietf.org/rfc/ rfc5681.txt. [Demichelis – Chimento(2002)Demichelis, Chimento] DEMICHELIS, C. – CHIMENTO, P. IP Packet Delay Variation Metric for IP Performance Metrics (IPPM). RFC 3393 (Proposed Standard), November 2002. Dostupné z: http://www.ietf.org/rfc/rfc3393.txt. [Higgins(2010a)] HIGGINS, T. How We Test Hardware Routers - Revision 3. http://www.smallnetbuilder.com/lanwan/lanwan-howto/ 31103-how-we-test-hardware-routers-revision-3, 2010a. [Online; navˇst´ıveno 8-12-2012]. [Higgins(2010b)] HIGGINS, T. Instructions for the Matrix21 Router Session Test Tool. http://jdsworld.com/wp-content/uploads/2010/ 09/router_session_test_tool_instructions.pdf, 2010b. [Online; navˇst´ıveno 8-12-2012]. [Huston(2013)] HUSTON, G. IPv4 Address Report. http://www.potaroo. net/tools/ipv4/, 2013. [Online; navˇst´ıveno 14-3-2013]. [Ixia(2012)] IXIA. IxChariot Specifications. http://www.ixchariot.com/ products/datasheets/ixchariot.html, 2012. [Online; navˇst´ıveno 1212-2012]. [Jacobson et al.(1992)Jacobson, Braden Borman] JACOBSON, V. – BRA” DEN, R. – BORMAN, D. TCP Extensions for High Performance. RFC 1323 (Proposed Standard), May 1992. Dostupné z: http://www.ietf. org/rfc/rfc1323.txt.

45

LITERATURA

LITERATURA

[Jonkman(2012)] JONKMAN, R. NetSpec. http://www.ittc.ku.edu/ netspec/, 2012. [Online; navˇst´ıveno 25-10-2012]. [MikroTik(2013)] MIKROTIK. Packet Flow Chart. http://wiki. mikrotik.com/wiki/Manual:Packet_Flow, 2013. [Online; navˇst´ıveno 23-3-2013]. [Paessler(2013)] PAESSLER. Features of Webserver Stress Tool. http:// www.paessler.com/webstress/features, 2013. [Online; navˇst´ıveno 51-2013]. [Schön(2012)] SCHöN, O. Kvalitn´ı router s WiFi je základ domác´ı pohody, otestovali jsme jich hned pˇet. http://tech.ihned.cz/, 2012. [Online; navˇst´ıveno 10-11-2012]. [Schulze – Mochalski(2009)Schulze, Mochalski] SCHULZE, H. – MOCHALSKI, K. Internet Study 2008/2009. http://www. ipoque.com/sites/default/files/mediafiles/documents/ internet-study-2008-2009.pdf, 2009. [Online; navˇst´ıveno 1712-2012]. [Sourceforge(2010)] SOURCEFORGE. Iperf. http://sourceforge.net/ projects/iperf/files/, 2010. [Online; navˇst´ıveno 25-10-2012]. [Tcpreplay(2013)] TCPREPLAY. Tcpreplay FAQ. http://tcpreplay. synfin.net/wiki/FAQ#RunningTcpreplay, 2013. [Online; navˇst´ıveno 30-1-2013]. [Wikipedia(2013)] WIKIPEDIA. Packet Injection. http://en.wikipedia. org/wiki/Packet_injection, 2013. [Online; navˇst´ıveno 4-1-2013].

46

A Namˇeˇrené hodnoty iterace Download Upload 1 214,39 478,02 2 210,49 440,94 3 208,53 478,02 4 208,53 488,46 208,53 487,79 5 6 208,53 498,66 7 208,65 498,66 218,45 498,66 8 9 208,53 487,13 10 204,82 498,66 11 210,36 488,46 12 222,66 510,03 208,53 488,46 13 14 196,08 498,66 202,97 487,79 15 16 210,49 487,79 206,60 488,46 17 18 208,65 487,79 212,36 498,66 19 20 206,72 546,63 Tabulka A.1: Testovac´ı scénáˇr ˇc.1. Hodnoty jsou v Mbps

47

Namˇeˇrené hodnoty

i. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

ASUS Edimax RouterBoard Cisco Linksys down up down up down up down up down up 53,73 69,94 38,36 60,19 33,88 40,53 93,24 93,99 27,05 41,33 52,73 73,81 38,36 43,02 34,03 41,71 93,24 93,70 25,57 72,05 53,22 75,38 40,38 38,31 34,08 42,10 93,26 93,67 55,26 43,42 53,10 75,46 38,30 39,39 33,78 41,40 93,24 94,24 55,00 72,01 53,34 76,47 38,23 58,79 33,78 41,81 93,26 89,19 54,87 34,50 53,10 73,04 38,23 63,86 33,98 41,75 92,49 93,70 55,27 71,99 53,85 74,42 40,38 58,64 34,13 40,98 93,24 85,70 55,54 72,70 53,09 74,68 38,42 57,62 33,93 41,73 93,26 93,75 54,88 34,73 54,10 33,08 38,42 64,54 33,88 41,72 92,87 93,87 49,87 72,21 52,85 73,82 37,66 59,16 33,93 41,65 86,23 93,85 30,54 34,64 53,22 71,23 37,85 64,73 34,03 39,98 92,85 93,90 55,68 71,78 53,10 76,16 38,35 58,34 34,03 41,61 93,24 93,70 55,54 71,72 52,84 76,08 38,16 39,41 33,98 41,54 92,87 93,80 55,14 72,62 53,73 71,78 38,23 42,19 33,88 40,05 93,26 93,67 54,36 68,48 53,10 74,59 38,16 62,79 34,03 40,90 93,24 93,92 55,54 72,61 53,22 67,36 38,30 58,87 34,03 41,63 93,24 93,78 55,54 72,10 52,97 74,94 38,10 64,46 33,98 41,75 93,22 92,51 55,02 72,62 53,09 34,65 38,17 58,38 34,03 40,77 93,24 94,10 55,13 71,94 53,22 76,40 38,23 61,41 33,88 41,62 93,26 93,90 55,40 69,30 51,90 75,87 40,46 59,06 33,88 41,18 93,24 93,06 55,54 72,55 Tabulka A.2: Testovac´ı scénáˇr ˇc.2. Hodnoty jsou v Mbps

48


iterace ASUS Cisco Edimax Linksys RouterBoard GigabitEth 1 8,10 5,92 8,54 6,23 6,76 4,87 2 8,07 5,12 7,15 6,45 6,32 4,42 3 8,21 5,42 115,32 7,21 7,38 4,58 8,16 5,34 6,51 7,21 6,23 4,46 4 5 8,51 5,35 112,13 8,19 6,26 4,42 6 8,26 5,38 7,59 7,93 6,03 4,34 8,21 5,03 6,52 8,34 6,10 4,15 7 8 8,68 5,10 105,73 8,87 6,14 4,20 9 8,91 5,20 9,82 9,07 7,16 4,23 4,96 10,22 9,08 8,63 4,18 10 48,14 11 9,57 4,76 108,60 9,80 5,88 4,17 8,94 5,15 7,35 9,71 5,98 4,28 12 13 8,79 4,75 117,95 10,54 5,92 4,14 8,93 4,75 6,98 10,44 7,15 4,11 14 8,85 5,56 10,38 11,10 5,84 4,12 15 16 8,90 4,76 115,78 11,13 5,89 4,15 17 8,69 5,01 8,12 10,18 5,93 4,12 18 8,73 5,14 112,51 10,37 5,96 4,15 19 8,87 5,18 7,43 10,08 5,85 5,07 4,92 13,50 10,07 5,90 4,57 20 45,27 Tabulka A.3: Testovac´ı scénáˇr ˇc.3. Hodnoty jsou sekundy

49


iterace 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

BRIDGE NAT ROUTING down up down up down up 62,50 73,52 33,88 40,53 45,60 55,27 62,50 73,15 34,03 41,71 45,96 55,98 62,17 73,29 34,08 42,10 45,87 56,51 62,84 73,18 33,78 41,40 45,70 56,57 62,32 72,49 33,78 41,81 45,97 56,74 62,17 73,04 33,98 41,75 45,60 56,78 62,33 73,38 34,13 40,98 46,25 56,70 62,16 73,25 33,93 41,73 45,78 56,42 62,16 73,34 33,88 41,72 45,60 56,93 62,16 72,92 33,93 41,65 45,15 56,62 62,32 73,42 34,03 39,98 45,69 56,56 62,34 71,42 34,03 41,61 45,60 56,64 62,16 73,10 33,98 41,54 45,87 55,43 61,98 73,59 33,88 40,05 45,15 56,78 61,99 72,99 34,03 40,90 45,87 56,58 61,99 72,94 34,03 41,63 46,15 55,66 61,66 73,01 33,98 41,75 45,78 57,39 61,02 73,20 34,03 40,77 45,78 56,59 62,33 72,92 33,88 41,62 45,70 54,29 62,50 73,06 33,88 41,18 45,70 57,05

Tabulka A.4: Testovac´ı scénáˇr ˇc.4. Hodnoty jsou v Mbps

50


it. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

ASUS Cisco Edimax RouterBoard down up down up down up down up 47,50 19,56 81,10 93,29 30,07 41,05 35,14 29,77 43,14 15,37 80,82 93,67 30,84 32,97 30,18 29,92 42,57 17,63 81,10 93,67 33,45 31,82 29,38 30,15 40,33 20,30 80,82 93,29 32,32 32,46 30,07 30,15 45,71 17,82 80,82 93,67 31,14 42,66 30,01 30,06 41,20 17,31 80,80 93,67 30,11 42,89 29,78 30,02 42,89 16,22 80,51 93,67 29,84 42,50 34,85 30,15 40,69 26,78 80,80 93,31 32,41 40,40 29,50 30,34 41,50 15,54 81,10 93,31 27,88 45,90 28,10 29,89 39,50 21,34 81,10 93,29 30,97 34,87 29,58 29,98 40,26 20,30 81,10 93,67 30,19 42,74 29,20 29,60 50,54 17,46 80,82 93,29 29,26 46,74 29,84 29,86 39,63 20,07 80,80 93,67 33,74 32,69 35,81 31,29 44,74 17,58 80,80 92,92 29,46 44,65 28,50 30,01 47,61 10,05 81,11 93,67 31,01 43,22 29,47 29,23 43,62 14,02 80,82 93,29 28,47 45,26 29,78 31,37 41,88 20,20 80,82 93,29 30,03 47,61 29,71 29,86 47,90 11,78 80,82 93,67 0,00 51,22 35,60 29,98 40,40 20,54 80,80 93,67 30,27 43,14 30,40 29,82 42,42 14,86 80,80 93,65 31,10 47,81 29,29 29,94

Tabulka A.5: Testovac´ı scénáˇr ˇc.5. - FTP test - Hodnoty jsou v Mbps

51


iterace ASUS Cisco Edimax RouterBoard 1 22,15 9,00 16,93 13,55 2 31,77 8,75 20,24 13,44 3 30,56 8,83 89,38 13,37 24,24 13,32 4 27,55 8,74 5 32,31 8,74 93,16 13,37 6 28,46 8,85 24,65 13,10 22,15 13,63 7 32,08 8,80 8 24,78 9,14 89,23 13,03 9 33,22 8,83 20,95 13,29 92,50 12,98 10 24,64 8,99 11 25,20 8,83 25,37 13,33 26,71 13,01 12 34,36 8,69 13 28,25 8,71 83,81 16,56 24,73 13,18 14 31,47 8,80 91,21 13,48 15 37,77 8,74 16 31,31 8,72 21,19 14,57 17 24,29 8,86 67,46 13,67 18 33,45 8,74 45,62 13,10 19 27,74 8,69 25,12 12,89 86,48 13,07 20 34,51 8,66 Tabulka A.6: Testovac´ı scénáˇr ˇc.5. - HTTP test - Hodnoty jsou sekundy

52


Telnet it. ASUS Cisco Edimax RB 1 462 1 4 6 426 1 15 5 2 3 1083 1 17 6 4 302 1 14 5 5 374 1 3 5 6 221 1 2 6 7 462 1 3 6 8 468 1 4 5 320 1 1 5 9 467 1 15 5 10 11 302 1 3 6 452 1 1 6 12 13 303 1 14 15 14 229 1 2 6 15 782 1 2 5 16 773 1 1 15 17 221 1 1 5 18 685 1 1 6 19 462 1 3 6 444 1 2 5 20

UDP stream ASUS Cisco Edimax RB 43 5 12 4 207 5 8 0 41 8 12 4 41 4 3 3 61 3 5 0 22 5 10 1 50 3 0 6 169 22 0 0 45 13 0 2 211 7 1 0 45 8 2 0 46 0 0 0 42 0 0 0 127 9 0 0 61 0 1 0 44 0 0 0 42 7 0 3 41 0 0 0 40 0 0 0 62 0 0 0

Tabulka A.7: Testovac´ı scénáˇr ˇc.5. - TELNET a UDP test - Hodnoty jsou v milisekundách u TELNET testu a poˇcet u UDP stream testu

53

B Uˇzivatelská dokumentace B.1

Prerekvizity

Aplikace byla vyv´ıjena a testována v prostˇred´ı OS Windows 7, ale jej´ı bˇeh je d´ıky 100%-n´ımu sloˇzen´ı z JAVA bal´ık˚ u moˇzn´ y i v dalˇs´ıch prostˇred´ıch. Spuˇstˇen´ı nástroje se provede zadán´ım pˇr´ıkazu java -jar Simulant.jar do pˇr´ıkazového ˇra´dku nebo spuˇstˇen´ım skriptu start.bat, kter´ y se nacház´ı ve stejném adresáˇri. Pˇred spuˇstˇen´ım programu je vhodné zkontrolovat nastaven´ı brány firewall a zde pˇr´ıpadnˇe povolit v´ yjimku pro aplikaci a j´ı vyuˇz´ıvané porty. Na serverové stranˇe to jsou defaultnˇe porty: 21,80,2023,4444. Na klientovi pak pro UDP stream port 5555.

B.2

Ovl´ ad´ an´ı aplikace

Na obrázku B.1 se nacház´ı okno aplikace po spuˇstˇen´ı. V pˇr´ıpadˇe, ˇze se jedná o serverovou instanci, nemus´ıme jiˇz kromˇe ˇc´ısla portu nic nastavovat a aplikaci spust´ıme tlaˇc´ıtkem Start v pravém horn´ım rohu. Uˇzivatel provád´ı volbu reˇzimu klient/server pomoc´ı pˇrep´ınaˇce v levém horn´ım rohu. Na klientské stranˇe se provád´ı volba vybran´ ych test˚ u zaˇskrtnut´ım pol´ıˇcka vedle názvu testu. Pod jednotliv´ ymi záloˇzkami se pak nacházej´ı konfiguraˇcn´ı rozhran´ı test˚ u. Metodiky test˚ u jsou popsány v kapitole 3.2. Pˇred spuˇstˇen´ım klienta nastavujeme poˇcet iterac´ı testu a IP adresu + komunikaˇcn´ı port serveru. Informace o pr˚ ubˇehu mˇeˇren´ı lze sledovat po celou jeho dobu. V´ ystupem je textová konzole a v pˇr´ıpadˇe klienta i pravidelnˇe aktualizované grafy ve spodn´ı ˇcásti aplikace. Bˇeˇz´ıc´ı klient je na obrázku B.2. Protˇejˇs´ı serverová strana pak na obrázku B.3. Zastaven´ı bˇeˇz´ıc´ıho testu provede uˇzivatel tlaˇc´ıtkem Stop v pravém horn´ım rohu. Po jeho stisknut´ı se nastav´ı aktuálnˇe bˇeˇz´ıc´ı iterace jako posledn´ı 54

Uˇzivatelská dokumentace

Ovládán´ı aplikace

a mˇeˇren´ı je ukonˇceno. Rychlé ukonˇcen´ı aplikace lze provést zavˇren´ım okna, klávesovou zkratkou ALT+F4 nebo CTRL+C v oknˇe pˇr´ıkazového ˇra´dku se spuˇstˇenou aplikac´ı. Soubor s v´ ysledky mˇeˇren´ı test.db je vytvoˇren v adresáˇri na u ´rovni spouˇstˇec´ıho JAR souboru aplikace. Po skonˇcen´ı mˇeˇren´ı je moˇzné soubor prohl´ıˇzet napˇr. freeware programem SQLite Database Browser. Ke staˇzen´ı na adrese: http://sourceforge.net/projects/sqlitebrowser/

55



Obrázek B.1: Aplikace po jej´ım spuˇstˇen´ı

56



Obrázek B.2: Aplikace - klient v pr˚ ubˇehu mˇeˇren´ı

57



Obrázek B.3: Aplikace - bˇeˇz´ıc´ı serverová instance programu

58

Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky

Recommend Documents