Návrh komunikačního jádra generátoru síťového provozu

Mendelova univerzita v Brně Provozně ekonomická fakulta

Návrh komunikačního jádra generátoru síťového provozu Diplomová práce

Vedoucí práce: Ing. Martin Pokorný, Ph.D.

Bc. Petr Zach

Brno 2012

Děkuji vedoucímu závěrečné práce Ing. Martinu Pokornému, Ph.D. za konstruktivní odborné rady, trpělivost a čas, který mi během vedení práce věnoval. Dále děkuji Ing. Janu Kryštofovi, Ph.D. a Bc. Rudolfu Bilkovi za spolupráci na projektu.

Prohlašuji, že jsem závěrečnou práci vypracoval samostatně s použitím literatury, kterou uvádím v seznamu.

V Brně 20. května 2012

....................................................

4

Abstract Zach, P. The design of network traffic generator core. Diploma thesis. Brno. 2012. The diploma thesis focuses on the issue of generating network traffic. The requirements specification on the network traffic generator for purposes of Network Laboratory of FBE MENDELU and theoretical basics are followed by analysis of current state of existing network traffic generators. Based on the requirements and shortcomings of current solutions is designed and implemented core of own network traffic generator. After that, testing on the model case studies and statistics are performed. Finally, the economic evaluation is made and the results with possibilities of future development are discussed. Keywords network traffic generator, network traffic, Java, libpcap, Wireshark

Abstrakt Zach, P. Návrh komunikačního jádra generátoru síťového provozu. Diplomová práce. Brno. 2012. Diplomová práce se zaměřuje na problematiku generování síťového provozu. Po specifikaci požadavků na síťový generátor pro účely Síťové laboratoře PEF MENDELU a teoretickém základu následuje analýza současného stavu existujícíh nástrojů. Na základě požadavků a nedostatků současných řešení je navrženo a implementováno jádro vlastního generátoru. Poté je provedeno testování na modelových případech použití a prezentovány statistiky. Na závěr je projekt ekonomicky zhodnocen a jsou diskutovány dosažené výsledky s možnostmi dalšího vývoje. Klíčová slova generátor síťového provozu, síťový provoz, Java, libpcap, Wireshark

5

OBSAH

Obsah 1 Úvod

7

2 Cíl práce

8

3 Specifikace požadavků 9 3.1 Souhrnný popis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 Funkční požadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3 Nefunkční požadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4 Technologický aparát práce 4.1 Základní pojmy . . . . . . . . . . 4.2 Charakteristiky počítačových sítí 4.3 QoS . . . . . . . . . . . . . . . . 4.4 Programové prostředky . . . . . .

. . . .

5 Analýza současného stavu 5.1 Analýza existujících řešení . . . . . 5.2 Nástroje ovládané pomocí GUI . . 5.3 Nástroje ovládané z CLI . . . . . . 5.4 Zhodnocení dostupných generátorů 5.5 Analýza publikací . . . . . . . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

13 13 17 20 22

. . . . .

29 29 30 34 37 39

6 Analýza generátoru 42 6.1 Případy použití generátoru . . . . . . . . . . . . . . . . . . . . . . . . 42 6.2 Analýza jádra nástroje . . . . . . . . . . . . . . . . . . . . . . . . . . 45 7 Návrh a popis implementace 52 7.1 Návrh jádra systému . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 7.2 Popis implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 8 Testování 63 8.1 Problematika QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 8.2 Dostupnost datového centra . . . . . . . . . . . . . . . . . . . . . . . 72 9 Ekonomické zhodnocení 75 9.1 SWOT analýza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 9.2 Analýza bodu zvratu . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 10 Diskuse a návrh dalšího vývoje

79

11 Závěr

81

12 Literatura

82

OBSAH

6

A GUI nástroje IP Test and Measure

85

B GUI nástroje Ostinato

86

C Statistika toku nástroje D-ITG

87

D Analytický diagram komponenty Sender

88

E Analytický diagram komponenty Capture

89

F Topologie datového centra

90

1

1

ÚVOD

7

Úvod

Generátor síťového provozu představuje užitečný nástroj pro testování výkonu a nastavení síťové infrastruktury, komunikačních protokolů nebo služeb. S neustálým rozvojem Internetu a jeho služeb, zejména služeb cloudu a přenosů multimediálních dat, se zvyšují nároky na síťovou infrastrukturu. Přesunem výpočetního výkonu na servery a vyšší konzumací multimediálního obsahu rostou požadavky na objem i kvalitu přenosu. Systémy pro generování síťového provozu vznikají v rámci projektů univerzit i firem. Existují řešení založená na speciálních hardwarových platformách, například FPGA (Field Programmable Gate Array) nebo rešení ryze softwarová. Síťové generátory mohou vytvářet provoz stochasticky, opakováním předešlých komunikací nebo podle připraveného scénáře komunikací. Bez ohledu na způsob generování provozu slouží obecně všechny tyto nástroje k simulaci reálných podmínek v laboratorním prostředí. Většina generátorů obsahuje také analýzu generovaného provozu a chování sítě. Díky těmto systémům poté vznikají doporučení zabývající se návrhem infrastruktury a nastavením kvality služeb (QoS – Quality of Service) pro zajištění optimálních podmínek přenosu v reálné síti. Různorodost generátorů umožňuje vybrat pro konkrétní účel ten nejvhodnější. Kvalita a funkcionalita nástroje je však uměrná pořizovací ceně. Vzniká proto myšlenka navrhnout a vytvořit vlastní softwarový síťový generátor pro účely Síťové laboratoře PEF MENDELU. Laboratoř je vybavena řadou technologií včetně technologií VoIP či datových center. V rámci výuky počítačových sítí a řešení bakalářských a diplomových prací se zde řeší řada experimentů, které vyžadují činnost síťového generátoru. Pokud by vytvořený systém splňoval požadavky laboratoře, vznikl by tak jeden komplexní nástroj sloužící jako podpora pro výuku a řešení zavěrečných prací.

2

CíL PRÁCE

2

8

Cíl práce

Cílem diplomové práce je na základě nedostatků dostupných softwarových generátorů a na základě uživatelských požadavků1 navrhnout, implementovat, experimentálně a ekonomicky ověřit jádro softwarového síťového generátoru. Programovým výstupem závěrečné práce bude jádro generátoru schopné generovat síťový provoz pomocí vybraných protokolů, poskytující rozhraní pro další vývoj nástroje, zejména pro tvorbu uživatelského rozhraní a zpracování statistik generovaného provozu.

1

Požadavky studentů a zaměstnanců fakulty pracujících na projektech v Síťové laboratoři PEF MENDELU.

3

SPECIFIKACE POŽADAVKŮ

3

9

Specifikace požadavků

3.1

Souhrnný popis

Základní popis síťového generátoru Úkolem vyvíjeného nástroje bude generovat síťový provoz v prostředí síťové laboratoře PEF MENDELU v Brně. Bez větších problémů však bude použitelný v jakékoliv TCP/IP síti. Primárně bude simulovat množství uživatelů koncových stanic, kteří využívají služeb připojené sítě. Nástroj bude pracovat jako softwarová aplikace na koncovém uzlu a bude do síťe vysílat běžný provoz, čímž umožní různé testování dané síťě. Aby věrně napodobil opravdového uživatele, musí být možno předem vytvořit plán komunikací (komunikační profil, scénář ) včetně jejich parametrů. Dílčí komunikace se ve správný čas aktivují. Pro snadné nastavení plánu komunikace v celé síti je nutno ovládat všechny koncové uzly z jednoho místa. Uživatelé Uživatelé nástroje budou zejména studenti univerzity, kteří ho mohou používat k simulaci reálné sítě vytvořené v rámci závěrečné práce nebo různých experimentů. Obecně lze ale za uživatele označit kohokoliv, kdo potřebuje ověřit správné nastavení své soukromé sítě nebo odhalit její problémy. V praxi to kromě studentů budou hlavně síťoví administrátoři. Nástroj předpokládá, že uživatel bude osoba, která má odpovídající znalosti síťových technologií minimálně na úrovni, kterou mají absolventi předmětu Počítačové sítě I. Při neopatrném nebo neodborném zacházení může dokonce nástroj působit jako zdroj (D)DoS2 útoku, kdy zapříčiní zhavarování síťové služby. Přehled hlavních funkcí Elementární účel aplikace je generovat síťový provoz z koncových uzlů tak, aby věrně napodoboval opravdového uživatele stanice a poskytl tak cenný zdroj testovacích dat pro experimenty na struktuře a technologii počítačové sítě. Pro zajištění této funkcionality je vhodné vyjmenovat hlavní funkce: 1. Správa komunikačního profilu se specifikacemi datových toků, které se mají generovat v rámci jednoho testu. 2. Ovládání dílčích generátorů (Senderů) generujích provoz (lokální nebo vzdálené) předáním informací v komunikačním profilu. 3. Generování síťového provozu ze zdrojové stanice (Senderu). 4. Sběr proběhlé komunikace. 5. Tvorba statistik na základě proběhlé komunikace. 6. Správa testů (řízení generátoru, profilu a statistik pro každý test zvlášť). 2

