Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO

Transkript

1 FAKULTA ELEKTROTECHNIKY A KOMUNIKAČNÍCH TECHNOLOGIÍ VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO Garant předmětu: Ing. Jan Jeřábek, Ph.D. Autoři textu: Ing. Jan Jeřábek, Ph.D. Ing. Jiří Hošek, Ph.D. BRNO * 2014 Vznik těchto skript byl podpořen projektem č. CZ.1.07/2.2.00/ Evropského sociálního fondu a státním rozpočtem České republiky.

2 2 FEKT Vysokého učení technického v Brně Autoři Název Vydavatel Vydání Ing. Jan Jeřábek, Ph.D., Ing. Jiří Hošek, Ph.D. Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO Vysoké učení technické v Brně Fakulta elektrotechniky a komunikačních technologií Ústav telekomunikací Technická 12, Brno první Rok vydání 2014 Náklad elektronicky ISBN Tato publikace neprošla redakční ani jazykovou úpravou.

3 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 3 Obsah 1 ÚVOD VYBRANÉ APLIKAČNÍ PROTOKOLY A JEJICH VLASTNOSTI VYBRANÉ PROTOKOLY VIRTUÁLNÍCH TERMINÁLŮ Terminál, počítačový terminál a emulátor Protokol SSH (Secure Shell) Průběh standardní komunikace (SSH-2) Vrstvy protokolu SSH (verze 2) VYBRANÉ PROTOKOLY PRO PŘENOS SOUBORŮ Bezpečné alternativy k protokolu FTP (File Transfer Protocol) Ukázka zachycení přihlašovacích údajů (login + heslo) Trivial FTP (TFTP) Aplikace RSYNC DOPLNĚNÍ K WWW TECHNOLOGIÍM Rozšiřující technologie zvyšující možnosti HTTP protokolu Proxy servery Protokol HTTPS VYBRANÉ PROTOKOLY PRO PŘENOS ELEKTRONICKÉ POŠTY SMTP (Simple Mail Transfer Protocol) POP3 (Post Office Protocol verze 3) IMAP4 (Internet Message Access Protocol verze 4) VYBRANÁ TÉMATA MANAGEMENTU POČÍTAČOVÝCH SÍTÍ ÚVOD DO MANAGEMENTU SÍTÍ S PROTOKOLEM IP OBLASTI ŘÍZENÍ POČÍTAČOVÝCH SÍTÍ OBECNÁ ARCHITEKTURA MANAGEMENTU INFORMACE PRO MANAGEMENT SÍTĚ ZÁKLADY PROTOKOLU SNMP (SIMPLE NETWORK MANAGEMENT PROTOCOL) Verze protokolu SNMP MODERNÍ KOMUNIKAČNÍ TECHNIKY V PROSTŘEDÍ INTERNETU DISTRIBUOVANÉ SYSTÉMY Distribuované aplikace a systémy Obecná charakteristika distribuovaných systémů Výhody distribuovaných systémů Vnitřní organizace distribuovaných systémů MIDDLEWARE VRSTVA Přístupy k tvorbě middleware vrstvy Služby poskytované middleware vrstvou UKÁZKA PROSTŘEDÍ PRO DISTRIBUOVANÉ APLIKACE.NET FRAMEWORK Základní struktura Stručná historie verzí platformy.net Framework NET REMOTING Architektura.NET Remoting Základní vlastnosti a principy technologie.net Remoting ÚVOD DO PROBLEMATIKY POKROČILÝCH WEBOVÝCH SLUŽEB Komunikace s využitím protokolu SOAP... 47

4 4 FEKT Vysokého učení technického v Brně 5 PROCESY A SYSTÉMY PROBLEMATIKA NÁVRHU SYSTÉMŮ Fáze definice problému Fáze specifikace chování systému Fáze implementace Fáze výroba, nasazení Fáze využívání systému a jeho údržba Ověření správnosti TEORIE KONEČNÝCH AUTOMATŮ Úvod do teorie konečných automatů Kombinační sítě Sekvenční sítě Tabulka přechodů a výstupů Grafická reprezentace konečných automatů PROCESY, PARALELNÍ SYSTÉMY A SOUVISEJÍCÍ POJMY Popis systému Systém reálného času Procesy Paralelní procesy Vznik a zánik procesů KOMUNIKACE A FORMY SYNCHRONIZACE MEZI PROCESY Komunikace mezi procesy Formy synchronizace mezi procesy Uváznutí procesu Problém Producent Konzument Kritéria vzájemného vyloučení procesů Stavový znak (blokovací proměnná) Konstrukce semaforu Kritické oblasti (sekce) Monitory Rendez-vous Vyrovnávací paměti NÁVRH VLASTNÍHO KOMUNIKAČNÍHO PROTOKOLU ÚVOD DO KRYPTOGRAFIE PŘÍSTUPY K ŠIFROVÁNÍ SYMETRICKÉ ŠIFROVÁNÍ ASYMETRICKÉ ŠIFROVÁNÍ VYBRANÉ ŠIFROVACÍ A HASH ALGORITMY DES AES Dokonalá (Vernamova) šifra Diffie-Hellman RSA MD SHA SMĚROVACÍ PROTOKOL IS-IS ZÁKLADNÍ FAKTA O PROTOKOLU IS-IS VYBRANÉ VLASTNOSTI PROTOKOLU IS-IS... 92

5 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO METRIKA PROTOKOLU IS-IS PAKETY PROTOKOLU IS-IS NSAP (NET) - INTERNÍ ADRESY V PROTOKOLU IS-IS OBLASTI A JEJICH IDENTIFIKÁTORY DOPLŇKOVÉ TECHNIKY DOMÉNOVÉHO PŘEKLADU MULTICAST DNS Základní popis protokolu mdns Znaková sada mdns Zprávy v protokolu mdns Formát záhlaví zpráv mdns Porovnání mdns a klasického DNS Protokol mdns a IPv Výhody multicastově přenášených odpovědí v mdns LOKÁLNÍ LINKOVÝ MULTICASTOVÝ PŘEKLAD JMÉNA (LLMNR) Překlad jména pomocí LLMNR Základní pravidla formátování LLMNR zpráv Formát záhlaví Použití protokolu LLMNR KVALITA SLUŽEB V IP SÍTÍCH PARAMETRY SÍŤOVÉHO PROVOZU Z POHLEDU ZAJIŠTĚNÍ QOS ZPOŽDĚNÍ PAKETŮ KOLÍSÁNÍ ZPOŽDĚNÍ ZTRÁTOVOST PAKETŮ PROPUSTNOST TŘÍDY SLUŽEB DOHODA O ÚROVNI POSKYTOVANÉ SLUŽBY SLA MECHANIZMY ZAJIŠTĚNÍ KVALITY SLUŽEB V IP SÍTÍCH TECHNOLOGIE INTEGROVANÝCH SLUŽEB (INTSERV) RSVP protokol Referenční model IntServ Modely služeb TECHNOLOGIE DIFERENCOVANÝCH SLUŽEB (DIFFSERV) DiffServ doména Identifikátor DSCP (DiffServ Code Point) Způsob zacházení PHB (Per-Hop Behavior) Referenční model DiffServ Mechanizmus Token Bucket Plánované odesílání paketů SEZNAM POUŽITÉ LITERATURY

6 6 FEKT Vysokého učení technického v Brně 1 Úvod Elektronická komunikace představuje sdělování informací mezi dvěma nebo více místy podle předem dohodnutých pravidel. Existuje velké množství technik a technologií, které nám moderní elektronickou komunikaci umožňují, a to různými způsoby a v různých, často velmi specifických, podmínkách. V současné době je dobře patrná konvergence veškeré naší elektronické komunikace do vzájemně propojených digitálních sítí. Dobrá znalost Protokolů komunikačních technik představuje jednu ze základních charakteristik absolventů telekomunikačních a počítačových oborů. Tento text tvoří doplňkový studijní materiál především pro studenty prvního ročníku oboru Telekomunikační a informační technika. Tento obor je zařazen do navazujícího magisterského studijního programu Elektrotechnika, elektronika, komunikační a řídící technika. Jedná se o povinný oborově zaměřený předmět, jehož cílem je rozšířit a prohloubit znalosti studentů v oblasti komunikačních technik. Obsahem text navazuje zejména na kurz Pokročilé komunikační techniky. Absolventi bakalářského studia by měli být schopni obsahu tohoto textu porozumět, jelikož se u nich již předpokládá dobrá orientace v základech této problematiky. Tento text se zaměřuje na problematiku vybraných aplikačních protokolů sady TCP/IP, jako jsou protokoly virtuálních terminálů, protokoly pro přenos souborů, doplňkové technologie k webovým technologiím a protokoly pro přenos elektronické pošty. Dále se text zaměřuje na vybraná témata managementu počítačových sítí, moderní komunikační techniky v prostředí Internetu a problematiku procesů a systémů. Pozornost je věnována i úvodu do kryptografie, směrovacímu protokolu IS-IS a doplňkovým technikám překladu doménových jmen. Poslední čtyři kapitoly jsou pak zaměřeny na problematiky kvality služeb, parametrů síťového provozu z hlediska zajištění kvality služeb, dále třídy služeb a poté mechanizmy k zajištění kvality služeb v IP sítích.

7 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 7 2 Vybrané aplikační protokoly a jejich vlastnosti 2.1 Vybrané protokoly virtuálních terminálů Terminál, počítačový terminál a emulátor Pojem terminál má více významů a souvisí především s počátky moderní éry počítačových systémů. Terminál v telekomunikacích je fyzické zařízení, které je schopné komunikovat přes telekomunikační linku. Nejběžnějšími typy jsou tedy telefon a dnes již velmi málo používané zařízení fax. Dalším důležitým pojmem je emulace. Pojmu emulace je nadřazena virtualizace, která představuje vyšší a efektivnější způsob, jak k dostupným zdrojům přistupovat jiným způsobem, než jakým ve skutečnosti existují nebo jsou propojeny a zakrývat nepodstatné rozdíly jako je např. fyzické rozmístění prostředků. Význam emulace spočívá v přizpůsobení něčeho, co původně vzniklo/fungovalo na jedné platformě, na použití pro odlišnou platformu. Telekomunikační terminál je možné emulovat, potom mluvíme o emulátoru telekomunikačního terminálu. Nejčastěji se jedná o softwarovou náhražku fyzického zařízení, tedy např. program HyperTerminal na Windows, Minicom na Linuxu nebo MacTerminal na Applu, či známou utilitu Putty. Nás však nejvíce zajímá počítačový terminál, který představuje původně fyzické zařízení uzpůsobené pro zobrazení vstupních/výstupních dat do/z výpočetního systému. Jedná se tedy o jakousi bránu k výpočetnímu systému, kterou můžeme také dle jiné terminologie označit jako tenkého klienta. Počítačový terminál může být dvojího typu základní a pokročilý, přičemž tyto dva se odlišují především tím, zda vstup/výstup je pouze textový nebo i grafický Protokol SSH (Secure Shell) Přestože název protokolu (SSH) obsahuje slovo shell (příkazový interpret), SSH není pouze příkazovým interpretem, představuje celý protokol zabezpečené komunikace. SSH je schopno nahradit starší protokoly jako je např. telnet nebo rlogin (remote login). Typicky je SSH využíváno k navázání spojení se vzdáleným strojem (počítač, server, router, ) a následné práci na něm, spočívající v zadávání příkazů a sledování odezvy. Hlavní výhodou protokolu je deklarovaná úroveň zabezpečení, protože jeho implementace pokrývají všechny tři základní oblasti bezpečné komunikace přes nedůvěryhodnou síť (např. Internet): Autentizace komunikujících stran server musí před zahájením komunikace obhájit svoji identitu před klientem a opačně, tj. proběhne ověření toho, zda jsou komunikující strany tím, za koho se vydávají. Probíhá na základě asymetrické kryptografie (více viz kap. Úvod do kryptografie). Šifrování přenášených dat veškerá data přenášená sítí jsou šifrována na základě společného tajemství (hesla) domluveným algoritmem a tedy nečitelná pro kohokoliv jiného, kdo má přístup na přenosovou trasu. Využívá se typicky symetrická kryptografie, jejíž heslo je domluveno v úvodní fázi komunikace pomocí nesymetrických metod. Integrita přenášených dat je zajištěna neměnnost dat při průchodu sítí, resp. pokud ke změně dojde, komunikující strany to vždy poznají.

8 8 FEKT Vysokého učení technického v Brně Protokol SSH vznikl v roce 1995 na Helsinské technické universitě po jednom masivním útoku spočívajícím v zachytávání hesel na univerzitní síti. Původní verze je nyní označována jako SSH-1, v roce 1996 byla navržena revize SSH-2 s mnoha vylepšeními a rozšířeními, bohužel bez zpětné kompatibility s SSH-1. Poměrně populární je sada označovaná jako OpenSSH, která vychází z poslední volné verze originálního SSH a je celá zdarma. Obsahuje kromě ssh klienta a ssh serveru i programy scp (secure copy) a sftp (secure file transfer protocol), tedy jak názvy napovídají, programy a protokoly pro zabezpečený přenos souborů. Kolem protokolu SSH (a zejména jeho nasazení v operačním systému Windows) existuje i spousta komerčních projektů, zájemce odkazujeme na použití libovolného vyhledávače a zadání hesla SSH server. Varianta, jak zprovoznit SSH server na operačním systému Windows a zároveň zdarma, je např. projekt Cygwin ( tj. program pro Windows tvářící se jako Linux, který již umožňuje používat sadu SSH Průběh standardní komunikace (SSH-2) Klient, který chce navázat spojení s SSH serverem se připojuje na TCP/22 port, na kterém server při standardní konfiguraci naslouchá. Navázání spojení proběhne pomocí třícestného podání rukou (three-way handshake) protokolu TCP (Transmission Control Protocol). Server i klient se navzájem představí (např. SSH-2.0-OpenSSH_4.2p1 Debian- 7ubuntu3.1, SSH-2.0-WinSCP_release_4.0.4 viz Obr. 2-1) a předají si seznamy podporovaných algoritmů (autentizační protokoly, šifrování, hashování, podpora komprese, apod.) Klient následně zahájí autentizaci serveru nejbezpečnějším společně podporovaným autentizačním (asymetrickým) protokolem, např. Diffie-Hellman. Provede to tak, že vygeneruje klíč pro symetrické šifrování spojení (session key), zašifruje ho pomocí veřejného klíče serveru a odešle. Server je následně pomocí svého privátního klíče schopen tento klíč dešifrovat. Může tedy začít přenos dat zašifrovaný pomocí vyměněného klíče. Tato metoda funguje správně, pokud klient zná veřejný klíč protistrany anebo je schopen jej zjistit a důvěryhodně ověřit. Server nemusí nutně vyžadovat, aby se i klient autentizoval stejným způsobem (pomocí asymetrické kryptografie, tj. za pomocí veřejného a privátního klíče), ale může podporovat i přihlášení zadáním přihlašovacího jména (login) a hesla do již bezpečného kanálu. Ukončení spojení je provedeno standardně pomocí zpráv TCP protokolu s příznaky FIN a ACK. Příklad komunikace SSH klienta s SSH serverem zachycená pomocí programu Wireshark a popsaná výše je uvedena na Obr Výstup programu je z důvodu přehlednosti vyfiltrován tak, aby ukazoval pouze pakety nesoucí protokol SSH, takže ve výpisu není viditelné např. navázání spojení protokolu TCP. Komunikace na obrázku zachycuje případ, kdy se autentizoval pouze server a uživatel se musel následně přihlásit pomocí přihlašovacího jména a hesla. To však již není ve výpisu zachycených paketů patrné, jelikož přihlášení proběhlo až po ustavení šifrovaného kanálu. V dolní půli obrázku je jako ukázka zobrazen detail paketu, kterým server informuje klienta o podporovaných službách a algoritmech.

9 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 9 Obr. 2-1: Komunikace klienta a serveru SSH protokolu, seznam paketů a obsah jednoho vybraného zasílaného od serveru ke klientovi Vrstvy protokolu SSH (verze 2) V předchozí kapitole byl popsán obecný princip fungování protokolu SSH. Pozorného čtenáře jistě napadlo, že protokol SSH bude rozdělen do vrstev zajišťujících jednotlivé části provozu, jednotlivé funkce. Struktura je naznačena na Obr. 2-2, stručný popis vrstev následuje: Transportní vrstva SSH tato vrstva se stará o výměnu klíče při inicializaci spojení, autentizaci serveru, nastavení šifrování, případně komprese a ověření integrity přenášených dat. Tato vrstva má taktéž na starost změnu šifrovacích klíčů po uplynutí určité časové jednotky nebo množství přenesených dat. Funkce této vrstvy je srovnatelná s TLS (Transport Layer Security) popis tohoto protokolu však není součástí tohoto textu. Vrstva autentizace uživatele SSH vrstva se stará o ověření identity klienta a poskytuje několik možností jak to provést. Kromě již zmiňovaných metod (login + heslo nebo využití asymetrické kryptografie) existují i další, jako je např. využití služeb autentizačního serveru Kerberos. Spojovací vrstva SSH na této úrovni jsou definovány přenosové kanály, SSH totiž podporuje více kanálů existujících v rámci jednoho spojení zároveň. Jeden kanál zpravidla reprezentuje vykonání jedné služby. Přes jedno ssh spojení lze tedy např.

10 10 FEKT Vysokého učení technického v Brně vykonávat nějaký proces na vzdáleném stroji a zároveň kopírovat soubor přes SFTP. Standardní typy kanálů jsou: - Sessions pro příkazové interprety, protokol SFTP a další. - Direct-tcpip pro tunelování TCP/IP spojení s třetí stranou přes protokol SSH a skrz vzdáleného hosta (server). Komunikace mezi klientem a serverem zůstává šifrovaná, komunikace serveru k třetí straně je již otevřená. - Forwarded-tcpip stejné použití jako v předchozím případě, pouze opačně, tj. že přesměrování na třetí stranu se provádí na straně klienta, nikoliv serveru. SSH aplikace SFTP FTP (over SSH) Spojovací vrstva SSH Vrstva autentizace uživatele SSH Transportní vrstva SSH TCP Obr. 2-2: Vrstvový model protokolu SSH verze Vybrané protokoly pro přenos souborů Bezpečné alternativy k protokolu FTP (File Transfer Protocol) Protokol FTP je již mnoho let velice intenzivně využíván pro přenos souborů přes počítačové sítě. Nicméně jeho specifikace se zaměřuje především na spolehlivý přenos a související služby, z hlediska bezpečnosti je v současné době zcela nedostačující. Veškerá data a dokonce i přihlašovací proces, probíhá v otevřené (nešifrované) formě, což znamená, že každý, kdo má možnost zachytávat pakety, může získat naše přihlašovací údaje a také i celé přenášené soubory. Proto je dobré uvést, že existují i zabezpečené alternativy k tomuto protokolu: FTPS též označováno jako FTP/SSL (Secure Socket Layer), zpětně kompatibilní protokol s původním FTP. Klient na začátku komunikace požádá server o ustavení zabezpečeného kanálu (konkrétně AUTH SSL zpráva), po přihlášení je šifrovaná veškerá komunikace (včetně řídícího kanálu). Princip je obdobný jako u HTTPS (který je popsán v kap ).

11 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 11 FTP-over-SSH součást SSH protokolu verze 2. Protokol nedefinuje žádnou autentizaci ani zabezpečení přenášených dat, to mu zajišťuje samotné SSH, viz kap Přenos obou spojení je součástí tunelu vytvořeného pomocí SSH. (FTP-over-SSH se však příliš nepoužívá.) SCP (Secure Copy Protocol) jednoduchý protokol pro zabezpečené kopírování opět prostřednictvím SSH spojení, které se stará o vše podstatné. Neprobíhá zde však tunelování klasického FTP přes zabezpečený kanál, ale jedná se o samostatný protokol. Často slouží jako záložní varianta v případě nepodpory SFTP na jedné straně komunikace, viz dále. SFTP ([SSH Secure] File Transfer Protocol) představuje rozšíření jednoduchého SCP do podoby nového protokolu s více možnostmi, nemá moc společného ani s původním FTP. SFTP přináší podporu práce s právy, adresáři apod., komunikace probíhá pouze přes jeden TCP port. V případě nekompatibility umožňuje software zpravidla přejít na SCP, které má ale omezené možnosti. SFTP je obsaženo i v OpenSSH, ve Windows lze protokol využívat např. prostřednictvím klienta WinSCP ( Ukázka zachycení přihlašovacích údajů (login + heslo) Snadnost zjištění uživatelských přihlašovacích údajů dokazuje následující Obr. 2-3, získaný zachycením FTP komunikace se serverem ftp.linux.cz. Obrázek sice ukazuje variantu tzv. anonymního přihlášení, nicméně podstata je stejná jako u plnohodnotného přihlášení. Obrázek doporučujeme porovnat např. s přihlášením pomocí SSH na Obr. 2-1, kde je už na první pohled patrné, že žádný login ani heslo nejsou nikde otevřeně obsaženy. Pozn.: login se posílá s příkazem USER, heslo s příkazem PASS, v druhém případě jde o zkrácení anglického slova password. Obr. 2-3: Ukázka FTP přihlášení údaje zadané uživatelem jsou zasílány zcela otevřeně Trivial FTP (TFTP) Protokol FTP představuje plnohodnotný souborový přenosový protokol, v tom smyslu že je vybaven prakticky všemi myslitelnými mechanizmy a vlastnostmi, které jsou zapotřebí

12 12 FEKT Vysokého učení technického v Brně pro přenosy celých souborů v počítačových sítích. V některých situacích však tato jeho "plnohodnotnost" může být spíše na závadu, a to kvůli jeho relativně velké složitosti a náročnosti na implementaci. To může vadit například u bezdiskových stanic či embedded zařízení, které si potřebují pouze jednorázově stáhnout např. svůj boot image (soubor, obsahující vše potřebné k jejich startu), přičemž příslušný kód který toto zajistí, musí být co možná nejmenší, tak aby jej bylo možné umístit do pevné paměti (např. paměti ROM) v tomto zařízení. Pro takovéto účely byl vyvinut protokol TFTP (Triviální FTP), jako maximálně zjednodušená alternativa k protokolu FTP. Odlehčení spočívá např. v tom, že protokol nezná pojem uživatele a přístupových práv, nezná pojem aktuálního adresáře a neumožňuje procházet adresáři serveru, ze kterého jsou soubory stahovány - TFTP klient nemůže na serveru nic vyhledávat, a místo toho musí "jít na jistotu" pro konkrétní soubor který potřebuje. Hlavní odlišnosti TFTP od FTP jsou: Pro transport dat používá služeb jednoduchého protokolu UDP (konkrétně port UDP/69 na straně serveru), nikoliv TCP, které je využíváno u FTP. Nezajišťuje žádné systémové akce na vzdáleném počítači, jako jsou výpis adresáře, jeho změna, rušení souborů apod. Nezjišťuje identifikaci uživatele žádajícího o přenos. Jak již bylo uvedeno, pro vlastní přenos využívá protokol TFTP nespolehlivých a nespojovaných služeb transportního protokolu UDP. S jeho nespolehlivostí se vyrovnává tak, že si sám zajišťuje potřebné potvrzování na aplikační úrovni. Jde o tzv. jednotlivé potvrzování (metoda stop-and-wait ), tj. každý vyslaný blok je potvrzován zvlášť. TFTP používá symetrické čekání na vypršení časového limitu, tj. odesílatel, který odeslal nějaká data, čeká na jejich potvrzení, a pokud jej nedostane do určitého časového limitu, vyšle data znovu. Obdobně příjemce, který data obdrží, potvrdí odesláním příslušného potvrzení, ale pokud do časového limitu nedostane další data, znovu vyšle již jednou odeslané potvrzení. Jednotlivé bloky dat, které jsou tímto způsobem přenášeny, mají pevnou velikost (512 bajtů), a jsou sekvenčně číslovány. Podobně jsou číslována i potvrzení. Konec celého přenosu příjemce rozpoznává podle posledního bloku, který musí obsahovat méně než standardních 512 bajtů (tedy např. i 0 bajtů) dat. V prvním (resp. nultém) bloku, kterým se přenos zahajuje, musí být uvedeno přesné jméno souboru, který má být přenesen, včetně přístupové cesty k tomuto souboru. Nejstarší verze protokolu podporovala přenos maximálně 32 MB velkého souboru, později však byla provedena úprava umožňující přenášet až 4 GB velké soubory Aplikace RSYNC Oba dříve diskutované a porovnávané protokoly (FTP i TFTP) umožňují přenos souborů sítí TCP/IP. Často však nastane situace, kdy cílový soubor (nebo případně adresář) již na vzdáleném stroji existuje a nám dostačuje ho pouze aktualizovat, tj. např. zahrnout poslední změny. V takovém případě je zbytečné aby se soubor přenášel přes síť celý znovu, daleko vhodnější je použít nástroje, které umožňují soubory vzdáleně synchronizovat, např. RSync = remote synchronize, tj. vzdálená synchronizace. Velký význam tato aplikace má především v situaci, kdy pracujeme s velkými soubory v řádu gigabajtů a vyšší.

13 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 13 RSync je unixový aplikační program využívající TCP/873 port, jeho výhodou je použití remote-update protokolu (pro vzdálenou aktualizaci), který maximálně urychluje přenosu souborů, pokud cílový soubor již existuje a pouze se liší. RSync umožňuje Kopírování (či synchronizaci) lokálních souborů nebo adresářů. Kopírování (či synchronizaci) souborů nebo adresářů z lokálního počítače na vzdálený, či obráceně, s využitím remote shell programu jako je např. SSH (viz kap ). Kopírování (či synchronizaci) ze vzdáleného RSync serveru na lokální počítač či obráceně, bez použití ssh nebo jiného remote shellu. Výpis soborů na vzdáleném stroji. Pro zájemce o podrobný popis algoritmu synchronizace je k dispozici www stránka rsync.samba.org. 2.3 Doplnění k WWW technologiím Rozšiřující technologie zvyšující možnosti HTTP protokolu Interaktivita webových stránek a zvyšování grafické úrovně souvisí s mnoha technikami a protokoly, kterým se bude věnovat následující text: CGI (Common Gateway Interface) je standardním protokolem pro předávání požadavků klienta webového serveru externí aplikaci a následně i vrácení odezvy aplikace. Technika umožňuje automatické generování webových stránek, tj. proměnných v čase. Těmto (přes web) spustitelným programům se říká CGI skripty. Funguje to tak, že uživatel zadá požadavek na vykonání skriptu, web server ho předá programu, ten skript vykoná a výsledek (např. vygenerovanou webovou stránku) předá serveru, který ji odešle klientovi. SSI (Server Side Includes) jednoduchý skriptovací jazyk pro přidání dynamického obsahu do HTML stránek, na rozdíl od CGI, které generuje stránku celou. Jak název napovídá, příkazy jsou vykonávány na straně serveru při požadavku klienta o konkrétní stránku. Triviálním příkladem použití je např. přidání aktuálního času nebo data do jinak statické webové stránky. CSS (Cascading Style Sheets) česky označované jako kaskádové styly. Jazyk se používá k popisu prezentace dokumentu napsaného v HTML, případně XHTML (viz níže). Umožňuje oddělení obsahu stránky (text) od prezentačního popisu dokumentu, jejímž jádrem je definování barev, fontů a rozvržení stránky. Dále umožňuje definovat různé styly zobrazení jedné a té samé stránky podle vykreslovacích metod, např. textový / grafický prohlížeč na straně klienta. Slovo kaskáda v názvu vychází z toho, že CSS umožňuje definovat priority jednotlivých typů zobrazení, resp. jejich posloupnost (kaskádu). CSS tak zlepšuje dostupnost obsahu stránek, umožňuje lepší kontrolu nad obsahem a jeho grafickou stránkou a snižuje množství opakování stejných částí kódu, čímž se zvyšuje jeho přehlednost.

14 14 FEKT Vysokého učení technického v Brně PHP (PHP: Hypertext Preprocessor) PHP je programovací jazyk původně navržen pro tvorbu dynamických HTML stránek, ale dnes používaný i pro další účely. PHP běží zpravidla na straně serveru, jeho vstupem je PHP kód a výstupem webová stránka. PHP je podporováno prakticky všemi operačními systémy. PHP je open source, na rozdíl od mnoha dalších (proprietarních) technologií. DOM (Document Object Model) standardizovaný objektový model dokumentů HTML nebo XML nezávislý na platformě a programovacím jazyku. Podporuje navigaci v libovolném směru, čímž se stává vhodný pro aplikace, kde se k jednomu dokumentu musí přistupovat opakovaně nebo mimo očekávané pořadí. JavaScript dynamický skriptovací jazyk užívaný pro dynamický běh webové stránky na straně klienta (tj. využívá se jeho výpočetní výkon a procesorový čas). Vznik JavaScriptu byl ovlivněn mnoha jinými jazyky a byl navržen tak, aby byl vzhledově podobný jazyku Java, ale jednodušší. Stejně jako Java je založen na syntaxi jazyka C, tím ale jejich faktická podobnost končí. JavaScript vyžaduje na straně klienta (webového prohlížeče) podporu, což může způsobovat jisté problémy, např. na mobilních zařízeních apod. Další nevýhodou je potenciální nebezpečnost pro uživatele, vyplývající z toho, že skript je vykonáván lokálně. Skript může teoreticky na počítači uživatele provádět i nežádoucí operace (pokud je napsán tak, aby obešel standardní ochranné mechanizmy) a způsobit nezanedbatelné škody. SSJS (Server-Side JavaScript) JavaScript běžící na serveru. Popis původního JavaScriptu byl omezen pouze na běh na straně klienta, proto vznikl tento pojem, pro případy, kdy skript běží na straně serveru. DHTML (Dynamic HyperText Markup Language) za dynamické HTML se považuje spojení statických stránek (HTML) se skriptovacím jazykem na straně klienta (jako např. JavaScript), kaskádových stylů (CSS) a objektové reprezentace dokumentu (DOM). Dynamika DHTML spočívá ve způsobu, jak stránka funguje, když je prohlížena, ne v generování unikátního obsahu při načítání (na rozdíl od např. PHP). DHTML se používá např. k vytvoření otevíracích menu na webových stránkách apod. XHTML (extensible HyperText Markup Language) značkovací jazyk srovnatelný s HTML avšak umožňující využít jazyk XML. Rozdíl mezi HTML a XHTML je zejména ve striktnosti. Dá se říct, že XHTML je postavené tak, že nutí autory psát kód bez chyb, což u HTML neplatí zdaleka do detailů. ActiveX představuje techniku pro objektově-orientovaný vývoj komponent, které lze vytvářet automatizovaně a dále s nimi manipulovat. Na této technice založil Microsoft spoustu dalších technologií, které však přesahují rámec tohoto textu. Adobe Flash je souhrnný název pro vývojové prostředí a přehrávač původně od firmy Macromedia. Flash umožňuje vytvářet (a na straně prohlížeče přehrávat ) animace a vytvářet tak interaktivitu, vše na základě vektorové grafiky. Nejčastějším použitím jsou reklamní bannery, hry a webové prezentace s důrazem na grafickou stránku věci. Flash podporuje i oboustranný přenos audia a videa. Používá vlastní objektově orientovaný programovací jazyk (ActionScript). ASP (Active Server Pages) představuje určitou obdobu SSJS (skriptování na straně serveru), jde však o celou platformu, která umožňuje využití více programovacích jazyků. Autorem je firma Microsoft. Současné (nástupnické) verze jsou označované jako ASP.NET. Již původní ASP umožňuje stejně jako mnoho dalších technologií vývoj dynamických stránek generovaných na straně serveru. ASP poskytuje programátorovi

15 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 15 určitou míru usnadnění práce, tím že obsahuje zabudované objekty se standardizovaným chováním a rozhraním. AJAX (Asynchronous JavaScript and XML) techniky vývoje interaktivních webových stránek. Využívá techniky XHTML, CSS, DOM a JavaScript a další. Přínosem je to, že webové stránky se nemusí načítat celé znovu při každé interakci uživatele, tj. obsah se mění, aniž by proběhlo obnovení celé stránky. To s sebou přináší i snížení množství zbytečně přenášených dat, zvýšení interaktivity a funkčnosti stránek. Současní web-profesionálové jsou stavěni před důležitá rozhodnutí, kterou z moderních technik (nebo kombinace několika) vybrat pro tvorbu svých webových stránek. Je to dáno tím, že v každé oblasti současného webového vývoje existuje více alternativ, které mají svá pro a proti. Některé věci mají odpovídající si platformy stejné, v řadě věcí se ale liší, některé jsou pro určité případy rychlejší apod. Přímo proti sobě stojí např. kombinace Linux + PHP + MySQL a Windows Server + ASP.NET + MS SQL. Situace je poměrně vyostřená i přímo mezi zastánci samotného PHP a ASP.NET. Obě tyto techniky již v současné době podporují např. použití AJAXu. Další protiklady tvoří Java Platform a.net Framework v kombinaci např. s jazykem C#. Při tvorbě aplikací pro mobilní zařízení se často objevuje Java (tzv. micro edition). Pro tvorbu skutečně interaktivních webových aplikací s grafickým prostředím má historicky převahu Flash, existuje však např. i technika Silverlight, označovanou také jako Windows Presentation Foundation/Everywhere (WPF/E) Proxy servery Přímá komunikace mezi klientem a WWW serverem pomocí HTTP protokolu je nejběžnější způsob získávání informací z WWW. V některých případech je však tato forma komunikace zprostředkována pomocí prostředníka proxy serveru. Proxy server 1 je zpravidla program (běžící na serveru organizace), který pracuje současně jako klient i server, schematické znázornění funkce je možné nalézt na Obr V obrázku je záměrně opomenuto DNS zjišťování IP adresy hostitele, které probíhá jak na straně klienta (hledání IP proxy serveru), tak na straně proxy serveru (hledání cílové IP www serveru). Nejpodstatnější vlastností je, že proxy server, tím že vystupuje za klienta, poskytuje uživateli anonymitu vzhledem k www serveru. Proxy server může fungovat i jako firewall aplikační vrstvy, viz dále. 1 V textu je pojednáno pouze o variantě proxy pracující s http protokolem, proxy server však zpravidla podporuje i další typy, jako např. ftp protokol a další.

16 16 FEKT Vysokého učení technického v Brně 3 8 WWW prohlížeč Proxy WWW server HTTP TCP IP serverová část HTTP TCP IP HTTP TCP IP klientská část HTTP TCP IP Síťové rozhraní Síťové rozhraní Síťové rozhraní Síťové rozhraní Obr. 2-4: Fungování komunikace zprostředkované proxy serverem 7 Stručný popis jednotlivých kroků fungování komunikace z Obr. 2-4: (1) Uživatel chce zobrazit určitou stránku na Internetu, např.: což se předá nižším vrstvám k přenosu. (2) Nižší vrstvy navážou spojení se serverovou částí proxy serveru a předají požadavek prohlížeče (HTTP metoda GET). (3) Proxy server rozumí struktuře HTTP protokolu a proto je schopen detailně vyhodnotit požadavek. Na základě vlastní logiky může proxy tento požadavek přepsat a de facto tak např. změnit cílový server, z kterého se bude stránka získávat. Dále může ověřovat, zda je vůbec uživatel oprávněn takový požadavek provést. Další netriviální činností, kterou může proxy provádět, je ukládání odpovědí do své cache paměti a při opakování dotazu na stejnou stránku tak zajistit rychlejší odezvu. Tato činnost však ztrácí význam v souvislosti s rozvojem dynamicky generovaných stránek. Komplexnější proxy dokáže na základě spolupráce s firewallem případně antivirovým programem účinně filtrovat provoz a chránit tak uživatele. Pokud proxy nenajde ve své paměti požadovanou stránku a uživatel je oprávněn, předá se požadavek klientské části proxy. (4) Klientská část zajistí navázání spojení s www serverem a předání metody (GET /stranka.htm). (5) WWW server přijme požadavek a vyhodnotí ho. (6) Výsledkem je odpověď WWW serveru, zpravidla požadovaná stránka. (7) Na základě nižších vrstev je odpověď předána zdroji metody GET, což je v tomto případě klientská část proxy serveru. (8) Stejné operace jako v bodě 3), jen zpětně. Např. přepsání odpovědi do formy v jaké ji očekává uživatel, případně zápis stránky do cache paměti. (9) Odpověď se pomocí nižších vrstev předá uživateli (původní tazatel). (10) Prohlížeč odpověď zpracuje a stránku zobrazí.

17 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 17 Jak je patrné z předcházejícího textu, proxy rozumí aplikačnímu protokolu (HTTP) a je schopno samo navazovat spojení, což jsou nejmarkantnější rozdíly např. od techniky překladu síťových adres (NAT = Network Address Translation). Umístění proxy serveru v rámci sítě není pevně dáno. Nejčastějším použitím je oddělení vnitřní sítě a Internetu, takže proxy server je umístěn na pomezí těchto dvou oblastí. K proxy serveru se však lze připojovat i za hranice vnitřní sítě (do Internetu). V takovém případě se často jedná o veřejné (public) proxy servery, kterých existuje velké množství, avšak jejich důvěryhodnost je často pochybná, protože do souhrnu (ne)žádoucích činností, které provádí, nemáme možnost nahlédnout Protokol HTTPS K protokolu HTTP existuje také jeho bezpečnější varianta HTTPS, která využívá port TCP/443. HTTPS není přímo zvláštním protokolem, používá se standardní HTTP, ale data nejsou přenášena otevřeně, nýbrž šifrovaně pomocí protokolu TLS (Transport Layer Security) nebo SSL (Secure Socket Layer), jejichž úloha je stejná 2. HTTPS tak chrání před odposlechem či jiným narušením komunikace klienta s webovým serverem. Aby mohl webový server přijmout spojení pomocí https, musí nejdříve administrátor vytvořit certifikát serveru. Tento certifikát si pak nechá ověřit (podepsat) certifikační autoritou. Server pak při žádosti o spojení klientovi zašle tento certifikát čímž je (zjednodušeně řečeno) zajištěna autentizace serveru. Detailní popis ustanovení zabezpečeného spojení představuje složitější handshake, který je nad rámec tohoto textu a je možné se s ním seznámit např. ve volitelném předmětu Kryptografie v informatice. Základní princip je ale jednoduchý: pomocí asymetrické kryptografie protokol SSL/TLS získá klíč pro symetrickou kryptografii, kterým je pak následná komunikace šifrována. 2.4 Vybrané protokoly pro přenos elektronické pošty SMTP (Simple Mail Transfer Protocol) Protokol SMTP je standard pro přenos elektronické pošty Internetem. Protokol je určen pro spolehlivý přenos zpráv elektronické pošty mezi dvěma stanicemi (resp. zejména mezi servery). Využívá port TCP/25 na straně serveru. SMTP se typicky používá pro přenos zprávy od klienta na server a následně pak mezi poštovními servery. Pro přístup uživatele do schránky se používají typicky jiné protokoly (POP3, IMAP4). Komunikace protokolu je založena na principu klient server. Z toho vyplývá, že poštovní server musí obsahovat obě tyto části, aby mohl jednak komunikovat s uživatelem, kde je v roli serveru a zároveň kontaktovat další poštovní server, sám v roli klienta. Vlastní protokol SMTP je poměrně jednoduchý, jednotlivé příkazy jsou textové v kódu ASCII, podobně jako u FTP, HTTP či dalších protokolů. Klient vkládá do navázaného spojení čtyřznakové příkazy a server odpovídá stavovými kódy s textovým popisem. Typy těchto 2 SSL (Secure Socket Layer) je předchůdcem TLS (Transport Layer Security), oba názvy však splývají a navzájem se zaměňují. TLS může být využito i jiným protokolem než HTTP, typickým příkladem je SMTP (Simple Mail Transfer Protocol) a POP3, viz kap. o elektronické poště.

18 18 FEKT Vysokého učení technického v Brně zpráv, stejně jako ukázky průběhu komunikace, je možné nalézt na Internetu např. ve specifikaci tohoto protokolu (RFC5321, viz V současné době se převážně používá rozšířená verze, tedy ESMTP (Extended SMTP). Tato umožňuje mimo jiné např. potvrzování o doručení ové zprávy (rozšíření DSN = Delivery Status Notification). U DSN potvrzuje doručení SMTP server, na kterém je umístěna schránka. Častější je ale využití záhlaví Disposition-Notification-To z rozšíření MIME 3 (Multipurpose Internet Mail Extensions), kdy potvrzení generuje až aplikace (poštovní klient) u konečného uživatele. Z pohledu uživatele a nastavení jeho ového klienta je podstatná role SMTP serveru odchozí pošty. Každý program fungující jako poštovní klient vždy vyžaduje nastavit server odchozí pošty, pokud chce uživatel zprávy nejen přijímat, ale i odesílat. Tento server vlastně doručuje zprávy v zastoupení za uživatele na poštovní servery adresátů. Uživatelé jsou často nuceni mít nastaven v rámci sítě poskytovatele připojení konkrétní server SMTP a přístup na jiné je záměrně blokován. To umožňuje poskytovateli připojení (nebo organizaci) snadněji odfiltrovat spam nebo jiné nežádoucí zprávy hned v zárodku, nastavovat různé politiky odesílání zpráv apod. Bezpečnost protokolu SMTP V současné době by bylo chybou používat čisté (E)SMTP jako takové. Přenos zpráv jeho prostřednictvím je sice možné považovat za spolehlivý, ale rozhodně ne za bezpečný. Podobně jako u protokolu HTTP, existuje zabezpečená verze SMTP, využívající služeb bezpečnostních protokolů TLS/SSL (viz kap ). Podpora těchto protokolů v poštovních klientech je dnes již standardem, je tedy na uživateli aby tuto podporu ve svém klientovi nastavil, pokud to neučiní tato aplikace automaticky POP3 (Post Office Protocol verze 3) POP3 je taktéž klient server protokol, který se běžně používá pro stahování ových zpráv z poštovního serveru. Po navázání spojení (port TCP/110 na straně serveru) si klient zpravidla stáhne nové zprávy ze své schránky na lokální počítač, na kterém je spuštěn. K tomu využije svého poštovního klienta. Z toho vyplývá, že protokol je navržen zejména pro práci offline a je tak určen primárně pro domácí uživatele. POP3 je stejně jako SMTP poměrně jednoduchý protokol, jehož příkazy jsou taktéž ve formátu ASCII. Detaily k protokolu je možné nalézt např. v dokumentu RFC1939 ( Protokol POP3 prochází při řízení připojení mezi poštovním serverem a ovým klientem podporujícím protokol POP3 třemi stavy: stav ověřování, stav transakce a stav aktualizace. V průběhu stavu ověřování musí být ový klient podporující protokol POP3, který se připojuje k serveru, ověřen. Teprve poté může uživatel stahovat svoje y. Pokud se uživatelské jméno a heslo předané ovým klientem shoduje s některým uživatelským jménem a heslem na serveru, je uživatel ověřen a přechází do stavu transakce. Pokud se neshoduje, zobrazí se chybová zpráva a uživateli samozřejmě není umožněno připojení ani stažení ů. 3 Rozšíření MIME umožňuje, aby znaky v ové zprávě byly i z jiné sady, než US-ASCII (je tedy povolena diakritika apod.), dále přílohy netextového charakteru a další dnes již samozřejmé věci.

19 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 19 V průběhu stavu transakce odesílá klient příkazy protokolu POP3 a server je přijímá a odpovídá na ně v souladu se specifikací protokolu. Jakékoli požadavky klienta, které neodpovídají specifikaci protokolu POP3, server ignoruje a odpovídá na ně chybovou zprávou. Stav aktualizace ukončuje připojení mezi klientem a serverem. Představuje poslední příkaz odesílaný klientem. Po ukončení připojení je zaktualizováno úložiště pošty, aby se projevily změny provedené v průběhu připojení uživatele k poštovnímu serveru. Pokud například uživatel úspěšně stáhne svůj , jsou stažené zprávy označeny k odstranění a poté z úložiště pošty odstraněny, pokud není ový klient nakonfigurován jinak. Z toho vyplývá, že lze smazanou zprávu ve stavu transakce ještě vrátit zpět, ale jakmile server přejde do stavu aktualizace, všechny změny se provedou a už není cesty zpět (standardním způsobem). Bezpečnost protokolu POP3 POP3 stejně jako velká většina starších Internetových protokolů bezpečnostní otázku příliš neřeší. Umožňuje autentizaci uživatele pomocí uživatelského jména a hesla, to však je přenášeno sítí otevřeně. Současná verze protokolu již některé bezpečnostní mechanizmy obsahuje, stejně jako v případě SMTP je však doporučováno provozovat přenos přes bezpečné TLS/SSL protokoly, které jsou schopny zajistit šifrování veškeré komunikace mezi klientem a poštovním serverem IMAP4 (Internet Message Access Protocol verze 4) Protokol IMAP verze 4 se používá 4, stejně jako POP3, pro přístup k ům uloženým na poštovních serverech. Oproti protokolu POP3 je výrazně složitější, nabízí však na oplátku i mnohem více funkcí. Jeho hlavní výhodou je automatická možnost nechat všechny zprávy na serveru, takže mohou být přístupné odkudkoliv a není tedy nutné je stahovat na lokální počítač a až na něm provádět jejich další zpracování. To lze tedy provádět přímo na serveru. Schránky se tak dají použít pro synchronizaci zpráv s jinými počítači, k jejich dlouhodobému zpřístupnění apod. Další odlišností je, že ke schránce může za určitých okolností být naráz připojeno více uživatelů. Z uvedeného popisu je patrné, že protokol IMAP je uzpůsoben spíše pro práci online, podporuje však i práci offline. IMAP je tak vhodný pro jiný typ použití, než POP3, často však poštovní server podporuje obě techniky. Protokol IMAP využívá jako transportní protokol TCP, konkrétně port TCP/143 na straně serveru. Více o protokolu IMAP lze nalézt např. v dokumentu RFC3501 ( Příkazy IMAP4 se liší od příkazů POP3, jsou však taktéž zadávány v ASCII. V protokolu IMAP4 může klient zadávat příkazy, ale odpovědi ze serveru mohou přijít v libovolném pořadí. Proto klient požadavky označuje a server v odpovědi uvede označení příkazu, kterého se odpověď týká. Identifikace příkazů je plně v kompetenci klienta (označení může být libovolný řetězec, často číslo). Za názvem příkazu může následovat seznam parametrů. Další výhodou IMAP oproti standardnímu POP3 je zabudovaná možnost rozšíření, které se běžně využívá. Zřejmou nevýhodou je větší zátěž poštovních serverů, které neslouží pouze jako dočasné úložiště, ale jako intenzivně využívaný pracovní prostor. 4 IMAP byl původně vyvinut na Stanford University v roce Současný standard označovaný jako IMAP4rev1 je z roku 2003.

20 20 FEKT Vysokého učení technického v Brně Bezpečnost protokolu IMAP IMAP nativně podporuje šifrování přihlašovacího mechanizmu, umožňuje ale i odeslání hesla v otevřeném tvaru, v případě že se klient a server nedokážou dohodnout na šifrovacím mechanizmu. Stejně jako u SMTP a POP3 je však výhodné celou komunikaci realizovat přes TLS/SSL protokoly a šifrovat tak bez výjimek všechna přenášená data mezi klientem a serverem.

21 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 21 3 Vybraná témata managementu počítačových sítí 3.1 Úvod do managementu sítí s protokolem IP Pojem management počítačových sítí zahrnuje prvky dohledu, řízení, kontroly, koordinace a správy síťových zdrojů a slouží tak k usměrňování chodu sítě. Management řadíme zpravidla především do aplikační vrstvy. Síťový management však na rozdíl od běžných aplikačních protokolů vychází z odlišné filozofie, jeho funkčnost je nutná i v případech, kdy síť nefunguje zcela správně, je z hlediska běžného provozu zahlcena apod. Pro běžné uživatele sítě je management transparentní, což znamená, že s ním nepřijdou žádným způsobem do styku. Internet se skládá z různých dílčích sítí často dosti různorodého charakteru, které jsou překlenuty protokolem IP a samozřejmě také vyššími vrstvami TCP/IP sady. Aby management sítí bylo možné používat a fungoval v podmínkách Internetu, tj. nejen lokálně, musí být splněny určité podmínky. Především musí být mezi zařízeními funkční IP vrstva a tedy i směrování a také musí být průchozí transportní vrstva celé sítě (typicky je využit protokol UDP), jelikož obě tyto vrstvy jsou používány pod protokolem SNMP, viz kap. 3.5, který umožňuje administrátorům sítí vzdáleně sledovat, řídit a případně řešit potíže různých zařízení připojených do sítě. Efektivní monitorování sítě spočívá také ve sledování trendů v síti, což umožňuje předcházet potenciálním problémům, a poskytuje informace, jak síť funguje v klidovém stavu. Tato data jsou důležitá např. v situacích, kdy se rozhodujeme, zda spravovaná síť (jako celek) zvládne rozšíření počtu koncových stanic, přidání dílčích sítí či podsítí, či také jako referenční data v situacích, kdy hledáme příčinu aktuálního problému. Monitorování sítě je kontinuální proces, který vyžaduje data z různých zdrojů. Tradičními zdroji jsou např. dokumentace k síti, nástroje analýzy výkonnosti a statistiky, systémové záznamy (logy) a v neposlední řadě protokol síťového managementu, který umožňuje sbírat požadovaná data vzdáleně přímo z jednotlivých zařízení. Management počítačové sítě může probíhat mnoha způsoby, jejichž použití závisí na rozsahu spravované sítě a samozřejmě na tom, jak velkou kontrolu nad sítí provozovatel nebo organizace požaduje. K definici managementu můžeme přistoupit různými způsoby. Můžeme definovat např. dále uvedené čtyři úrovně síťového managementu: 1) Nejjednodušším způsobem (prosté kontroly funkčnosti sítě) je používání standardních utilit, jako je příkaz ping (protokol ICMP), tracert (traceroute) nebo např. pathping. Tato metoda je vhodná pouze k základnímu ověření funkčnosti (např. nově vytvořeného) spojení a její použití může být komplikováno bezpečnostní politikou dané sítě, typicky realizované pomocí firewallů. 2) O něco komplexnější je využívání dohledových software dodávaných přímo s daným síťovým zařízením. Typicky se jedná o webové prostředí s velmi malým množstvím informací a s minimální možnosti nějakým způsobem na změny automaticky reagovat. Zřejmou nevýhodou tohoto způsobu je roztříštěnost informací na dílčí aktivní prvky či zařízení, jejichž systémy mohou být navíc naprosto odlišné. Tento přístup má opodstatnění pouze v případě malých sítí s jedním centrálním prvkem, typicky např. domácí sítě. Zde nám dostačují pouze tyto dílčí informace.

22 22 FEKT Vysokého učení technického v Brně 3) Existují i specializované síťové analyzátory, které dokáží např. sledovat provoz na daném spoji, umí sesbíraná data (pakety) vyhodnocovat a následně poskytovat výstupy v požadovaném formátu, např. v podobě grafů. V tomto případě nebudeme zpravidla schopni zasahovat do dílčích zařízení, budeme však mít velmi kvalitní a komplexní pohled na situaci na celé síti či konkrétním spoji. To nám umožní vyhodnocovat kapacitní problémy, používání jednotlivých protokolů apod. 4) Nejvyšší formou správy sítě je využití standardizovaných systémů pro řízení sítí, tj. protokolů pro centralizovaný dohled nad spravovanou oblastí, která se obecně skládá ze zařízení od různých výrobců. Systém musí umět definovat typ potřebných dat, monitorovat síťové zdroje, získávat různé charakteristiky ve vhodném časovém měřítku, provádět archivaci získaných dat pro pozdější analýzu apod. Na základě těchto informací musí být schopen diagnostikovat problémy a řídit zdroje, případně rekonfigurovat síť, a tak vyhovět změněným potřebám uživatelů, reagovat na aktuální situaci. Implementace je možná pouze v případě, že aktivní prvky sítě tento způsob podporují, zpravidla ve formě agentů (server), v síti se pak vyskytuje manažer (klient), který informace od agentů sbírá, patřičně je zpracovává a vyhodnocuje. Typickým příkladem z oblasti sítí TCP/IP je protokol SNMP (Simple Network Management Protocol), viz kap. 3.5 a související nástroje. Pro úplnost uveďme, že v rámci ISO/OSI je definován obdobný protokol CMIP (Common Management Information Protocol). Je třeba zdůraznit rozdílnost pohledu běžného uživatele, který u sítě požaduje především bezproblémovost a výkonnost a má omezený pohled na síťové služby a pohled síťového manažera, který zpravidla vyžaduje detailní pohled na síť, tj. všechny její komponenty, které se podílejí na zprostředkování služeb běžným uživatelům. 3.2 Oblasti řízení počítačových sítí Management sítě (většinou provozovaný ve formě standardizovaných protokolů) spočívá zejména v aktivitách umožňujících hladký chod sítí v následujících oblastech: Řízení v případě poruch (fault management) obsahuje funkce rozpoznání různých problémů v síti, podávání výstražných zpráv, které informují správce o těchto poruchách. Management musí mít přístup ke všem síťovým prvkům i v případě zahlcení sítě apod. Konfigurace (configuration management) provádění úprav a upgradů (vylepšení) ať už přímo hardware nebo jen software nebo i přidání nových zařízení, linek, např. za účelem rozšíření kapacity. Účtování (accounting management) zodpovídá za sběr a zpracování dat související s využíváním síťových prostředků z hlediska poskytování služeb za úplatu. Účtování pak probíhá na základě určitého tarifu, který má zákazník zvolen. Výkonnost (performance management) monitorování stavu síťových zdrojů a vytížení linek. Sledovanými veličinami mohou být např. propustnost, doba odezvy nebo chybovost. Bezpečnost (security management) ověřování oprávněnosti přístupu ke zdrojům, ochrana před útoky apod. V širším slova smyslu do této kategorie patří i FUP 5, správa 5 FUP = Fair User Policy, volně přeloženo jako spravedlivý přístup ke zdrojům. Poskytovatel se pomocí daných pravidel (politiky) snaží omezit jednotlivé uživatele tak, aby jejich přehnané aktivity na sítí neznemožňovaly nebo ani výrazně neomezovaly aktivity ostatních uživatelů. Tedy aby např. jeden uživatel neblokoval celou

