Obr. 5

Transkript

Obr. 5

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/28.0062
Evropského sociálního fondu a státním rozpočtem České republiky.
FEKT Vysokého učení technického v Brně
2
Autoři
Ing. Jan Jeřábek, Ph.D., Ing. Jiří Hošek, Ph.D.
Název
Protokoly komunikačních technik pro integrovanou výuku VUT a
VŠB-TUO
Vydavatel
Vysoké učení technické v Brně
Fakulta elektrotechniky a komunikačních technologií
Ústav telekomunikací
Technická 12, 612 00 Brno
Vydání
první
Rok vydání
2014
Náklad
elektronicky
ISBN
978-80-214-5070-7
Tato publikace neprošla redakční ani jazykovou úpravou.
Protokoly komunikačních technik pro integrovanou výuku VUT a VŠB-TUO
3
Obsah
1
ÚVOD ............................................................................................................................ 6
2
VYBRANÉ APLIKAČNÍ PROTOKOLY A JEJICH VLASTNOSTI ....................... 7
2.1 VYBRANÉ PROTOKOLY VIRTUÁLNÍCH TERMINÁLŮ ........................................................ 7
2.1.1
Terminál, počítačový terminál a emulátor ................................................ 7
2.1.2
Protokol SSH (Secure Shell) ..................................................................... 7
2.1.3
Průběh standardní komunikace (SSH-2) ................................................... 8
2.1.4
Vrstvy protokolu SSH (verze 2) ................................................................. 9
2.2 VYBRANÉ PROTOKOLY PRO PŘENOS SOUBORŮ ............................................................ 10
2.2.1
Bezpečné alternativy k protokolu FTP (File Transfer Protocol) .............. 10
2.2.2
Ukázka zachycení přihlašovacích údajů (login + heslo).......................... 11
2.2.3
Trivial FTP (TFTP) ................................................................................ 11
2.2.4
Aplikace RSYNC ..................................................................................... 12
2.3 DOPLNĚNÍ K WWW TECHNOLOGIÍM .......................................................................... 13
2.3.1
Rozšiřující technologie zvyšující možnosti HTTP protokolu .................... 13
2.3.2
Proxy servery ......................................................................................... 15
2.3.3
Protokol HTTPS ..................................................................................... 17
2.4 VYBRANÉ PROTOKOLY PRO PŘENOS ELEKTRONICKÉ POŠTY ......................................... 17
2.4.1
SMTP (Simple Mail Transfer Protocol) .................................................. 17
2.4.2
POP3 (Post Office Protocol verze 3) ...................................................... 18
2.4.3
IMAP4 (Internet Message Access Protocol verze 4) ................................ 19
3
VYBRANÁ TÉMATA MANAGEMENTU POČÍTAČOVÝCH SÍTÍ ...................... 21
3.1
3.2
3.3
3.4
3.5
4
ÚVOD DO MANAGEMENTU SÍTÍ S PROTOKOLEM IP ....................................................... 21
OBLASTI ŘÍZENÍ POČÍTAČOVÝCH SÍTÍ .......................................................................... 22
OBECNÁ ARCHITEKTURA MANAGEMENTU .................................................................. 23
INFORMACE PRO MANAGEMENT SÍTĚ .......................................................................... 24
ZÁKLADY PROTOKOLU SNMP (SIMPLE NETWORK MANAGEMENT PROTOCOL) ........... 29
3.5.1
Verze protokolu SNMP ........................................................................... 29
MODERNÍ KOMUNIKAČNÍ TECHNIKY V PROSTŘEDÍ INTERNETU ........... 33
4.1 DISTRIBUOVANÉ SYSTÉMY......................................................................................... 33
4.1.1
Distribuované aplikace a systémy ........................................................... 33
4.1.2
Obecná charakteristika distribuovaných systémů .................................... 35
4.1.3
Výhody distribuovaných systémů ............................................................ 35
4.1.4
Vnitřní organizace distribuovaných systémů ........................................... 36
4.2 MIDDLEWARE VRSTVA .............................................................................................. 36
4.2.1
Přístupy k tvorbě middleware vrstvy ....................................................... 37
4.2.2
Služby poskytované middleware vrstvou ................................................. 38
4.3 UKÁZKA PROSTŘEDÍ PRO DISTRIBUOVANÉ APLIKACE – .NET FRAMEWORK ................. 39
4.3.1
Základní struktura .................................................................................. 39
4.3.2
Stručná historie verzí platformy .NET Framework .................................. 43
4.4 .NET REMOTING ....................................................................................................... 44
4.4.1
Architektura .NET Remoting ................................................................... 44
4.4.2
Základní vlastnosti a principy technologie .NET Remoting ..................... 45
4.5 ÚVOD DO PROBLEMATIKY POKROČILÝCH WEBOVÝCH SLUŽEB ..................................... 46
4.5.1
Komunikace s využitím protokolu SOAP ................................................. 47
4
5
PROCESY A SYSTÉMY ............................................................................................ 49
5.1 PROBLEMATIKA NÁVRHU SYSTÉMŮ ............................................................................ 49
5.1.1
Fáze definice problému........................................................................... 50
5.1.2
Fáze specifikace chování systému ........................................................... 50
5.1.3
Fáze implementace ................................................................................. 51
5.1.4
Fáze výroba, nasazení ............................................................................ 51
5.1.5
Fáze využívání systému a jeho údržba ..................................................... 51
5.1.6
Ověření správnosti ................................................................................. 51
5.2 TEORIE KONEČNÝCH AUTOMATŮ................................................................................ 52
5.2.1
Úvod do teorie konečných automatů ....................................................... 52
5.2.2
Kombinační sítě ...................................................................................... 52
5.2.3
Sekvenční sítě ......................................................................................... 53
5.2.4
Tabulka přechodů a výstupů ................................................................... 54
5.2.5
Grafická reprezentace konečných automatů ............................................ 56
5.3 PROCESY, PARALELNÍ SYSTÉMY A SOUVISEJÍCÍ POJMY................................................. 61
5.3.1
Popis systému ......................................................................................... 61
5.3.2
Systém reálného času.............................................................................. 61
5.3.3
Procesy .................................................................................................. 62
5.3.4
Paralelní procesy ................................................................................... 63
5.3.5
Vznik a zánik procesů ............................................................................. 63
5.4 KOMUNIKACE A FORMY SYNCHRONIZACE MEZI PROCESY ............................................ 66
5.4.1
Komunikace mezi procesy ....................................................................... 66
5.4.2
Formy synchronizace mezi procesy ......................................................... 67
5.4.3
Uváznutí procesu .................................................................................... 69
5.4.4
Problém Producent – Konzument ........................................................... 73
5.4.5
Kritéria vzájemného vyloučení procesů................................................... 74
5.4.6
Stavový znak (blokovací proměnná) ........................................................ 75
5.4.7
Konstrukce semaforu .............................................................................. 75
5.4.8
Kritické oblasti (sekce) ........................................................................... 77
5.4.9
Monitory................................................................................................. 78
5.4.10 Rendez-vous ........................................................................................... 81
5.4.11 Vyrovnávací paměti ................................................................................ 82
5.5 NÁVRH VLASTNÍHO KOMUNIKAČNÍHO PROTOKOLU ..................................................... 83
6
ÚVOD DO KRYPTOGRAFIE ................................................................................... 85
6.1
6.2
6.3
6.4
7
PŘÍSTUPY K ŠIFROVÁNÍ .............................................................................................. 85
SYMETRICKÉ ŠIFROVÁNÍ ............................................................................................ 85
ASYMETRICKÉ ŠIFROVÁNÍ .......................................................................................... 86
VYBRANÉ ŠIFROVACÍ A HASH ALGORITMY .................................................................. 88
6.4.1
DES ........................................................................................................ 88
6.4.2
AES ........................................................................................................ 88
6.4.3
Dokonalá (Vernamova) šifra .................................................................. 88
6.4.4
Diffie-Hellman........................................................................................ 89
6.4.5
RSA ........................................................................................................ 89
6.4.6
MD ......................................................................................................... 89
6.4.7
SHA ........................................................................................................ 90
SMĚROVACÍ PROTOKOL IS-IS ............................................................................. 91
7.1 ZÁKLADNÍ FAKTA O PROTOKOLU IS-IS ....................................................................... 91
7.2 VYBRANÉ VLASTNOSTI PROTOKOLU IS-IS .................................................................. 92
7.3
7.4
7.5
7.6
8
5
METRIKA PROTOKOLU IS-IS ...................................................................................... 92
PAKETY PROTOKOLU IS-IS ........................................................................................ 93
NSAP (NET) - INTERNÍ ADRESY V PROTOKOLU IS-IS ................................................. 93
OBLASTI A JEJICH IDENTIFIKÁTORY ............................................................................ 94
DOPLŇKOVÉ TECHNIKY DOMÉNOVÉHO PŘEKLADU .................................. 95
8.1 MULTICAST DNS ...................................................................................................... 95
8.1.1
Základní popis protokolu mDNS ............................................................. 95
8.1.2
Znaková sada mDNS .............................................................................. 95
8.1.3
Zprávy v protokolu mDNS ...................................................................... 96
8.1.4
Formát záhlaví zpráv mDNS ................................................................... 96
8.1.5
Porovnání mDNS a klasického DNS ....................................................... 97
8.1.6
Protokol mDNS a IPv6 ........................................................................... 97
8.1.7
Výhody multicastově přenášených odpovědí v mDNS .............................. 97
8.2 LOKÁLNÍ LINKOVÝ MULTICASTOVÝ PŘEKLAD JMÉNA (LLMNR) ................................. 98
8.2.1
Překlad jména pomocí LLMNR............................................................... 99
8.2.2
Základní pravidla formátování LLMNR zpráv ........................................ 99
8.2.3
Formát záhlaví ....................................................................................... 99
8.2.4
Použití protokolu LLMNR....................................................................... 99
9
KVALITA SLUŽEB V IP SÍTÍCH .......................................................................... 101
10 PARAMETRY SÍŤOVÉHO PROVOZU Z POHLEDU ZAJIŠTĚNÍ QOS ........... 103
10.1 ZPOŽDĚNÍ PAKETŮ ................................................................................................... 103
10.2 KOLÍSÁNÍ ZPOŽDĚNÍ ................................................................................................ 103
10.3 ZTRÁTOVOST PAKETŮ .............................................................................................. 103
10.4 PROPUSTNOST ......................................................................................................... 104
11 TŘÍDY SLUŽEB ....................................................................................................... 105
11.1 DOHODA O ÚROVNI POSKYTOVANÉ SLUŽBY SLA ...................................................... 105
12 MECHANIZMY ZAJIŠTĚNÍ KVALITY SLUŽEB V IP SÍTÍCH ........................ 107
12.1 TECHNOLOGIE INTEGROVANÝCH SLUŽEB (INTSERV) ................................................ 108
12.1.1 RSVP protokol ...................................................................................... 108
12.1.2 Referenční model IntServ ...................................................................... 109
12.1.3 Modely služeb ....................................................................................... 110
12.2 TECHNOLOGIE DIFERENCOVANÝCH SLUŽEB (DIFFSERV)........................................... 111
12.2.1 DiffServ doména ................................................................................... 112
12.2.2 Identifikátor DSCP (DiffServ Code Point) ............................................ 113
12.2.3 Způsob zacházení PHB (Per-Hop Behavior) ......................................... 114
12.2.4 Referenční model DiffServ .................................................................... 116
12.2.5 Mechanizmus Token Bucket .................................................................. 118
12.2.6 Plánované odesílání paketů .................................................................. 119
SEZNAM POUŽITÉ LITERATURY ............................................................................. 124
6
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
2 Vybrané aplikační protokoly a jejich vlastnosti
2.1 Vybrané protokoly virtuálních terminálů
2.1.1 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ý.
2.1.2 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
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 (www.cygwin.com),
tj. „program“ pro Windows tvářící se jako Linux, který již umožňuje používat sadu SSH.
2.1.3 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 Debian7ubuntu3.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. 2-1. 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
Obr. 2-1: Komunikace klienta a serveru SSH protokolu, seznam paketů a obsah jednoho
vybraného zasílaného od serveru ke klientovi
2.1.4 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
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 2
2.2 Vybrané protokoly pro přenos souborů
2.2.1 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. 2.3.3).
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. 2.1.2. 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
(www.winscp.org).
2.2.2 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ě
2.2.3 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
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.
2.2.4 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
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. 2.1.2).

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
2.3.1 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

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
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).
2.3.2 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 server1 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. 2-4. 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.
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ší.
1
16
3
8
WWW prohlížeč
Proxy
WWW server
5
10
6.
1
TCP
IP
Síťové rozhraní
HTTP
HTTP
TCP
TCP
IP
IP
Síťové rozhraní
Síťové rozhraní
HTTP
klientská část
serverová část
HTTP
TCP
IP
Síťové rozhraní
2
4
9
7
Obr. 2-4: Fungování komunikace zprostředkované proxy serverem
Stručný popis jednotlivých kroků fungování komunikace z Obr. 2-4:
(1) Uživatel
chce
zobrazit
určitou
stránku
na
Internetu,
http://www.server.cz/stranka.htm, což se předá nižším vrstvám k přenosu.
např.:
(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
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.
2.3.3 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
2.4.1 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
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ě.
2
18
zpráv, stejně jako ukázky průběhu komunikace, je možné nalézt na Internetu např. ve
specifikaci tohoto protokolu (RFC5321, viz http://tools.ietf.org/html/rfc5321).
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í emailové 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í MIME3
(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 emailové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. 2.3.3). 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.
2.4.2 POP3 (Post Office Protocol verze 3)
POP3 je taktéž klient – server protokol, který se běžně používá pro stahování
emailový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
(http://tools.ietf.org/html/rfc1939).
Protokol POP3 prochází při řízení připojení mezi poštovním serverem a e-mailový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 emailový klient podporující protokol POP3, který
se připojuje k serveru, ověřen. Teprve poté může uživatel stahovat svoje e-maily. Pokud se
uživatelské jméno a heslo předané emailový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í emailů.
Rozšíření MIME umožňuje, aby znaky v emailové 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.
3
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 e-mail, jsou stažené zprávy označeny k odstranění
a poté z úložiště pošty odstraněny, pokud není emailový 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.
2.4.3 IMAP4 (Internet Message Access Protocol verze 4)
Protokol IMAP verze 4 se používá4, stejně jako POP3, pro přístup k e-mailů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 (http://tools.ietf.org/html/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“.
IMAP byl původně vyvinut na Stanford University v roce 1986. Současný standard označovaný jako
IMAP4rev1 je z roku 2003.
4
20
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
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
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 FUP5, správa
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
5
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. 3-1.
Horní
úroveň
-
Účtování, …
Řízení databází
Střední
úroveň
-
Nízká
úroveň
-
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 Station6). 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. 3.4. 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
http://en.wikipedia.org/wiki/Network_monitoring_comparison .
24
Příklad rozmístění agentů a manažera v rámci spravované sítě je možné nalézt na Obr.
3-2. Na obrázku jsou agenti pro jednoduchost umístěni pouze na aktivních prvcích sítě
a serverech.
WAN
agent
agent
Farma
serverů
agent
agent
agent
agent
Síť 4
Síť 1
Síť 3
agent
agent
Síť 2
Síť 5
agent
agent
...
...
manager
Síť 0
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í – syntax7
a sémantika8. 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
8
Syntax = skladba vyjadřuje pravidla pro zápis symbolů (zpráv).
Sémantika = jejich význam.
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ř.: 1.3.6.1.2.1.1.5.
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 stromu9, 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.
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.
9
26
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ě
.1.3.6.1.2.1.2.1. 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ů“
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.
10
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
•
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
3.5 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 1989. 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. 3-4. 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 (getrequest13) 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.
3.5.1 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.
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.
11
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.
12
30
Množina základních operací protokolu SNMP (verze 1)
Příkaz
Význam
get-request
žádost manažera o získání hodnoty určité proměnné
get-next-request
žádost o získání hodnoty proměnné bez udání jejího přesného
jména (př.: další hodnota v tabulce)
get-response
odpověď agenta na operaci žádosti o čtení nebo zápis
manažera
set-request
příkaz manažera k zápisu hodnoty ve zprávě
specifikované proměnné
trap
asynchronní událost iniciovaná agentem
SNMP agent
get-response
set-request
get-request
SNMP spojení
get-next-request
Program správy
SNMP dohled a řízení
trap
get-response
set-request
get-next-request
get-request
Spravovaný
objekt
trap
Tab. 1:
SNMP manager
UDP
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
3.5.1.1 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
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í.
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.
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.
3.5.1.4 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

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
4 Moderní komunikační techniky v prostředí Internetu
4.1 Distribuované systémy
4.1.1 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. 4-1. 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
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ích15. 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.
Seznam nejvýkonnějších superpočítačů, mezi kterými jsou i clustery, je možné nalézt na http://top500.org/ .
Jako příklad uveďme např. velmi populární systém Seti@Home (http://setiathome.berkeley.edu/) nebo
Folding@Home (http://folding.stanford.edu/). 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.
14
15

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.
4.1.2 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ě.
4.1.3 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
4.1.4 Vnitřní organizace distribuovaných systémů
Distribuovaný systém může mít plně decentralizované řízení, tzv. P2P sítě (Peer-ToPeer), 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. 4-2. 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).
Komunikace v
závislosti na typu
použitého protokolu
Distribuovaná
aplikace
Middleware
...
Uživatelská
logika
systému
Uživatelská
logika
systému
Komunikace
nezávislá na typu
použitého protokolu
Uživatelská
logika
systému
Aplikační server
Klient
Middleware
TCP/IP
Obr. 4-2: Blokové schéma distribuovaného systému, typ klient-server s middleware vrstvou
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. 4-3. 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)
Jádro (Kernel)
Jádro (Kernel)
Stanice/Proces
Stanice/Proces
Stanice/Proces
Obr. 4-3: Distribuovaný systém z pohledu procesů
4.2.1 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 paradigmatech16, 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. 4.4.
16
Paradigma = vzor, příklad, model.
38
4.2.2 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
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. 4.3.
4.3 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.
4.3.1 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. 4-4. S platformou souvisí i programovací jazyky, viz obrázek a dále.
.NET Framework
Jazyky
40
Visual
Basic
C++
C#
J#
...
Specifikace jazyků CLS (Common Language Specification)
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
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
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. 4-5.
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
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
Kompilace Just-in-Time
Kód závislý na
vykonávající
platformě
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.NET17 (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
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.
17
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.NET17 (Active Server Pages.NET).
4.3.2 Stručná historie verzí platformy .NET Framework
.NET Framework 2.0
3.0
3.5
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. 4-7. 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.
LINQ
WPF/E
WinForms
ADO.NET Framework
WCF
WF
ASP.NET
Card Space
ADO.NET
Základní knihovna tříd (Base Class Library), Data, XML
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

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ě.
4.4.1 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
Formátovač
Formátovač
Transportní kanál
Transportní kanál
Serverový objekt
Obr. 4-8: Zjednodušená architektura .NET Remoting
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
objektu18 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).
4.4.2 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
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. 4.4.1. 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. 4-9.
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 UDDI19 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.
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.
19
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. 4.2.
Mezilehlá síť
(Internet)
Webová
Aplikační
kód
služba
Klient
Obr. 4-9: Postavení webové služby v rámci komunikačního procesu
4.5.1 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. 4-10.
SOAP
XML
HTTP
TCP/IP
Obr. 4-10: Sada protokolů při komunikaci s webovou službou
48
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
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

NE
Systém
vyhovuje
Definice
problému
Určené funkce,
objekty
ANO
Využívání
systému
Specifikace
chování
Systém
NE
Ověření
specifikace
ANO
Výroba,
nasazení
Abstraktní
systém
NE
ANO
Implementace
Testování
prototypu
NE
Prototyp
Ověření
implementace
ANO
Obr. 5-1: Vývojový diagram vzniku a existence systému
50
Tuto posloupnost kroků a rozhodnutí je možné přehledně zaznačit pomocí vývojového
diagramu znázorněného na Obr. 5-1. Pět základních stavů přibližují následující kapitoly.
5.1.1 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ě.
5.1.2 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
5.1.3 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.
5.1.4 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.
5.1.5 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.
5.1.6 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
5.2 Teorie konečných automatů
5.2.1 Úvod do teorie konečných automatů
Když vytváříme specifikaci systému (např. viz kap. 5.1.2), 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. 5-2. 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ů.
Xm
Y1
Systém
Q1 … Qr
Y2
...
{
X2
...
Vstupní
vektor
X1
Yn
}
Výstupní
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.
5.2.2 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.
Y1
Systém
Y = f(X)
Xm
Y2
...
{
X2
...
Vstupní
vektor
X1
Yn
53
}
Výstupní
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čí.
5.2.3 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. 5-4. 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 [Xm]
Stav
[Qr]
systému
Kombinační síť
[Yn]
Výstupní
vektor
Paměť
vnitřních
stavů
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
 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í.
5.2.4 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
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
Tab. 3:
Výchozí stav
X1
X2
Q1
Y1
Y1
Q2
Y1
Y1
Q3
Y2
Y1
Q4
Y2
Y2
Tabulka přechodů > nový stav(výchozí stav; vstup)
Vstup
Výchozí stav
X1
X2
Q1
Q2
Q1
Q2
Q2
Q3
Q3
Q4
Q1
Q4
Q4
Q4
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
Tab. 4:
Složená tabulka > [nový stav, výstup](výchozí stav; vstup)
Vstup
Výchozí stav
X1
X2
Q1
Q2, Y1
Q1, Y1
Q2
Q2, Y1
Q3, Y1
Q3
Q4, Y2
Q1, Y1
Q4
Q4, Y2
Q4, Y2
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
Q1
Q2
Q3
Q4
Q1
X2, Y1
X1, Y1
0
0
Q2
0
X1, Y1
X2, Y1
0
Q3
X2, Y1
0
0
X1, Y2
Q4
0
0
0
X1, Y2
X2, Y2
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.
5.2.5 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
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. 5-5.
[Xi] / [Yi]
Qi
Qj
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. 5-6. 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ý.
[Xi]
Qi /Y(Qi)
Qj /Y(Qj)
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. 5.2.4 zapisovali pomocí tabulek. Situace je znázorněna na Obr. 5-7. 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. 5-7.
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
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
Q1
1/0
1/0
Q2
0/0
0/0
Q3
1/1
1/1
Q4
0/1
a)
Q1 / 0
0
1
0
Q2 / 0
1
0
Q3 / 0
1
Q4 / 1
1
0
b)
Obr. 5-7: Zápis příkladu Příklad 5.1 pomocí a) Mealyho b) Mooreho automatu
59
INIT
–/
–/
DISCOVER
TIMEOUT
SELECTING
OFFER
SELECT OFFER /
REQUEST
–/
TIMEOUT
OFFER / COLLECT
ACK not
accepted /
DECLINE
REQUESTING
NAK /
ERASE
ACK /
RECORD LEASE TIME
OFFER, ACK, NAC /
Discard
BOUND
PRE-EXPIRED LEASE /
REQUEST
ACK /
RECORD LEASE TIME
RENEWING
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. 5-8. 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. 5-10 ), 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
Cesta klienta
CLOSED
Cesta serveru
Neobvyklé cesty
LISTEN / –
LISTEN
SYN / SYN + ACK
CLOSE / –
SEND / SYN
RST / –
SYN
RECEIVED
CONNECT
/ SYN
CLOSE / –
SYN
SENT
SYN / SYN + ACK
(souběžné spojení)
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 / ACK
FIN WAIT 1
ACK / –
CLOSING
FIN + ACK /
ACK
FIN WAIT 2
ACK / –
TIME WAIT
CLOSE WAIT
CLOSE / FIN
LAST ACK
FIN / ACK
Timeout
Aktivní ukončení
Pasivní ukončení
Neobvyklé cesty
ACK / –
CLOSED
Obr. 5-10: Stavový automat reprezentující ukončování spojení u TCP protokolu
(zjednodušená varianta)
61
5.3 Procesy, paralelní systémy a související pojmy
5.3.1 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í.
5.3.2 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

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.
5.3.3 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, S0) = (K0, S0), (K1, S1), ...
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. 511.
63
deaktivace
Aktivní
Čekající
Příchod očekávaných
událostí
aktivace
Obr. 5-11: Nejjednodušší rozdělení stavů procesu
5.3.4 Paralelní procesy
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ý.
5.3.5 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. 5-12. 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
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. 5-12. 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. 5-12 jsou stavy, kterými proces
prochází značeny vodorovnou čárou a popisem, kde např. S 3A 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
S1A
S1A
S2A
S2A
S3A
S4
A
Volání
procedury
Návrat z
procedury
a)
S3A
Vytvoř
proces B
S1P
S4A
S2P
S5A
S1B
S3P
S6A
S2B
S7A
S3B
Proces B
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
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 (P4)
Procespotomek rodič (P1)
Procespotomek (Q2)
Hlavní proces
(rodič)
Procespotomek (P2)
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
5.4 Komunikace a formy synchronizace mezi procesy
5.4.1 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
5.4.1.1 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é.
5.4.1.2 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. 5-14 je graficky znázorněna v předcházejícím textu popisovaná rozdílnost
mezi asynchronním a synchronním způsobem komunikace.
Proces A
Proces B
Proces A
Vyslání informace
(požadavek
synchronizace)
Čekání na
synchronizaci
Komunikace
Běh procesu B
Běh procesu A
a)
Proces B
Běh procesu B
Běh procesu A
Běh procesu A → → →
Vyslání
informace
67
b)
Obr. 5-14: a) Asynchronní způsob komunikace b) synchronní způsob komunikace
5.4.2 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.
5.4.2.1 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
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.
5.4.2.2 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
realizaci tohoto principu se používá řídící abstrakce, která se nazývá kritické sekce, více viz
kap. 5.4.8. Ta obsahuje zpravidla dvě části, mechanizmus přidělení a manipulace
s prostředkem a mechanizmus uvolnění prostředku.
5.4.2.3 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 5.4.2.1, 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.
5.4.3 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
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í.
5.4.3.1 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.
5.4.3.2 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. 5-15. 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
Postup
procesu B
Uvolni
tiskárnu
Uvolni
disk
Přiděl
disk
Přiděl
tiskárnu
Zakázaná oblast
Zakáza-
Zakáza-
ná oblast
ná oblast
Oblast
uváznutí
Zakáza-
ZakázaNebezpečná oblast ná oblast
ná oblast
Zakázaná oblast
Postupová cesta
(pro jednoprocesorový
systém)
Přiděl
disk
Přiděl Uvolni
tiskárnu 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
5.4.3.3 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).
5.4.3.4 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
 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í.
