VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor Aplikovaná informatika
Řízení šířky pásma pomocí C# aplikace bakalářská práce
Autor: Martin Fraj Vedoucí práce: Mgr. Antonín Přibyl Jihlava 2014
Abstrakt Tato bakalářská práce se zabývá problematikou řízení šířky pásma v počítačové síti a komplexním řešením této problematiky. V první části je popsán systém MikroTik RouterOS, který zprostředkovává řízení šířky pásma. Ve druhé části je zdokumentována aplikace v jazyce C#, která implementovaný systém spravuje. Závěrem budou předvedeny výsledky a poznatky z nasazení v praxi.
Klíčová slova počítačová síť, MikroTik, RouterOS, QoS, šířka pásma, formování toku, značkování, fronty, aplikace, C#, .NET
Abstract This thesis discusses about traffic shaping in the wireless computer network. In the first part is documented system MikroTik RouterOS that is used for implementation of this system. In the second part is documented the application in programme language C# that administrate this system. The results of deployment this system in practice, will be presented at the end.
Key words computer network, MikroTik, RouterOS, QoS, bandwidth, shaping, marking (mangle), queues, application, C#, .NET
Prohlašuji, že předložená bakalářská práce je původní a zpracoval jsem ji samostatně. Prohlašuji, že citace použitých pramenů je úplná, že jsem v práci neporušil autorská práva (ve smyslu zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů, v platném znění, dále též „AZ“). Souhlasím s umístěním bakalářské práce v knihovně VŠPJ a s jejím užitím k výuce nebo k vlastní vnitřní potřebě VŠPJ. Byl jsem seznámen s tím, že na mou bakalářskou práci se plně vztahuje AZ, zejména § 60 (školní dílo). Beru na vědomí, že VŠPJ má právo na uzavření licenční smlouvy o užití mé bakalářské práce a prohlašuji, že s o u h l a s í m s případným užitím mé bakalářské práce (prodej, zapůjčení apod.). Jsem si vědom toho, že užít své bakalářské práce či poskytnout licenci k jejímu využití mohu jen se souhlasem VŠPJ, která má právo ode mne požadovat přiměřený příspěvek na úhradu nákladů, vynaložených vysokou školou na vytvoření díla (až do jejich skutečné výše), z výdělku dosaženého v souvislosti s užitím díla či poskytnutí licence. V Jihlavě dne
............................................... Podpis
Poděkování Na tomto místě bych rád poděkoval svému vedoucímu bakalářské práce Mgr. Antonínu Přibylovi za podporu a cenné rady při psaní této práce.
Obsah 1
Úvod.......................................................................................................................... 8
2
QoS ........................................................................................................................... 9 2.1
2.1.1
Best-effort service ....................................................................................... 9
2.1.2
Integrated services (IntServ) ....................................................................... 9
2.1.3
Differentiated services (DiffServ) ............................................................ 10
2.2 3
3.1
Systém komunikace ......................................................................................... 13
3.2
Klasifikace a značkování paketů ...................................................................... 14
3.2.1
Typy značkování ....................................................................................... 15
3.2.2
Řetězec (Chain)......................................................................................... 16
3.2.3
Skok (Jump) .............................................................................................. 17
Řazení do front a řízení šířky pásma ................................................................ 17
3.3.1
HTB (Hierarchical Token Bucket) ........................................................... 18
3.3.2
Simple queue (jednoduchá fronta) ............................................................ 19
3.3.3
Queue tree (stromová struktura) ............................................................... 19
3.3.4
Queue type (typ fronty)............................................................................. 20
Implementace .......................................................................................................... 22 4.1
5
Možné přístupy k problematice ........................................................................ 11
MikroTik RouterOS ................................................................................................ 13
3.3
4
Principy QoS ...................................................................................................... 9
Prostředí pro implementaci .............................................................................. 22
4.1.1
Struktura sítě ............................................................................................. 22
4.1.2
Zapojení systému řízení do sítě ................................................................ 22
4.2
Klasifikace a značkování paketů ...................................................................... 23
4.3
Řazení do front a řízení šířky pásma ................................................................ 25
4.4
Správa a údržba ................................................................................................ 25
Aplikace pro správu a údržbu ................................................................................. 27 5.1
Vývojové prostředí ........................................................................................... 27
5.2
MikroTik API ................................................................................................... 27
5.2.1 5.3
Protokol ..................................................................................................... 28
Implementace aplikace ..................................................................................... 29
5.3.1
Data aplikace............................................................................................. 30
5.3.2
Třídy aplikace ........................................................................................... 31
5.3.3
Formulářové třídy aplikace ....................................................................... 36
6
Testování ................................................................................................................. 40
7
Závěr ....................................................................................................................... 41
Seznam použité literatury ............................................................................................... 42 Seznam obrázků .............................................................................................................. 44 Seznam tabulek ............................................................................................................... 45 Seznam použitých zkratek .............................................................................................. 46 Přílohy............................................................................................................................. 47 1
Obsah přiloženého CD ............................................................................................ 47
1 Úvod Do své bakalářské práce jsem si zvolil problematiku řízení šířky pásma v počítačové síti. V oblasti počítačových sítí se již delší dobu pohybuji, a proto jsem se rozhodl pro toto téma, ve kterém mohu uplatnit své poznatky a zároveň prohloubit své znalosti. Výsledek práce bych rád implementoval a předvedl ve fungující bezdrátové síti. Prostředkem pro samotné řízení mi bude routovací systém RouterOS vyvinutý lotyšskou firmou MikroTik. Pro ovládání a řízení celého procesu bude naprogramována formulářová aplikace v jazyce C#. Obecně si pod pojmem řízení šířky pásma (běžně označováno jako klasifikace provozu, shaping či QoS) lze představit množinu pravidel, která se omezují a korigují průběh a pořadí komunikace mezi koncovým prvkem v síti a Internetem. Výhody řízené komunikace, a nutnost ji mít, jsou nezpochybnitelné. Představme si síť, která je určitou omezenou rychlostí připojená do Internetu. Jeden z uživatelů začne přenášet velký objem dat, další uživatel prohlíží internetové stránky. V takovém případě dochází ke zpomalení odezvy na stránky právě u druhého uživatele. Pokud se přidá třetí uživatel, který zamýšlí telefonovat pomocí IP telefonu, bude mít problém vůbec rozumět protistraně, pokud zpoždění hlasových dat v danou chvíli přesáhne mezní hranici cca 150ms. Počet uživatelů a hlavně počet zařízení, která se dokážou připojit k Internetu, neustále stoupá a rychlosti datových linek budou vždy omezujícím faktorem. Z tohoto důvodu je, a do budoucna nadále bude řízení šířky pásma nutnou součástí dobře fungující sítě.
8
2 QoS QoS (Quality of Service) je množina nástrojů (technologií), které na různých vrstvách modelu ISO/OSI řídí síťovou komunikaci. Jedná se o rozsáhlou problematiku, která se navíc dále rozvíjí dle použité technologie, není tedy možné v rámci této práce plně nahlédnout do všech zákoutí QoS. Tato práce se zabývá řízením šířky pásma, což je právě jedna z podmnožin problematiky QoS [1]. Parametry přenosu, které je možné ovlivňovat pomocí systému QoS jsou [1]:
Bandwidth – šířka pásma (datová propustnost)
Delay – odezva (zpoždění) mezi odesláním a přijmutím paketu
Jitter – velikost kolísání odezvy
Packet loss – ztrátovost paketů
2.1 Principy QoS 2.1.1 Best-effort service Tato metoda nevyužívá žádných nástrojů QoS pro optimalizaci datového toku. Jedná se v podstatě o běžný stav před nasazením QoS. Je to pouze snaha o nejrychlejší a co možná nejúspěšnější doručení paketů od zdroje k cíli. Není řešena priorita kritických toků, provoz není nikterak klasifikován. V okamžiku zaplnění šířky pásma se začnou nové pakety, přesahující tento pomyslný strop, zahazovat. Tento velmi jednoduchý algoritmus zahazování se označuje jako tail drop [1, 2].
2.1.2 Integrated services (IntServ) Zřídka používaná metoda, která je specifická svým požadavkem na rezervaci cesty. Cesta je rezervována napříč celou sítí od zdroje k cíli. Protokol, který tento proces zajišťuje, se nazývá Resource ReSerVation Protocol (RSVP). Spolu s požadovanou šířkou pásma se postupně mezi zařízeními předává i požadavek na rychlost odezvy. Toto má na starosti funkce Resource reservation (rezervace zdrojů). Druhou nezbytnou funkcí je Admission control (řízení přístupu), která říká, jak se má k takto signalizovanému požadavku přistoupit. Požadavek na rezervaci je po dobu navázané
9
rezervace opětovně odesílán, teprve když požadavek není poslán, je vyhrazená cesta po určité době zrušena [1, 2]. Příkladem může být požadavek na rezervaci pásma o šířce 64kb/s s požadavkem na normální odezvu pro komunikaci s kritickou aplikací, případně pásmo o šířce 256kb/s s požadavkem nízké odezvy, pro využití IP telefonů. Komunikace pak přednostně proběhne s dostatečnou šířkou pásma, přestože je jinak pásmo zaplněné. Šířka pásma je stále rezervovaná, i když patřičný datový tok využívá jen zlomek vyhrazené šířky [1, 2]. Z požadavku rezervace cesty od zdroje k cíli plyne nevýhoda v nutnosti podpory všech zařízení v cestě. Další významnou nevýhodou je velká výpočetní náročnost tohoto protokolu, jelikož rezervovanou cestou lze použít pouze pro jeden datový tok (např. IP telefony – protokol SIP) [1, 2].
2.1.3 Differentiated services (DiffServ) V praxi nejpoužívanější metoda. Můžeme ji považovat za následníka IntServ. Podstatným rozdílem je řízení toku na základě klasifikace do tříd, se kterými pak pracují nástroje QoS. Jde o efektivní metodu, která nevyžaduje pevnou rezervaci určité šířky pásma, její snahou je upřednostnění kritického datového toku před ostatním. Předem není vyjednána cesta od zdroje k cíli, tudíž není vyžadována podpora všech zařízení v cestě. Značka datového toku platí v rámci sítě a každé zařízení aplikuje pravidla na značky po svém (může i značku přepsat). Tento způsob se nazývá Per-Hop Behavior (PHB). Přes nepodporované zařízení značený tok projde také, ovšem bez jakéhokoliv zpracování, což degraduje snahu na zbylé části cesty [1, 2]. Značení se děje na 3. vrstvě ISO/OSI a zapisuje se do hlavičky IP paketu. Konkrétně se jedná o pole ToS (Type of Service) o šířce 8 bitů. V něm je pole DSCP (Differentiated Services Codepoint) o vyhrazené šířce 6 bitů. DSCP nahradilo původní IPP (IP precedenci), se kterou je zpětně kompatibilní. Zbylé 2 bity nejsou využity. Vše je patrné z následujícího znázornění hlavičky IP paketu a její ToS části [3, 4].
10
Obrázek 1: Hlavička IP paketu s polem ToS [4]
Zpracování datového toku probíhá v několika fázích [2]: 1) Klasifikace paketů (rozlišení paketů) 2) Značkování paketů (marking) 3) Řazení do front a plánování (queuing and scheduling) Jednotlivé fáze budou podrobně vysvětleny v dalších kapitolách, přímo na systému MikroTik RouterOS (dále jen ROS), jelikož se v rámci různých systému řeší odlišně. Výše popsané 3 hlavní architektury QoS jsou uvedeny pro teoretický přehled a pochopení principu řízení datových toků. Jejich myšlenkou je řízení během cesty od zdroje k cíli v rámci sítě. Pokud však páteřní infrastruktura není limitujícím faktorem, lze řídit šířku pásma až centrálně u brány k poskytovateli Internetu. To je případ i této práce, nebude proto využito značkovaní pomocí DSCP, ale pomocí značek v ROS.
2.2 Možné přístupy k problematice Řízení šířky se zpravidla děje na rozhraní brány vlastní sítě a předávacího zařízení poskytovatele Internetu. Zařízení, na kterém řízení šířky pásma probíhá, je označováno jako shaper. Nemusí to být však jediné místo. Vhodné je základní řízení pásma již na straně prvku sítě (klienta). Zamezí se tak zahlcení trasy ve vnitřní síti. Jako hardwarový prostředek lze využívat zařízení určené pro tyto účely, případně lze využít UNIX like operačních systémů či routovacích systémů, které lze provozovat jak na běžné x86 architektuře, tak i na síťovém hardwaru s např. MIPSBE architekturou (RouterBoard). Dříve zmíněný efekt neřízené počítačové sítě lze řešit více způsoby. Na trhu se nachází profesionální specializovaná zařízení určená pro řízení šířky pásma, prioritizaci kritické komunikace a obsahující např. ochranu proti DDoS útoku. Dokážou rozpoznat značnou 11
část komunikace. Jako jedno z nejznámějších zařízení je možno uvést Allot NetEnforcer. Jedná se o kompletní zařízení určené pro umístění do racku. Obsahuje několik ethernet portů pro zapojení do kaskády. Důraz je tedy kladen na vysokou dostupnost. Výkon postačuje pro řízení rozsáhlé sítě s připojením o rychlosti řádově stovek megabitů (dle konkrétního modelu). Komunikace a správa probíhá prostřednictvím webového rozhraní podobně jako u standardních síťových prvků. Nevýhodou takového komplexního systému je návratnost investice, pro menší instituce je nepřípustná. Naopak druhá z možností je přívětivá svou cenou, nicméně je potřeba vynaložit čas ruční konfiguraci pro danou síť. Jedná se o konfiguraci pravidel na vhodné distribuci operačního systému Linux. Oblíbené jsou distribuce založené na Red Hat Enterprise Linux a Debianu a další z nich vycházejících, například CentOS. Na provoz je zapotřebí serveru, ať už ve fyzické, nebo virtuální podobě. Nevýhodou je tedy obtížnější implementace do sítě, nicméně správce má absolutní volnost v konfiguraci. Z toho plyne další nevýhoda, a to obtížná konfigurace, kterou nelze provést bez patřičných znalostí Linuxu a problematiky řízení pásma. Posledním řešením se budu v rámci této práce zabývat. Jde o výše zmiňovaný routovací systém ROS. Jádro tohoto systému vychází z jádra operačního systému Linux, je to tudíž velmi podobný systém. Na rozdíl od Linuxu je ROS kompatibilní se síťovým hardwarem na architektuře MIPSBE či PowerPC (desky MikroTik RouterBoard). Existuje verze pro x86 architekturu, nicméně pro nenáročné řízení provozu lze použít RouterBoardy, které jsou kompaktní a mimořádně úsporná zařízení. Konfigurace a správa probíhá skrze grafickou aplikaci Winbox, což je hlavní ulehčení oproti konfiguraci na čistém Linuxu. Nevýhoda v nutnosti vynaložit čas pro konfiguraci je zde také.
12
3 MikroTik RouterOS ROS vyvíjí firma MikroTik již řadu let. Jeho jádro vychází z linuxového jádra, jedná se tedy o stabilní systém podporující celou řadu platforem. Vydává se v podobě ISO obrazu pro x86 architekturu, nicméně nejrozšířenější je v podobě předinstalovaných balíčků na tzv. embeded zařízeních (síťový hardware MikroTik RouterBoard). Zařízení MikroTik RouterBoard se vyrábí v mnoha variantách, od čistě bezdrátových jednoportových zařízení určených pro klienty či point-to-point spoje, až po výkonná zařízení v provedení do racku, které lze využít např. jako firemní brány s VPN serverem, firewallem atp. Určité řady RouterBoardů disponují různými sloty pro další rozšíření, např. miniPCI sloty pro Wi-Fi moduly, slotem na SIM kartu pro využití mobilní sítě, nebo sloty pro paměťové karty. Třetím významným produktem firmy MikroTik byl monitorovací systém The Dude. Systém je k dispozici zdarma a je funkční bez větších problémů. Z důvodu rozpadu vývojářského týmu však jeho poslední verze zůstala ve stádiu betaverze. Systém nabízí množství nástrojů, které dokážou monitorovat, konfigurovat a ovládat systém ROS centrálně. Příkladem a zajímavým nástrojem je spektrální skenování pásma o určitém rozsahu frekvence. Zařízení třetích stran lze monitorovat pomocí protokolu SNMP (Simple Network Management Protocol). ROS také nabízí možnost skriptování. To významně rozšiřuje již tak široké spektrum využití. Používá se vlastní shell od MikroTiku, který je velmi dobře zdokumentován. Oproti firmwaru běžného síťového hardwaru má uživatel v ROS naprostou volnost při konfiguraci.
3.1 Systém komunikace Pro ovládání a konfiguraci ROS slouží primárně GUI aplikace Winbox. Další možností je komunikace pomocí telnetu a SSH. Přestože ROS vychází z Linuxu, terminál má vlastní jazyk shellu. Oba tyto způsoby dovolují plné ovládání. Zvlášť důležitý je MAC-Telnet. Jde o komunikaci na 2. vrstvě ISO/OSI bez ohledu na IP protokol. Hojně se využívá při přečíslování IP rozsahů sítě nebo změně routování, kdy nehrozí, že správce ztratí spojení se zařízením.
13
Na rozdíl od běžných síťových prvků je zde webové rozhraní druhořadé a nedovoluje plné ovládání. Teprve nedávno MikroTik spustil webové prostředí Webfix, které má vzhled podobný právě Winboxu a s každou aktualizací se mu pomalu blíží i možnostmi ovládání. ROS rovněž nabízí rozhraní API, díky kterému lze ovládání převést do aplikací v různých programovacích jazycích.
Obrázek 2: Prostředí Winbox
3.2 Klasifikace a značkování paketů Značkování paketů (obecně označováno jako manglování z anglického mangle), je jednou z nejdůležitějších částí celkového systému řízení. Paket přicházející do sítě nebo naopak paket odcházející dostane v systému jednoznačnou značku, pomocí které ho systém řízení šířky pásma rozpoznává a třídí do patřičných pravidel. Značku nepoužívá jenom systém řízení, ale například i firewall či NAT. Značka platí v rámci konkrétního zařízení (není součástí hlavičky IP paketu), nepřenáší se tedy dál po síti. Podle druhu použití se aplikují různé značky. Pakety pro použití ve statickém routování se značkují pomocí mark-routing, pakety pro firewall, NAT a systém řízení
14
šířky pásma dostávají značku mark-packet. Obvykle se využívá dvou pravidel pro každý směr datového toku (upload a download).
3.2.1 Typy značkování Ve fázi manglování se musíme rozhodnout, jakým způsobem a na jaké části provoz budeme rozdělovat. Možnosti jsou následující: 1) Dle IP adresy (3. vrstva ISO/OSI) Provoz dělíme na jednotlivé IP adresy (na jednotlivé klienty sítě), případně na rozsahy IP adres (sektory, části LAN). V této konfiguraci přidělíme každé IP adrese určitou šířku pásma a je jen na klientovi, jakým způsobem ji využije. 2) Dle portu či protokolu (3. vrstva ISO/OSI) Systém vhodný pro řízení pásma v podnikové síti. Cílem je přidělit pásmo různým protokolům nebo službám na základě čísla portu. Můžeme například vyhradit pásmo pro VoIP a nastavit vyšší prioritu, než například FTP přenosu či SMTP komunikaci. 3) Pomocí L7 filtru Tato možnost je v ROS dostupná od verze 3 a rozpoznává provoz na úrovni sedmé vrstvy modelu ISO/OSI. Na Internetu jsou k dispozici regulární výrazy, pomocí kterých se provoz rozpoznává. Lze rozpoznat například SIP protokol, Skype, Jabber, konkrétní P2P sítě, komunikace s herními servery atd. Bohužel celá řada dostupných regulárních výrazů je nefunkční nebo jen částečně funkční. Situaci neulehčují ani vývojáři různých BitTorrentových klientů. Ti záměrně v nastavení nabízí možnost komunikovat na TCP protokolu s portem 80, tváří se tedy jako webová komunikace a není možné je těmito způsoby identifikovat. Rovněž výkonově je tato metoda poměrně náročná. Celkově L7 filtr nedosahuje dle mého názoru takových výsledků, aby mohl být reálně nasazen.
15
3.2.2 Řetězec (Chain) Manglování musíme dále přizpůsobit i konkrétnímu zapojení systému řízení v síti. Záleží, zda na stejném zařízení se provádí NAT a na počtu interfaců v daném zařízení. Podle pořadí routování a značkování dělíme tzv. řetězce (anglicky chains) na: 1) Prerouting Paket je označen ještě před rozhodnutím o směrování. Tento chain se většinou využívá v případě, že na zařízení, kde řešíme řízení pásma, není konfigurován NAT (maškaráda), nebo má toto zařízení více vnitřních rozhraní. Tento chain také použijeme u značkování spojení a paketů pro následné statické routování (mark-routing a mark-connection). 2) Postrouting Paket je označen až těsně předtím, než opustí výstupní port. Někdy se využívá pro značkování uploadu. 3) Forward Paket je označen bezprostředně po rozhodnutí o směrování. Na rozdíl od Preroutingu značkuje Forward ještě před source-NATem, používá se tedy v případě, že na stejném zařízení je i NAT (maškaráda) a pokud je pouze jeden interface pro vnitřní síť. Průchod paketu je možno ilustrovat diagramem na obrázku 1 [12].
Obrázek 3: Průchod paketu "ethernet-to-ethernet"
16
3.2.3 Skok (Jump) Jedná se o jakési roztřídění klientů. Používá se primárně u značkování dle IP. S velikostí sítě výrazně roste i počet pravidel v mangle. Abychom šetřili strojový čas a nezapříčinili zpoždění paketů průchodem, dělíme části sítě na třídy. Můžeme si představit 1000 pravidel v mangle. Právě průchozí paket bude zachycen až pravidlem č. 850, tedy projde celý seznam od začátku. To je značně neefektivní, proto nadefinujeme třídu segment1 pomocí jump pravidla, do kterého budou spadat pakety z určitého IP rozsahu. U ovlivněných pravidel z tohoto rozsahu upravíme chain z forwardu či preroutingu na segment1. Po této úpravě průchozí paket bude zachycen pravidlem jump na základě IP rozsahu, kam spadá a rovnou bude pokračovat na pravidlo č. 850, které je označeno jako segment1. Tím zkrátíme vyhledání pravidla v nejlepším případě pouze na 2 kroky.
3.3 Řazení do front a řízení šířky pásma Šířku pásma můžeme v rámci systému ROS řešit několika způsoby. Běžné je použití front, nicméně pro nenáročné rychlé omezení toku je možné využít vlastnosti bandwidth. Jedná se o vlastnost rozhraní ethernet a je dostupná u vybraných řad RouterBoardů. Nelze nikterak ovlivnit algoritmus řízení, je možné pouze stanovit rychlost toku dat (pouze předdefinované hodnoty). Sofistikovanější metodou s velkou škálou možností nastavení jsou fronty (Queues). Datový tok můžeme řídit dvěma způsoby.
policing - v dokumentaci MikroTiku nazývaný termíny dropper a shaper. Principem je zahození veškerých paketů nad rámec limitu rychlosti.
traffic shaping (formování toku) - MikroTik používá opět jiný termín – scheduling (plánování). Zde dochází k využití zásobníku, který pozdrží pakety a propustí je při uvolnění pásma. Samozřejmě má buffer omezenou velikost, takže po jisté začíná systém zahazovat pakety taktéž.
Termín shaper, který MikroTik uvádí je zavádějící, vzhledem k názvu druhé metody. Z tohoto důvodu budu v dalších částech užívat obecně známých termínů. Obě metody jsou znázorněny na následujícím obrázku z dokumentace MikroTiku.
17
Obrázek 4: Metody řízení datového toku
Parametr, primárně ovlivňující způsob řízení datového toku, je Queue size. Nulová hodnota odpovídá prvnímu případu (policingu), naopak zvyšující se hodnota konverguje k druhému způsobu (shapingu). Velikost tohoto a několika dalších parametrů, je ovlivněna typem fronty (viz kapitola 3.3.4).
3.3.1 HTB (Hierarchical Token Bucket) Jedná se o algoritmus řízení, na základě kterého pracují fronty. V rámci ROS je pouze použito jiné terminologie u parametrů. CIR (Committed Information Rate) – v terminologii MikroTiku se jedná o parametr limit-at a udává garantovanou šířku pásma pro danou frontu. MIR (Maximal Information Rate) – dle MikroTiku parametr max-limit, udávající maximální šířku pásma pro frontu. Další důležité parametry jako priority a burst se v ROS neliší a budou popsány níže. Princip algoritmu je jednoduchý a je znázorněn na následujících dvou obrázcích. Již z názvu je patrné, že se jedná o pomyslný kbelík, který je plněn tzv. tokeny a to rychlostí CIR. Kbelík má velikost určenou parametrem burst. Každý příchozí paket se spojí s jedním tokenem a úspěšně odchází. Pokud dojdou tokeny, přicházející pakety se začnou zahazovat, dokud opět tokeny nebudou k dispozici. Toto je metoda policing. U shapingu je princip stejný, pouze se objevuje buffer (Queue size), ve které pakety mohou čekat. Po zaplnění bufferu se pakety opět začnou zahazovat, jak je patrné z obrázků. 18
pl ně ní to keny K B E L IK S TO K E NY
TO K E N PAKET PAK E T
Obrázek 5: HTB algoritmus pro policing
pl ně ní to keny PAKET
K B E L IK S TO K E NY PAKET
PAKET TO K E N PAKET PAK E T
Obrázek 6: HTB algoritmus pro shaping
3.3.2 Simple queue (jednoduchá fronta) Jedná se o jednoduchý typ fronty. Lze řídit určitou část provozu, která byla označkována, či provoz na konkrétním rozhraní. Jednotlivá pravidla spolu nijak nesouvisí. Používá se pro základní stanovení pásma pro klienty, hlavně maximální rychlosti (max-limit) s možností vyšší počáteční rychlosti po určitou dobu od zahájení přenosu – tzv. burst. Není garantována minimální šířka pásma. Jedno pravidlo pokrývá download i upload.
3.3.3 Queue tree (stromová struktura) Jak již název vypovídá, jedná se o frontu se stromovou hierarchií. Stejně jako u Simple queue je možno stanovit maximální šířku pásma, burst a navíc garantované (minimální) pásmo (limit-at). Jedno pravidlo pokrývá jeden směr toku dat. 19
Každé pravidlo má nadřazené rodičovské pravidlo (parent). Maximální šířka pásma každého pravidla je menší rovna maximální šířce parentu. Podobně garantovaná (minimální) šířka pásma musí být menší rovna garantované šířce parentu, ovšem s rozdílem, že součet všech hodnot pravidel musí být menší rovno parentu. Parenty mají také své rodičovské pravidlo a hodnoty šířek pásma odpovídají stejnému systému. Nejvyšší pravidlo má nastavenou rychlost síťového připojení (linky) jak u maximální, tak u minimální šířky pásma. Pravidlo má jako svůj parent nastaveno global. Tento parent reprezentuje celkový datový tok skrze zařízení. Tento systém je obzvláště vhodný pro spravedlivé rozdělení pásma mezi klienty nebo mezi různé protokoly a porty. Rovněž lze snadno vytvořit rychlostní tarify a jednoznačně určit agregaci (poměr počtu klientů na šířku pásma). Pokud jsou pakety značkovány dle protokolu či portu, může být užitečná možnost stanovení priority daného pravidla nebo celé větve stromu, kdy 8 je nejnižší a 1 nejvyšší priorita. Obzvláště vhodné to je pro prioritizaci VoIP nebo obecně SIP protokolu. Celý systém je patrný z obrázku 7.
Obrázek 7: Queue Tree
3.3.4 Queue type (typ fronty)
BFIFO, PFIFO, MQ PFIFO – fungují na principu fronty FIFO (First In First Out) a posílá pakety v pořadí, v jakém je dostane. První znak v názvu uvádí, jaké objekty jsou ve frontě (B – bytes, P – packets, MQ – multi queue, stejný princip, pouze více front současně). Hodí se pro omezování na linkách, kde nehrozí přetížení, typicky pro řízení v LAN (Local Area Network). Velikost fronty (Queue size) je standardně 50 bajtů [9]. 20
PCQ (Per Connection Queue) – tento algoritmus usnadňuje konfigurace fronty pomocí identifikátoru. Pokud se do identifikátoru nastaví např. rozsah zdrojových adres, může být použito jedno pravidlo, a přesto bude omezovat každou IP adresu z daného rozsahu [9].
RED (Random Early Detection) – tzv. statistické zahazování paketů. Výhodou je, že tento algoritmus dokáže zamezit špičkám, a tím přetížení linky [9].
SFQ (Stochastic Fair Queuing) – dělení pásma spravedlivě mezi jednotlivé relace (sessions), nepřiděluje tedy pásmo IP adresám. Vhodné pro přetížené linky (Wi-Fi) [9].
21
4 Implementace Systém řízení pásma se bude aplikován ve fungující menší, ale poměrně rozlehlé bezdrátové síti. Jak již bylo v úvodu řečeno, systém řízení bude implementován na systému MikroTik ROS ve verzi 6.2. Aktuální verze nese označení 6.12, nepřináší však nic zásadního pro toto využití. U systému ROS je dobrý zvykem zůstávat na verzích, které fungují stabilně v daném použití a splňují potřeby konfigurace. Systém bude pracovat na platformě x86 ve virtuálním prostředí, viz kapitola 4.1.2.
4.1 Prostředí pro implementaci 4.1.1 Struktura sítě Bezdrátová síť čítá kolem 200 klientů zahrnujících firmy, kterým poskytuje bezdrátové Wi-Fi připojení k Internetu, převážně ve standardu 802.11a. Síť je kompletně routovaná a tvoří ji přibližně 40 zařízení MikroTik RouterBoard. Ty jsou navzájem propojené páteřními spoji taktéž na technologii Wi-Fi ve standardu 802.11a případně 802.11N. Pro připojení klientů je k dispozici 17 vysílacích sektorů. Síť je k poskytovateli připojena prostřednictvím poslední míle (last-mile) realizované pomocí rádiového spoje v pásmu 10Ghz (Summit Development QAM) rychlostí symetrických 60Mbit/s.
4.1.2 Zapojení systému řízení do sítě Hardwarem budu 2 hypervizory, které se nachází v serverovně na rozhraní sítě. Toto místo je zároveň hlavním uzlem sítě, ze kterého jsou směrované spoje do všech destinací. Primárním prvkem na tomto bodě je zařízení MikroTik RouterBoard 493AH, které zajištuje veškeré směrování (routing) do sítě. Disponuje devíti LAN porty a dvěma bezdrátovými kartami s následující konfigurací:
ether3 – veřejná IP adresa s přívodem od předávacího zařízení poskytovatele (Summit QAM). Po nasazení systému řízení je přívod přímo do serveru, viz dále. 22
ether2 – vlan 99 – shaper (ROS se systémem řízení šířky pásma)
ether4 – vlan 2 – DNS server, monitorovací server (Windows Server 2008 R2) – vlan 20 – veřejné IP adresy – další servery, VPN server atd.
Takto tagované pakety putují do řiditelného L3 switche (prostřednictvím trunk portů). Na switchi jsou rozbalené na určité porty. Výstupem ze switche jsou 2 trunk porty. Každý z nich míří do jednoho ze dvou serverů. Servery jsou 2 identické stroje DELL PowerEdge 2950III s procesory Intel Xeon L5420 a 16GB FB-DIMM operační paměti. Diskový SAS (Serial Attached SCSI) řadič Perc obsluhuje 4 vysokootáčkové (15k) disky z řad enterprise. Disky jsou zapojeny do pole RAID 1 (zrcadlení). Síťové karty jsou však k dispozici pouze 2, pokud nepočítáme kartu pro vzdálenou správu serveru. Z tohoto důvodu do serveru směřuje trunk s VLANy (Virtuální LAN) do jedné a přívod od poskytovatele do druhé síťové karty. Jako hypervizor slouží Vmware ESXi 5, na němž je již několik virtuálních apliancí. VLANy jsou rozbaleny do virtuálních vmxnet síťových karet. Takto jsou nastaveny oba servery, čímž je zaručena naprostá redundantnost. Virtuální apliance je však nutné migrovat ručně při problému s jedním serverem. ROS bude nasazen také ve virtuálním prostředí, čímž se eliminují náklady na provoz samostatného RouterBoardu či serveru. Zároveň poskytuje x86 architektura výrazně více výpočetního výkonu, pro náročné značkování stovek pravidel a řízení desítek až stovek megabitů datového toku.
4.2 Klasifikace a značkování paketů S ohledem na bezdrátový typ sítě bude značkován každý klient a jeho download a upload. Bude to tedy systém značkování dle IP. Vysílací sektor má určitou omezenou datovou propustnost. Pokud datový tok dosáhne stropu, začnou významně růst latence. Proto bude v současnosti prioritou tento způsob značkování a bude na klientovi, jakým typem provozu si své pásmo zaplní.
23
Obrázek 8: Pravidla pro značkování paketů
Počet klientů se neustále zvyšuje, a tak stále narůstá počet pravidel pro značkování. Pro urychlení cesty paketu a snížení nároku na výpočetní výkon, připadá na každý vysílací sektor v síti jedno forward jump pravidlo. To nasměruje pakety z rozsahu vysílacího sektoru na chain s patřičným názvem sektoru. Tam se nachází pravidla pro upload a download každého klienta.
Obrázek 9: Pravidla jump pro optimalizaci
Tímto způsobem se označkuje veškerý známý provoz. Pokud se ale v síti objeví nový klient a ještě není zadán do systému řízení, celý proces řízení pásma by degradoval. Z toho důvodu je vhodné značkovat provoz, který propadne všemi pravidly, a označit ho pomocí mark-paketu značkou no-mark.
24
4.3 Řazení do front a řízení šířky pásma Řízení šířky pásma bude mít podobu stromové struktury (Queue Tree). Pro download i upload bude zvláštní strom. Pravidla budou mít algoritmus SFQ, který je vhodný pro Wi-Fi. Každý směr bude rozdělen na oblasti sítě, ty dále na sektory a konečně na jednotlivé klienty. Maximální rychlost rodičovského pravidla (parent) závisí na použité technologii na daném sektoru. Pro standard 802.11a je stanovena rychlost sektoru na 20Mbit, v případě staršího 802.11g to je pouze 12Mbit. Pro upload budou vzhledem k bezdrátové technologii rychlosti poloviční. Rychlost hlavního download pravidla je záměrně snížena, aby vytížení linky nešlo až na samý strop. V tom případě by přišel ke slovu systém na straně poskytovatele a sám by začal provoz omezovat. Každý sektor a klient má vyhrazené pásmo. Je zřejmé, že v této síti se nevyužívají rychlostní tarify, ale je nabízena maximální možná sdílená rychlost dle lokality s důrazem na spravedlivé dělení. Ukázka řešení na obrázku 10 (pouze část download stromu).
Obrázek 10: Implementované Queue Tree
4.4 Správa a údržba S přibývajícími a ubývajícími klienty je třeba aktualizovat pravidla v systému řízení. V první řadě je nutno upravit značkování a poté stromovou strukturu Queue Tree, kde je potřeba vypočítat novou hodnotu garantované rychlosti pro klienty daného sektoru. Toho je možné docílit ruční úpravou pravidel přes GUI ve Winboxu. Druhou možností
25
je úprava příkazem přes terminál. Přidání queue pravidla a úprava rychlostí pro všechny uživatele sektoru vypadá následovně. queue tree add parent=Sektor1 packet-mark=mark-paket1 limit-at=1M max-limit=5M Toto pravidlo přidá do sektoru Sektor1 klienta s minimální šířkou pásma 1Mbit a maximální 5Mbit. Následující pravidlo nastaví všem klientům na sektoru novou minimální šířku (5Mbit / 5 klientu = 1Mbit/klient). queueu tree set [find parent=Sektor1] limit-at=1M Oba způsoby jsou značně nepohodlné a zdlouhavé při větších změnách. Z tohoto důvodu je vhodné využít rozhraní API a tyto úkony řešit vlastní aplikací. Administrátor získá jistotu správnosti dat a celý proces přidání / smazání klienta zabere nejvýše pár vteřin.
26
5 Aplikace pro správu a údržbu Součástí mé bakalářské práce je desktopová aplikace, která pracuje s výše vytvořeným systémem řízení. Aplikace v současné době nedokáže samostatně vytvořit stromovou strukturu sítě v ROS, jelikož možností je mnoho a aplikace by nabývala na rozsahu a složitosti. V konečné fázi by bylo vytvoření systému řízení podobně náročné, jako pomocí nástroje Winbox. Cílem aplikace je převzít hotový systém řízení a maximálně zjednodušit administraci klientů. Dalším žádaným cílem je eliminace chyb při aktualizaci záznamů. MikroTik ROS je v tomto směru benevolentní a dovolí vytvoření v podstatě jakéhokoliv pravidla, včetně duplicitního. Aplikace umožnuje aktualizovat údaje jako jsou názvy vysílacích sektorů, IP rozsahy či rychlosti, ovšem v rámci aplikace, nikoliv v systému řízení na ROS. Tam je nutné případný nový sektor začlenit do stromové struktury a přehodnotit limit-at (CIR) rychlosti.
5.1 Vývojové prostředí Aplikace je formulářová a stojí na platformě .NET, cíleně na starší verzi 4.0. Aktuální verze .NET Frameworku je 4.5.1, nicméně nepřináší žádná vylepšení, které by bylo možné zužitkovat v této aplikaci. Verze 4.0 lépe zajistí kompatibilitu na starších či neaktualizovaných operačních systémech Windows, kde nemusí být nutně nová verze instalována. Aplikace je vyvíjena v prostředí Microsoft Visual Studio 2013, programovacím jazykem je C#. Důvodem volby platformy .NET a jazyka C# jsou zkušenosti nabyté studiem na této škole a také vize tvorby mobilní aplikace pro Windows Phone 8.1. Windows Phone SDK (vývojový kit) pracuje se stejnými knihovnami a je pouze ochuzen o některé implementace metod a tříd.
5.2 MikroTik API Aplikace využívá ke komunikaci s ROS rozhraní API (Application Programming Interface). API je dostupné od ROS verze 3 a naslouchá implicitně na portu 8728. Nutností je povolit službu v ROS, v továrním nastavení je zakázána.
27
5.2.1 Protokol Komunikace probíhá zasíláním dat do ROS, který je zpracuje a zašle zpět odpověď. Struktura příkazu (věty) je následující [10]:
Délka – délka slova (část příkazu) zakódovaná do pole bajtů o velikosti 1 až 5, dle následující tabulky.
Data (slova) jako pole bajtů.
Ukončovací znak – bajt 0 se posílá po posledním slově (části příkazu) jako symbol pro ukončení.
Kódování délky je určeno protokolem dle délky slova a znázorňuje ho následující tabulka [10]. Tabulka 1: kódování délky slova
délka slova
počet bajtů
zakódování délky
0 <= len <= 0x7F
1
len, lowest byte
0x80 <= len <= 0x3FFF
2
len | 0x8000, two lower bytes
0x4000 <= len <= 0x1FFFFF
3
len | 0xC00000, three lower bytes
0x200000 <= len <= 0xFFFFFFF
4
len | 0xE0000000
len >= 0x10000000
5
0xF0 and len as four bytes
Slova věty se dělí do pěti skupin: 1) Command word Slovo obsahující cestu a klíčový příkaz, který říká systému ROS, jakou akci má provést. Akcemi se rozumí přidání, mazání, editace, výpis, login atd. např. /ip/firewall/mangle/add (požadavek na přidání záznamu do mangle - značkování)
28
2) Attribute word Obsahuje specifikaci konkrétní hodnoty atributu v daném umístění (určeném cestou v command word). např. =action=mark-packet (v pravidle pro značkování se nastaví atribut action na hodnotu mark-paket) 3) API attribute word V současnosti jediným atributem je tag. Jedná se o identifikační značku věty (příkazu), kterou následně ROS použije do odpovědi. Pokud by bylo zapotřebí, lze tak jednoznačně identifikovat dvojice věta-odpověď. např. .tag=oznaceniVety 4) query word Slouží pro filtraci výstupu. Užívá jej příkaz print. Je možné specifikovat položky podle názvu, podle hodnoty, rozsahu hodnoty atd. Filtry je možné dále řetězit pomocí logických operátorů. Syntaxe začíná vždy znakem otazníku. Např. /interface/print ?type=ether (specifikuje položky, kde hodnota atributu type je rovna ether) ?type=vlan (specifikuje položky, kde hodnota atributu type je rovna vlan) ?#| (logický operátor OR, je uveden na konci věty a upřesňuje vztah mezi
přechozími filtry) 5) reply word Odpověď (reakce) zasílaná systémem ROS na každou přijatou větu. Např. =!done
5.3 Implementace aplikace Aplikace komunikuje se systémem ROS prostřednictvím převzaté třídy zajišťující komunikaci s MikroTik API. Přístup do aplikace je zabezpečen přihlášením pomocí účtu ROS. 29
Po přihlášení je možné zadávat respektive mazat záznamy (uživatele) zadáním jména, sektoru a IP adresy, nebo pouze sektoru a IP v případě mazání. Aplikace umožňuje výpis všech záznamů, již zmíněnou editaci dat a dále obsahuje potřebné údaje pro vysvětlení funkce položek v menu nastavení. Část těchto funkcionalit lze volat klávesovými zkratkami. Aplikace intuitivně informuje o průběhu prováděných akcí a srozumitelně vypisuje informace o nastalých výjimkách.
5.3.1 Data aplikace Aplikace obsahuje inicializační data pro správný běh v síti, kde je systém řízení nasazen. Pro lepší použitelnost aplikace v jiných sítích je možné data editovat (IP rozsahy, názvy sektorů, atd.). Po editaci hodnot ze strany uživatele jsou změny zaznamenány do textových souborů. Aplikace pracuje pouze s hrstkou konstant a s inicializačními daty. Pro takové množství dat je nadbytečné mít databázi. Soubory s daty, stejně jako soubor s uloženými přístupovými údaji, jsou uloženy v profilu uživatele. Konkrétní cesta ke složce je %appdata%/SG_client. Tato složka se vytváří při první editaci či uložení přihlašovacích údajů. Pokud bude aplikace využita v síti, pro kterou je implementována, vystačí si s inicializačními daty a nebude tak zbytečně ukládat data na disk. Přihlášený uživatel je v patřičném formuláři titulkem seznámen s faktem, že se mu tato složka v počítači vytvoří. Záměrně nebylo zvoleno uložiště programu v C:\Program Files\ s ohledem na doménové uživatele. V jejich případě by došlo k uložení na lokální disk, kam navíc v rámci domény často nemá uživatel práva pro zápis. Po následném přihlášení k doménovému účtu na jiném počítači budou data opět chybět a na přechozím počítači zůstanou opuštěna na disku i po smazání profilu uživatele. Z tohoto důvodu je zvolen adresář %appdata%, který je součástí profilu (i cestovního). Veškerá ostatní data, jako např. seznam pravidel značkování, se načítají a odesílají do systému ROS v reálném čase.
30
5.3.2 Třídy aplikace K nejdůležitější třídě patří třída MikroTik.cs, která se používá pro komunikaci s API systému ROS. Třída je převzata a mírně upravena z oficiální dokumentace MikroTiku [11]. Navazuje se zde spojení s ROS prostřednictvím tříd NetworkStream a TcpClient. Pro komunikaci slouží metody Send a Read. Metoda Send přijímá parametrem příkaz (slovo odesílané věty) a na základě protokolu API jej odesílá systému ROS. V druhém parametru přijímá logickou hodnotu udávající, zda věta končí nebo bude dále pokračovat. public void Send(string command, bool end) { byte[] bytes; byte[] size; bytes = System.Text.Encoding.ASCII.GetBytes(command); size = EncodeLength(bytes.Length); connection.Write(size, 0, size.Length); connection.Write(bytes, 0, bytes.Length); if (end) connection.WriteByte(0); }
Na základě protokolem určeného výpočtu délky, který znázorňuje Tabulka 1: kódování délky slova, se pomocí metody EncodeLenght vytváří pole bajtů. V následující ukázce je znázorněno kódování pro délku slova menší než 80h. Výstupem je pole o velikosti 1. Analogicky jsou v metodě zpracovány zbylé 4 možnosti. byte[] EncodeLength(int delka) { if (delka < 0x80) { byte[] tmp = BitConverter.GetBytes(delka); return new byte[1] { tmp[0] }; } … }
Metoda Read načítá cyklicky délku slova, které je v odpovědi. Opět dle protokolu je hodnota dle velikosti zachycena patřičnou podmínkou v metodě a je vypočítána zakódovaná délka.
31
tmp[3] = (byte)connection.ReadByte(); if (tmp[3] < 0x80) { count = tmp[3]; } else { if (tmp[3] < 0xC0) { int tmpi = BitConverter.ToInt32(new byte[] { (byte)connection.ReadByte(), tmp[3], 0, 0 },0); count = tmpi ^ 0x8000; } … }
Výsledná hodnota (v ukázkovém kódu značena „count“) délky je použita v cyklu, který postupně načítá znaky odpovědi a vytváří z nich řetězec. Výsledný řetězec (značený „o“) je při dalším průchodu přidán do kolekce List<string>, která je výstupem celé funkce. for (int i = 0; i < count; i++) { o += (Char)connection.ReadByte(); } Metoda login zajištuje přihlášení k ROS z prostředí aplikace. public bool Login(string username, string password) { Send("/login", true); string hash = Read()[0].Split(new string[] { "ret=" }, StringSplitOptions.None)[1]; Send("/login", false); Send("=name=" + username, false); Send("=response=00" + EncodePassword(password, hash), true); string state = Read()[0]; if (state == "!done") { return true; } else { throw new Exception("Špatné jméno nebo heslo."); } }
32
Aplikace odesílá command word login. ROS vrací řetězec použitý pouze při dané relaci. Tvar obdržené odpovědi obsahuje reply word, proto se čistý řetězec musí získat použitím funkce Split. Následně se odesílá věta obsahující command word login spolu s uživatelským jménem a zakódovaným heslem. V případě úspěšného přihlášení ROS vrací potvrzující reply word. V případě chyby je vyhozena výjimka. Kódování hesla se děje v metodě EncodePassword. Jejími parametry jsou heslo v podobě řetězce a ověřovací hash řetězec, který ROS vrátil po zaslání příkazu login. V metodě se oba parametry převedou a sloučí do jednoho pole bajtů. Toto pole je zahashováno algoritmem MD5 a znovu převedeno na výsledný string. public string EncodePassword(string Password, string hash) { byte[] hash_byte = new byte[hash.Length / 2]; for (int i = 0; i <= hash.Length - 2; i += 2) { hash_byte[i / 2] = Byte.Parse(hash.Substring(i, 2), System.Globalization.NumberStyles.HexNumber); } byte[] heslo = new byte[1 + Password.Length + hash_byte.Length]; heslo[0] = 0; Encoding.ASCII.GetBytes(Password.ToCharArray()).CopyTo(heslo,1); hash_byte.CopyTo(heslo, 1 + Password.Length); Byte[] hotovo; MD5 md5; md5 = new MD5CryptoServiceProvider(); hotovo = md5.ComputeHash(heslo); //Convert encoded bytes back to a 'readable' string string navrat = ""; foreach (byte h in hotovo) { navrat += h.ToString("x2"); } return navrat; }
33
Pro uchování klíčových dat programu slouží třída Constants.cs. V současné verzi programu jsou v ní uloženy objekty:
static int spodIntervalMangle
Tato hodnota není klíčová pro běh aplikace. Udává pouze pořadové číslo prvního pravidla značkování na ROS, které souvisí se systémem řízení. Na začátku mangle listu může být mnoho dalších pravidel nesouvisejících se systémem řízení šířky pásma a nechceme, aby tato pravidla byla zobrazena ve výpisu, nebo aby v nich bylo vyhledáváno. Implicitně je nastavena hodnota 30.
static int maxLenghtName
Maximální délka jména klienta, kterou je možné zadat do aplikace. Implicitně nastavena na hodnotu 22.
static bool clientMaxLimitByParent = true
Tato konstanta udává, jak se aplikace zachová při přidávání pravidla do Queue Tree. Pokud je nastavena na true, bude max-limit rychlost klienta odpovídat max-limit rychlosti sektoru. Pokud je false, použije se hodnota max-limit, uložená společně se sektorem. Implicitně hodnota true.
static string ip
IP adresa zařízení (shaperu). Implicitně adresa 79.141.241.50.
static int port
Port rozhraní API. Implicitně port 8728. Třída Sector.cs reprezentuje vysílací sektory sítě. U každého sektoru se uchovává jeho jméno, IP adresa a maximální rychlost (max-limit) klienta daného sektoru. Nejedná se o rychlost daného sektoru, ta je stanovena v systému řízení přímo a aplikace ji neovlivní. Pokud je v menu aplikace zatržena položka rychlost dle parentu, pak tato hodnota není využita (viz popis konstant). Třída obsahuje předefinovanou (override) metodu ToString() z důvodu správného formátování při výpisu ve formulářovém prvku ListBox. Poslední neformulářovou třídou je FileController.cs. Její funkcí je práce s daty a jejich uložení v souborech. Obsahuje metodu pro uložení sektorů do textového souboru. Metoda přijímá kolekci List<Sektor> a pomocí předefinované metody ToString() uloží každý objekt kolekce na vlastní řádek textového souboru.
34
using (StreamWriter sw = new StreamWriter(new FileStream(path + "/sectors.txt", FileMode.Create))) { foreach (var item in sectors) { sw.WriteLine(item); } }
Podobným způsobem je řešeno ukládání přihlašovacích údajů. Údaje jsou uloženy pomocí metody saveCredential v binárním souboru ve složce aplikace. Uživatelské jméno je uloženo přímo, heslo je z důvodu bezpečnosti zašifrováno. Šifrování zajištuje metoda encryptPassword, která v současné konfiguraci převádí řetězec s heslem na pole ASCII hodnot. Každému prvku pole je přičtena hodnota 2. Výsledné pole je zpět převedeno na řetězec. Pro zamezení přečtení hesla je toto dostatečná metoda. Do budoucna je možné implementovat sofistikovanější šifrování v rámci této metody bez zásahu do programu. Posledními ukládanými objekty jsou konstanty. S těmi pracuje metoda saveConstants. V parametru přijímá hodnotu konstanty reprezentovanou řetězcem. Ukládané konstanty mohou být tím pádem různých datových typů a převedením na řetězec se uloží pomocí jediné metody. Místem uložení je složka aplikace a podsložka konstanty, kde každé uložené konstantě přísluší jeden textový soubor. Stejně jako v přechozí metodě pro uložení sektorů je použito třídy StreamWriter. Načítání dat je realizováno pomocí třídy StreamReader. Pro načítání sektorů slouží metoda loadSectors, která načítá jednotlivé řádky textového souboru, dokud nenarazí na konec. Hodnoty na řádcích (jméno, IP adresa, rychlost) jsou v souboru oddělené tabulátory, díky kterým funkce Split z řádku vytvoří pole řetězců. Z vytvořených prvků se vytváří nový objekt třídy Sector a přidává se do kolekce List<Sector>. Tato kolekce je vrácena z funkce a použije se ve vlastnosti DataSource formulářového prvku. Pokud se akce nezdaří, je vrácena hodnota null.
35
using (StreamReader sr = new StreamReader(File.Open(loginPath, FileMode.Open))) { string tmp; while((tmp = sr.ReadLine()) != null) { string[] s = tmp.Split('\t', StringSplitOptions.RemoveEmptyEntries); l.Add(new Sector(s[0], IPAddress.Parse(s[1]), Convert.ToInt32(s[2]))); } } return l;
5.3.3 Formulářové třídy aplikace Po spuštění aplikace se objeví následující rozhraní. Jedná se o hlavní formulář mainForm.cs, ve kterém je implementována většina funkcí. Vlastní kód má kolem tisíce řádků a nebude tedy možné ukázat řešení všech funkcionalit. Stěžejní třída byla popsána v minulé kapitole, zde bude krátká ukázka formulářové části. Kompletní kód je dostupný na přiloženém CD.
Obrázek 11: Rozhraní aplikace - login
Od uživatele je vyžadováno jméno a heslo, které odpovídá účtu v systému ROS. Uživatel má možnost zvolení zapamatování hesla. Bez přihlášení je možné pouze
36
nastavovat IP adresu a port shaperu. Poslední volbou je smazání dočasných dat ve složce %appdata%. Po přihlášení se zobrazí vlastní prostředí aplikace. Nejedná se o nový formulář, jedná se stále o mainForm.cs. Prostřednictvím metody changeForm se upravuje vzhled a viditelnost prvků, dle stavu přihlášení. Možnosti nastavení se rozšířily o správu sektorů a konstant. V aplikaci je kladen důraz na jednoduchost, přehlednost a funkčnost pro maximální zjednodušení administrace klientů. V případě přidání uživatele stačí zadat jméno, jehož tvar upřesňuje okno s tipem, které se zobrazí po kliknutí na otazník. Přesto je vstup ošetřený programově a jméno je z důvodu sjednocení vždy převedeno na malá písmena s velkými úvodními. Po výběru sektoru z roletky je automaticky doplněna IP adresa, kromě posledního oktetu. To spolu s kontrolou duplicity IP adresy a jména eliminuje chyby při zadání.
Obrázek 12: Rozhraní aplikace po přihlášení
Odebírání klienta se děje na základě IP adresy. Pro kontrolu je před samotným smazáním zobrazeno potvrzovací dialogové okno, kde je uvedeno i nalezené jméno k dané IP adrese.
37
//******Test duplicity*********** mk.Send("/ip/firewall/mangle/getall", false); mk.Send("=.proplist=.id,comment,chain,src-address,dst-address", true); List<string> outputMangle = mk.Read(); for (int i = Constants.spodIntervalMangle; i < outputMangle.Count; i++) { if (outputMangle[i].Contains(getIpFromTxb())) { throw new Exception("Záznam s danou IP již existuje."); } if (outputMangle[i].Contains(txb_jmeno.Text)) { throw new NoClearException("Shoda jmen, zadejte jiný tvar jména."); } }
Na tomto kódu je vidět testování duplicity v rámci kontroly před přidáním nového uživatele. Je vidět způsob práce s metodou Send třídy MikroTik.cs a příkazy korespondující s protokolem API. Do kolekce List<string> se nejprve uloží kompletně celý seznam mangle, ovšem pouze data z požadovaných sloupců. Následně se hledá stejná IP a jméno. V případě stejného jména je vyhozena vlastní definovaná výjimka NoClearException, na kterou se reaguje odlišně, než na ostatní (pouze varování a nedochází ke smazání zadaného vstupu). Poslední ukázkou kódu je zajímavá část metody, kde dochází k výpočtu správných rychlostí při každé změně počtu klientů na sektoru. //*******nacteni parent limit-at a max-limit mk.Send("/queue/tree/getall", false); mk.Send("=.proplist=limit-at,max-limit", false); mk.Send(String.Format("?=name={0}", sektor.secName), false); mk.Send(".tag=findParentQueue", true); string parentSpeeds = mk.Read()[0]; char[] delChars = { '=', '.' }; string[] parentWords = parentSpeeds.Split(delChars); int pocet = (output.Count - 1) + zmena; //pricteni pridaneho uzivatele limit = (Convert.ToInt32(parentWords[2]) / pocet) /1000 * 1000; // na Kb if (Constants.clientMaxLimitByParent) { maxlimit = Convert.ToInt32(parentWords[4]); } else { maxlimit = sektor.clientLimit; }
38
for (int i = 0; i < output.Count - 1; i++) { string[] words = output[i].Split(delChars); mk.Send("/queue/tree/set", false); mk.Send(String.Format("=.id={0}", words[3]), false); mk.Send(String.Format("=limit-at={0}", limit), false); mk.Send(String.Format("=max-limit={0}", maxlimit), true); resultCommand(); }
Nejprve se nalezne položka, která má stejný název jako je název vybraného sektoru. Tím nalezneme položku se sektorem (parent). Jsou požadovány pouze sloupce limit-at a max-limit. Získanou kolekci je nutné opět rozdělit funkcí Split. Z dříve získané kolekce klientů vybraného sektoru (output - není vidět v tomto kódu) přičtením změny (-1 nebo 1) dostaneme finální počet klientů v tomto sektoru. To je důležitý údaj pro výpočet garantované limit-at rychlosti. Dále je přiřazena maximální rychlost přidávaného klienta a to na základě nastavení v menu (Max-limit dle sektoru, viz třída Constants.cs v kapitole 5.3.2). Na závěr jsou spočítané hodnoty odeslány do systému ROS na všechny klienty v kolekci. Děje se tak For cyklem, který v ROS identifikuje správná pravidla na základě vnitřního identifikátoru id. Zadané klienty je možné v aplikaci vypsat. Slouží pro to formulář Print.cs, který se vyvolá v menu Soubor – výpis, nebo po stisknutí klávesové zkratky CTRL + P.
Obrázek 13: Rozhraní aplikace - výpis klientů
Ve výsledcích lze vyhledávat psaním do pole vyhledávání. Vyhledávají podřetězce a výsledky se dynamicky mění s každou změnou v dotazu.
39
6 Testování Systém řízení byl úspěšně nasazen a první úspěchy jsou vidět na spokojenosti klientů. Dříve bylo zcela běžné, že si klient stěžoval na nepoužitelnost IP telefonu nebo na velmi pomalé připojení. Pro ukázku funkčnosti systému jsem si vybral situaci, kdy je vysílací sektor zcela vytížen několika klienty najednou.
Obrázek 14: Ukázka činnosti systému řízení
Můžeme vidět, že max-rychlost sektoru 20Mbit je vyčerpána a na sektoru SKOLA2 se provádí shaping (formuje se datový tok). Červená barva pravidla značí datový tok, který se blíží maximu. Zároveň se provádí shaping u jednoho z klientů. Ten má nastavenou maximální rychlost také 20Mbit, ale jelikož jiný klient požaduje šířku pásma 2,5Mbit, je mu to díky systému umožněno. Pokud by oba požadovali např. 20Mbit, každý z nich by byl omezen přibližně na 10Mbit. Zároveň je nutno zdůraznit, že i na takto vytížených sektorech nedochází k růstu odezvy, stále zůstává na 1-3ms s drobnými výchylkami. Bez systému řízení by první klient pravděpodobně využil limitu přenosového pásma, což v praxi znamená narůst odezvy do řádu stovek milisekund. Zároveň by druhý klient pravděpodobně nedostal k dispozici požadovanou šířku pásma.
40
7 Závěr Cílem této bakalářské práce bylo navrhnout a implementovat systém řízení šířky pásma v bezdrátové síti a zároveň bylo cílem vyřešit administraci klientů pomocí aplikace. Oba cíle se povedlo splnit a celé řešení bylo nasazeno do reálného prostředí bezdrátové sítě o 200 klientech. Pokyny k připojení a testovací data pro vyzkoušení jsou uvedena na přiloženém CD. Pro síť má tento systém velmi pozitivní přínos, jak po technické stránce, tak ve spokojenosti klientů (viz kapitola 6). Nyní se bude sledovat chování systému a bude se dále vyvíjet dle zjištěných nedostatků. Tvorba systému řízení šířky pásma byla rovněž přínosem i pro mne. Mé znalosti z oblasti systému MikroTik RouterOS jsem si dále rozšířil o obecnou teorii QoS a objasnil jsem si řadu různých algoritmů a principů činnosti. Cílem dalšího zlepšování systému je například výpočet minimální rychlosti u klientů (garantované pásmo limit-at). Momentálně je přidělena šířka pásma rovnoměrně mezi všechny sektory. Některý má však větší počet připojených klientů, a tudíž výsledné garantované pásmo klientů se na každém sektoru liší. V praxi však nedochází k takovému vytížení sítě, aby klient dostal pouze své garantované minimum, není to tudíž problém stěžejní. S tímto zlepšením úzce souvisí možnost nastavit jednotlivým klientům různé garantované rychlosti a při přidání či odebrání klienta zachovávat poměr těchto rychlostí. Toto ovšem nejsou cíle bakalářské práce, v současné době nejsou ani ve zmiňované bezdrátové síti potřeba, a proto se budou realizovat průběžně. Aplikace je v praxi vyzkoušena a je plně funkční, její vývoj však taktéž stále nekončí. Do budoucna je nutno implementovat několik vylepšení pro intuitivnější obsluhu aplikace. Novinkami může být práce s klienty v okně výpisu nebo například doplňování první volné IP adresy během přidávání nového klienta. Velkou vizí do budoucna je vytvoření verze této aplikace pro mobilní platformu Windows Phone. Správci této sítě až na výjimky používají tuto platformu a možnost administrovat klienty z telefonu by v budoucnu uvítali.
41
Seznam použité literatury [1] Jak funguje řízení datových toků s QoS. [online]. [cit. 2014-05-04]. Dostupné z: http://connect.zive.cz/clanky/jak-funguje-rizeni-datovych-toku-s-qos/sc-320a-161738 [2] Cisco QoS 1 - úvod do Quality of Service a DiffServ. [online]. [cit. 2014-0504]. Dostupné z: http://www.samuraj-cz.com/clanek/cisco-qos-1-uvod-doquality-of-service-a-diffserv/ [3] Cisco QoS 2 - Classification and Marking, Modular QoS CLI. [online]. [cit. 2014-05-04]. Dostupné z: http://www.samuraj-cz.com/clanek/cisco-qos-2classification-and-marking-modular-qos-cli/ [4] Enterprise Medianet Quality of Service Design 4.0. [online]. [cit. 2014-05-07]. Dostupné
z:
http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/WAN_and_MAN/Q oS_SRND_40/QoSIntro_40.html [5] Řízení pásma ve WAN - úvod do problematiky. [online]. [cit. 2014-05-04]. Dostupné
z:
http://www.svetsiti.cz/clanek.asp?cid=Rizeni-pasma-ve-WAN-
uvod-do-problematiky-13122000 [6] MikroTik Wiki: Manual:Queue. [online]. [cit. 2014-05-08]. Dostupné z: http://wiki.MikroTik.com/wiki/Manual:Queue [7] Cisco QoS 3 - omezování rychlosti - Policing, Shaping. [online]. [cit. 2014-0509]. Dostupné z: http://www.samuraj-cz.com/clanek/cisco-qos-3-omezovanirychlosti-policing-shaping/ [8] MikroTik Wiki: Manual:HTB. [online]. [cit. 2014-05-09]. Dostupné z: http://wiki.MikroTik.com/wiki/Manual:HTB [9] MikroTik RouterOS: Řízení datových toků. [online]. s. 3 [cit. 2014-05-09]. Dostupné
z:
http://download.asm.cz/inshop/prod/xtendlan/MikroTik/EM-
MikroTik-Rizeni_datovych_toku.pdf [10] MikroTik Wiki: Manual:API. [online]. [cit. 2014-05-14]. Dostupné z: http://wiki.MikroTik.com/wiki/Manual:API#Protocol
42
[11] MikroTik Wiki: API in C Sharp. [online]. [cit. 2014-05-16]. Dostupné z: http://wiki.MikroTik.com/wiki/API_in_C_Sharp [12] Diagram routing - from Ethernet to Ethernet interface. In: MikroTik Wiki: Manual:Packet
Flow
[online].
[cit.
2014-05-18].
Dostupné
z:
http://wiki.MikroTik.com/wiki/Manual:Packet_Flow
43
Seznam obrázků Obrázek 1: Hlavička IP paketu s polem ToS [4] ............................................................ 11 Obrázek 2: Prostředí Winbox ......................................................................................... 14 Obrázek 3: Průchod paketu "ethernet-to-ethernet" ......................................................... 16 Obrázek 4: Metody řízení datového toku ....................................................................... 18 Obrázek 5: HTB algoritmus pro policing ....................................................................... 19 Obrázek 6: HTB algoritmus pro shaping ........................................................................ 19 Obrázek 7: Queue Tree ................................................................................................... 20 Obrázek 8: Pravidla pro značkování paketů ................................................................... 24 Obrázek 9: Pravidla jump pro optimalizaci .................................................................... 24 Obrázek 10: Implementované Queue Tree ..................................................................... 25 Obrázek 11: Rozhraní aplikace - login ........................................................................... 36 Obrázek 12: Rozhraní aplikace po přihlášení ................................................................. 37 Obrázek 13: Rozhraní aplikace - výpis klientů ............................................................... 39 Obrázek 14: Ukázka činnosti systému řízení .................................................................. 40
44
Seznam tabulek Tabulka 1: kódování délky slova .................................................................................... 28
45
Seznam použitých zkratek API – Application Programming Interface CIR – Committed Information Rate DDoS – Distributed Denial-of-Service DSCP – Differentiated Services Code Point FIFO – First In, First Out GUI – Graphical User Interface HTB – Hierarchical Token Bucket IP – Internet Protocol IPP – Internet Protocol Precedence LAN – Local Area Network MIR – Maximum Information Rate NAT – Network Address Translation PCQ – Per Connection Queuing PHB – Per-Hop Behavior QoS – Quality of Service RED – Random Early Drop ROS – RouterOS SAS – Serial Attached SCSI SDK – Software Development Kit SFQ – Stochastic Fairness Queuing SIP – Session Initiation Protocol SNMP – Simple Network Management Protocol SSH – Secure Shell ToS – Type of Service VLAN – Virtuální LAN VoIP – Voice over Internet Protocol VPN – Virtual Private Network Wi-Fi – Wireless Fidelity
46
Přílohy 1 Obsah přiloženého CD Na přiloženém CD se v kořenové složce nachází tato bakalářská práce ve formátu PDF. Ve složce Zdrojovy_kod se nachází kompletní řešení aplikace – formát MS Solution (.sln) Ve složce Aplikace se nachází spustitelný .exe soubor aplikace a soubor s pokyny pro testování.
47