23 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 23 uživatelských účtů (přidělování přístupových práv, přizpůsobování pracovního prostředí apod.). V literatuře je někdy možné nalézt rozdělení výše uvedených oblastí řízení sítí do tří úrovní, viz Obr Horní úroveň Střední úroveň Nízká úroveň - Účtování, - Řízení databází - Užívání databází - Uživatelské a statistické záznamy - Monitorování sítě - Řízení sítě Obr. 3-1: Úrovně řízení sítí Nízká úroveň obsahuje funkce spojené s monitorováním a řízením sítě. Přenášené zprávy jsou např. určitá chybová hlášení, monitorování stavů, shromažďování statistických dat a sběr podrobných dat z hlediska budoucího účtování. Střední úroveň řízení shromažďuje výše uvedené záznamy do databáze. Tuto databázi pak dále zpřístupňujeme horní úrovni. Horní úroveň řízení poskytuje veškeré informace (ve srozumitelné formě) obsluze sítě nebo jejímu manažerovi a to na základě informací z databáze. Je možné vydělovat jednotlivé části, např. účtování apod. 3.3 Obecná architektura managementu Funkce managementu jsou, jak již bylo uvedeno, rozděleny (distribuovány) na dva typy účastníků manažer (klient) a agent (server). Manager software, který běží na počítači nebo lépe serveru, někdy označovaném jako stanice síťového managementu (NMS = Network Management Station 6 ). Základním úkolem manažera je vysílat dotazy (zpravidla pravidelně opakované) na jednotlivé agenty ve spravované oblasti. Manažer má tedy možnost manipulovat s řízenými objekty v síti prostřednictvím agentů. Manažer tak představuje centrální bod systému, který v sobě sdružuje řídící funkce nad dohlíženou oblastí. Manažerů může být v síti distribuováno i více a mohou si mezi sebou získané informace vyměňovat. Agent software, který běží na řízeném síťovém zařízení (běžně směrovač, přepínač, server, ale také síťová tiskárna nebo záložní zdroj). Agent udržuje databázi objektů (MIB = Management Information Base), které je možné řídit (tj. vzdáleně ovlivňovat). O MIB bude pojednáno podrobněji v kap Agent je schopný vykonávat operace (modifikace nebo jen čtení) na řízených objektech, především na základě výzvy od manažera. V případě neočekávané události může agent iniciovat nezbytné operace i sám. kapacitu linky sdílené více uživateli. FUP je v posledních letech spíše na ústupu, zejména pak v pevných datových sítích. 6 Přehled četných systémů NMS a jejich tabulkové srovnání je možné nalézt na adrese

24 24 FEKT Vysokého učení technického v Brně Příklad rozmístění agentů a manažera v rámci spravované sítě je možné nalézt na Obr Na obrázku jsou agenti pro jednoduchost umístěni pouze na aktivních prvcích sítě a serverech. agent agent WAN Farma serverů agent agent agent agent Síť 1 Síť 3 Síť 4 agent Síť 2 agent agent Síť 5 agent Síť 0 manager Obr. 3-2: Příklad rozmístění prvků při distribuovaném řízení sítě 3.4 Informace pro management sítě Aby byl vůbec management sítí realizovatelný, musí existovat standardizovaný formát informací pro management. Formát těchto informací se skládá ze dvou částí syntax 7 a sémantika 8. Důležitá je nezávislost těchto informací na platformě, architektuře či operačním systému daného řízeného zařízení. Je také nezbytné, aby pojetí těchto informací bylo všude stejné, jinak není možné zajistit konzistenci pohledů na informace. To si můžeme představit např. tak, že zatížení rozhraní na úrovni 50 % jeho kapacity bude mít všude význam 50-ti procentního zatížení ze skutečně stejného pohledu (blokovaná šířka pásma, počet paketů ve vyrovnávací paměti, apod.). Informace o řízených objektech jsou běžně ukládány v bázi informací pro management, MIB = Management Information Base. 7 Syntax = skladba vyjadřuje pravidla pro zápis symbolů (zpráv). 8 Sémantika = jejich význam.

25 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 25 MIB představuje hierarchický model řízených objektů, tj. abstrakci systémových prostředků. Tento model je pak přístupný pro agenty a prostřednictvím nich (a protokolu managementu) i pro manažery sítě. MIB představuje specifikaci pro objekty, které musí agent udržovat, a dále způsob vzdáleného přístupu k nim (čtení a případně i zápis). Informace se definují pomocí: Object Identifier jedinečné a také jednoznačné pojmenování proměnné, pomocí textového jména. Jejich úkolem je větší srozumitelnost. Př.: položka sysname definuje název zařízení (systému). Object Descriptor jedinečné a také jednoznačné definování proměnné pomocí posloupnosti přirozených čísel, které je platné v celé MIB. S tímto pojmenováním pak pracuje SNMP protokol (viz dále). Př.: Dalším důležitým pojmem, který se vyskytuje v souvislosti s MIB, je SMI (Structure of Management Information). Jak název napovídá, jde o možné způsoby definice, typy proměnných a následné identifikace a pojmenovávání proměnných v MIB, které jsou shrnuty do souboru pravidel. SMI i MIB nejsou závislé na používaném řídicím protokolu. Je třeba si také uvědomit, že k managementu síťových prvků se přistupuje tak, aby jeho provozování zatěžovalo zařízení jen minimálně. Management je sice důležitou, ale nikoliv hlavní funkcí daného zařízení. Z toho tedy vyplývá, že báze informací musí být maximálně jednoduchá a obsahovat jen nejnutnější objekty. Naprosto vyloučeny jsou tedy např. objekty, které mají konkrétní vztah s jinými již řízenými objekty, nebo pokud lze jejich hodnotu odvodit i na straně manažera apod. Přidání vlastních sledovaných veličin je možné pomocí privátní větve stromu 9, kterou má např. firma Cisco poměrně rozsáhlou. Dále je možné přidat i nestandardní objekty prostřednictvím speciální experimentální větve této databáze. Hierarchie celé MIB je tvořena logickým stromem. Pro představu MIB definuje více než 200 standardních objektů a více jak 400 privátních objektů. Na Obr. 3-3 je vyobrazena základní hierarchie MIB a jeho předci. Počátkem je kořen stromu (ROOT), nejobsáhlejší větev pokračuje objektem ISO, což je známá organizace pro standardy. Dále následuje objekt ORG, představující zkratku pro organizace. Dalším objektem je DoD (Department of Defense), vyjadřující americké ministerstvo obrany, které je odpovědné za počátky Internetu. Další objekt je Internet. Zde se strom dělí na šest důležitých větví. Pro účely této kapitoly je důležitá především druhá větev objektů Management, což je větev standardních objektů pro nástroje na správu sítí. Třetí větví objektů je větev Experimental, jak již bylo řečeno, slouží k experimentálním účelům. Čtvrtá větev Private je nejdůležitější pro výrobce zařízení, protože si v této větvi mohou vytvořit (při dodržení určitých pravidel) cokoliv. 9 Kompletní seznam prvků privátní větve má často pouze výrobce konkrétního zařízení. Firma pak dodává zpravidla komplexní řešení managementu svých zařízení a také tím své zákazníky tak trochu tlačí do používání vybavení od jednoho výrobce.

26 26 FEKT Vysokého učení technického v Brně Přístup ke konkrétní položce pak probíhá podle očekávání hierarchicky, např..iso.org.dod.internet.mgmt.mib-2.interfaces.ifnumber nebo lze přistupovat i pomocí čísel uvedených v závorkách, tedy v tomto případě Je zřejmé, že tato identifikace je platná globálně. Jako příklady objektů z jednotlivých kategorií MIB-2 poslouží následující přehled 10, který obsahuje seznam pouze několika málo vybraných proměnných, jejich zařazení do kategorie a stručně i jejich význam. Také je vždy zmíněno, zda konkrétní proměnné je možné pouze číst nebo i vzdáleně zapisovat. ROOT ITU-T (0) ISO (1) ITU/ISO (2) Standard (1) Mem (2) ORG (3) DoD (6) Internet (1) Directory (1) Management (2) Experimental (3) Private (4) Security (5) SNMPv2 (6) MIB-2 (1) System (1) SNMP (11) Interfaces (2) Transmission (10) Address Translation (3) EGP (8) IP (4) UDP (6) ICMP (5) TCP (6) Obr. 3-3: Část struktury stromu MIB a jeho předků 10 Pozn.: Seznam slouží pouze jako ukázka možností a není po studentech vyžadován, plně dostačuje přehled o možných kategoriích v MIB-2.

27 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 27 Kategorie System informace týkající se stavu a typu zařízení sysdescr textový popis identifikace hardware a software systému; pouze čtení sysuptime čas v setinách sekundy od restartu; pouze čtení Kategorie Interfaces (if) informace o stavech rozhraní ifnumber počet rozhraní na zařízení, které je možné použít; pouze čtení iftable seznam záznamů o rozhraních (počet ifnumber), v součinnosti s dalšími objekty; čtení a zápis ifindex jednoznačná číselná identifikace rozhraní; pouze čtení ifmtu největší možná velikost rámce v bajtech; pouze čtení iftype číslo označující typ rozhraní; pouze čtení ifspeed odhad současné rychlosti rozhraní v bit/s; pouze čtení ifphysaddress fyzická adresa rozhraní; pouze čtení ifinoctets celkový počet bajtů přijatých rozhraním; pouze čtení ifinerrors počet jednotek obsahujících chybu zahozených; pouze čtení ifoutnucastpkts počet broadcast a multicast paketů směrem ven; pouze čtení ifoutqlen délka výstupní fronty paketů k odeslání, pouze čtení Kategorie Address Translation (at) informace o překladu adres atentry zápis/čtení záznamu překladové tabulky, nutné blíže specifikovat: atifindex specifikace rozhraní, kterého se záznam týká atphysaddress fyzická adresa; čtení a zápis atnetaddress síťová adresa korespondující s fyzickou adresou; čtení a zápis Kategorie IP (Internet Protocol) informace z IP vrstvy, o směrování ipdefaultttl vyčtení nebo zápis výchozí hodnoty Time-To-Live v IP záhlaví ipinreceives celkový počet přijatých datagramů; pouze čtení ipinhdrerrors počet vstupních datagramů s chybou v záhlaví (CRC, verze, ); čtení ipforwdatagrams počet přesměrovaných datagramů; pouze čtení ipindiscards počet zahozených paketů, nikoliv chybných, ale např. z důvodů plné vyrovnávací paměti přetížení prvku; pouze čtení ipoutnoroutes počet datagramů zahozených kvůli nenalezení cesty k jejich adresátovi; pouze čtení ipfragoks počet datagramů úspěšně fragmentovaných; pouze čtení ipfragfails počet datagramů, které bylo potřeba fragmentovat, ale nebylo to možné (příznak don t fragment); pouze čtení

28 28 FEKT Vysokého učení technického v Brně iproutingtable v součinnosti s dalšími objekty pracuje se směrovací tabulkou; čtení i zápis Kategorie ICMP (Internet Control Message Protocol) informace o odezvě, dostupnosti icmpinmsgs celkový počet přijatých ICMP zpráv; pouze čtení icmpindestunreachs počet zpráv destination unreachable ; pouze čtení icmpinechos počet přijatých zpráv echo request ; pouze čtení Kategorie TCP (Transmission Control Protocol) informace z protokolu TCP tcprtomax maximální hodnota povolená u konkrétní tcp implementace pro časovač opakování přenosu v milisekundách; pouze čtení tcpmaxconn limitní hodnota počtu tcp spojení, kterou zařízení podporuje; pouze čtení tcpcurrestab počet právě probíhajících spojení; pouze čtení tcpinsegs celkový počet přijatých segmentů TCP; pouze čtení tcpretranssegs celkový počet opakovaně přenášených segmentů; pouze čtení Kategorie UDP (User Datagram Protocol) informace z protokolu UDP udpoutdatagrams celkový počet odeslaných UDP datagramů; pouze čtení udpports celkový počet datagramů, pro které neexistovala přijímací aplikace (cílový port nebyl aktivní); pouze čtení udpinerrors počet datagramů UDP, které obsahovaly chyby a proto nebylo možné je předat aplikaci; pouze čtení Kategorie EGP (Exterior Gateway Protocol) informace ze směrování na úrovni AS egpinmsgs počet přijatých EGP zpráv; pouze čtení egpneightable tabulka sousedů EGP (v součinnosti s dalšími objekty); pouze čtení Jak je možné odvodit z předcházejícího přehledu, v MIB rozlišujeme několik druhů proměnných: jednoduché typy primitiva INTEGER (celé číslo), OCTET STRING (řetězec znaků), OBJECT IDENTIFIER (řetězec znaků, pojmenování objektu), NULL (žádná hodnota) složené typy tabulka SEQUENCE OF jednoduchých typů speciální definované typy IpAddress jako OCTET STRING v délce 4 slabik, TimeTicks jako Integer (hodnota v setinách sekundy). Aktivní síťový prvek či jiné spravované zařízení nemusí vždy podporovat všechny typy kategorií a tedy i do nich příslušející proměnné. Mezi nepovinné kategorie patří např. tcp, udp nebo egp.

29 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO Základy protokolu SNMP (Simple Network Management Protocol) Protokol SNMP (Simple Network Management Protocol) umožňuje sbírat předem definovaná data o různých zdrojích v síti. Pomocí SNMP můžeme zjišťovat údaje ze zařízení, aniž bychom k němu měli fyzický přístup. SNMP je asynchronní, transakčně orientovaný a distribuovaný protokol založený na modelu klient-server. Protokol byl vyvinut k usnadnění správy počítačových sítí 11. Strana, která posílá (typicky periodicky) požadavky (snmp manažer), může být v nejjednodušším případě tzv. snmp browser, nebo složitější NMS (Network Management System). Na straně spravovaného zařízení je snmp agent (snmp server), který reaguje ve velké většině případů pouze na základě výzvy. Výjimku tvoří tzv. trapy, které agenti vysílají asynchronně při výskytu mimořádných událostí (výpadek proudu, ventilátoru, překročení mezních údajů apod.). Jak již bylo dříve uvedeno, pro přenos dat se používá protokol UDP, konkrétně port UDP/162 pro trapy (na straně manažera) a UDP/161 pro ostatní (běžné) zprávy (na straně agenta) 12. Protokol je považován do určité míry za minimalistický, několik málo operací poskytuje veškerou funkcionalitu. Každá zpráva, která je přenášena, je reprezentována pouze jedním datagramem (UDP) a na jejím úvodu je pole obsahující číslo verze protokolu (o verzích SNMP dále). Další položkou SNMP jednotky (PDU = Protocol Data Unit) je jméno SNMP komunity, které je možné považovat za nezabezpečené heslo. První specifikace protokolu (SNMPv1) vznikla již v roce Stanovovala jen několik jednoduchých příkazů, jejichž provedení se v této verzi protokolu žádným způsobem nepotvrzuje. Přehled je možné nalézt v následující Tab. 1, hlavní dvě operace jsou čtení a zápis položky. Verze 2 přinesla další dva příkazy, get-bulk-request a inform. Tyto příkazy umožňují manažerovi přečtení celé množiny informací (get-bulk-request), resp. umožňují dvěma manažerům komunikovat mezi sebou (inform). Grafické znázornění všech operací uvedených v Tab. 1 je možné shlédnout spolu s protokoly nutnými pro zapouzdření SNMP na Obr Z obrázku je např. dobře patrné, že ověření zápisu (příkaz set-request) lze principiálně snadno provést následným vyčtením (getrequest 13 ) zapsané hodnoty. To je však zbytečný krok, jelikož agent zápis potvrzuje následnou zprávou get-response, kde se již nachází nová hodnota proměnné, která byla změněna příkazem set-request Verze protokolu SNMP Zabezpečení řídící komunikace u protokolu SNMP představuje nejvýznamnější rozdíl mezi jednotlivými verzemi, viz další tři podkapitoly. 11 Ačkoli byl protokol SNMP původně určen pouze pro usnadnění správy sítě, možnosti jeho využití je podstatně širší, a tak stále častěji díky své jednoduchosti proniká např. i do průmyslové automatizace či měřicí techniky. Této problematice se však v rámci tohoto kurzu nebudeme věnovat. 12 Experimentuje se i s verzí SNMP, která by využívala spolehlivý transportní protokol TCP. Nicméně bližší informace jsou nad rámec tohoto textu. 13 Operace get-request a set-request musí být atomické. To znamená, že agent musí provést všechny úkony, které se ve zprávě požadují (pokud jich je více) v jedné sekvenci anebo neprovést žádný z nich. Zajištění atomicity je klíčové zejména v paralelních systémech, kde může probíhat více operací zároveň. O problematice paralelního zpracování a souvisejících problémech bude více pojednáno v kap. 5.