5.4.4 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. 5-16. 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
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
5.4.5 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
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éž.
5.4.6 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).
5.4.7 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. 5.4.4. V procesu
Producent vzniknou data (X) a proces má zájem je předat procesu Konzument procedurou
"vlož(X)", jak bylo uvedeno na Obr. 5-16. Tento problém můžeme doplnit o konstrukci
semaforu, jak je uvedeno na Obr. 5-17.
76
Proces Producent
Proces Konzument
S
(obsazený)
S
Sdílená
oblast
(obsazený)
(volný)
S=obsazený;
vlož (X);
S=volný;
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
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.
5.4.8 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
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).
5.4.9 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

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. 5-18 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 …
private …
define …
…
MODUL B
MODUL C
define Int A pervasive;
define Int B;
define procedure …
define Int C;
…
use Int C;
private
…
tělo modulu
...
private
…
tělo modulu
...
use Int A;
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
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. 5-20 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
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;
proces KONZUMENT
var X : DATA;
begin
.
.
POUŽITÍ_VYR_PAMĚTI . PŘIJMI (X);
ZPRACUJ (X);
.
.
end;
// použití procedury monitoru
// použití procedury monitoru
Obr. 5-20: Použití monitoru uvnitř procesů
5.4.10 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. 5-21 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
Proces A
Proces B
S1A
S1B
S2A
S2B
S3A
S4A
zpráva Z
objekt
I
S5A
S3B
S6A
S4B
Obr. 5-21: Komunikace obecným rendez-vous
5.4.11 Vyrovnávací paměti
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
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. 5.1.
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
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.
 Implementace
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
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í znalosti20. Š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. 6-1. 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,
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.
20
86
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
Blok
zprávy
Zpráva
Šifrátor
Bit klíče
Zašifrovaný
bit zprávy
Klíč
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. 6-3.
2)
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. 6-4. 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.
Strana A
Zpráva
Strana B
Zpráva
Privátní klíč
strany B (PKB)
Privátní klíč
strany A (PKA)
Veřejný klíč
strany A (VKA)
87
VKB
Šifrování
zprávy
Šifrovaná zpráva
Veřejný klíč
strany B (VKB)
Dešifrování
zprávy
Přenosový
kanál
PKB
Šifrovaná zpráva
Veřejný klíč
strany B (VKB)
Veřejný klíč
strany A (VKA)
Útočník
Obr. 6-3: Šifrování za pomocí asymetrické kryptografie – přenos zpráva od strany A k B
Strana A
Zpráva
Privátní klíč
strany A (PKA)
Veřejný klíč
strany A (VKA)
PKA
Privátní klíč
strany B (PKB)
Digitální
podpis
Digitálně
podepsaná
zpráva
Veřejný klíč
strany B (VKB)
Strana B
Zpráva
Ověření
podpisu
Přenosový
kanál
VKA
Digitálně
podepsaná
zpráva
Veřejný klíč
strany B (VKB)
Veřejný klíč
strany A (VKA)
Útočník
Obr. 6-4: Digitální podepsání zprávy od strany A k B, za pomocí asymetrické kryptografie
Zpráva
Zpráva
VKB
Šifrování
zprávy
Dešifrování
zprávy
PKA
Digitální
podpis
Ověření
podpisu
Strana A
Privátní klíč
strany A (PKA)
Veřejný klíč
strany A (VKA)
Veřejný klíč
strany B (VKB)
Digitálně
podepsaná a
šifrovaná zpráva
Přenosový
kanál
Digitálně
podepsaná a
šifrovaná zpráva
Strana B
PKB
Privátní klíč
strany B (PKB)
Veřejný klíč
strany B (VKB)
VKA
Veřejný klíč
strany A (VKA)
Ú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
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
6.4.1 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,2 × 10 16
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.
6.4.2 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,16 × 1077. 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.
6.4.3 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
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.
6.4.4 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.
6.4.5 RSA
Zkratka RSA vznikla taktéž z iniciál autorů algoritmu – pánové Rivest, Shamir
a Adleman a je z roku 1977. 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.
6.4.6 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
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.
6.4.7 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.
Otisky zpráv nebo souborů lze vytvářet prostřednictvím speciálního software nebo i online nástrojů, např.
http://www.fileformat.info/tool/hash.htm
21
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. 7-1. 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).
EIGRP
OSPF
eBGP
AS2
eBGP
eBGP
IS-IS
IS-IS
AS4
AS3
IS-IS
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
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
 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