(Distributed) denial-of-service attack (http://www.lupa.cz/serialy/utoky-typu-dos/).

3.1

Souhrnný popis

10

Obr. 1: Znázornění základních funkcí systému.

Omezující podmínky Hlavní omezující podmínkou tohoto nástroje je výkon koncových stanic, které budou síťový provoz fyzicky generovat. V závislosti na výkonu hostujícího stroje se bude měnit maximální výkon generátoru. Není například pravděpodobné, aby byl v rámci komunikačního profilu zadán požadavek generovat v jeden okamžik na daném uzlu (generátoru) velké množství různých paketů (tisíce za sekundu) a jakýkoliv stroj je dokázal vygenerovat v požadovaném čase. Co se týče samotné aplikace, je nutné, aby bylo možno vzdáleně navázat řídící spojení mezi uzly v síti (dílčími generátory, Sendery), které chceme pro generování síťového provozu použít a řídící částí celého systému. Provozní požadavky Základním provozním požadavkem je přítomnost virtuálního stroje JRE3 na každé pracovní stanici. Bez tohoto nástroje není možné spustit instanci aplikace napsané v jazyce Java, která bude základním vývojovým prostředkem. Aplikace simuluje činnost uživatelů na koncových uzlech v síti. Stejně jako uživatel přistupuje k určitým již fungujícím službám v síti (např. v prohlížeči otevře určitou webovou stránku), tak i tato aplikace funkční služby předpokládá. Z tohoto důvodu je třeba, aby pro každý zvolený aplikační protokol, jehož pakety mají být generovány, existoval v síti daný aplikační server, který bude s klientem (Senderem) komunikovat. Pokud chce např. uživatel z uzlu A generovat webový provoz na uzel B, je nutné aby na uzlu B fungoval např. Apache. Bez tohoto nebude navázáno řádné TCP spojení a korektní webový provoz neproběhne (jako v reálném provozu). Sender se pokusí inicializovat komunikaci i v případě, že požadovaná serverová služba nebude dostupná, protože se snaží napodobit reálného uživatele, který také pozná nefunkční službu pouze neúspěšnou komunikací. O neúspěchu bude řídící stanice informována příšlušným logem z dílčího Senderu. 3

Java Runtime Enviroment.

3.2

Funkční požadavky

11

Při ovládání vzdálených stanic generujících provoz z jedné řídící stanice bude nutno akceptovat režijní komunikaci mezi koncovými uzly. Tomu se musí přizpůsobit i zabezpečení sítě – například musí být při komunikaci mimo jednu podsíť na firewallu povoleny příslušné komunikační porty režijní komunikace.

3.2

Funkční požadavky

V této kapitole budou představeny funkční požadavky, které definují funkcionalitu budoucího generátoru síťového provozu. Generování síťového provozu Samotné jádro systému, které zajišťuje vygenerování požadovaných datových toků přijatých v komunikačním profilu. Musí zde probíhat korektní komunikace mezi vyvíjeným systémem a používanou síťovou službou (např. webový server). V případě komunikace přes transportní protokol TCP to znamená navázání správného TCP spojení (3cestný handshake). Systém bude jednoduše rozšiřitelný o další aplikační protokoly, v rámci této závěrečné práce budou implementovány HTTP, SMTP, POP3 zapouzdřené v TCP, na UDP běžící RTP a dále ICMP. Centrální řízení dílčích generátorů Tak jako v reálném provozu, tak i při simulovaném, se v síti zpravidla nachází více než jeden zdroj komunikace. Bylo by neefektivní až téměř nepoužitelné řešení nastavovat komunikační profil na každém zdroji (Senderu) zvlášť při testu síťové topologie obsahující už jen desítky uzlů. Proto je nutné, aby systém umožňoval centrální vzdálenou správu všech dílčích Senderů, které se v rámci konkrétního testu budou používat. Správa komunikačního profilu Systém umožňuje řídit generování síťového provozu na základě komunikačního profilu, který přesně definuje, kterou stanicí, jaký druh komunikace má být generován. Komunikační profil je tvořen množinou záznamů obsahujících informace pro dílčí Sendery o tom, jakou komunikaci a kdy generovat, například: PC1 ve 12:00 v intervalu 60 sekund 5 × přistoupí na stránku webového serveru s URL http://192.168.1.1/index.html. Systém také musí umět přidávat, editovat a odebírat záznamy z komunikačního profilu, uložit si celý profil pro budoucí práci či načíst již vytvořený. Je zřejmé, že záznamů bude v profilu mnoho, navíc při využití řádově desítek stanic generujících síťový provoz (nejčastěji virtualizované stroje) musí být tvorba profilu zjednodušena, aby uživatel nemusel pro každý stroj definovat každý konkrétní typ komunikace (záznam v komunikačním profilu).

3.3

Nefunkční požadavky

12

Sběr proběhlé komunikace Aby mohl systém vypočítat potřebné statistiky, musí shromažďovat data o provozu mezi všemi dvojicemi, které v síti komunikují. Simulovaný síťový provoz nesmí být ovlivněn režijní komunikací mezi vzdálenou řídící jednotkou a Sendery. Report proběhlé komunikace Systém po ukončení testu nabídne statistiku proběhlé komunikace, se kterou může uživatel dále pracovat nebo ji exportovat do jiných formátu pro další využití. Jako výstup uživateli by měl systém zobrazit například: • Zpoždění paketů mezi dvěma uzly (Delay). • Procento ztracených paketů (Packet Loss). • Variaci ve zpoždění paketů (Jitter). • Dostupnou šířku pásma (Bandwidth). • Zátěž rozhraní (Load). • Propustnost rozhraní (Throughtput). Podrobné přiblížení síťových charakteristik se nachází v části 4.2. Správa testů Po vytvoření nebo načtení komunikačního profilu může uživatel spustit test nad tímto profilem. Systém musí odeslat pokyny pro generování jednotlivým stanicím (Senderům) a zároveň odeslat startovní signál monitorům proběhlé komunikace (Capture). Systém také umožní kdykoliv probíhající test zastavit.

3.3

Nefunkční požadavky

• Z důvodu síťové komunikace musí být všechny používané stanice nějakým způsobem propojeny. Každý uzel tedy musí mít síťovou kartu a nainstalovány potřebné ovladače k ní. Důležitá je také správná instalace a nastavení protokolů TCP/IP (IP adresa, maska sítě a výchozí brána). • Tato aplikace by neměla být používána v produkční síti, kterou může neopatrným zacházením narušit. Určena je hlavně pro testování nové sítě nebo k experimentům ve specializovaných síťových laboratořích, které jsou navenek uzavřené. • Systém bude ukládat data o již vytvořeném komunikačním profilu, odchycená data vygenerovaná nástrojem a pak také logy o průběhu generované komunikace. Není tedy třeba data žádným zvláštním způsobem zabezpečovat, protože se nejedná o uživatelská data nebo osobní údaje, ale čistě o produkt generátoru. Případné zálohy souborů budou čistě v režii uživatele, stejně jako zabezpečení případného zneužití dat. • Výsledná aplikace musí být vytvořena s ohledem na budoucí rozšíření. Současně se předpokládá využití návrhových vzorů, což jistě zkvalitní výsledný produkt.

4

TECHNOLOGICKÝ APARÁT PRÁCE

4

13

Technologický aparát práce

4.1

Základní pojmy

Simulace a emulace Význam a rozdíl mezi těmito termíny popisuje Peterka (2011). Udává, že simulace je činnost, která má za cíl získat nové poznatky, které z nejrůznějších důvodů není možno získat přímo, zkoumáním původního systému či experimentováním s ním. Emulaci popisuje jako nahrazení originálu, jehož chování a vlastnosti jsou zcela známy, ale samotný systém není k dispozici. Jeho funkce jsou však potřebné, proto se musí realizovat jinými dostupnými prostředky. Rozdíl mezi simulací a emulací je tedy především v tom, k čemu slouží – simulace k získání nových poznatků o určitém systému, zatímco emulace umožňuje zajištění jeho funkcí jinými prostředky (Peterka, 2011). V informatice je emulátor chápán jako HW nebo SW systém, který duplikuje funkce hosta v jiném systému (hostitel) tak, aby úzce napodobil jeho reálné chování. Naopak počítačová simulace experimentuje s modelem reálného systému – např. meteorologická simulace (Wikipedia EN, 2011). Přeneseně na problematiku síťového generátoru lze říci, že síťový generátor simuluje provoz v počítačové síti, přičemž během komunikace může emulovat stranu klienta (klientské aplikace). Generování síťového provozu Generování síťového provozu lze provádět pomocí hardwarových nebo softwarových nástrojů (viz kapitola 5.1). V zásadě lze data generovat třemi různými způsoby4 (Vishwanath, 2006): • stochasticky, • replikovat na základě dat nasbíraných z produkční sítě, • mapou instrukcí pro aplikace v dané síti (tzv. „komunikační profil“). Většina síťových generátorů je součástí první skupiny. Zpravidla, na rozdíl od dalších dvou skupin, generují jeden TCP nebo UDP proud s náhodnými daty, na kterém ale umožňují definovat statistická rozdělení (např. Poissonovo nebo studentovo) počtu generovaných paketů za sekundu nebo délky paketu (DIT-G, Rude/Crude, MGEN ). Takový proud bývá složen z paketů oddělených konstatním intervalem. Generátory tohoto typu slouží zejména k výkonnostním testům nebo testům QoS politik. Například RFC 2544 and RFC 2889 zabývající se testováním zátěže doporučují pro objektivní výsledky tento typ datových proudů (Sommers, 2004). Druhou skupinou jsou generátory, které dokáží replikovat provoz na základě odchytu z produkční sítě. Jsou vhodné pro experimenty, kdy je nutné do sítě přidat reálný datový podkres (BitTwist, Harpoon). Je však problematické takový odchyt produkční sítě získat, je to v rozporu s § 180 až § 183 Trestního zákona 4

Řadu síťových generátorů ale nelze zcela přesně klasifikovat.

4.1

Základní pojmy

14

(č. 40/2009 Sb.). Existuje ale řada vzorových odchytů dostupných na Internetu5 . Poslední jsou nástroje zaměřující se na protokoly aplikační úrovně, kde klienti posílají žádosti na servery, čímž je iniciován síťový provoz, který má stejné vlastnosti jako provoz v reálné síti. Takové systémy jsou vhodné k testování chování a výkonnosti hostů v síti. Nenabízí ale tak pestrou množinu protokolů jako reálná síť v Internetu (Sommers, 2004). Měření (analýza) síťového provozu Williamson (2002) popisuje měření síťového provozu (Network Traffic Measurement) jako metodologii sběru a analýzy dat vztahujících se k činnosti a výkonnosti síťových protokolů. Síťový provoz se analyzuje za účelem: • odstranění problémů (špatná adresace, bezpečnostní útoky), • odladění nových protokolů (pro vývojáře), • měření provozu (empirická data, statistické metody), • měření výkonnosti (nového protokolu). Nástroje pro analýzu síťového provozu dále Williamson (2002) dělí podle několika pohledů: • HW a SW nástroje: Podobně jako generátory lze rozlišovat HW a SW řešení. Výhoda hardwarových je ve větším výkonu, ale jsou dražší. Naopak softwarové poskytují stejnou funkcionalitu za minimální cenu, ale s omezeným výkonem (rodina nástrojů libpcap). • Pasivní a aktivní přístup: Nástroje, které nezasahují do provozu v testované síti, se označují jako pasivní (neboli „non-intrusive“). Naopak aktivní jsou takové nástroje, které za účelem měření vysílají pakety do sítě (např. ping nebo traceroute). • Online a offline analýzy: Některé nástroje (zejména HW) podporují sběr statistik přímo za běhu, často s grafickým výstupem. Ostatní analyzátory (skupina libpcap) nejprve data ukládá a analyzována mohou být až po skončení testu. • Podle L2 protokolu (Ethernet, Frame Relay, ATM). Network Time Protocol Protokol NTP (Network Time Protocol) slouží k synchronizaci času v síti mezi NTP servery a klienty. Jeho cílem je zajistit stejný systémový čas na všech zařízeních v síti. Vytvořil ho David Mills v roce 1985. Definici aktuální čtvrté verze popisuje RFC 59056 . Protokol pracuje na protokolu UDP, port 123. Synchronizace času pomocí NTP je v Internetu široce používaná. Protokol je založen na hierarchickém principu, podobně jako DNS. Primární úroveň NTP serverů tvoří tzv. „stratum-1 “ servery. Ty jsou přímo synchronizovány se zařízeními jako 5 6

http://wiki.wireshark.org/SampleCaptures http://tools.ietf.org/html/rfc5905

4.1

Základní pojmy

15

atomové hodiny, satelity, apod. Sekundární úroveň je složena z stratum-2 serverů, které se synchronizují s primárními servery. Servery na dalších úrovních se dotazují sekundárních serverů, aby nezatěžovaly vrstvu stratum-1 (Mills, 2012). Počítače v této druhé vrstvě si však nevyberou jeden z první vrstvy, zpravidla získávají informace hned z několika. Navíc mohou spolupracovat i mezi sebou (obr. 2). Dochází tedy k určitému zpřesňování času. Podobný princip platí i na dalších vrstvách, většinou však již ve třetí vrstvě bývají klienti (firemní NTP servery), kteří se zpravidla synchronizují pouze s jedním nadřazeným serverem7 . Skupina využívaných NTP serverů se označuje jako NTP Pool. Je definováno až 15 startum vrstev, ale v praxi se používá maximálně 5 (Chvalovský, 2003). Proces komunikace mezi klientem a serverem je označován jako Pool Process složený z řady složitých algoritmů a heuristických metod (Mills, 2012). Proces je založen na postupném přibližování se přesnému času. NTP poskytuje čas ve formátu UTC. Klient ho poté musí interpretovat do času aktuálního časového pásma (Chvalovský, 2003).

Obr. 2: Hierarchie NTP serverů. Převzato od Chvalovského (2003)

Licencování software Během krátké historie vývoje software postupně vznikla potřeba definovat licenčními podmínkami distribuci a zacházení s vytvořeným software. Dnes jich existuje celá řada, přičemž je lze dělit do několika skupin známých pod anglickými názvy, pro něž však v českém právu neexistuje jednoznačný překlad. Podle Aujezdského (2012) se dělí do skupin popsaných níže. Jako tzv. „Public Domain “ jsou nazývána díla, včetně počítačových programů, která nepodléhají ochraně autorským právem (Copyrightem)8 .U public domain programu se tak předpokládá, že může být všemi osobami volně užíván (i pro komerční účely), a to včetně provádění změn tohoto počítačového programu. 7

Seznam některých českých NTP serverů úrovně stratum-2 : http://phoenix.inf.upol.cz/ ~bazgierv/ntp.html. 8 http://www.edwardsamuels.com/copyright/beyond/articles/public.html#fn109

4.1

16

Základní pojmy

Free Software (tzv. „svobodný software“) je podle Free Software Foundation, Inc. počítačový program označovaný jako svobodný, pokud jsou ve smluvním ujednání, na základě kterého je počítačový program poskytován, splněny všechny předpoklady tzv. definice svobodného software9 . Zjednodušeně lze říci, že takový SW je možné bez omezení používat, bez omezení zkoumat, jakým způsobem počítačový program pracuje, bez omezení distribuovat rozmnoženiny a bez omezení vylepšovat (měnit). V oblasti svobodného SW jsou nejčastější licenční podmínky GNU GPL, GNU FDL nebo GNU LGPL. Alternativou ke GNU je BSD License, popř. MIT License. Další skupinou je Open Source Software, který je nadmnožinou skupiny Free Software. Freeware počítačový program, který může být kýmkoliv bezúplatně užíván, a to bez časového omezení, obvykle určené pouze na nepodnikatelské účely. Freewarový počítačový program bývá distribuován výhradně ve formě spustitelného souboru. Proprietální (komerční) software jsou všechny běžně prodáváné programy. Uživatel nemá přístup ke zdrojovým kódům, nemůže měnit funkcionalitu. Často je tato skupina označována za protiklad k Free Software. Analýza bodu zvratu Analýza bodu zvratu (BEP – Break-Even Point) je nástroj krátkodobého rozhodování podniku. Matematicky a graficky modeluje vztahy mezi náklady, výnosy (tržbami), ziskem a objemem produkce. Vychází z dělení nákladů na fixní a variabilní (kapacitní dělení). Analýza bodu zvratu poskytuje informace o tom, kolik má podnik vyrobit a prodat, aby se tržby a náklady rovnaly nebo kolik by měl podnik prodat, aby dosáhl plánovaného zisku. (Synek a spol., 2010). Za předpokladu těchto veličin: • q (počet jednotek produkce), • p (prodejní cena jednoho výrobku), • PVN (průměrné variabilní náklady na jednotku produkce), • FN (roční fixní náklady), • CT (celkové tržby): CT = p ∗ q, • CN (celkové náklady): CN = F N + P V N ∗ q, lze jako situaci, kdy je generován zisk, popsat vztahem CT > CN , naopak ztrátu značí vztah, kdy jsou celkové tržby nižší než celkové náklady. Bod, kdy CT = CN , je označován jako bod zvratu (Qk ). Množství produkce v tomto bodě se označuje jako kritické množství. S každou další jednotkou je generován zisk a s jakýmkoli menším množstvím jednotek je spojena ztráta. Z výše definovaných vztahů lze následně odvodit vzorec pro výpočet bodu zvratu: Qk = F N/ (p − P V N ) 9

http://www.gnu.org/philosophy/free-sw.html

4.2

17

Charakteristiky počítačových sítí

4.2


Základní charakteristiky, které definují stav sítě jsou podle Švece (2011, str. 43): • Ztrátovost (Packet Loss). • Jednosměrné, resp. dvousměrné zpoždění (Latency, resp. Delay). • Variace ve zpoždění (Jitter). • Dostupná šířka pásma (Bandwidth). • Propustnost (Throughput). • Zátěž trasy (Load). Ztrátovost Jak dále Švec (2011) popisuje, ztrátovost lze definovat jako množství ztracených paketů odeslaných v síti mezi uzly A a B. Ztrátovost je rovna procentu rámců, které měly být přeposlány síťovým zařízením při stabilním zatížení, ale nebyly přeposlány z důvodu nedostatků zdrojů (Mrštíková, 2009). Paket a rámec lze zobecnit na PDU10 . Udává se také jako „ztrátovost na lince“. Lze rozlišovat ztrátovost jednosměrnou nebo obousměrnou, která je častější. Vyjadřuje se jako poměr ztracených paketů mezi uzly A a B v obou směrech, konkrétně: PLAB

P AB = 1 − RAB PS

!

∗ 100

[%]

kde: • PSAB je celkový počet odeslaných paketů, • PRAB je celkový počet úspěšně přijatých paketů, • PLAB je relativní množství ztracených paketů udávaných v procentech. Při PLAB = 0 nedochází k žádným ztrátám při přenosu. Jedná se tedy o ideální stav. Problematické jsou hodnoty vyšší než 1 %. Příčinou vzniku vysoké ztrátovosti je zpravidla přetížení přenosové sítě (Švec, 2011). Zpoždění Zpoždění se měří v milisekundách. Švec (2011) ho dělí podobně jako ztrátovost na jednosměrné (Delay) a obousměrné (Latency). Jednosměrné měří časový interval od odeslání paketu z uzlu A do přijetí paketu uzlem B. Jednosměrné (tzv. „end-toend “) zpoždění se skládá ze dvou částí – fixní a variabilní. Fixní je tvořeno serializací (proces vkládání paketu na médium) a propagace (zpoždění způsobené přenosem). Variabilní zpoždění je tvořeno časem, který paket stráví ve frontě (bufferu) při zpracování na rozhraní. To je způsobeno zahlcením sítě (Wallace, 2011). Švec (2011) dále tvrdí, že obousměrné zpoždění měří časový interval od odeslání paketu z uzlu A do uzlu B a příjetím odpovědi uzlem A. Zpoždění bývá zpravidla ovlivněno zatížením přenosového média a směrovačů. Za předpokladu, že velikost paketu při odeslání 10

Protocol Data Unit.

4.2

18


z uzlu A i paketu s odpovědí z uzlu B je stejná, lze obousměrné zpoždění definovat takto: LAB = DAB + DBA + DB • • • •

[ms]

kde: LAB je obousměrné zpoždění, DAB je jednosměrné zpoždění z A do B, DBA je jednosměrné zpoždění z B do A, DB je zpoždění uzlu B způsobené generováním odpovědi. Hodnotu jednosměrného zpoždění DAB lze vyjádřit jako: P R DAB = DAB + DAB

[ms]

Jednosměrné zpoždění opačným směrem lze vyjádřit analogicky: P R DBA = DBA + DBA

[ms]

Hodnota DP je zpoždění při přenosu (fixní) a DR je zpoždění na směrovačích nebo přepínačích (variabilní), které je způsobeno jejich aktuální zátěží. Pokud je cesta mezi uzly A, B a zpět stejná a současně probíhá v malém časovém P P intervalu, lze pominout směr, ve kterém zpoždění vzniklo a říci, že DAB = DBA . Poté lze obousměrné zpoždění vyjádřit vztahem: P R LAB = 2DAB + 2DAB + DB

[ms]

Typickým nástrojem, kterým se měří Latency je ICMP protokol. Z uzlu A odchází ICMP Echo, uzel B odpovídá A pomocí ICMP Reply. Jednosměrné zpoždění se měří obtížněji. Je totiž nutné, aby se hodnota zpoždění měřila na vzdáleném uzlu B, v případě obousměrného lze měření iniciovat i vyhodnotit z jednoho uzlu. Opět platí, že čím menší hodnota, tím lépe. Na zpoždění má mj. zejména vliv šířka pásma přenosového média, která určuje, kolik bitů lze přenést za jednotku času. Variace ve zpoždění Při přenosu některých dat v síti je kromě minimálního zpoždění nutno dbát i na stabilní intervaly zpoždění mezi jednotlivými pakety. Měří se v milisekundách jako rozptyl zpoždění přenášených paketů (Jitter). Pakety nemusí v rámci konkrétní konverzace pocházet z jednoho uzlu a všechny se stejným zpožděním. Jitter je způsoben rozdíly v délkách front při zahlcení sítě a rozdílech v mechanizmech zpracování front (Pužmanová, 2010). Typickým představitelem dat vyžadujících stabilní Jitter jsou multimediální data. Streamované sledování videa nebo VoIP telefonie vyžaduje pro plynulý srozumitelný chod stabilní frekvenci přísunu dat. Například pro srozumitelný VoIP hovor

4.2

19


nesmí být Jitter větší než 30 ms. RFC 3550 (2003) a Wireshark Foundation (2009) definují Jitter vztahem: Ji = Ji−1 + (|Di−1,i | − Ji−1 ) /16

[ms]

kde • Ji je Jitter aktuálního příjatého paketu, • Ji−1 je Jitter předcházejícího paketu, • Di−1,i značí jednosměrné zpoždění mezi předcházejícím a aktuálním přijatým paketem, které se počítá jako: Di−1,i = (Ri − Ri−1 ) − (Si − Si−1 ) = (Ri − Si ) − (Ri−1 − Si−1 )

[ms]

kde Si je hodnota z pole Timestamp v záhlaví RTP paketu (časové razítko odebrání vzorku na odesílateli) a Ri je okamžik přijetí paketu na příjemci. Výpočet variace ve zpoždění Wireshark Foundation (2009) uvádí příklad výpočtu na vzorovém PCAP souboru11 s odchyceným RTP přenosem. Jitter je vypočítán na prvních třech přijatých RTP paketech (číslo 624–626). Za Si , resp. Ri jsou dosazeny tyto hodnoty: • R0 = čas přijetí rámce 624 = 0,3484 s • S0 = pole timestamp rámce 624 = 1240 • R1 = čas přijetí rámce 625 = 0,4183 s • S1 = pole timestamp rámce 624 = 1400 • R2 = čas přijetí rámce 625 = 0,4218 s • S2 = pole timestamp rámce 624 = 1560 Dále je nutné převést hodnotu pole Timestamp na sekundy. V záhlaví paketu přenášená hodnota totiž značí, ve kterém kmitu byl vzorek odebrán. Je tedy nutné ještě znát vzorkovací frekvenci. Frekvence je přenášena v záhlaví RTP paketu v poli Payload Type, v tomto případě je to 8 kHz. Jednotky pole Timestamp je tedy pro převod na sekundy nutné dělit 8000. Nyní již přichází na řadu výpočet Jitteru: • paket 624: J0 = 0 ms • paket 625: D0,1 = (R1 − R0 ) − (S1 − S0 ) = (0, 4183 − 0, 3484) − ((1400 − 1240)/8000) = 0, 0499 s . J1 = J0 + (|D0,1 | − J0 )/16 = 0 + (|0, 0499| − 0)/16 = 3, 12 ms • paket 626: D1,2 = (R2 − R1 ) − (S2 − S1 ) = (0, 4218 − 0, 4183) − ((1560 − 1400)/8000) = −0, 0164 s . J2 = J1 + (|D1,2 | − J1 )/16 = 0, 0031 + (| − 0, 0164| − 0, 0031)/16 = 3, 96 ms 11

http://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=aaa. pcap

4.3

20

QoS

Šířka pásma Šířka pásma (Bandwidth) označuje, kolik bitů se přenese za jednotku času daným médiem (Pužmanová, 2010). Čím vyšší šířka pásma, tím efektivnější využívání signálu. Měří se v bitech za sekundu. Zátěž Zátěž dle Švece (2011) udává množství využité šířky pásma na dané trase. Vyjadřuje se v bps jako: LO =

n X

LOi

[bps]

i=1

kde: • LO je absolutní zátěž trasy, • LOi je zátěž trasy jednoho přenosu (např. jedno TCP spojení). Relativní zátěž (LOR ) vyjadřovaná v procentech je podíl absolutní zátěže a šírky pásma spoje (BW ): LOR =

LO ∗ 100 BW

[%]

Propustnost Propustnost (TR ) je relativní veličina udávající aktuálně využitelnou šířku pásma vyjádřenou v procentech jako (Švec, 2011):

TR = 1 −

4.3

LO BW

∗ 100

[%]

QoS

S příchodem konvergovaných sítí musel být zaveden mechanismus, který zajistil, aby bylo možné v jedné síti provozovat služby se zcela odlišnými požadavky na provoz. Protokoly i tradiční sítě se vyvíjely odděleně a přímo na míru pro danou službu. V konvergovaných sítích je tedy nutné pomocí QoS (Quality of Service) třídit datové toky, přidělovat jim prioritu a potřebnou šířku pásma, aby bylo vyhověno všem rozdílným požadavkům. Ačkoliv jsou pakety přenášející multimediální data typicky malé, nemohou při cestě sítí tolerovat velké zpoždění a Jitter, telefonní hovor by byl nesrozumitelný nebo by bylo spojení přerušeno. Tab. 2 přibližuje druhy přenosů v konvergovaných sítích a jejich potřeby na kvalitu služeb. Naopak pakety přenášející soubory jsou často velké, ale jsou schopné ustát větší zpoždění a ztráty paketů. Nedoručené pakety přenášeného souboru lze díky TCP přeposlat, ale přeposílání části telefonního hovoru postrádá smysl. Na jedné straně tedy stojí konstantní přenos malých paketů,

4.3

21

QoS

Obr. 3: Klasifikace provozu do tříd Převzato od Wallace (2011)

který je nutné rychle a plynule přenášet (náročný na malé zpoždění a Jitter), a na druhé straně je nárazový provoz s vysokým datovým tokem, který je ale odolný vůči neočekávaným změnám v síti. Síťový provoz je tedy klasifikován do tříd podle potřeb datových toků (obr. 3). Ukázku QoS poliky popisující jednotlivé třídy, jak ji uvádí Wallace (2011), znázorňuje tabulka 1. Tab. 1: Příklad QoS politiky Převzato od Wallace (2011) Položka Voice ERP systém Výrobní provoz HTTP/HTTPS

QoS Jednosměrné delay menší než 150 ms Garance 256 kbps dostupné BW Garance 128 kbps dostupné BW Best-effort

Časový interval Po-Pá 24 × 7 × 365 Po-Pá Po-Pá, 6:00-10:00

Tab. 2: Data a síťové charakteristiky Převzato od Pužmanové (2010) Typ provozu VoIP Videokonference Videostreaming Běžná data

Max. ztráty paketů 1% 1% 2% různé

Max. jednosměrná latence 200 ms 200 ms 5s různé

Max. jitter 30 ms 30 ms různé

4.4

Programové prostředky

4.4

22


Java Tento programovací jazyk založený na principech C a C++ začal být vyvíjen v roce 1991 společností Sun Microsystem. Dnes ho vlastní Oracle Corporation. Zajímavostí Javy je, že se jedná o jazyk interpetovaný, ne kompilovaný. Zdrojový kód (soubor s příponou .java) je přeložen do pseudojazyka, tzv. „byte-code“ (soubory s příponou .class), příkazem javac nazev.java. O zavádění programu do paměti při spuštění se stará Java platforma (JRE – Java Runtime Enviroment), spuštění příkazem java nazev, která tak tvoří vrstvu mezi aplikací a operačním systémem, potažmo HW. Díky tomu je zajištěna platformní nezávislost. Java platforma se skládá ze dvou částí: JVM – Java Virtual Machine a základního balíku knihovních tříd označovaného jako Java Core API (Herout, 2008). Vlákna v Javě Využívání vláken (Threads) v programování je dnes s nástupem víceprocesorových počítačů zcela běžné. Vlákna pracují pararelně, tzn. využívají současně několik procesorových jader. Má-li počítač jeden procesor, je pararelní běh zajištěn předáváním řízení prostředků procesoru – tzv. „pseudoparalelní běh “ (Herout, 2008). Každý běžící proces obsahuje minimálně jedno vlákno. Na podobném principu jako vlákna jsou založeny i procesy. Jednotlivé procesy mají vlastní paměťový kontext (nikoliv pouze zásobník volání) a vlastní zámky nad soubory. Z uvedených rozdílů plyne, že výměna vlákna na procesoru, stejně jako jeho vytvoření nebo zrušení, je oproti stejné akci s procesem výrazně levnější operací (není třeba měnit paměťový kontext). Dále je komunikace vláken výrazně snazší než komunikace procesů, protože stačí využít sdílených struktur, zatímco u procesů by bylo zapotřebí využít volání vzdálených metod, sdílet data skrze soubor namapovaný do paměti, atp. Nevýhodou vláken pak je zejména obtížné ošetření jejich korektního souběhu (Algoritmy.net, 2012). Práce s vlákny Vlákno lze vytvořit dvěma způsoby. Může dědit třídu java.lang.Thread nebo implementovat rozhraní Runnable. Java totiž nepodporuje vícenásobnou dědičnost, proto je často jediná možnost použít rozhraní. V obou případech je pak nutné překrýt metodu run(), jejíž kód je po spuštění vlákna vykonán. Vlákno (a metoda run()) se spouští metodou start(). Během svého životního cyklu se podle Herouta (2008) může dostat do čtyř stavů (viz obr. 4): • Nové vlákno – bylo vytvořeno jako nový objekt, ale dosud neproběhla metoda start(). • Běhuschopné – proběhla metoda start(). V tomto stavu se může nacházet více vláken, ale vždy pouze jedno je běžící, ostatní čekají na předání řízení.

4.4


23

• Neběhuschopné – vlákno, které bylo uspáno metodou sleep() nebo čeká na I/O. • Mrtvé vlákno – po skončení metody run().

Obr. 4: Stavy vláken v Javě Převzato od Herouta (2008)

Předávání řízení lze vykonávat metodou yield(), popř. metodou sleep(), která vlákno na určitou dobu uspí. Pokud však není předávání řízení implementováno, stará se o předávání řízení vláken plánovač. Předávání vláken pak závisí na stavu okolních vláken, prioritě vlákna a schopnostech OS. Pokud jsou běhuschopná alespoň dvě vlákna, běží vždy to, které má nejvyšší prioritu. Tu lze u vláken nastavovat v intervalu 1–10, přičemž hodnota 5 je výchozí. Pokud se v množině běhuschopných objeví vlákno s vyšší prioritou, je mu okamžitě předáno řízení – tzv. preemptivní plánování. Pokud na přidělení prostředků čeká více vláken se stejnou prioritou, plánovač se je snaží střídat rovnoměrně. Pokud OS podporuje tzv. „sdílení času “, pak se vlákna pravidelně střídají. Detaily se ale liší podle konkrétních OS (Herout, 2008). Speciálním případem jsou vlákna typu démon. V případě, že program pracuje s vlákny, nemůže skončit dřív, než doběhne poslední vlákno. Pokud však vlákno prohlásíme za démona (setDaemon(true)), běží vlákno jako služba (hodí se typicky pro implementaci serveru) a program lze ukončit i s běžícím démonem. V praxi je časté, že vlákna nepracují nezávisle na ostatních, ale zpravidla potřebují sdílet data. Zde hrozí z důvodu paralelního přístupu k datům jejich nekonzistence. To se řeší synchronizačním prvkem nazvaným monitor. Vlastní ho každý objekt v Javě a lze ho aktivovat klíčovým slovem synchronized. Jak píše Herout (2008), při vstupu do synchronizované kritické sekce vlákno získá monitor (jakoby uzamkne data) a po jejím opuštění opět monitor uvolní (data odemkne). Po získání monitoru jedním vláknem, nemůže jiné vlákno zahájit práci v kritické sekci. Monitor lze aktivovat u třídy, metody nebo bloku. Následující ukázka přibližuje synchronizaci práce se souborem pomocí bloku: public void presun(long kam) throws Exception { // definice bloku, kde je chráněn file synchronized(file){ file.seek(kam); } }

4.4


24

Síťová komunikace v Javě Java je první programovací jazyk, který byl od začátku navrhovaný s ohledem na síťovou komunikaci. Java během svého vývoje implementovala řadu síťových standardů, nyní široce podporuje TCP/IP (Harold, 2005). Vývojáři si uvědomovali vzrůstající význam Internetu a současně velkou konkurenci programovacích jazyků, proto se Java od začátku orientovala na síťové aplikace (Herout, 2008). Protože již Java nepředpokládá, že programátoři potřebují pracovat s nižšími vrstvami referenčního modelu ISO/OSI, podporuje síťovou komunikaci ve svém základním balíku java.net až od transportní vrstvy (L4). Obsluhu nižších vrstev standardní balíky Javy nenabízí. Na L3 lze pouze definovat IP adresy. Podle Pitta (2006) je Java vhodná k programování síťových aplikací zejména z těchto důvodů: • Java je přenositelná mezi platformami bez dalšího programování. • Java podporuje jednoduchou práci s vlákny, což je vhodné pro psaní serverových aplikací, kde jsou vlákna nutná například k alokování spojení. • Prostředí Javy je „bezpečné“, takže aplikace napsané v tomto jazyce jsou relativně imunní vůči kompletnímu pádu. Absence ukazatelů eliminuje všechny druhy problémů spojených s referencí paměti. Všechny výjimky a chyby mohou být zachyceny, i chyby typu „out-of-memory “ lze ošetřit bez výrazných potíží. Nezachycené „runtime“ podmínky mohou být fatální pouze pro dané vlákno, ne pro celou aplikaci. • Java má rozsáhlou a velmi dobře navrženou knihovnu tříd (java.net) schopnou různými způsoby pracovat s IP sockety (API od L4 výše, viz předchozí odstavec). Implementace základní síťové komunikace v Javě Implementace síťové komunikace v Javě začíná na úrovni soketu. V balíku java.net je dostupná třída Socket a její potomci ServerSocket, DatagramSocket a MulticastSocket. Pro potřeby této závěrečné práce je popsána činnost tříd Socket, ServerSocket (TCP), DatagramSocket (UDP) až v praktické části. Soket je spojení IP adresy a portu jednoznačně identifikující cílové zařízení a službu. Port je reprezentován číslem 1-65535 a IP adresa třídou InetAddress. Nejčastěji se IP adresa zakládá pomocí statické metody getByName(), která vytváří objekt třídy InetAddress na základě IP adresy nebo doménového jména předaného v parametru jako text, např.: InetAddress ip = InetAddress.getByName("192.168.1.1"); InetAddress ip2 = InetAddress.getByName("pokusna.domena.cz");

Častější je komunikace pomocí TCP, tento druh spojení je i ve vyvíjeném generátoru využíván více, proto bude přiblížena právě práce s TCP. Podle Pitta (2006) je spolehlivé síťové spojení (TCP) v Javě realizováno pomocí dvou druhů socketů

4.4


25

Obr. 5: Ustanovení TCP spojení v Javě Převzato od Pitta (2006)

označovaných jako active a passive (obecně rozšířenější označení je listening). Server nejprve vytvoří passive socket příkazem: ServerSocket sSocket=new ServerSocket(port);

V nekonečné smyčce čeká na akceptování žádosti od klienta. Pro čekání na připojení klienta využijeme funkci accept, která čeká na spojení s klientem a po takovém úspěšném spojení vytváří proměnnou typu Socket, jež reprezentuje individuální socket – konkrétní aktuální spojení s klientem (Zaachi.com, 2008). Socket socket=sSocket.accept();

Vytvoří se tedy aktivní socket a obě strany mohou spolehlivě komunikovat. Tento proces znázorňuje obr. 5. Z proměnné socket lze číst vstup vytvořením vstupního proudu, který objekt soketu vrací: BufferedReader reader=new BufferedReader( new InputStreamReader(socket.getInputStream()));

Následující ukázka přibližuje implementaci TCP serveru, analogicky je vytvářen i TCP client, podrobně rozebrány budou v praktické části. Účelem této ukázky je přiblížit využití vláken (rozhraní Runnable a metoda run()) a akceptace spojení ve smyčce. class TCPServer implements Runnable { private ServerSocket serverSocket; public TCPServer(int port) throws IOException { this.serverSocket = new ServerSocket(port); } public void run() { for (;;) { try { Socket socket = serverSocket.accept(); ... // KOMUNIKACE POMOCÍ STREAMŮ } catch (IOException e) {} } } }

4.4


26

Analyzátory založené na knihovně libpcap Knihovna libpcap12 je určena pro odchyt paketů (Capturing). Byla vytvořena v jazyce C pod BSD licencí a původně určena pro systémy Unix-based systémy. Později byla vydána verze i pro operační systémy Windows pod názvem WinPcap13 (Schneider, 2005). Libpcap poskytuje rozhraní pro práci s pakety už vrstvy L2. Dá se již označit za standard pro nízkoúrovňový přístup aplikací k síťovému rozhraní. Na knihovně libpcap pracuje velká většina aplikací pro odchyt, generování a testování síťového provozu napříč všemi platformami14 . Knihovna libpcap příjímá pakety přímo od jádra operačního systému, lze tak snímat provoz před zpracováním cílovou službou nebo při odesílání odpovědi odesílateli.

Obr. 6: Pozice knihovny libpcap v OS

Na Linuxu tuto knihovnu využívá nástroj tcpdump15 vytvořený autory knihovny libpcap. Nástroj nabízí odchyt paketů, ukládání do binárního souboru .pcap a pokročilé možnosti filtrací a pravidel. Alternativou na Windows je WinDump. Dnes však oba tyto nástroje zastínil Wireshark a jeho přidružená skupina nástrojů. Měření a analýza síťového provozu je zpravidla součástí systému pro monitoring sítě, který nabízí řadu dalších funkcí. Tato problematika je však mimo rozsah práce. K měření síťového provozu se často využívá protokolu NetFlow (jFlow, sFlow). Samostatné nástroje pro měření síťového provozu jsou však nejčastěji založeny na knihovně libpcap. Nástroje Wireshark Wireshark je multiplatformní paketový analyzátor pracující nad knihovnou libpcap vydaný pod licencí GNU GPLv2. Ve srovnání s tcpdump má kromě grafického rozhraní i rozšířenou množinu podporovaných protokolů, funkcí filtrování paketů i výpočtů statistik. Odchytává provoz z Ethernetu, 802.11, PPP/HDLC nebo USB či Bluetooth (Wireshark, 2012). 12

Zkratka znamená LIBrary Packet CAPture. Pro jednoduchost budou dále pod názvem libpcap chápány obě verze. 14 http://en.wikipedia.org/wiki/Pcap#Programs_that_use_libpcap.2FWinPcap 15 http://www.tcpdump.org/ 13

4.4


27

Wireshark Foundation uvolnilo další užitečné nástroje nad knihovnou libpcap ovládané z příkazové řádky16 : • dumpcap – jedná se o alternativu k tcpdump, • capinfos – vypisuje informace o PCAP souboru s odchytem, • editcap – upravuje odchycené pakety v PCAP souboru (mění záhlaví, vypouští nechtěnné pakety, apod.), • mergecap – spojuje několik PCAP souborů do jednoho, • text2pcap – z tzv. „ASCII hex dump“ vytváří binární PCAP soubor, • tshark – ekvivalent Wiresharku ovládaný z příkazové řádky. Z tohoto výčtu je z pohledu vyvíjeného generátoru velmi zajímavý poslední zmiňovaný nástroj. Nabízí veškeré funkce známého Wiresharku, přičemž odchycené pakety z vybraného síťového rozhraní nebo souboru vypisuje na standardní výstup či do souboru. Jeho kompletní možnosti jsou popsány v manuálových stránkách17 a existuje i seznam všech filtrů18 . V tomto textu je níže pro názornost uveden jeden příklad použití. Tento příkaz nastaví tshark tak, aby odchytával provoz na rozhraní eth0 po dobu 60 sekund, odchytával pouze pakety RADIUS serveru (1812/UDP) a odchyt ukládal do souboru odchyt.pcap: tshark -i eth0 -a duration:60 -f "udp port 1812" -w odchyt.pcap

Protokol RPCAP Nad knihovnou libpcap byl dále vytvořen komunikační protokol pro odchyt na vzdáleném stroji nazvaný RPCAP. Podobně jako všechny nástroje postavené nad touto knihovnou je platformě nezávislý. Pracuje tak, že na vzdáleném stroji se spustí služba (démon) na Linuxu nazvaná rpcapd, na Windows Remote Packet Capture Protocol v.0 (experimental), který od klienta (Wireshark nebo tshark) přijme instrukce, spustí odchyt a místo výpisu na standardní výstup odchyt okamžitě přeposílá na klientskou aplikaci (WinPcap, 2007). Navázání spojení se vzdáleným strojem lze z klienta provést tak, že se místo volby lokálního rozhraní vloží URL vzdáleného, například: tshark -i rpcap://192.168.1.10/eth0 -a duration:60 -f "udp port 1812" -w odchyt.pcap

Tento protokol by jistě našel uplatnění i ve vytvářeném generátoru. Jeho největší nevýhodou ale je, že přeposílá odchycená data okamžitě na řídícího klienta, pokud by se nacházel ve stejné (testované) síti nebo by touto cestou vedla ke klientovi cesta, test by byl touto komunikací výrazně zkreslen. 16

http://wiki.wireshark.org/Tools http://www.wireshark.org/docs/man-pages/tshark.html 18 http://www.wireshark.org/docs/dfref/ 17

4.4


28

Java knihovny pro práci s libpcap V Javě existuje několik frameworků fungujících jako nadstavba v Javě nad knihovnou libpcap. Lze tak v Java aplikacích pracovat s pakety podobně jako to dělá tshark. Vzniká však otázka, zda není z hlediska výkonu lepší používat optimalizovaný nástroj tshark. Jak přiznává sám Wireshark – při extrémních zátěžích ani jeho produkty nejsou schopny odchytit všechny pakety. Za zmínku stojí celkem tři tyto frameworky. První dva jsou pojmenovány stejně (jpcap)19 . Bohužel už ani jeden z projektů není aktivní. Jediný stále podporovaný je framework JNetPcap20 dostupný pod LGPL licencí (existuje i komerční verze). Java Mail JavaMail API (javax.mail.*) je platformě a protokolově nezávislý framework pro práci s emaily. Nabízí rozhraní pro práci s protokoly SMTP, POP3 i IMAP. Standardně je přítomný v Java EE (Enterprise Edition), do Java SE (Standard Edition) lze tento framework dodatečně stáhnout a připojit (JavaMail 1.4.5). Existují i další alternativy JavaMail – např. JHTTPMail 21 nebo GNU JavaMail 22 . Díky JavaMail API lze vytvářet vlastní emailové klienty kompletně v Javě. Lze odesílat a příjímat maily včetně příloh (Harold, 2005). Java JMF Java Media Framework API umožňuje odesílat (unicast, multicast i broadcast) a příjímat streamované video a zvuk v řadě formátů (JPEG, MPEG-1, MPEG2, QuickTime, AVI, WAV, MP3, GSM, G723, H263 a MIDI). Data jsou přenášena protokolem RTP (RFC 3550) (více Huja (2003)). K protokolu RTP se váže protokol RTCP (Real-time Transport Control Protocol, RFC 3550), který pracuje jako podpůrný protokol k RTP. Tak jako JavaMail, je to nestandardní balík (javax.media.*) aktuálně ve verzi 2.1.1. Mastracci (2011) rozlišuje v procesu stramování multimedií pomocí JMF tři fáze: vstupní, procesní a výstupní. První fáze obsahuje načtení dat ze souborů (webová kamera, mikrofon, TV) a předání procesním bufferům. V procesní fázi některý z množiny kodeků zmodifikuje proud dat do formy přenositelné v síti a v rámci poslední fáze se data odešlou do sítě. Přijímací strana funguje v opačném pořadí.

19

http://netresearch.ics.uci.edu/kfujii/Jpcap/doc/index.html a http://jpcap.sourceforge.net/ 20 http://jnetpcap.com/ 21 http://httpmail.sourceforge.net/ 22 http://www.gnu.org/software/classpathx/javamail/javamail.html

5

29

ANALÝZA SOUČASNÉHO STAVU

5

Analýza současného stavu

5.1

Analýza existujících řešení

Po analýze požadavků na síťový generátor v prostředí Síťové laboratoře PEF MENDELU je nutné zanalyzovat současný stav existujících řešení. Cílem této analýzy je získat přehled o příbuzných projektech, který má odpovědět na několik otázek. Nejdříve je nutné zjistit, zda již neexistuje takový nástroj, který plně nebo z velké části plní všechny stanovené požadavky na síťový generátor (SG). Další vývoj podobné aplikace by byl zbytečný. Pro případ, že žádný existující nástroj v dostatečné míře neuspokojuje definované požadavky, zhodnotí analýza dostupná řešení, přičemž vyzdvihne pozitiva dílčích nástrojů, která mohou být přínosem ve fázi návrhu vlastního nástroje. SG lze dělit podle řady různých kritérií. Základní hledisko je dělí na hardwarová (HW) a softwarová (SW) řešení. Jejich vlastnosti shrnují tabulky 3 a 4. HW nástroje jsou jednoúčelová zařízení určená pouze k simulaci síťového provozu. Je to spojení HW a SW vytvořeného přímo pro daný HW tak, aby ho efektivně využíval. Z toho je patrné, že dosahují často vyššího výkonu než SW nástroje, které zpravidla ve formě aplikace spuštěné na pracovní stanici simulují jejího uživatele. S prvním dělením úzce souvisí další pohled jak SG dělit – dle pořizovací ceny. Lze říci, že HW nástroje jsou komerční řešení s nemalou pořizovací cenou23 . Naopak SW nástroje jsou dostupné jak ke stažení zdarma, tak s pořizovací cenou v řádu tisíců dolarů. Jejich pořizovací cena úzce souvisí s tím, zda jsou to řešení komerční nebo dostupná pod některou volně dostupnou licencí. Maximální pořizovací cena, za kterou je ústav informatiky ochoten koupit existující SG vyhovující všem specifikovaným požadavkům je 500 dolarů. Tab. 3: Charakteristiky softwarových generátorů Převzato od Yallapragady a spol., 2009 Klady Flexibilní funkce Cenově přijatelné Dostupné i jako open-source

Zápory Proměnlivá doba zpracování úkolů Nelze generovat vysoké objemy dat Výkon závisí na CPU, OS, aktuální zátěži systému

Tab. 4: Charakteristiky hardwarových generátorů Převzato od Yallapragady a spol., 2009 Klady Generují velké objemy dat Nastavené na míru uživateli Vysoce výkonné Predikovatelné časy výsledků zpracování 23

Zápory Vysoká pořizovací cena Často až příliš komplexní Pravidelné aktualizace licencí Dostupné zpravidla komerčně

Mezi nejznámější komerční HW generátory patří Miercom, Spirent nebo IxChariot.

5.2

Nástroje ovládané pomocí GUI

30

V rámci závěrečné práce byly analyzovány HW i SW nástroje. Žádný HW generátor vzhledem ke své pořizovací ceně nevyhovuje definovaným potřebám (kromě FPGA generátorů, viz níže), proto jsou v této práci dále zmiňovány pouze softwarové SG. V textu dále jsou rozděleny podle toho, zda je k nim dostupné GUI nebo jsou zatím ovladatelné jen pomocí CLI. V rámci sekce jsou seřazeny abecedně. Poté následuje zhodnocení existujících nástrojů a doporučení dalšího vývoje. Na závěr této kapitoly (tab. 6) jsou vyjmenovány další nástroje pro testování sítě. Pro snazší orientaci v analýze a jednotnost všech ukázek níže budou všechny nástroje testovány a popisovány na jednoduché topologii, kdy jsou tři PC propojeny klasickým L2 switchem ve výchozí konfiguraci. Adresní prostor sítě je 192.168.1.0/24. IP adresy jsou přidělovány sekvenčně. Vzhledem k operačním systémům používaných v síťové laboratoři PEF, bude se při testování pracovat na OS Windows XP, Windows 7 a Linux CentOS.

5.2


Cat Karat Packet Builder Nástroj Karat je pro osobní a vzdělávací účely dostupný zdarma, ale s omezenou funkcionalitou. Požadavkům nevyhovuje, protože pracuje pouze na platformě MS Windows. V této analýze je zmíněn zejména pro jeho přehledně zpracované GUI, kde je zajímavě zpracován výběr protokolů při stavbě paketu, který má být generován24 . Omnicor LanTraffic V2 a IP Traffic Test and Measure Společnost Omnicor nabízí celkem tři nástroje pro generování paketů v síti. Všechny jsou si velmi pododobné, IP Traffic TaM obsahuje navíc systém pro testování QoS25 . LanTraffic V2 existuje ve dvou verzích – Standard (600 USD) a Enhanced Edition (750 USD). Nejdražší nabízená aplikace IP Traffic Test and Measure stojí 900 dolarů. Kvůli této pořizovací ceně již nesplňují jeden ze základních požadavků na systém. I když by bylo případně možné vyjednat akademickou slevu, druhým z našeho pohledu základním, nedostatkem je závislost aplikace na platformě MS Windows. Bez ohledu na cenu a závislost na platformě jsou tyto nástroje velmi propracované a nabízí řadu možností v generování, odchytávání, filtrování paketů a jejich statistik. Všechny tři nástroje například podporují řadu protokolů L1 a L2: LAN (např. Ethernet, Token-ring), WLAN (Wi-Fi, WiMax, . . . ), WAN modem, ISDN, ATM, ADSL, FTTx, . . . (Omnicor, 2010). Ovládání GUI je ale neintuitivní a nepřehledné a i po delším seznamování s aplikací je orientace při práci velmi slabá. Základní pracovní okno nástroje26 (příloha A) nabízí definici 16 dílčích spojení (unicast, multicast, broadcast), přičemž pro každé lze kromě socketu nakonfigurovat 24

Snímek rozhraní je dostupný na: https://sites.google.com/site/catkaratpacketbuilder/screenhots. 25 K měření QoS jsou dále nutná HW zařízení společnosti synchronizovaná pomocí GPS. 26 Pro jednoduchost bude dále popsán pouze nástroj LanTraffic V2 Standard Edition.

5.2


31

parametry záhlaví na jednotlivých vrstvách. Vedle protokolů TCP, UDP podporuje i ICMP a SCTP. Nástroj obsahuje dva základní moduly Sender a Receiver (obrázek 7), Sender je zdrojem paketů odcházejících z rozhraní, Receiver příjemcem paketů. Pokud se vytvoří vzájemná spojení mezi dvěma hosty, může tak existovat až 32 spojení současně.

Obr. 7: Schéma generování spojení Převzato z LanTraffic V2 User Guide (2010)

Sender vysílá pakety pomocí tří zdrojů dat: • Paketový generátor (počet a obsah paketů, zpoždění mezi pakety, . . . ). • Automatický generátor náhodných dat s rozložením pravděpodobnosti. Definuje se start, doba trvání, množství přenesených dat, rozložení pravděpodobnosti (Poissonovo, Paretovo, binomické, atd.) pro množství dat v paketu a druhé rozložení pravděpodobnosti pro množství vytvářených spojení. • Soubor. Modul Receiver na straně příjemce musí mít nastavené odpovídající parametry podle nastavení na straně Senderu, jinak nebude spojení úspěšné. U každého spojení lze vybrat jeden z pěti pracovních módů: • Absorber Mode – přijatá data jsou pouze započítávána do statistik. • Absorber File Mode – přijatá data jsou navíc ukládána do souboru. • Echoer Mode – každý přijatý paket je odesílán zpět odesílateli. • Echoer File Mode – každý přijatý paket je navíc na odesílateli ukládán do souboru. • Generator Mode – přijatá data jsou započítávána do statistik a Receiver odesílá zpět na Sender datový tok, který lze libovolně nadefinovat stejným způsobem jako lze definovat spojení na straně Senderu. V případě příchozího TCP spojení odchází z Receiveru na Sender datový tok po úspěšném ustanovení příchozího TCP spojení, pokud je příchozí spojení relizováno pomocí UDP, je zpětný datový tok spuštěn po 5 sekundách od prvního přijatého UDP datagramu. Nástroj vytváří statistiky například o odeslaných a přijatých paketech, vzniklé chyby během přenosu, ztracené pakety, Jitter, atd. Zajímavou součástí aplikace LanTraffic je nástroj pro tvorbu scénářů nazvaný Automation Tool for LanTraffic V2. Scénář je posloupnost příkazů a instrukcí (viz ukázka níže). Příkazy definují jednotlivé síťové operace, jsou určeny pro LanTraffic. Instrukce jsou určeny jen pro Automation Tool, například reprezentují čas, kdy se

5.2


32

Obr. 8: Vztah mezi scénáři a generátorem Převzato z LanTraffic V2 User Guide (2010)

má předat příkaz pro LanTraffic. Vztah mezi scénáři a generátorem je znázorněn na obrázku 8. Pomocí scénářů je řešen i vzdálený přístup k jednotlivým SG. Na vzdáleném SG se nejprve musí povolit vzdálený přístup. Poté lze v ovládající instanci SG řídit vzdálený nástroj vyplněním cílového soketu a názvu scénáře, který se má aplikovat. -- Set and start connection #02 (UDP), wait 1 minute and stop -SET AND START CONNECTION(S) 02 DESTINATION IPADDRESS 192.168.1.2 PORT 2010 PROTOCOL UDP AVERAGE THROUGHPUT 512 kb/s PACKET SIZE 1024 bytes WAIT 00:01:00 STOP CONNECTION(S)#02

Ostinato Ostinato je multiplatformní open-source SG a paketový analyzátor vydaný pod licencí GNU GPL v3. Vychází za podpory projektu Google Code27 . Ostinato se snaží být komplementem k Wiresharku. Wireshark je nejrozšířenější paketový analyzátor, naopak Ostinato chce dosáhnout stejného úspěchu mezi SW generátory provozu (paketů). Tak jak Wireshark umožňuje sledovat síťový provoz za účelem odstranění závad v síti, Ostinato ze stejného důvodu síťový provoz generuje (Ostinato, 2011). Wireshark je v Ostinatu dokonce využíván v rámci paketového analyzátoru, přičemž spolu komunikují prostřednictvím knihovny libpcap28 , který oba implementují. Mezi jeho hlavní přednosti patří uživatelsky přívětivé GUI, široká podpora protokolů, platformní nezávislost a zejména propracované ovládání vzdálených stanic. Hlavní okno aplikace (příloha B) se skládá ze tří částí: seznamu portů, k nim vytvořeným streamem (definice úlohy generátoru) a tabulkou statistik. Porty (rozhraní hosta) jsou v seznamu sdruženy do tzv. „Port Group“, která reprezentuje jedno zařízení. Aktivní porty jsou označeny zeleně, neaktivní červeně. Ke každému rozhraní lze definovat množinu streamů. Postup je velmi podobný nastavení paketové tvorby u nástroje Karat. Také lze vybrat protokoly na všech vrstvách a měnit 27

http://code.google.com/intl/cs-CZ/ V Unix-like systémech se používá implementace libpcap, na Windows existuje ekvivalent známý jako WinPcap. 28

5.2


33

hodnoty v záhlaví. Lze vkládat i libovolný text do aplikačních dat. Statistiky pak nabízí základní údaje o přenosu. Ostinato je realizováno architekturou klient-server. Díky této architektuře je automaticky zajištěno ovládání vzdálených stanic – Senderů (tzv. „Remote Access“). Klient (Ostinato) je spuštěný jako aplikace na řídící stanici a je připojeno na jeden nebo více stanic (Senderů), na kterých běží proces drone (server). Server může být v jeden okamžik ovládán pouze jedním klientem. Oba mohou komunikovat i na jedné stanici současně – tzv. „Default Mode“. V takovém případě je lokální server reprezentován v seznamu portů IP adresou loopback (obr. 9). Pro ovládání vzdáleného hosta (PC se spuštěným serverem drone) stačí přidat novou Port Group s odpovídající IP (obr. 10). Dále už se pracuje stejně jako v případě Default Mode. Nevýhodou při ovládání vzdálené stanice je přítomnost paketů s řídícími instrukcemi protokolu RPCAP. Při vzdáleném přístupu je však minimální režijní komunikace nezbytná. U každého portu lze navíc spustit velmi užitečnou funkci – Exclusive Port Control. Ta kompletně vyhradí daný port pouze pro Ostinato. Je tak zaručeno, že do plánovaného testu nevstoupí cizí nechtěná komunikace ostatních systémů. Jinými slovy, veškeré následné statistiky jsou odfiltrované tak, aby vyhodnocovaly data generovaná pouze Ostinatem. Tento SG se nejvíce přibližuje specifikovaným požadavkům. Bohužel nástroji téměř chybí nastavení parametrů datového toku, volby aplikačních protokolů a také se s požadavky rozchází v definici komunikačního profilu, resp. streamů.

Obr. 9: Výchozí seznam portů.

Obr. 10: Seznam portů po připojení vzdálené stanice.

Serverový tester Apache J-Meter Společnost Apache Software Foundation, vyjíjející webový server Apache, připravila volně dostupný29 nástroj J-Meter pro zátěžové testování webových serverů, aplikací a databází. Nástroj je kompletně vytvořený v Javě a umožňuje nadefinovat 29

http://en.wikipedia.org/wiki/Apache_License

5.3

Nástroje ovládané z CLI

34

zátěžový scénář složený mj. zejména z HTTP Requestů, kterými podle dalších voleb dotazuje na server (v několika vláknech) a tím generuje zátěž. Podporuje protokoly HTTP(S), SOAP, JDBC, LDAP, JMS, POP3 a IMAP (Apache Software, 2012). Jak píše Sýkora (2011), byl nejprve navržen pouze pro problematiku zátěžového testování, ale od začátku vývoje, díky možnosti integrace zásuvných modulů, přibylo značné množství dalších funkcí. Aplikace se ovládá pomocí GUI, kde lze vytvářet testovací scénáře. Také nabízí ovládání instancí J-Meteru na vzdálených zařízeních a tím věrněji simulovat zátěž. Po ukončení testu zpřístupní přehled statistik. J-Meter patří mezi nejznámější nástroje pro testování zátěže webových serverů30 , svůj účel plní výborně, a proto ani není cílem vznikajícího generátoru JMeteru konkurovat. Navrhovaný generátor není zaměřený pouze na (webové) servery, ale bude sloužit k testování i dalších síťových prvků.

5.3


BitTwist BitTwist je jednoduchý, ale užitečný nástroj pro Ethernetové sítě postavený na knihovně libpcap. Pracuje tak, že regeneruje odchycený provoz uložený v souboru typu PCAP (Heng, 2011). Podporuje jak OS Linux, tak Windows31 . Celkově se skládá ze dvou komponent – bittwiste a bittwist. K práci s nástrojem se předpokládá přítomnost PCAP souborů se záznamem komunikace. Pomocí první jmenované komponenty lze ve vstupním PCAP souboru upravit zdrojové a cílové IP adresy a porty. Druhá komponenta (bittwist) je pak schopná vygenerovat síťový provoz přesně podle upraveného vstupního souboru. Tento generátor výborně doplňuje nástroj tcpdump, který slouží pro zachytávání komunikace na příslušném síťovém rozhraní. Právě pomocí něho lze výchozí PCAP soubory vytvářet. Bittwist se ale pro náš účel do síťové laboratoře nehodí, zejména proto, že se nejedná o klasický generátor, je úzce spojený s PCAP soubory a neumožňuje definovat vlastní komunikaci. D-ITG Distributed Internet Traffic Generator je nástroj schopný vytvářet síťový provoz (IPv4/IPv6) na síťové, transportní a aplikační vrstvě a který věrně kopíruje stochastické charakteristiky síťového provozu (D-ITG, 2011). D-ITG je projekt Neapolské univerzity, vyvíjený v jazyce C++, dostupný pod licencí GNU GPL v3. Původně je D-ITG navržen pro ovládání z příkazové řádky. Později se nástroj začal nabízet i grafickým rozhraním vytvořeným v Javě, které přistupuje k samotnému nástroji pomocí příkazové řádky. GUI však není zpracováno přehledně a ve srovnání se samotným TG nepřináší nic navíc. 30

Dále existují volně dostupné například: FunkLoad, OpenSTA, httperf. Komerční dále popisuje Sýkora (2011). 31 Je nutné doinstalovat knihovnu cigwin.dll.

5.3


35

Na rozdíl od ostatních TG dovoluje D-ITG definovat paket až od 3. vrstvy, tedy nelze měnit protokol a parametry L2 rámce. Od L3 dále podporuje ICMP, UDP, TCP, SCTP, DCCP. Z aplikačních protokolů pracuje omezeně (viz níže) s DNS, Telnet a VoIP.

Obr. 11: Schéma komponent D-ITG. Převzato z D-ITG (2011)

Jak již název napovídá, systém je distribuovaný. Využívá několika komponent, které vzájemně komunikují pomocí TCP (viz obr. 11). Základem pro úspěšné generování síťového provozu jsou komponenty ITGSend a ITGRecv. ITGSend generuje ze zdrojové stanice provoz, přičemž na cílové stanici32 musí být spuštěna komponenta ITGRecv, která poslouchá na příslušném portu a odchytává přijatý provoz a případně i reaguje prostřednictvím odpovědí odesílateli (např. při generování TCP). Je tedy nutné, aby byl ITGRecv vždy spuštěný. O zpracování síťového provozu se tedy na straně příjemce nestarají odpovídající služby OS, ale samotný ITGRecv. Nástroj je ovládán z příkazové řádky pomocí přepínačů a parametrů prostřednictvím dílčích komponent. Ukázka níže demonstruje případ, kdy se má z lokálního stroje (192.168.1.1, port 9000) vygenerovat 5 UDP segmentů za sekundu, velikost 500 B, po dobu 10 sekund (10 000 ms) a odesílat na 192.168.1.2:9001. Na vzdáleném stroji je nutno spustit ITGRecv, poté lze spustit generování z lokálního stroje. Před prvním UDP datagramem je navíc navázáno mezi stanicemi řídící TCP spojení, které skončí po posledním přeneseném UDP datagramu. To může být v řadě praktických testů vnímáno jako nechtěnný provoz. /* na příjemci 192.168.1.2 */ ./ITGRecv /* na odesílateli 192.168.1.1 */ ./ITGSend -a 192.168.1.2 -sp 9000 -rp 9001 -C 5 -c 500 -t 10000

Třetí komponentou nástroje je ITGLog. Jedná se o log server celého nástroje. Na něj navazuje ITGDec, který analyzuje logy a vytváří statistiky. Ukázka statistik z příkladu uvedeného výše je znázorněna v příloze C. Poslední významnou komponentou je ITGManager, pomocí které je realizováno ovládání vzdálených stanic. Na ovládaných odesílatelích musí být spuštěn ITG Sender jako démon. Poté lze komp. ITGManager předat IP vzdáleného odesílatele 32

Lze obě komponenty spouštět i na localhostu (výchozí stav).

5.3


36

a příkaz pro vzdálený ITGSender, ten se pomocí UDP odešle a po úspěšném úkolu odesílatel informuje přes UDP managera o dokončení činnosti. Nástroj D-ITG je velmi propracovaný a řadu možností plní nad rámec požadavků. Jako nevýhoda může být ale chápána závislost na komponentě ITGRecv a s tím spojená TCP komunikace před a po každém generovaném datovém toku. Není tak možné například otestovat chování reálného webového serveru, protože ho zastupuje komponenta ITGRecv. Tento síťový generátor (SG) navíc pracuje s aplikačními daty jen omezeně. U podporovaných protokolů (DNS, Telnet, VoIP) totiž umožňuje generovat jen odpovídající náhodná data, i když pomocí různých rozdělení (binomické, Poissonovo, atd.). NetCat NetCat je síťový nástroj pracující na TCP/IP, který příjímá a odesílá data mezi koncovými uzly. Je navržen jako spolehlivý nástroj ovládaný z CLI nebo jednodušeji pomocí jiných programů a skriptů. Je vybaven mnoha funkcemi pro experimenty v síti a dokáže vytvořit řadu síťových spojení (Giacobbi, 2006). Nejprve byl NetCat navržen pouze pro Unix-like systémy, nejnovější původní verze je dostupná na http://nc110.sf.net/. Později také vznikla řada dalších linuxových verzí – GNU netcat, SBD, pnetcat, OpenBSD, atd. a také varianta pro operační systémy Windows33 . Existuje i verze pro MacOSX a mobilní zařízení (Wikipedia EN, 2011). Přestože je dostupný v různě upravených podobách bez pevné dokumentace a kromě OpenBSD už není aktivně vyvíjen, je tento nástroj vývojáři široce používán, protože i v základu (bez ohledu na konkrétní implementaci) nabízí řadu užitečných funkcí. Mezi nejužitečnějšími nástroji pro sítě a bezpečnost je zařazen na 8. místo (Sectools.org, 2011). Neslouží pouze k odesílání a čtení komunikace ze sítě, umožňuje také například skenovat porty na vzdálené stanici nebo simulovat webový server. NetCat lze také využít ke komunikaci pomocí dalších aplikačních protokolů, tzn. umožňuje simulovat klienta protokolem telnet nebo odesílat e-maily prostřednictvím SMTP. Podmínkou pro úspěšné spojení ale je, aby uživatel správně nadefinoval záhlaví na aplikační vrstvě, protože NetCat pouze vkládá surová data na vstupu do TCP, popř. aplikačního protokolu vyžádaným klientem. S tím souvisí také to, že přenos není šifrovaný. Pro bezpečný přenos dat je nutné navíc využít prostředků protokolu SSH. Současně je nutné připomenout, že textem výše nejsou vyčerpány všechny možnosti použití nástroje. Scapy Scapy je síťový generátor ovládaný z CLI, který uživateli umožňuje interaktivně manipulovat s pakety. Kromě toho, že vytvořené pakety generuje, také zachytává 33

http://joncraton.org/blog/46.

5.4

Zhodnocení dostupných generátorů

37

odpovědi. Lze ho využít na řadu klasických testů jako skenování portů a sítě, traceroute a různé druhy útoků (Scapy, 2011). Nástroj je napsaný v Pythonu a primárně je určený pro Linuxové distribuce, ale lze ho po instalaci řady prerekvizit34 používat i na MS Windows. Systém uživateli dovoluje upravit všechny atributy záhlaví PDU na vrstvách L2 – L4. Protokoly aplikační vrstvy lze simulovat správným tvarem textových dat, která se vkládají do paketu. Ukázka níže ukazuje, jak odeslat paket na cílovou stanici 192.168.1.2:80, s flagem SYN, který inicializuje TCP spojení. Server odpovídá paketem s flagy SEQ a ACK: >>> sr1(IP(dst="192.168.1.2")/TCP(dport=80,flags="S")) Begin emission: .Finished to send 1 packets. Received 2 packets, got 1 answers, remaining 0 packets >>

Jak je z ukázky patrné, Scapy je navrženo za účelem generování dílčích paketů, přičemž analyzuje i odpověď a z odchycených dat umožňuje dokonce i vytvářet statistiky a grafy. To je ve srovnání s řadou generátorů výhoda. Bohužel ale nedokáže generovat další pakety na základě analýzy odpovědi. Poté není pomocí tohoto nástroje možné například úspěšně ustanovit TCP spojení. Pro jeho využití výše se ale jedná o nejlepší volbu, proto je také na sectools.org zařazen mezi nejlepší nástroje pro administraci sítě.

5.4


Kapitola se zabývala problematikou existujících síťových generátorů. Účelem kapitoly bylo provést analýzu současného stavu a seznámit čtenáře s možnostmi dostupných nástrojů. Do analýzy byly zahrnuty pouze ty systémy, které bylo vhodné zmínit, protože plní všechny nebo alespoň některé ze stanovených požadavků na síťový generátor a bylo by možné je využít v další práci. V tab. 6 jsou vyjmenovány další síťové generátory a jejich základní vlastnosti, které najdou své uplatnění v řadě experimentů v síti35 . Jak vyplývá z analýzy výše a zejména tab. 5, není znám nástroj, který by v dostatečné míře plnil požadavky na síťový generátor pro síťovou laboratoř. Tab. 5 34

Viz zde: http://www.secdev.org/projects/scapy/doc/installation.html#windows. Další seznamy síťových generátorů a jím příbuzných nástrojů jsou dostupné na: http://wiki.wireshark.org/Tools, http://www.grid.unina.it/software/ITG/link.php, http://www.cs.columbia.edu/~hgs/internet/traffic-generator.html, http://www.icir.org/models/trafficgenerators.html. 35

5.4

38


srovnává generátory v pěti požadovaných kritériích. Nástroj musí být distribuovaný, musí využívat nativních serverových služeb36 , musí nabízet statistiky, implementovat multimediální přenosy (RTP) a zejména musí věrně napodobovat reálného uživatele. Jak je z tabulky patrné, žádný cenově dostupný systém není bez dalších úprav schopný generovat síťovou komunikaci takovým způsobem, aby reálně simuloval uživatele koncového uzlu, tedy pracoval jako reálné klientské aplikace. Nástroje jako Ostinato nebo DIT-G nabízí možnosti různého pravděpodobnostního rozložení pro generování dílčích paketů, neumožňují však realizovat takové spojení, které zajistí reálnou odpověď serveru. Jinými slovy nástroje generují pouze dílčí pakety, přičemž nedokáží následujícím paketem reagovat na přijatou odpověď. Pokud generátor odešle žádost o WWW stránku na server, ten nevrátí webovou stránku (HTTP/1.1 200 OK), pokud před tím nebude ustanoveno TCP spojení. Už ze specifikace požadavků na síťový generátor vyplývá, že vhodný nástroj by měl patřit do třetí skupiny dělení síťových generátorů, jak je uvedeno v sekci 4.1. Po prozkoumání dostupných systémů lze ale definovat řadu doporučení pro budoucí generátor. Díky analýze komponent aplikace D-ITG (obr. 11) jsou známy způsoby komunikace komponent již existujícího distribuovaného nástroje, což jsou užitečné informace pro návrh vlastního síťového generátoru. Program LanTraffic napověděl, jak efektivně vytvářet sadu (frontu) úkolů pomocí scénářů. Ostinato je inspirací v tom, jak efektně znázornit ovládání vzdáleného uzlu. Tab. 5: Srovnání testovaných generátorů Název

36

Distribuovaný

Receiver

Statistiky

RTP

Uživatel

Vyhovující nástroj

ANO

NE

ANO

ANO

ANO

Karat Omnicor Ostinato J-Meter Bit-twist D-ITG NetCat Scapy

ANO ANO ANO ANO NE ANO NE NE

NE ANO NE NE NE ANO NE NE

ANO ANO ANO ANO NE ANO NE ANO

NE NE NE NE NE ANO NE NE

NE NE NE ANO NE NE ANO NE

Nesmí implementovat vlastního příjemce komunikace (Receiver).

5.5

39

Analýza publikací

Tab. 6: Další síťové generátory Název Nemesis GSpoof3.0 Harpoon PktGen Mausezahn Rude and Crude

5.5

Analýza provozu NE ANO ANO NE ANO ANO

Popis Vhodný pro penetrační testy Nastavení od L2 po L4 a aplikačních dat Generuje pakety na základě NetFlow statistik Součást linuxového jádra Vhodný pro penetrační testy Podporuje pouze transportní protokol UDP

Analýza publikací

Po analýze existujících řešení síťových generátorů je nutné analyzovat akademické práce, které se zabývají tímto nebo podobným tématem. Poznatky z oblasti závěrečných prací vysokých škol v ČR a odborných publikací mohou být uplatněny v této závěrečné práci, popř. budou navržena doporučení pro další vývoj generátoru. V neposlední řadě má analýza za úkol zjistit, zda problém, kterým se závěrečná práce zabývá, již není vyřešen. Analýza zahrnuje závěrečné práce z vysokých škol ČR za poslední 4 roky a odborné publikace z licencovaných databází dostupných z Mendelu37 , konkrétně se jedná o databáze Scopus a Web of Knowledge. K vyhledávání byla použita klíčová slova: traffic generator, network traffic generator, network traffic, síťový generátor, generátor síťového provozu, síťový provoz. Závěrečná práce Měření Ethernetu Součástí zamýšleného generátoru síťového provozu musí být i paketový analyzátor, který odchytává pakety na rozhraní a poskytuje data pro výpočet statistik. Problematikou paketových analyzátorů se ve své diplomové práci zabývá Jelínek (2008). Cílem jeho práce je vytvořit nástroj pro sledování provozu a vytváření statistik pro diagnostiku sítě. Nástroj je vytvořen s využitím knihovny WinPcap, je tedy určen pouze pro platformu MS Windows. Vytvořený nástroj v podstatě následuje známý Wireshark, současně ale názorně popisuje možnosti knihovny libpcap. Modulární tester V roce 2008 vznikala v rámci tří závěrečných prací velmi zdařilá aplikace nazvaná „Modulární tester síťových aplikací/spojení“. Mrštíková (2009) v rámci diplomové práce vytvořila v jazyce C modulární síťový generátor určený k testování síťových charakteristik. Jak přibližuje obr. 12, základem nástroje je jádro, které přijímá konfigurační XML soubor s instrukcemi. Jádro je stejné jak na straně odesílatele (generátoru), 37

http://mendelu.cz/cz/sluzby_sz/icuk/databaze#abeceda

5.5

Analýza publikací

40

Obr. 12: Architektura testeru Převzato od Mrštíkové (2010)

tak na straně příjemce (analyzátoru). Podle potřeby se na jádro navazují moduly, které obsahují různé funkcionality. Jak Mrštíková (2009) udává, jedná se například o modul pro měření rozptylu a zpoždění, modul pro analýzu šířky pásma apod. Chytře je řešeno předávání paketů mezi moduly pomocí front, kdy moduly sekvenčně zapisují do datové části paketu informace pro moduly na druhém jádře potřebné pro analýzu (např. časové razítko apod.). Tímto tématem se zabývají ještě dvě bakalářské práce, konkrétně Beňo (2008) pracoval na vývoji vybraných modulů a Kuba (2010) se zabýval zefektivněním tvorby konfiguračních souborů a vytvořením GUI, které obaluje ovládání z CLI. Aplikace se jeví jako velmi zdařilá, zejména kvůli zvolené architektuře využívající modulů. Současně lze ale namítnout absenci vzájemné řídící komunikace mezi jádry, se kterou však autorka v dalším vývoji počítá. Aspektem, který je zde řešitelný až zbytečně složitě, je přenos skutečných aplikačních dat. Nástroj nabízí speciální modul, který dovoluje implementaci definic konkrétního aplikačního protokolu. Generátor navrhovaný v rámci závěrečné práce tuto problematiku řeší jiným způsobem (viz dále). Zátěžové testy webových serverů Zvláštní skupinu nástrojů pro generování síťového provozu tvoří aplikace pro zatěžovaní webových serverů. Tímto tématem se ve svých závěrečných pracích zabývají Vavřík (2010) a Sýkora (2011). Tyto aplikace jsou speciálním případem síťových generátorů, které se specializují na webové servery. Vzhledem k tomu, že snad v každé firmě existuje webový server nebo IS přístupný webovým rozhraním, jsou tyto nástroje dobře uplatnitelné. Obzvláště u velkých firem s často navštěvovanými weby, e-shopy nebo u informačních systémů univerzit je nutné testovat chování serveru ve vysoké zátěži. Úzká specializace těchto nástrojů na problém umožňuje lépe zpracovat danou problematiku. Často lze testovat i chování databázového serveru na

5.5

Analýza publikací

41

tvar a objem dotazů. Oba autoři ve svých pracech zmiňují nástroj J-Meter, který je nastíněn v analýze existujících nástrojů. Generátor vznikajicí v rámci této závěrečné práce se snaží problematiku pojmout komplexněji a kromě protokolů HTTP(S)38 umožnit realistický provoz i dalších protokolů, podle potřeb síťové laboratoře. Pro detailní testování pouze webových serverů a webových aplikací jsou ale vhodnější nástroje J-Meter nebo vytvořené autory Vavříkem (2010), resp. Sýkorou (2011). Platforma FPGA Jak je již v práci zmíněno, kromě softwarových generátorů existuje i skupina hardwarových, zpravidla dražších, ale zcela jistě rychlejších. Mezi tyto HW komponenty patří tzv. „programovatelné hradlové pole“ (FPGA, Field Programmable Gate Array). FPGA lze osadit na PCI sběrnici a naprogramovat mu činnost přímo na míru39 . Lze je také upravit jako generátor síťového provozu. Protože HW generátory dosahují vyšší účinnosti než softwarové, označují se také jako „high-speed packet generators“. Tímto tématem se ve svém příspěvku zabývají i Sanli a spol. (2011). Představují generátor nazvaný Fast Packet GENerator (FPGEN). Tato FPGA karta pracuje na frekvenci 125 MHz a obsahuje dvě fyzická rozhraní. V každém taktu je FPGEN schopný vytvořit jeden paket, to umožňuje na každém z rozhraní vytvořit 125 Mbps, celkem tedy 250 milionů paketů za sekundu. Tyto generátory se nejčastěji využívají k testovaní QoS v páteřních spojích a k výkonostním testům síťových prvků. Jsou však ve srovnání se softwarovými generátory limitovány svou problematickou přenositelností mezi fyzickými stroji.

38

JMeter zvládá i další protokoly jako POP3, IMAP nebo LDAP. Více o FPGA např. na: http://www.hw.cz/Teorie-a-praxe/Dokumentace/ART365-Nebojte-se-FPGA.html. 39

6

ANALÝZA GENERÁTORU

6 6.1

42

Analýza generátoru Případy použití generátoru

Při řešení experimentů v síťové laboratoři lze test vykonávat různými způsoby. Řadu základních testů lze provést pomocí standardních nástrojů operačního systému (např. ping, wget, telnet, ssh). Vznikají však situace, kdy pro ověření správného nastavení infrastruktury tyto nástroje nestačí. Jedná se zejména o případy, kdy cílem experimentu není ověřit výchozí nastavení sítě, ale zjistit, jak síť pracuje v reálném provozu, tedy při mnohem větší zátěži a hlavně zcela jiných charakteristikách provozu než v případě zatížení sítě jednorázovým ověřením spojení pomocí nástroje ping. Pro takové případy se nabízí využít síťové generátory. Následující text popisuje základní případy experimentů, pro které je využití generátoru síťového provozu, který dokáže simulovat reálného uživatele, nezbytné. Datové centrum

Obr. 13: Schéma síťové topologie datového centra.

Infrastruktura datového centra je běžně zatížena vysokým provozem, přičemž je vyžadována spolehlivá komunikace, odolná vůči neočekávaným výpadkům v síti. Ke zvýšení efektivity komunikace a zejména spolehlivosti slouží zdvojování serverů a prvků v síti (redundance). Způsobů, jak navrhnout infrastrukturu datového centra je celá řada. Obr. 13 je zjednodušený příklad takové topologie, jehož cílem je nastínit redundanci a Load-balancing (vyvažování zátěže). Díky zdvojení některých prvků je možné za běžného provozu rozdělovat zátěž podobně, jak ukazuje obr. 13. Virtuální server1 (VS1) pracuje na Hostu1 (fyzický server) a primárně využívá Switch1 (SW1), analogicky funguje komunikace VS2 přes

6.1

Případy použití generátoru

43

SW2. Redundance je užitečná i v případě neočekávaného výpadku jednoho zařízení, kdy převezme během určitého časového intervalu (Failover Time) jeho úlohu záložní prvek a snaží se nedostupné zařízení co nejdříve nahradit. V zásadě mohou v redundantní části nastat tři případy výpadku v síti: • výpadek L3 přepínače, • výpadek přenosového média, • výpadek fyzického serveru. V případě výpadku SW1, mohou virtuální servery na Hostu1 komunikovat přes SW2. Pokud bude přerušen spoj mezi SW1 a Hostem1, zastoupí ho druhý spoj mezi Hostem1 a SW2. Při výpadku samotného Hostu1 zpřístupní všechny na něm aktivní virtuální servery Host2. Poté budou oba VS aktivní na Hostu2. Při výpadcích vzniká Failover Time, během kterého je využívaná serverová služba nedostupná. Proto je nutné, aby generátor mj. sbíral data o provozu v síti tak, aby z nich bylo možné analyzovat: • Failover Time – časový interval mezi výpadkem v síti a opětovnou komunikací, • počet a procento ztracených paketů během Failover Time. Po výpadku síť zpravidla nedosahuje stejného výkonu jako před výpadkem. Protože jsou zbývající prvky zatíženy úkoly nedostupných prvků, je třeba měřit další exaktní veličiny, které naznačí, jak je síť schopna se vypořádat s vyjímečnou situací: • zpoždění (Latency) – měřeno pomocí Round-trip Time (RTT) – čas od odeslání paketu po příjem odpovědi, • procento ztrácených paketů (Packet Loss) – s růstem objemu přenášených dat odkládá přepínač (směrovač) přijaté pakety do front. Po jejich přetečení začnou síťové prvky některé pakety zahazovat, • rychlost stahování (Download Speed) (bps) – zvýšení využití šířky pásma (Bandwidth) může mít vliv na objem přenášených dat. Pro věrnou simulaci reálné zátěže infrastruktury je vhodné na pracovních stanicích virtualizovat další operační systémy se síťovým generátorem tak, aby generátor napodobil zátěž vytvářenou až stovkami koncových uživatelů. Nástroj, který dokáže zpracovat tyto charakteristiky, pak může sloužit k optimalizaci infrastruktury datového centra vzhledem k charakteristikám konkrétního provozu v síťi. Ze statistik o komunikaci v síti, posbíraných PŘED, BĚHEM a PO výpadku, lze podat doporučení i pro konkrétní případy v praxi. QoS V konvergovaných sítích, kdy jsou v síťi přenášena obvyklá data (WWW, email), tzv. „Best-effort Services“, a současně komunikace multimediálních služeb (VoIP, streamované video), tzv. „Differentiated Services“, pro které je nutné při nedostatečné šířce pásma zavádět QoS. Jak znázorňuje obr. 14, je třeba pomocí QoS garantovat dostatečnou šířku pásma, rychlost zpracování a tím pádem nízké zpoždění

6.1

Případy použití generátoru

44

Obr. 14: Vliv QoS na využívání šířky pásma.

pro multimediální služby. Tyto služby pro správnou komunikaci vyžadují stabilní a dostatečnou šířku pásma, naopak Best-effort datový přenos není zúžením šířky pásma výrazně neomezen. Správné nastavení QoS tedy umožní paralelní provoz všech typů dat v konvergované síti. V opačném případě nelze například streamované video plynule přehrávat. Schéma na obr. 14 znázorňuje test, kdy bude z LAN1 do LAN2 simulován webový provoz. Jako v případě datového centra bude k simulaci reálného provozu využito virtuálních stanic s generátory. Následně bude infrastruktura zatížena množstvím multimediálních dat simulovaných síťovým generátorem. Test bude proveden bez QoS a opakovaně po zavedení QoS. Síťový generátor bude kromě vytváření zátěže sítě snímat její činnost a nabízet statistiky komunikace PŘED a PO zavedení QoS. Wallace (2011), že stěžejní pro kvalitu multimediálních dat a tedy nutné měřit je: • zpoždění (Delay) – jednosměrné zpoždění. Pro úspěšnou komunikaci nesmí být větší než 200 ms, • procento ztracených paketů (Packet Loss) – ztrátovost paketů nesmí být větší než 1 %, • prodleva mezi pakety (Jitter) – pro srozumitelnou telefonní komunikaci je nutný konstantní jitter, zároveň nesmí být větší než 30 ms, • šírka pásma (Bandwidth) – teoreticky možné množství dat přenesených za jednotku času. Podobně jako v případě datového centra, generátor, který je schopný generovat provoz a současně nabídnout statistiky zpracovávající výše zmíněné veličiny, najde uplatnění nejen v laboratoři, ale i v praxi. Díky testům na řadě implementací QoS lze zvolit nebo navrhnout optimální v závislosti na charakteristikách provozu dané sítě.

6.2

Analýza jádra nástroje

45

Další modely Existuje ještě několik modelových situací, kde je síťový generátor užitečný. Za zmínku stojí ověření firewallových politik. Síťový generátor podle předem nastaveného scénáře provede test firewallové politiky. Výslednou komunikaci zobrazí ve statistice, kde příznak, zda bylo dílčí spojení úspěšné nebo ne, odpoví na otázku, zda je FW politika nastavena tak, jak bylo požadováno.

6.2


Dle specifikace požadavků a případů použití popsaných výše je na řadě zanalyzovat architekturu budoucího nástroje z pohledu komponent, jejich úloh v činnosti generátoru a vzájemné komunikaci. Komponenty nástroje Aby nástroj dokázal plnit všechny očekávané funkce, je nutné, aby byl distribuovaný, tedy bude vzájemně spolupracovat několik komponent rozdělených na několik strojů. Základní pohled vznikajícího síťového generátoru se skládá z těchto komponent (viz obr. 15): • Řídící prvek (Administrator – značeno A) • Generátor (Sender – značeno S ) • Analyzátor (Capture – značeno C ) • Výpočet statistik (Statistics – značeno ST )

Obr. 15: Schéma komponent a jejich komunikace.

Základem celého systému je Sender (S ) vytvářející síťový provoz, který reprezentuje činnost fyzického uživatele. Na rozdíl od ostatních síťových generátorů zde probíhá korektní komunikace mezi klientem (S ) a serverem (nativní síťové služby). Podporované protokoly jsou HTTP, POP3, SMTP, RTP a ICMP. Musí být ale zajištěno, aby byla aplikace rozšiřitelná o další protokoly. Data o komunikaci

6.2


46

sbírá analyzátor (C ), který shromažďuje jak odchozí komunikaci z generátoru, tak i příchozí. Současně je v některých případech nutné snímat i příchozí komunikaci na příjemci (viz 6.2). Komponenty S a C jsou řízeny pomocí řídícího prvku (A). Ten lze chápat jako rozhraní, ze kterého administrátor vzdáleně a přitom centrálně konfiguruje generátor. Řídící prvek předává S komunikační profil obsahující přesné informace o tom, jakou komunikaci a kdy vytvořit. Analogicky oznámí C, kdy a na jak dlouho je třeba začít odchytávat provoz. Řídící komunikace mezi komponentami A a S, resp. C bude probíhat pomocí TCP spojení, aby A mělo jistotu, že všechna data byla přenesena. Po skončení testu analyzátor zastaví snímání rozhraní a odchycenou komunikaci odešle komponentě výpočet statistik (ST ), která zpracuje přijatá surová data a k danému testu vyhodnotí odpovídající statistiky – viz modelové případy použítí výše. Zpracované statistiky jsou pak předány řídící komponentě, aby výsledky zobrazila uživateli, popř. nabídla export (CSV, XML atd.). Jako poslední prvek z obr. 15 zbývá objasnit zpětný kanál od komponent S a C vedoucí k A. Jedná se o logy, které jsou vytvářeny během činnosti komponent S a C. Ty jsou okamžitě po jejich vzniku odesílány pomocí UDP komponentě A, která je tak schopná již během testu odhalit aktuální chování systému a sítě. Pokud například dojde k výpadku webového serveru a žádost o HTML stránku bude neúspěšná, získá o tom komponenta A okamžitě přehled. Nebude již možné upravit následující generovanou komunikaci, protože komunikační profil již byl předán komponentám S, ale uživatel tak získá aktuální pohled na vývoj testu. Komunikační kanál je vyznačen odlišně od řídící komunikace vedoucí od A, protože se jedná o zcela odlišný druh a způsob komunikace. Zjednodušenou posloupnost činností generátoru v rámci jednoho testu lze popsat takto: 1. Vytvoření komunikačního profilu na A. 2. Odeslání odpovídajících úloh z profilu z A na dílčí S. 3. Odeslání instrukcí z A na všechny C. 4. Start testu v nastavený čas. 5. Generování komunikace z S a její odchyt C. 6. Konec testu v nastevený čas. 7. Přesun nasbíraných dat o vygenerované komunikaci z C do ST. 8. Vyhodnocení statistik v ST. 9. Prezentace výsledků v A. Komunikace a rozmístění komponent Protože je systém distribuovaný a jednotlivé komponenty nástroje budou spolupracovat vzdáleně po síti, vznikají otázky, jak zajistit, aby mohla mezi komponentami probíhat bezproblémová režijní komunikace40 a současně mohl v síti nerušeně 40

Patří sem řídící komunikace mezi A a S, resp. C, odesílání logů z S a C do A a přesun dat o nasbírané komunikaci z C do ST.

6.2

47


probíhat test. Aby byl experiment korektní, nesmí být šířka pásma zabírána jinou (režijní) komunikací. Pokud by i přesto režijní komunikace v testované síti probíhala, může nastat situace, kdy bude testem celá šířka pásma obsazená (tzv. „saturace pásma“) a režijní komunikace by mezi komponentami neprocházela. Vznikají tedy dva problémy spojené s distribuovanou činností generátoru v rámci jedné sítě: • hrozba saturace šírky pásma a následně nemožná komunikace komponent, • ovlivnění testu režijní komunikací. Z výše uvedených důvodů je nutno uvažovat dvě různé podoby, kudy mohou komponenty komunikovat: • využití oddělené sítě pro režijní komunikaci, • ponechání režijní komunikace v testované síti. Navíc lze z důvodů popsaných níže uvažovat další dva způsoby, jak v testované síti rozmístit jednotlivé komponenty: • Rozmístění analyzátorů (C ) pouze na odesílatele, stroje s komponentou Sender (S ), • umístění komponenty (C ) na všechny komunikující uzly testované sítě. Než přistoupíme k představení jednotlivých návrhů, je vhodné představit si možné počty komponent v rámci jednoho generátoru. Počet instancí jednotlivých komponent se liší podle jejich druhu. Generátor obsahuje vždy pouze jednu komponentu A a ST. Komponent S je právě tolik, kolik je koncových hostů (fyzických nebo virtuálních), které mají v rámci testu generovat provoz, přičemž v každém OS daného hostu je spuštěna právě jedna instance S. Komponent C je právě tolik, kolik je hostů, na kterých si přejeme snímat provoz, přičemž na každý takový uzel je umístěna právě jedna instance. Každý uzel s komponentou S musí mít i komponentu C 41 , z toho plyne, že C musí být alespoň tolik, kolik je S. Zpravidla se v práci pro názornost počítá s tím, že řídící stanice bude sloužit jen pro ovládání částí S a C a nebude se aktivně zapojovat testu (viz níže). Nic však nebrání tomu, aby na jednom PC pracovaly současně všechny čtyři části generátoru. Mezi počty jednotlivých částí generátoru ale musí platit určité vztahy. Pokud označíme Sm jako množinu všech komponent S generátoru a analogicky množiny dalších komponent (Cm , Am , STm ), můžeme definovat tyto vztahy: |Am | = |STm | = 1 |Sm | ≥ 1 |Sm | ≤ |Cm | 41

Pokud chce mít uživatel přehled o všech datech, které byly celým systémem vygenerovány, je nezbytné, aby se na každém hostu s komponentou S nacházela i C. Kvůli vzájemné nezávislosti dílčích komponent však toto pravidlo není nijak zajištěno. Opět záleží na uživateli, popř. na „frontendu“, jaká pravidla zavede.

6.2


48

Využití jediné (in-band) sítě Jednodušší varianta toho, jak realizovat režijní komunikaci v rámci generátoru, je ponechat ji v testované síti. To s sebou přináší nevýhodu zkreslení výsledků a potenciální riziko pádu režijní komunikace. Naopak nespornou výhodou jsou menší požadavky na přípravu topologie. Tímto způsobem pracují i nástroje Ostinato a DIT-G popisované v kapitole 5. V řadě experimentů nemusí být vždy na obtíž, pokud režijní komunikace bude protékat testovanou sítí, pokud nemá vliv na věrohodnost testu a nehrozí saturace šířky pásma. Analyzátor provozu ale musí být schopný tuto komunikaci odfiltrovat, aby nezkreslila některé charakteristiky jako například zátěž trasy nebo propustnost, naopak některé charakteristiky jako ztrátovost nebo zpoždění mohou být ovlivněny režijní komunikací nepřímo také, ale jejich hodnoty od režijní komunikace očistit nelze. Je tedy na uživateli, aby se podle cíle a obsahu konkrétního testu rozhodl pro tuto topologii.

Obr. 16: Režijní komunikace v in-band síti s C na všech aktivních uzlech.

Dále je nutné rozlišovat dvě možnosti rozložení komponent v rámci testované sítě. Obr. 16 popisuje situaci, kdy testovaná síť obsahuje jednu řídíci stanici (komponenty A a ST ), dále dvě stanice, které jsou určeny ke generování komunikace (obsahují S ) a na kterých se tedy musí nacházet i C pro snímání komunikace. Dále je v sítí jeden server, který poskytuje služby do sítě přes rozhraní NIC1. V tomto případě je i na serveru přítomna komponenta C. O tomto příkladu lze tedy říci, že všechny uzly komunikují jedním rozhraním NIC1 a kromě řídící stanice obsahují část C jak klienti, tak server. Při rozmístění komponent generátoru v této podobě je možné měřit veškeré výše definované síťové charakteristiky, protože jsou snímány všechny komunikující dvojice v rámci sítě. Lze tak měřit například jednosměrné zpoždění i charakteristiky spojené s UDP protokolem, protože i když je nepotvrzovaný, je úspěšné doručení ověřitelné podle odchytu na straně příjemce. Druhá možnost osazení komponent je jednodušší na správu, avšak nabízí i menší množinu dostupných funkcí. Znázorňuje ji obr. 17. Narozdíl od předchozího rozložení

6.2


49

se zde nachází komponenty C pouze na uzlech obsahujících část sender (S ). Je zřejmé, že tak je možné změřit charakteristiky sítě pouze omezeně. Protože nemáme možnost vidět, zda a kdy byl paket doručen na příjemce, nelze počítat například ztrátovost na UDP, jednosměrné zpoždění nebo jitter. Naopak lze i v této situaci počítat obousměrné zpoždění, ztrátovost paketů na TCP (díky přeposílání ztracených paketů), zátěž a propustnost rozhraní, které generuje provoz.

Obr. 17: Režijní komunikace v in-band síti s C pouze na S.

Využití režijní (out-of-band) síťě Druhá varianta, kudy realizovat režijní komunikaci, přichází s využítím další režijní sítě, která oddělí veškerou režijní komunikaci z testované sítě. Podobně jako v předchozí variantě, i zde je možno komponenty v testované síti rozmístit dvěma způsoby, které však kvůli režijní síti získávají další specifika přiblížené na obr. 18 a 19. Aby bylo zajištěno, že testovaná síť nebude zatěžována režijní komunikací, znamená to, že nesmí tento druh paketů do testované sítě vůbec vstoupit. To lze zajistit pouze tak, že se uzly obsahující komponenty Sender nebo Capture připojí do dvou sítí současně – do testované a režijní. Jinými slovy je nutné vybavit uzly obsahující komponenty S nebo C dvěma síťovými adaptéry. Takový uzel potom vysílá generovanou komunikaci komponentou S do in-band testované sítě přes rozhraní NIC1, přičemž veškeré instrukce budou přicházet z out-of-band režijní sítě přes rozhraní NIC2. Analogicky v případě komponenty C. Ta bude odchytávat provoz na testovaném rozhraní NIC1, ale instrukce pro odchyt, logování i následný přesun nasbíraných dat z odchytu budou procházet rozhraním NIC2 a režijní sítí. Tím bude zajištěno, že režijní komunikace vůbec do testované sítě nevstoupí. Pokud aplikujeme dvojí rozložení komponent v testované síti z předchozí varianty, vzniknou situace z obr. 18 a 19. Jejich možnosti výpočtu síťových charakteristik jsou stejné, probíhá-li režijní komunikace v testované nebo ve zvláštní oddělené

6.2


50

Obr. 18: Režijní komunikace v out-of-band síti s C pouze na všech aktivních uzlech.

síti. V prvním případě rozložení umístíme komponenty C na všechny aktivní prvky v síti, tedy jak na všechny hosty, kde je S, tak i na ostatní. Tato kombinace je optimálním řešením, jak připravit topologii a rozprostření komponent v testované síti. Řešení zajistí, že není nijak ohrožena řežijní komunikace generátoru, protože je zcela oddělena, a současně je zajištěna korektnost testu (testovanou sítí prochází pouze generovaná komunikace) a současně lze měřit všechny síťové charakteristiky, protože jsou snímána všechna rozhraní všech hostů.

Obr. 19: Režijní komunikace v out-of-band síti s C pouze na S.

Druhý příklad (obr. 19) opět umísťuje komponenty C pouze na uzly se Sendery. Opět jsou zajištěny výhody spojené se zavedením řežijní sítě. Přínosem ve srovnání s předchozím řešením je menší potřebný počet strojů vybavených více než jednou NIC (komponenty C se nacházejí pouze na S ), menší je však i množina zjistitelných charakteristik. Se zapojením řežijní sítě je spojeno složitější směrování paketů na hostech s více rozhraními. Může zde nastat problém v nesprávném nastavení výchozí brány, který

6.2

51


Obr. 20: Příklad testované sítě složené z více podsítí.

je vhodné osvětlit na příkladu (obr. 20). Jedná se o topologii, kde existuje režijní sít 192.168.0.2/24 a testovaná síť 172.16.0.0/16, která rozdělena na dvě podsítě 172.16.100.0/24 a 172.16.200.0/24. PC, kde je umístěný Sender, má přístup do režijní sítě a testované podsítě 172.16.100.0/24. Pokud je v takovém případě výchozí brána PC s komponentou (S ) (viz směrovací tabulka níže) nastavena na uzel v režijní síti (192.168.0.2) a Sender odešle paket na server 172.16.200.5, bude paket chybně směrován na výchozí bránu v režijní síti. Tedy místo na rozhraní NIC1 by paket putoval chybně na NIC2. Proto je nutné, aby byla adresace rozhraní a výchozí brána na všech uzlech správně nastavena. Kernel IP routing table Destination Gateway 172.16.100.0 0.0.0.0 192.168.0.0 0.0.0.0 0.0.0.0 192.168.0.2

Genmask 255.255.255.0 255.255.255.0 0.0.0.0

Flags U U UG

Metric 0 0 0

Ref 0 0 0

Use 0 0 0

Iface eth1 eth0 eth0

7

NÁVRH A POPIS IMPLEMENTACE

7

52

Návrh a popis implementace

7.1

Návrh jádra systému

Popis tříd a jejich úloh V této sekci budou popsány UML diagramy dvou základních komponent jádra generátoru – Sender (příloha D) a Capture (příloha E). Jedná se o diagramy tříd, které se snaží zachytit základní kostru obou komponent. Současně již byly do diagramů zavedeny některé návrhové vzory usnadňující implementaci a práci s nástrojem. Základem Senderu je stejnojmenná třída (obsahující metodu main), která vytváří dva objekty, které jsou svázané s programem po celou dobu jeho běhu. První, CPServerTCP, implementuje TCP server, spouštěný jako nové vlákno a čekající na instrukce v podobě komunikačního profilu od řídídí stanice (A). Komunikační profil implementuje rozhraní java.io.Serializable, které zajistí serializaci daného objektu při přenosu po síti. Navržený komunikační protokol pro výměnu zpráv mezi řídící stanicí a Senderem, resp. Capture je popsán dále. Jakmile CPServerTCP přijme komunikační profil, vytvoří objekt třídy DilciCP42 a poté ho předá jediné instanci třídy Logika. Reprezentuje funkcionalitu, která má na starost zpracování komunikačního profilu. Jinými slovy, podle instrukcí z profilu se ve správný čas pomocí metody provedUkol objektu třídy Protokoly předají instrukce potomkům třídy Protokol. Tito potomci jsou vytvářeni v nových vláknech třídy Ukol. Každý objekt třídy Ukol je v požadovaný čas volán jako nové vlákno objektem Timer. Tím je zajištěno, že se každý úkol (jeden záznam z profilu) vykoná v odděleném vlákně a hlavní program může fungovat bez prodlev dále. Potomci třídy Protokol obsahují konkrétní implementace daného protokolu. Objekt třídy Logika přistupuje k objektu třídy Protokoly prostřednictvím rozhraní IntProtokol. To zajišťuje, že se instrukce z komunikačního profilu předávájí v metodě provedUkol v podobě objektu některého z potomků třídy ProtokolConfig. Každý protokol má totiž jinou množinu prvků, kterými se konfiguruje jeho úkol. Všechny významné události během běhu komponenty Sender jsou pomocí objektu třídy LogClientUDP odesílány pomocí nespolehlivého ale rychlého transportního protokolu UDP na komponentu A generátoru. Tak jako u předchozího diagramu, i v případě komponenty C (příloha E) je základem třída Capture. I ananalyzátor musí přijímat instrukce od řídící stanice (A), proto je v celém běhu programu aktivní objekt třídy CPServerTCP. Aby mohl neustále poslouchat na smluveném portu, je vytvářen jako nové vlákno. Přijímá instrukce mj. o tom, kdy a na jak dlouho odchytávat provoz. Z přijatých informací vytvoří objekt třídy Filtr. Ten opět implementuje rozhraní java.io.Serializable, aby mohl být tento objekt snadno přenositelný v síti. Filtr je pak předán instanci třídy Logika. Tak jako u Senderu, kdy Logika vytvoří úkol 42

Každý Sender dostane pouze tu část z celého komunikačního profilu, která se týká jen jeho (více v popisu implementace).

7.1


53

zavoláním metody provedUkol objektu Protokoly, kde se rozhoduje o tom, kdy a kterou metodu kterého protokolového objektu zavolat, zde v Capture Logika řídí, kdy spustit a ukončit odchyt a kam předávat výsledky odchytu. Odchyt spouští prostřednictvím objektu CaptureEngine reprezentující samotný nástroj odchytávající provoz. Ten vytváří nové vlákno Ukol, který v požadovaný čas vytvoří Timer. Data o odchycené komunikaci představuje objekt třídy PCAPsoubor. Ten po ukončení testu převezme PCAPClientTCP. Jeho úkolem je prostřednictvím sítě přenést objekt PCAPsoubor na komponentu ST pomocí TCP, kde se zpracovávají statistiky. Navíc i zde se nachází třída LogClientUDP odesílající logy vygenerované během provozu komponenty. Analytické diagramy komponent A a ST nejsou v práci analyzovány, protože se již nejedná o jádro systému. Je ale zřejmé, že obě komponenty musí implementovat zakončení kanálu pro komunikaci mezi ostatními částmi systému: CPClientTCP na A pro odesílání instrukcí komponentám S a C, LogServerTCP na A pro příjem logů a TCPServer na ST pro příjem dat z odchytu od C. Tyto třídy budou pro komponenty frontendu připraveny. Návrhové vzory Při návrhu komponent S a C považované za jádro generátoru byly aplikovány návrhové vzory, které byly promítnuty již do UML diagramů v předchozí sekci. Celkem byly při návrhu uplatněny tři návrhové vzory: Singleton, Messenger a Bridge. Účelem vzoru jedináček (Singleton) je zajistit, aby třída, na kterou je aplikován, nemohla mít více, než jednu instanci. To lze zajistit skrytím konstruktoru a metodou getInstance, která vrací stále stejnou instanci. To je v rámci Senderu třeba provést u tříd Logika (zpracování komunikačního profilu má na starost pouze jeden objekt), Protokoly (jediný objekt se stará o vytváření nových vláken pro konkrétní úkol a protokol) a CPServerTCP (postačuje jeden server v rámci komponenty). Poslední jmenovaný je navíc vytvářen jako nové vlákno. Analogicky u Capture se jedná o třídy LogikaF a FiltrServerTCP. Dalším uplatněným vzorem je Messenger. Jedná se jednoduše o to, že předáváme mezi dvěma metodami kontejner obsahující množinu parametrů. Předají se tak všechny naráz. V případě generátoru jsou třídy typu Messenger DilciCP (S ) a Filtr (C ). Nepředávají si je ale metody přímo, posílají se po síti mezi objekty implementující TCP klienta na řídící stanici (A) a objekty reprezentující TCP servery na S, resp. C (obr. 21). To usnadňuje práci s předáváním instrukcí. Ty se zapouzdří do jednoho objektu, který je serializován a v binární formě přenesen po síti. Tato problematika se týká řídících instrukcí – na schématu z obr. 15 se jedná o plné červené šipky. Třetím vzorem je Bridge. Jak se zmiňuje Dvořák (2005), vzor řeší problém oddělení rozhraní třídy od její vlastní implementace, aby obě tyto části mohly být vytvářeny nezávisle na sobě. Tento princip zajistí, že může být změněna implemen-

7.1


54

Obr. 21: Princip vzoru Messenger.

tace třídy, aniž bychom měnili kód klienta43 . To se týká třídy Protokoly (příloha D), která musí nabízet třídě Logika jednotné rozhraní bez ohledu na konkrétní protokol. Na tuto práci bude navázáno další závěrečnou prací, kde bude pravděpodobně upravena struktura komunikačního profilu. Proto musí třída Protokoly nabízet rozhraní (API), se kterým lze v rámci třídy Logika později pracovat. Základem rozhraní je několikrát přetížená metoda provedUkol ve třídě Protokoly komponenty S. Mj. je jedním z parametrů metody konfigurace protokolu dílčího úkolu. Bez ohledu na konkrétní protokol, vždy danou konfiguraci protokolu pro konkrétní úkol v metodě provedUkol reprezentuje abstraktní třída ProtokolConfig. Až za běhu programu lze rozhodovat, jakého konkrétního potomka konfigurace v metodě předat. Je tak zajištěno, že metoda provedUkol se nemusí nikdy měnit a je tak zajištěna jednoduchá rozšiřitelnost o další protokoly. Popis implementovaných protokolů Jak je již patrné z diagramu tříd (příloha D), byla v rámci závěrečné práce implementována pětice generovaných protokolů: HTTP, SMTP, POP3, ICMP a RTP. V implementaci protokolu HTTP se v podstatě jedná o vytvoření webového klienta v Javě, který se dotazuje na server na základě definované URL. Veškerý přijímaný obsah však klient zahazuje. Jako pseudoklientské aplikace je implementováno i zpracování protokolů SMTP a POP3. SMTP odešle uživatelem předloženou emailovou zprávu (lze i s přílohou) do emailové schránky na definovaném serveru. POP3 je schopen ze zadané emailové schánky přijmout poštu včetně příloh. Opět, stejně jako HTTP klient, stažené zprávy neukládá. Implementace ICMP protokolu využívá systémový nástroj ping. Implementace protokolu RTP nereprezentuje klienta ale server, který streamuje na specifikovanou URL vybranou MP3 nahrávku. Použité knihovny a nástroje V Senderu, jak je naznačeno výše, je ke generování ICMP zpráv využíván externí systémový nástroj ping. Slabá podpora L3 vrstvy ISO/OSI v Javě totiž neumožňuje 43

V tomto případě je klient třída Logika.

7.1


55

uspokojivě vytvořit kvalitativní ekvivalent ke známému nástroji operačního systému. V implementaci protokolů POP3 a SMTP byl využit framework Java Mail (verze 1.4.4). Při práci s přenosem multimediálních dat je v Javě vyžadován Java Media Framework, použitá verze je 2.1.1. Druhý externí nástroj využívaný v generátoru je součástí komponenty C. Jak již bylo předesláno v teoretické části práce, soubor programů pod souhrnným názvem Wireshark nabízí efektivní způsob, jak snímat síťový provoz na rozhraní a dále s ním pracovat. Proto je konkrétně nástroj tshark využíván komponentou C pro snímání provozu. Protokol režijní komunikace Navrhovaný nástroj je distribuovaný – jednotlivé části tedy spolu komunikují vzdáleně. Je tedy vhodné, ještě před implementačními detaily komponent, definovat jednotlivé datové toky režijní komlunikace komponent jádra (S a C ) s ostatními částmi generátoru.

Obr. 22: Princip výměny zpráv řídící komunikace (z A na S, resp. C ).

V životním cyklu jednoho testu generátoru nejprve musí komponenta A rozdat úkoly jádru generátoru. To znázorňuje obr. 22. Komponenta A pomocí TCP klienta naváže spolehlivé spojení s TCP serverem (S nebo C ). Komponenty jádra ale mohou být zaneprázdněny jiným testem (doposud probíhající předchozí test), proto klient nejprve pošle žádost o spojení na server (značeno SYN). Server odpoví ACK, pokud je dostupný nebo odpoví příznakem NACK (NotACK) a časem, kdy bude komponenta opět dostupná plnit další úkoly44 . Pokud server odpoví kladně (ACK), odešle mu klient komunikační profil (CP), resp. filtr (F). Tím tato komunikace končí45 . Poté, co test skončí, odešlou všechny komponenty C (TCP klienti) svůj odchyt na ST (TCP server). Zde není nutné vyjednávat, zda server požadavky klientů přijme, musí jednoduše obsloužit všechny. Proto celou komunikaci tvoří pouze přenesení souboru s odchytem z analyzátoru provozu na komponentu statistik (obr. 23). Během činnosti generátoru jsou vytvářeny logy, které jádro generátoru odesílá na centrální bod. Ten v generátoru obstarává komponenta A. Z logů lze vyčíst řadu 44

Nejen z tohoto důvodu je nutné, aby měly prvky v síti synchronizovaný čas. Impementace řežijní komunikace předává mezi komponentami celé objekty, reprezentaci dat v paketu a zaopuzdření do TCP řeší na nižší úrovni Java. 45

7.1


56

Obr. 23: Režijní datový tok od C k ST.

pro uživatele užitečných informací a samotná aplikace (komponenta A) je může integrovat do systému upozornění. Protože logů vzniká poměrně hodně a případná ztráta dílčího logu není pro chod nástroje kritická, může být přenos po síti realizován pomocí nespolehlivého protokolu UDP (obr. 24).

Obr. 24: Logování komponent S a C.

Aby bylo možné s logy na řídící stanici dále pracovat, je nutné, aby měly pevnou syntaxi. Možných řešení je jistě řada, ale nástroj aktuálně používá tuto syntaxi logu: timestamp:testSrcIP:componentName:ClassName:Error:Event

Časové razítko je okamžik vzniku logu, testSrcIP značí zdrojovou testovanou IP adresu, ze které log přišel. Nejedná se ale o případné druhé fyzické rozhraní hosta (např. červené NIC2 z obr. 18), ze kterého byl opravdu log odeslán na server, jedná se o testované rozhraní daného uzlu (např. modré NIC1 z obr. 18). Princip adresace na obou rozhraních může být zcela odlišný a pokud by se jednalo o IP NIC2, ztrácí uživatel přehled, o jaké testované rozhraní se jedná. Dalším parametrem logu je componentName označující název komponenty, třída informuje, v jaké třídě přesně log vznikl v rámci komponenty, předposlední parametr je příznak, zda je log chybový nebo informativní a poslední parametr již obsahuje samotnou zprávu. Jediný druh režijní komunikace, který probíhá během testu a může ho tedy ovlivnit, je odesílání logů. Je vhodné nastínit, jak velký objem dat tato komunikace představuje. Každý log je vložen do jednoho UDP datagramu, který nese pouze text logu. Dle zkušeností při testování je přibližná velikost datagramu včetně záhlaví 150 B. Dále záleží na frekvenci, s jakou jsou logy generovány, tzn. na obsahu komunikačního profilu. Komponenta C generuje minimum logů, naopak komponenta S odesílá log po každém úspěšně provedeném úkolu. Pokud například bude S prokolem RTP přenášet MP3 nahrávku, odešle se log až po konci přenosu. Analogicky případě, kdy S odešle během minuty 1 000 HTTP Requestů, vygeneruje se 1 000 logů. Definovaná režijní spojení v této sekci nejsou v rámci generátoru všechna. Další bude muset existovat mezi komponentami A a ST. Obě komponenty se totiž mohou nacházet na různých hostech46 . Není ale vhodné ji definovat před návrhem frontendu. 46

V případě lokálního umístění pomocí loopback adresy.

7.2

7.2

Popis implementace

57

Popis implementace

Implementace režijní komunikace Pro přenos instrukcí (komunikačního profilu) mezi komponentami byl vytvořen balík tříd pojmenovaný mendelu.pef.dp.xzach.serializable, ten mj. obsahuje třídy CP, DilciCP, Zaznam a Filtr. Tvoří základ pro přenos instrukcí po síti mezi komponentami A a S, resp. C. První tři třídy slouží ke konstrukci komunikačního profilu. Ten reprezentuje třída CP, která se skládá ze startovního času celého testu a z několika objektů třídy DilciCP, reprezentující úkoly pro dílčí Sendery. Množina instrukcí v dílčím profilu je tvořena objekty třídy Zaznam. Vztah těchto tří tříd znázorňuje diagram na obr. 25. Při rozesílání komunikačního profilu na komponenty S je pro komunikaci s každou komponentu vytvořeno vlastní vlákno, které předá startovní čas a objekt třídy DilciCP. Naopak jediný objekt třídy Filtr postačí k přenosu instrukcí pro Capture. Atributy této třídy jsou: IP adresa serveru komponenty ST, kam po testu odešle nasnímaná data, dále je to startovní čas testu, délka trvání a také počet bytů, které u každého odchyceného paketu uchovávat. Velikost PCAP souboru s nasnímanými daty o provozu roste úměrně s velikostí provozu na sledovaném rozhraní. U testů, kde testovaný provoz obsahuje vysoký počet objemných paketů, bude i PCAP soubor zbytečně velmi velký. Pro následné výpočty statistik jsou důležitá pouze záhlaví protokolů. Nástroj tshark proto umožňuje snímat pouze definovanou velikost z každého odchyceného paketu.

Obr. 25: Vztah tříd pro přenos komunikačního profilu.

Na klientu i serveru pro přenos instrukcí se v implementaci postupuje stejným způsobem, jako je popsáno v technologickém aparátu s tím rozdílem, že je nutné upravit vstupní a výstupní proudy pro práci s objekty. Část metody TCP serveru níže přibližuje vytvoření vstupního, resp. výstupního proudu a načtení, resp. zápis objektu na straně serveru:

7.2

Popis implementace

58

ObjectInputStream inFromClient = new ObjectInputStream(connectionSocket.getInputStream()); ObjectOutputStream outToClient = new ObjectOutputStream(connectionSocket.getOutputStream()); DilciCP cp = (DilciCP) inFromClient.readObject(); outToClient.writeObject(new ACK(true));

Po skončení testu odešle Capture vytvořený PCAP soubor na server (ST ). Server pracuje obdobně jako je již zmiňováno výše, pouze s tím rozdílem, že vstupní proud neinterpretuje jako objekt, ale jen jako proud bytů, který ukládá do bufferu a po 1 kB zapisuje do souboru. Ten pojmenuje podle IP adresy komponenty C, která soubor posílá. Narozdíl od TCP serverů pro příjem instrukcí na komponentách S, resp. C, je implementace tohoto serveru kromě typu I/O proudů rozdílná v tom, že je pro každé navázané spojení vytvářeno nové vlákno pro rychlejší odbavení při posílání řady objemných PCAP souborů. Klientská strana naopak načítá vytvořený PCAP soubor do bufferu po 1 kB a odesílá ho na server. Následující ukázka naopak přibližuje část serverové metody listen(): ServerSocket serverSocket = new ServerSocket(port); while (true) { Socket socket = serverSocket.accept(); File file = new File(socket.getInetAddress().toString()+".pcap"); new Vlakno(socket, file).start(); //implementuje zápis do souboru }

Poslední část režijní komunikace komponent tvoří logy. Jsou generovány v komponentách S a C voláním metody send objektu LogClientUDP. Ten sestaví textový řetězec za dodržení syntaxe definované výše v sekci 7.1 a příkazy uvednými níže (pouze část metody) odešle log na server. Ten přijatá data přetypuje na datový typ String a předá ho dalšímu zpracování47 : DatagramSocket clientSocket = new DatagramSocket(); byte[] data = textLogu.getBytes(); // převedení textu na pole bytů DatagramPacket packet = new DatagramPacket(data, sendData.length, InetAddress.getByName(udpServerIP), udpServerPort); clientSocket.send(packet); clientSocket.close();

Atributy generovaných protokolů a třída ProtokolConfig Aby mohl Sender vygenerovat požadovaný provoz, musí mu být předána množina atributů, která jednoznačně definuje protokol, který se má generovat a jeho parametry: • HTTP – cílový host, cílový port, cesta k souboru (/index.html), • POP3 – cílový host, cílový port, emailová schránka, heslo, 47

V současné podobě ho pouze vypíše.

7.2

Popis implementace

59

• SMTP – cílový host, cílový port, odesílatel, příjemce, předmět zprávy, text zprávy, příloha, • RTP – cílový host, cílový port, přenášený MP3 soubor, • ICMP – cílový host, velikost, paketu, počet paketů, interval mezi pakety. Až na protokol ICMP mají všechny protokoly společné dva atributy – cílový host a port. Abstraktní třída ProtokolConfig tedy implementuje tyto dva povinné atributy a její potomci zapouzdřují specifika konkrétního protokolu. Skupina těchto tříd tedy slouží k uchování konfigurace pro konkrétní protokol v rámci dílčího úkolu. Parametry konfigurace jsou předávány v konstruktorech těchto konfiguračních tříd. Například nastavení protokolu HTTP v rámci jednoho úkolu (jednoho záznamu v komunikačním profilu) lze definovat pomocí těchto konstruktorů třídy HTTPConfig (host musí být nastavený vždy, port je implicitně nastaven): ConfigHTTP(String host, int port, String cesta) ConfigHTTP(String host, String cesta) ConfigHTTP(String host, int port)

Rozhraní IntProtokol Rozhraní IntProtokol je implementováno třídou Protokoly, aby definovalo jednotný přístup (API) k definici úkolů Senderu v třídě Logika na základě přijatého profilu. Rozhraní tvoří metoda setStartTime, které se v parametru předá z komunikačního profilu start celého testu, a třikrát přetížená metoda provedUkol. V první variantě jsou její parametry protokol, který očekává jednu z veřejných konstant třídy CP definující protokol. Druhým parametrem je objekt třídy ProtokolConfig nebo jeho potomek (viz předchozí odstavec) a poslední parametr startTime znamená relativní čas spuštění úkolu v milisekundách. Pokud například startTime nabyde hodnoty 3 000, znamená to, že tento dílčí úkol bude aktivován 3 sekundy po začátku testu. V druhé variantě přetížené metody je navíc parametr pocetOpakovani, který, jak je zřejmé z názvu, definuje, kolikrát se má daný úkol v rámci jednoho vlákna vykonat (například dvakrát po sobě přistoupit na www.google.com). Třetí varianta přetížení metody provedUkol vyžaduje parametr delay, který značí, jak dlouhé intervaly má generátor vkládat při vícenásobném vykonávání úkolu (pocetOpakovani > 1). public void setStartTime(long startTime); public void provedUkol(int protokol, ProtokolConfig config, long startTime); public void provedUkol(int protokol, ProtokolConfig config, int pocetOpakovani, long startTime); public void provedUkol(int protokol, ProtokolConfig config, int pocetOpakovani, int delay, long startTime);

Implementace HTTP Třída HTTP představuje jednoduchý webový prohlížeč, který po vytvoření naváže se serverem TCP spojení a stáhne soubor (ale nikam neukládá) dle předložené URL

7.2

60

Popis implementace

adresy. O úspěchu či neúspěchu operace je prostřednictvím zprávy ve formě logu informována komponenta A. Jakmile je přenos u konce, ukončí se TCP spojení a vlákno se buď ukončí, nebo pokračuje po uplynutí delay další iterací podle hodnoty pocetOpakovani definované v metodě provedUkol třídy Protokoly. Implementace POP3 Protokol POP3 je implementován jako emailový klient, který nejprve naváže spojení se serverem, poté získá přístup do emailové schránky a nakonec získá odkaz na zprávy. Nejsou ale nikam ukládány, je pouze vynucen jejich přenos po síti. Stejně jako v případě HTTP je o úspěšnosti úkolu vytvořen a odeslán log. Úkol v rámci POP3 lze také v jednom vlákně spustit několikrát za sebou. Následuje ukázka konstruktorů třídy ConfigPOP3, kterou lze předávat nastavení pro dílčí úkol48 (blíže práci s POP3 v Javě popisuje Harold (2005), s. 653): ConfigPOP3(String host, int port, String username, String password) ConfigPOP3(String host, String username, String password)

Implementace SMTP SMTP navazuje spojení velmi podobným způsobem jako POP3. Odesílaná zpráva je poté vytvořena jako objekt třídy MimeMessage, do kterého jsou postupně přidány atributy hlavičky odesílané zprávy. Metodou setContent je nakonec do zprávy přidán objekt třídy Multipart, která zajistí, že může zpráva současně obsahovat text i přílohu. Více o implementaci SMTP protoku píše Harold (2005) od str. 644. I objekt SMTP komponenty S je schopný vykonat jeden úkol v rámci vlákna opakovaně. Ke konfiguraci úkolu slouží tyto konstruktory: ConfigSMTP(String String ConfigSMTP(String String

host, int port, predmet, String host, int port, predmet, String

String odesilatel, String prijemce, text, String fileName) String odesilatel, String prijemce, text)

Implementace RTP

Obr. 26: Procesní model vytvoření RTP datového toku. Převzato od Olsena (2002) 48

Opět platí, že pokud není specifikován port, zvolí se výchozí (well-known).

7.2

Popis implementace

61

Při implentaci RTP bylo postupováno podle návodu, který uvádí Olsen (2002). Jak již bylo předesláno v teoretické části práce, proces streamování multimediálních dat má v JMF podobu přibliženou na obr. 26. Vstupní část tvoří MP3 nahrávka, ta se v procesní části převede na proud RTP dat, který je v poslední fázi odesílán na adresu příjemce. Z pohledu implementace je základem procesní fáze objekt třídy Processor, kterému je metodou setDataSource(DataSource source) předán odkaz na MP3 soubor. Výstupní část reprezentuje objekt třídy DataSink, který odesílá RTP data na URL adresu – objekt třídy MediaLocator. URL adresa musí být ve tvaru rtp://adresa:port/content-type, přičemž content-type je v případě přenosu zvuku vždy audio. Před samotným spuštěním přenosu je nutné nastavit ještě další parametry, například typ nebo formát přenášených dat. Stejně jako u všech předchozích protokolů, lze i RTP úkol v rámci vlákna spouštět opakovaně. Definice RTP úkolu má pouze jeden konstruktor vyžadující adresu cílového hosta, jeho port a cestu k MP3 souboru, který přenášet: ConfigRTPServer(String host, int port, String fileName)

Implementace ICMP K příkazové řádce přistupuje Java pomocí metody exec(String command) objektu třídy java.lang.Runtime, která je vždy jedinou instancí (Singleton) přítomná v každém vlákně Java aplikace. Při práci s příkazovou řádkou doposud multiplatformní aplikace můsí k příkazům přistupovat v závislosti na platformě. Nastává zde problém s rozdílnými pokročilými funkcemi nástroje ping. Zatímco ping na operačním systému unixového typu umožňuje uživateli například volit počet paketů, velikost náhodných dat přenášených v paketu a zejména časový interval, který musí uběhnout před vysláním dalšího paketu, ping operačního systému Windows neumožňuje měnit časový interval před odesláním dalšího paketu ICMP Echo Request. Nový paket se vždy odešle po jedné sekundě. Vytvořené konstruktory konfigurační třídy protokolu ICMP ConfigPING umožňují vytvořit konfiguraci i bez parametru interval. Pokud by byl v konfiguraci nastaven i parametr interval a úkol měl vykonávat ping na platformě Windows, jednoduše se nepoužije. Způsoby konfigurace úkolu protokolu ICMP jsou: ConfigPing(String host, int pocetPaketu) ConfigPing(String host, int pocetPaketu, int interval) ConfigPing(String host, int pocetPaketu, int packetSize, int interval)

API jádra Nyní, když byla popsána funkcionalita celé komponenty Sender, je již možné představit API celého jádra systému. Komponenta Capture nebude v práci blíže představována, protože všechny techniky v ní použité (režijní komunikace, práce s vlákny, přístup k příkazové řádce) jsou již popsány v rámci komponenty S.

7.2

Popis implementace

62

Pro vytvoření komunikačního profilu slouží konstruktor CP(long startTime), který vytvoří objekt komunikačního profilu a nastaví startovní čas testu. Dále je nutné metodou addProfil(String IPSender) vytvořit v objektu CP nový DilciCP. Na konec lze opakovaným voláním metody addZaznam přidávat jednotlivé úkoly (záznamy komunikačního profilu). Parametry metody addZaznam jsou IP adresa senderu, podle které se přiřadí záznam k dílčímu profilu, generovaný protokol (konstanta třídy CP), konfigurace protokolu (ProtokolConfig), počet opakování úkolu v jednom vlákně, interval před opakovaným vykonáním úkolu a interval od spuštění testu, kdy bude daný záznam aktivován. Po naplnění komunikačního profilu ho lze rozeslat jako jednotlivé dílčí profily pomocí objektu třídy CPClientTCP, která se spustí jako vlákno a v konstruktoru jí je předán objekt třídy DilciCP (cp.getDilciProfily()). Praktická ukázka naplnění komunikačního profilu se nachází v kapitole 8. Rozhraní pro práci s komponentou C je o poznání jednodušší, stačí vytvořit objekt třídy Filtr pomocí konstruktoru níže, který obsahuje IP komponenty ST, délku trvání testu, velikost odchytu z každého paketu v bytech a startovní čas celého testu. Na jednotlivé C se filtr rozesílá objektem třídy FiltrClientTCP spuštěným jako nové vlákno, který v kostruktoru vyžaduje Filtr a cílovou IP. Filtr(String IPstat, int duration, int packetSize, long startTime)

TCP server komponenty ST je nyní součástí A, stačí spustit objekt třídy TCPServerPCAP jako nové vlákno. Přijaté PCAP soubory bude ukládat pod název zdrojové IP do aktuální složky. Obdobně se ovládá logovací server pojmenovaný LogServerUDP, přijaté logy v současné době vypisuje na standardní výstup.

8

TESTOVÁNí

8 8.1

63

Testování Problematika QoS

Sekce přibližuje využití generátoru pro testování nastavení QoS. Test na níže představené topologii se skládá ze dvou fází, kdy v rámci první fáze probíhá přenos dat s dostatečnou šířkou pásma, naopak v druhé fázi je šířka pásma výrazně omezena, což má za následek zhoršení síťových charakteristik. Získat data pro vyčíslení těchto charakteristik včetně vygenerování samotného provozu je úkolem generátoru jako celku. Síťové charakteristiky z obou fází jsou následně porovnány. Testovaná síť tedy pro jednoduchost neaplikuje klasifikaci a priorizaci vybraných datových toků, ale je pouze účelově omezována šířka pásma. Lze tak například simulovat pomalejší sériou linku WAN spoje s rychlostí 1 544 kbps. Je tak demonstrována nutnost zavádění QoS. Topologie a konfigurace prvků

Obr. 27: Topologie testu šířky pásma.

Síťová infrastruktura (obr. 27) se skládá ze dvou sítí – testované (rozsah IP adres je 172.16.0.0/24) a režijní (rozsah IP adres je 192.168.0.0/24). Testovaná obsahuje jeden L2 switch Cisco Catalyst 2960 (WS-C2960-24TT-L, IOS verze 12.2(35)SE5,

8.1

Problematika QoS

64

LAN Base, 61440 kB RAM) a jeden L3 switch Cisco Catalyst 3750 (WS-C3750-24P, IOS verze 12.2(44)SE5, IP Services, 131072 kB RAM). Topologie režijní sítě není podstatná, zavádí se, aby režijní komunikace generátoru (v průběhu testu jsou to logy) nezkreslovala sledovaný provoz v testované síti. Na hranici obou sítí se nachází tři pracovní stanice a jeden server. Pro lepší orientaci mají hodnotu posledního bytu obou IP adres stejný. Dále jsou tedy označovány podle této hodnoty. Hardwarová konfigurace všech počítačů je následovná: • Procesor – Intel Core2 Duo E4300 • Paměť RAM – 1,5 GB • Rozhraní NIC1 – Intel 82566DM Family Gigabit Ethernet • Rozhraní NIC2 – Realtek RTL8139 Family PCI Fast Ethernet Na PC1, PC2 i PC3 pracuje 32b operační systém Windows 7 Professional, na serveru je rovněž 32b CentOS 5.2. Na něm je spuštěn webový server (služba httpd). Dále je zde povolen cílový port 80. Na všech strojích je aktivní JRE ve verzi 1.7.0_02 a na všech je dostupná instalace nástroje Wireshark. V neposladní řadě je nutné synchronizovat čas na všech stojích pomocí NTP serveru, který je spuštěn na serveru (IP adresa 172.16.0.5). Na PC v režijní síti (IP adresa 192.168.0.10) je spuštěn Windows 7 Professional a JRE. Na zařízeních v režijní síti není nutné synchronizovat čas, pokud se při definici komunikačního profilu bude uživatel řídit časem v testované síti49 . L2 switch nevyžaduje žádnou explicitní konfiguraci. Pro jeho úlohu v testu postačí výchozí konfigurace po spuštění. Na L3 switchi je další konfigurace nutná, a to pro druhou fázi testu (pro omezení šířky pásma). V rámci druhé fáze je na rozhraní Fa1/0/1 (viz obr. 27) aplikována konfigurace (uvedena níže), která omezí šířku pásma z původních 100 Mbps (maximum pro FastEthernet) na pouhých 0,5 Mbps. Konfigurace aplikuje při vstupu dat na rozhraní FastEthernet1/0/1 politiku xzach-qos-pmap, která omezí šířku pásma na 0,5 Mbps, tzv. „Burst Size50 “ na 8000 kb a všechny pakety nad limit bude zahazovat51 . Tato politika bude platit pro IP adresy definované v ACL (Access Conrol List) – konkrétně 172.16.0.1 a 172.16.0.2: SW9-Q#show run ... // výpustek class-map match-all xzach-qos-cmap match access-group name xzach-qos-policing-acl ... policy-map xzach-qos-pmap class xzach-qos-cmap police 500000 8000 exceed-action drop ... 49

Ihned po spuštění testu jsou instrukce rozeslány na stroje s komponentami S a C, které jsou již synchronizované. 50 Burst size definuje šířku pásma nad stanovenou mezí, která může být nárazově využita aniž by byla data zahozena. 51 Více na: http://www.cisco.com/en/US/products/hw/switches/ps5023/products_tech_ note09186a0080883f9e.shtml.

8.1

Problematika QoS

65

interface FastEthernet1/0/1 service-policy input xzach-qos-pmap ... ip access-list extended xzach-qos-policing-acl permit ip host 172.16.0.1 any permit ip host 172.16.0.2 any ...

Nastavení generátoru Na PC1 a PC2 je pod účtem administrátora spuštěna komponenta S. Po spuštění je nutné nastavit IP adresu, kde naslouchá logovací server, který je obsažený v komponentě A v režijní síti, tzn. je vložena IP 192.168.0.10. Dále se aplikace zeptá na port, ten je standardně 9999. Poté komponenta S připravena. Ukázka níže přibližuje postup spuštění S : C:\>java -jar mendelu.pef.dp.xzach.sender.jar Zvolte IP log serveru: 192.16.0.10 Zvolte port log serveru: 9999 Čekám na instrukce...

Na všechny uzly v testované síti jsou rozmístěny komponenty C. Níže je zařazena ukázka spuštění komponenty C na linuxovém serveru pod účtem root. Po spuštění je pouze nutné zvolit, na kterém rozhraní odchytávat po přijetí instrukcí provoz. Poté již komponenta, stejně jako v přechozím případě, čeká na instrukce od řídící stanice: [root@Pokuston10SiteL ~]#java -jar mendelu.pef.dp.xzach.capture.jar Vyberte, na kterém rozhraní odchytávat: 1. lo0 2. eth0 3. eth1 2 Čekám na instrukce...

Na závěr je nutné zprovoznit řídící stanici. Ta se v tomto příkladě skládá z komponenty A a ST, přičemž ST je v současné době pouze server, který sbírá data o proběhlé komunikaci v testované síti od všech komponent C. Pro zpracování síťových charakteristik je v této práci využito statistických funkcí nástroje Wireshark. Rozvoj komponenty ST je předmětem dalšího vývoje. Komunikační profil Jak je patrné z topologického diagramu (obr. 27), budou generovány dva druhy komunikace – HTTP a RTP. Délka jedné fáze testu je 70 sekund. PC1 (172.16.0.1) v čase 0 začne pětkrát po sobě stahovat ze serveru (172.16.0.5) soubor o velikosti

8.1

Problematika QoS

66

10 MB. Okamžitě po skončení jedné iterace, začne další. Dále v 30. sekundě testu začne stejný klient stahovat ze serveru soubor o velikosti 50 MB. Až do konce testu už PC1 další komunikaci negeneruje. Úkolem PC2 (172.16.0.2) je v čase 0 začít streamovat na PC3 (172.16.0.3) MP3 nahrávku o délce 55 sekund s konstantním datovým tokem 320 kbps. Komunikační profil v podobě Java kódu s využitím vytvořeného API vypadá na komponentě A (řídíci stanici) v demonstrativně vytvořené metodě vytvorProfil následovně: public void vytvorProfil(){ CP cp = new CP(new Date().getTime() + 1000); cp.addProfil("192.168.0.1"); cp.addZaznam("192.168.0.1", CP.HTTP, new ConfigHTTP("172.16.0.5", "10.rar"), 5, 0, 0); cp.addZaznam("192.168.0.1", CP.HTTP, new ConfigHTTP("172.16.0.5", "50.rar"), 1, 0, 30000); cp.addProfil("192.168.0.2"); cp.addZaznam("192.168.0.2", CP.RTPserver, new ConfigRTPServer("172.16.0.3", 5555,"nahravka.mp3"), 1, 0, 0); }

Nejprve je nutné vytvořit instanci komunikačního profilu, kterému je v konstruktoru předán startovní čas testu. V tomto případě je to aktuální čas zvětšený o 1 000 ms. Tím získá komponenta A jednu sekundu k rozeslání profilů ostatním komponentám52 . Dále je definován profil pro PC1 a nakonec pro PC2. Metoda cp.addProfil("192.168.0.1") přidá dílčí profil pro PC1 (k identifikaci se používá režijní rozhraní). Následné volání metody addZaznam definuje dílčí záznam komunikačního profilu. První parametr označuje režijní IP adresu Senderu, kterému je úkol určen, druhý parametr definuje generovaný protokol, třetí atribut je objekt konfigurace generovaného protokolu HTTP, následuje počet opakování komunikace (5), časový interval před dalším opakováním (0 ms) a nakonec časový interval měřený od začátku testu, kdy se má dílčí záznam (úkol) vykonat (0 ms). Konfigurace protokolu HTTP obsahuje cílový webový server a cestu k souboru. Ve zkratce lze říci, že tento záznam přiřazuje úkol pro Sender s režijní IP 192.168.0.1 okamžitě po spuštění testu stáhnout 5× po sobě soubor 10.rar z webového serveru 172.16.0.5. Analogicky se postupuje s definicí dalších záznamů. Přesný popis parametrů metod se nachází v kapitole 7.2. Po definici kompletního profilu jsou dílčí profily pro jednotlivé komponenty S rozeslány ve zvláštních vláknech. Komponentám C je také s využitím vláken rozeslán příkaz o započetí odchytu s délkou trvání 70 s, poté snímání provozu ukončí a odešlou nasbíraná data komponentě ST. 52

Pokud by komponenta S, resp. C získala profil později než v něm definovaném startovním čase testu, žačne zpracovávat profil okamžitě. Zpoždění, které je tvořeno předáním instrukcí mezi komponentou S, resp. C, je však minimální (v řádu ms).

8.1

Problematika QoS

67

Statistiky z první fáze testu Ze shromážděných dat byly vytvořeny grafy nasnímaného provozu, které v první fázi testu ukazují, že dostupná maximální šířka pásma pro FastEthernet – 100 Mbps – nijak neomezuje generovaný pararelní provoz. Současně je nutné upozornit, že v síti probíhá i další komunikace vytvářená operačními systémy a síťovými prvky53 . Jedná se zpravidla o intenzivní komunikaci, avšak s malým objemem přenášených dat, která se ve vysokém provozu stává zanedbatelnou, s menší dostupnou šířkou pásma, se její vliv zvětšuje.

Obr. 28: Graf datového toku RTP generovaného z rozhraní 172.16.0.2 (PC2) odchyceným na 172.16.0.2 (PC2).


Odchozí provoz protokolu RTP nasnímaný C na (172.16.0.2) je znázorněný na obr. 28. Je patrné, že čas přibližně do 4. vteřiny testu byl spotřebován na přípravu nahrávky k přenosu po síti, následuje počáteční výrazný objem vkládaných dat (až ke 2 Mbps). Dále je již až do konce přenosu objem přenášených dat konstantní, 53

Patří sem například CDP, STP, LLMNR, NBNS nebo ARP protokol.

8.1

Problematika QoS

68

pod hranicí 400 kbps. 320 kbps tvoří data a zbytek záhlaví PDU, přičemž záhlaví každého paketu má celkem 60 B. Záhlaví L2 rámce má 20 B, stejně velké je záhlaví IP paketu, záhlaví UDP datagramu má 8 B a RTP 12 B. Současně byl snímán RTP provoz po přenosu v síti na cílovém PC3 (172.16.0.3), nyní zanesený do grafu na obr. 29. Na první pohled je při porovnání obou grafů zřejmé, že při přenosu v síti nedocházelo k žádným, nebo pouze minimálním ztrátám.

Obr. 30: Graf datových toků RTP a HTTP generovaných z 172.16.0.1 (PC1), resp. 172.16.0.2 (PC2) odchycených na 172.16.0.1 (PC1), resp. 172.16.0.2 (PC2).

Obr. 31: Graf datových toků RTP a HTTP generovaných z 172.16.0.1 (PC1), resp. 172.16.0.2 (PC2) odchycených na 172.16.0.5 (WWW server), resp. 172.16.0.3 (PC3).

Graf na obr. 30 zachycuje kompletní generátorem vytvořený odchozí provoz z PC1 a PC2. Zeleně je vyznačen datový tok RTP z obr. 28, červeně je vyznačen odchozí HTTP provoz z PC1 a černou barvou je znázorněn součet obou datových toků. Z grafu je patrné opakované stahování 10MB souboru, přičemž 2. a 3. iterace splynula v grafu do jedné. Snadno rozlišitelné je stahování 50MB souboru ve 30. sekundě první fáze testu. Naopak graf z obr. 31 vykresluje odchozí provoz z PC1

8.1

Problematika QoS

69

a PC2 tak, jak byl zachycen po přenosu v síti na cílových uzlech (PC3 a webový server). Zeleně je vyznačen RTP provoz z obr. 29, červeně odchozí HTTP provoz z PC1 po doručení na webový server. Součet obou datových toků je opět vyznačen černě.

Obr. 32: Jitter generovaného RTP přenosu na příjemci 172.16.0.3 (PC3).

Graf z obr. 32 představuje naměřený Jitter v ms. Jitter se během první vteřiny přenosu ustálí na konstantní hodnotě přibližně 7 ms. Taková hodnota zaručuje spolu s nulovou ztrátovostí bezproblémovou interpretaci nahrávky na příjemci. Další detaily RTP přenosu shromažďuje tabulka 6. Potvrzuje nulovou ztrátovost v první fázi, uspěšný přenos 2 036 RTP paketů a průměrný Jitter 8,71 ms. Statistiky z druhé fáze testu


Před spuštěním druhé fáze testu byla na L3 přepínači z topologie na obr. 27 omezena vstupní šířka pásma rozhraní Fa1/0/1 na 0,5 Mbps pomocí konfigurace zmíněné výše. Poté bylo v rámci druhé fáze testu odstartováno generování provozu

8.1

Problematika QoS

70

s totožným nastavením jako ve fázi první, tedy stejný komunikační profil s dobou odchytu 70 sekund. Následuje sestava grafů zachycující statistiky stejným způsobem jako v první části, ale již s rozdílnými výsledky.


Odchozí provoz protokolu RTP (obr. 33) nasnímaný na zdrojovém rozhraní 172.16.0.2 je srovnatelný se stejným datovým tokem z předchozí fáze (obr. 28). Data doposud nebyla přenášena v síti, omezená šířka pásma se tedy nemohla projevit. Výrazná změna však nastavá při snímání RTP provozu, který dorazí na rozhraní příjemce. Jak je vidět na grafu z obr. 34, přijatý RTP provoz na PC3 vůbec nedosahoval vysokého datového toku na začátku přenosu, naopak přibližně do 12. sekundy jsou patrné výkyvy v objemu přijatých dat a navíc na několik sekund přibližně v polovině přenosu nebyla přijata žádná RTP data. To má za následek výpadky zvuku při přehrávání nahrávky na příjemci. Jitter a zpoždění tohoto přenosu jsou analyzovány níže.

Obr. 35: Graf datových toků RTP a HTTP generovaných z 172.16.0.1 (PC1), resp. 172.16.0.2 (PC1) odchycených na 172.16.0.1 (PC1), resp. 172.16.0.2 (PC2).

8.1

Problematika QoS

71

Obr. 36: Graf datových toků RTP a HTTP generovaných z 172.16.0.1 (PC1), resp. 172.16.0.2 (PC2) odchycených na 172.16.0.5 (WWW server), resp. 172.16.0.3 (PC3).

Ztráty přenášených RTP dat způsobilo vyčerpání dostupné šířky pásma HTTP provozem mezi PC1 a webovým serverem. Na obr. 35 je RTP přenos znázorněn zeleně (jedná se o křivku z grafu na obr. 33), červeně je vyznačen HTTP provoz generovaný komponentou S na PC1. Je zde opět zřejmé opakované stažení 10MB souboru ze začátku testu, i stažení 50MB souboru ve 30. vteřině. Provoz byl odchycen před vstupem dat do sítě, není tedy poznamenán přenosem po síti. Naopak graf z obr. 36 přibližuje vygenerovaný RTP a HTTP provoz tak, jak byl odchycen na příjemcích, tedy PC3 a webovém serveru. Příchozí provoz na rozhraní Fa1/0/1 L3 přepínače, který je již nad povolený limit, je zahazován. HTTP provoz je schopen se díky transportnímu protokolu TCP s případnou ztrátou paketu vyrovnat jeho přeposláním. Naopak RTP je přenášeno nespolehlivým UDP, které ztracené pakety nepřeposílá. Proto RTP přenos zaznamenává během zaplnění šířky pásma v době vysokého HTTP provozu výraznou ztrátovost.

Obr. 37: Jitter generovaného RTP přenosu na příjemci 172.16.0.3 (PC3).

Detaily RTP přenosu při omezené šířce pásma využívanou i dalšími toky (HTTP provoz) přibližuje tabulka 7 a graf z obr. 37. V tabulce lze porovnat obě fáze testu.

8.2

72

Dostupnost datového centra

V druhé fázi zaznamenal RTP provoz 28,5% ztrátovost. Z celkového počtu 2 036 paketů bylo celkem 581 z nich ztraceno při přenosu v síti. Průměrný Jitter se zvýšil na 10,36 ms, na který však nemají vliv ztracené pakety. Z grafu na obr. 37 jsou zřejmé intervaly, kdy se pakety ztrácely. Na cílové stanici (PC3) byl proud přehráván pomocí VLC. V úvodu, kdy byly z webového serveru stahovány soubory, byla kvalita zvuku velmi špatná, nesrozumitelná melodie ani text přehrávané písně, ztrácely se celé slabiky slov. Jakmile HTTP přenos ustal a zvětšila se dostupná šířka pásma, byla kvalita zvuku vynikající. V okamžiku, kdy začal PC1 stahovat z webového serveru 50 MB soubor, nastal přibližně na 5 sekund úplný výpadek zvuku. Tab. 7: Charakteristiky RTP toků z obou fází.

8.2

Fáze

SPort

DPort

1. 2.

38816 13826

5555 5555

Počet paketů 2036 1455

Ztraceno Počet v % 0 0 581 28,5

Jitter [ms] Max. Prům. 25,98 8,71 323,58 10,36


Test generování provozu při omezené šířce pásma dokázal, že lze generátorem jako celkem analyzovat všechny potřebné síťové charakteristiky definované v sekci 6.1. Cílem testu na dostupnost datového centra tedy bude pouze demonstrovat, jak lze generováním ICMP paketů zachytit a znázornit výpadek v síti a dobu konvergence. Demonstrovaný test nepokrývá celou problematiku dostupnosti datového centra. Dále by bylo nutné zohlednit redundanci a vyvažování zátěže, tzn. sledování provozu pod zátěží při výpadku např. jednoho redundantního spoje. Přestože je generátor schopný zachytit i další potřebné charakteristiky, je tento test zaměřen pouze na měření délky výpadku serveru (Failover Time). Topologie a konfigurace prvků Pro jednoduchost byla pro tento test vytvořena topologie z obr. 38. Jedná se o propojení PC1 a serveru z předchozího příkladu pomocí jednoho L2 přepínače. Budou předstírány výpadky síťového prvku nebo serveru odpojením kabelu z přepínače. Tento test lze jednoduše aplikovat na skutečný případ (topologie je součástí přílohy F). Jak je zřejmé z diagramu (obr. 38), skládá se nyní topologie pouze z jedné sítě – testované 172.16.0.0/24. Konfigurace obou koncových uzlů (PC1 a serveru) je od předchozího testu nezměněna. Byly pouze přepojeny do L2 switche. Rozhraní přepínače s připojenými kabely je nutné nastavit tak, aby po zapojení kabelu okamžitě posílaly data z/na rozhraní a switch protokolem STP netestoval, zda připojená část

8.2


73

sítě obsahuje nechtěnou smyčku (cyklus) či nikoli54 . Rozhraní získají tuto konfiguraci: Switch(config)# interface range fastethernet 0/1 - 2 Switch(config-if)# spanning-tree portfast

Obr. 38: Testovaná topologie.

Nastavení generátoru a komunikační profil V tomto testu jsou komponenty distribuovaného generátoru umístěny netradičně všechny na jednom stroji (PC1). Data budou generována pouze na jednom koncovém uzlu (PC1), a proto lze všechny komponenty umístit na tento stroj, kde budou dílčí komponenty komunikovat přes rozhraní 127.0.0.1. Dále generátor obsahuje druhou komponentu C umístěnou na serveru. V tomto případě není nutné zavádět režijní síť. Test měří pouze počty ICMP paketů a režijní komunikace (logy) tedy měření neovlivní. Množštví logů komponenty C je minimální a přeposlání nasnímaných dat komponentě ST probíhá až po testu, proto během testu neovlivní ani dostupnou šířku pásma. Vlastnosti a postup spuštění komponent je stejný s popisem v předchozím testu. Test bude trvat 120 sekund, během kterých bude třikrát odpojen síťový kabel. Komunikační profil obsahuje pouze jednu položku definující pro komponentu S instrukce, aby začala v čase 0 generovat 1 000 ICMP Echo Request paketů, rychlostí 10 pps. Rychlost generování je dána konstruktorem ConfigPing, kde je definován v prvním parametru počet paketů a ve třetím interval před odesláním dalšího paketu (0,1 s)55 . Hodnota 56 (pro linuxové distribuce výchozí) je počet bytů náhodných dat, která jsou v ICMP paketu přenášena: public void vytvorProfil(){ CP cp = new CP(new Date().getTime()); cp.addProfil("192.168.0.1"); cp.addZaznam("192.168.0.1", Protokoly.PING, new ConfigPing("172.16.0.2", 1000, 56, 0.1), 1, 0, 0); } 54 55

Bude vždy připojen pouze jeden koncový uzel – smyčka v síti nemůže vzniknout. Pro hodnoty menší než 0,2 je třeba mít práva uživatele root.

8.2


74

Nasbírané statistiky Graf na obr. 39 přibližuje výsledek testu. Zeleně je zachycen počet paketů za sekundu typu ICMP Echo Request, který procházel rozhraním 172.16.0.5, modrý je počet ICMP Echo Reply paketů, červená křivka je součtem předchozích dvou a nakonec černě je zvýrazněn veškerý provoz nasnímaný na rozhraní serveru. Poprvé byl kabel odpojen približně na 5 vteřin kolem 10. sekundy testu. Po 30. sekundě testu byl podruhé odpojen odhadem na 10 sekund. Nakonec třetí ztráta konektivity je vytvořena rychlým vytažením a připojením síťového kabelu. Jak vyplývá z komunikačního profilu, komponenta S splní svůj úkol po 100 sekundách generování. I z grafu je zřejmé, že od 100. sekundy již nejsou žádna ICMP data zachycena. Graf odchytu na PC1 by vypadal až na zelenou křivku podobně. Počet ICMP Echo Request paketů by byl konstantní, i v případě výpadku v síti jsou pakety z PC1 stále odesílány.

Obr. 39: Množství odchycených ICMP paketů na 172.16.0.5 (WWW server).

9

EKONOMICKÉ ZHODNOCENí

9

75

Ekonomické zhodnocení

Dle údajů ČSÚ stále roste vybavení společnosti informačními technologiemi. Jak ukazuje dokument ČSÚ (2012), bylo v roce 2005 připojeno k Internetu 19 % domácností, v roce 2011 již bylo k Internetu připojeno 62 % domácností ČR. Naopak klesá vybavení domácností pevnou linkou. Zatímco v roce 2005 mělo pevnou linku 55 % domácností, v loňském roce to bylo pouze 24 %, což přináší příležitost pro zavádění VoIP telefonie do domácností. Podniky s alespoň 10 zaměstnanci jsou připojení k Internetu z 96 %. VoIP telefonie je ve firmách využívána více než v domácnostech a i zde trend využívání multimediálních služeb roste. Přibližuje to graf56 na obr. 40. Roste tak i potřeba nasazování QoS pro bezproblémovou funkci multimediálních služeb. Současně se zvyšuje počet e-shopů a internetového obchodování. Zatímco v roce 2011 mělo e-shop 25 % podniků ČR, v roce 2012 je to již 32 %. Jak naznačuje kapitola 8, najde nástroj uplatnění i zde, např. pro testování doby konvergence datového centra.

Obr. 40: Podniky v ČR využívající VoIP telefonii. Převzato z ČSÚ (2012)

9.1

SWOT analýza

Na základě výkazů ČSÚ a analýzy existujících generátorů síťového provozu byla sestavena SWOT matice vyvíjeného nástroje. Zachycuje v horní polovině silné a slabé stránky generátoru a v dolní příležitosti, kterých může další vývoj nástroje využít, a možné hrozby, na které by měl být generátor v budoucnu připraven. Silnými stránkami generátoru jsou snadná rozšiřitelnost o další protokoly, vygenerování libovolných datových toků díky komunikačnímu profilu, platformní nezávislost a využitelnost v různých testech. Slabou stránkou je zejména výkon, prozatimní absence frontendu a protože je vyvíjen na akademické půdě, nedokázal by zřejmě další vývoj reagovat na aktuální potřeby trhu. Příležitost je neustálý 56

Malé firmy jsou 10–49 zaměstnanců, střední 50–249 a velké 250+.

9.2

76

Analýza bodu zvratu

Obr. 41: SWOT matice generátoru.

rozvoj přenosu multimediálních dat a datových center. Stálou hrozbou nástroje jsou konkurenční existující či nově vznikající generátory. Případnou hrozbou je i vývoj zcela nových přenosových technologií.

9.2


Ekonomické zhodnocení generátoru je zpracováno na fiktivním příkladu lokálního poskytovatele Internetu, který plánuje nástroj od roku 2013 využívat k testování nastavení služeb zákazníkům. Aby mohl vyhovět všem specifickým požadavkům zákazníka, namodeluje dle požadavků komunikační profil a generátorem bude simulovat uživatele ještě před jeho zapojením do Internetu. Poskytovatel doposud zaznamenával reklamace za nekvalitní služby, přičemž každá reklamace způsobí poskytovateli náklady. Od zavedení generátoru si slibuje, že zákazníci přestanou reklamace podávat. Vyčíslením bodu zvratu získá poskytovatel potřebné informace k rozhodnutí, zda generátor ve firmě zavést či ne. Fixní náklady na provoz generátoru tvoří 22 000 Kč ročně. Byly vytvořeny tři různé varianty průměrných variabilních nákladů (PVN ) na provoz generátoru a tržby (p), v podobě ušetřených nákladů, na jednu reklamaci. Konkrétní hodnoty přibližuje tabulka 8. Tab. 8: Varianty výchozích hodnot pro výpočet bodu zvratu. Položka PVN p

Pesimistická 700 Kč 750 Kč

Neutrální 600 Kč 900 Kč

Optimistická 500 Kč 1000 Kč

Pokud bod zvratu označíme jako Qk, lze ho dle vzorce v teoretické části vypočítat jako: Qkp = F N/ (p − P V N ) = 22000/(750 − 700) = 440 reklamací Qkn = F N/ (p − P V N ) = 22000/(900 − 600) = 74 reklamací Qko = F N/ (p − P V N ) = 22000/(1000 − 500) = 44 reklamací

9.2


77

Nasazením generátoru u poskytovatele nastane v pesimistické variantě bod zvratu až při ušetření 440 reklamací, v neutrální variantě dosáhne nástroj bodu zvratu při 74 reklamacích a nejlepší variantě již při 44. Vývoj nákladů a tržeb všech tří variant je přiblížen na obr. 42, 43 a 44. Popisky os odpovídají označení veličin z teoretické části – tedy FN značí fixní náklady, VN variabilní náklady, CN celkové náklady a CT celkové tržby. Index (p, n, o) značí, zda se jedná o pesimistickou, neutrální nebo optimistickou variantu. Grafy neutrální a optimistické varianty znázorňují bod zvratu v černém kroužku, bod zvratu pesimistické varianty se v grafu vůbec nenachází.

Obr. 42: Vývoj nákladů a tržeb v pesimistické variantě.

Obr. 43: Bod zvratu v neutrální variantě.

9.2


Obr. 44: Bod zvratu v optimistické variantě.

78

10

10

DISKUSE A NÁVRH DALŠíHO VÝVOJE

79

Diskuse a návrh dalšího vývoje

Klady a zápory řešení Vytvořený systém se řadí do skupiny generátorů, které vytvářejí síťový provoz na základě komunikačního profilu. Hlavní přínos tohoto způsobu generování dat je ve flexibilitě komunikačního profilu. Lze tak z dostupné množiny podporovaných protokolů vytvořit v podstatě jakýkoliv síťový provoz – krátký, ale intenzivní provoz jedním protokolem, či provoz v dlouhodobém testu s nárazovou komunikací několika protokolů. Současně je toto softwarové řešení, ve srovnání s hardwarovými generátory, omezeno výkonem. Výkonový limit generátoru je však kompenzován jeho distribuovanou architekturou, která je schopna ke generování využít neomezený počet strojů, které všechny spravuje z jednoho bodu. Navržené řešení navíc předpokládá existenci doplňkové režijní sítě, která oddělí režijní komunikaci mezi komponentami generátoru od testované sítě, čímž není zkreslen generovaný provoz v testované síti. Negativem režijní sítě je však delší doba přípravy testu. V průběhu testu tvoří režijní komunikaci pouze logovací systém, který generátor umožní v případě potřeby vypnout. Tím odpadá potřeba režijní sítě. Generátor je schopný provozu na všech systémových platformách. Využívá multiplatformního nástroje tshark a jako aplikace vytvořená v jazyku Java pracuje v prostředí JRE. Nevýhodou tohoto řešení je nutnost instalace JRE a nástroje Wireshark na všech koncových uzlech, kde bude některá komponenta generátoru provozována. Návrh na zlepšení Závěrečná práce se zabývá první verzí vytvořeného generátoru, kterou čeká ještě řada zlepšení před vývojem dalších částí nástroje (frontend, modul statitik) a nasazením v síťové laboratoři. Jak je patrné z ukázek nastavení komponent Sender a Capture v kapitole 8, musí uživatel při spuštění vyplnit několik údajů, které nelze definovat v komunikačním profilu, protože se mohou lišit podle koncového uzlu. Řešením může být nastavení pevných výchozích hodnot a komponenty spouštět jako systémovou službu. Způsob jak minimalizovat přípravu koncových uzlů před spuštěním generátoru, může být i vytvoření vzorové virtuální stanice a dle potřeby vytvářet a poté virtualizovat identické kopie systému. Dalším návrhem na zlepšení je již výše diskutovaná volba pro vypnutí a zapnutí logovacího systému. Logy odesílají komponenty S a C na řídící stanici A, informují tak uživatele o aktuálním stavu testu, ale aby tato komunikace nezasahovala do testu, musí probíhat v separované síti. Diagram na obr. 22 přibližuje průběh komunikace mezi řídící stanicí a komponentami jádra. Tuto komunikaci by bylo vhodné doplnit o další signál, kterým by řídící stanice mohla okamžitě ukončit probíhající test. Pokud nyní uživatel nechtěně

10

DISKUSE A NÁVRH DALŠíHO VÝVOJE

80

spustí test trvající několik hodin, nemá kromě opětovného nastavení všech komponent jinou možnost než počkat na konec testu. Další vývoj Programový výstup závěrečné práce je připraven pro implementaci grafického rozhraní, které bude využívat rozhraní jádra a sofistikovaně vytvářet komunikační profil. Tato netriviální úloha vyžaduje analýzu chování uživatele a zapojení poznatků z oblasti Human-Computer Interaction 57 . Bude zpracována v rámci další závěrečné práce. Grafy z nasbíraných dat jsou v této práci zpracovány analytickými nástroji aplikace Wireshark. Bylo by vhodné zapracovat tvorbu těchto statistik do grafického rozhraní řídící stanice generátoru, ať s využitím zmíněné aplikace, nebo vlastní implementací. Správce (uživatel) generátoru by jiště ocenil možnost automatického vykreslení testované sítě s přehledy úkolů z komunikačního profilu pro dílčí stanice, či indikací činností na základě přijatých logů. Směrů dalšího vývoje se jistě najde celá řada. V současné době je funkční jádro generátoru a v nejbližší době další závěrečná práce zpracuje tzv. „frontend “ nástroje. Autorem závěrečné práce bude Bc. Rudolf Bilka, který je současně spoluautorem specifikace požadavků na generátor.

57

Zkoumá aspekty komunikace člověka se stroji a navrhuje metody pro zlepšení této interakce.

11

11

ZÁVĚR

81

Závěr

Diplomová práce se zabývá problematikou generování síťového provozu, po analýze současných generátorů je navrženo, implementováno a ověřeno vlastní řešení. Systém najde uplatnění v Síťové laboratoři PEF MENDELU, kde bude sloužit jako podpůrný nástroj při experimentech ve výuce a v rámci závěrečných prací. Nástroj lze provozovat v jakékoliv TCP/IP síti na všech systémových platformách. Je vytvořen v jazyce Java a využívá externích volně dostupných nástrojů. Specifikace požadavků, v části Přehled hlavních funkcí, definuje celkem šest hlavních funkcí kompletního generátoru. Cílem diplomové práce je zpracovat jádro systému, které obnáší realizaci bodu 2 – ovládání vzdálených komponent generátoru, 3 – generování provozu dílčími generátory (Sendery) a 4 – sběr dat o proběhlé komunikaci. Všechny tyto body se podařilo navrhnout, implementovat a vzájemně otestovat. Vývoj jádra generátoru bude nadále pokračovat. V současné době je zpracováno generování protokolu HTTP, SMTP, POP3, ICMP a RTP. V budoucnu je plánováno rozšířit tuto množinu protokolů a odstranit nedostatky diskutované v předchozí kapitole. Navázáním dalších závěrečných prací vzniknou nová užitečná rozšíření nástroje, který nalezne uplatnění nejen v síťové laboratoři, ale i v praxi.

12

12

LITERATURA

82

Literatura

Algoritmy.net: příručka vývojáře. Algoritmy.net: Java pro začátečníky (22) [online]. 2012 [cit. 2012-03-11]. Dostupné z: . Apache Software Foundation. Apache JMeter [online]. 2012 [cit. 2012-02-23]. Dostupné z: . Aujezdský, J. Právní aspekty volně šiřitelných počítačových programů. Root.cz [online]. 2012 [cit. 2012-03-05]. Dostupné z: . Beňo, M. Návrh a implementácia modulov pre tester sieťových spojení. Brno, 2008. Bakalářská práce. Masarykova univerzita v Brně. ČSÚ. Informační společnost v číslech 2012. Český statistický úřad [online]. 2012 [cit. 2012-05-07]. Dostupné z: . Distributed ITG. Distributed Internet Traffic Generator [online]. 2011 [cit. 2011-10-30]. Dostupné z: . Dvořák, M. Návrhové vzory: Bridge Pattern [online]. 2005 [cit. 2012-04-12]. Dostupné z: . Giacobbi, G. The GNU Netcat Project. The GNU Netcat [online]. 2006 [cit. 2011-11-19]. Dostupné z: . Google Project Hosting. Packet Traffic Generator and Analyzer [online]. 2011 [cit. 2011-10-26]. Dostupné z: . Harold, E. R. Java network programming. 3th ed. Sebastopol, Calif.,: O’Reilly, 2005. 735 s. ISBN 05-960-0721-3. Heng, A. Bit-Twist: Libpcap-based Ethernet packet generator. Bit-Twist [online]. 2011 [cit. 2011-12-04]. Dostupné z: . Herout, P.Učebnice jazyka Java. 3. vyd. České Budějovice: Kopp, 2008. 381 s. ISBN 978-80-7232-323-4. Huja, P. RTP a aplikační rozhraní Java Media Framework. FEKT VUT Brno. Elektrorevue.cz [online]. 2003 [cit. 2012-03-05]. Dostupné z: . Chvalovský, K. NTP: Filozofie synchronizace času po Internetu. Lupa.cz [online]. 2003 [cit. 2012-04-14]. Dostupné z:. IETF. RFC 3550. 2003. Dostupné z: . Jelínek, M. Metody testování zatížení sítě Ethernet. Brno, 2008. Diplomová práce. Masarykova univerzita v Brně. Kuba, T. Návrh a implementácia modulov pre tester sieťových spojení. Brno, 2008. Bakalářská práce. Masarykova univerzita v Brně.

12

LITERATURA

83

Mastracci, M. Java Media Framework [online]. 2011 [cit. 2012-04-08]. Dostupné z: . Mills, D. How NTP Works [online]. 2012 [cit. 2012-04-14]. Dostupné z: . Mrštíková, H. Modulární tester síťových aplikací/spojení. Brno, 2009. Diplomová práce. Masarykova univerzita v Brně. Olson E. Java Media Framework basics. DeveloperWorks [online]. 2002 [cit. 2012-03-07]. Dostupné z: . Omnicor – IP Performance Test Systems. LanTraffic V2 – Enhanced Edition – Software [online]. 2010 [cit. 2011-11-13]. Dostupné z: . PacketBuilder. Product Overview [online]. 2010 [cit. 2011-11-13]. Dostupné z: . Peterka, J. Simulace vs. emulace. EArchiv.cz: Archiv článků a přednášek Jiřího Peterky [online]. 2011 [cit. 2012-04-05]. Dostupné z: . Pitt, E.Fundamental Networking in Java. USA: Springer Science+Business Media, 2006. ISBN 978-1846-2803-6. Pužmanová, R. TCP/IP v kostce. 2. vydání. České Budějovice: Kopp, 2010. ISBN 978-80-7232-388-3. Sanli, M. a spol. FPGEN: A fast, scalable and programmable traffic generator for the performance evaluation of high-speed computer networks. Volume 68. Issue 12. December 2011. p. 1276–1290. ISSN 0166-5316. Scapy. Introduction of Scapy [online]. 2011 [cit. 2011-12-04]. Dostupné z: . SecTools.org. Top Network Security Tools [online]. 2011 [cit. 2011-11-20]. Dostupné z: . Schneider, F. Performance evaluation of packet capturing systems for high-speed networks. München, 2005. Diplomarbeit. Technische Universität München. Sommers, J. Self-configuring network traffic generation. In: IMC 2004: proceedings of the 2004 ACM SIGCOMM Internet Measurement Conference. Taormina. Sicily. Italy, 2004. New York: ACM Press, p. 68–81. ISBN 1-58113-821-0. Švec, P. Návrh a mplementácia IPv6 siete v akademickej sfére. Ostrava, 2011. Dizertační práce. Ostravská univerzita v Ostravě. Synek, M., Kyslingerová, E. a kol. Podniková ekonomika 5. vyd. Praha: C.H. Beck, 2010. 498 s. ISBN 978-80-7400-336-3. Sýkora, T. Zátěžové testy podnikového informačního systému. Brno, 2011. Bakalářská práce. Masarykova univerzita v Brně. Vavřík, J. Zátěžové testy webových aplikací. Brno, 2010. Diplomová práce. Masarykova univerzita v Brně.

12

LITERATURA

84

Vishwanath, K. V. Realistic and responsive network traffic generation. In: Proceedings of ACM SIGCOMM 2006: Pisa, ItalyConference on Computer Communications. New York, ACM Press, 2006, p. 111–122. ISBN 1-59593-308-5. Wallace, K. Implementing Cisco Unified Communications Voice over IP and QoS: Foundation Learning Guide. Cisco Systems, Inc. 4th ed. Indianapolis: Cisco Press, 2011. ISBN 978-1-58720-419-7. Wikipedia EN. Netcat [online]. 2011 [cit. 2011-11-20]. Dostupné z: . Wikipedia EN. Emulator [online]. 2011 [cit. 2012-03-05]. Dostupné z: . Williamson, C. Internet traffic measurement. In: IEEE internet computing. USA: IEEE Educational Activities Department Piscataway, 2002, p. 70–74. ISSN 1089-7801. WinPcap. Remote Capture [online]. 2007 [cit. 2012-04-08]. Dostupné z: . Wireshark Foundation. RTP Statistics [online]. 2012 [cit. 2012-04-08]. Dostupné z: . Wireshark Foundation. Wireshark.org [online]. 2012 [cit. 2012-04-08]. Dostupné z: . Yallapragada, V., Venkat G., Shripal P. Network Packet Generator: A Project Report. San Jose State University. 2009. Zaachi.com. Java: Síťová komunikace [online]. 2008 [cit. 2012-03-13]. Dostupné z: . *

A

A

GUI NÁSTROJE IP TEST AND MEASURE

GUI nástroje IP Test and Measure

Obr. 45: Hlavní okno GUI nástroje IP Test and Measure

85

B

B

GUI NÁSTROJE OSTINATO

GUI nástroje Ostinato

Obr. 46: Hlavní okno GUI nástroje Ostinato

86

C

C

87

STATISTIKA TOKU NÁSTROJE D-ITG

Statistika toku nástroje D-ITG

Flow number: 1 From 192.168.1.1:9000 To 192.168.1.2:9001 Total time Total packets Minimum delay Maximum delay Average delay Average jitter Delay standard deviation Bytes received Average bitrate Average packet rate Packets dropped Average loss-burst size

= = = = = = = = = = = =

9.916000 100 0.000000 0.000000 0.000000 0.000000 0.000000 50000 40.338846 10.084712 0 0.000000

s s s s s s Kbit/s pkt/s (0.00 %) pkt

**************** TOTAL RESULTS ****************** Number of flows = 1 Total time = 9.916000 s Total packets = 100 Minimum delay = 0.000000 s Maximum delay = 0.000000 s Average delay = 0.000000 s Average jitter = 0.000000 s Delay standard deviation = 0.000000 s Bytes received = 50000 Average bitrate = 40.338846 Kbit/s Average packet rate = 10.084712 pkt/s Packets dropped = 0 (0.00 %) Average loss-burst size = 0 pkt Error lines = 0

D

D

ANALYTICKÝ DIAGRAM KOMPONENTY SENDER

Analytický diagram komponenty Sender

Obr. 47: Analytický diagram komponenty Sender.

88

E

E

ANALYTICKÝ DIAGRAM KOMPONENTY CAPTURE

Analytický diagram komponenty Capture

Obr. 48: Analytický diagram komponenty Capture.

89

F

F

TOPOLOGIE DATOVÉHO CENTRA

Topologie datového centra

Obr. 49: Topologie datového centra. Převzato ze studijních materiálů k předmětu IPIAC, Pokorný (2012)

90

Návrh komunikačního jádra generátoru síťového provozu

Recommend Documents