30 30 FEKT Vysokého učení technického v Brně Tab. 1: Množina základních operací protokolu SNMP (verze 1) Příkaz get-request get-next-request get-response set-request trap Význam žádost manažera o získání hodnoty určité proměnné žádost o získání hodnoty proměnné bez udání jejího přesného jména (př.: další hodnota v tabulce) odpověď agenta na operaci žádosti o čtení nebo zápis manažera příkaz manažera k zápisu hodnoty ve zprávě specifikované proměnné asynchronní událost iniciovaná agentem Spravovaný objekt SNMP dohled a řízení Program správy get-request get-next-request set-request get-response trap get-request get-next-request set-request get-response trap SNMP agent UDP SNMP spojení SNMP manager UDP IP IP Síťové rozhraní Síťové rozhraní TCP/IP síť Obr. 3-4: Spojení mezi manažerem a agentem protokolu SNMP, typy zpráv SNMP verze 1 Již u první verze SNMP je patrná určitá snaha integrovat základní bezpečnostní funkce. Zaměřuje se však pouze na zabezpečení z hlediska přístupu, tj. identifikace entit oprávněných vyžadovat operace managementu (manažeři), dále identifikaci povoleného

31 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 31 typu operace a identifikaci informace, která bude dostupná povoleným operacím. Jak již bylo uvedeno výše, SNMP obsahuje položku komunita. Komunita představuje jedinečné jméno (textové pole), které sdružuje všechny tři výše uvedené identifikace (entity, operace, informace). Problémem je, že toto pole je přenášeno sítí otevřeně, takže je možné ho snadno zjistit, čistě zachycením paketu protokolu SNMP. Kdokoliv, kdo by měl přístup na přenosové trasy sítě je pak schopen management sledovat či dokonce ovlivňovat, což rozhodně není žádoucí SNMP verze 2 Model SNMPv2 opustil myšlenku tzv. komunit a řeší koncepci zabezpečení jiným způsobem. Metoda je však v současné době považována za velmi složitou a hlavně obtížně konfigurovatelnou a příliš se neuchytila. Existují pouze experimentální implementace plné verze 2. Jak již bylo uvedeno, protokol přináší dvě nové zprávy - get-bulk-request a inform. První umožňuje manažerovi přečtení celé množiny informací, např. tabulky, druhá poskytuje dvěma manažerům možnost komunikovat mezi sebou a vyměňovat si (potvrzovaně) informace. Existují dvě zjednodušené verze protokolu SNMPv2. První je SNMPv2c (communitybased), která stále používá pro autentifikaci přístupu pouze názvy komunit. Druhá pak SNMPv2u (user-based), jež definuje problematiku bezpečnosti odlišným způsobem a obdobné principy je možné využívat i v následné verzi SNMPv3, o které je pojednáno v následující kapitole SNMP verze 3 Poslední verze je založena na stejných principech jako SNMPv1 a dále na některých principech z SNMPv2, avšak výrazně vylepšuje pojetí celé architektury, včetně bezpečnostního mechanizmu. Byl přepracován i formát zpráv a řízení přístupu k síťovým zdrojům. Bezpečnostní mechanizmus umožňuje ochranu zpráv SNMP před změnou nebo odposlechem a dále verifikaci zdroje zpráv (autentizace). Ochrana dat je umožněna např. i pomocí šifrovacího algoritmu DES (Data Encryption Standard), autentizace pomocí techniky MAC (Message Authentication Code). Více o těchto technikách lze nalézt v kap. 6 nebo v literatuře. SNMPv3 umožňuje tři úrovně zabezpečení: Bez autentifikace a šifrování, Autentifikace pomocí HMAC-MD5 nebo HMAC-SHA, bez šifrování, Autentifikace stejně jako v předcházejícím bodě a navíc šifrování pomocí DES, 3DES nebo i AES Současný standard pro management sítí Současná norma pro problematiku managementu je obsažena v celkem osmi dokumentech RFC (Request For Comments). Pro základní představu, tyto dokumenty popisují následující oblasti: Architektura managementu,

32 32 FEKT Vysokého učení technického v Brně mechanizmus pro popis a pojmenování objektů a událostí pro účely managementu, protokol pro přenos zpráv managementu (SNMPv3), protokolové operace pro přístup k informacím pro management a soubor základních aplikací a přístupový mechanizmus (MIB).

33 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 33 4 Moderní komunikační techniky v prostředí Internetu 4.1 Distribuované systémy Distribuované aplikace a systémy V době počátků éry výpočetní techniky byl běžný koncept centrálních výpočetních systémů a přístupových terminálů, který principiálně odpovídá konceptu tenkého klienta. Postupem času se schopnosti terminálů zvyšovaly a stalo se běžné, že pro práci s nějakou aplikací bylo možné si ji nainstalovat přímo do svého počítače. S postupným rozvojem sítí se spousta aplikací s výhodou posunula do fungování na principu režimu klient-server, kdy na koncových stanicích jsou různě složití klienti a v síti je pak server (např. úložiště), který centralizovaně poskytuje služby. V tomto režimu jsou však velmi často intenzivně využívány i prostředky klienta (úložiště, výpočetní výkon). Distribuované systémy se určitým způsobem (zejména v případě Cloudů, viz dále) vrací k původnímu konceptu výpočetní techniky, tj. centralizaci a existenci jednoduchých přístupových terminálů. Pro mnohé aplikace je výhodnější, když nepředstavují jeden balík umístěný na koncovém zařízení konkrétního uživatele, ale když se skládají z malých modulů umístěných na více strojích. Tyto moduly pak vzájemně spolupracující a v maximální míře využívají výhod síťové komunikace. V takovém případě mluvíme o tzv. distribuovaných aplikacích. Distribuované aplikace a algoritmy využívají síťové rozhraní pro přístup k nejrůznějším datovým zdrojům a službám. Distribuovaná aplikace je tedy součástí komplexnějšího systému, který kromě vlastní aplikace obsahuje hardwarové a další softwarové prostředky, které zpřístupňují požadované služby. Příkladem může být i relativně jednoduchý databázový server. Takový systém se označuje jako distribuovaný systém. Distribuovaný systém představuje celistvý systém, který je však rozprostřen na více výpočetních stanicích spojených počítačovou sítí. Komponenty systému komunikují a jsou koordinovány pouze prostřednictvím předávání zpráv přes síť. Z hardwarového pohledu to tedy znamená, že jednotlivé výpočetní stanice jsou autonomní, zatímco z pohledu software se celý systém jeví jeho uživatelům jako jednotný, názorně viz Obr V distribuovaných systémech platí, že se složitý a rozsáhlý problém rozdělí na velké množství menších a jednodušších, které následně řeší velké množství strojů. Příkladem obecného distribuovaného systému může být i počítačová síť pracovních stanic využívající společné zdroje (soubory, databáze, tiskárny apod.), podniková síť (Intranet) nebo v nejobecnějším případě také Internet.

34 34 FEKT Vysokého učení technického v Brně Distribuovaný systém Obr. 4-1: Distribuovaný systém jako kompaktní celek Příklady významných typů distribuovaných systémů: Cluster typ paralelního nebo distribuovaného výpočetního systému, který se skládá z propojených nezávislých stanic, které spolupracují na úlohách jako jeden sloučený výpočetní stroj. Mezi těmito stroji je relativně silná vazba a bývají propojeny velice rychlými lokálními sítěmi. Příkladem clusteru jsou systémy zaměřené primárně na výpočty, často v rámci jedné lokality, běžící na stejné platformě, ve vlastnictví jedné organizace apod. Výpočetní výkon těchto systémů je obrovský 14 (zejména ten paralelní) a u nejvýkonnějších platí, že je vyšší, než u Gridů, ale za cenu poměrně vysokých nákladů. V některých případech nemusí u Clusteru jít primárně jen o vysoký výkon, ale také o zvýšení dostupnosti, případně rozložení zátěže. Clustery využívají často nějakou middleware vrstvu. Grid typ paralelního nebo distribuovaného systému, který umožňuje dynamické sdílení, selekci a agregaci geograficky distribuovaných a nezávislých zdrojů, v závislosti na jejich dostupnosti, kapacitě, výkonu, ceně a případných dalších požadavcích 15. Gridy často obsahují celé a nezávislé stroje běžící na různých platformách, ve vlastnictví různých organizací apod. Vazba mezi těmito stroji je relativně slabá. Gridy často využívají služeb vrstev middleware, o které bude pojednáno dále, a neobejdou se bez síťového propojení jednotlivých elementů (které je zpravidla zajištěno Internetem). Zřejmou nevýhodou gridu je, že musíme počítat s tím, že počet stanic a jejich stav se bude průběžně měnit a že není možné mít nad všemi komponentami kontrolu a může tedy nastat situace, že některé stroje budou třeba i záměrně dodávat falešné výsledky. 14 Seznam nejvýkonnějších superpočítačů, mezi kterými jsou i clustery, je možné nalézt na 15 Jako příklad uveďme např. velmi populární systém Seti@Home ( nebo Folding@Home ( První systém umožňuje každému poskytnout výkon svého počítače k analýze radiových signálů z vesmíru, druhý pak k detailním biologickým simulacím.

35 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 35 Cloud masivně se rozšiřující technologie poskytování mnoha druhů služeb a zdrojů přes Internet. Poskytovatel má k dispozici určitý fond serverů, úložišť, aplikací a služeb, které spravuje a zpravidla za úplatu poskytuje zákazníkům přístup k určitému objemu těchto zdrojů. Setkat se můžeme např. s SaaS (Software as a Service) nebo DaaS (Desktop as a Service) službami, které spočívají v poskytování dočasného přístupu k nějakému software nebo celého desktopu přes Internetovou síť. Z pohledu zákazníka je možné dosáhnout úspor, jelikož není nutné vše (třeba jen krátkodobě potřebné pořizovat) a spravovat lokálně. Mezi nevýhody patří zejména to, že naše data jsou mimo majetek a přímou správu společnosti a např. jejich bezpečnost je závislá na poskytovateli. Z pohledu poskytovatele je výhodná efektivita, s jakou se využívají jeho zdroje, tj. že mohou být sdíleny více zákazníky. Dalšími výhodami Cloudů jsou ve srovnání s klasickými řešeními lepší spolehlivost, škálovatelnost, nezávislost na poloze klienta a jeho OS a celková výkonnost (pokud ji nelimituje rychlost připojení). Klientská stanice připojující se do Cloudu může být velmi jednoduchá a často na ní stačí mít pouze webový prohlížeč nebo nějakou přístupovou aplikaci, tedy tzv. tenkého klienta. Cloudy mohou být veřejné, komunitní nebo privátní, podle toho, kdo může jejich služeb využívat. Cloud může využívat jako svoji výpočetní součást Clustery Obecná charakteristika distribuovaných systémů Základní charakteristiky distribuovaných systémů lze shrnout do následujících bodů. Paralelní aktivity nezávislé komponenty systému vykonávají souběžné úkoly Komunikace prostřednictvím předávání zpráv systémy nesdílí paměť (to lze obvykle pouze v rámci jednoho stroje mezi paralelními procesy). Sdílení zdrojů zejména dat tj. databáze; dále např. tiskárny. Žádný globální stav systému žádná součást systému nedokáže přímo ověřit současný stav celého systému. Žádné globální hodiny systému synchronizace procesů a jejich časování má pouze omezené možnosti. Nelze však říci, že by systém jako celek pracoval náhodně Výhody distribuovaných systémů Základním cílem distribuovaného systému je jednoduché propojení uživatelů systému navzájem a také propojení uživatelů a zdrojů. Distribuovaný systém dokáže také skrýt rozdíly, které lze mezi různými stroji vytvářejícími daný systém nalézt. Snaží se tedy o vytvoření jakýchsi virtuálních strojů, které budou poskytovat jednotné rozhraní. Také skutečnost, že jednotlivé zdroje jsou distribuovány, může být skryta. Další vlastností těchto systémů je, že zaručují jednotný a konzistentní způsob komunikace mezi koncovými uživateli, či aplikacemi s distribuovaným systémem, a to bez ohledu na to, kdy a kde tato komunikace probíhá. To velmi zjednodušuje užívání těchto systémů.

36 36 FEKT Vysokého učení technického v Brně Vnitřní organizace distribuovaných systémů Distribuovaný systém může mít plně decentralizované řízení, tzv. P2P sítě (Peer-To- Peer), kdy jednotky v systému jsou si navzájem rovny. Častějším typem jsou však systémy, které obsahují alespoň jeden centrální prvek, který je určen k částečnému nebo úplnému řízení a správě distribuovaného systému. Tyto systémy jsou tedy založeny na principu klient-server. Systém se obvykle skládá ze tří vrstev uživatelského rozhraní, zpracování dat a datové vrstvy. Rozprostření těchto vrstev mezi klienta a server se může lišit. Obvyklou součástí takového systému je tzv. aplikační server, na kterém je implementována vlastní logika služeb poskytovaných celým systémem. Snahou při vývoji těchto aplikací je odstínění síťové komunikace (transparentnost) se serverem, a to převážně na straně klientské aplikace. 4.2 Middleware vrstva Odstínění síťové komunikace (a samozřejmě i odlišností mezi jednotlivými komponentami) distribuovaného systému může být docíleno speciální vrstvou, která se nazývá middleware (nachází se uprostřed mezi logikou serveru a kódem klientské aplikace), viz Obr Middleware poskytuje nadřazeným vrstvám rozhraní, které na straně klientské aplikace vytváří dojem, že vzdálená komunikace probíhá vlastně pouze na lokální úrovni. Na straně serveru middleware umožňuje vytvářet logiku systému ve formě jednoduchých adresovatelných objektů. Veškerou komunikaci a její řízení obstarává jádro aplikačního serveru ve spolupráci s middleware, který tímto významně usnadňuje a urychluje vývoj distribuovaných systémů jako takových. Middleware je tedy vrstva určená primárně pro vývojáře distribuovaných systémů. Příklady jednodušších middleware vrstev jsou Oracle (dříve Sun) RPC (Remote Procedure Call), OMG CORBA (Common Object Request Broker Architecture), Microsoft D-COM (Distributed Component Object Model), Java RMI (Remote Method Invocation). Příkladem komplexnějších middleware jsou Melbourne Gridbus for Grid computing, ANL Globus a Grid toolkit, IBM WebSphere, Microsoft.NET (viz kap. 4.3) a J2EE (Java 2 Enterprise Edition). Klient Aplikační server Komunikace nezávislá na typu použitého protokolu Distribuovaná aplikace Uživatelská logika systému Uživatelská logika systému... Uživatelská logika systému Komunikace v závislosti na typu použitého protokolu Middleware Middleware TCP/IP Obr. 4-2: Blokové schéma distribuovaného systému, typ klient-server s middleware vrstvou

37 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 37 Middleware si můžeme představit jako soubor programových, vývojových prostředků a zdrojů, které usnadňují tvorbu aplikací intenzivně využívajících pro svou činnost síťového prostředí. Některé aplikace dokonce nejen síťovou komunikaci využívají, ale přímo ji vyžadují pro svou správnou a plnohodnotnou činnost, ať už se jedná pouze o výměnu dat, využití služby umístěné na jiném místě nebo získání dalších zdrojů pro svoji činnost. Samozřejmě mohou existovat distribuované aplikace fungující i bez této vrstvy, návrh takového systému je však výrazně komplikovanější a v některých případech prakticky nemožný. Charakter distribuovaného systému z mírně odlišného pohledu (pohledu procesů běžících na stanicích) než na předcházejícím obrázku objasňuje Obr Middleware je v tomto obrázku zaznačena jako vrstva překlenující jednotlivé stanice, nicméně je třeba vzít v potaz, že je to vždy o konkrétním úhlu pohledu. Prostředky middleware vrstvy totiž musí být rozprostřeny na jednotlivé stanice a komunikace těchto komponent následně probíhá pomocí síťových služeb operačního systému. Distribuovaná aplikace Služby vrstvy middleware Síťové služby Síťové služby Síťové služby Jádro (Kernel) Stanice/Proces Jádro (Kernel) Stanice/Proces Jádro (Kernel) Stanice/Proces Obr. 4-3: Distribuovaný systém z pohledu procesů Přístupy k tvorbě middleware vrstvy Za účelem zjednodušení vývoje distribuovaných aplikací je většina middleware vrstev založena na určitých paradigmatech 16, pomocí kterých jsou popsány komunikace a distribuce zdrojů v rámci systému. Nejjednodušším přístupem je, že na vše je nahlíženo jako na soubor. Se všemi prostředky se tedy pracuje jako se soubory, tj. včetně přístupu, uvolňování, čtení či zápisu, jako nejběžnějšími operacemi se soubory. Dalším typem middleware je model založený na volání vzdálených procedur - RPC (Remote Procedure Call). Tento model je založen na ukrytí síťové komunikace pod volání metod, které je obdobou volání metod na lokální úrovni. Další možností jsou tzv. distribuované objekty, které skrývají síťový charakter komunikace se vzdálenými objekty až na takovou úroveň, že komunikace s těmito objekty se téměř vůbec neliší od komunikace s lokálními objekty. Více o tomto přístupu viz kap Paradigma = vzor, příklad, model.

38 38 FEKT Vysokého učení technického v Brně Služby poskytované middleware vrstvou Základní službou, kterou se middleware snaží poskytnout, je implementace tzv. přístupové transparence, tedy poskytuje prostředky pro komunikaci na vyšší úrovni. Pro tyto účely je rozhraní transportní vrstvy vrstvového modelu plně zapouzdřeno a zakryto vlastním komunikačním rozhraním middleware vrstvy. Další významnou službou, kterou middleware poskytuje, je jmenná služba, která zajišťuje dohledání zdrojů a komponent v systému podle určitého jména. Zde můžeme vidět určitou paralelu na systém DNS (Domain Name System), což je systém překladu doménových jmen na IP adresy. Systém DNS pracuje v obecném prostředí počítačové sítě, nejčastěji celého Internetu, zatímco jméno služba distribuovaného systému bude mít pouze lokální dosah, myšleno z pohledu celého systému. Mnoho middleware systémů nabízí možnost uchování stavů určitých zdrojů i v době kdy systém není aktivní. Tato služba se označuje jako persistence. U profesionálnějších middleware se často setkáváme s prostředky pro zajištění bezpečné komunikace v systému. Význam této služby roste, pokud distribuovaná komunikace probíhá v rámci Internetu. Je zřejmé, že pokud naše komunikace, a to nejen v distribuovaném systému, probíhá přes přenosové trasy, nad kterými nemáme kontrolu, musíme vždy počítat s tím, že tuto komunikaci může někdo monitorovat. Z hlediska návrhu systému by měla middleware vrstva řešit základní problematické oblasti týkající se vnitřní komunikace distribuovaných systémů. Patří sem: Pravidla komunikace vnitřní komunikace distribuovaného systému nemusí být postavena na žádných obecných standardech. Snahou však je, aby i tato komunikace měla velmi podobné rysy jako vnější způsob komunikace a to z důvodu snadnější a efektivnější implementace, údržby a řízení. I v rámci vnitřní komunikace je nutné se zabývat otázkami efektivních přenosů velkých objemů dat, propustností, zpožděním a přenosem informací o vzniklých výjimkách. Typy komunikace a jejich vlastnosti základní dělení komunikace je na synchronní a asynchronní, což platí i pro distribuované systémy. Každá z uvedených typů komunikace má své výhody i nevýhody, zpravidla je zde ale výhodnější asynchronní způsob komunikace. Je také nutné zavést určitý mechanizmus potvrzování o provedení zprávy (služby). To znamená uchovávání stavu komunikace a tedy zavedení mechanizmu provázání dvojic sobě odpovídajících zpráv žádost-odpověď, např. pomocí ID zprávy. Správa provozu distribuovaný systém vytváří samostatný podsystém v rámci sítě a proto je potřeba i nad ním provádět správu provozu, což úzce souvisí s dohledem a řízením provozu (více viz kap. 3). Správa distribuovaného systému bude zpravidla prováděna odděleně od správy sítě. Správa výjimek zachycení a ošetření výjimek je důležitou součástí každé aplikace, včetně těch distribuovaných. Také je důležité standardizovat komunikační mechanizmus předávání výjimek mezi součástmi systému. Konfigurace systém by měl mít schopnost uchovávat a zpracovávat informace o svém nastavení, popř. o možných změnách nastavení, které je možné provést. Lokalizace adresace a dohledávání určité logické jednotky v rámci celého distribuovaného systému. Distribuce adresních informací.

39 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 39 Rozhraní logické jednotky je také nutné specifikovat rozhraní každé entity v systému, aby byla umožněna komunikace mezi nimi. Rozhraní musí být co nejjednodušší, ale zároveň dostatečně obsáhlé, aby umožňovalo více způsobů komunikace apod. Příkladem velkých platforem pro vývoj distribuovaných aplikací je Java 2 Platform Enterprise Edition nebo Microsoft.NET Framework viz kap Ukázka prostředí pro distribuované aplikace.net Framework První verze platformy.net Framework byla oficiálně vypuštěna začátkem roku 2002, v současné době existuje.net již i verze 4.5, v tomto textu je však pojednáno o verzi 3.5. Platforma.NET Framework není svázána pouze se společnostní Microsoft (která je jejím autorem) a operačním systémem Windows. S implementacemi technologie.net se lze setkat již v určité formě i na jiných operačních systémech..net Framework představuje první vývojářskou platformu, která je od počátku postavena tak, aby vyhovovala potřebám Internetových aplikací. Tato platforma není určena pouze pro (obrovské) distribuované systémy, její technologie pokrývají samozřejmě i klasické aplikace Základní struktura Platforma.NET Framework byla navržena tak, aby byla schopna zajistit tyto cíle: Poskytnout konzistentní prostředí pro objektově orientované programování bez ohledu na to, zda je objekt uložen a spuštěn lokálně nebo distribuován v síti a tedy spouštěn vzdáleně. Poskytnout prostředí pro vykonání kódu, které minimalizuje jeho vývoj a údržbu. Poskytnout prostředí, které by odstraňovalo výkonnostní problémy skriptovacího nebo interpretovaného prostředí. Poskytnout vývojářům prostředí, na kterém lze vyvíjet nejrůznější typy aplikací. Postavit veškerou komunikaci na průmyslových standardech, za účelem zajištění integrace kódu platformy.net Framework s jakýmkoliv jiným kódem. Architektura platformy.net Framework se dělí do několika základních vrstev, viz Obr S platformou souvisí i programovací jazyky, viz obrázek a dále.

40 40 FEKT Vysokého učení technického v Brně Jazyky Visual Basic C++ C# J#... Specifikace jazyků CLS (Common Language Specification).NET Framework Programová rozhraní Uživatelská rozhraní Základní knihovna tříd (Base Class Library), Data, XML Běhové prostředí CLR (Common Language Runtime) Obr. 4-4: Základní struktura.net Framework a navazující programovací jazyky Běhové prostředí CLR (Common Language Runtime) Hlavní rysy této klíčové vrstvy celého.net lze shrnout do následujících bodů. CLR umožňuje jednodušší a rychlejší vývoj aplikací, tím že mnohé věci standardizuje. Je potřeba psát méně zdrojové kódu a tento kód je následně opakovatelně využitelný. Automatická správa a konfigurace paměti, optimalizace opětovného využívání dříve obsazené paměti. Dobrá podpora různých vývojářských programovacích jazyků, kód může být napsán obecně ve více jazycích. Všechny jazyky se kompilují do standardního přechodného jazyka, viz dále. CLR umožňuje snadnější a bezpečnější instalaci aplikací. Často pouze prostým kopírováním. Snadná aktualizace dílčích komponent systému, široké spektrum možností pro rozšiřitelnost. V Obr. 4-4 nahoře jsou znázorněny dvě vrstvy, které se týkají programovacích jazyků. Tato část však patří do CLR. Platforma.NET Framework obecně umožňuje používat různé programovací jazyky, podmínkou však je, že budou odpovídat specifikaci jazyků CLS (Common Language Specification). Pokud vyhovují, je možné dokonce sdílet navzájem knihovny více jazyků apod. CLS tedy specifikuje základní vlastnosti, které jsou od programovacího jazyka pro.net platformu vyžadovány. Pokud jazyk obsahuje nějaké

41 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 41 rozšíření nad rámec CLS, není zaručena dostupnost tohoto rozšíření i v jiných programovacích jazycích. Zdrojový kód aplikace, či kódu.net platformy se při překladu nepřevádí přímo do nativního kódu systému, nýbrž do jazyka MSIL (Microsoft Intermediate Language), označovaný také zkratkou CIL (Common Intermediate Language) nebo jen IL. Teprve po požadavku o využití tohoto kódu je provedena jeho kompilace pomocí JIT (Just-in-Time) překladače do nativního kódu systému a následně může být započato jeho provádění. Celý tento proces je zobrazen na Obr Zdrojový kód v jazyce Visual Basic C# J# Převod do jazyka CIL Kompilátor Kompilátor Kompilátor Jazyk nezávislý na platformě Common Intermediate Language (CIL) Kompilace Just-in-Time Kód závislý na vykonávající platformě Nativní kód Běh aplikace Obr. 4-5: Zpracování zdrojového kódu na platformě.net Jak je patrné z obrázku, jazyk CIL je do značné míry platformově nezávislý a je zpracováván jádrem platformy.net nebo jiným virtuálním strojem, který mu rozumí. Díky jazyku CIL, což je obdoba byte kódu na platformě JAVA (viz Obr. 4-6), může aplikace být spuštěna všude tam, kde se nachází virtuální stroj schopný zpracovat instrukce CIL jazyka. Jak již bylo uvedeno, jakmile je řízený kód přeložen pomocí JIT překladače může započít jeho provádění, a to ve formě nativního kódu, což se příznivě projeví na jeho rychlosti. Na druhou stranu, zpomalení provádění může být způsobeno především vestavěnou typovou kontrolou a bezpečnostními mechanizmy platformy.net Framework.

42 42 FEKT Vysokého učení technického v Brně Zdrojový kód v jazyce Java code Převod do přech. jazyka Kompilátor Jazyk nezávislý na platformě Byte Code Java virtual machine Kód závislý na vykonávající platformě Kompilace Just-in-Time Nativní kód Běh aplikace Obr. 4-6: Zpracování zdrojového kódu u platformy Java Základní knihovna tříd patřící do.net Framework Tato (druhá) vrstva se často nazývá.net Class Framework nebo též Base Class Library a poskytuje konzistentní a všem jazykům dostupné knihovny a služby. Jako př. uveďme knihovny pro přístup k datům a jejich zpracování, práce s vrstvami, rozhraními, otázky zabezpečení, konfigurace aplikací, práce s adresářovými službami, frontami zpráv a časovači a rozhraní pro přístup k informacím v distribučních jednotkách. Tyto knihovny tedy výrazně usnadňují práci, tím že velké množství často používaných věcí je již předprogramováno. Jak je patrné, tato vrstva obsahuje mnoho prvků, které programátoři běžně považují za součást programovacího jazyka, čímž se zvyšuje jednotnost a konzistence kódu. Techniky pro přístup k datům z databází jsou založeny na tzv. ADO.NET 17 (ActiveX Data Objects.NET), což přestavuje přepracovanou a rozšířenou verzi technologie ADO, určenou pro distribuované užití v Internetu, někdy řazenou až do třetí vrstvy, (Obr. 4-7). Uživatelská a programová rozhraní Třetí vrstva původního.net (viz Obr. 4-4 a také Obr. 4-7) vytváří programová a uživatelská rozhraní aplikace a má taktéž souvislost se všemi programovacími jazyky 17 Obsáhlé technologie ADO.NET a ASP.NET, které patří do platformy.net Framework, jsou zmíněny pouze jako pojmy, o kterých je dobré vědět. Bližší popis je možné nalézt v literatuře nebo na Internetu.

43 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 43 pracujícími v platformě.net. Součástí jsou např. nástroje na vytvoření typických formulářových oken aplikací ve Windows (WinForms), které obsahují sadu unifikovaných ovládacích prvků atd. Pro uživatelské rozhraní přes web jsou taktéž poskytovány pokročilé mechanizmy a standardizované formuláře (označovány jako Web). Mechanizmy pro přímou komunikaci přes Internet jsou založeny na protokolu SOAP (Simple Object Access Protocol). SOAP a Web dohromady jsou označovány jako ASP.NET 17 (Active Server Pages.NET) Stručná historie verzí platformy.net Framework Platforma.NET Framework se neustále vyvíjí přibližně od roku 2000, kdy se objevila beta verze první verze (1.0). Graficky je možné vývoj zachytit přidáváním nových vrstev, které shrnují přídavné funkce nových verzí, viz Obr Funkce starších vrstev však nejsou v novějších verzích opomíjeny, nýbrž dále zdokonalovány. Kompletní vývojové prostředí od společnosti Microsoft nejen pro.net aplikace nese název Visual Studio. 3.5 LINQ ADO.NET Framework 3.0 WPF/E WCF WF Card Space.NET Framework 2.0 WinForms ASP.NET ADO.NET Základní knihovna tříd (Base Class Library), Data, XML Běhové prostředí CLR (Common Language Runtime) Obr. 4-7: Technologie přidávané do.net v jednotlivých vrstvách.net Framework 1.0 a verze 1.1 jsou z dnešního pohledu již zastaralé, verze 2.0, která tvoří základní úroveň obrázku, je pojednána i výše v textu. Technologie, které přináší verze 3.0, jsou: Windows Presentation Foundation/Everywhere (WPF/E) neboli Silverlight, nový subsystém uživatelského rozhraní a aplikačního rozhraní založený na XML a vektorové grafice, Snaha Microsoftu o protiváhu technologii Flash od Adobe. Windows Communication Foundation (WCF) na služby orientovaný systém přenosu zpráv. Rozšíření webových služeb z.net Framework 2.0. Windows Workflow Foundation (WF) umožňuje automatizaci úkolů použitím šablon.

44 44 FEKT Vysokého učení technického v Brně Windows Card Space stará se o bezpečné ukládání digitální identity uživatele a poskytuje jednotné rozhraní pro volbu identity pro konkrétní transakci, jako je např. přihlášení se na web. Verze.NET Framework 3.5, která vyšla koncem roku 2007, přináší ještě: Language Integrated Query (LINQ) jak název napovídá, tato komponenta přidává do všech jazyků.net Framework nativní podporu dotazovacích prostředků (query) na různorodě uložená data. Je patrná jistá podobnost na SQL. ADO.NET Framework (ActiveX Data Objects) velké rozšíření technologie ADO.NET. 4.4.NET Remoting Celá platforma.net Framework je určena zejména pro vývoj aplikací hojně využívající síťové komunikace, a proto na této platformě najdeme podporu pro realizaci komunikace se vzdálenými stanicemi. S platformou.net přichází především dvě technologie umožňující výměnu dat a volání služeb prostřednictvím sítě. Jedná se o technologii webových služeb (viz kap. 4.5) a technologii.net Remoting. Obě technologie jsou schopny značně usnadnit vývoj distribuovaných systémů. Navíc se jedná o standardní řešení pro platformu.net a v případě webových služeb navíc o technologii nezávislou na použité platformě Architektura.NET Remoting.NET Remoting je technologie, která umožňuje vzdálenou komunikaci mezi objekty prostřednictvím sítě, tudíž opět plně zapadá do OOP (objektově-orientované programování) přístupu celé platformy. Nejedná se však o zcela průlomovou technologii, neboť již před uvedením této platformy existovaly některé technologie umožňující vzdálenou komunikaci mezi objekty, jako jsou DCOM (Distributed Component Object Model) nebo CORBA (Common Object Request Broker Architecture). Hlavním rozdílem.net Remoting oproti zmíněným technologiím je možnost široké rozšiřitelnosti této technologie a dále možnost použít pro vzdálenou komunikaci vlastní komunikační protokol. Zjednodušená architektura technologie.net Remoting je uvedena na následujícím Obr. 4-8, popis následuje níže. Klient Server Proxy objekt Dispatcher Serverový objekt Formátovač Formátovač Transportní kanál Transportní kanál Obr. 4-8: Zjednodušená architektura.net Remoting

45 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 45 Komunikace mezi objekty je typu klient-server, kdy klient volá metody vzdáleného objektu umístěného na serverové stanici (server side object = objekt na straně serveru). Na straně klienta.net Remoting zapouzdřuje rozhraní vzdáleného (serverového) objektu do tzv. proxy objektu. Proxy objekt obsahuje shodné rozhraní, jako je rozhraní distribuovaného objektu umístěného na serveru. Tímto způsobem je ošetřena práce se vzdáleným objektem, který se jeví klientské aplikaci, jako každý jiný lokální objekt. Vytváří se tedy middleware vrstva systému, tj. (virtuálně) jsou odstraněny distribuované charaktery zdrojů. Kdykoliv je provedeno volání vzdáleného objektu, vše probíhá prostřednictvím proxy objektu 18 na straně klienta. Tento požadavek je nejprve převeden do formátu zprávy a tato zpráva je předána na zpracování do dalších vrstev. Mezi těmito vrstvami se nachází tzv. Formátovač (Formatter), který provádí serializaci zprávy neboli převod zprávy do formátu vhodný pro přenos po síti. Poslední vrstvou je tzv. transportní kanál (Transport Channel), který zajišťuje vlastní komunikaci přes síťové rozhraní. Na straně serveru je pak postup opačný, zpráva je deserializována a předána dále do komponenty Dispatcher, který provede volání požadované metody objektu na straně serveru. Výsledek, případně návratová hodnota volané metody pak prochází zpět stejnou cestou, jen opačným směrem. Velkým přínosem techniky.net Remoting je, že umožňuje vložení přídavných vrstev, nebo úpravu či náhradu stávajících vrstev architektury za účelem implementace vlastních požadavků a tím rozšířit možnosti této technologie. Je tedy možné definovat vlastní transportní kanál apod..net Remoting sám o sobě neřeší problematiku zabezpečení a tudíž musí být implementována dodatečně, např. právě pomocí přídavné vrstvy. Vlastností technologie.net Remoting lze shrnout do bodů jednoduchost, přehlednost, snadná rozšiřitelnost, avšak za cenu nižšího počtu doprovodných a podpůrných služeb ve srovnání např. s technikou CORBA (o této technice není v tomto textu pojednáno) Základní vlastnosti a principy technologie.net Remoting Následuje popis vybraných charakteristických vlastností a principů technologie.net Remoting. Definice rozhraní Mnoho systémů vzdáleného volání (CORBA, DCOM) vyžaduje explicitní definování rozhraní serverového objektu. Kromě vlastního kódu serverového objektu tedy musí vývojář též vytvořit popis tohoto objektu a zajistit přítomnost tohoto popisu na straně klienta. Tento popis může mít různé podoby. Díky platformě.net a jejím samopopisných vlastnostem odpadá vytváření zvláštních popisných souborů. Vývojář se tak stará jen o definici serverového objektu, který implementuje téměř shodně jako každý jiný standardní objekt. Pokud sestavení s tímto objektem umístíme i na klientské straně, pak lze již snadno realizovat vzdálenou komunikaci se serverovým objektem. Serializace dat Serializace je, jak již bylo řečeno, proces převodu datových objektů do podoby vhodné pro přenos přes síťové rozhraní, jinými slovy do zpráv nějakého protokolu. Serializace je prováděna pomocí tzv. formátovačů (formatter). 18 Vytvoření proxy objektu je zajištěno jádrem platformy.net, nikoliv programátorem.

46 46 FEKT Vysokého učení technického v Brně Standardně.NET nabízí dvě možnosti, jak lze data serializovat binárně nebo pomocí protokolu SOAP (Simple Object Access Protocol). Výsledkem binární serializace jsou zprávy bajtově orientovaného protokolu. Výhodou tohoto typu serializace je její rychlost, menší velikost zpráv, avšak za cenu složitější čitelnosti zpráv musí se použít speciální nástroj. Touto nevýhodou netrpí protokol SOAP. Protokol SOAP, viz kap. 4.5, je textově orientovaný protokol postavený na syntaxi jazyka XML (Extensible Markup Language). Jako transportní protokol pro již serializovaná data nabízí.net standardně TCP nebo HTTP kanál, umožňuje ale implementovat i vlastní transportní protokoly. Řízení životnosti objektů S přítomností síťového rozhraní a rozdělení systému do distribuovaných aplikací, vzniká jen velmi slabá vazba mezi jednotlivými částmi systému. V případě, kdy nastane situace, že dojde k přerušení spojení mezi klientem a serverem (např. v důsledku výpadku síťové komunikace) je nutné nějakým způsobem zajistit, aby při tomto výpadku byly uvolněny na straně serveru veškeré zdroje a procesy související s nedostupným klientem, nebo byly provedeny potřebné kroky pro pozdější znovunavázání spojení. Je tedy nezbytné hlídat zda serverové objekty příslušející danému klientu jsou stále aktuální a mají konektivitu na svého klienta. V rámci.net Remoting je tedy obsažena služba řízení životnosti objektů, která je založena na monitorování komunikace mezi serverovým objektem a klientem. Předávání vzdálených objektů Komunikace se vzdáleným objektem probíhá skrz proxy objekt, jak bylo uvedeno v kap Jelikož se jeví jako standardní objekt, můžeme s ním tak i zacházet. Je tedy možné jej předat jako parametr jinému než původnímu serveru..net Framework dokáže automaticky určit místo původu, na které proxy objekt odkazuje. Druhý server tedy bude komunikovat s původním serverovým objektem přímo, nikoliv prostřednictvím klienta, který mu proxy objekt předal, což je samozřejmě efektivnější. 4.5 Úvod do problematiky pokročilých webových služeb Webová služba tvoří síťově přístupné rozhraní k aplikačnímu kódu, tj. k vlastnímu výkonnému kódu, a to na základě standardních Internetových technologií postavených ve většině případů na otevřených standardech. Webová služba představuje souhrn protokolů a standardů používaných pro výměnu dat mezi aplikacemi přes Internet a také pro vzdálené spouštění procedur. Tyto aplikace přitom mohou být napsané v různých programovacích jazycích a běžet na různých platformách. Postavení webové služby v rámci komunikačního procesu je zobrazeno na Obr Lze říci, že pokud je aplikace přístupná prostřednictvím síťového rozhraní využívajícího protokoly HTTP, XML, SOAP, WSDL nebo UDDI 19 jedná se o webovou službu. Stručně lze říct, že HTTP tvoří servisní transportní protokol, XML se používá na značkování dat, SOAP na přenos těchto dat, WSDL na popis dostupných služeb a UDDI na zjišťování dostupnosti služeb. Nejčastějším případem webové služby jsou v současné době moderní HTML stránky přístupné prostřednictvím standardního webového prohlížeče. 19 V rámci tohoto textu je dále pojednáno pouze o SOAP, ostatní zkratky názvů protokolů jsou uvedeny pouze pro základní orientaci, pouze s krátkým popisem. WSDL je zkratkou Web Services Description Language, UDDI pak Universal Description, Discovery and Integration Protocol.

47 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 47 Webová služba se tedy chová jako abstraktní vrstva oddělující způsob implementace a specifické vlastnosti platformy, na které je vykonáván aplikační kód webové služby, od způsobu, jakým je tento aplikační kód volán. V případě, že se jedná o peer-to-peer uspořádání, můžeme hovořit o middleware vrstvě, jak bylo popsáno v kap Klient Mezilehlá síť (Internet) Webová služba Aplikační kód Obr. 4-9: Postavení webové služby v rámci komunikačního procesu Komunikace s využitím protokolu SOAP Pro přenos dat webových služeb se často používá protokol SOAP (Simple Object Access Protocol), který definuje předpis k výměně informací. Jedná se o textový protokol využívající syntaxi jazyka XML (Extensible Markup Language). Základní vlastnosti protokolu SOAP vycházejí z jazyka XML, mezi které patří pružnost, snadná čitelnost a definice vlastních datových typů, pomocí kterých lze realizovat přenos dat s vlastní strukturou. Zprávy protokolu SOAP nejsou přenášeny přímo, ale jsou zabaleny (zapouzdřeny) uvnitř jiných komunikačních protokolů, které tak slouží jako transportní protokoly. Nejčastějším příkladem je umístění uvnitř HTTP protokolu, který je přenášen prostřednictvím TCP spojení mezi klientem a serverem, na kterém je umístěna webová služba. Celkový pohled na protokoly používané při komunikaci s webovou službou je znázorněn na Obr SOAP XML HTTP TCP/IP Obr. 4-10: Sada protokolů při komunikaci s webovou službou

48 48 FEKT Vysokého učení technického v Brně Nejčastěji se SOAP používá jako náhrada vzdáleného volání procedur RPC (Remote Procedure Call), což odpovídá modelu požadavek/odpověď. Jedna aplikace pošle v XML zprávě požadavek druhé aplikaci, ta požadavek obslouží a výsledek zašle jako druhou zprávu zpět původnímu iniciátorovi komunikace. V tomto případě bývá webová služba vyvolána webovým serverem, který čeká na požadavky klientů a v okamžiku, kdy přes HTTP přijde SOAP zpráva, spustí webovou službu a předá jí požadavek. Výsledek služby je pak předán zpět klientovi jako odpověď.

49 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 49 5 Procesy a systémy 5.1 Problematika návrhu systémů Při projektování rozsáhlých nejen komunikačních programových systémů je při jejich návrhu vhodné uplatňovat stanovené postupy, které spočívají v pevně daném sledu činností. Celou existenci libovolného programového systému lze od počátku po konec rozdělit do pěti základních etap: Definice problému, který má systém řešit (nově vznikající nebo úprava již existujícího), Specifikace chování systému, Implementace systému, Výroba nebo nasazení systému, Využívání systému. požadavky Vlastnosti okolí, technické možnosti Využívání systému Systém vyhovuje NE ANO Definice problému Určené funkce, objekty Specifikace chování Systém NE Ověření specifikace ANO Výroba, nasazení Abstraktní systém ANO NE Testování prototypu Prototyp NE Ověření implementace ANO Implementace Obr. 5-1: Vývojový diagram vzniku a existence systému

50 50 FEKT Vysokého učení technického v Brně Tuto posloupnost kroků a rozhodnutí je možné přehledně zaznačit pomocí vývojového diagramu znázorněného na Obr Pět základních stavů přibližují následující kapitoly Fáze definice problému V tomto počátečním kroku jsou nejdříve sbírány poznatky, zkušenosti a obecnější představy o určení systému, taktéž o programovém a technickém vybavení, které bude systém následně využívat. Musí být vypracován úplný rámec funkcí případně objektů, které budou potřeba pro řešení daného problému. Takovýto seznam může být zpracován neformálně nebo pomocí některého problémově orientovaného popisného jazyka. Je zřejmé, že nepřesná nebo nejasná definice problému může vést k jeho špatnému pochopení a tím logicky i ke špatné specifikaci. Při definování vnějšího chování systému se musí vzít v úvahu i vlastnosti veškerého okolí systému a technické možnosti řešení. Definice problému by proto měla obsahovat: Zadání vstupních dat (jejich strukturu, formát a množiny přípustných hodnot), Určení výstupních dat (jejich strukturu, formát a v neposlední řadě i jejich závislost na vstupních datech), Definici výjimečných situací (např. požadovaná reakce na chybná vstupní data). Forma definice problému závisí na jeho složitosti a na oblasti aplikace. Jednoznačná definice problému je obzvlášť důležitá u rozsáhlých systémů. Výsledkem tohoto kroku je určení požadavků a definice funkcí případně objektů, které budou tyto požadavky naplňovat, především však v obecné rovině Fáze specifikace chování systému V této části se provádí úplná specifikace chování systému. K tomu existují tzv. specifikační jazyky, např. SDL (Specification and Description Language). Na úrovni specifikace lze provést simulaci chování systému a tím verifikovat správnost návrhu. Tento postup umožňuje předem odhalit různé druhy chyb a ušetřit tak prostředky na vývoj špatně navržených systémů. V tomto kroku se provádí rozklad problému na menší podproblémy a tyto dílčí problémy se případně ještě dále dělí tak dlouho, dokud se nedostaneme od úrovně abstraktních operací k úrovni použitelné následně v programovacím jazyku v dalším kroku. Nedílnou součástí této algoritmizace je i postupný návrh datových struktur, s nimiž bude program dále pracovat. Výsledkem tohoto kroku je návrh abstraktního systému, který: Určuje architekturu systému, jednotlivých složek systému a rozhraní mezi nimi, popisuje chování systému, specifikuje datové struktury.

51 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO Fáze implementace V této části návrhu je prováděn převod navrženého abstraktního systému do zápisu programu (zdrojový kód), což bývá též nazýváno kódování. Stanovuje se, jakým způsobem se budou realizovat požadované funkce systému dle specifikace. Tento převod může být provázen více způsoby, od teoreticky plně automatických metod, přes poloautomatické až po ruční metody. Programy je vhodné psát modulárně (rozložit na podprogramy) a výslednou strukturu vhodně pospojovat. Součástí implementace musí být i ověření a ladění těchto autonomních částí programu (modulů), které vede ke zvyšování celkové spolehlivosti budoucího systému. Výsledkem fáze implementace je prototyp. Prototyp se často nejdříve testuje za pomocí simulátorů, které umožňují např. imitovat funkce připojených zařízení, poruch, měnit zatížení, opakovaně provádět požadovanou činnost apod. V dalším kroku se prototyp nasadí zkušebně do skutečného provozu v reálných provozních podmínkách. Je pak možné statisticky vyhodnotit výsledky zkoušek a také zkušenosti z údržby systému Fáze výroba, nasazení V této etapě jsou sestaveny kompletní soubory programu a dat pro danou aplikaci a jsou zapsány na vhodná paměťová média a připraveno na dodání spolu s celým systémem (technickým vybavením) a dokumentací o systému Fáze využívání systému a jeho údržba Poté co byl systém nasazen a je využíván k účelu, ke kterému byl navržen, mohlo by se zdát, že již není nic dalšího potřeba. Systém je však nutné celou jeho existenci spravovat a udržovat. Údržba (zejména programového vybavení) však spočívá v: Dohledávání, analýze a opravě chyb a nedostatků, distribuce nových verzí uživateli. Aktualizaci programového vybavení podle měnícího se okolí systému (fyzického, právního, aj.). Případně i v doplňování programového vybavení o nové funkce a služby, to vše za provozu a bez jakýchkoliv ztrát Ověření správnosti Významným krokem, který je využíván prakticky v každém kroku při vývoji systému, je ověření správnosti řešení (verifikace). Včasné zachycení závažných chyb umožňuje snížit náklady na vývoj celého systému. Pro ověřování správnosti jsou potřeba výkonné technické prostředky, které umožní přesnou analýzu možných druhů chování systému. Získat formální důkaz správnosti je však pro složité programy prakticky nemožné.

52 52 FEKT Vysokého učení technického v Brně 5.2 Teorie konečných automatů Úvod do teorie konečných automatů Když vytváříme specifikaci systému (např. viz kap ), je dobré si stanovit určité základní požadavky na techniku formálního popisu, jako jsou např.: Tvorba jednoznačných, jasných a stručných specifikací, Možnost verifikování specifikace, Snadný vývoj implementací ze specifikace, přičemž specifikace by měla být implementačně nezávislá. Zejména rozsáhlé systémy vyžadují jednoznačný popis. Jedním z možných prostředků jak toho dosáhnout je i teorie konečných automatů. Každý systém lze popsat pomocí stavů vstupních veličin X, kde X se mění v závislosti na čase, a pomocí výstupních veličin Y, jejichž hodnoty jsou zpravidla závislé na vstupních veličinách. Skupinu vstupních veličin X označme jako vstupní vektor, podobně skupinu výstupních veličin Y jako výstupní vektor systému. U našeho systému zároveň předpokládáme obecně i určité vnitřní stavy, tj. stavy ve kterých se systém aktuálně nachází, značené Q. Situaci ilustruje Obr Počet vstupních a výstupních proměnných, stejně tak jako vnitřních stavů je konečné diskrétní číslo, v obrázku značeno jako m pro počet vstupních veličin, n pro počet výstupních veličin a r pro počet možných vnitřních stavů. Vstupní vektor { Výstupní X 1 X 2... X m Systém Q 1 Q r Y 1 Y 2... Y n }vektor Obr. 5-2: Obecná struktura systému se vstupy, výstupy a vnitřními stavy Dva typy systémů můžeme rozlišit pomocí kombinačních sítí a sekvenčních sítí., kterým se budeme věnovat v následujícím textu Kombinační sítě Kombinační sítě (Obr. 5-3) jsou charakterizovány jednoznačným přiřazením výstupní kombinace na každou vstupní kombinaci. Systémy popsané pomocí kombinační sítě tedy nemají definované žádné vnitřní stavy a skládají se pouze z: Vstupů, které jsou tvořeny vstupním vektorem X = (x1, x2,, xm), Výstupů, které jsou tvořeny výstupním vektorem Y = (y1, y2,, yn), Funkce f, která určuje jednoznačný převod vstupního vektoru X na výstupní vektor Y. Funkce může být definována matematicky, převodní tabulkou apod.

53 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 53 Vstupní vektor { Výstupní X 1 X 2... X m Systém Y = f(x) Y 1 Y 2... Y n }vektor Obr. 5-3: Systém typu kombinační síť Za kombinační sítě můžeme považovat například hradla z oblasti digitální techniky, které představují velmi jednoduché systémy, konkrétně např. hradlo NAND (Not AND), NOR (Not OR), které skutečně nemají žádné vnitřní stavy, pouze se na základě vstupu mění výstup. Z oblasti komunikačních technik nám jako příklad poslouží jakýkoliv bezestavový systém, který funguje pouze na principu dotaz odpověď, bez jakéhokoliv dalšího mechanizmu. Je to tedy např. původní HTTP (HyperText Transfer Protocol), který funguje skutečně pouze tak, že jedna strana (klient) si vyžádá konkrétní stránku, druhá (server) ji poskytne, a tím celá relace končí Sekvenční sítě Sekvenční sítě, na rozdíl od kombinačních, mají nějakým způsobem zakomponovanou vnitřní paměť, která jim umožňuje udržovat si informaci o vnitřním stavu systému Q. Hodnoty výstupního vektoru pak nezávisí pouze na vstupním vektoru, ale zároveň i na stavu systému tak, jak ilustruje Obr Z logiky věci vyplývá, že sekvenční systém musí pracovat diskrétně, nelze ho uvažovat jako spojitý. Systém pracuje sekvenčně, tj. po krocích, označíme-li např. vektor jeho vnitřního stavu Qn v kroku n, v dalším kroku bude vnitřním stavem Qn+1, atd. Systém Vstupní vektor Stav systému [X m ] [Q r ] Kombinační síť Paměť vnitřních stavů [Y n ] Výstupní vektor Obr. 5-4: Systém typu sekvenční síť Sekvenční sítě jsou tedy definovány prostřednictvím: Vstupů, které jsou tvořeny vstupním vektorem X = (x1, x2,, xm),

54 54 FEKT Vysokého učení technického v Brně Výstupů, které jsou tvořeny výstupním vektorem Y = (y1, y2,, yn), Vnitřních stavů, které jsou dány pamětí obsahující informace o předešlých stavech, značeno taktéž vektorem Q = (q1, q2,, qr), kde r může být chápáno jako kapacita paměti. Počet vnitřních stavů je stejně jako počet možných vstupů a výstupů konečný, odtud pochází název konečné automaty, Operací, pro každé n 0 síť spočítá pomocí vstupního vektoru Xn v daném kroku a aktuálního vnitřního stavu Qn nový vnitřní stav Qn+1. Výstup Yn je tedy dán pomocí Xn a Qn. V systému jsou definovány dvě (obecně odlišné) funkce: o Přechodová funkce Qn+1 = f1 (Xn, Qn), o Výstupní funkce Yn = f2 (Xn, Qn). Jinými slovy, stavem konečného automatu S se rozumí popis v bodě n, tedy množina (Xn, Qn, Yn), což není nic jiného než aktuální vstupy, vnitřní stav a výstupy. Cesta v síti je založena na aktuálním vnitřním stavu a vstupu. Následníkem je takový vnitřní stav Q, do kterého systém přejde. Přímým následníkem je stav, do kterého konečný automat přejde bezprostředně, nepřímý následník je stav, který vyžaduje nejméně dva přechody. Jak částečně vyplývá z předchozího textu, algoritmus sekvenční sítě musí mít následující vlastnosti: Determinizmus poskytované řešení musí být jednoznačné, Hromadnost musí poskytovat možnost řešení (třídy) skupiny úloh, Konečnost počet vnitřních stavů je omezen. Skupina dříve uvedených veličin (X, Y, Q, f1, f2) bývá ještě vždy doplněna o šestý symbol počáteční stav S0, který popisuje stav systému (sekvenční sítě) na počátku jeho běhu. Jako příklady sekvenčních systémů z oblasti digitální techniky si můžeme uvést například klopné obvody, konkrétně např. obvod RS (reset-set) či JK. U těchto obvodů existují jisté vnitřní stavy, které zároveň se vstupem ovlivňují, co bude na výstupu. Z oblasti komunikačních technik si můžeme jako příklady uvést např. protokol TCP (Transmission Control Protocol) či protokol DHCP (Dynamic Host Configuration Protocol), u kterých je komunikace dvou stran založena na určitém dialogu a obě strany si udržují přehled o tom, v jaké fázi se aktuální tato komunikace nachází Tabulka přechodů a výstupů Na Obr. 5-4 bylo znázorněno, jak lze sekvenční síť zakreslit pomocí kombinační sítě a paměti. Existuje však více způsobů, sekvenční sítě lze zapsat např. pomocí rovnic (viz výše), případně pomocí pravdivostních tabulek. K zápisu lze taktéž využít dvě další tabulky: tabulku výstupů a tabulku přechodů, jak ukazují Tab. 2 a Tab. 3, případně lze obě tabulky sloučit do jedné, viz Tab. 4. Tyto tabulky umožňují plně popsat konečný automat, konkrétní hodnoty uvedené v tabulkách demonstrují zadání Příklad 5.1.

55 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 55 Příklad 5.1 Detektor binární sekvence 101 Mějme konečný automat, který realizuje triviální funkci detektoru binární (sériové) sekvence 101. Detektor má jeden vstup a jeden výstup, přičemž množina všech vstupů je X = {1, 0}, (X1 = 1, X2 = 0) a množina všech možných výstupů Y = {0, 1}, kde Y1 = 0 znamená, že hledaná posloupnost dosud nebyla detekována, hodnota Y2 = 1 opak. Automat má definovány celkem čtyři vnitřní stavy Q1, Q2, Q3 a Q4, přičemž Q1 je výchozím stavem, Q4 konečným stavem. Automat svou činnost zdárnou detekcí hledané posloupnosti 101 končí a následně na libovolný vstup už žádným způsobem nereaguje a zůstává v konečném stavu Q4. Tabulka výstupů Každá výstupní funkce pro jednotlivé stavy Q může být reprezentována pomocí tabulky obsahující výchozí stav Q a odezvu na výstupu Y vyvolanou jedním z možných vstupů X. Hodnoty v tabulce Tab. 2 popisují výše definovaný detektor binární sekvence. Tabulka přechodů Každá přechodová funkce pro jednotlivé stavy Q může být reprezentována pomocí tabulky obsahující výchozí stav Qn a následný stav Qn+1, který byl vyvolán vstupem X. Uvedená tabulka Tab. 3 náleží taktéž k výše definovanému detektoru binární sekvence. Tab. 2: Tabulka výstupů > výstup(výchozí stav; vstup) Vstup Výchozí stav X 1 X 2 Q 1 Y 1 Y 1 Q 2 Y 1 Y 1 Q 3 Y 2 Y 1 Q 4 Y 2 Y 2 Tab. 3: Tabulka přechodů > nový stav(výchozí stav; vstup) Vstup Výchozí stav X 1 X 2 Q 1 Q 2 Q 1 Q 2 Q 2 Q 3 Q 3 Q 4 Q 1 Q 4 Q 4 Q 4 Složená tabulka přechodů a výstupů Dvě výše uvedené tabulky můžeme sloučit do jedné. Tato tabulka (Tab. 4) tak obsahuje zápis jak přechodové funkce, tak i výstupní funkce.

56 56 FEKT Vysokého učení technického v Brně Tab. 4: Složená tabulka > [nový stav, výstup](výchozí stav; vstup) Vstup Výchozí stav X 1 X 2 Q 1 Q 2, Y 1 Q 1, Y 1 Q 2 Q 2, Y 1 Q 3, Y 1 Q 3 Q 4, Y 2 Q 1, Y 1 Q 4 Q 4, Y 2 Q 4, Y 2 Spojující matice Dalším možným vyjádřením konečného automatu je tzv. spojující matice, kdy je pro danou síť (mající Q stavů) konstruována tabulka o stejném počtu řádků i sloupců a tento počet odpovídá počtu vnitřních stavů Q. Známe dva typy spojující matice, přechodová nebo výstupní, případně lze využít složené varianty, jako je dále uvedená. Tab. 5. V matici jsou nejprve uvedeny vstupy a čárkou odděleny výstupy. Na řádku je uveden výchozí stav, následujícímu stavu, do kterého automat přejde, pak odpovídá sloupec. (Tabulka popisuje stále stejný příklad.) Zajímavostí uvedeného příkladu je, že v posledním výchozím stavu Q4 máme dvě možnosti, které mají za následek stejný nový stav, taktéž Q4. Tab. 5: Spojující matice (složená varianta) Nový stav Výchozí stav Q 1 Q 2 Q 3 Q 4 Q 1 X 2, Y 1 X 1, Y Q 2 0 X 1, Y 1 X 2, Y 1 0 Q 3 X 2, Y X 1, Y 2 Q X 1, Y 2 X 2, Y 2 Pozn.: Pomocí výše uvedených tabulek je možné (různými metodami) konečný automat (zejména ve složitějších případech) zjednodušit, a to snížením počtu vnitřních stavů. Tato problematika je však nad rámec tohoto předmětu Grafická reprezentace konečných automatů V předcházející kapitole jsme se seznámili s konečnými stavovými automaty (finite state machine = FSM) a jejich zápisem pomocí několika různých druhů tabulek. Dalším velmi častým způsobem je zápis ve formě grafu. Mezi jeho přednosti patří zejména přehlednost a dobrá čitelnost. Takovýto graf se skládá z: Uzlů které jsou zaznačeny kroužky a reprezentují jednotlivé vnitřní stavy Qi, případně i hodnotu výstupního vektoru Yi (viz dále), Orientovaných spojnic spojují vždy jednosměrně dva uzly.

57 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 57 Běžně se používají dva základní typy grafické reprezentace: Mealyho automat U Mealyho automatu platí, že každý uzel určuje jeden stav Qi. Existuje tolik uzlů, kolik existuje stavů. Pro daný pár stavů Qi, Qj existuje nula, jeden nebo i více přechodů zapsaných pomocí orientovaných křivek. Nad spojnici bývá zaznačeno, jaká událost (vstup Xi) přechod vyvolala a za lomítkem pak odpovídající výstup Yi. Jinými slovy lze říci, že výstup závisí jak na aktuálním stavu, tak na vstupu. Ilustrativní příklad je znázorněn na Obr [X i ] / [Y i ] Q i Q j Obr. 5-5: Mealyho automat Mooreho automat Naproti tomu u Moorova automatu platí, že každý uzel určuje nejen stav Qi, ale i odpovídající výstup Y, který je tak možné přímo považovat za funkci stavu, což je formálně zapsáno jako Y(Qi). Nad spojnicí bývá naznačen pouze vstup Xi, který změnu stavu vyvolal. Situace je ilustrována na Obr Jinými slovy lze říci, že výstup automatu vychází pouze z aktuálního stavu, přechody mezi stavy zajišťuje vstup. Výhodou Moorova automatu je snadná čitelnost popisu chování dané sítě z grafu, popis systému pomocí Mealyho automatu však může být v určitých případech stručnější. Je třeba zdůraznit, že se jedná pouze o rozdílný popis, výsledný systém je však následně, co se týká jeho chování, stejný. Q i /Y(Q i ) [X i ] Q j /Y(Q j ) Obr. 5-6: Mooreho automat Nyní si pomocí Mealyho i Mooreho automatu zakresleme předcházející Příklad 5.1, jež jsme v kap zapisovali pomocí tabulek. Situace je znázorněna na Obr Oba tyto grafy nám umožňují přehledně zapsat funkci detektoru binární sekvence 101, již na první pohled je jejich funkce zřejmější než z tabulkového zápisu. Výše uvedený a různými metodami popisovaný příklad je možné považovat za naprosto triviální. Existují stavové automaty s mnohem větším počtem stavů, případně vstup X nese více hodnot a ty jsou vyjádřeny vektorem, jak bylo uvedeno v úvodu kapitoly, X = (x1, x2,, xm), podobně může být i výstup Y taktéž definován vektorem, Y = (y1, y2,, yn). Situace se pak samozřejmě komplikuje a grafický zápis již nemusí být tak přehledný jako na Obr Obecně je možné prakticky libovolný (a nejen) telekomunikační systém specifikovat chováním konečného automatu a zapsat výše uvedenými způsoby. V některých případech samozřejmě nevystačíme pouze s jedním stavovým automatem, ale v systému jich existuje

58 58 FEKT Vysokého učení technického v Brně více, běží paralelně, závisle nebo nezávisle na sobě. Jejich počet je dán počtem procesů, které daný systém využívá. 0 / 0 Q 1 1 / 0 1 / 0 Q 2 0 / 0 0 / 0 Q 3 1 / 1 1 / 1 Q 4 0 / 1 a) Q 1 / Q 2 / 0 0 Q 3 / Q 4 / 1 0 b) Obr. 5-7: Zápis příkladu Příklad 5.1 pomocí a) Mealyho b) Mooreho automatu