AFI
DSP
IDI
Area
Proměnná délka (1 až 13 bajtů)
System ID
NSEL
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
Příklad na adresu typu NSAP (NET):
49.0001.1234.5678.9012.00
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
8 Doplňkové techniky doménového překladu
8.1 Multicast DNS
8.1.1 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 169.254.0.0/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
224.0.0.251 (nebo v IPv6 FF02::FB), cílový UDP port u tohoto protokolu je 5353. 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).
8.1.2 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
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.
8.1.3 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ě.
8.1.4 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.
8.1.4.1 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.
8.1.4.2 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 1.
8.1.4.3 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
8.1.4.4 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.
8.1.5 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í.
8.1.6 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 IPv6.
8.1.7 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
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 4795.
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
8.2.1 Překlad jména pomocí LLMNR
LLMNR dotazy jsou posílány a přijímány na portu 5355. Multicastová adresa v IPv4,
na které uživatelé poslouchají a na kterou se posílají i odpovědi, je 224.0.0.252. 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.
8.2.2 Základní pravidla formátování LLMNR zpráv
LLMNR je založeno na specifikaci DNS definované již v RFC 1035. 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.
8.2.3 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.
8.2.4 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
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
9 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í
100 – 90
4,5 – 4,3
Velká spokojenost
90 – 80
4,3 – 4,0
Spokojenost
80 – 70
4,0 – 3,6
Někteří uživatelé nespokojeni
70 – 60
3,6 – 3,1
Mnoho uživatelů nespokojeno
60 – 50
3,1 – 2,6 Téměř všichni uživatelé nespokojeni
50 – 0
2,6 – 1,0
Není doporučeno
102
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
10 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ří:
•
•
•
•
10.1
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.
10.2
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.
10.3
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
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
11 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-1541 . 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.
11.1
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. 11-1 je zobrazeno rozhraní a soubor bodů
interakce mezi poskytovatelem síťového připojení a koncovým uživatelem.
106
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
12 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. 12-1 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
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
1633.
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.
12.1.1 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
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
12.1.2 Referenční model IntServ
Na Obr. 12-3 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
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.
12.1.3 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.
12.2
111
Technologie Diferencovaných služeb (DiffServ)
Architektura IntServ využívající protokol RSVP pro rezervaci síťových zdrojů byla
dokončena v roce 1997. 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 2208.
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
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.
12.2.1 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. 12-5.
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
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.
12.2.2 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. 12-6. 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
Struktura DSCP značky je definována v RFC 2474. Díky kombinaci 6 bitů je možné
získat celkem 64 jedinečných identifikátorů udávaných ve formátu 𝑥𝑥𝑥𝑥𝑥𝑥, kde 𝑥 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
Standardní data
Třída provozu
(PHB)
DSCP
hodnota
Vzorová aplikace
EF
101110
IP telefonie
AF41
100010
AF42
100100
AF43
100110
AF31
011010
AF32
011100
AF33
011110
AF21
010010
AF22
010100
AF23
010110
AF11
001010
AF12
001100
AF13
001110
BE (výchozí)
000000
Videokonference
Audio a video streaming
Webové služby typu
klient-server
Webové služby typu
klient-server
Není specifikováno
12.2.3 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
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 000000. 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 𝑥𝑥𝑥000, kde 𝑥 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
111000 a 110000 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 2598. 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
Assured Forwarding PHB
AF (Assured Forwarding) PHB je definován v dokumentu RFC 2597. 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 AF𝑥𝑦, kde 𝑥 označuje třídu doručení (1 až 4) a 𝑦
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 AF31.
12.2.4 Referenční model DiffServ
Referenční model technologie DiffServ je definován v RFC 2475 a také v RFC 3290. 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. 12-7 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
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
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ěť.
12.2.5 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
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.
12.2.6 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
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. 12-9.
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. 12-10.
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.
Obr. 12-10:
121
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/𝑁. 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. 12-11.
Obr. 12-11:
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 𝑁 existujícím
frontám, plánovač automaticky nastaví pro každou frontu novou velikost propustnosti, která
bude odpovídat 1/(𝑁 + 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/𝑁 .
122
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. 12-12. 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
w
i 1
i
 100%,
(1)
kde 𝑚 je celkový počet tříd a 𝑤𝑖 je váhová hodnota přiřazená 𝑖-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 𝑁 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 𝑚 a druhý RR slouží pro obsluhu front uvnitř
dané třídy.
Obr. 12-12:
Algoritmus Weighted Round Robin
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. 12-13, 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. 12-13:
Algoritmus Weighted Fair Queuing
124
Seznam použité literatury
[1]
Dostálek, L.: Velký průvodce protokoly TCP/IP a systémem DNS, Computer Press,
Praha 2002.
[2]
Dostálek, L.: Velký průvodce protokoly TCP/IP: bezpečnost, Computer Press, Praha
2003.
[3]
Pužmanová, R.: TCP/IP v kostce, Kopp, České Budějovice, 2004.
[4]
Pužmanová, R.: Moderní komunikační sítě od A do Z, druhé aktualizované vydání.
Computer Press, Brno 2006.
[5]
Pužmanová, R.: Širokopásmový Internet: přístupové a domácí sítě, první vydání.
Computer Press, Brno 2004.
[6]
Halsall Fred, Computer networking and the Internet, Fourth edition, Addison-Wesley,
Edinburg, 2005.
[7]
Stallings, W.: Data and Computer Communication, Maxwell Macmillian International
Publishing Company, Fourth edition, London 1991.
[8]
Stallings, W.: Computer organization and architecture, 7th edition, Prentice Hall, New
Jersey, 2006.
[9]
Stallings, W.: High-speed network and Internet: performance and quality of service.
Prentice Hall, Upper Saddle River 2002.
[ 10 ] Norris, M.: Communications Technology Explained. John Wiley, United Kingdom,
2000.
[ 11 ] Morreale, P., Terplan, K.: The CRC Handbook of Modern Telecommunications, CRC
Press, New York 2001.
[ 12 ] Osterloh, H.: TCP/IP: kompletní průvodce: použitelný pro veškeré operační systémy.
SoftPress, Praha 2003.
[ 13 ] Odom, W., Knott, T.: Networking basics: CCNA1 companion guide. Cisco Press,
Indianapolis 2006.
[ 14 ] Odom, W., McDonald, R.: Routers and rating basics: CCNA2 companion guide. Cisco
Press, Indianapolis 2007.
[ 15 ] Lewis, W.: Switching basics and intermediate rating: CCNA3 companion guide. Cisco
Press, Indianapolis 2006.
[ 16 ] Reid, A.: WAN technologies, CCNA4 companion guide. Cisco Press, Indianapolis
2007.
[ 17 ] Droms, R.: DHCP příručka administrátora, Computer Press, Brno 2004.
[ 18 ] Loshin, P.: IPv6 theory, protokol, and practise. Morgan Kaufmann, San Francisco
2004.
[ 19 ] Stevens, W. R., Fenner, B., Rudoff, A. M.: Unix network programming. Vol. 1, the
sockets networking API, third edition. Addison-Wesley, Boston 2004.
125
[ 20 ] Stevens, W. R.: Unix network programming. Vol. 2, interprocess communications,
second edition. Prentice Hall, Upper Saddle River 1999.
[ 21 ] Reilly, D., Reilly, M.: Java network programming and distributed computing.
Addison-Wesley, Boston 2002.
[ 22 ] Evjen, B.: ASP.NET 2.0: programujeme profesionálně, první vydání. Computer Press,
Brno 2006.
[ 23 ] Troelsen, A.: C# a .NET 2.0 profesionálně, první vydání. Zoner Press, Brno 2006.
[ 24 ] Mollin, R. A.: An introduction to cryptography, second edition. Chapman & Hall,
New York 2007.
[ 25 ] Tanenbaum, A. S., Van Steen, M.: Distributed systems: principles and paradigms,
second edition. Pearson Education, Upper Saddle River 2007.
[ 26 ] Tanenbaum, A. S.: Computer Networks, first edition. Prentice Hall, New Jersey 2003.
[ 27 ] Tanenbaum, A. S.: Modern operating systems, first edition. Prentice Hall, New Jersey
2001.
[ 28 ] Taubenfeld, G.: Synchronization algorithms and concurrent programming. Pearson
Education, Harlow 2006.
[ 29 ] Wilkinson, B., Allen, M.: Parallel programming: techniques and applications using
networked workstation and parallel computers, second edition. Pearson Education,
Upper Saddle River 2005.
[ 30 ] Hughes, C., Hughes, T.: Parallel and distributed programming using C++. AddisonWesley, Boston 2004.
[ 31 ] Wilkinson, B., Allen, M.: Parallel programming, first edition, Prentice Hall, New
Jersey 1999.
[ 32 ] Satrapa, P.: IPv6: Internet Protocol verze 6, druhé vydání. Neocortex, Praha 2008.
[ 33 ] Conlan, J.P.: Cisco Network professional’s advanced internetworking guide. Wiley
Publishing, Hoboken 2009.
[ 34 ] Cole, E.: Network security bible, druhé vydání. Wiley Publishing, Indianopolis, 2009.
[ 35 ] Davies, J.: Understanding IPv6, druhé vydání. Microsoft Press, Redmont, 2008.
[ 36 ] Maufer, T. A.: Deploying IP multicast in the enterprise. Prentice-Hall, Upper Saddle
River, 1992.
[ 37 ] Stolarz, D.: Mastering internet video: a guide to streaming and on-demand video.
Addison-Wesley, Boston, 2005.
[ 38 ] Minoli, D.: IP multicast with applications to IPTV and mobile DVB-H, John Wiley,
Hoboken (USA), 2008.
[ 39 ] Dulaney, E. a kol.: MCSE Training Guide TCP/IP, New Riders Publishing,
Indianopolis (USA), 1997.
[ 40 ] Berg, G: MCSE Networking Essentials, second edition, New Riders Publishing,
Indianopolis (USA), 1998.
[ 41 ] Comer, D. E.: Internetworking with TCP/IP Vol.1: Principles, Protocols, and
Architecture, 4th edition, Prentice Hall, Upper Saddle River, 2000.
126
[ 42 ] Cheshire, S. Krochmal, M. RFC 6762: Multicast DNS. 2013. Dostupné z:
http://tools.ietf.org/html/rfc6762
[ 43 ] Aboba, B., Thaler, D., Esibov, L. RFC 4795: Link-Local Multicast Name Resolution.
2007. Dostupné z: http://tools.ietf.org/html/rfc4795
[ 44 ] FLANNAGAN, M. E. Administering Cisco QoS for IP Networks. Syngress
Publishing, 2001. ISBN 978-1928994213.
[ 45 ] WANG, Z. Internet QoS: Architecture and Mechanisms for Quality of Service.
Morgan Kaufmann, 2001. ISBN 978-1558606081.
[ 46 ] HOŠEK, J.; KOUTNÝ, M. Zabezpečení technologie VoIP pomocí protokolu
ZRTP. Elektrorevue - Internetový časopis (http://www.elektrorevue.cz), 2008, roč.
2008, č. 11, s. 1-11. ISSN: 1213-1539.
[ 47 ] SZIGETI, T., HATTINGH, C. End-to-End QoS Network Design: Quality of Service in
LANs, WANs, and VPNs. Cisco Press, 2004. ISBN 978-1-58705-176-0.
[ 48 ] ITU-T. Recommendation P.800: Methods for subjective determination of transmission
quality. ITU, 1996.
[ 49 ] VOZNAK, M., ZUKAL, D. Kvalita hovoru v prostředí VoIP. Cesnet, 2005.
[ 50 ] ITU-T. Recommendation G.107: The E-Model, a Computational Model for Use in
Transmission Planning. ITU, 2003.
[ 51 ] PARK, I. K. QoS in Packet Networks. Springer, 2005. ISBN 978-1441936226.
[ 52 ] MARCHESE, M. QoS Over Heterogeneous Networks. Wiley Publishing, 2007. ISBN
978-0470017524.
[53]
ADAMI, D., MARCHESE, M., RONGA, L. S. An applied research study for the
provision of a qos-oriented environment for voice and video services over satellite
networks. Computer Communications. 2002, roč. 25, s. 1113–1124. ISSN 0140-3664.
[54]
VELTE, J. T. Cisco: A Beginner’s Guide. McGraw-Hill, 2001. ISBN 9780071812313.
[55]
ITU-T. Recommendation
IPBasedService. ITU, 2003.
[56]
ETSI. Telecommunications and Internet Protocol Harmonization Over Networks TIPHON. ETSI, 1997.
[57]
ETSI. Satellite Earth Stations and Systems (SES). Broadband Satellite Multimedia IP.
IP Interworking over Satellite; Performance, Availability and Quality of Service - TR
102 157 V1.1.1. ETSI, 2003.
[58]
RÄISÄNEN, V. Implementing Service Quality in IP Networks. Wiley, 2003. ISBN
978-0470847930.
[59]
ITU-T. Recommendation E.860: Framework of a Service Level Agreement. ITU, 2002.
[60]
BRADEN, R., CLARK, D., SHENKER, S. RFC 1633: Integrated services in the
internet architecture: an overview. IETF, 1994.
[61]
BRADEN, R. a jiní. RFC 2205: Resource ReSerVation Protocol (RSVP) - Version 1
Functional Specification. IETF, 1997.
[62]
PEUHKURI, M. IP Quality of Service. Helsinki University of Technology, Laboratory
of Telecommunications Technology, 1999.
Y.1541:
Network
Performance
Objectives
for
127
[63]
HUSTON, G. Internet Performance Survival Guide: QoS Strategies for Multiservice
Networks. John Wiley & Sons, 2000. ISBN 978-0471378082.
[64]
MANKIN, A. a jiní. RFC 2208: Resource ReSerVation Protocol (RSVP) - Version 1
Applicability Statement Some Guidelines on Deployment. IETF, 1997.
[65]
CLARK, D., WROCLAWSKI, J. An Approach to Service Allocation in the Internet.
IETF, 1997.
[66]
NICHOLS, K., JACOBSON, V., ZHANG, L. A Two-bit Differentiated Services
Architecture for the Internet. IETF, 1999.
[67]
BLAKE, S. a jiní. RFC 2475: An Architecture for Differentiated Services. IETF, 1998.
[68]
HOŠEK, J.; KOUTNÝ, M. Simulation of QoS DiffServ Technology in Opnet
Modeler. In Proceedings of 31th International Conference on Telecommunications
and Signal Processing - TSP 2008. 1. Budapest: Asszisztencia Szervezo Kft., 2008. s.
1-6. ISBN: 978-963-06-5487- 6.
[69]
BABIARZ, J., CHAN, K., BAKER, F. RFC 4594: Configuration Guidelines for
DiffServ Service Classes. IETF, 2006.
[70]
RAMAKRISHNAN, K., FLOYD, S. RFC 2481: A Proposal to add Explicit
Congestion Notification (ECN) to IP. IETF, 1999.
[71]
RAMAKRISHNAN, K., FLOYD, S. RFC 3168: The Addition of Explicit Congestion
Notification (ECN) to IPIP. IETF, 2001.
[72]
NICHOLS, K. a jiní. RFC 2474: Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers. IETF, 1998.
[73]
BABIARZ, J., CHAN, K., BKAER, F. RFC 4594: Configuration Guidelines for
DiffServ Service Classes. IETF, 2006.
[74]
GIG, D. Proposed DSCP Strawman for Phase I. Version 10. DoD GIG QoS/CoS
Working Group, 2003.
[75]
HEINANEN, J. a jiní. RFC 2597: Assured Forwarding PHB Group IETF, 1999.
[76]
GROSSMAN, D. RFC 3260: New Terminology and Clarifications for Diffserv. IETF,
2002.
[77]
BERNET, Y. a jiní. RFC 3290: An Informal Management Model for Diffserv Routers.
IETF, 2002.
[78]
GEBALI, F. Analysis of Computer and Communication Networks. Springer, 2008.
ISBN 978-0387744360.
[79]
SHENKER, S., PATRIDGE, C., GUERIN, R. RFC 2212: Specification of Guaranteed
Quality of Service. IETF, 1997.
[80]
HEINANEN, J., GUERIN, R. RFC 2697: A Single Rate Three Color Marker. IETF,
1999.
[81]
HEINANEN, J., GUERIN, R. RFC 2698: A Two Rate Three Color Marker. IETF,
1999.

Obr. 5

Transkript

Podobné dokumenty

Učební texty Datové sítě V

Zpracování multimediálních dat pro integrovanou výuku VUT a

Studijní text - E-learningové prvky pro podporu výuky

Slovníku neologizmů 2

zde - Mediální studia / Media Studies

OFF5/2014 - off_festival

Angkor Wat

manuál ke službě - T

Úvod 21 Kapitola 1 Historie Internetu 25 Kapitola 2

PCI Express