59 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 59 INIT / TIMEOUT / DISCOVER / TIMEOUT SELECTING OFFER SELECT OFFER / REQUEST OFFER / COLLECT ACK not accepted / DECLINE NAK / ERASE REQUESTING ACK / RECORD LEASE TIME OFFER, ACK, NAC / Discard BOUND PRE-EXPIRED LEASE / REQUEST RENEWING ACK / RECORD LEASE TIME Obr. 5-8: Stavový automat reprezentující chování DHCP klienta (zjednodušená verze) Jako příklad z oblasti komunikačních technik poslouží stavový automat reprezentující chování DHCP klienta. Velmi komplexní popis je možné nalézt v RFC 2131, ještě podrobnější pak v dalších zdrojích na Internetu. Jako ukázka nám postačí zjednodušená varianta, která je uvedena na Obr Popis by měl být zřejmý přímo z obrázku, je patrné, že se jedná o automat Mealyho typu. Popis však bohužel není zcela jednoznačný (odbočky šipek), což samozřejmě odporuje formálním požadavkům teorie konečných automatů. Druhý příklad reprezentuje chování protokolu TCP při navazování ( Obr. 5-9 ) a také ukončování spojení ( Obr ), opět se jedná pouze o zjednodušené varianty, které však plně postačují pro vysvětlení podstaty věci. Plnou verzi lze nalézt např. v RFC 793 (resp. jeho případných nástupcích). Dokument popisuje chování protokolu TCP. Popis chování by opět měl být zřejmý přímo z obrázků a i v tomto případě se jedná o stavové automaty Mealyho typu. I v tomto případě platí, že z formálního hlediska nejsou tyto nákresy zcela v pořádku, nicméně oba velmi dobře reprezentují realitu využívání této teorie v praxi.

60 60 FEKT Vysokého učení technického v Brně Cesta klienta Cesta serveru Neobvyklé cesty LISTEN / CLOSED CLOSE / CONNECT / SYN SYN / SYN + ACK LISTEN CLOSE / RST / SEND / SYN SYN RECEIVED SYN / SYN + ACK (souběžné spojení) SYN SENT ACK / ESTABLISHED SYN + ACK / ACK Obr. 5-9: Stavový automat reprezentující navazování spojení u TCP protokolu (zjednodušená varianta) ESTABLISHED CLOSE / FIN FIN / ACK FIN WAIT 1 FIN / ACK CLOSING CLOSE WAIT ACK / FIN + ACK / ACK ACK / CLOSE / FIN FIN WAIT 2 FIN / ACK TIME WAIT LAST ACK Aktivní ukončení Pasivní ukončení Neobvyklé cesty Timeout CLOSED ACK / Obr. 5-10: Stavový automat reprezentující ukončování spojení u TCP protokolu (zjednodušená varianta)

61 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO Procesy, paralelní systémy a související pojmy Popis systému V případě, že se budeme snažit kompletně popsat chování složitého systému pomocí jednoho stavového diagramu (resp. u programového vybavení jediným sekvenčním programem), došli bychom k závěru, že je to v mnoha případech prakticky nemožné. Proto je výhodnější, je-li tento jeden velmi složitý automat rozdělen do mnoha méně složitých automatů, které nazveme procesy. Procesy tak reprezentují chování jednoduchých konečných automatů a ve svém celku pak reprezentují chování celého složitého konečného automatu. Vyjádřit chování systému na zpracování N událostí pomocí jednoho automatu je výrazně obtížnější, než pomocí N stavových diagramů, kde každý automat zpracovává jen jednu událost. Mechanismus rozdělení na jednotlivé procesy mimo jiné způsobuje, že není v mnoha případech nutné sledovat, v jakém pořadí se události vyskytly. Rozčlenění složitého stavového diagramu na jednotlivé procesy zjednodušuje jeho koncepci i realizaci a usnadňuje též splnění požadavku na rychlou odezvu. Přitom je však nutné splnit podmínku, že každý z těchto N procesů má vytvořené vlastní prostředí (tj. vlastní stavy, vstupy a výstupy). Pokud bude nutné, aby tyto procesy vzájemně spolupracovaly, nemohou být vyvíjeny úplně nezávisle. Musí mezi nimi existovat nějaký styčný bod, typicky nazývaný a používaný jako rozhraní (interface). Paralelní systém můžeme chápat jako systém, ve kterém je současně rozpracováno několik procesů, které sdílejí společné systémové prostředky a mohou spolu komunikovat. Vzájemné vazby mezi procesy pak budou probíhat podle pravidel, která zajistí u každého procesu výlučné a samostatné zpracování posloupnosti za sebou prováděných operací Systém reálného času Systém reálného času je takový systém, který je schopen včas reagovat na vnější podněty. Říkáme, že systém pracuje v reálném čase, proto systém reálného času. Jakákoliv aktivita systému reálného času, při níž se zpracovává informace, musí dát odpověď na vnější podnět v konečné, předem stanovené lhůtě, tj. odezva systému musí bezprostředně následovat. Zpravidla se setkáváme se systémy, jejichž odezva je očekávána např. v řádu stovek ms. Jelikož podněty vznikají v reálném světě v nepředvídatelných časových okamžicích, nepředvídatelném pořadí a někdy i těžko předvídatelném objemu, není struktura systému reálného času triviální. Předpokladem pro úspěšné zvládnutí těchto požadavků je paralelní zpracování problému. Charakter a vlastnosti systémů reálného času vychází zjednodušeně ze tří základních abstrakcí: skupina procesů, které umožňují vyjádřit potřebu souběžně prováděných činností (řízení, snímání dat, jejich zpracování, sledování nebezpečných situací, atd.), komunikačních (a synchronizačních) kanálů, které zajišťují vzájemnou výměnu informací mezi procesy nebo vstup událostí z okolí do systému,

62 62 FEKT Vysokého učení technického v Brně událostmi, které soutěží mezi sebou, neboť jedna událost se může vyskytnout ve chvíli, kdy je jiná událost zpracována. Aby systém reagoval na výskyt více událostí správně, je nutné stanovit pořadí zpracování událostí. Ucelený problém (např. uživatelem požadovaný výpočet), který řeší systém reálného času, se zpravidla nazývá úloha. Ta je tvořena skupinou závislých (kooperujících) procesů řešících společné zadání. Základní problémy paralelních systémů se dají shrnout do: Specifikace a vytváření paralelních procesů, Jejich vzájemná komunikace a ukončení, Programování vstupních nebo výstupních zařízení (častým problémem je, že s jedním zařízením může pracovat v jednom okamžiku pouze jeden proces), Ošetření specifických typů chyb, které se v multi-procesových systémech mohou vyskytnout Procesy Definice procesu Každý proces je složen z posloupnosti příkazů (vstupů) K0, K1,... a posloupnosti stavů S0, S1,... (můžeme rozumět stavy paměti). Pod pojmem proces pak budeme rozumět konečnou množinu dvojic příkazů a stavů: Proc (P, S 0 ) = (K 0, S 0 ), (K 1, S 1 ),... tak, že ke každé dvojici (Ki, Si) je jednoznačně definována následující dvojice (Ki+1, Si+1). Jedná se tedy o obdobu konečného automatu, kde byl následující stav jednoznačně určen výchozím stavem a vstupem. Každý proces operuje nad nějakými objekty a má určitý efekt, který spočívá např. v předem dané transformaci objektů. Objekty, s nimiž operují procesy, se nazývají data. Vlastnosti dat, např. jejich označení, struktura množina možných hodnot, přípustné operace apod., se v programu specifikují pomocí deklarací. Proces může být prováděn až od chvíle, kdy nastane určitá událost, ať již vnější nebo vnitřní (vypršení časového limitu pro pozdržení práce procesu, požadavek na pokračování procesu od jiného procesu, atd.). Proces může být těmito událostmi synchronizován, o tom bude řeč dále. Stavy a přidělování procesů Proces se zjednodušeně nachází pouze ve dvou režimech. Prvním z nich je bod procesu, kdy nejsou vykonávány akce, tj. proces je v klidu (čekající) vůči okolí a čeká na popud zvenčí. Do druhého režimu se proces dostane po přijetí vnější události a stane se činným, tj. začne provádět posloupnost akcí odpovídajících přijaté události. Tehdy je proces aktivní. Tyto dva režimy procesu se neustále střídají, dokud proces existuje. Poměr dob obou režimů procesu závisí na množství výskytů události a době aktivity procesu. Situaci ilustruje Obr

63 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 63 deaktivace Aktivní Čekající Příchod očekávaných událostí Paralelní procesy aktivace Obr. 5-11: Nejjednodušší rozdělení stavů procesu Jak bylo uvedeno dříve, pro definování složitého problému je výhodnější jej rozdělit na množství menších problémů a tyto pak řešit samostatnými algoritmy. Tak de facto vzniknou paralelní procesy. Paralelní procesy lze definovat tak, že jsou dány virtuální (abstraktní) stroje, které mají alespoň část paměti vlastní. Každý virtuální stroj pak představuje jeden z paralelních procesů. Obecně jsou paralelní (souběžné) procesy takové, pro které platí, že počátek vykonávání jednoho procesu spadá do běhu procesu druhého. Paralelní procesy jsou tak definovány v závislosti na souběžném vykonávání příkazů v čase, ale ne již na rychlosti vykonávání příkazů. Ta může být libovolná a je vždy závislá na povaze úkolu. Jsou-li dva nebo více procesů paralelní (podle předcházející definice) a zároveň jsou tyto procesy totožné, existuje tentýž proces ve více kopiích a nazýváme je instance. Jako příklad si můžeme představit popis telefonní ústředny, který byl v dřívějších letech předmětem cvičení z předmětu Komunikační technologie (BKOM). V ústředně existuje jeden typ procesu na obsluhu volání účastníků, tzv. "spojovací úloha". Ta existuje současně tolikrát, kolik probíhá zároveň volání, neboť všichni účastníci jsou ekvivalentní a všichni se v reálném systému chovají paralelně. Obecně v takovémto systému samozřejmě dochází pravidelně ke vzniku a zániku instancí procesu v závislosti na chování účastníků. Determinismus paralelních procesů Determinismus paralelních procesů je definován tak, že spustíme-li daný paralelní proces několikrát se stejnými vstupními daty, musíme vždy obdržet tytéž výsledky a nejenom to i vnitřní průběh programu by měl být totožný Vznik a zánik procesů Vznik procesu Formálně jsou procesy určitou obdobou procedur. Deklarace procesu je popisem množiny akcí a množiny stavů, podobně jako u procedury, viz Obr Vznik procesu nemůže proběhnout bez provedení deklarace procesu. Na základě jedné definice procesu lze spustit dvě a více dynamických kopií - instancí s různými či stejnými parametry. Nově vzniklým procesům jsou vnitřním mechanismem nadřazeného systému přiřazeny identifikátory procesů. Ty je jednoznačně identifikují a umožňují např. jinému procesu

64 64 FEKT Vysokého učení technického v Brně odvolat se na jiný apod. I instance samotná zná svoji totožnost. Tím je umožněna synchronizace a komunikace mezi procesy. Vytvoření instance procesu (jeho počáteční inicializace) nastává dvěma způsoby: zvláštním příkazem na způsob "Vytvoř proces", který je obdobou volání procedury. V případě procedury si můžeme představit, že proces volající proceduru je blokován, dokud není volaná procedura dokončena, kdežto při vytvoření nového procesu mohou volaný a volající proces probíhat nadále souběžně. Vzniká tak de facto nová větev programu, viz Obr Dále již existují dva procesy, tj. proces A pokračuje a nový proces B, přičemž oba probíhají souběžně a asynchronně. Pozn.: V Obr jsou stavy, kterými proces prochází značeny vodorovnou čárou a popisem, kde např. S3 A znamená, že se jedná o třetí stav procesu A apod. vznikem instance procesu v závislosti na vzniku systému. V tomto případě je nutno určit počet instancí procesu, které vzniknou v době vzniku celého systému. Dále je běžné uvádět i maximální počet instancí procesu, který může vzniknout v době života systému. Proces A Proces A S 1 A S 1 A S 2 A S 2 A S 3 A Volání procedury S 1 P A S 3 A S 4 Vytvoř proces B Proces B S 2 P S 5 A S 1 B S 3 P S 6 A S 2 B S 4 A Návrat z procedury S 7 A S 3 B a) b) Obr. 5-12: Rozdíl mezi a) voláním procedury a b) vytvořením procesu V praxi se vznik systému obvykle děje takovým způsobem, že existuje jeden kořenový proces, který postupně spouští ostatní požadované procesy. Při aktivaci procesů při vzniku systému je nutné obvykle dodržet jistou posloupnost spouštění dalších procesů, jejichž činnost je nezbytná pro správný chod systému. Pro snadnější orientaci při spuštění systému se navrhuje tzv. aktivační schéma systému (Obr. 5-13). Z něj je zřejmé, že existuje přirozená hierarchie mezi procesy: vytvářející proces se nazývá proces-rodič a spouštěné (nově vznikající) procesy jsou procesy-potomci, přičemž každý nově vzniklý proces může vytvářet další nové procesy-potomky (viz obrázek). Potomci mohou být kopie téže deklarace procesu (typu procesu) nebo může být jejich deklarace odlišná. V obrázku jsou jako

65 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 65 příklad používány dva druhy deklarací nového procesu, rozlišeny znaky P a Q. Vztah mezi procesy-rodiči a procesy-potomky z hlediska jejich existence bývá různý. Od nezávislosti této vazby, až k vazbě, která omezuje dobu života potomka pouze po dobu života rodiče. Procespotomek - rodič (P1) Procespotomek (P4) Hlavní proces (rodič) Procespotomek (P2) Procespotomek (Q2) Procespotomek (Q1) Obr. 5-13: Příklad aktivačního schématu systému Ukončení činnosti procesu Proces končí svoji činnost provedením příkazu pro ukončení. Rozlišujeme dva typy těchto ukončení: normální ukončení procesu, kdy proces sám ukončí svoji činnost po provedení posledního příkazu. Tento způsob nabízí zřejmou výhodu, že proces může ošetřit jím rozpracované úlohy (např. uvolnit obsazené sdílené prostředky), jelikož ví, že končí. Riziko havárie (uváznutí) celého systému je v tomto případě prakticky nulové. násilné ukončení procesu, kdy činnost procesu je ukončena bez jeho souhlasu operací typu "Zruš proces X". Tohoto způsobu nejčastěji využívají procesyrodičové. Rušit lze v tomto případě pouze konkrétní instanci procesu - je nutné znát její identifikátor. Oba způsoby mají stejný následek, proces je ukončen a jsou zrušeny i všechny objekty vytvořené procesem, jejich rozdílnost a výhodnost prvního ze způsobů je však zřejmá.

66 66 FEKT Vysokého učení technického v Brně 5.4 Komunikace a formy synchronizace mezi procesy Komunikace mezi procesy Paralelní aplikace nebo distribuovaný systém je zpravidla tvořen množstvím spolupracujících procesů, z nichž každý zabezpečuje vykonávání určité funkce. Je naprosto zřejmé, že mezi procesy existuje potřeba výměny informací potřeba komunikace. Komunikace mezi procesy představuje klíčový bod v reprezentaci systému a je to také jedna z forem vzájemné spolupráce procesů (viz dále). V praxi rozlišujeme, zda jsou všechny procesy soustředěny do jednoho bloku (vykonávány na jednom procesoru) nebo jsou distribuovány do více bloků (procesorů). Je také velmi důležité, zda komunikace bude probíhat mezi systémem a jeho okolím nebo uvnitř systému. Nejzákladnější rozdělení způsobů komunikace mezi procesy je na dva způsoby: Asynchronní způsob komunikace Synchronní způsob komunikace Asynchronní způsob komunikace Asynchronní způsob komunikace spočívá v odeslání zprávy procesem bez zdržení jeho dalšího průběhu, tj. když je zpráva předána vysílacím procesem k odeslání komunikačnímu prostředku, vysílací proces se o osud zprávy dále nestará. Vše probíhá bez ohledu na to, zda je zprávu schopen přijímací proces zpracovat. Tento způsob komunikace má výhodu v tom, že proces odesílající zprávu není dále zdržen např. do okamžiku příjmu potvrzení (může neustále pracovat) a je také méně zatěžována komunikační síť. Zřejmou nevýhodou je, že proces není informován o tom, jak, kdy a zda vůbec bylo uskutečněno předání zprávy, což může být v některých případech kritické Synchronní způsob komunikace Synchronní způsob je takový způsob, kdy vysílací proces je ve své činnosti pozdržen do té doby, dokud není přijímací proces schopen zprávu přijmout. K výměně informace dojde až po synchronizaci procesů. Hlavním problémem tohoto způsobu komunikace je riziko tzv. uváznutí, kdy jeden z procesů čeká na spojení s protějším procesem a ten neexistuje nebo případně nepožaduje výměnu informace. Tato situace se obvykle řeší vyvoláním časové výjimky. Naopak výhodou je, že proces, který zprávu odeslal, ví, že jeho zpráva byla příjemci předána. Je zřejmé, že synchronní přenos zpráv komplikuje systém přenosu zpráv tím, že v době, kdy proces čeká (např. na potvrzení o přijetí zprávy), se mohou vyskytnout nové události, vyžadující přenos zpráv apod. Na Obr je graficky znázorněna v předcházejícím textu popisovaná rozdílnost mezi asynchronním a synchronním způsobem komunikace.

67 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 67 Proces A Proces B Proces A Proces B Běh procesu A Vyslání informace Běh procesu A Čekání na synchronizaci Běh procesu A Vyslání informace (požadavek synchronizace) Komunikace Běh procesu B Běh procesu B a) b) Obr. 5-14: a) Asynchronní způsob komunikace b) synchronní způsob komunikace Formy synchronizace mezi procesy Dva na sobě nezávislé procesy je možné považovat za asynchronní, což znamená to, že kroky jednoho procesu jsou nezávislé na krocích druhého procesu. Takovéto procesy nejsou prakticky schopny vzájemné spolupráce, a proto nás z pohledu komunikačních technologií nebudou příliš zajímat. Procesy, které vzájemně spolupracují, je možné považovat za synchronní a musí mezi nimi existovat určitý způsob synchronizace. Pod pojmem synchronizace procesů si můžeme představit to, že v určitých situacích na sebe musí procesy čekat, např. dokud jeden z nich nedokončí určitou operaci, nemohou ani ostatní pokračovat. Synchronizaci, kterou se budeme zabývat v následujících kapitolách, lze zabezpečit více způsoby: Synchronizace komunikací, Synchronizace následkem konkurence, Synchronizace následkem spolupráce Synchronizace komunikací Synchronizace komunikací mezi více procesy jednoho (distribuovaného) systému předpokládá všestranné šíření informací a procesy jsou tak synchronizovány centrálně. To znamená, že jeden proces šíří zprávy všestranně do svého okolí pro sousedící procesy, z nichž každý tuto zprávu přijme. Rozlišujeme několik podtypů:

68 68 FEKT Vysokého učení technického v Brně a) synchronizace událostí Pod pojmem událost rozumíme pouze tzv. "synchronizační impulz", tj. zprávu, která nenese žádnou informaci. Procesy se tak synchronizují pouhou výměnou tohoto impulzu. Jako základní příkazy si lze představit např.: čekej_na_událost(s); pošli_událost(s); kde S značí signál neboli synchronizační impulz. b) synchronizace zprávou V tomto případě ponese synchronizační impuls i zprávu. V systému se pak mohou objevit dva příkazy: čekej_zprávu(z); pošli_zprávu(z); kde Z značí zprávu. c) synchronizace i za pomocí času Existují situace, kdy odezva (očekávaná událost či zpráva z vnějšího prostředí) musí přijít do určité doby nebo pouze v daný čas. V takovém případě je možné obecně doplnit body a) a b) o dva typy časových údajů. Můžeme tedy zavést operaci typu: očekávej_signál (S, T1, T2); kde S je událost či zpráva, kterou smí proces přijmout v časovém intervalu T1 až T2. Na základě časové operace lze odvodit další kombinace časové synchronizace: očekávej_signál (S, T1); znamená, že signál S může přijít teprve po době T1. očekávej_signál (S, T2); znamená, že signál může přijít do doby T2. očekávej_signál (T1); znamená, že vykonávání procesu se má pozastavit o dobu T1. Příkazy, ve kterých se objevuje doba T2, jsou velmi nebezpečné. Pokud totiž nepřijde událost či zpráva do vypršení této doby, dojde k uváznutí procesu. V praxi se tato situace řeší tak, že po vypršení doby T2 je vyvolána příslušná "časová výjimka". Proces tak začne vykonávat činnost, která ošetří vzniklou situaci, tj. že do zvolené doby nebyla provedena synchronizace Synchronizace následkem konkurence Synchronizace následkem konkurence je způsobena přístupem různých procesů k omezenému množství zdrojů v systému. Procesy soutěží o přidělení sdílených prostředků, jejichž množství je v systému omezeno. Příkladem mohou být tiskárny, disky, paměť, procesor nebo prostý výpis na obrazovku. Tento problém se nazývá vzájemné vyloučení procesů, neboť s požadovaným zdrojem může pracovat současně pouze jeden proces. Pro

69 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 69 realizaci tohoto principu se používá řídící abstrakce, která se nazývá kritické sekce, více viz kap Ta obsahuje zpravidla dvě části, mechanizmus přidělení a manipulace s prostředkem a mechanizmus uvolnění prostředku Synchronizace následkem spolupráce V případě synchronizace následkem spolupráce je běh procesu závislý na chodu jiných procesů. Systém pak musí umožnit vstup vnějších událostí do systému, což je obvykle řešeno pomocí obsluhy přerušení. Rozeznáváme dva základní způsoby: synchronizaci na základě podmínek V tomto případě je postup zpracování procesu pozdržen, dokud není splněna jistá podmínka systému. Zde můžeme rozlišovat dva typy systémů, první jsou centralizované systémy, což jsou systémy obsahující globální proměnné v centralizované paměti. Jedná se např. o konstrukci semaforu nebo monitoru boolean proměnné (viz další kapitoly), kdy jsou budovány fronty procesů nad těmito proměnnými. Druhým typem je synchronizace na základě podmínek u distribuovaných systémů. V tomto případě se synchronizace provádí výměnnou zpráv mezi sousedícími procesy. Jako problém se zde jeví, když jeden proces je synchronizován několika jinými procesy. Tehdy se musí vyhodnocovat několik přijatých zpráv. Dalším problémem je nenulový čas přenosu zprávy nesoucí hodnotu. synchronizaci na základě komunikace Tato část již byla pojednána v samostatné kapitole , je možné ji ale považovat i za formu synchronizace následkem spolupráce. Procesy si navzájem vyměňují údaje, které rozhodují o dalším vývoji systému. Způsob předávání zpráv závisí na tom, zda jsou všechny procesy soustředěny do jednoho procesoru nebo jsou distribuovány do více procesorů, přičemž každý procesor může mít vlastní skupinu procesů. U distribuovaných systémů lze tak vytvářet různě složité komunikující systémy s různými závislostmi mezi jednotlivými částmi. Rozdělení úlohy na samostatné procesy přináší výhodu spočívající ve zjednodušení popisu jednotlivých procesů. Nevýhodou je poté časová ztráta při komunikaci a také přenášení stejné informace na více míst (duplicita informace). Vždy je nutno zvážit množství informace, kterou si procesy musí vyměňovat, aby se nestalo, že výhody plynoucí ze souběžného provádění programů, budou zcela potlačeny časovou ztrátou při komunikaci Uváznutí procesu Uváznutí nebo též vzájemné blokování (deadlock) je situace, která může vzniknout: V rámci sekvenčního programu jako nekonečná smyčka programu, Při přidělování (sdílených) prostředků několika procesům, Při výměně zpráv v případě, že jsou tyto události v jednotlivých procesech na sobě závislé.

70 70 FEKT Vysokého učení technického v Brně Poslední případ je charakteristický tím, že dva nebo více procesů čekají nekonečně dlouho na události, které nemohou nikdy nastat. Nastává tak bezvýchodná situace. Uváznutí může nastat pouze tehdy, existují-li v systému alespoň dva závislé procesy. Příklad 5.2 Uváznutí procesů při závislosti dvou procesů jeden na druhém Mějme dva procesy, P1 a P2. P1 má jako podmínku ukončení nastaveno zahájení P2. P2 má nastaveno jako podmínku vzniku dostupnost určitých prostředků, P1 však tyto prostředky blokuje. P2 tedy nemůže vzniknout, protože P1 mu blokuje prostředky, které potřebuje ke svému vzniku a P1 nemůže být ukončen, dokud není zahájen P2 a nedojde v něm k události ukončující P1. Dojde tedy k uváznutí obou procesů. Proto i pro komunikaci procesů musí existovat jistá pravidla, aby se předešlo uváznutí. Jedním z obvyklých přístupů je hierarchická komunikace procesů. Tato metoda spočívá v tom, že se procesy rozdělí do několika tříd. V této hierarchii mohou procesy na nižší úrovni zasílat zprávy procesům na vyšší úrovni, jen je-li to vyžadováno výzvou (tzv. synchronizace pomocí vln, viz literatura). Každý podřízený proces má pouze jeden řídící proces nemůže tak dojít k uváznutí Uváznutí při přidělování sdílených prostředků úplné vyhrazení prostředků Při přidělování prostředků lze nebezpečí uváznutí snížit tzv. statickým přidělováním prostředků. Činnost procesu je zahájena teprve po přidělení všech prostředků k ní potřebných (tzv. úplné vyhrazení prostředků). To má za následek snížení využití prostředků a správce procesů musí mít k dispozici informace o všech prostředcích, které bude úloha potřebovat. Po dobu běhu procesu je pak nepřidělí nikomu jinému. V tomto případě tedy nemůže dojít k zablokování, protože proces nikdy na přidělení nějakého prostředku nečeká. Čeká pouze na své spuštění. Zásadní nevýhodou této metody je obrovské snížení průchodnosti systému, protože jeden proces blokuje daný prostředek celou dobu svého běhu, a to i v případě, že ho používá jen omezenou dobu Uváznutí při přidělování sdílených prostředků hierarchické přidělování prostředků Další možností je dynamické (postupné) přidělování prostředků, kdy dochází k jejich lepšímu využití. Je třeba si uvědomit, že je-li sdílený prostředek přidělen, nemá operační systém možnost jej odebrat procesu a přidělit jej jinému. Prostředek tak zůstává přidělen procesu tak dlouho, dokud jej sám neuvolní. Klasickým příkladem uváznutí procesů při přidělování je uveden na Obr Jak vyplývá z obrázku, proces A (vodorovná osa) vyžaduje k dalšímu postupu postupné přidělení disku a tiskárny a současně proces B (svislá osa) potřebuje ke svému dalšímu postupu postupné přidělení tiskárny a disku, tj. opačný postup přidělování než má proces A. V tomto případě může nastat situace, že proces A má již přidělen disk a čeká na přidělení tiskárny a proces B má již přidělenu tiskárnu a čeká na přidělení disku. K dalšímu postupu je tedy nutné, aby buď proces A uvolnil disk nebo proces B uvolnil tiskárnu. To není možné, neboť oba procesy potřebují výše uvedené prostředky k dalšímu běhu. Došlo tedy k uváznutí.

71 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 71 Postup procesu B Uvolni tiskárnu Uvolni disk Přiděl disk Přiděl tiskárnu Zakázaná oblast Nebezpečná oblast Zakázaná oblast Oblast uváznutí Zakázaná oblast Postupová cesta (pro jednoprocesorový systém) Zakázaná oblast Zakázaná oblast Zakázaná oblast Přiděl disk Přiděl tiskárnu Uvolni disk Uvolni tiskárnu Postup procesu A Obr. 5-15: Postupový prostor procesů Uvedený příklad lze s výhodou znázornit tzv. postupovým prostorem procesů, viz Obr. 5-15, kde postupová cesta znázorňuje relativní postup běhu procesů (uvedeno pro jednoprocesorový systém). Je zde znázorněna nebezpečná oblast, do které když vstoupí postupová cesta, dojde nutně k uváznutí. Zakázané oblasti pak zobrazují oblast, do které když vstoupí jeden proces, je druhý blokován. K tomu, abychom zabránili výše uvedenému způsobu uváznutí, jsou uspořádány všechny prostředky do jisté hierarchie. Tak je dovoleno procesům alokovat prostředky kdykoliv chtějí, ale pod jednou podmínkou musí prostředky požadovat ve vzrůstajícím pořadí podle dané hierarchie a uvolňovat je naopak v pořadí klesajícím. Tím dosáhneme toho, že v kterémkoliv okamžiku existuje v systému alespoň jeden proces, který nemůže být zablokován. V praxi se tato metoda často kombinuje s metodou úplného vyhrazení prostředků v tom smyslu, že na jedné úrovni nebývá jediný prostředek, ale celá skupina prostředků. Prostředky z této skupiny pak samozřejmě procesy musí požadovat v jediném kroku.

72 72 FEKT Vysokého učení technického v Brně Uváznutí při přidělování sdílených prostředků bankéřův algoritmus Nejvhodnější by bylo nalézt takovou strategii přidělování prostředků, která by procesy neomezovala tak dlouho, dokud by nehrozilo nebezpečí zablokování procesů. V případě akutního nebezpečí by si je nechala v "zásobě", dokud se situace nezlepší a přidělení prostředku nebude bez nebezpečí. Taková strategie skutečně existuje, říkáme jí bankéřův algoritmus. Mějme bankéře (správce prostředků), který má k dispozici určité částky peněz v různých měnách (počty jednotlivých prostředků). Bankéř půjčuje peníze svým zákazníkům (procesům) a ti mu je po dokončení svých záměrů opět vracejí. Úkolem bankéře je půjčovat peníze takovým způsobem, aby nemohlo dojít k situaci, kdy by banka byla nenávratně insolventní tj. nemohla by plnit požadavky svých zákazníků, a ti by nemohli vracet vypůjčené peníze, protože (pro nedostatek dalších peněz) by nemohli dokončit své záměry. Pro splnění tohoto požadavku potřebuje bankéř předem znát maximální možné požadavky svého zákazníka. Pak může při každé půjčce uvažovat tak, že peníze půjčí jen tehdy, když má zaručeno, že existuje alespoň jedno pořadí dalších požadavků (pořadí může bankéř ovlivnit snadno - řekne žádajícímu, aby přišel později), při kterém všichni zákazníci ukončí své záměry a vrátí peníze. Je-li bankéř inteligentní, mohl by uvažovat například takto: 1) Musím si nejprve rozmyslet, je-li bezpečné půjčit tyto peníze. Budu tedy předpokládat, že jsem je půjčil, a zkusím, stačí-li zbytek ke splnění budoucích požadavků. 2) Musím projít všechny své zákazníky a zjistit, zda je mezi nimi aspoň jeden, který mi bude moci vrátit peníze, tedy takový, jehož budoucí požadavky již nepřesáhnou množství peněz, které mi ještě zbývá. Pokud by snad žádný takový zákazník neexistoval, jistě peníze nepůjčím. 3) Pokud někdo takový existuje, představím si, že mi již peníze vrátil. Pak obdobným způsobem zjistím, bude-li mi moci vrátit peníze některý z dalších zákazníků. Kdyby tomu tak nebylo, peníze samozřejmě také nepůjčím. 4) Úvahu bodu 3. budu opakovat tak dlouho, dokud nezjistím, že peníze půjčit nemohu nebo dokud neprojdu všechny zákazníky. V druhém případě je vše v pořádku a peníze mohu doopravdy půjčit. Stručně lze algoritmus bankéře shrnout do: Za bezpečný stav lze považovat stav, kdy nedošlo k uváznutí a existuje takové alokační pořadí, které zaručuje, že každý proces bude postupně uspokojen a skončí. Bankéřův algoritmus tedy kontroluje, zda přidělení prostředku nevede na nebezpečný stav. Pokud ano, pak je žádost odmítnuta, pokud ne, prostředek je přidělen. Nevýhodou tohoto systému je, že proces musí dopředu vědět, které prostředky bude během svého života potřebovat (maximální možné požadavky) Uváznutí při přidělování sdílených prostředků detekce a metody odstranění uváznutí při přidělování prostředků Ne vždy je proces žádající o prostředek uspokojen. Tehdy, je žádající proces pozastaven nad semaforem a čeká na chvíli, kdy bude jeho požadavek splnitelný. Nebezpečí zablokování se stává realitou. Čelit zablokování lze následujícími způsoby:

73 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 73 Prevence procesy se naprogramují tak, aby zmizely nebezpečné oblasti. Např. tak, že prostředky jsou přidělovány vždy v závazném pořadí - tzv. hierarchické přidělování prostředků nebo je přidělujeme staticky, viz výše. Vyhýbání tato skupina metod spočívá v řízení postupové cesty procesů tak, aby nikdy nevstoupila do nebezpečné oblasti. Testování vstupu do nebezpečné oblasti se provádí vždy při přidělování prostředku. Omezení počtu prostředků, které je možno procesům přidělit. Proces tak nemůže požadovat plný počet prostředků stejného typu, který je obsažen v systému. Indikace neuspokojeného požadavku, kdy proces není v případě nepřidělení prostředku "pozastaven nad semaforem", ale na místo toho mu operační systém vrátí informaci o tom, že se požadavek uspokojit nepodařilo (obvykle pomocí nějakého chybového kódu). Je již věcí programu samotného, jak se s takovou situací vypořádá. Detekce a zotavení princip spočívá v tom, že se připouští (a detekuje) vznik vzájemného blokování procesů a volí se speciální postup spočívající v odebrání prostředků jednomu z procesů a jeho pozdější opětovné spuštění "od nějakého již provedeného bodu". Tato metoda se dá použít jen zřídka. Je založena na tom, že správce prostředků musí udržovat dvě tabulky: o tabulku přidělení, ve které je pro každý prostředek zapsáno, ke kterému procesu momentálně patří, o tabulky čekání, ve kterých je pro každý proces uvedeno, na který prostředek čeká. Použití serveru, kdy se vytvoří jeden speciální systémový proces obsluhující jeden prostředek - tzv. server, který bude zprostředkovávat služby zařízení ostatním procesům. Se serverem mohou komunikovat třeba všechny procesy najednou, není proto zapotřebí nic vyhrazovat a zablokování nehrozí Problém Producent Konzument Zaměřme se nyní na nutnost vzájemného vyloučení procesů nad sdíleným prostředkem (objektem). Příkladem nutnosti použití vzájemného vyloučení procesů může být i přenos zprávy přes sdílenou oblast paměti. Tu si lze představit jako sdílený prostředek, který používají procesy Producent a Konzument, přičemž proces Producent do ní data zasílá a proces Konzument data odebírá. Situace je ilustrována na Obr Nebude-li přístup obou procesů ke sdílené oblasti žádným způsobem koordinován, může dojít k následujícím situacím: 1) Jestliže zápis do sdílené oblasti paměti skončil dříve, než bylo zahájeno čtení, pak budou získána správná a aktuální data, tedy všechno proběhlo tak jak mělo. 2) Jestliže čtení dat ze sdílené oblasti paměti je ukončeno dříve, než je zahájen jejich zápis (přepis novými daty), je získán předchozí zápis dat. 3) Jestliže čtení dat ze sdílené oblasti probíhá současně se zápisem dat (pokud je to vůbec možné), tj. nad sdílenou oblastí pracují oba procesy, je výsledek značně nejistý. 4) Jestliže jsou další data zapisována do sdílené oblasti paměti v situaci, kdy proces konzument dosud předcházející data nepřečetl, pak dojde k jejich ztrátě.

74 74 FEKT Vysokého učení technického v Brně Z 1) až 4) je zřejmé, že pouze situace v bodu 1) přináší správný výsledek, výsledky v ostatních případech jsou chybné a nežádoucí. Proto je vhodné zabezpečit takovou synchronizaci, aby proces Producent mohl zapsat data pouze do prázdné sdílené oblasti a proces Konzument mohl číst jen ze zaplněné sdílené oblasti. Je nezbytné použít takové prostředky, které zajistí synchronizaci procesů při práci nad sdílenou oblastí paměti. Tento případ musí platit nejen pro sdílenou oblast paměti, ale i pro jiné typy sdílených prostředků, než je sdílená oblast, která může být představována např. globální proměnnou. Proces Producent Proces Konzument Sdílená oblast vlož (X); odeber (X); Obr. 5-16: Grafické znázornění problému Producent Konzument Kritéria vzájemného vyloučení procesů Kritéria, která musí splňovat korektní řešení problému vzájemného vyloučení prostředků požadovaných n-procesy, jsou následující: 1. Prostředek může být v daném okamžiku užíván pouze jedním procesem. Proces, který začal používat sdílený prostředek, musí mít i výhradní právo dokončit svoji činnost bez přerušení jinou úlohou (nemohou být zbaveni prostředků zvenčí). 2. Jestliže je prostředek žádán současně několika procesy, musí být poskytnut jednomu z nich v konečném čase (předpokládá se výlučný přístup). 3. Jestliže proces prostředek získá, musí jej v konečné době opět uvolnit. Žádné jiné předpoklady o relativních rychlostech neděláme. V době, kdy neužívají procesy prostředek, měly by být na konečnou dobu zastaveny (viz bod 4.). 4. Proces, který čeká na získání prostředku či dat, nesmí spotřebovávat čas procesoru. V tomto případě, pokud by mělo běžet na jednom procesoru více procesů, by ostatní procesy nemohly být spuštěny, a jedna z výše uvedených podmínek by nebyla splněna v konečné době. Došlo by tak k uváznutí.

75 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 75 Podmínka konečné doby je velmi důležitá, neboť kdyby nebyla použita, mohlo by dojít k uváznutí celého systému, i když nastavení jednoho procesu neovlivní přímo pokračování druhého procesu. Ale tento proces bude čekat na zprávu od uváznutého procesu a tím uvázne též Stavový znak (blokovací proměnná) Nejjednodušší možností (ale bohužel ne plně splňující podmínky vzájemného vyloučení procesů), jak dosáhnout výše uvedeného způsobu sdílení prostředků, je tzv. stavový znak. Stavový znak lze chápat tak, že sdílenému prostředku je vyčleněn informační "bajt", jehož hodnota určuje stav "obsazený" nebo "volný". Pokud má tento "bajt" charakter proměnné z vyššího programovacího jazyka (např. C++), pak hovoříme o blokovací proměnné. Např. použití stavového znaku nebo blokovací proměnné s hodnotou true má význam, že proces může dále pokračovat v činnosti, s hodnotou false má význam, že proces musí čekat na změnu booleovské proměnné. Tento způsob lze použít s výhodou při synchronizaci mezi hlavním programem a obsluhou přerušení. Tehdy hlavní program neustále testuje stavový znak, který může být změněn pouze obsluhou přerušení, která takto signalizuje svůj stav či předává data hlavnímu programu. Pro tento případ synchronizace je třeba používat mechanismus "uzamknutí sběrnice" v případě víceprocesorového systému, neboť zde hrozí nebezpečí, že dva procesy mohou současně provést test na hodnotu jedné stavové proměnné a v případě, že oba zjistí, že má hodnotu true, oba dva ji přepíší. Nevýhodou této metody je nehospodárný mechanismus v tom smyslu, že proces čekající na uvolnění sdíleného prostředku se pohybuje v aktivním cyklu (není ve stavu nečinnosti) Konstrukce semaforu Sdílený prostředek (společnou paměť) si lze představit jako společnou booleovskou proměnnou, která indikuje, je-li v daném okamžiku požadovaný zdroj volný nebo obsazený. Každý proces, který má o sdílený prostředek zájem, prochází cyklem, v němž sdílený prostředek nejdříve obsadí, poté použije a nakonec jej uvolní. Před obsazením prostředku musí testovat, zda je prostředek volný. V případě, že tomu tak není, čeká proces na jeho uvolnění. Vraťme se k problému Producent Konzument popisovaném v kap V procesu Producent vzniknou data (X) a proces má zájem je předat procesu Konzument procedurou "vlož(x)", jak bylo uvedeno na Obr Tento problém můžeme doplnit o konstrukci semaforu, jak je uvedeno na Obr

76 76 FEKT Vysokého učení technického v Brně Proces Producent S Proces Konzument (obsazený) S (volný) S=obsazený; vlož (X); S=volný; Sdílená oblast (obsazený) S (volný) S=obsazený; odeber (X); S=volný; Obr. 5-17: Problém Producent Konzument doplněný o semafor Producent musí nejprve zjistit, zda oblast sdílené paměti představující systémový prostředek je volná. To je provedeno testováním společné booleovské proměnné (S). Má-li proměnná S hodnotu volný, provede proces její obsazení (nastaví hodnotu proměnné S = obsazený) a dále pracuje se systémovým prostředkem, tj. sdílenou oblastí paměti (procedura vlož(x)). Po zápisu všech dat, pak změní hodnotu proměnné zpět na S = volný. Obdobně se chová i proces Konzument, s tím rozdílem, že poté co nastaví booleovskou proměnnou S na obsazený, data ze sdílené oblasti paměti čte. Protože producent není závislý na jiných procesech, může sdílenou zprávu vytvořit v době, kdy není konzument schopen tuto zprávu odebrat. Tento způsob synchronizace prostředků umožňuje zajistit sice vzájemně výlučný přístup ke sdílenému prostředku (v našem případě ke sdílené oblasti paměti), ale neřeší správnost výměny zpráv (tj. byla-li čtena stejná zpráva nebo dosud nepřečtená zpráva byla přepsána novou). Zobecníme-li výše uvedená pravidla, pak konstrukce semaforu zajišťuje výlučný přístup více procesů ke sdíleným prostředkům. Přitom musí mít schopnost převést procesy žádající sdílený prostředek do fronty čekajících nad semaforem v případě, že sdílený prostředek je již obsazen jiným procesem (proces nemusí aktivně čekat nad proměnnou "S" a může být realizován na jednom procesoru). Existuje-li tato fronta čekajících procesů nad semaforem a dojde-li k uvolnění prostředku, pak je provedena nad semaforem operace, která převede dle mechanismu fronty její první proces ze stavu čekající na prostředky do stavu připraven (příp. poté do stavu aktivní). Neexistuje-li proces ve frontě, je převeden semafor do stavu indikujícího volný prostředek. Fronta procesů může mít různou charakteristiku rozvrhování procesů, kterou je zpravidla metoda FIFO (First In First Out) nebo fronta je odbavována dle priority procesů (PQ = Priority Queuing).

77 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 77 Takto definovaný semafor nazýváme binárním semaforem, protože má dva stavy: může být buď uzavřen, nebo otevřen. Vlastní semafor je tvořen strukturou se dvěma položkami: Booleovskou proměnnou realizující vlastní semafor (signalizuje volný a obsazený), Frontou, do které se řadí procesy čekající na sdílený prostředek Kritické oblasti (sekce) Každému sdílenému prostředku (oblast paměti, proměnné, V/V zařízení) může být přidělena kritická oblast (region), tj. posloupnost příkazů zprostředkujících přístup k tomuto sdílenému prostředku. Kritická oblast zakazuje současný vstup dvou procesů k jisté části programu nebo k jistým datovým objektům (vzájemně výlučný přístup). Oproti semaforům a událostem je tak zvýšena zabezpečenost programu, neboť je zkrácen jeho zápis, protože kritická oblast sama uzavírá příslušnou posloupnost příkazů. Jejich nevýhodou je nedostatečná pružnost. Kritické oblasti umožňují paralelním procesům vyměňovat si údaje pomocí sdílených proměnných nebo používat stejný program pro různé úkony ve výpočetním systému. Zabraňují následujícím typickým chybám, které mohou snadno vzniknout při použití semaforu: 1. Vstup do kritické sekce bez předchozího volání uzavírací procedury prostředku. Z toho by vyplývalo, že přístup ke sdíleným datům mohou mít současně dva nebo dokonce více procesů, což může vést k narušení konzistence dat. 2. Vynechání příkazu uvolnění prostředku při programování, což způsobí uváznutí ostatních procesů prostředek zůstane blokován. 3. Ve složitých a rozsáhlých programech se snadno zapomene semafor vůbec použít. Při použití kritické oblasti smí pracovat současně pouze jeden proces. Tak se zabrání konfliktním situacím (např., že jeden proces v oblasti data čte a druhý je při tom mění). Toto "zabránění" se dělá pro jistotu, neboť současná práce dvou procesů ve stejné oblasti programu nemusí nutně vést k poškození sdílených dat. Pouze k němu vést může. Vstup do kritické oblasti si lze představit tak, že je řízen semaforem (událostí), a proto i pravidla vstupu a výstupu do a z kritické oblasti jsou podobné. Je-li uvnitř kritické oblasti nějaký proces, nesmí do ní jiný proces vstoupit. Kritické oblasti sdružené se semaforem Pro tento typ kritických sekcí musí platit: 1. Jestliže chce proces vstoupit do kritické oblasti, bude mu to umožněno v konečném čase a to buď přímým vstupem, v případě, že není v oblasti žádný proces. Je-li nějaký proces obsažen, pak je vstup blokován. 2. Nanejvýš jeden proces může být v daném okamžiku v kritické oblasti. 3. Proces zůstává v kritické oblasti konečnou dobu, po jejím opuštění závisí na mechanismu fronty (FIFO, LIFO, ), který proces do oblasti vstoupí. Podmínka konečné doby je nutná, aby nedošlo k uváznutí systému.

78 78 FEKT Vysokého učení technického v Brně V případě, že bychom chtěli provést výměnu zprávy pomocí vnitřního mechanismu kritické oblasti, nebudeme mít zaručenu správnost předané hodnoty proměnné, protože je sice známo, že je oblast obsazena, ale o tom, zda byla změněna hodnota proměnné, není známo nic. Z tohoto hlediska je mechanismus kritické oblasti při použití pro výměnu zpráv neúplný. V některých programovacích jazycích je tento mechanismus vytvořen za použití monitorů (viz dále) Monitory Monitory představují vyšší techniku určenou pro zabezpečení výlučné správy prostředků a spojují datovou strukturu s dovolenými operacemi nad ní (poprvé zavedeno v roce 1973 jazyk CONCURENT PASCAL). Monitor je modul, v němž jsou sdílená data spojena s množinou procedur určujících další operace, které je možné nad daty provádět. Poněvadž však monitory nenabízejí další prostředky pro synchronizaci procesů, doplňují se mechanismem událostí. Mechanismus modulů Konstrukci programů lze logicky rozložit na dvě části: specifikaci dat a specifikaci akcí. Pro rozsáhlé programy je toto členění nedostačující, a to hned z několika důvodů: Nerespektuje dostatečně existenci jednotlivých logických jednotek, Vyžaduje, aby statické proměnné byly staticky umístěny v paměti po celou dobu běhu programu v paměti, V každém okamžiku jsou datové objekty dostupné a mají stejnou oblast viditelnosti, apod. Tyto problémy jsou řešeny zavedením takových programových konstrukcí (jednotek), které umožňují soustředit do jednoho celku specifikace určitých objektů a specifikovat i operace nad nimi tak, aby bylo možno přístup k nim z vnějšího okolí přesně stanovit a řídit. Taková jednotka se nazývá modul (module). Modul obsahuje dvě části: specifikační část obsahující specifikaci rozhraní, tj. jména, která jsou z okolí přístupná, implementační část (privátní) - zvnějšku nepřístupná. Konstrukci modulu lze přirovnat k ohradě vytvořené kolem objektů. Pro spojení těchto objektů s vnějším okolím za ohradou slouží definované rozhraní. Je samozřejmé, že z vnějšku jsou viditelné pouze ty objekty, které jsou dostupné přes toto rozhraní. Konstrukce modulu umožňuje realizaci programů s vysokou mírou zabezpečenosti. Modul zajišťuje konzistenci objektů a chrání jejich vnitřní strukturu tím, že jsou vnějšímu okolí neviditelné, a tedy nepřístupné a nemohou být modifikovány - s výjimkou použití specifikovaných (povolených) operací. Jak již bylo uvedeno, modul se skládá ze specifikační části a implementační části. Obecně specifikační část obsahuje specifikaci rozhraní tvořenou seznamy typu: Define (definovat), kde jsou uvedeny ty objekty, které jsou definovány v modulu a jsou přístupné z okolí modulu nazývají se exportované objekty,

79 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 79 Use (použít), kde jsou uvedeny ty objekty, které jsou deklarované v okolí modulu, ale jsou přístupné i uvnitř modulu nazývají se importované objekty, Pervasive (pronikání, prostupování mezi úrovněmi). Užije se tehdy, když chceme, aby data byla viditelná v celém systému. To nemusí být možné tehdy, existuje-li modul v modulu a data exportovaná z vnitřního modulu by nebyla viditelná mimo vnější modul, ve kterém se nachází exportující modul. Pozn.: Některé jazyky neobsahují vlastnosti typu use a pervasive. Obr ilustruje, jak může být poskládán složitější systém, který sestává z více modulů existujících na více úrovních. Jednotlivé moduly mají potřebu sdílet proměnné, k čemuž jsou použity typy define, use i typ pervasive. MODUL A MODUL D define use define private MODUL B MODUL C use Int A; define Int A pervasive; define Int B; define procedure define Int C; use Int C; private tělo modulu... private tělo modulu... private tělo modulu Obr. 5-18: Rozložení systému na moduly, použití mechanizmů define, use a pervasive Mechanismus monitoru Syntakticky je struktura monitoru stejná jako struktura modulu. Jsou zde uvedeny deklarace dat, deklarace procedur pro přístup k těmto datům a tělo, jehož příkazy slouží k inicializaci dat a vykonají se při zpracování deklarace monitoru, tedy ještě před prvním voláním některé z monitorových procedur. Ukažme si nyní příklad definice monitoru, jež má usnadnit a dále více zabezpečit řešení již zmiňovaného problému Producent Konzument. Monitor POUŽITÍ_VYR_PAMĚTI (Obr. 5-19) obsahuje nejprve deklaraci proměnné B, hodnot PRÁZDNÁ, PLNÁ, kterých nabývá proměnná SIGNÁL nad pozicí E. Nad ní se vytváří fronta čekajících procesů. Monitor dále obsahuje dvě procedury PŘEDEJ a PŘIJMI. Proces producent předává data do vyrovnávací paměti pomocí volání procedury monitoru PŘEDEJ. Obdobně proces konzument odebírá data z vyrovnávací paměti pomocí volání procedury PŘIJMI. Monitor tak plně přebírá "odpovědnost za všechny přístupy ke sdílené paměti B. Obsahuje též tělo monitoru pro jeho inicializaci.

80 80 FEKT Vysokého učení technického v Brně K zajištění synchronizace uvnitř monitoru je použito mechanismu signálů. Jestliže určitý proces začal vykonávat proceduru monitoru a v rámci této procedury došlo ke zpracování příkazu čekání na signál, udělá se výjimka z pravidla o vzájemném vyloučení a do monitoru smí vstoupit jiný proces. Čekající proces může být znovu aktivován, pouze když jiný proces vstoupí do monitoru a vyšle signál, na který čeká. Bez dalších omezení by však potom byly v monitoru dva aktivní procesy; aby se tomu zabránilo, a zůstalo v platnosti pravidlo o vzájemném vyloučení, doplňuje se další požadavek: aby operace SEND byla poslední provedenou operací procedury monitoru. monitor POUŽITÍ_VYR_PAMETI; var B : VYR_PAM; PLNÁ, PRÁZDNÁ : BOOLEAN; // hodnoty binární proměnné nad událostí E E : EVENT; // deklarace jména pozice události procedure entry PŘEDEJ (in X:DATA); // definice první procedury monitoru begin if PLNÁ // test, zda je vyrovnávací paměť prázdná then WAIT (E) end if; // není-li čekej na vyprázdnění VLOŽ (X); // uložení dat oblasti vyrovnávací paměti SEND (E) // událost značící uvolnění vyrovnávací paměti end; // konec definice procedury PŘEDEJ procedure entry PŘIJMI (out X:DATA); // definice procedury monitoru PŘIJMI begin if PRÁZDNÁ // test na možnost odebrání dat z vyrovnávací paměti then WAIT (E) end if; // není-li možno, čekej na její naplnění ODEBER (X); // přečti data z vyrovnávací paměti SEND (E) // událost značící uvolnění vyrovnávací paměti end; begin INICIALIZUJ (B); SEND (E) end; // začátek těla monitoru // nastavení počáteční hodnoty vyrovnávací paměti Obr. 5-19: Příklad definice monitoru Ukažme si dále na Obr jak se zjednoduší definice komunikačních procesů, budeli využito konstrukce monitoru. Navíc díky použití definice monitoru POUŽITÍ_VYR_PAMĚTI je řešení problému Producent Konzument vždy korektní. Protože monitor poskytuje modulární strukturu, kdy přístup ke sdíleným datům je povolen pouze prostřednictvím procedur, má jeho použití značné výhody. Monitor lze totiž vytvořit a odladit samostatně, nezávisle na procesech, které jej užívají. Je-li odladěný monitor zaveden do systému, je celistvost jím chráněných dat zaručena: operace monitoru nemohou být totiž narušeny ani v případě, že v systému je proces obsahující chybu. Přes uvedené výhodné vlastnosti má koncepce monitoru i dva podstatné nedostatky Proces vystupující z monitoru může aktivovat nanejvýš jeden další proces. Toto pravidlo je nutné pro zachování vzájemného vyloučení, avšak v některých aplikacích způsobuje obtíže. Například v případě, kdy je nutno synchronizovat několik procesů pomocí jednoho koordinačního. Toho lze dosáhnout obecnějším užitím událostí.

81 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 81 Monitor A může teoreticky volat procedury monitoru B, což může způsobit potíže s řetězovým voláním monitorů a zejména výrazně zvyšuje nebezpečí uváznutí. Proto se nejčastěji tento problém řeší tím, že řetězové volání monitorů je zakázáno. proces PRODUCENT var X : DATA; begin. VZNIK_DAT (X); POUŤITÍ_VYR_PAMĚTI. PŘEDEJ (X);. end; // použití procedury monitoru proces KONZUMENT var X : DATA; begin.. POUŽITÍ_VYR_PAMĚTI. PŘIJMI (X); ZPRACUJ (X);.. end; // použití procedury monitoru Obr. 5-20: Použití monitoru uvnitř procesů Rendez-vous Komunikace rendez-vous je synchronní způsob předávání zpráv mezi procesy. Je založena na myšlence, že výměnu dat mezi procesy a jejich synchronizaci není možné oddělovat. Jestliže si proces A přeje předat data procesu B, pak oba procesy musí vyjádřit ochotu ke komunikaci. Tj. vysílací proces A je pozdržen, dokud není přijímací proces B schopen zprávu přijmout. A naopak, přijímací proces je pozdržen, dokud není schopen vysílací proces předat zprávu. Jakmile dojde k předání dat, rozběhnou se opět oba procesy nezávisle. Data jsou předána bez použití vyrovnávací paměti. Tento způsob synchronizace nazýváme rendez-vous. Na Obr je zaznačena výše popsaná metoda předávání informací mezi procesy A a B. Když chce proces A poslat zprávu Z procesu B, používá pro výměnu oblast paměti I. Odesílatel A čeká, dokud B není připraven. Když je B připraven, A je aktivován a předá zprávu procesu B přes oblast I. Naopak, jestliže B je připraven přijmout zprávu přes I a proces A nečeká, pak B čeká na odesílatele A.

82 82 FEKT Vysokého učení technického v Brně Proces A Proces B S 1 A S 2 A S 1 B S 2 B S 3 A S 4 A zpráva Z objekt I S 5 A S 6 A S 3 B S 4 B Vyrovnávací paměti Obr. 5-21: Komunikace obecným rendez-vous Při řešení problému Producent Konzument byl často užit pojem vyrovnávací paměti, tato oblast však nebyla blíže specifikována. Obecně mohou vznikat zprávy (u Producenta) rychleji, než je stačí Konzument v dané chvíli spotřebovávat (zpracovávat). Aby nedocházelo k vzájemnému blokování procesů Producent Konzument v případě, kdy je vznik zpráv rychlejší než jejich spotřeba, musí mít Producent k dispozici více sdílených prostorů a Konzumentovi je předávat po jejich naplnění. Těmto sdíleným prostorům se říká vyrovnávací paměti. A naopak, v situaci, kdy se pokouší Konzument převzít neexistující zprávu (schránka je prázdná), je pozdržen. Pro realizaci vyrovnávacích pamětí se používá pole zpráv stejného typu. Fronta, podle které jsou zprávy řazeny do vyrovnávací paměti, může být definována více způsoby, obvykle se však jedná o typ FIFO (First In First Out). Základní požadavky na vyrovnávací paměti jsou: Zprávy zaslané do vyrovnávací paměti nesmějí být ztraceny a měly by být předány konzumentovi dle typu fronty (musí být dodrženo pořadí). Počet zpráv odeslaných do vyrovnávací paměti, které ještě nebyly vybrány, nesmí překročit kapacitu vyrovnávací paměti. Proto rozsah vyrovnávací pamětí se volí tak, aby byl dostatečný pro všechny různé případy, které mohou nastat. V případě, že je přesto naplněna kapacita vyrovnávací paměti, musí být proces Producent pozdržen do doby, dokud není alespoň jedna zpráva z vyrovnávací paměti odebrána. Počet přijatých zpráv nesmí převýšit počet odeslaných zpráv. V případě, že nastane tato situace, je proces Konzument pozdržen do doby, dokud není alespoň jedna zpráva zaslána do vyrovnávací paměti.

83 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 83 Vyrovnávací paměť (buffer) je jistá oblast v paměti, do které je možné ukládat zprávy; jedná se tedy o strukturovaný datový typ. Lze obvykle zadat nejvyšší možný počet zpráv čekajících na této pozici, přičemž je běžné, že vyrovnávací paměť obsahuje zprávy jednoho datového typu. Někdy se pozici vyrovnávací paměti říká schránka. 5.5 Návrh vlastního komunikačního protokolu V praxi mohou nastat situace, kdy potřebujeme navrhnout vlastní komunikační protokol. Příčinou tohoto stavu mohou být nestandardní potřeby naší aplikace nebo specifické podmínky našeho prostředí, firemní politika, apod. Návrhu vlastního komunikačního protokolu by měla předcházet hlubší analýza konkrétních potřeb tak, aby byly promyšleny pokud možno všechny možné situace. Obecně by návrh měl probíhat dle postupu uvedeného v kap Při návrhu jsou důležité zejména tyto body, které jsou v následujícím přehledu rozděleny dle příslušnosti k hlavním částem vývoje celého systému. Pozornost je věnována zejména prvním dvěma oblastem a výčet není samozřejmě zcela úplný. Definice problému o Cíle, které chceme dosáhnout, tj. jakým účelům by měl protokol sloužit. o Vrstva modelu ISO/OSI, v které bude protokol pracovat. Nejčastěji se v praxi bude jednat o aplikační protokol, což budeme předpokládat dále. Obecně však může být situace samozřejmě složitější, můžeme pracovat i na více vrstvách. Specifikace chování o Jaké bude základní schéma komunikace (klient-server, klient-klient), kolik bude řádově komunikujících stanic. o Jaké základní typy zpráv budeme potřebovat k dosažení cílů a jaká bude struktura těchto zpráv (počet a význam jednotlivých polí záhlaví, datová část, délka zpráv, apod). o Jaké bude základní schéma chování jednotlivých stran komunikace, počáteční a koncové stavy. o Jaké bude standardní schéma výměny zpráv mezi komunikujícími stranami v jednotlivých úkonech. V tomto kroku je velmi důležité naznačit si toto schéma graficky. o Zpřesnění chování komunikujících stran, s ohledem na vyměňované zprávy, zpravidla pomocí jednoduchých stavových automatů. o Který transportní protokol bude využit v kterých situacích, případně zda bude využíván mimo nejběžnějšího, tj. unicastového přenosu dat i multicastový nebo dokonce broadcastový přenos zpráv. o Zda vyžadujeme šifrování přenosu některých nebo všech zpráv, případně na jaké vrstvě komunikace chceme šifrovat. o Jaké mohou nastat nestandardní situace v reálných podmínkách a jakým způsobem nebo případně zprávami mají být ošetřeny. V tomto ohledu je

84 84 FEKT Vysokého učení technického v Brně Implementace třeba doplnit schéma výměny zpráv, typy zpráv a také stavové automaty, popisující chování komunikujících stran. o V neposlední řadě musíme také uvážit programovací jazyk, případně platformu, která bude využita ke kódování celého systému. Výroba, nasazení, využívání systému o V této fázi dochází k reálnému nasazení protokolu do místa určení a následně k standardnímu životu systému spočívajícímu v jeho udržování, aktualizacích, opravách apod.

85 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 85 6 Úvod do kryptografie 6.1 Přístupy k šifrování Šifrování (kryptografie) představuje nauku o metodách utajení obsahu přenášené (z hlediska komunikačních technik) zprávy, a to transformací do podoby, která je čitelná pouze vlastníkovi speciální znalosti 20. Šifrování může sloužit ale i k autentizaci nebo jiným účelům. Opakem šifrování je dešifrování. Existují dva základní způsoby šifrovaní, viz dále, obecné blokové schéma kryptografického systému je možné nalézt na Obr Z obrázku je patrné, že v tomto případě předpokládáme, že útočník má přístup pouze do přenosové části, tj. ke komunikačnímu kanálu a proto musíme před vstupem do kanálu zprávu šifrovat a následně na straně příjemce po přijetí dešifrovat. Pozn.: tento systém zabezpečení však logicky postrádá smysl, je-li útočník schopen přístupu přímo k zařízení odesílatele nebo příjemce, kde v tomto případě předpokládáme zprávu v nešifrované podobě. Útočník Odposlech nebo modifikace Odesílatel zprávy Šifrování zprávy Přenosový kanál Dešifrování zprávy Příjemce zprávy Zdroj klíčů Obr. 6-1: Blokové schéma kryptografického systému 6.2 Symetrické šifrování Pro symetrické metody šifrování platí, že obě komunikující strany sdílejí stejný (nebo navzájem snadno odvoditelný) soukromý klíč, který se používá jak pro šifrování, tak pro dešifrování. Klíče jsou obvykle krátké (vzhledem k délce přenášených dat), aby byl algoritmický výpočet rychlý a i relativně jednoduchý. V případě symetrického šifrování je zřejmým problémem bezpečná distribuce (de)šifrovacích klíčů, které je navíc vhodné poměrně často měnit. V rámci symetrického šifrování existují dvě základní metody a to proudové (stream) šifrování a blokové (block) šifrování. Oba tyto principy vysvětlují následující obrázky, Obr. 6-2a) a Obr. 6-2b). Rozdílnost těchto systémů spočívá zejména ve způsobu zpracování právě šifrované zprávy. U proudové šifry je zpráva jednoduše po bitech operací XOR (exlusive OR) sčítána s jednotlivými bity klíče, které vznikají v generátoru klíče. Stavba bloku generujícího klíč není triviální, tento blok musí být schopen vytvořit kvalitní pseudonáhodnou posloupnost, 20 Pro ujasnění pojmů ještě uveďme, že celá vědní disciplína se nazývá kryptologie a zahrnuje jak kryptografii, které se věnuje text této kapitoly, tak kryptoanalýzu, která se věnuje prolamování zašifrovaných zpráv různými metodami, samozřejmě bez znalosti použitého šifrovacího klíče.

86 86 FEKT Vysokého učení technického v Brně a aby vše správně fungovalo, stejný a synchronně běžící generátor musí běžet i na straně příjemce. Podstatnou roli zde hraje tzv. inicializační vektor, který se podílí na startu tohoto generátoru. Dešifrování se provádí stejným způsobem, zašifrované bity se operací XOR sčítají s bity klíče. Zpráva Bit zprávy Generátor klíče Zpráva Blok zprávy Bit klíče Šifrátor Klíč Zašifrovaný bit zprávy Zašifrovaný blok zprávy a) b) Obr. 6-2: Symetrické šifrování a) proudový režim b) blokový režim U blokové šifry je situace odlišná. Zpráva se zpracovává po pevně daných blocích, běžné hodnoty jsou mocniny dvou, tedy typicky 64, 128, 256 či dokonce 512. Klíč je zde pevně dán a znám oběma stranám komunikace. Jádro algoritmu je obsaženo v tzv. šifrátoru, kde se provádí s bloky zprávy určité předem dané operace a to zpravidla ve více na sebe navazujících cyklech. Popis algoritmu je většinou veřejný, bez znalosti klíče však lze jen velmi obtížně šifru prolomit. Analogicky k bloku šifrátoru musí na straně příjemce existovat blok dešifrátoru, který provádí na základě stejného klíče inverzní operaci, tj. dešifrování. 6.3 Asymetrické šifrování Asymetrická kryptografie pracuje s dvěma druhy klíčů, zpráva se šifruje jedním klíčem a dešifruje druhým, přičemž oba tyto klíče tvoří jedinečný pár vzájemně korespondujících klíčů. Jeden z klíčů je pak veřejně dostupný a druhý přísně soukromý. Základní vlastností tohoto páru klíčů je, že nelze ze znalosti veřejného klíče odvodit privátní klíč. Použití asymetrické kryptografie lze rozdělit na dvě části: 1) Jestliže chceme někomu odeslat zprávu, musíme znát jeho veřejný klíč, jímž zprávu zašifrujeme, a tuto zprávu pak může dešifrovat pouze majitel privátního klíče, který koresponduje s veřejným klíčem, jenž byl použit při šifrování. Situaci ilustruje Obr ) Dalším použitím asymetrické kryptografie je tzv. digitální podpis. Používá se ke stejnému účelu jako klasický podpis, autor podpisu má tedy toto podepisování pod kontrolou (autentičnost) a nemůže tvrdit, že daný dokument nebo zprávu nepodepsal on (neodvolatelnost). Z celkového pohledu je použití klíčů přesně opačné než v případě asymetrického šifrování dat. Privátní klíč se používá k podepsání a veřejný klíč k ověření podpisu. Možná situace je naznačena na Obr V případě samostatného digitálního podpisu není obsah zprávy žádným způsobem šifrován. Každý, kdo má přístup k veřejnému klíči strany A, která zprávu podepsala, si může ověřit, zda je podpis pravý. Číst obsah zprávy může kdokoliv. Z tohoto důvodu lze dva výše uvedené postupy kombinovat, tj. zprávu jak šifrovat, tak podepsat, viz Obr. 6-5.

87 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 87 Strana A Privátní klíč strany A (PK A ) Veřejný klíč strany A (VK A ) Veřejný klíč strany B (VK B ) VK B Zpráva Šifrování zprávy Šifrovaná zpráva Přenosový kanál Zpráva Dešifrování zprávy Šifrovaná zpráva PK B Strana B Privátní klíč strany B (PK B ) Veřejný klíč strany B (VK B ) Veřejný klíč strany A (VK A ) Útočník Obr. 6-3: Šifrování za pomocí asymetrické kryptografie přenos zpráva od strany A k B Strana A Privátní klíč strany A (PK A ) Veřejný klíč strany A (VK A ) Veřejný klíč strany B (VK B ) PK A Zpráva Digitální podpis Digitálně podepsaná zpráva Přenosový kanál Zpráva Ověření podpisu Digitálně podepsaná zpráva VK A Strana B Privátní klíč strany B (PK B ) Veřejný klíč strany B (VK B ) Veřejný klíč strany A (VK A ) Útočník Obr. 6-4: Digitální podepsání zprávy od strany A k B, za pomocí asymetrické kryptografie Strana A Privátní klíč strany A (PK A ) Veřejný klíč strany A (VK A ) Veřejný klíč strany B (VK B ) VK B PK A Zpráva Šifrování zprávy Digitální podpis Digitálně podepsaná a šifrovaná zpráva Přenosový kanál Zpráva Dešifrování zprávy Ověření podpisu Digitálně podepsaná a šifrovaná zpráva PK B VK A Strana B Privátní klíč strany B (PK B ) Veřejný klíč strany B (VK B ) Veřejný klíč strany A (VK A ) Útočník Obr. 6-5: Schéma uskutečnění přenosu zašifrované a digitálně podepsané zprávy Popis fungování režimu dle Obr. 6-5 Máme dvě strany, které spolu chtějí bezpečně komunikovat, stranu A a stranu B. Každá z těchto stran disponuje vlastním párem klíčů (privátní a veřejný) a zároveň je schopna si věrohodně opatřit veřejný klíč protistrany. Strana A chce poslat bezpečně zprávu straně B a obě strany si chtějí být zároveň jisté, že opravdu komunikují s tím, s kým chtějí. Tyto věci lze provést ve dvou krocích a to šifrováním zprávy pomocí veřejného klíče strany B a následného podepsání zprávy pomocí vlastního privátního klíče (strany A). Takto zašifrovaná a podepsaná zpráva je vyslána přenosovým kanálem. Strana B nejdříve

88 88 FEKT Vysokého učení technického v Brně u obdržené zprávy ověří digitální podpis za pomocí znalosti veřejného klíče strany A. Následně je strana B schopna zprávu dešifrovat svým privátním klíčem a přenos informace je hotov. Analogicky by se postupovalo v případě přenosu zprávy opačným směrem. Útočník, u kterého předpokládáme, že má přístup k přenosovému kanálu a má rovněž možnost získat veřejný klíč strany A (případně B), je pouze schopen ověřit původce zprávy, tj. že pochází od strany A, ale již není schopen zprávu dešifrovat, jelikož nedisponuje privátním klíčem strany B a z veřejného klíče nelze privátní klíč odvodit. Z toho vyplývá, že je nutné privátní klíč vždy dobře chránit před kompromitací. Pozn.: Tento příklad je oproti skutečnému fungování mírně zjednodušen, avšak dostatečně osvětluje základní princip. Případné zájemce o bližší seznámení odkazujeme na literaturu. 6.4 Vybrané šifrovací a hash algoritmy DES Americká norma šifrování dat, DES (Data Encryption Standard), je z konce sedmdesátých let. Je to symetrická šifrovací metoda s délkou klíče 56 bitů, která pracuje v blokovém režimu s délkou jednotky 64 bitů. Délka klíče nám dává přibližně 7, možných klíčů. Šifra je od roku 1997 považována za prolomenou a v současné době již není její použití doporučováno. Existuje uměle zesílená varianta, tzv. 3DES (Triple DES), kdy se klíč používá trojitě, za cenu značného zpomalení šifrovacího procesu AES AES (Advanced Encryption Standard) byl vytvořen jako nástupce algoritmu DES. AES je založen na tzv. Rijndaelovu algoritmu, zájemce o podrobnosti odkazujeme na literaturu. AES představuje stejně jako DES symetrickou šifrovací metodu, která pracuje v blokovém režimu. Možné délky klíčů jsou 128, 192 a 256 bitů, stejně tak jako délky bloků zpracovávaných dat. Maximální délka klíče, 256 bitů, nám poskytuje obrovské množství možných klíčů, téměř 1, Tento šifrovací algoritmus je v současné době (2014) stále považován za bezpečný a hojně používaný v různých komunikačních systémech a protokolech. Pozn.: Mezi další méně běžné symetrické algoritmy patří Serpent a Blowfish, celkem však šifrovacích algoritmů existují desítky až stovky, více či méně zdařilých Dokonalá (Vernamova) šifra Za dokonalou šifru je považován teoreticky velmi jednoduchý algoritmus symetrické šifry, který je však v praxi téměř nerealizovatelný a proto tedy i nepoužívaný. Lze matematicky dokázat, že tento algoritmus nelze prolomit. Při počítačovém zpracování dat se jedná o prostou operaci XOR zprávy a klíče, přičemž na klíč jsou kladeny tyto požadavky: Klíč musí být zcela náhodný, Klíč musí mít stejnou délku jako zpráva, kterou jim chceme zašifrovat, Klíč můžeme použít pouze jednou, pro každou zprávu musí být unikátní.

89 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 89 Každý z těchto tří požadavků je problematický. Vytvořit zcela náhodnou posloupnost, nikoliv pouze např. pseudonáhodnou je cílem mnoha vědeckých projektů (např. v oblasti kvantové fyziky) a lze říci, že se to daří jen částečně. Aby bylo možné šifrovat a dešifrovat, musí klíč znát obě strany komunikace. Jestliže musí být klíč stejně dlouhý jako zpráva, je obtížné ho bezpečně přenést. Pokud máme k dispozici bezpečný přenosový kanál, kterým by bylo možné přenést celý klíč, je výhodnější ho využít přímo pro přenos zprávy. Nevýhoda vyplývající z toho, že každý klíč lze použít pouze jednou je zřejmá. Musíme mít tedy v zásobě obrovské množství klíčů. Pokud všechny tyto podmínky dodržíme, naše zpráva se stává de facto šumem, který nemůže být útočníkem rozluštěn. Původní Vernamova varianta byla patentována v roce 1917 a byla zamýšlena pro šifrování textových zpráv - znaků abecedy. Spočívá v posunutí každého znaku textu o náhodnou hodnotu v abecedě. Např. ze znaku A se tedy může stát libovolný znak v rozsahu B až Z. Zpráva se tedy stává zcela náhodou a nerozluštitelnou, za předpokladu, že dodržíme stejná pravidla jako ta, která byla uvedena výše, tj. klíč musí být zcela náhodný a jeden klíč musí být vždy použit pouze jednou Diffie-Hellman První mechanizmus (1976) pracující s veřejným klíčem, tedy asymetricky je podle autorů nazýván Diffie-Hellman. Jeho hlavním úkolem v praxi je bezpečná distribuce klíčů, které budou následně použity v rámci některé symetrické šifrovací metody. Jelikož tento algoritmus neprovádí žádnou autentizaci komunikujících stran, je náchylný na útok typu man-in-the-middle. Matematický princip algoritmu je založen na problému složitosti výpočtu diskrétního logaritmu, zájemce odkazujeme na literaturu RSA Zkratka RSA vznikla taktéž z iniciál autorů algoritmu pánové Rivest, Shamir a Adleman a je z roku Algoritmus je založen na složitosti faktorizace (součin prvočísel) velkých celých čísel, zájemce o bližší seznámení opět odkazujeme na literaturu. Mechanizmus je vhodný jak pro podepisování (algoritmus digitálního podpisu), tak i pro šifrování. Vyžaduje značnou délku klíče (1024, 2048 nebo i 4096 bitů), aby bylo možné ho i v současné době považovat za bezpečný (výpočetní výkon superpočítačů totiž od roku 1977 extrémním způsobem vzrostl). Obrovská délka klíče logicky způsobuje relativní pomalost celého algoritmu a je proto vhodný zejména na přenesení klíče pro symetrický algoritmus nebo šifrování krátké zprávy. Přesto se hojně používá např. v elektronické poště, SSL (Secure Socket Layer), při budování virtuálních privátních sítí a digitálním podpisu MD Algoritmus MD (Message Digest) při zpracování zprávy prakticky libovolné délky vyprodukuje jedinečný otisk (hash, fingerprint) v pevné délce, např. 128 bitů. Otisk zprávy tvoří jakýsi šifrovací kontrolní součet, který vzniká pomocí jednosměrné funkce. Jestliže se původní zpráva změní třeba jen v jednom bitu, otisk musí být odlišný (a bude naprosto odlišný díky tzv. lavinovému efektu). Jinak řečeno, musí platit, že dvě různé zprávy nebudou mít nikdy stejný otisk. Algoritmus nevyužívá žádné šifrovací klíče, takže není šifrou, vytvořit otisk libovolné zprávy může kdokoliv. Existuje v několika verzích, nejčastěji používaná je verze 5 (MD5). Pokud některá z výše uvedených podmínek nebude platit, dochází k tzv. kolizi, která znamená nebezpečí pro důvěrnost či integritu dat. Otisky se totiž používají např. ke kontrole, zda ve

90 90 FEKT Vysokého učení technického v Brně zprávě nedošlo během přenosu k záměrným změnám. Algoritmus MD5 již v současné době není považován za příliš bezpečný, jelikož jsou známy postupy, jak kolizí dosáhnout záměrně. Přesto se poměrně hodně tento algoritmus i v současné době používá. Zejména je to v situacích, kde nejsou dostupné novější algoritmy či bezpečnost není tak kritická nebo nalezení kolize, které není nikdy okamžité, nemá efekt na již proběhlou komunikaci SHA Algoritmus SHA (Secure Hash Algorithm) provádí v principu stejnou operaci jako MD, délka vyprodukovaného otisku však byla rozšířena na 160 bitů (ve verzi SHA-1). Metoda jakou se otisk 21 ze zprávy získává je samozřejmě odlišná od MD5. Existují i verze SHA-224, SHA-256, SHA-384, SHA-512, délka produkovaného otisku (hash) je zřejmá z uvedených názvů. Tyto verze jsou často souhrnně označovány jako SHA-2. Algoritmus je považován za výrazně bezpečnější než MD5, verze SHA-2 dosud nebyly nikterak prolomeny (což znamená nalezení kolize metodou výrazně rychlejší než vyzkoušením všech možných kombinací, které je výpočetně extrémně náročné). Algoritmus SHA se používá např. u TLS (Transport Layer Security), PGP (Pretty Good Privacy), SSH (Secure Shell) nebo IPsec (IP security). Pozn.: existuje celá řada dalších hash algoritmů, např.: MD6, RIPEMD (RACE Integrity Primitives Evaluation Message Digest), SHA-3, Tiger a Whirlpool. 21 Otisky zpráv nebo souborů lze vytvářet prostřednictvím speciálního software nebo i online nástrojů, např.

91 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 91 7 Směrovací protokol IS-IS 7.1 Základní fakta o protokolu IS-IS Dynamický směrovací protokol IS-IS (Intermediate System - Intermediate System), dnes již spíše ve variantě integrované IS-IS, je velmi starým směrovacím protokolem z dob OSI sítí, který je nicméně navržen tak, že je možné jej poměrně snadno rozšiřovat o další funkcionalitu, což jej činí velmi dobře použitelným i v současné době a také velmi významným s ohledem na relativní snadnost implementace směrování jak s protokolem IPv4 tak i IPv6 v současných dual-stack TCP/IP sítích. Protokol patří do skupiny interních směrovacích protokolů (IGP = Interior Gateway Protocol), tzn. do protokolů využívaných uvnitř autonomních systémů (v terminologii IS-IS nazývaných doména), viz Obr Z hlediska členění interních protokolů se jedná o zástupce protokolů typu link-state (stav linky), podobného v určitých ohledech s OSPF (Open Shortest Path First), což vede k tomu, že při jeho popisu se často využívá porovnání s protokolem OSPF. Protokol tedy primárně pracuje se stavy jednotlivých linek v dané síti (oblasti). AS2 EIGRP ebgp OSPF AS4 ebgp ebgp IS-IS IS-IS IS-IS AS3 Obr. 7-1: Interní a externí směrovací protokoly z pohledu existence autonomních systémů a zařazení IS-IS protokolu Současné implementace protokolu podporují větší počet síťových protokolů, což je důvod proč se jim říká integrované IS-IS. Protokol je přenášen přímo v L2 rámcích, pro výměnu informací mezi směrovači tedy nevyužívá přímo žádné IP adresy uzlů či podobně. Uvnitř protokolu je pro výpočty hledání optimálních tras využit velmi známý Dijkstrův algoritmus hledání nejkratší cesty, který využívá např. i OSPF či STP (Spanning Tree Protocol).

92 92 FEKT Vysokého učení technického v Brně 7.2 Vybrané vlastnosti protokolu IS-IS IS-IS podporuje či přináší: VLSM (Variable Length Subnet Mask), tj. přenáší i informaci o masce dané sítě, což je významné pro současné IPv4 sítě, libovolnou sumarizaci, autentizaci výměny směrovacích informací, rychlou konvergenci, rozdělení autonomních systémů na menší oblasti (podobně jako OSPF), tj. umožňuje vytvořit v rámci jednoho autonomního systému dvě úrovně směrování (v IS-IS terminologii označované jako level-1, level-2). Level-1 představuje směrování pouze uvnitř dané oblasti, Level-2 pak směrování mezi těmito oblastmi (tj. páteř, neboli backbone). Směrovač pak může být zapojen pouze do level-1 směrování, popřípadě do level-1 i level-2, což názorně demonstruje následující obrázek, kde je zeleně označena páteř dané sítě a modře směrovače, které jsou významné pouze v rámci dané oblasti (kterých by v reálné síti patrně bylo více). Obr. 7-2: Znázornění dvou úrovní směrování i směrovačů v protokolu IS-IS 7.3 Metrika protokolu IS-IS IS-IS pracuje s tzv. metrikou, což je veličina určená k ohodnocení kvality dostupných tras a také k následnému výběru trasy používané, tj. považované aktuálně za optimální. Metrika může být jednoho z následujících druhů: Default výchozí všeobecná metrika, Expense metrika vyjadřuje finanční náklady na použití trasy, Delay metrika vyjadřuje zpoždění dané trasy,

93 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 93 Error metrika reprezentuje chybovost dané trasy. Ne všechny implementace IS-IS podporují všechny typy metriky, např. na směrovačích společnosti Cisco je podporována pouze metrika typu Default., kterou lze však téměř libovolně konfigurovat. 7.4 Pakety protokolu IS-IS Protokol IS-IS využívá čtyři základní druhy paketů: Hello (IIH = IS-IS Hello) posílán periodicky, např. každých 10 sekund, paket je využíván k vytvoření komunikační vazby se sousedními směrovači a následnému udržování sousedství. S paketem souvisí i doba, po kterou je soused považován za dostupného, tzv. timeout, který je zpravidla trojnásobek intervalu hello zprávy, Link-state PDU (LSP) zpráva generovaná každým routerem, s informací o topologii a metrice, tato informace má určitou životnost, což způsobuje fakt, že informace musí být pravidelně (15 min) aktualizovány (udržovány v platnosti), Partial Sequence Number PDU (PSNP) pomocí této zprávy si lze vyžádat nebo potvrdit konkrétní LSP informaci z databáze protokolu, Complete Sequence Number PDU (CSNP) každých 10 sekund se zasílá úplný seznam (nikoliv celá informace) LSP ve vlastní databázi sousedům. 7.5 NSAP (NET) - interní adresy v protokolu IS-IS Protokol IS-IS využívá interně k rozlišení směrovačů (či i jiného zařízení) původní OSI adresy, které se nazývají Network Service Access Point (NSAP). Těchto adres existuje více druhů a mají proměnnou délku od 8 do 20 bajtů, jsou tedy výrazně delší než IPv4 adresy. Poslední bajt této adresy se nazývá NSEL (NSAP Selector) a reprezentuje identifikátor adresované služby. Pokud je tato hodnota rovna 0, říkáme celé adrese NET (Network Entity Title), což je adresa bez specifikace konkrétní služby, kterou využíváme při konfiguraci IS-IS směrovače. Celková struktura NSAP adresy je znázorněna na následujícím obrázku. Adresy se správně čtou a analyzují zprava doleva. IDP DSP AFI IDI Area System ID NSEL Proměnná délka (1 až 13 bajtů) 6 bajtů 1 bajt Obr. 7-3: Struktura NSAP adresy používané v IS-IS Význam zkratek z obrázku: IDP = Inter-Domain Part, DSP = Domain Specific Part, AFI = Authority and Format Identifier, IDI = Initial Domain Identifier, NSEL = NSAP Selector.

94 94 FEKT Vysokého učení technického v Brně Příklad na adresu typu NSAP (NET): V tomto případě je NSEL rovno 0, proto se jedná o adresu typu NET. Zeleně je označeno System ID, které slouží k identifikaci směrovače v rámci IS-IS oblasti nebo lépe celé domény, a které musí unikátní. Červeně označené bajty slouží k odlišení jednotlivých oblastí v rámci IS-IS domény, viz následující kapitola. Modrý bajt pak ve své podstatě značí do určité míry typ celé adresy, kde hodnota 49 znamená privátní typy domény v OSI. Více podrobností k AFI a IDI je nad rámec tohoto textu. 7.6 Oblasti a jejich identifikátory Při popisu adresy v IS-IS jsme narazili i na číslo dané oblasti, které identifikuje skupinu směrovačů tvořících jednu oblast. Pro názornost je rozdělení na oblasti a i konkrétní příklady adres ukázány na následujícím obrázku. Obr. 7-4: Rozdělení na oblasti v rámci IS-IS domény a příklady NET adres konkrétních směrovačů

95 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 95 8 Doplňkové techniky doménového překladu 8.1 Multicast DNS Základní popis protokolu mdns Multicast DNS (mdns) je doplňující technika k běžně využívanému protokolu DNS vyvinutá společností Apple. Protokol byl vytvořen k tomu, aby klienti mohli posílat dotazy obdobné typu DNS pomocí multicastu a bylo možné, že na odpovědi budou schopny se podílet ostatní stanice lokální sítě podporující daný protokol. Protokol tedy přináší z hlediska překladu doménových jmen určitou alternativní metodu lokálního překladu jména na IP adresu. mdns byl vytvořen s cílem snížit intenzitu IP komunikace a také ulehčit autokonfiguraci. mdns se neliší zásadně od běžného DNS, primárně je však určen pouze pro lokální překlad jmen mezi stanicemi v rámci dané sítě či linky. Umožňuje stanicím zvolit si prakticky libovolný DNS název, jako např. MujPocitac.local., který bude využíván pro lokální označování a adresování stanic a umožní tak i bez veřejně platných DNS názvů v globální DNS databázi usnadnění komunikace s využitím těchto lokálních jmenných názvů. mdns využívá většinu základních principů DNS, dokonce dodržuje i formát jeho zpráv. Lze předpokládat, že jakékoliv doménové jméno, které končí.local. je platné pouze v rámci linky (lokální sítě) a tato jména mají význam pouze v této doménové oblasti. To odpovídá IPv4 adresám z rozsahu /16 nebo IPv6 adresám z rozsahu FE80::/10. Všechny dotazy mdns na jména, která končí.local. musí být poslány na multicastovou IPv4 adresu (nebo v IPv6 FF02::FB), cílový UDP port u tohoto protokolu je mdns může být použit i k překladu veřejně platných doménových jmen, avšak pouze v situaci, kdy standardní DNS server není k dispozici. Z pohledu běžné koncové stanice umožňuje mdns zvolit si libovolný jmenný název v rámci oddělené lokální domény.local a tento ohlásit do lokální sítě. Přes tuto jmennou adresu pak může být stanice lokálně dostupná (po provedení překladu na IP adresu) Znaková sada mdns Z historického hlediska mělo DNS velmi omezenou sadu použitelných znaků. Jedná se pouze o 26 písmen, 10 čísel a pomlčku. Pokusy napravit tento problém byly značně omezeny především kvůli starým implementacím DNS. Vlastní specifikace nijak neomezuje sadu znaků a dobrá implementace DNS je schopná zvládnout libovolné 8 bitové znaky bez problémů. Blíže je toto vysvětleno prodiskutováno v RFC 2181 s názvem Clarifications to the DNS Specification, kde je uvedeno, že jména v rámci DNS mohou obsahovat libovolné 8 bitové znaky. Nicméně stará pravidla ARPANETu (RFC 1034) vyžadovala, aby jména obsahovala pouze písmena, čísla a pomlčky. Vzniká a stále se drží proto domněnka, že protokol DNS je v tomto ohledu nedokonalý a jeho implementace nezvládne 8 bitové znaky. Bylo by však přesnější říct, že 8 bitové znaky nezvládne pouze špatná či velmi zastaralá implementace DNS. Multicast DNS je však v tomto ohledu považován za nový protokol, a proto všechna jména musí používat znakovou sadu UTF-8. Pro jména, která používají pouze sadu US-ASCII, tj. písmena, čísla a pomlčku, je kódování UTF-8 stejné, tudíž jsou tyto dvě sady kompletně kompatibilní. Pro znaky, které nejde zobrazit pomocí US-ASCII, se použije

96 96 FEKT Vysokého učení technického v Brně UTF-8. V rámci mdns se nesmí použít žádný jiný způsob kódování. Tento protokol stejně jako běžné DNS nerozlišuje velké a malé písmena Zprávy v protokolu mdns V z dnešního pohledu již zastaralé specifikaci protokolu DNS z roku 1987 (RFC 1035) je vyžadováno, aby DNS zprávy nesené protokolem UDP nebyly na úrovni aplikační vrstvy delší než 512 bajtů. Toto pravidlo však dnes již neplatí a pro zprávy v rámci linky (lokální sítě) ani není potřeba. Zprávy v protokolu mdns mohou teoreticky dosahovat prakticky libovolné velikosti, kterou dovoluje daná technologie, s přihlédnutím k faktu, že může dojít následně k fragmentaci této zprávy do více paketů. Např. u Ethernetu je to u tzv. jumbo paketů 9000 bajtů, včetně IP a UDP záhlaví. Mnohem vhodnější je však udržovat zprávy protokolu, včetně IP a UDP záhlaví ve velikosti do 1500 bajtů. Tato velikost vede zpravidla k optimalizaci potřebného výpočetního výkonu ke zpracování paketů a úspoře procesorového času, popř. základnímu zpracování rámců přímo na síťové kartě Formát záhlaví zpráv mdns V této části textu bude stručně popsán obsah záhlaví zpráv, které používá protokol mdns, resp. několika významných polí. Dále jsou zde zmíněny i určitá specifika, která je potřeba uvážit při případné implementaci tohoto protokolu Pole ID (Query Identifier) Pro mdns je doporučeno, aby přijímalo také nevyžádané zprávy. Týká se to převážně stanic, které se nově spouštějí nebo se znovu připojují na síť. Tyto zprávy mohou obsahovat užitečné informace, které může stanice v pozdějším provozu použít bez nutnosti vysílání nového dotazu. Z toho důvodu by měly všechny implementace mdns zpracovat všechny multicastové zprávy nesoucí odpověď bez ohledu na obsah pole ID. Předpokládá se, že je důležitější znát obsah mdns zprávy, než vědět, která zpráva vyvolala tuto odpověď. Proto by v mdns zprávách žádajících o překlad na IP adresu mělo být ID nastaveno na 0. Naproti tomu v odpovědích na mdns musí být ID nastaveno na 0 a na příjímací straně musí být ID ignorováno. Pozn.: V některých zastaralých implementacích se musely hodnoty ID shodovat. Stejně jako v běžné implementaci protokolu DNS, se i v mdns zprávy ukládají do vyrovnávací paměti pro případné pozdější použití. Zprávy jsou v paměti uloženy po dobu její doby života (TTL), což je hodnota zjišťovaná přímo z přijaté mdns odpovědi Pole QR (Query/Response) Bit Zde platí stejný režim nastavení bitu jako v běžném DNS dotazu a odpovědi. QR bit je při dotazu nastaven na hodnotu 0 a v odpovědi pak na hodnotu Pole OPCODE V odpovědi i v dotazu musí být OPCODE nastaven na 0, neboť mdns podporuje pouze standardní dotazy. Zprávy s jinou hodnotou jsou bez jakéhokoliv upozornění zahozeny.

97 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO Pole AA (Authoritative Answer) Bit V dotazech tento bit musí být nastaven na 0, při příjmu dotazu je však hodnota pole ignorována. V odpovědi pak musí být nastavena hodnota na 1, jinak by to znamenalo, že je zde nějaké jiné místo, kde by se dala získat lepší informace. Hodnota tohoto pole v odpovědi je při příjmu, stejně jako u dotazu, ignorována Porovnání mdns a klasického DNS Běžné unicastové DNS a mdns spolu sdílejí většinu základních nastavení a rozhraní, pojmenování, syntaxi, typy zpráv apod. Jsou zde však některé nutné rozdíly, které si vynutilo zejména použití multicastových zpráv a charakter použítí (určení) protokolu. O mdns platí zejména, že: - Používá multicast, - Používá UDP port 5353 namísto 53, - Používá se v přesně definovaných částech jmenného prostoru (.local.), - Používá pouze UTF-8 kódování, - Umožňuje, aby jména byly 255 bajtů dlouhá, - Povoluje větší UDP pakety než původní limit DNS protokolu 512 bajtů, - Dovoluje více než jedno jméno na překlad v dotazu, - Ignoruje pole ID, - Nevyžaduje opakování otázky v odpovědi, - Používá nevyžádané zprávy (odpovědi) k získání nových záznamů, - Používá NSEC k signalizaci neexistujícího záznamu, - Doporučuje AAAA záznamy v sekci dalších záznamů, když odpovídá na dotazy typu A a naopak, - Zkoumá dotazy, aby zabránil opakování stejných dotazů, - Zkoumá odpovědi, aby zabránil opakování odpovědí Protokol mdns a IPv6 Počítače používající pouze IPv4 adresy si nejsou vědomé možné přítomnosti IPv6 hostů na síti, i když jsou např. na stejné Ethernetové síti. To samozřejmě platí i naopak. Z tohoto důvodu může mít každé fyzické rozhraní dvě spolu nesouvisející zóny, jednu pro IPv4 síť a druhou pro IPv6 síť. V případě využití obou síťových protokolů (dual stack IPv4 a IPv6) mohou počítače pracovat v obou zónách, tudíž jsou počítače dosažitelné také v obou zónách. Navenek to pak vypadá, jakoby uživatel měl vícenásobné připojení (tzv. multihoming), jedno připojení přes IPv4 druhé přes IPv Výhody multicastově přenášených odpovědí v mdns Protokol mdns umožňuje v principu zasílat odpovědi na dotazy jak multicastově, tak unicastově. Na počátku vývoje protokolu se diskutovalo o výhodách multicastového přenosu.

98 98 FEKT Vysokého učení technického v Brně Konsensus je takový, že multicastové odpovědi mohou zmenšit celkovou zátěž na síti a proto by měly být preferovány. Je to dáno několika důvody: - Jedna multicastová odpověď může být zachycena více zařízeními. - Zamezuje se vícenásobným dotazům na stejnou otázku. Když jedna stanice vyšle dotaz, všechny ostatní vidí odpověď. - Pasivní kontrola chyb. Pokud stanice vidí dotaz, ale nevidí odpovídající odpověď, může této informace využít a okamžitě smazat staré údaje z paměti. Tak je dosažena stejná úroveň kvality, která by jinak vyžadovala zavedení nižší časy uložení (nižší TTL) a častější dotazy, čímž by vzrostla zátěž na síti. - Pasivní detekce konfliktů. Jelikož odpovědi mohou být čteny všemi, tak se může odhalit i konflikt vzniklý při přidělení jména, i když doménové jméno bylo předtím jedinečné. Pokud by odpovědi nebyly zasílány multicastově, tak by se musel implementovat jiný způsob kontroly, což by opět zatížilo síť. - Stálost i při špatné konfiguraci. Lokální linkové multicastové vysílání má velkou šanci, že projde přes síť i v případě chyb její v konfiguraci zejména s ohledem na IP prostory. Pakety odeslané jakýmkoliv zařízením cílené na lokální linkovou multicastovou adresu budou stále doručena všem stanicím v lokální síti. Toto může být velmi užitečné zvláště při řešení problémů v síti, neboť to zajišťuje přímý komunikační kanál mezi klientem a serverem. Tato komunikace funguje bez závislosti na ARP protokolu, směrovacích tabulkách a podobně. Můžeme tedy s daným zařízením komunikovat i bez přesné znalosti IP adresy a bez závislosti na dalších protokolech běžících v dané síti. 8.2 Lokální linkový multicastový překlad jména (LLMNR) Tato část se zabývá popisem překladu jmen pomocí protokolu LLMNR (Link-Local Multicast Name Resolution), který byl vytvořen ve společnosti Microsoft. Tento protokol je, podobně jako mdns, založen také na principech blízkých protokolu DNS. LLMNR zachovává formát paketů a podporuje všechny současné formáty zpráv DNS, typy i třídy. LLMNR pracuje, stejně jako mdns, na jiném portu než DNS (UDP/TCP port 5355), dokonce používá i odlišnou vyrovnávací paměť v rámci operačního systému (jinou než než DNS). Jelikož LLMNR pracuje pouze na lokální lince, tak se nedá považovat za náhradu DNS, ale spíše doplněk. LLMNR je určen primárně k lokálnímu překladu lokálně platných doménových jmen, popř. k překladu jmen v situaci, kdy standardní DNS nefunguje. Díky lokálním linkovým multicastovým adresám se nemohou zprávy šířit za směrovače a nemohou tedy zahltit síť. Existuje i varianta, kdy se LLMNR posílá přímo na IP adresu, tedy jako unicastová zpráva. LLMNR pro IPv4 je detailně projednáno v RFC Základní rozdíl mezi LLMNR a mdns je, že LLMNR je intenzivně využíván v operačních systémech Windows, přestože jeho specifikace je pouze informačním dokumentem (nebyla schválena jako standard), zatímco mdns je v režimu RFC standardu. S oběma protokoly se však můžeme na reálné síti potkat, proto je důležité je alespoň přehledově znát.

99 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO Překlad jména pomocí LLMNR LLMNR dotazy jsou posílány a přijímány na portu Multicastová adresa v IPv4, na které uživatelé poslouchají a na kterou se posílají i odpovědi, je Stejná adresa pro IPv6 je FF02::1:3. Většinou jsou stanice nakonfigurované jako LLMNR odpovídač (nebo také stanice odpovídající na dotazy) a zároveň i odesílatel (stanice, která přijímá LLMNR zprávy, ale neodpovídá na dotazy). Host může být nakonfigurován i jako pouze odesílatel, tj. nemusí být nutně i odpovídač. Stanice nakonfigurovaná jako odpovídač se musí chovat i jako odesílatel. Typický průběh výměny zpráv v LLMNR (schéma komunikace) je takové, jak je popsáno v následujícím: - LLMNR odesílatel vyšle dotaz na lokální linkovou multicastovou adresu, - Odpovídač odpoví na tenhle dotaz pouze v případě, že jeho odpověď je autoritativní pro dané doménové jméno. Odpoví na multicastový dotaz tak, že vyšle unicastovou odpověď přímo jejímu odesílateli. - Odpověď je po jejím přijetí zpracována a vyhodnocena Základní pravidla formátování LLMNR zpráv LLMNR je založeno na specifikaci DNS definované již v RFC Jednotlivé implementace by měly odesílat multicast odpovědi za pomoci UDP a to takové velikosti, aby nedošlo ke fragmentaci. Pokud není jisté, zda ke fragmentaci dojde nebo ne, tak je doporučeno použít maximální velikost 512 bajtů. Implementace však musí podporovat UDP dotazy a odpovědi od nejmenších velikostí až po maximální velikosti jumbo rámců (cca 9000 bajtů). Je tedy patrné, že LLMNR se na rozdíl od mdns drží spíše původní specifikace DNS protokolu. LLMNR umožňuje ve své specifikaci přenášet zprávy i unicastově, avšak v tomto případě je použit výhradně transportní protokol TCP Formát záhlaví Hlavička LLMNR je velmi podobná hlavičce běžného DNS, jak bylo popsáno v RFC 1035, není však prakticky stejná, jako je tomu u mdns. Pole ID má stejný význam jako v běžném DNS, stejně tak jako pole QR. Zajímavý je především bit označovaný jako C (conflict), jehož význam je popsán dále. Když je bit C nastaven v dotazu, znamená to, že odesílatel přijal dříve více LLMNR odpovědí na tento dotaz. V LLMNR odpovědi, pokud je tento bit nastaven, tak se znamená, že doménové jméno není unikátní. V takovém případě nedochází ke generování odpovědí, ale stanice by měly začít proces ověřování unikátnosti svých jmen Použití protokolu LLMNR Ve výchozí konfiguraci by měl být LLMNR dotaz použit pouze pro žádost o překlad jména s jedním návěštím (bez oddělování tečkami), či pro řetězec s doplněním o koncovku.local. LLMNR dotaz je vždy položen pouze na originální zadané jméno, nikdy nemá být doplněn o další části jako je např. název domény, ve které se daný počítač nachází, což provádí běžně protokol DNS. Tzn., že je vždy dotazováno pouze zadané jméno, nikoliv jeho nabízející se alternativy. Protokol se v případě IPv4 i IPv6 konektivity snaží provádět překlad oběma protokoly zároveň, čímž zvyšuje šanci na úspěch. LLMNR by však nikdy neměl být

100 100 FEKT Vysokého učení technického v Brně použit jako hlavní překladový mechanizmus, spíše pouze jako záložní varianta pro případ selhání systému DNS. Z pohledu běžné koncové stanice umožňuje LLMNR zvolit si téměř libovolný jmenný název a tento ohlásit do lokální sítě. Z praktického hlediska je tento název často vytvořen z názvu počítače, který je třeba při instalaci operačního systému Windows zadat. Přes tuto jmennou adresu pak může být stanice lokálně dostupná (opět samozřejmě až po provedení překladu na IP adresu) a tato adresa se může lišit od klasického DNS názvu stanice v DNS databázi.

101 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO Kvalita služeb v IP sítích Klasické IP sítě jsou od své podstaty sítě typu best-effort, což znamená, že každý paket zpracovávají stejným způsobem a nezávisle na ostatních a tím pádem zachovávají pro všechny pakety jednotnou úroveň zacházení. Tento způsob je dostačující pro klasický přenos souborů, ne však pro moderní síťové služby pracující v reálném čase nebo obecně služby vyžadující od sítě specifickou úroveň zacházení. Mezi tyto služby je možné zařadit například přenos hlasu přes IP síť označovaný jako VoIP (Voice over Internet Protocol), videokonference, služby využívané v rámci telemedicíny, vzdálený dohled, bankovní a finanční operace a různé druhy záchranných a bezpečnostních systémů. IP sítě dlouho nebyly připraveny na přenos a zajištění požadované úrovně kvality takového typu dat. Velký uživatelský zájem o tyto služby však vedl k návrhu a implementaci mechanismů, které v různé míře umožňují zajištění kvality služeb, tzv. QoS (Quality of Service). Pojem QoS lze vyjádřit různými způsoby, záleží totiž na úhlu pohledu. Z pohledu koncového uživatele je vnímání QoS subjektivní, relativní a těžko měřitelné. Koncový uživatel vnímá kvalitu služby skrz jeho koncová zařízení a má určitá očekávání o odpovídající úrovni kvality. Zjednodušeně lze tedy říci, že uživatel hodnotí zajištění QoS podle subjektivní kvality zvuku během VoIP přenosu nebo kvality obrazu během videokonference. I přesto, že je objektivní hodnocení uživatelského vnímání kvality služeb poněkud problematické, pro hodnocení kvality lidské řeči bylo definováno několik nástrojů. Jedním z nich je stupnice MOS (Mean Opinion Score) nabývající hodnot od 1 do 5, kdy 1 = špatná, 2 = nízká, 3 = uspokojivá, 4 = dobrá, 5 = excelentní kvalita. MOS je stanoven subjektivní metodou hodnocení. Uživatel hodnotí úroveň kvality přenášené řeči a definuje odpovídající MOS hodnocení. Hraniční hodnotou MOS pro použití v oblasti VoIP je hodnota 2.6. Subjektivní hodnocení je poměrně drahé a časově náročné, proto byl dle doporučení ITU-T G.107 definován tzv. E-model, jehož výstupem je R-factor (Quality Ranking Factor). E-model je výpočetní model, kterým je možné nahradit subjektivní hodnocení využívající stupnici MOS. E-model v sobě zahrnuje kombinaci účinků různých variant přenosových parametrů působících na kvalitu hovoru. Výstupem je pak metrika nazvaná R-faktor, která je numerickým vyjádřením hlasové kvality. R-faktor nabývá hodnot 0 až 100, kde hodnota nula reprezentuje extrémně špatnou kvalitu a hodnota 100 velmi vysokou kvalitu, Tab. 6 ukazuje vzájemnou provázanost hodnot MOS a R-factor. Tab. 6: Vzájemný vztah mezi hodnotami R-factor a MOS R-factor MOS Uživatelské hodnocení ,5 4,3 Velká spokojenost ,3 4,0 Spokojenost ,0 3,6 Někteří uživatelé nespokojeni ,6 3,1 Mnoho uživatelů nespokojeno ,1 2,6 Téměř všichni uživatelé nespokojeni ,6 1,0 Není doporučeno

102 102 FEKT Vysokého učení technického v Brně Naproti tomu je definice QoS z pohledu sítě poněkud odlišná. Jedná se o schopnost sítě poskytovat odlišné zacházení různým typům síťového provozu. QoS tedy umožňuje přidělování rozdílných priorit provozu různým datovým tokům a zvýhodňovat tak určitý typ provozu před ostatními. Zajištění QoS z pohledu sítě lze tedy jednoznačně definovat pomocí objektivních parametrů provozu jako je ztrátovost paketů nebo jejich zpoždění. Tyto dva odlišné pohledy na problematiku QoS uživatelský a síťový však nemusí být vždy v souladu. V některých případech může být sítí garantováno spojení s jasně definovanými objektivními parametry, avšak uživatel nemusí pocítit subjektivní zlepšení nebo zhoršení kvality služby. Nasazení technologie pro zajištění kvality služeb tedy nemusí vždy nutně vést ke spokojenosti koncového uživatele. Z pohledu síťových operátorů je tedy nutné jednak zvolit efektivní QoS mechanizmus, jeho konfiguraci přizpůsobit konkrétním požadavkům a skladbě síťového provozu v dané síti a v neposlední řadě také získat zpětnou vazbu od koncových uživatelů. V dalších kapitolách budou popsány jednotlivé QoS parametry a mechanizmy a problematika zajištění kvality služeb bude tedy rozebírána ze síťového pohledu.

103 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO Parametry síťového provozu z pohledu zajištění QoS Aby bylo možné v sítí zavést diferenciaci datových toků a odlišné úrovně priority, je nutné jednotlivé úrovně zacházení popsat pomocí jasně definovaných a snadno měřitelných parametrů. Mezi základní QoS parametry, které ovlivňují kvalitu služeb, patří: zpoždění paketů, kolísání zpoždění, ztrátovost paketů, propustnost Zpoždění paketů Zpoždění neboli latence je definováno jako doba potřebná k přenosu paketu od zdroje k cíli. Celkové zpoždění se skládá z dílčích složek. Mezi hlavní zdroje zpoždění patří: zdrojové kódování (A/D a D/A převod, doba trvání jednoho rámce), paketizační zpoždění, kanálové kódování (detekce a opravy chyb, prokládání), jitter buffer (pokud je využíván), zpoždění způsobené čekáním paketů ve frontě aktivního prvku, propagační zpoždění (odvozené od rychlosti šíření signálu v médiu a ze vzdálenosti). Hodnoty zpoždění způsobené zdrojovým kódováním, paketizací, kanálovým kódováním a jitter bufferem jsou závislé na použitém kodeku, naproti tomu zpoždění způsobené čekáním paketů ve frontách síťových prvků nebo samotných přenosem jde na vrub samotné síti Kolísání zpoždění Kolísání zpoždění, označováno také jako jitter, zachycuje změnu zpoždění během přenosu jednotlivých paketů od zdroje k cíli. Pakety jsou ze zdroje odesílány s určitými časovými rozestupy. V ideálním případě by se stejnými časovými rozestupy byly také přijaty a hodnota jitteru by tedy byla nulová. V reálném prostředí však často vlivem různého stupně zahlcení síťových prvků dochází ke změně tohoto intervalu a tím pádem mohou pakety dorazit do cíle s různým zpožděním Ztrátovost paketů Ztrátovost paketů udává množství paketů, které nedorazí do cíle. Nejčastěji se udává v procentech a vypočítá se jako poměr počtu ztracených paketů k celkovému počtu odeslaných paketů. Ke ztrátě paketů může dojít hned z několika důvodů. Nejčastěji je to z důvodu zahlcení či přetížení síťového uzlu, kdy některé směrovače nebo přepínače nestačí odbavovat příchozí pakety dostatečně rychle. Dojde tedy k zaplnění front v jejich vyrovnávacích pamětích a další příchozí pakety musí být zahozeny.

104 104 FEKT Vysokého učení technického v Brně 10.4 Propustnost Propustnost v oblasti počítačových sítí označuje maximální množství dat, které je možné přenést přes danou linku za jednotku času. Propustnost je nejčastěji udávána v bitech za sekundu.

105 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO Třídy služeb V předchozím textu byly uvedeny některé příklady síťových služeb, který vyžadují rozdílný způsob zacházení a je pro ně vhodné použít některý z mechanizmů zajištění kvality služeb. Každá z těchto služeb má však odlišný charakter provozu a vyžaduje tedy specifickou úroveň QoS. Například klasický přenos souborů nebo elektronická pošta, což byly jedny z prvních síťových služeb, jsou vysoce citlivé na ztrátu nebo chybný příjem paketů, ale nejsou tolik citlivé na zpoždění nebo jitter. Naproti tomu, služba VoIP je vysoce citlivá na zpoždění a jeho proměnlivost, ale naopak je schopná si poradit s malou mírou ztrátovosti paketů. Aby tedy bylo možné každý typ aplikace nějak zařadit a určit pro ni konkrétní hodnoty požadovaných parametrů provozu, byly definovány tzv. kategorie služeb, někdy označované také jako QoS třídy nebo třídy služeb. Jedna z používaných klasifikací pro IP sítě, viz Tab. 7, je definována v doporučení ITU-T Y Jinou, alternativní, klasifikaci QoS tříd navrhla organizace ETSI v rámci projektu TIPHON (Telecommunications and Internet Protocol Harmonization Over Networks). Tab. 7: Klasifikace QoS tříd podle ITU-T Y.1541 QoS třída Charakteristika 0 Aplikace pracující v reálném čase, citlivost na jitter, vysoce interaktivní 1 Aplikace pracující v reálném čase, citlivost na jitter, interaktivní 2 Transakční data, vysoce interaktivní 3 Transakční data, interaktivní 4 Pouze nízká ztrátovost (krátké transakce, shluková data, streamování videa 5 Tradiční aplikace původních IP sítí Zařazení síťové aplikace do některé z výše uvedených QoS tříd je základním předpokladem pro efektivní zajištění požadované úrovně služby Dohoda o úrovni poskytované služby SLA Výsledná úroveň zajištění QoS je závislá na všech prvcích, přes které prochází uživatelský datový tok. Vzhledem k tomu, že data často prochází přes síťové domény spravované různými poskytovateli síťového připojení SP (Service Provider), je potřeba určitým standardním formálním způsobem definovat vztah mezi těmito poskytovateli a koncovými uživateli. Proto je nedílnou součástí systému pro zajištění kvality služeb dohoda o úrovni poskytované služby, označovaná zkráceně jako SLA (Service Level Agreement). Podle standardu ITU-T E.860 je SLA formální dohoda mezi dvěma nebo více entitami, které je dosaženo po vzájemném vyjednávání za účelem definování konkrétních parametrů přenosu a příslušných práv a povinností. Zmíněnými entitami jsou nejčastěji dva poskytovatelé síťového připojení nebo poskytoval připojení a koncový uživatel. Na Obr je zobrazeno rozhraní a soubor bodů interakce mezi poskytovatelem síťového připojení a koncovým uživatelem.

106 106 FEKT Vysokého učení technického v Brně Obr. 11-1: Vzájemný vztah mezi uživatelem a poskytovatelem služby Dohoda SLA jasně vymezuje úroveň poskytované služby, způsob kontroly jejího dodržování a také situace, kdy sjednané parametry nejsou dodrženy. SLA definuje nejen povinnosti poskytovatele síťového připojení, ale také formát a parametry provozu, který smí koncový uživatel do sítě vysílat. SLA vymezuje také podmínky tarifikace a účtování. Na základě této dohody tedy uživatel ví, jaké parametry jsou mu garantovány, a může podle toho posoudit využití různých sítových služeb případně se rozhodnout pro jiného SP. Na druhé straně, také poskytovatel připojení má informace o charakteru příchozího provozu a tyto informace pak může využít při návrhu a optimalizaci přenosové sítě. Zpravidla sjednané parametry se vztahují na provoz určité kategorie služeb a ne na konkrétní toky dat.

107 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO Mechanizmy zajištění kvality služeb v IP sítích Základní způsob zpracovávání datových jednotek v IP sítích, označovaný jako best-effort, zajišťuje všem tokům stejnou pravděpodobnost přenosu, avšak zároveň není schopný garantovat specifické parametry síťového provozu. Proto bylo nutné vyvinout mechanizmus, který bude schopný zajistit klasifikaci datových toků podle typu služby a následné odlišné zacházení pro jednotlivé třídy služeb uvnitř sítě, což jsou dva základní úkoly všech technologií pro zajištění QoS. Existuje poměrně velké množství teoretických návrhů systémů pro zajištění QoS v datových sítích, avšak jen malé množství z nich se skutečně podařilo prakticky realizovat a ve větší míře prosadit. V následujícím textu budou popsány dvě základní technologie pro zajištění kvality služeb - IntServ a DiffServ, které se prosadily v praxi. Každá z těchto mechanizmů řeší problematiku QoS odlišným způsobem. Na Obr jsou srovnány jednotlivé metody zacházení s datovými toky aplikované v mechanizmech best-effort, IntServ a DiffServ. Při metodě best-effort jsou všechny pakety koncentrované do jednoho výsledného toku nezávisle na zdroji a typu dat. V mechanizmu IntServ jsou jednotlivé toky rozlišovány a je s nimi individuálně zacházeno po celé trase spojení. Třetí způsob zacházení přináší architektura DiffServ, kdy jsou vstupní datové toky rozřazeny do menšího počtu předem definovaných tříd a je s nimi dále zacházeno podle pravidel definovaných pro danou třídu provozu. Místem, kde jsou v IP síti implementovány funkce pro vykonávání základních úkolů při zajišťování QoS, jsou aktivní síťové prvky. Tuto pozici zastávají nejčastěji směrovače nebo inteligentní přepínače. Obr. 12-1: Způsoby zacházení s datovými toky pro technologie IntServ, DiffServ a Best-effort

108 108 FEKT Vysokého učení technického v Brně 12.1 Technologie Integrovaných služeb (IntServ) Technologie Integrovaných služeb (IntServ - Integrated Services), byla první technologie používaná v IP sítích, která umožňovala klasifikaci datových toků a přidělování síťových zdrojů podle typu služby a splnila tak oba výše popsané základní úkoly obecného QoS mechanizmu. Koncept Integrovaných služeb byl definován v roce 1994 v dokumentu RFC Základní myšlenka architektury IntServ vychází z okruhově-spínaného typu komunikace, kdy jsou síťové zdroje alokovány zvlášť pro každý vybraný tok dat. Aby aplikace získala požadované parametry přenosu, musí před samotným přenosem dat proběhnout proces rezervace. Rezervace síťových zdrojů se skládá z několika kroků. Nejprve musí aplikace definovat charakter odesílaných dat a také požadavky na síťové zdroje. Síť poté použije směrovací protokol pro nalezení vhodné trasy, která umožní uspokojení požadavků uživatelské aplikace. Následně je použit rezervační protokol pro vytvoření tzv. rezervačního stavu, který zajištuje garanci síťových zdrojů na všech zúčastněných uzlech podél celé trasy. Je tedy nutné vyjednat, zda jsou všechny prvky sítě schopné garantovat požadované parametry přenosu. Jestliže poskytnuté síťové zdroje nejsou na některém z uzlů dostačující, spojení bude odmítnuto a zdrojová aplikace se může rozhodnout, zda se spokojí s mírnějšími požadavky, nebo odloží přenos. Pokud je však proces rezervace jednou schválen a řádně dokončen, aplikace může začít vysílat svoje data po rezervované trase RSVP protokol K zajištění informovanosti prvků sítě a tím pádem k rezervaci prostředků v síti slouží u mechanizmu IntServ tzv. rezervační protokoly. V praxi je používán především protokol RSVP (Resource Reservation Protocol), jehož podrobný popis je uveden v literatuře. RSVP protokol poskytuje mechanizmus pro vytváření a správu rezervačního stavu podél celé trasy mezi zdrojem a cílem datového toku. Samotné rozhodnutí, která trasa bude pro přenos dat vybrána, je však provedeno směrovacím protokolem. RSVP proces se jednoduše řídí informacemi ve směrovací tabulce a na základě těchto informací posílá RSVP zprávy. Díky tomu je RSVP protokol nezávislý na použitém směrovacím protokolu. Protokol RSVP definuje dva typy zpráv: PATH a RESV (viz Obr. 12-2). Aplikace působící jako zdroj datového toku vysílá v pravidelných intervalech zprávy typu PATH. Tato zpráva putuje směrem k příjemci přes jednotlivé směrovače. Zpráva obsahuje záznam o charakteru vysílané informace a je do ní zaznamenávána cesta mezi zdrojem a příjemcem dat. Tyto informace dále slouží k rezervaci výše zmíněných síťových prostředků. Po přijetí zprávy PATH aplikace na straně příjemce odpoví zprávou typu RESV, kterou potvrdí přidělení požadovaných síťových zdrojů. Zprávu RESV zašle směrem ke zdroji po cestě definované v přijaté zprávě PATH. RESV zprávy specifikují požadavky na síťové zdroje a vytváří rezervační stav ve směrovačích podél zvolené trasy. Zpráva typu PATH obsahuje následující objekty PHOP (Previous Hop), Sender template, Sender TSpec a AdSpec, jejichž význam je blíže popsán v literatuře. Zpráva typu RESV figuruje v protokolu RSVP jako rezervační žádost a je tvořena objekty Flow Spec a Filter Spec, které jsou společně označované jako Flow Descriptor. Rezervační stav vytvořený protokolem RSVP má definovanou dobu trvání, a pokud tato doba vyprší, dojde k automatickému zrušení tohoto stavu. Z tohoto důvodu musí být rezervační stav pravidelně, standardně každých 30 sekund, aktualizován pomocí RSVP zpráv. Tyto aktualizace zároveň umožňují protokolu RSVP reagovat na změny v topologii sítě.

109 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 109 RSVP protokol provádí rezervaci pouze v jednom směru. Přestože aplikace většinou pracuje současně jako vysílač i přijímač, RSVP tyto dvě entity logicky odděluje. Proto je nutné při obousměrné komunikaci provést rezervaci pro oba směry zvlášť. Obr. 12-2: Základní operace protokolu RSVP Referenční model IntServ Na Obr je znázorněný referenční model technologie IntServ, který se skládá z několika funkčních bloků, které jsou třeba pro správnou funkci mechanizmu Integrovaných služeb. Tyto komponenty musí být implementovány ve směrovačích i koncových uzlech podílejících se na zajištění QoS pro dané spojení. Obr. 12-3: Referenční model technologie IntServ

110 110 FEKT Vysokého učení technického v Brně Referenční model technologie IntServ je možné rozdělit na dvě základní části - řídící rovinu a datovou rovinu. Řídící rovina zajišťuje proces rezervace síťových zdrojů a datová rovina provádí předávání datových paketů na základě vytvořeného rezervačního stavu. V následujícím textu budou popsány základní funkce čtyř hlavních bloků referenčního modelu IntServ, kterými jsou rezervační agent, řízení přístupu, klasifikátor a plánovač paketů. Detailnější popis je uveden v literatuře. Rezervační agent tento blok vykonává veškeré funkce spojené s rezervací síťových zdrojů. Za účelem rezervace dosažení požadované úrovně služby je potřeba v každém směrovači vytvořit a následně spravovat rezervační stav. K tomuto účelu se využívají dříve popsané zprávy protokolu RSVP. Na základě sestaveného rezervačního stavu jsou řízeny funkce v blocích klasifikátor a plánovač paketů. Řízení přístupu funkce řízení přístupu slouží k rozhodnutí, zda bude požadavek na rezervaci zdrojů schválen nebo zamítnut. Každý síťový uzel podél celé trasy musí provést lokální rozhodnutí, zda má dostatečné množství zbývajících síťových zdrojů pro uspokojení požadavků definovaných v rezervačním profilu. Mezi síťové prostředky patří zejména požadovaná velikost vyrovnávacích pamětí a propustnost. Blok řízení přístupu v sobě může zahrnovat autentizaci žádosti o rezervaci nebo některé prioritní funkce pro zamezení situace, kdy by rezervované zdroje byly v rozporu s definovanou lokální politikou provozu. Klasifikátor jedná se o blok patřící do datové roviny, která slouží ke zpracovávání jednotlivých paketů. Hlavní funkcí klasifikátoru je rozhodování, zda patří daný paket k některému z datových toků s garantovaným zacházením a pokud ano, tak ke kterému. Každý příchozí paket musí být přiřazen některému datovému toku s rezervovanými prostředky, příp. zůstat mezi datové toky zpracované metodou Best-effort. Parametry, s kterými klasifikátor pracuje, jsou nejčastěji zdrojová a cílová IP adresa, ID (Identifikátor) protokolu vyšší vrstvy a čísla portů transportního protokolu, což jsou informace uložené v hlavičce přicházejícího paketu. Pokud je paket úspěšně přiřazen k některému z rezervovaných RSVP toků, je z kontrolní databáze datových toků získána informace rezervačním stavu a paket je následně předán do bloku plánovače odesílání. Plánovač paketů řídí řazení paketů do front a jejich následné odesílání na výstupní port směrovače. Plánovač paketů je ve skutečnosti zodpovědný za realizaci dojednané rezervace síťových zdrojů, proto je často považován za nejdůležitější část referenčního modelu architektury IntServ. Řazením paketů do front na základě jejich předešlé klasifikace a podle použité metody řízení jejich odesílání je plánovač schopný přímo ovlivňovat dobu, kterou paket stráví ve frontě, nebo prioritu zahození paketu při zaplnění vyrovnávací paměti. Obecným úkolem plánovače paketů je tedy opakovaný výběr paketu k odeslání, v případě volné odchozí linky Modely služeb Modely služeb popisují rozhraní mezi sítí a jejími uživateli v rámci architektury rezervace zdrojů. Model služby tedy definuje, co uživatel služby může žádat od sítě a jaký typ zdrojů může síť poskytnout. Technologie IntServ definuje dva základní modely služeb - službu s řízenou zátěží a službu s garantovanými parametry, jejichž bližší popis je možné najít v literatuře.

111 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO Technologie Diferencovaných služeb (DiffServ) Architektura IntServ využívající protokol RSVP pro rezervaci síťových zdrojů byla dokončena v roce Téměř okamžitě se však objevily problémy s její implementací. Poskytovatelé internetového připojení argumentovali zejména vysokou složitostí a neefektivním fungováním této technologie na nízko-kapacitních linkách. Mezi jednotlivými ISP platila obecná shoda, že masové nasazování mechanizmu IntServ spolu s protokolem RSVP je nepraktické a neekonomické a že je nutné hledat jednodušší a efektivnější řešení. Některé z hlavních implementačních problémů jsou rozebrány v dokumentu RFC Bylo tedy nutné nalézt řešení, které bude nabízet jednoduchý způsob rozlišení síťového provozu a zároveň nebude vyžadovat vytváření rezervačních stavů pro jednotlivé toky dat, což výrazným způsobem zatěžuje síťové uzly. V počáteční fázi tohoto hledání vznikly dva prvotní návrhy. Základní myšlenkou obou těchto dokumentů byl předpoklad, že každý IP paket je individuálně označen v závislosti na jeho prioritě, což umožní odlišný způsob zacházení pro pakety různých síťových služeb. Tento princip se později stal základem pro mechanizmus DiffServ. Technologie DiffServ tedy využívá zcela odlišný způsob zajištění kvality služeb v IP sítích v porovnání s technologií IntServ. Základní myšlenka Diferencovaných služeb je velmi jednoduchá. Jednotlivé datové toky jsou sdruženy do několika tříd podle základního charakteru služeb (viz Obr. 12-4), takže síťové prvky (s výjimkou hraničních) se nemusí starat o každý datový tok zvlášť. Každý IP paket vstupující do datové sítě je označen značkou, která říká, jak má být s paketem zacházeno neboli určuje třídu přenosu poskytnutou paketu. Toto značení paketů probíhá pouze na vstupu do datové sítě. Během přenosu paketů datovou sítí další směrovače pouze přečtou značku každého paketu a dle této značky se řídí při zacházení s paketem. Značka je uložena přímo v hlavičce IP paketu, takže není potřeba žádný signalizační protokol pro vytvoření rezervačního stavu. Dále, jelikož je síťový provoz sdružován a následně zpracováván v rámci tříd, odpadá potřeba složitého třídění a plánování síťových zdrojů pro jednotlivé datové toky, jako je tomu u technologie IntServ. Obr. 12-4: Základní princip fungování technologie DiffServ

112 112 FEKT Vysokého učení technického v Brně Počet značek, a tedy i definovaných tříd provozu, je relativně malý, obvykle jednotky, maximálně desítky. Zatímco u technologie integrovaných služeb (IntServ) udržuje každý směrovač informaci o prostředcích přidělených každému jednotlivému spojení, u rozlišovaných služeb směrovače pouze přidělí určité prostředky každé třídě přenosu a zajistí určitý vztah mezi jednotlivými třídami. Např. může být stanoveno, že pakety s určitou značkou budou ve směrovači obslouženy pouze tehdy, pokud ve frontě nebudou stát pakety s jinou značkou odpovídající vyšší prioritě. V následujícím textu budou popsány dílčí bloky a funkce mechanizmu diferencovaných služeb DiffServ doména Rozsáhlé počítačové sítě se obvykle tvoří propojením menších sítí, přičemž každá síť může být řízena jiným subjektem, organizačně jinak uspořádaná a vybavená různými síťovými prvky. Proto v každé síti může docházet i k odlišnému způsobu zpracování paketů pro zajištění požadované kvality služeb. Z tohoto důvodu se rozsáhlé sítě dělí na více oblastí se samostatnou správou. Z pohledu mechanizmu diferencovaných služeb se tyto oblasti nazývají DS (DiffServ) domény. Příklad DiffServ domény je zobrazen na Obr Obr. 12-5: DiffServ doména Každá DS doména je spravována jedním poskytovatelem připojení ISP (Internet Service Provider) a probíhá v ní jednotná administrace, která zajišťuje vyhodnocování oprávněnosti požadavků, přiřazení toků do jednotlivých tříd a označování paketů. V rámci DS domény jsou rozlišovány dva typy směrovačů: Hraniční směrovač (Edge / Boundary Router) hraniční směrovač leží mezi dvěma DS doménami nebo na rozhraní mezi DS doménou a částí sítě, která nepodporuje mechanizmus DiffServ. Tento směrovač tedy provádí klasifikaci vstupních toků a následné označování paketů, které jsou pak dále posílány do DS domény. Hraniční směrovač může v závislosti na svém umístění pracovat buď jako vstupní (Ingress) nebo výstupní (Egress) prvek. Jsou-li dvě DiffServ domény

113 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 113 propojeny jedním směrovačem, pracuje výstupní směrovač jedné DS domény zároveň jako vstupní směrovač druhé DS domény a plní i opačné funkce pro pakety procházející v opačném směru. Páteřní směrovač (Core / Interior Router) - páteřní směrovač se nachází uvnitř DS domény a nároky na tento prvek jsou podstatně menší v porovnání s hraničním směrovačem. Páteřní směrovač neprovádí žádnou klasifikaci paketů, zajišťuje pouhé předávání označených paketů a garantuje určitou kvalitu služby definovanou značkou v hlavičce paketu. V rámci každé DS domény musí být jasně definována úroveň služby, kterou může koncový uživatel očekávat od sítě, respektive od ISP. K tomuto účelu slouží dohoda o úrovni poskytované služby SLA. SLA je aplikována na rozhraních mezi uživatelem a DS doménou nebo dvěma DS doménami spravovanými různými ISP (viz Obr. 12-5) a jasně vymezuje povolené profily síťového provozu, podmínky zacházení s datovými toky, konkrétní síťové parametry pro jednotlivé třídy provozu atd Identifikátor DSCP (DiffServ Code Point) Mechanizmus DiffServ je postaven na předpokladu odlišného zacházení pro jednotlivé pakety. Aby to bylo možné, je třeba pakety nějakým způsobem od sebe odlišit. K tomu slouží jedinečný identifikátor, značka, označovaný jako DSCP. Tato značka je uložena v hlavičce IP paketu v 8-bitovém poli původně označovaném jako ToS (Type of Service) pro verzi IPv4 nebo TC (Traffic Class) pro verzi IPv6. Původní význam pole ToS včetně jeho struktury je uveden v dokumentu RFC 791. První 3 bity se označují jako IP precedence a udávají prioritu obsloužení daného paketu, neboli definují pravděpodobnost jeho zahození a ovlivňují zpoždění způsobené řazením paketu do front síťového prvku. Další 3 bity označují očekávanou úroveň přednostního zpracování daného IP paketu. Konkrétně se jedná o zpoždění (D - Delay), propustnost (T - Throughput) a spolehlivost (R - Reliability) zvolené trasy. Zbylé dva bity (č. 6 a 7) jsou rezervovány pro budoucí použití nebo pro experimentální účely. V případě, že je v síti použita technologie DiffServ, pak jsou původní pole ToS a TC využita pro uložení značky DSCP, která definuje způsob zacházení s daným paketem během jeho průchodu DiffServ doménou. V takovém případě se změní struktura pole ToS (TC) a toto pole je označováno jako DS pole. Velikost DS pole zůstává 8 bitů, avšak pro uložení DSCP značky se používá pouze prvních 6 bitů, zbylé dva jsou momentálně nevyužité - CU (Currently Unused), viz Obr V současnosti však již existují řešení, která využívají právě tyto poslední dva bity z DS pole pro detekci blížícího se zahlcení sítě. CU bity se pak označují jako ECN (Explicit Congestion Notification) identifikátor. Obr. 12-6: DS pole

114 114 FEKT Vysokého učení technického v Brně Struktura DSCP značky je definována v RFC Díky kombinaci 6 bitů je možné získat celkem 64 jedinečných identifikátorů udávaných ve formátu xxxxxx, kde x může nabývat hodnoty 0 nebo 1. Rozsah hodnot DSCP byl rozdělen do 3 skupin. První skupina obsahuje prvních 32 DSCP hodnot, které jsou standardizované a určené pro běžné použití. Druhá skupina obsahuje dalších 16 hodnot, které jsou určené pro experimentální nebo lokální použití. Zbývajících 16 DSCP hodnot je vyhrazeno taktéž pro výzkumné nebo lokální účely, avšak může být standardizováno v případě, že dojde k vyčerpání hodnot z první skupiny. DSCP hodnota označuje konkrétní třídu provozu a zároveň označuje způsob zacházení, který je poskytnut všem paketům patřícím do této třídy. Mapování DSCP hodnot na třídy provozu je závislé na konkrétní implementaci mechanizmu DiffServ, existuje však několik doporučení uvedených v literatuře. V následující Tab. 8 je uveden jeden z možných způsobů přidělení DSCP značek jednotlivým třídám provozu. Tab. 8: Příklad mapování DSCP hodnot na konkrétní typy síťových služeb Typ služby Telefonie Multimediální konference Multimediální streamování Data vyžadující nízké zpoždění Data vyžadující vysokou propustnost Třída provozu (PHB) DSCP hodnota Vzorová aplikace EF IP telefonie AF AF Videokonference AF AF AF Audio a video streaming AF AF AF AF AF AF AF Webové služby typu klient-server Webové služby typu klient-server Standardní data BE (výchozí) Není specifikováno Způsob zacházení PHB (Per-Hop Behavior) Značka DSCP definuje konkrétní třídu provozu a na ni je navázán definovaný způsob zacházení s pakety patřícími do dané třídy. V rámci architektury Diferencovaných služeb se způsob zacházení s pakety označuje zkratkou PHB. PHB nedefinuje přímo konkrétní mechanizmy nebo způsob jejich implementace, ale obsahuje spíše obecný popis způsobu zacházení s pakety (v závislosti na DSCP) nebo specifikaci parametrů požadované služby

115 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 115 v rámci dané DS domény. Pro dosažení stejné úrovně zacházení v rámci konkrétního PHB je tedy možné použít různé fyzické implementace metod řízení front a plánování odesílání paketů. V rámci technologie DiffServ jsou organizací IETF definovány čtyři typy způsobu zacházení PHB. Výchozí PHB Výchozí PHB je definován pro zpětnou kompatibilitu s tradičním způsobem zacházení typu best-effort, který poskytuje všem paketům stejnou úroveň QoS. Tento způsob zacházení musí podporovat všechny DiffServ prvky. Výchozímu PHB odpovídá hodnota DSCP ve formátu Výchozí způsob zacházení PHB je nejčastěji přidělen paketům, které nespadají do žádné z definovaných tříd provozu. Class Selector PHB Druhým způsobem zacházení je CS (Class Selector) PHB, který je definován v literatuře. CS PHB je definován kvůli snaze o zpětnou kompatibilitu s původní strukturou pole IP ToS a zejména pak s jeho částí označovanou jako IP precedence. Jak již bylo dříve uvedeno, IP precedence je 3-bitové pole udávající prioritu obsloužení daného paketu. Aby byla zajištěna koexistence starších QoS implementací, které využívají pole IP precedence, spolu s technologií DiffServ, byl definován Class Selector PHB, kterému odpovídají DSCP ve formátu xxx000, kde x reprezentuje hodnotu 0 nebo 1. Pro CS PHB je tedy vyhrazeno 8 DSCP značek. Mapování mezi těmito 8 DSCP značkami a konkrétními třídami provozu je závislé na dané implementaci, avšak hodnoty a musí mít vždy zajištěnu vyšší prioritu zacházení v porovnání s defaultním PHB. Tyto dvě hodnoty DSCP odpovídají hodnotám IP precedence 111 a 110, které se běžné používají pro služby typu řízení sítě nebo signalizace. Přednostní zacházení definované pro tyto dvě DSCP značky zachovává původní způsob použití hodnot IP precedence. Expedited Forwarding PHB Způsob zacházení EF (Expedited Forwarding) je definován v RFC EF PHB je určen pro síťové služby vyžadující nízké zpoždění, jitter a ztrátovost. Je tedy vhodný zejména pro služby pracující v reálném čase, neboť představuje nejvyšší úroveň zacházení. EF PHB je však poměrně složitý na řízení a konfiguraci, proto se využívá pro zajištění QoS pouze u vybraných kritických aplikací. V současnosti nejčastějším typem služby, pro který je využíván EF PHB je VoIP. Aby bylo možné splnit přísné požadavky na zmíněné parametry provozu, je třeba pro PHB typu EF zajistit prioritní obsluhu odpovídající fronty DS směrovače. Nejčastěji je tato prioritní obsluha implementována formou prioritní fronty, jejíž pakety budou vždy obslouženy přednostně. Poskytnutí PHB typu EF danému toku však současně znamená vyhrazení téměř všech síťových prostředků, což pak může vést k neefektivnímu využívání prostředků sítě. Urychlené doručení, jak je EF někdy překládán, by tedy mělo být využíváno jen pro datové toky, které tvoří malou část z celkové síťového provozu. Z hlediska praktické implementace je dále velice žádoucí, aby tato prioritní fronta měla uměle omezenou propustnost, např. využitím mechanismu rate-limiting.

116 116 FEKT Vysokého učení technického v Brně Assured Forwarding PHB AF (Assured Forwarding) PHB je definován v dokumentu RFC Hlavním cílem způsobu zacházení Assured Forwarding je doručení paketů, a proto zpoždění paketů nebo jitter nejsou tak důležité jako míra ztrátovosti, což je zásadní rozdíl oproti EF PHB. Způsob zacházení AF tedy představuje vysokou úroveň garance, že daný paket bude doručen, pokud agregovaný provoz nevybočuje z podmínek dohodnutých v SLA. Síťový provoz překračující dohodnuté podmínky má vysokou pravděpodobnost zahození. Pokud je však i přesto přenesen přes síť, pak vždy zůstává zachováno pořadí všech přenesených paketů, což představuje další rozdíl oproti způsobu zacházení EF, kde mohou být pakety vybočující z daného profilu provozu zahozeny nebo doručeny mimo pořadí. Z tohoto pohledu je tedy AF PHB vhodnější pro služby, které nepracují v reálném čase, jako například aplikace využívající protokol TCP. AF PHB se dále dělí na čtyři třídy - AF1, AF2, AF3 a AF4. V rámci každé třídy jsou pakety zařazeny do některé ze tří podtříd s odpovídající úrovní pravděpodobnosti zahození. Rozdíly mezi třídami jsou nejčastěji dány propustností garantované pro jednotlivé třídy. Třída AF4 by tedy měla mít garantovánu největší propustnost a naopak třída AF1 nejmenší, tím pádem pakety zařazené do třídy AF1 mají menší pravděpodobnost doručení než pakety ve třídě AF4. Obecný formát značení AF tříd je AFxy, kde x označuje třídu doručení (1 až 4) a y označuje prioritu zahození v rámci dané třídy. Priorita zahození je definována hodnotami 1, 2 nebo 3, kdy 1 představuje nízkou a 3 vysokou pravděpodobnost zahození. Podtřída AF33 má tedy větší prioritu zahození než podtřída AF Referenční model DiffServ Referenční model technologie DiffServ je definován v RFC 2475 a také v RFC Model diferencovaných služeb se skládá z několika bloků, které jsou stavebními kameny celého mechanizmu. Referenční model DiffServ je zobrazen na Obr a je možné jej rozdělit na dvě základní části. Na část klasifikace, kde probíhá třídění a značkování paketů a část pro úpravu provoz, která na základě parametrů provozu a DSCP značek přidělených jednotlivým paketům rozhoduje o jejich dalším zpracování. Obr. 12-7: Referenční model technologie DiffServ

117 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 117 Třídič (Classifier) Hraniční prvky DiffServ sítě jsou zodpovědné za mapování paketů do některé z podporovaných tříd provozu. Tuto funkci vykonává blok třídič, který provádí identifikaci přicházejících paketů a jejich následné dělení do několika skupin podle předem definovaných pravidel. Existují dva základní druhy třídičů: BA (Behavior Aggregate) patří mezi nejjednodušší DiffServ třídiče. Tento třídič vybírá pakety pouze na základě DSCP značky umístěné v DS poli v hlavičce IP paketu. Tento typ klasifikace se implicitně používá v případě, kdy byl paket označen dříve, než dorazil na vstupní rozhraní směrovače. MF (Multifield) druhý typ třídiče vybírá pakety na základě jednoho nebo více kritérií, jako může být například IP zdrojová adresa, cílová IP adresa, zdrojový a cílový TCP/UDP port nebo identifikátor zapouzdřeného protokolu, atd. MF třídič je flexibilnější a je možné jej použít pro složitější politiku alokace síťových zdrojů. Značkovač (Marker) Jakmile jsou pakety roztříděny do jednotlivých tříd, přicházejí do bloku značkovače, kde jsou označeny DSCP značkou odpovídající dané třídě provozu. Podle přidělené hodnoty DSCP má každý paket definován způsob zacházení PHB, který určuje úroveň zajištění QoS. Jednotlivé typy PHB byly popsány v předchozím textu. Měřič (Meter) Funkce části referenčního modelu DiffServ označené jako úprava provozu zajišťují dohled nad síťovým provozem. Hraniční směrovače musí provádět kontrolu, zda síťový provoz přicházející od zákazníka je v souladu s předem dohodnutými podmínkami definovanými mezi koncovým zákazníkem a poskytovatelem služby. Ty pakety, které odpovídají dohodnutému profilu služby, jsou odeslány na výstup směrovače směrem do sítě. Při překročení dohodnutých podmínek pro daný typ provozu jsou pakety dále zpracovávány, přičemž může nastat jejich přeznačení (Remaker), tvarování (Shaper) nebo zahození (Dropper). Aby mohla být prováděna kontrola přicházejících datových toků, je třeba definovat konkrétní síťové parametry a také způsob jejich měření. Nejčastěji se jedná o následující dva parametry provozu: Maximální okamžitá přenosová rychlost PIR (Peak Information Rate) označuje maximální povolený (na základě SLA) počet bitů, které mohou být uživatelem vyslány v daný okamžik. Nejčastěji PIR odpovídá maximální přenosové rychlosti zákaznické linky. PIR je udávána v bajtech za sekundu. Převrácená hodnota 1/PIR udává minimální dobu mezi příchody dvou po sobě jdoucích paketů. Garantovaná průměrná přenosová rychlost CIR (Committed Information Rate) označuje průměrnou přenosovou rychlost, kterou poskytovatel připojení garantuje zákazníkovi. Stejně jako PIR, i CIR je udávána v bajtech za sekundu. PIR i CIR se měří pouze na úrovni síťové vrstvy, což znamená, že se do výpočtu nezahrnují hlavičky nižších vrstev. Spolu s maximální okamžitou a garantovanou průměrnou přenosovou rychlostí jsou definovány další tři parametry provozu, které slouží jako pomocné parametry při měření PIR a CIR. Konkrétně se pak jedná o velikost garantovaného shluku CBS (Committed Burst Size),

118 118 FEKT Vysokého učení technického v Brně velikost nadměrného shluku EBS (Excess Burst Size) a velikost maximálního shluku PBS (Peak Burst Size). CBS tedy udává maximální množství paketů udávané v bajtech, které může být přeneseno rychlostí PIR v rámci jednoho shluku, aniž by došlo k překročení CIR. EBS označuje prahovou hodnotu pro shluk, který překročí velikost CBS, to znamená, že CBS < EBS. CBS a EBS jsou používány ve spojení s měřením přenosové rychlosti CIR. Parametr PBS má obdobný význam jako CBS, avšak je definován ve spojitosti s rychlostí PIR. Parametry CBS, EBS i PBS jsou udávány v bajtech. Přeznačovač (Remaker) Funkce přeznačovače byla částečně rozebrána již v předchozím textu. K přeznačení paketu může dojít na základě nesplnění kritérií pro definovanou třídu provozu. Většinou se tedy pro tyto nevyhovující pakety nastaví jiná DSCP značka představující vyšší prioritu zahození při případném zahlcení sítě v dalších směrovačích. Dalším důvodem k přeznačení paketů může být jejich přechod mezi dvěma DS doménami, které používají odlišný způsob třídění provozu. Tvarovač (Shaper) Tvarovač má za úkol přenést datový tok v souladu se sjednaným datovým profilem. To se nejčastěji provádí pozdržením nevyhovujících paketů v paměti síťového prvku za účelem vytvarování datového toku do podoby vyhovující definovaným podmínkám. Rozdíl mezi tvarovačem a značkovačem je v tom, že značkovač jednoduše označí paket a nechá jej projít do sítě. Zatímco tvarovač zabrání paketům projít sítí do té doby, dokud se datový tok nepřizpůsobí danému profilu. Vlivem pozdržení paketů ve frontě narůstá zpoždění přenosu a jitter, což však může mít nepříznivý vliv na služby pracující v reálném čase. Stejně jako přeznačení, tak i tvarování je důležitý proces v hraničním uzlu mezi dvěma DiffServ doménami. Zahazovač (Dropper) Výsledkem barvení může být rozhodnutí, že daný paket odporuje dohodnutým parametrům provozu a má být zahozen. Tuto funkci provádí blok zahazovače. Zahazovač realizuje jednodušší metodu zpracování paketů než tvarovač, neboť nepotřebuje vyrovnávací paměť Mechanizmus Token Bucket Základním algoritmem většiny implementací části úpravy provozu v architektuře diferencovaných služeb je mechanizmus TB (Token Bucket). Jedná se o algoritmus využívající principu kreditů (tokenů) pro tvarování provozu a řízení objemu dat, který může být přenesen přes síťový prvek. TB je nejčastěji popisován jako virtuální nádoba, která obsahuje určitý počet tokenů. Tokeny jsou do nádoby doplňovány konstantní rychlostí. Přicházející paket může být odeslán na výstupní rozhraní směrovače pouze v případě, že je v nádobě dostatečný počet tokenů, který je roven minimálně velikosti příchozího paketu. Jinými slovy, token představuje povolení pro odeslání určitého množství dat dále do sítě. Při každém zpracování jednoho paketu je z nádoby odebráno množství tokenů odpovídající velikosti paketu.

119 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 119 Token Bucket, viz Obr. 12-8, je tedy definován rychlostí doplňování tokenů r a velikostí nádoby b. Největší povolený shluk přicházejících paketů pak tedy odpovídá objemu nádoby a průměrná rychlost příchodu paketů odpovídá rychlosti doplňování tokenů. Pokud průměrná rychlost paketů překročí rychlost doplňování tokenů do nádoby nebo velikost shluku přicházejících paketů překročí velikost nádoby, dojde k dočasnému vyprázdnění nádoby, což vede k pozdržení nebo přímému zahození zpracovávaného paketu. Obr. 12-8: Mechanizmus Token Bucket Proces měření a následné označování (nebo přeznačování) paketů na základě výsledků měření spolu velmi úzce souvisí a proto bývají často implementovány v rámci jednoho mechanizmu. Kombinace procesů měření a nastavení odpovídající značky je označována pojmem barvení. V současnosti jsou nejčastěji využívány dvě metody barvení: jedna rychlost - 3 barvy (srtcm - Single Rate Three Color Marker) a dvě rychlosti - 3 barvy (trtcm - Two Rate Three Color Marker). Základem obou těchto metod je mechanizmus Token Bucket Plánované odesílání paketů Plánované odesílání paketů umožňuje prioritní zacházení pro vybrané třídy síťového provozu, což je základní myšlenka téměř všech technologií pro zajištění kvality služeb. Proto je plánované odesílání paketů srdcem každého QoS mechanizmu, neboť právě tento proces má zásadní vliv na výslednou úroveň kvality uživatelské aplikace. Pojmem plánované odesílání paketů jsou většinou označeny dva úzce související procesy - proces řazení paketů do front a proces řízeného odesílání, který rozhoduje, který paket bude odeslán na výstupní rozhraní síťového prvku. Plánované odesílání paketů je u technologie DiffServ prováděno na základě DSCP značky a k ní přidruženému způsobu zacházení PHB. Proces řízeného odesílání paketů není standardizovaný, ale je závislý na typu zařízení od určitého výrobce. Je definováno pouze

120 120 FEKT Vysokého učení technického v Brně několik základních požadavků, které by měla každá metoda plánovaného odesílání paketů splňovat. Jedním ze základních požadavků je spravedlivé rozdělování dostupné šířky pásma mezi datové toky v souladu s prioritním systémem implementovaným do správy front. Funkce plánovaného odesílání paketů je aplikována na každém výstupním rozhraní DiffServ směrovače. V následujícím textu budou rozebrány základní principy nejčastěji používaných metod plánovaného odesílání paketů. FIFO (First In First Out) FIFO je nejstarší a nejjednodušší metoda řazení a následného odesílání paketů, která je založená na jednoduchém algoritmu, který řadí přicházející pakety podle času jejich příchodu. Jak je již z názvu zřejmé, paket, který první přijde, je také jako první odeslán na výstup, viz Obr Obr. 12-9: Algoritmus First In First Out Metoda FIFO je také někdy označovaná jako FCFS (First Come First Serve). Jedná se o nejrozšířenější metodu obsluhy paketů uvnitř síťových prvků, která však neposkytuje možnost zvýhodnění některého typu provozu, neboť poskytuje všem paketům stejný způsob zacházení. Z tohoto důvodu se FIFO nejlépe hodí pro výchozí způsob zacházení Best-effort. Jedinou výhodou tohoto mechanizmu je jednoduchá implementace. PQ (Priority Queuing) Metodou, která již přináší možnost prioritizace vybraného typu provozu, je PQ. V rámci tohoto algoritmu je definováno několik FIFO front s přidělenou úrovní priority. Pakety z vybrané fronty s určitou úrovní priority mohou být odeslány na výstupní rozhraní směrovače pouze tehdy, pokud jsou všechny fronty s vyšší prioritou prázdné. Princip algoritmu PQ je zobrazen na Obr Výhodou metody PQ je, podobně jako u FIFO, její jednoduchá implementace. Naproti tomu, hlavní nevýhodou je fakt, že pokud je vysoce prioritní provoz zastoupen v síti velkým dílem, pak fronty s nízkou prioritou nemusí být nikdy obslouženy. Prioritní systém front by tedy měl být používán velmi opatrně a fronty s vysokou prioritou by měly být vyhrazeny pouze pro menšinový typ síťového provozu.

121 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 121 Obr : Algoritmus Priority Queuing FQ (Fair Queuing) U algoritmu FQ, někdy také označovaného jako RR (Round Robin), jsou pakety řazeny do N front. Každé z těchto front je přidělena část celkové propustnost výstupního portu o velikosti 1/N. Všechny fronty jsou pak cyklicky obsluhovány v pevně daném pořadí (prázdné fronty jsou přeskakovány). Z každé navštívené fronty je vždy odeslán jeden paket. Princip metody spravedlivé obsluhy je zobrazen na Obr Obr : Algoritmus Fair Queuing Implementace algoritmu FQ je jednoduchá, neboť není vyžadován speciální mechanizmus pro alokaci přenosové kapacity. Pokud je přidána nová fronta k N existujícím frontám, plánovač automaticky nastaví pro každou frontu novou velikost propustnosti, která bude odpovídat 1/(N + 1) z celkové propustnosti výstupního portu. Spravedlivá obsluha má však také dvě hlavní nevýhody. První nevýhoda vychází právě ze spravedlivého dělení celkové propustnosti mezi jednotlivé fronty. Není totiž možné poskytnout odlišnou propustnost pro služby s různými požadavky. Druhá nevýhoda spočívá v tom, že metoda FQ bude skutečně spravedlivá jen v případě, že budou ve všech frontách pakety se stejnou velikostí. To je však pouze ideální situace a praxe je poněkud odlišná. Fronty obsahující pakety s větší velikostí ve skutečnosti zaberou větší přenosovou rychlost než je původně přidělená část 1/N.

122 122 FEKT Vysokého učení technického v Brně WRR (Weighted Round Robin) První uvedenou nevýhodu algoritmu FQ řeší algoritmus WRR, který je schopný vyhradit rozdílnou část celkové kapacity výstupního portu pro třídy provozu s odlišnými požadavky. Tento mechanizmus je někdy označován také jako CBQ (Class-Based Queuing) nebo také CQ (Custom Queuing). Mechanizmus vážené spravedlivé obsluhy je zobrazen na Obr Vstupní datové toky jsou rozděleny do m tříd, kdy je každé třídě přidělena určitá část celkové propustnosti výstupního portu v závislosti na váze přidělené dané třídě. Jednotlivé váhy jsou odvozeny od skutečných požadavků konkrétní třídy. Součet váhových hodnot všech tříd je roven 100% dostupné šířky pásma, tj. (1): m i1 w i 100%, (1) kde m je celkový počet tříd a wi je váhová hodnota přiřazená i-té třídě. Alokace šířky pásma pro každou třídu může být provedena pomocí procentuálního rozdělení času, který je použit pro obsluhu dané třídy. V rámci každé třídy je definováno N front se spravedlivou obsluhou FQ. Algoritmus WRR tedy využívá dvojitý systém obsluhy typu Round Robin. První RR je použit pro výběr třídy od 1 až do m a druhý RR slouží pro obsluhu front uvnitř dané třídy. Obr : Algoritmus Weighted Round Robin

123 Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO 123 Mechanizmus WRR sice řeší jeden z nedostatků algoritmu FQ, kterým je neschopnost rozdělit celkovou propustnost podle skutečných požadavků jednotlivých tříd, avšak problém s velikostí paketů zůstal. Pokud některá z front bude obsahovat delší pakety v porovnání s ostatními, pak tato fronta získá vyšší přenosovou rychlost, než jí bylo původně přiděleno. WFQ (Weighted Fair Queuing) Zmíněný vliv délky paketu na skutečně přidělenou část celkové propustnosti řeší až algoritmus WFQ. U tohoto mechanizmu jsou vstupující pakety rozděleny do N front. Na základě váhových hodnot jednotlivých front je jim přidělena odpovídající část celkové propustnosti. Součet všech váhových hodnot je opět na základě rovnice (1) roven 100%. Zatímco u algoritmu FQ je z právě obsluhované fronty odeslán vždy jeden celý paket, u WFQ se plánovač snaží odesílat pakety z front tak, aby odesílání skončilo v době vypočítané dle teoretického modelu zohledňujícího délku paketů. Tento teoretický model se označuje jako vážená bitová cyklická obsluha WBBRR (Weighted Bit-by-Bit Round Robin). WBBRR využívá mechanizmu, kdy jsou cyklicky obsluhovány jednotlivé fronty, ale pakety nejsou na výstup odesílány v celku, ale bit po bitu. Tyto bity jsou pak zachyceny v bloku složení paketu a odtud jsou teprve odeslány na výstup. Větší paket tedy musí cekat delší dobu, aby byl znovu složen. Jak je vidět z Obr , WFQ se snaží vypočítat dobu (na základě modelu vážené bitové cyklické obsluhy), kdy má skončit přenos daného paketu a vlastní odesílání pak řídí tak, aby pakety byly odesílány právě v souladu s touto vypočítanou dobou konce odesílání. Tento systém spravedlivé alokace kapacity rozhraní zohledňující velikost paketů však s sebou přináší také výraznou výpočetní náročnost a složitou implementaci. I přesto se však jedná o jeden z nejpoužívanějších algoritmů pro plánované odesílání paketů v rámci technologie DiffServ. Obr : Algoritmus Weighted Fair Queuing