Báječný svět počítačových sítí (www.earchiv.cz)Počítačové sítě nevznikly a nevyvíjí se ve vakuu, zcela izolovaně od ostatních sítí. Právě naopak, od svého vzniku soupeří zejména s telekomunikačními sítěmi, se kterými mají počítačové sítě na jedné straně mnoho společného, ale na druhé straně je dělí i řada odlišností. Oba druhy sítí se dnes snaží přenášet digitální data, ale každá to dělá poněkud jiným způsobem, a typicky také s jinými náklady.

Historicky přitom oba druhy sítí vychází z různých světů - ze světa spojů a světa počítačů - které se liší v řadě výchozích předpokladů, pohledů na své okolí i na potřeby svých uživatelů resp. zákazníků, i na celkové fungování sítí a jejich architekturu.

V dnešní době však jsme svědky výrazného trendu, kterému se říká konvergence. Spočívá v tom, že dříve oddělené světy spojů a počítačů stále více splývají (do tzv. elektronických komunikací), a v rámci toho dochází i ke konvergenci (splývání) počítačových a telekomunikačních sítí. Současně s tím dochází i ke konvergenci služeb, které jsou skrze tyto sítě poskytovány. Názorným příkladem je možnost telefonování po datových sítích (tzv. IP telefonie, resp. VOIP), televizní a rozhlasové vysílání po Internetu atd.

A nejen to, konvergence pokračuje i na "vyšších vrstvách" - dnes již konvergují (splývají) například i operátoři (poskytující telekomunikační služby) a provideři (poskytující internetové služby). Konvergovat začíná také přístup státu k oběma dosud odděleným oblastem. To se projevuje mj. tím, že místo dvou oddělených koncepcí (Státní informační politiky a Národní komunikační politiky) máme již jen jednu společnou politiku (Státní informační a komunikační politiku). V neposlední řadě máme i jedno společné (konvergované) ministerstvo - Ministerstvo informatiky ČR. Naše putování báječným světem počítačových sítí proto začneme právě srovnáním výchozí pozice počítačových a telekomunikačních sítí, a nastíněním hlavních koncepčních rozdílů mezi nimi.

Kolik je zdrojů?Klíčem k pochopení hlavních rozdílů mezi počítačovými a telekomunikačními sítěmi je docenění rozdílů mezi světem počítačů a světem spojů, odkud oba druhy sítí pochází.

Svět spojů je mnohem starší než svět počítačů. Vznikal v době, kdy nejrůznějších zdrojů, potřebných pro budování a provoz sítí, bylo málo a byly velmi drahé. Jednalo se zejména o přenosové kapacity v nejrůznějším provedení, kterých tehdy bylo opravdu málo. Problémem ovšem byla i malá "výpočetní kapacita" - třeba kapacita telefonních ústředen a jejich omezené možnosti. Prakticky všeho v telekomunikacích bylo tehdy málo, bylo to drahé, pomalé a nepružné. Proto se také dostupnost zdrojů stala hlavním limitujícím faktorem celkového rozvoje oboru. Obecně to lze shrnout do konstatování, že zájem zákaznické veřejnosti o telekomunikační služby se dlouhou dobu musel podřizovat dostupnosti těchto služeb.

Naproti tomu svět počítačů vznikal v době, kdy zdrojů již bylo podstatně více, a tyto brzy přestaly být hlavním limitujícím faktorem. Dnes se svět počítačů pyšní několika fundamentálními zákony, které popisují, jak rychle se objem dostupných zdrojů zvětšuje. Jde například o tzv. Mooreův zákon, který říká že výpočetní kapacita se zdvojnásobí každých 24 měsíců (podrobněji viz box). Nebo zákon Gilderův, který se týká přenosové kapacity a říká, že tato roste dokonce třikrát rychleji než kapacita výpočetní! Dnes ve světě počítačů spíše převažuje nabídka nad poptávkou, a limitujícím faktorem se stává schopnost něco prodat.

Za co se platí?

Ve světě spojů, který od svého vzniku zápasil s nedostatkem zdrojů, rychle zdomácněla praxe že zákazník platí podle toho, kolik zdrojů je mu dáno k dispozici - bez ohledu na to, jak hodně či málo mu poslouží a jaký efekt a užitek mu přinesou. Dodnes je tato praxe k vidění například v telefonní síti, kde volající platí podle počtu provolaných minut. Naproti tomu ve světě počítačů se již vychází z jiného principu zpoplatnění. Zákazník zde platí spíše podle toho, co skutečně "zkonzumuje", resp. jaký přínos mu poskytnutá služba přináší, jaký má pro něj efekt, přínos atd. Konkrétních možností je více, příkladem může být zpoplatnění podle objemu skutečně přenesených dat. Další možností světa počítačů je paušální způsob zpoplatnění, kdy koncový uživatel platí pevnou cenu, bez ohledu na to, co "zkonzumuje". To ale neznamená přesné napodobení "švédských stolů", resp. principu "sežer co

můžeš". Paušálně stanovená cena totiž vždy vychází z určitého předpokladu o průměrném chování zákazníka - a pokud by se významná část reálných zákazníků chovala jinak, poskytování služby by se velmi brzy stalo nerentabilním.

Pokud takovéto nebezpečí reálně hrozí, poskytovatelé služeb se snaží vynutit si na zákaznících "předpokládané chování". Děje se tak skrze zavádění různých Fair Use Policy (pravidel korektního využití), které nejčastěji spočívají v zavedení konkrétních objemových limitů u paušálně zpoplatněných služeb. Tedy limitů na objem dat, které je možné přenést za určité časové období.

Vyhrazení zdrojů ve světě spojů

Jestliže svět spojů vznikal v době, kdy zdrojů bylo opravdu málo, pak by bylo na místě předpokládat, že se s nimi bude hospodařit šetrně a efektivně. Tedy například že jednotlivým zákazníkům (uživatelům) bude přidělováno právě a pouze tolik zdrojů, kolik v daném okamžiku skutečně potřebují - a pokud právě nic nepotřebují, nebude jim přiděleno nic (a oni za to také nebudou muset platit).

Bohužel opak je pravdou. Důvody k tomu je třeba hledat ve skutečnosti, že ještě dlouho po vzniku světa spojů nebyly k dispozici vhodné mechanismy, které by něco takového umožnily. Proto se ve světě spojů a telekomunikačních sítí zavedla jiná praxe: uživatelům se vždy přidělí určitý fixní objem zdrojů. Je pak na nich, jak je využijí - zda "hodně, "málo" či dokonce "vůbec". Platit však budou stejně, viz již zmíněný příklad s minutovou cenou hovorného v telefonní síti. Ta je zcela nezávislá na tom, zda účastníci skutečně hovoří nebo na sebe mlčí.

Důležité je také to, že fixní objem zdrojů se ve světě spojů přiděluje výlučně konkrétnímu zájemci, resp. se pro něj vyhrazuje. To je na jedné straně pozitivní v tom, že pro dotyčného zákazníka je dostupnost těchto zdrojů garantována (může se spolehnout na to, že je má k dispozici).

Telekomunikační sítě tedy typicky poskytují služby s garantovanými parametry. Na druhou stranu je to negativní v tom, že vyhrazené ale fakticky nevyužité zdroje již nemohou být přenechány nikomu jinému (a je to tudíž neefektivní hospodaření s těmito zdroji). Nevýhodné je pro zákazníka i to, že musí platit za objem vyhrazených zdrojů, a tedy za maximum toho, co může potenciálně využít - a nikoli za to co skutečně využívá. To dále zvedá cenu koncových služeb ve světě spojů. Dodnes je tento přístup patrný na vytáčeném připojení k Internetu (tzv. dial-upu): je úplně jedno, zda připojený uživatel internetu právě něco přenáší či nikoli. Za své připojení platí stále stejně (podle minut), a stále blokuje linku, přes kterou se nemůže k Internetu připojit nikdo jiný. Pravdou je také to, že svět spojů od začátku využíval cenu také jako prostředek regulace poptávky. Ta většinou výrazně převyšovala nabídku, a právě zvyšováním ceny poskytovatelé dokázali poptávku efektivně snižovat.

Princip přepojování okruhů

Po technické stránce se právě popsaný způsob hospodaření se zdroji ve světě spojů realizoval a stále realizuje prostřednictvím tzv. přepojování okruhů (anglicky: circuit switching). Okruhem se rozumí obousměrná přenosová cesta mezi dvěma body, s určitou konkrétní kapacitou. V rámci jednoho přenosového média (například koaxiálního kabelu, optického vlákna apod.) může být vytvořeno více takovýchto přenosových okruhů, resp. jejich dílčích úseků, s tím že každému je pevně vyhrazena určitá přenosová kapacita. Tam, kde se přenosová média "scházejí" (v přepojovacích uzlech) dochází k potřebnému pospojování (propojení) úseků jednotlivých okruhů, způsobem který naznačuje následující obrázek. Výsledný efekt je takový, jako kdyby celý okruh vůbec nebyl přerušený, ale byl naopak souvislý, procházel příslušným přepojovacím uzlem a pokračoval dále. Po celé své "trase" tak má vždy stejnou "šířku" (vyhrazenou kapacitu).

Představa přepojování okruhů

Příkladem sítě, která funguje na právě popsaném principu, je již zmiňovaná telefonní síť. Roli přepojovacích uzlů, které zajišťují vlastní přepojování okruhů, zde hrají telefonní ústředny. Každý přenosový okruh v telefonní síti je využit pro přenos jednoho telefonního hovoru. Vzniká (je tzv. sestaven, příslušným propojením na ústřednách) s vytočením čísla volaného, existuje a je zpoplatněn po celou dobu trvání hovoru, bez ohledu na aktivitu jeho účastníků (zda právě hovoří či nikoli), a je zrušen s ukončením (zavěšením) hovoru.

V analogové telefonní síti měl každý takovýto okruh šířku 3,1 kHz, v dnešní digitální telefonní síti pak rychlost 64 kbit/s. Jen pro dokreslení efektivnosti, resp. neefektivnosti: v mobilních sítích lze vystačit s přenosovou rychlostí 12 až 13 kbit/s, s nezhoršenou kvalitou přenosu hovoru, a v rámci tzv. IP telefonie i s rychlostí ještě nižší.

Výhody a nevýhody přepojování okruhů

Předností přepojování okruhů je již popisovaná garance přenosové kapacity. Ta je pro celý okruh a po celou dobu jeho existence skutečně vyhrazena právě a pouze pro tento okruh. Současně je to ale i nevýhoda - pokud není takto vyhrazená kapacita fakticky využita, nemůže být přepuštěna (přenechána) někomu jinému. Dalším charakteristickým rysem je to, že data přenášená přes takovýto okruh se nikde "nezdržují". Nikde se totiž po cestě neukládají, a tak je doba jejich přenosu dána v zásadě jen dobou šíření signálu skrze příslušné médium. Tato doba bývá velmi krátká, a hlavně předem odhadnutelná a konstantní. To má velký význam pro přenos multimediálních dat (právě hlasu a obrazu), které velmi dbají na pravidelnost a rychlost doručování svých dat.

Sdílení kapacit a přepojování paketů

Zatímco ve světě spojů se přenosové kapacity vyhrazují a přidělují do výlučného využití, a děje se tak skrze právě popsané přepojování okruhů, ve světě počítačů se přenosové kapacity spíše sdílí. To se realizuje zejména skrze tzv. přepojování paketů (anglicky: packet switching). Sdílení přenosových kapacit je vhodné chápat tak, že nikdo zde nedostává žádnou přenosovou kapacitu jen pro sebe, k výlučnému využití (tj. není nikomu vyhrazena). Nedochází zde tedy k trvalejšímu dělení přenosové kapacity, tak jako u přepojování okruhů, ale tato kapacita je ponechána "v celku". Každý zájemce o využití této kapacity pak svým způsobem soupeří s dalšími zájemci, kteří také chtějí využít stejnou přenosovou cestu k přenosu svých dat. Má-li takovéto sdílení fungovat, nesmí dojít k "promíchání" dat od různých odesilatelů v rámci téže (nerozdělené) přenosové cesty. Proto každý odesilatel musí svá data vhodně "zabalit", do balíčku kterému se nejčastěji říká paket. Tento paket musí opatřit adresou příjemce (a také svou, coby odesilatele), a pak předat k odeslání skrze vhodnou přenosovou cestu. U přepojování okruhů takováto povinnost není a data zde nemusí být "balena" do paketů (i když mohou). Jejich příjemcem je totiž vždy "ten, kdo je na druhém konci okruhu". U přepojování paketů je tomu jinak a každý paket musí obsahovat nějakou identifikaci svého příjemce.

Představa přepojování paketů

Mechanismus Store&Forward

Zpět ale k samotnému přepojování paketů: každá přenosová cesta se vždy naplno (celou svou kapacitou) věnuje přenosu jednotlivých paketů, v takovém pořadí, v jakém jí jsou předkládány. Takováto přenosová cesta přitom již může ústit do cílového uzlu, kam některé pakety směřují. Jindy tomu tak ale není, a přenosová cesta ústí jen do dalšího přepojovacího uzlu (v praxi např. do tzv.směrovače), do kterého mohou vstupovat ještě i další přenosové cesty, a stejně tak z něj další přenosové cesty zase vystupují. V tomto přepojovacím uzlu pak dochází k vlastnímu "přepojování paketu" - k jejich přijímání z jednoho směru, k rozhodnutí o jejich dalším směrování, a k následnému předání k dalšímu přenosu v takto zvoleném (odchozím) směru. Detailnější představu ukazuje následující obrázek (č. 3.), na kterém je znázorněno fungování příslušných přepojovacích uzlů, zajišťujících přepojování paketů. Jde o princip, označovaný jako store&forvard.

Představa mechanismu store&forward

Přepojovací uzel, fungující na tomto principu, nejprve každý přijatý paket uloží do vstupní vyrovnávací paměti (tzv. vstupního bufferu, resp. vstupní fronty). Odsud také ono "Store" v jeho názvu (z anglického "uložit"). Přepojovací uzel, resp. jeho interní procesor (CPU) pak postupně vybírá jednotlivé pakety ze vstupních front, rozhoduje se jak s nimi naložit (kterým směrem je předat dál, případně zda je např. nezahodit), a pak toto své rozhodnutí naplňuje. Pokud již vybral určitý odchozí směr, uloží paket do výstupní fronty, spojené s tímto odchozím směrem. Zde pak paket čeká, než na něj dojde řada (vzhledem ke kapacitním možnostem přenosové cesty v odchozím směru), a následně je skutečně odeslán (předán dál, anglicky: "forwarded", odsud druhá část názvu tohoto způsobu fungování).

Přenosové zpoždění a jeho rozptyl

Doba, kterou trvá přenos dat na principu přepojování paketů, je vždy větší, než u přepojování okruhů. Je to dáno tím, že data přenášená ve formě paketů se po cestě různé ukládají (do vyrovnávacích pamětí, resp. front v přepojovacích uzlech), a zde čekají na své další zpracování. Naproti tomu u přepojování okruhů se data takto nikde neukládala (a ani nemusela být "balena" do paketů, a mohla být přenášena i po jednotlivých bytech). Nepříjemné je také to, že nelze dopředu určit, jak dlouho se ten který paket zdrží v přepojovacím uzlu. To totiž nezáleží jenom na něm, resp. na jedné dvojici komunikujících stran, které si navzájem posílají nějaké počty paketů. Vzhledem ke sdílení přenosových cest (i přepojovacích uzlů) zde obecně záleží i na ostatních přenosech, neboli na tom, jak intenzivně či naopak málo intenzivně spolu komunikují jiné uzly. Z pohledu jedné komunikující dvojice je proto nutné považovat dobu přenosu (skrze síť s přepojováním paketů) spíše za statistickou, ne-li přímo náhodnou veličinu.Uživatelé Internetu to často pociťují na vlastní kůži, asi nejvíce při brouzdání WWW stránkami. Někdy totiž přitékají rychleji, a jindy zase mnohem pomaleji - podle toho, jak moc či málo právě "stahují" či "odesílají" ostatní uživatelé.

Míra sdílení, agregace

Sdílení, ke kterému dochází v sítích s přepojováním paketů, má velkou výhodou v efektivnějším hospodaření s přenosovými kapacitami i dalšími zdroji. Projevuje se to i v odlišném přístupu ke zpoplatnění zákazníka: zatímco v sítích s přepojováním okruhů zákazník platí za to, co je mu potenciálně dostupné (co je mu vyhrazeno, bez ohledu na využití), v sítích s přepojováním paketů platí za to, co aktuálně využívá. Důsledkem jsou mnohdy výrazně nižší ceny, což lze dokumentovat třeba na rozdílu cen za telefonování přes klasickou telefonní síť a po Internetu.

Celá věc má ale jeden háček. Velmi totiž záleží i na míře sdílení, neboli na tom, kolik aktivních uživatelů se právě dělí o jednu společnou přenosovou kapacitu. Pokud jich je "rozumně" málo, pak žádný z nich nepociťuje nějaké významnější dopady sdílení. Pokud jich je ale příliš mnoho, už se navzájem omezují a toto omezení mohou pociťovat dosti zásadním způsobem.

Lze to připodobnit k využití silnic. Princip přepojování okruhů by odpovídal situaci, kdy každé auto (či spíše každá autobusová linka apod.) má pro sebe vyhrazen jeden jízdní pruh, kterým nesmí jezdit nikdo jiný. Něco takového je ale nesmírně nákladné. Princip přepojování paketů naopak odpovídá tomu, že všechna auta jezdí po jedné společné silnici (bez ohledu na počet pruhů). Pokud je poměr počtu aut k počtu a délce silnic odpovídající, pak nedochází k výraznějším dopravním zácpám. Běda ale, jak tento poměr příliš naroste - pak vznikají samé zácpy, doprava se zpožďuje, a může dojít až k úplnému zahlcení.

Stanovení "odpovídajícího" poměru přitom není jednoduché ani u silnic, ani u sítí s přepojováním paketů. U silnic záleží zejména na tom, kolik je aut a jak moc s nimi lidé jezdí. V případě sítí záleží jak na počtu uživatelů, tak i na jejich chování.

Konkrétním příkladem, kde se míra sdílení (často označovaná také jako stupeň agregace) projevuje velmi významně, jsou vysokorychlostní přípojky k Internetu, a z nich asi nejvíce přípojky na bázi ADSL. Ty, které jsou určeny pro domácnosti, mají obvykle agregaci 1:50. Pro spíše příležitostné využití koncovými uživateli to vcelku postačuje, ale při intenzivnějším využívání (například při pravidelném stahování z výměnných sítí) už nikoli. Poskytovatelé příslušných služeb proto začali na těchto přípojkách uplatňovat dosti striktní Fair Use Policy (viz výše), právě proto aby příslušným způsobem ovlivnili chování uživatelů.

I přes tato opatření naše ADSL přípojky vykazují v praxi dosti nízkou propustnost. Tzv. efektivní (skutečně dosahovaná) přenosová rychlost se pohybuje jen někde kolem 50 až 60 procent rychlosti nominální, neboli té, kterou uvádí poskytovatel služby (a myslí to jako rychlost "maximální", byť to tak mnohdy neříká).

Maximální snaha, vs. kvalita služeb

Služby telekomunikačních sítí, které fungují na principu přepojování paketů, jsou na jedné straně sice výrazně dražší, ale na straně druhé mají garantovanou úroveň kvality - ať již jde o celkovou propustnost, či o přenosové zpoždění a jeho rozptyl. Lze se na to dívat také tak, že každému (přenosu) dají to, oč si řekne a co si také zaplatí.

Naproti tomu lacinější sítě s přepojováním paketů využívají sdílení, a díky tomu dokáží být (i výrazně) lacinější. Platí za to ovšem daní v podobě toho, že jejich služby nemají garantovanou kvalitu. Ta se mění v závislosti na celkové zátěži. Není přitom vyloučeno není ani to, že některé požadavky na přenos paketů vůbec nebude možné uspokojit, a příslušné pakety pak bude nutné zahodit.

Pokud už k takovéto situaci dojde, a nějaký paket musí být zahozen, je "oběť" vybírána víceméně náhodně. Sítě na principu přepojování paketů totiž standardně nerozlišují různé přenosy mezi sebou, v tom smyslu že by některým dávaly přednost před jinými. V rámci sdílení se ke všem chovají stejně, a totéž platí i v kritických situacích - pakety k zahození se pak také vybírají rovnoměrně, bez ohledu na to, komu patří.

V praxi se takovýto způsob fungování označuje jako princip "maximální snahy" (anglicky: best effort): dokud na to dostupné zdroje stačí, jsou všechny požadavky uspokojovány stejně a v úplné míře. Síť se tedy snaží, jak jen může. Jakmile ale dostupné zdroje přestávají stačit, musí dojít ke krácení - a všem přenosům je opět kráceno stejně (v tom smyslu, že pakety k zahození se vybírají bez ohledu na to, komu patří). Alternativou k principu maximální snahy je takový přístup, kdy se rozlišují různé druhy přenosů, a podle toho je s nimi také různě nakládáno. Může to být zařízeno třeba tak, že existuje několik úrovní priority, a přenosy na vyšší úrovni priority mají vždy přednost před přenosy na nižší úrovni. Takže když se pak přestane dostávat nějakých zdrojů, jsou přednostně kráceny přenosy na nižší úrovni priority. Nebo to může být zařízeno tak, že určité konkrétní přenosy mají skutečně garantované podmínky, obdobně jako u přepojování okruhů. Obecně se tento přístup označuje jako zajištění kvality služeb, zkratkou "QoS" (z anglického: Quality of Service). V praxi má častěji podobu "různé kvality služeb pro různé druhy přenosů", než garantovaných parametrů přenosu. Konkrétním příkladem z praxe mohou být již zmiňované Fair Use Policy, uplatňované u některých ADSL přípojek. Některé z nich jsou řešeny tak, že když uživatel přečerpá svůj datový limit, všechny jeho přenosy získají nižší prioritu a musí tak dávat přednost přenosům ostatních uživatelů. Většinou se to projeví výrazným poklesem propustnosti (efektivní rychlosti), mnohdy až k nepoužitelnosti. Alternativou je to, že zákazník si za nadlimitní data připlatí, a ta se pak přenáší s původní prioritou.

Spolehlivé a nespolehlivé přenosy

S principem maximální snahy i kvalitou služeb souvisí také otázka toho, jak má přenosová část sítě zareagovat, když dojde k poškození, úplné ztrátě či dokonce k zahození nějakého paketu. V takovéto situaci existují dvě základní možnosti: postarat se o nápravu, typicky vyžádáním si opakovaného zaslání poškozeného (ztraceného) paketu. Tato varianta bývá označována jako spolehlivý přenos. nechat to být a pokračovat dál. Tato varianta se označuje jako nespolehlivý přenos. Při posuzování spolehlivosti je vhodné si uvědomit, že ji lze zajistit na různých úrovních. Mohou si ji například zajistit až jednotlivé aplikace, které asi nejlépe ví, které části dat skutečně potřebují a které naopak mohou postrádat. Stejně tak ale může být spolehlivost zajišťována již přenosovou částí sítě.

Zajímavé je, že telekomunikační sítě ze světa spojů obvykle zajišťují spolehlivost, bez ohledu na to, zda ji aplikace požadují či nikoli. Naopak přenosové sítě ze světa počítačů buď fungují nespolehlivě (v tom smyslu, že se nestarají o nápravu), nebo dávají aplikacím vybrat, zda spolehlivost chtějí nebo nechtějí. Není totiž těžké si domyslet, že se zajištěním spolehlivosti je spojena určitá časová i další režie, nutná na opakovaný přenos ztracených či poškozených dat. To pak zhoršuje (zvyšuje) jak přenosové zpoždění, tak i pravidelnost doručování. Multimediálním přenosům, jako například přenosu hlasu a obrazu, přitom občasná ztráta či poškození nějakých dat vadí podstatně méně, než nepravidelnost jejich doručování. Například u přenosu hlasu (telefonování) se obvykle uvádí, že i při ztrátě až 20 procent dat je přenášený hovor stále ještě dostatečně srozumitelný. Naopak při zvýšení přenosového zpoždění nad 400 až 500 milisekund přestává být služba použitelná, kvůli příliš dlouhé prodlevě. Lidé si pak začínají skákat do řeči, v domnění že druhá strana nic neslyšela nebo vůbec nereaguje.

Požadavky aplikací

Obecně lze říci, že různé aplikace a služby mají různé požadavky na přenosovou část sítě (viz tabulka). Například přenosu souborů či elektronické poště vyhovuje chování sítě na principu maximální snahy (best effort), a nevadí jim ani vyšší přenosové zpoždění. Stejně tak pro ně

nehraje roli ani pravidelnost doručování jednotlivých paketů, protože stejně čekají až na ten poslední (v rámci daného souboru či zprávy). O to více pak dokáží ocenit efektivnost datových přenosů, ve smyslu nízkých nákladů - a proto jim plně vyhovují sítě s přepojováním paketů, fungující na principu maximální snahy, bez podpory kvality služeb. Příkladem takové sítě může být celosvětový Internet.

Naproti tomu multimediální přenosy (hlavně přenosy hlasu a obrazu) jsou na celkové zpoždění o pravidelnost doručování velmi citlivé. Nejlépe jim dokáží vyhovět sítě fungující na principu přepojování okruhů - což je další z důvodů, proč se tyto sítě historicky tak ujaly ve světě spojů. Sítě s přepojováním paketů, fungující na principu maximální snahy (best effort) jim naopak moc nevyhovují.

Konvergované sítě a přístup hrubou silou

Dnešní konvergence světa spojů a světa počítačů směřuje k tomu, aby se používaly pouze sítě fungující na principu přepojování paketů, nejlépe jen na principu maximální snahy (best effort). Tedy takové sítě, jako celosvětový Internet. To, že příliš nevychází vstříc potřebám některých aplikací, hlavně pak multimediálních, lze řešit podporou kvality služeb (QoS) v těchto sítích. To je možné, a existují na to i dostupné standardy, specifikující jak to dělat. Problém je ale v tom, že je to hodně nákladné, málo efektivní, a také organizačně nesmírně náročné - pokud by se to mělo dělat v něčem tak rozsáhlém, jako je dnešní Internet. Proto se v praxi uplatňuje spíše jiný přístup, který by bylo možné označit jako "přístup hrubou silou". Spočívá v tom, že se "hodně nafouknou" (předimenzují) příslušné zdroje, hlavně přenosové kapacity těchto sítí, tak aby co nejvíce snížila četnost stavu, kdy už tyto zdroje dochází a je třeba některé přenosy omezovat. Kupodivu je to jednodušší, schůdnější, a často i lacinější, než "dokonalé" řešení v podobě podpory kvality služeb.

Kritérií, podle kterých je možné "škatulkovat" počítačové sítě, neboli rozdělovat je do různých skupin, tříd či typů, existuje celá řada. Může to být například kritérium vlastnictví sítě: podle něj se pak počítačové sítě rozpadají na veřejné, privátní, a různě poloprivátní a poloveřejné. Pokud nás bude zajímat hlavně jejich dosah, rozdělí se na sítě lokální (LAN, Local Area Network), na sítě rozlehlé (WAN, Wide Area Network), a třeba také na sítě metropolitní (MAN, Metropolitan Area Network), či na sítě PAN (Personal Area Network). Ještě další kritérium, beroucí do úvahy účel provozování sítě, zase vede k dělení na intranet (pouze pro potřeby interního fungování), na extranet (pro fungování směrem ven) atd. Takovýchto kritérií bychom mohli vymyslet celou řadu - a záhy se k některým dalším skutečně dostaneme. Měli bychom ale mít na mysli, že tato kritéria jsou na sobě do značné míry nezávislá, a vedou k různému dělení. Třeba dvě různé sítě mohou být obě rozlehlé (WAN), ale jedna z nich bude privátní a druhá veřejná. Nebo dva intranety: jeden z nich může být malou lokální sítí, a druhý, patřící velké nadnárodní firmě, může mít charakter rozlehlé sítě, rozkládající se po několika kontinentech. Navíc ani nemusí být sítí ve fyzickém slova smyslu, ale

pouze sítí virtuální (může být tzv. virtuální privátní sítí, využívanou jako intranet). Virtuálnost či skutečně fyzický charakter sítě jsou dalším kritériem, kterým se budeme zabývat.

Ještě jednu nepříjemnou věc si ale musíme říci hned v úvodu. Jde o to, že většina kritérií pro dělení sítí nemá úplně exaktní charakter a nemusí vést na jednoznačné rozdělení sítí do té či oné škatulky. Vezměme si třeba kritérium dosahu. U sítě, provozované v malé kanceláři či dokonce v bytě, asi nikdo nebude pochybovat o tom, že jde o síť lokální (síť LAN). Naopak, u sítě které pokrývá celé kontinenty, je jasné že jde o síť rozlehlou (síť WAN). Ale kde je hranice mezi lokální a rozlehlou sítí? Kde přesně leží? Co třeba síť pokrývající celé město - je ještě lokální, nebo již rozlehlá?

Někdo se tento problém snažil řešit zavedením samostatné kategorie: sítí metropolitních. Tím se ale celý problém jen zdvojnásobil: kde potom leží hranice mezi lokální a metropolitní sítí, a kde mezi sítí metropolitní a sítí rozlehlou?

Sítě LAN a WAN, MAN a PAN

S dělením sítí na lokální (LAN, Local Area Network) a WAN (Wide Area Network) jsme se vlastně již seznámili, s tím že jde o dělení na základě dosahu sítě. Mezi sítěmi LAN a WAN však existují i další charakteristické rozdíly, jako například rozdíly v přenosové rychlosti (bývá i řádově vyšší u lokálních sítí než u rozlehlých), či v přenosovém zpoždění (což je dáno dobou šíření signálu nesoucího data), v topologii (u lokálních sítí bývá systematická, u rozlehlých naopak nesystematická), ve vlastnictví přenosové infrastruktury ("drátů") atd.

Kde leží hranice mezi sítěmi LAN a WAN? Tvoří ji sítě MAN? A kde začíná a kde končí MAN?

Zmínili jsme se také o tom, že na hranici mezi sítěmi lokálními a rozlehlými se nachází sítě metropolitní (MAN, Metropolitan Area Network), typicky pokrývající nějaké město (metropoli, odsud také jejich název). Vedle sítí WAN, MAN a LAN pak ještě existuje jedna zavedená zkratka, která ale již tak dobře nezapadá do členění "podle dosahu". Jde o sítě PAN, alias: Personal Area Network, čili "osobní sítě". Jejich dosah bývá velmi malý, maximálně několik málo metrů, ale podstatné je pro ně spíše to, že slouží potřebám jednotlivce, případně velmi malé skupiny uživatelů. Nejčastěji propojuje mobilní zařízení (například různá PDA, notebooky, mobilní telefony), a umožňuje jim vzájemně komunikovat. Mezi technologie, které takovéto propojení zajišťují, patří zejména Bluetooth, Wi-Fi, IrDa, DECT, a z drátových pak USB.

Představa sítě PAN (Personal Area Network)

internet a Internet

Zajímavým a důležitým trendem je ale to, že z pohledu uživatelů se rozdíl mezi lokálními, metropolitními a rozlehlými sítěmi postupně vytrácí, s tím jak tyto sítě začínají splývat. Toto splývání je nejčastěji zapříčiněno tím, že lokální sítě již nejsou izolované a zcela oddělené od ostatních sítí a okolního světa. Právě naopak, většina lokálních sítí se dnes propojuje mezi sebou, buďto přímo nebo přes jinou síť, kterou může být i síť rozlehlá. Výsledkem pak je větší či menší soustava vzájemně propojených sítí (anglicky: "internetwork", zkráceně "internet"), jejíž vnitřní struktura bývá pro uživatele nepodstatná. Uživatel si může celou soustavu sítí představit jako jakýsi homogenní oblak, ke kterému se může připojit kdekoli a výsledek bude (v principu) vždy stejný - uživatel bude mít k dispozici stejné možnosti a služby.

Dobrým příkladem může být jedna konkrétní soustava vzájemně propojených sítí, neboli jeden konkrétní internetwork alias internet - ten celosvětový, který se dokonce jmenuje Internet. Jelikož je to jeho vlastní jméno, je vhodné jej rozlišit velkým počátečním písmenem od druhového jména internet, které označuje obecně jakoukoli soustavu vzájemně propojených sítí. Pravdou ale je, že dnes už velká část našich médií obě jména nerozlišuje, a i pro celosvětový Internet používá malé počáteční písmeno.

Páteřní sítě, přístupové sítě, místní smyčky

Také dnešní Internet (ten celosvětový, s velkým počátečním I) lze připodobnit k velkému oblaku, jehož vnitřní strukturu uživatelé nemusí vůbec znát. Mohou se k němu připojit v zásadě kdekoli, s tím že efekt tohoto připojení bude v principu vždy stejný - uživatelé získají stejné možnosti, stejné postavení, jsou jim dostupné stejné služby. Platí to ale obecně, s tím že v konkrétních případech to přeci jen nemusí být všude stejné. Podle místa a způsobu připojení se může lišit například dostupná přenosová rychlost, dostupnost některých služeb (daná např. existencí a nastavením firewallů) atd.

I když si uživatel nemusí nijak uvědomovat vnitřní strukturu Internetu, případně jiné soustavy vzájemně propojených sítí ke které je připojen, přesto zde určitá charakteristická vnitřní struktura většinou existuje. S určitým zjednodušením si ji lze představit podle následujícího obrázku jako "třípatrovou" konstrukci, složenou z:páteřní sítě, propojující několik málo ústředních lokalit "střední" sítě (propojovací sítě) přístupové sítě, rozvedené až do lokalit kde se vyskytuje koncový zákazník.

Představa tří úrovní v rámci rozlehlých sítí

Pro lepší představu si to můžeme zkonkretizovat na dvou příkladech. Prvním je veřejná telefonní síť Českého Telecomu, která má celkem 8 tzv. tranzitních ústředen. Ty jsou mezi sebou propojeny, a toto jejich propojení tvoří páteřní síť. Dále má Český Telecom na 142 tzv. místních ústředen, které jsou na tranzitní ústředny napojeny prostřednictvím "střední" sítě. Z místních ústředen pak vychází jednotlivá účastnická vedení (tzv. místní smyčky), vedoucí až do místa, kde se nachází zákazník. Tato účastnická vedení pak dohromady vytváří tzv. přístupovou síť. Ta by měla být co možná "nejhustší", aby dokázala "rozvést" telefonní služby k co nejvíce zákazníkům, kamkoli by oni mohli potřebovat.

Představa struktury veřejné telefonní sítě

V konkrétním případě telefonní sítě Českého Telecomu je její přístupová část (přístupová síť) místy ještě dále strukturována, když místní smyčky nevychází bezprostředně z telefonních ústředen, ale z jakýchsi "předsunutých ústředen" (jednotek RSU, Remote Subscriber Unit), které jsou na samotné ústředny připojeny nejčastěji optickým kabelem.Jako další příklad si můžeme ukázat vnitřní strukturu Internetu. I ten má páteřní část, která se fyzicky nachází v zámoří, a tvoří ji hned několik na sobě nezávislých páteřních sítí, propojených "výhybkami" (propojovacími body NAP). Na tyto páteřní sítě jsou napojeny, ve "střední části", sítě jednotlivých internetových providerů (tzv. ISP, Internet Service Provider), které bývají ještě hierarchicky "navěšeny" jedna na druhou. Jeden provider je tak napojen na jiného providera, a skrze něj přenáší svůj datový provoz do páteřních částí Internetu (pokud ovšem nevyužije tzv. peering, spočívající v přímém propojení sítí jednotlivých providerů, viz obrázek).

Představa vnitřní struktury dnešního Internetu

První a poslední míle

Na obou uvedených příkladech si můžeme také názorně ukázat, čemu se v praxi říká poslední míle (anglicky: last mile). Jde vlastně o úsek, který má za úkol překlenout přístupová síť - tedy úsek mezi místem, kde končí síť internetového providera (resp. telefonní ústředna), a místem kde se vyskytuje zákazník. Přívlastek "poslední" si tento úsek vysloužil kvůli pohledu ze strany provozovatelů sítí, resp. poskytovatelů služeb, kteří své páteřní sítě považují za začátek (někdy označovaný také jako "první míle"). Úsek, končící u zákazníka, jim pak skutečně musí vycházet jako "poslední míle". Naopak, při opačném pohledu (očima zákazníka), by se místo "poslední míle" mělo jednat spíše o "první míli". Ale obvyklá praxe je taková, že u zákazníka (uživatele, účastníka či jak jinak jej označíme) končí "poslední míle", a nikoli "první míle". Proto se také hovoří o problému překlenutí poslední míle, který je asi největším oříškem například při rozvoji širokopásmového přístupu (broadbandu). Pro jednotlivé internetové providery (ISP) není až tak těžké vybudovat jejich sítě, a napojit je na ostatní sítě, které dohromady tvoří celosvětový Internet. Nejtěžší je připojit na tyto sítě (na jejich přístupové body, tzv. PoPy, z anglického "Point of Presence") koncové uživatele. Lze to udělat například pomocí ADSL (tj. nasazením ADSL modemů na již existující místní smyčky, vybudované pro telefonní síť). Nebo lze vybudovat zcela nové přístupové sítě (to dělají například kabelové společnosti), nebo překlenout poslední míli bezdrátově, případně zvolit ještě jiné řešení.

Domácí sítě, firemní sítě

Vraťme se ještě jednou k představě sítí LAN a WAN, a k jejich vzájemnému napojování na sebe. Celosvětový Internet si můžeme snadno představit jako jednu opravdu rozlehlou síť (síť WAN). Ale kde a jak se na ni napojí nějaké sítě LAN? Až dosud jsme mlčky předpokládali, že na konci přístupové sítě (na konci "poslední míle") je vždy jeden konkrétní zákazník, resp. jeden uživatel, resp. jeden počítač (uzel). To je ale čím dál tím méně pravda. Dnes se totiž čím dál tím více připojují k Internetu hned celé sítě, které můžeme označit jako "koncové". V nich se nachází více uzlů (‚počítačů), s kterými může pracovat více uživatelů. Právě tyto "koncové" sítě pak jsou těmi sítěmi LAN, které nám v celkovém obrázku dosud chyběly. Jsou to nejrůznější sítě LAN ve firmách, ve školách, na úřadech. A v poslední době čím dál tím více i v domácnostech. Jejich velikost, co do počtu uzlů, bývá velmi různorodá - a podle ní pak musí být dimenzováno i jejich připojení k Internetu, které překlenuje poslední míli a napojuje příslušnou firemní, domácí či jinou síť k přístupovému bodu (POP-u) příslušného internetového providera.

Trendem je připojování celých koncových (firemních, domácích) sítí, místo jednotlivých uživatelů

Dalším výrazným trendem je připojování nejrůznějších "koncových" sítí (ať již firemních, domácích atd.) k veřejnému Internetu přes vhodný firewall. Tak se označuje řešení, zajišťující určitou míru ochrany a zabezpečení před nástrahami, které mohou na koncovou síť a její zdroje číhat ve veřejném Internetu. Samozřejmě existují různé druhy firewallů, v různém provedení (od nenákladných až po velmi drahé), a s nimi také různé úrovně zabezpečení. Pro firemní síť asi bude vhodný jiný firewall, než třeba pro malou domácí síť. V zásadě ale lze říci, že dnes je vhodný firewall, odpovídající druhu a obsahu připojené sítě, již nutností.

Představa firewallu

Poslední metr

Trend připojování většího počtu koncových sítí k Internetu vedl k zavedení dalšího zajímavého pojmu a řešení, kterým je tzv. poslední metr a jeho překlenutí. Představme si například dům, ve kterém je hned několik bytů. Každý z nich se může k Internetu připojit individuálně, prostřednictvím vlastního překlenutí poslední míle (třeba tak, že v každém bytě si pořídí vlastní ADSL, a na něj si připojí jediný počítač v domácnosti, nebo celou domácí síť s více počítači).

Existuje ale i chytřejší řešení, kdy se obyvatelé celého domu domluví, pořídí si jedno "širší" (více kapacitně dimenzované) připojení, neboli jedno společné překlenutí poslední míle, a toto si pak již sami rozvedou v rámci celého domu do jednotlivých bytů. V této souvislosti se pak čím dál tím častěji objevuje onen nový termín,

kterým je "poslední metr". Označuje právě rozvody, realizované přímo u zákazníků a typicky v jejich režii - například právě v rámci jednoho domu. Představu ukazuje následující obrázek.

Představa poslední míle a posledního metru

NAN, aneb: sousedské sítě

Nově se formující kategorií sítí jsou tzv. sousedské sítě, označované také jako sítě NAN (od: Neighbourhood Area Network). Lze si je představit jako sítě, které mají za úkol překlenout poslední metr a rozvést jedno společné připojení do více bytů v rámci nějakého objektu. Případně mohou takto propojit několik sousedních objektů (například sousedních domů), a v rámci nich rozvádět připojení k Internetu.

Podstatné a charakteristické přitom je, že uživatele těchto sítí (do jejichž bytů je Internet rozveden) pojí fyzická blízkost jejich příbytků, resp. "sousedské vztahy" (bydlí vedle sebe). Nejde tedy o žádné společné profesní či jiné zájmy, ale skutečně o "geografické vztahy".

Představa sousedské sítě

Na takovouto "sousedskou síť" (síť NAN) se pak samozřejmě mohou připojovat jak celé domácí sítě, tak i jednotlivé domácí počítače (pokud je v konkrétním bytě počítač jen jeden).

CAN, aneb: komunitní sítě

Na podobném principu jako sítě sousedské fungují také sítě komunitní (CAN, Community Area Network). Také totiž rozvádí jedno společné připojení k Internetu mezi více koncových zákazníků. Rozdíl oproti sousedským

sítím je ale v tom, co tyto koncové zákazníky sdružuje. Již to není jejich geografická blízkost (stejný dům, sousední domy), ale jsou to nějaké společné zájmy. Ty pak z těchto zákazníků vytváří komunitu (odsud také název "komunitní síť"), která si pro sebe buduje svou komunitní síť a na ni napojuje své členy. V praxi se ale nejedná o komunity typu "zahrádkáři", včelaři" apod. Společným pojítkem komunity, budující vlastní komunitní síť, bývá spíše zájem postarat se o připojení vlastními silami - to když třeba v určité lokalitě nepůsobí žádný komerční provider (ISP), nebo jeho služby nejsou pro dané zákazníky atraktivní. Proto také bývá "dosah" komunitní sítě větší, než sítě sousedské. Mnohdy je to právě komunitní síť, která zajišťuje i překlenutí celé poslední míle.

Dobře známým příkladem komunitní sítě v ČR je síť CZFree.Net, využívající především bezdrátové technologie přenosu dat. Velikostí ji lze přirovnat již k metropolitní síti (či dokonce k několika metropolitním sítím, protože už se nenachází jen v Praze, ale i v dalších městech). Společným pojítkem jejích uživatelů pak skutečně je snaha postarat se o připojení vlastními silami, resp. být "sami sobě providerem". Určitě to souvisí i se stavem nabídky od komerčních providerů, která tyto uživatele neuspokojuje, a proto se rozhodli "vzít své připojení do svých rukou".

Intranet a extranet

Vraťme se nyní ještě ke dvěma pojmům, zmíněným v úvodu článku. Jde o pojmy "intranet" a "extranet". Oba se týkají účelu, ke kterému je nějaká síť využívána, a nikoli jejího dosahu (velikosti) ani způsobu realizace. Intranet (psáno s malým počátečním písmenem, protože jde o druhové jméno) slouží interním potřebám svého provozovatele, typicky pro provozování jeho vlastních agend. Takže typickými aplikacemi, provozovanými v intranetech, jsou různé groupwarové aplikace - třeba skupinové plánování a úkolování, sdílení dokumentů, vzájemná interní komunikace atd.

Naproti tomu extranet, jak už jeho označení napovídá, je využíván "směrem ven". Tedy zejména ke komunikaci se zákazníky (jde-li o firemní extranet). Typickými extranetovými aplikacemi pak jsou různé aplikace z oblasti e-commerce a e-business, umožňující objednávání, prodej a související aktivity.

Vraťme se ale ještě k intranetu. Bylo by chybou dívat se na něj jako na způsob využití nějaké lokální sítě, nejspíše firemní. Intranet může stejně tak dobře být hodně "rozlehlý", a může se rozprostírat i přes celá města, státy i kontinenty. Třeba taková nadnárodní firma může mít vlastní intranet, který mohou využívat všichni její zaměstnanci po celém světě, a dokonce se do něj přihlašovat i na cestách, kdekoli po světě. Takže vhodnější je dívat se na intranet jako na virtuální síť, která nabízí určité zdroje a služby, dostupné jen někomu (oprávněným uživatelům), a tyto zdroje a služby se týkají interního fungování provozovatele intranetu. To také znamená, že vstup do intranetu není volný, ale je vyhrazen jen pro oprávněné uživatele (zaměstnance firmy). Typicky je intranet také pečlivě chráněný proti neoprávněnému přístupu zvenčí. Naproti tomu typický extranet bývá spíše otevřený a přístupný komukoli, kdo o něj má zájem. Do budoucna je asi možné počítat s tím, že intranety si nebudou budovat jen firmy (a úřady, školy apod.), ale třeba také rodiny. Vždyť takové sdílení úkolů v rámci rodiny, společné plánování aktivit, sdílení informací atd. lze také realizovat na počítačích.

Sítě serverového typu a sítě peer-to-peer

Na závěr, abych si ukázali že výše popsaným dělením škatulkování sítí zdaleka nekončí, si řekneme ještě o jedné další možné klasifikaci počítačových sítí. Jde o kritérium, které se zajímá o postavení a roli jednotlivých uzlů v síti - a ani ono není zdaleka poslední, které je možné brát v úvahu pro dělení sítí. Takže tedy: pokud se budeme zajímat o postavení a roli uzlů, můžeme v praxi najít dvě varianty: situaci, kdy všechny uzly mají v principu stejné postavení a stejnou roli situaci, kdy se postavení a role jednotlivých uzlů liší

V druhém případě můžeme většinou rozdělit uzly sítě do dvou skupin: na servery, které nabízí určité zdroje a služby, ale samy je nikomu nevnucují a čekají, až si o ně někdo řekne na tzv. klienty, neboli uzly které samy nic nemají, ale když něco potřebují (službu či zdroj), tak si o to explicitně řeknou vhodnému serveru.

Rozdělení na dvě skupiny (servery, klienti) je jedno ze základních paradigmat světa počítačových sítí. Jde vlastně o jakousi "dvoučlennou" dělbu práce, obecně označovanou jako "model klient/server". Samozřejmě to není jediná možná dělba práce (existuje například i trojčlenná dělba). Pravdou ale je, že "dvoučlenný" model

klient/server, počítající s rozdělením uzlů do uvedených dvou skupin, je v praxi zatím nejčastější. Sítě, které s tímto modelem pracují, se pak označují jako sítě serverového typu.

Jejich protipólem jsou takové sítě, ve kterých se postavení a role jednotlivých uzlů neliší. To si lze představit také tak, že všechny uzly si jsou rovny - a odsud pak také pochází označení této varianty: jde o sítě peer-to-peer (neboť anglické "peer" lze přeložit jako "na stejné úrovni", event. stejný).

Pro správné docenění rozdílu mezi sítěmi serverového typu a sítěmi peer-to-peer si naznačme, jaké zdroje a služby mohou být ve hře. Může jít například o uchovávání souborů (obsahujících data, programy atd.). V sítích serverového typu se tyto souboru soustřeďují na serverech, které v tomto případ plní roli "souborových serverů" (anglicky: file serverů). Kdykoli některý klient potřebuje nějaký soubor, řekne si o něj příslušnému serveru, a ten mu jej poskytne. Jiným příkladem může být tisk na tiskárně. Ta může být připojena k serveru (který je pak tzv. tiskovým serverem, anglicky: print server). Kdykoli pak nějaký klient potřebuje na této tiskárně něco vytisknout, požádá o to tiskový server, a ten už vytisknutí zajistí. Svému klientovi tedy poskytuje službu, spočívající v tisku na své tiskárně. Celkově si pak lze představit, že v sítích serverového typu jsou všechny zdroje (resp. služby) soustředěny na jedno místo, a to na příslušný server.

Představa sítě serverového typu (vlevo) a sítě peer-to-peer (vpravo)

Naproti tomu v sítích peer-to-peer je tomu jinak. Zde jednotlivé zdroje zůstávají na místě, u svých vlastníků, resp. tam kde vznikají. Pokud je potřebuje někdo jiný, nějaký jiný uzel, pak si o ně řekne tomu uzlu, který příslušný zdroj vlastní. Ten pak zafunguje jako server, a druhému uzlu (v roli žadatele) poskytne příslušný zdroj, resp. službu (například tisk na své tiskárně). Jindy se zase může situace přesně obrátit: ten, kdo předtím "něco měl", může jindy sám žádat o něco jiného, nějaký jiný uzel.

Obecně tedy v síti peer-to-peer všechny uzly mohou potenciálně vystupovat jako servery (a něco poskytovat), i jako klienti (něco požadovat). Záleží na tom, co kdo chce, a kdo a jak to má - a za jakých podmínek to je ochoten poskytnout. Už tušíte, proč se koncept "peer-to-peer" tak dobře ujal například pro sdílení hudby mezi uživateli? Třeba v sítích, jako (byl) Napster, či stále je Gnutella, Kazaa a další? Ne nadarmo se těmto sítím také říká Peer-to-peer sítě (spíše ale zkráceně P2P).

Navrhnout a zrealizovat dobře fungující síť není žádná maličkost. Právě naopak, je to pořádně velký oříšek. K jeho rozlousknutí je proto vhodné použít stejný postup, jaký se používá ve stejné situaci i v jiných oblastech lidské činnosti: "když je něco příliš velké, než aby se to dalo zvládnout jako celek, tak to rozdělme na menší části a ty řešme samostatně". Odborně se tomu říká dekompozice, a jejím výsledkem by měl být rozklad jednoho velkého a obtížně řešitelného problému na několik menších problémů, z nichž každý je sám o sobě snáze řešitelný.

Při vlastní dekompozici (dělení velkého problému na menší) je samozřejmě třeba dát dobrý pozor na to, aby výsledné dílčí celky byly řešitelné samostatně, resp. aby řešení jedné dílčí části nebylo vázáno na to, jaké řešení se zvolí v jiné části. Jde tedy o to, kudy a jak vést pomyslný řez velkého problému.

V případě počítačových sítí je "řez" tradičně veden horizontálně, díky čemuž vznikají hierarchicky uspořádané vrstvy. Kolik takovýchto vrstev má být, co a jak mají dělat, jak mají fungovat atd. - právě v tom už se jednotlivé síťové architektury liší.

Představa dekompozice

Až se záhy dostaneme k tzv. referenčnímu modelu ISO/OSI, zjistíme že ten předpokládá 7 vrstev. Naopak rodina protokolů TCP/IP, na které dodnes funguje celý Internet, předpokládá pouze 4 vrstvy. A také jí to stačí.

Výhody vrstevnatých modelů

Vedle schůdnějšího řešení menších problémů, místo obtížného řešení jednoho velkého problému, přináší rozdělení do hierarchicky uspořádaných vrstev (tzv. vrstevnatý model) i některé další výhody. Právě u počítačových sítí je velmi důležité to, že při vhodném návrhu může být každá vrstva implementována nezávisle na ostatních vrstvách, a to dokonce variantně (různými způsoby). To znamená, že nižší vrstvy, zabývající se přenosem dat, mohou existovat ve více variantách, a být používány podle toho jaký konkrétní mechanismus přenosu dat a jaké přenosové médium je právě k dispozici. Vyšším vrstvám to ale může být jedno, a mohou tak existovat v jednotném provedení a fungovat vždy stejně bez ohledu na to, jaká nižší vrstva je pod nimi právě "podstrčena". Praktickým důsledkem je například to, že Internet funguje v principu všude stejně, bez ohledu na to, zda jste právě připojeni přes telefon, přes ADSL, kabelovou přípojku, nějakou formu bezdrátového připojení apod. Rychlost odezvy se nejspíše bude lišit, ale to by měl být jediný rozdíl - jinak by vše ostatní mělo fungovat stejně.

Pokud se v budoucnu objeví nějaká nová technologie, schopná přenášet data a zajistit připojení k Internetu, bude třeba vyvinout novou variantu implementace té vrstvy, která tuto novou technologii využívá a přenáší po ni data. Tato nová varianta nižší vrstvy se pak "podstrčí" pod vrstvy vyšší, které mohou zůstat beze změny, a přesto by vše mělo fungovat tak jak má. Internet bude rázem dostupný i po této nové přenosové technologii.

Vrstvy, služby, protokoly

Předchozí příklad dává tušit, že jednotlivé vrstvy mají své konkrétní úkoly, které naplňují. Jedna vrstva může zajišťovat přenos dat k přímým sousedům, zatímco jiná hledá cestu po celé soustavě sítí, tak aby se přenášená data dostala až ke svému cíli. Ještě další vrstva pak rozumí přenášeným datům a zajišťuje fungování takových služeb, jako je elektronická pošta či WWW apod.

Obecně tedy každá vrstva plní své úkoly tak, že poskytuje určité služby. Nejvyšší vrstva je poskytuje přímo uživatelům (jako již zmiňovanou elektronickou poštu, WWW stránky, přenos souborů atd.), ale ostatní vrstvy si je poskytují navzájem: konkrétní vrstva poskytuje své služby vrstvě bezprostředně vyšší (v rámci daného uzlu). Sama přitom ke svému fungování využívá služeb, které jí poskytuje vrstva bezprostředně nižší. Vše naznačuje i následující obrázek.

Představa vrstev a protokolů

V prostředí sítě je přirozené, že vrstvy jednotlivých uzlů spolupracují při plnění svých úkolů s vrstvami jiných uzlů. Tato spolupráce se ale vždy odehrává na stejné úrovni, resp. na úrovni stejnolehlých vrstev. Nikdy by naopak neměly spolupracovat vrstvy na nestejných úrovních. Důležitý je také konkrétní způsob vzájemné komunikace stejnolehlých vrstev. Pravidla této komunikace a vzájemné interakce obou stran definuje tzv. protokol. Ten například říká, jaký formát a význam mají data, která si obě strany vzájemně předávají, jak má jedna strana reagovat na to co jí posílá protistrana atd. Protokoly přitom přísluší jednotlivým vrstvám - různé vrstvy stejných uzlů tedy používají ke vzájemné komunikaci různé uzly. Nebo obráceně: každý protokol vždy "patří" do určité vrstvy.

Bylo by ale chybou myslet si, že mezi protokoly a vrstvami platí poměr 1:1, neboli že co protokol co vrstva a naopak. Jedna vrstva může ke svému fungování využívat více protokolů, to i souběžně. Například na jedné vrstvě (transportní, viz dále) mohou být používány dva různé protokoly, jeden pro spolehlivý přenos (zabezpečený proti ztrátám a poškození dat), a druhý nespolehlivý (který takto zabezpečen není). Nebo na nejvyšší úrovni (aplikační, viz dále) může být používán jeden protokol pro přenos WWW stránek, jiný protokol pro přenos zpráv elektronické pošty, a ještě jiný pro přenos souborů atd.

Zpět ale k protokolům jako takovým: ty musí být oběma stranám známy dopředu, aniž by se na jejich podobě musely nějak domlouvat. Proč tomu tak musí být, vyplývá ze skutečnosti, že spolu mohou chtít komunikovat dva uzly, které až dosud neměly spolu nic společného. Vůbec se neznají, stojí na různých systémových platformách, mají jiné operační systémy, používají jiné aplikace atd. - a přesto si musí hned napoprvé dobře porozumět. Musí tedy příslušný protokol znát "odjinud", v jeho definitivní a "závazné" podobě. Takovouto "dopředu známou" podobu protokolů dává standardizace, resp. vydávání standardů popisujících dané protokoly.

Horizontální komunikace mezi vrstvami

Pravidla vzájemné komunikace mezi stejnolehlými vrstvami různých uzlů (horizontální komunikace), definovaná konkrétním protokolem, obvykle předpokládají že jedna strana pošle druhé straně určitý "balíček", obsahující jak data, tak i instrukce ohledně toho, co se daty má stát (jak mají být dále zpracovány atd.). Lze si to představit také tak, že jde o obálku: uvnitř této obálky jsou data, a na obálce je nadepsán vzkaz protistraně (instrukce).

Ovšem představa, že by tuto obálku skutečně jedna strana předala přímo své partnerské straně (stejnolehlé vrstvě), není většinou správná. Kromě nejnižších vrstev totiž spolu žádné jiné vrstvy fakticky přímo nekomunikují. Pokud si potřebují něco předat, udělají to tak, že příslušnou "obálku" předají k doručení své bezprostředně nižší vrstvě. Ta se zachová stejně: obálku od vyšší vrstvy vloží do jiné (poněkud větší) obálky, na

tu napíše vzkaz pro svou partnerskou (stejnolehlou) vrstvu, a předá ji protistraně. Opět ale nikoli přímo, ale tak že tuto obálku předá své bezprostřední vrstvě ….

Horizontální komunikace mezi vrstvami - představa a skutečnost

Takto vše pokračuje, dokud se obálka nedostane k nejnižší vrstvě. Teprve ta totiž něco fakticky přenáší - takže vezme obálku od druhé nejnižší vrstvy (fakticky určitý blok dat), a celou ji přenese, bit po bitu, druhé straně.

Horizontální komunikace mezi vrstvami

Síťové architektury

Když už tušíme, co je protokol a co jsou vrstvy, můžeme si vysvětlit i pojem "síťová architektura". Představuje ucelenou představou o tom, kolik by mělo existovat vrstev, a co by mělo být jejich úkolem. Kromě toho je součástí síťové architektury i konkrétní představa o tom, jak by jednotlivé vrstvy měly své úkoly plnit. Tedy představa o konkrétních protokolech, patřících do jednotlivých vrstev.

Již avizovaným příkladem síťové architektury je rodina protokolů TCP/IP, vytvořená pro potřeby Internetu, a dnes jednoznačně nejrozšířenější a nejpoužívanější. Rozhodně ale není jednou síťovou architekturou.

Síťové architektury začaly vznikat již v době vzniku prvních počítačových sítí, ale zpočátku jako tzv. proprietární (tj. jako vlastní řešení jedné konkrétní firmy). Takto vznikly například architektury SNA (Systems Network Architecture, firmy IBM), či DECNET od společnosti Digital Equipment Corporation). Záhy se ale objevila potřeba vytvořit něco ne-proprietárního, čemu by "nevelela" jen jedna firma, ale co bylo naopak dostatečně otevřené.

Geneze referenčního modelu ISO/OSI

Úkolu vypracovat otevřenou síťovou architekturu se nakonec podujala organizace ISO (International Organization for Standardization). Ta pochází spíše ze světa spojů, je mezinárodní organizací pro normalizaci, má formální mandát od jednotlivých členských zemí, a jejími členy jsou národní normalizační instituce. Za ČR je členem ČSNI (Český normalizační institut).

Organizace ISO však původně chtěla vytvořit mnohem více, než jen síťovou architekturu ve výše uvedeném smyslu. Předsevzala si, že vytvoří obecnou a ucelenou představu toho, jak mají vypadat tzv. otevřené systémy. Přesněji: architekturu otevřených systémů (Open Systems Architecture), zahrnující kromě sítí i samotné uzly a jejich fungování "uvnitř". To se ale záhy ukázalo jako příliš velké sousto, a tak ISO svůj záměr zredukovala - odebrala "vnitřní fungování" jednotlivých uzlů, a rozhodla se soustředit jen na jejich vnější projevy, při jejich vzájemném propojení. Výsledkem byla i změna názvu toho, co mělo vzniknout. Nyní to už bylo "pouhé" Open Systems Interconnection Architecture (aneb: architektura propojování otevřených systémů). Bohužel i to se nakonec ukázalo jako příliš velké sousto, a tak ISO musela ještě jednou slevit. Připravila sice představu o počtu vrstev a jejich úkolech, ale již nestihla včas vymyslet i jednotlivé protokoly, které by jednotlivé vrstvy používaly. Proto nakonec zredukovala své zadání na vytvoření pouhého "referenčního modelu" (jakéhosi všeobecného rámce), a z předchozího názvu (Open Systems Interconnection Architecture, zkratkou OSIA) muselo vypadnout slovo "Architecture". Tak vznikl finální název "Open Systems Interconnection", zkratkou OSI.

Výsledkem práce organizace ISO tedy byl referenční model ISO/OSI. Ten měl být "oficiálním" řešením, které by jednotlivé členské státy následně zavedly do praxe. Některé se o to skutečně i snažily - ale neuspěly. Narazily totiž na to, že na trhu nebyly prakticky žádné produkty, které by z referenčního modelu ISO/OSI vycházely. Důvod byl dosti příznačný. Celá koncepce RM ISO/OSI totiž vznikala značně od zeleného stolu, bez kontaktu s realitou a bez respektování toho, co a jak se dá prakticky implementovat, a také co se vyplatí implementovat a je pro praxi potřebné. Zjednodušeně by se dalo říci, že referenční model ISO/OSI vznikal následujícím postupem: jeho autoři postupně "přihazovali" další a další vlastnosti a funkce, které by celé řešení podle jejich názoru mělo mít. Když už je nic dalšího nenapadalo, vše sečetli a udělali z toho závazný standard. Teprve následně (a často i jiní lidé) se začali zamýšlet nad tím, zda a jak by to šlo realizovat. A tu se obvykle zjistilo, že standardem požadované řešení je příliš bohaté, příliš "velké" a prakticky nerealizovatelné. Musely se hledat prakticky implementovatelné podmnožiny … ale než se stačily najít a prosadit do praxe, ujala se vlády nad počítačovými sítěmi jiná architektura: rodina protokolů TCP/IP. Na tu se podrobněji podíváme v příštím dílu tohoto seriálu.

Současnost ISO/OSI

Ačkoli referenční model ISO/OSI prohrál v souboji s protokoly TCP/IP (i v souvislosti s úspěchem TCP/IP v rámci Internetu), přesto není správné se na něj dívat jako na něco zcela odepsaného, o čem nemá smysl se ani zmiňovat. To určitě ne. Některé z protokolů, které byly vyvinuty pro ISO/OSI a (dodatečně) dosazeny do jeho referenční modelu, byly skutečně používány, nebo se staly alespoň základem pro jiné úspěšné protokoly. Za všechny lze zmínit například protokol X.400, který sloužil potřebám elektronické pošty, a byly na něm založeny i některé reálně fungující poštovní systémy. Nebo protokol X.500, který prošel odtučňovací kůrou a stal se základem pro protokol LDAP (Lightweight Directory Access Protocol), z rodiny protokolů TCP/IP.

Kromě toho je referenční model ISO/OSI - a to hlavně jeho vrstvový model - dodnes základem pro většinu učebních textů, které seznamují zájemce se základními principy světa počítačových sítí. Proto s ním začneme i my.

Sedm vrstev ISO/OSI

Referenční model ISO/OSI předpokládá existenci sedmi vrstev, jak ostatně naznačuje i následující obrázek. Tři nejnižší vrstvy se primárně zabývají přenosem dat, a přenášená data nijak nezpracovávají ani neinterpretují. Naopak tři nejvyšší vrstvy již přenášená data nějakým způsobem zpracovávají či alespoň ínterpretují, a snaží se vycházet vstříc potřebám jednotlivých aplikací. Mezi těmito dvěma trojicemi pak je ještě jedna vrstva, která má fungovat jako jakési přizpůsobení, resp. přizpůsobovací vrstva.

Sedm vrstev ISO/OSI

Jen pro srovnání - rodina protokolů TCP/IP má jen 4 vrstvy, a také s nimi bohatě vystačí.

Fyzická vrstva

Úkolem fyzické vrstvy, jak už její název napovídá, je "fyzický" přenos jednotlivých bitů. Jak jsme si již uvedli výše, jde vlastně o jedinou vrstvu, která skutečně přenáší nějaká data. Přenáší je po bitech, a bezprostředně vyšší vrstvě (vrstvě linkové) tedy nabízí dvě služby: odeslání bitu a příjem bitu. Aby tak mohla činit, musí se fyzická vrstva zabývat tím, jak jsou jednotlivé bity znázorněny na přenášeném médiu - zda a jak jsou kódovány či modulovány, jak je řešeno časování a synchronizace, případně jaké jsou používány konektory a jednotlivá rozhraní, jaké jsou jejich řídící signály atd. Podle toho se pak rozlišuje např. synchronní a asynchronní přenos, přenos modulovaný a nemodulovaný (resp. v základním pásmu), případně přenos sériový a paralelní atd. Uvažuje se také přenosová rychlost (v bitech za sekundu, resp. v násobcích), modulační rychlost (v Baudech), volí se různé způsoby modulace atd. Fyzická vrstva naopak nijak neinterpretuje bity, které přenáší, a s každým nakládá stejně jako s ostatními. Nepozná ani to, že některé bity "patří k sobě" a představují nějaký ucelenější blok dat - například linkový rámec.

Linková vrstva

Sestavovat jednotlivé bity do větších celků - tzv. linkových rámců (anglicky: frames) - má za úkol až vrstva linková. Ta tedy sama využívá služeb fyzické vrstvy (typu "přijmi bit, odešli bit"), a sama již musí zajistit korektní rozpoznání začátku i konce každého jednotlivého rámce.

Představa fungování linkové vrstvy

Důležité také je, že linková vrstva přenáší linkové rámce jen ke svým přímým sousedům. Tedy k uzlům, se kterými má přímé spojení (a nikoli takové, které vede zprostředkovaně přes jiný uzel). Lze si to představit také tak, že na úrovni linkové vrstvy každý uzel "vidí" jen své přímé sousedy, zatímco existenci dalších uzlů si nemusí uvědomovat.

Představa "viditelnosti uzlů" na úrovni linkové vrstvy

Na linkovou vrstvu však mohou být kladeny ještě další požadavky, kromě samotného přenosu linkových rámců. Například tzv. řízení toku, které má zabraňovat tomu, aby odesilatel zahlcoval příjemce. Tedy aby mu posílal data rychleji, než je příjemce schopen je zpracovávat.Nebo může být po linkové vrstvy požadováno, aby zajišťovala spolehlivý přenos. Tedy aby kontrolovala, zda při přenosu nedošlo k nějaké chybě - a pokud snad ano, pak je povinna se postarat o nápravu (typicky tak, že si nechá poslat poškozená či ztracená data znovu). V opačném případě, pokud není spolehlivost požadována, se takový přenos označuje jako nespolehlivý.

Podvrstvy linkové vrstvy

Linková vrstva referenčního modelu ISO/OSI původně počítala spíše s rozlehlými sítěmi (sítěmi WAN), které propojují své uzly pomocí vyhrazených dvoubodových spojů - tak jako na předchozím obrázku. Velmi brzy se ale objevily na scéně také sítě lokální (sítě LAN), které mají sdílenou topologii, protože používají sdílené přenosové médium. Tedy takové, ke kterému je připojeno více uzlů najednou, a všechny tyto uzly mohou také současně přijímat. Ovšem vysílat by měl vždy nejvýše jeden uzel, protože jinak dochází k tzv. kolizi a k "promíchání" signálů od více vysílajících uzlů.

V takovýchto lokálních sítích proto musí být použita nějaká metoda řízení přístupu jednotlivých uzlů ke sdílenému médiu. Ta ale musí být implementována nad fyzickou vrstvou, protože sama ke svému fungování využívá vysílání a příjem jednotlivých bitů. Stejně tak ale musí být přístupová metoda implementována ještě pod linkovou vrstvou, protože když tato vrstva přenáší celé rámce, měla by již mít zajištěn výlučný přístup ke sdílenému médiu, pro potřeby vysílání.

Autoři ISO/OSI tento protichůdný požadavek vyřešili šalamounsky. V zásadě mezi původní fyzickou a linkovou vrstvu vsunuli jednu další vrstvu. Aby tím ale nezvyšovali již tak vysoký počet vrstev, označili to jako rozdělení vrstvy linkové na dvě podvrstvy: (vyšší) podvrstvu řízení linkového spoje (podvrstvu LLC, z anglického: Logical Link Control) - která dělá v zásadě všechno to, co původní linková vrstva (nižší) podvrstvu řízení přístupu ke sdílenému médiu (podvrstvu MAC, z anglického: Media Access Control) - implementuje přístupovou metodu

Podvrstvy LLC a MAC

Síťová vrstva

Zatímco linková vrstva přenáší linkové rámce pouze ke svým sousedům, v praxi bývá nutné přenést nějaká data ještě dále - i přes mezilehlé uzly, do dalších sítí. To už ale má za úkol vrstva síťová. Blokům dat, které ona přenáší, se říká pakety (anglicky: packets) - a síťová vrstva je přenáší přes různé mezilehlé uzly tak dlouho, dokud je nedoručí jejich konečnému příjemci. Aby se tak stalo, musí být síťová vrstva schopna provádět tzv. směrování, neboli hledat cesty skrze sítě, vedoucí až ke kýženému cílovému uzlu.

Představa fungování síťové vrstvy - doručuje síťové pakety až k jejich koncovým příjemcům

Metod, jak hledat nejvhodnější cestu k cílovému uzlu existuje celá řada, a jejich podrobnější popis nám vydá na jeden z příštích dílů tohoto seriálu. Zde si jen naznačme, že existují různě inteligentní (promyšlené) algoritmy směrování. Mezi ty "méně promyšlené" patří například metoda tzv. záplavového směrování, kdy každý mezilehlý uzel předá každý paket dál ve všech směrech, které vedu z daného uzlu (kromě příchozího směru). Tím sice vznikají duplicitní pakety, které je třeba následně eliminovat, ale zato je zaručené, že se "záplava" dříve či později dostane ke svému cíli.

Více promyšlené algoritmy směrování hledají cestu k cílovému uzlu jinak, a to na základě znalosti celé soustavy vzájemně propojených sítí. Na úrovni síťové vrstvy by si proto jednotlivé (mezilehlé) uzly měly plně uvědomovat celou topologii soustavy sítí, a nikoli jen bezprostřední sousedy.

Viditelnost uzlů na úrovni síťové vrstvy

Transportní vrstva

O transportní vrstvě již víme, že je jakousi přizpůsobovací vrstvou mezi trojicí nejspodnějších vrstev, orientovaných na přenos dat, a trojicí nejvyšších vrstev, orientovaných na podporu aplikací. Je také první vrstvou, která je přítomna až v koncových uzlech, a naopak není přítomna v mezilehlých uzlech, propojujících jednotlivých sítě (v tzv. směrovačích). Na rozdíl od nižších vrstev tedy nezajišťuje komunikaci mezi přímými sousedy, ale až komunikaci mezi dvěma koncovými uzly (tzv. end-to-end komunikaci).

Funguje-li transportní vrstva jako přizpůsobovací vrstva, pak přizpůsobuje možnosti a způsob fungování trojice nižších vrstev tomu, co požadují tři nejvyšší vrstvy. Rozdíl mezi možnostmi a požadavky může být například v tom, že nejnižší tři vrstvy fungují nespolehlivě (nepovažují za svou povinnost postarat se o nápravu eventuelních chyb při přenosu), zatímco vyšší vrstvy požadují spolehlivý přenos. Nebo v tom, že nižší vrstvy fungují tzv. nespojovaně (nenavazují spojení na začátku přenosu), zatímco vyšší vrstvy naopak chtějí fungovat spojovaně.

Představa transportní vrstvy

V prostředí sítí na bázi protokolů TCP/IP je tomu přesně tak: síťová vrstva (a na ní protokol IP) funguje nespolehlivě a nespojovaně. Na úrovni transportní vrstvy pak existují dva vzájemně alternativní protokoly, TCP a UDP, z nich UDP nemění způsob fungování protokolu IP (také funguje nespojovaně a nespolehlivě), zatímco protokol TCP funguje spojovaně a spolehlivě. Vyšší vrstvy si pak mohou vybrat, kterou vrstvu budou používat.

Transportní vrstva má však ještě jeden důležitý úkol, a tím je rozlišování různých příjemců a odesilatelů v rámci každého jednotlivého uzlu. Ještě síťová vrstva se totiž dívala na každý uzel jako na dále nedělitelný celek, a nerozlišovala například mezi tím, že v rámci jednoho uzlu mohou přijímaná data "patřit" například WWW serveru, poštovnímu serveru, nebo naopak WWW browseru, poštovnímu klientovi, či nějaké jiné aplikaci.

Takovéto rozlišení různých odesilatelů a příjemců v rámci uzlu zajišťuje až transportní vrstva. Využívá k tomu přechodové body mezi sebou a bezprostředně vyšší vrstvou, které se v terminologii referenčního modelu ISO/OSI označují jako "body SAP" (Service Access Point), a v terminologii TCP/IP jako tzv. porty.

Představa bodů SAP

Jednotlivé pakety pak specifikují své odesilatele a příjemce tím, že obsahují číselné identifikátory příslušných přechodových bodů. Přes ně si je pak příslušný příjemce převezme, resp. odevzdá.

Relační vrstva

O relační vrstvě referenčního modelu ISO/OSI se říká, že vlastně nemá nic na práci, a je tedy ve své podstatě zbytečná. Původně tomu ale tak nemělo být, a relační vrstva měla zajišťovat řadu činností, spojených s "vedením relace" mezi dvěma komunikujícími stranami. Například měla zajišťovat podporu transakcí, nebo zabezpečení přenášených dat (jejich šifrování), případně i řízení toku a poloduplexnosti (aby například klient nezahltil server příliš mnoha požadavky). Nakonec se ale ukázalo, že takovéto funkce buďto nejsou vůbec zapotřební, nebo sice zapotřebí jsou, ale stejně si je podle svého zajistí vyšší vrstvy (hlavně vrstva aplikační).

Prezentační vrstva

To prezentační vrstva již má větší opodstatnění. Řeší totiž problém s tím, že stejný řetězec bitů může mít jiný význam pro odesilatele, a jiný pro příjemce. Důvodem může být jiné kódování znaků - pokud si dvě strany posílají nějaký text, ale každá používá jiné kódování znaků, pak příjemce nebude přijatému textu vůbec rozumět. Podobně pro znázornění celých čísel či čísel s plovoucí desetinnou čárkou, a obecně pro všechny datové struktury, či pro pouhé uložení vícebitových dat v paměti. I zde existují dvě různé konvence (označované jako Little Encián a Big Endian), mezi kterými je třeba řádně rozlišovat.

Pokud se ale bezprostředně nižší vrstvy snaží stůj co stůj přenést všechny bity tak jak jsou, aniž by se na nich cokoli změnilo, pak to může být špatně a příjemce může přijatým datům rozumět jinak, než jim rozuměl odesilatel. Proto jsou zapotřebí vhodné konverze přenášených dat - no a právě tyto konverze má na starosti prezentační vrstva.

Aplikační vrstva

Poslání aplikační vrstvy by na první pohled mohlo být jasné a přímočaré: v této vrstvě jsou provozovány jednotlivé aplikace. Není to ale pravda, a to z dosti kuriózního důvodu: pokud by se v aplikační vrstvě nacházely skutečně celé aplikace, se vším všudy, pak by to znamenalo, že by jejich fungování muselo být standardizováno,

a tudíž i sjednoceno. Takže v praxi by všechna okénka musela být stejná (standardizovaná), stejné (standardizované) by musely být způsoby ovládání aplikací atd. To samozřejmě nemá smysl, protože by to bránilo autorům aplikací v rozvoji a v unikátnosti jejich produktů.

V aplikační vrstvě proto nejsou celé aplikace, ale jen jejich části - takové, které má smyl standardizovat, a tím podřídit společným konvencím, tak aby si rozuměly s jinými implementacemi téže aplikace. Jsou to obvykle "základy" aplikací, jako například mechanismy přenosu zpráv elektronické pošty. Naopak uživatelské rozhraní, sloužící k psaní zpráv, k jejich čtení, třídění, tisk, odpovídání atd. zajišťuje část aplikace, která již je "nad" aplikační vrstvou, a tudíž již nemusí být standardizována.

Představa aplikační vrstvy

Rodina protokolů TCP/IP je opravdu početná (má přes 100 "členů"), a neustále se rozrůstá o nově vznikající protokoly. Její základ však vznikl poměrně dávno, alespoň podle "počítačových měřítek" - již v polovině sedmdesátých let. Důvodem byla existence sítě ARPANET, kterou v USA nechali vybudovat (a také zaplatili) tamní vojáci, aby na ní odzkoušeli myšlenku tzv. paketového přenosu. Tedy myšlenku přenosu dat "po vhodně velkých kusech", označovaných právě jako pakety. Dnes tak fungují snad všechny datové a počítačové sítě, ale tedy to byla úplně revoluční myšlenka, která se musela někde odzkoušet. No a k tomu posloužila právě síť ARPANET.

Pro nás je podstatné také to, že když síť ARPANET splnila svůj účel a potvrdila životaschopnost paketového přenosu, její vlastnící (vojáci, resp. resort obrany USA) se rozhodli ji nerušit. Právě naopak, rozhodli se ji zachovat a ponechat akademické sféře (univerzitám) k používání a k řešení výzkumných úkolů. Dokonce aktivně podpořili to, aby se na ARPANET začaly napojovat další univerzity i celé akademické sítě. K tomu skutečně došlo, a na zárodečný ARPANET se začaly postupně "nabalovat" další a další sítě. Výsledné soustavě vzájemně propojených sítí se pak začalo říkat Internet ….

Vznik TCP/IP

Jak s tím ale souvisí protokoly TCP/IP? Tak, že když se vojáci v USA rozhodli nerušit ARPANET a předat ho do rutinního používání akademické sféře, bylo zapotřebí vyvinout nové protokoly, na kterých by tato síť fungovala. Původně totiž používala jen experimentální protokoly (hlavně protokol NCP, Network Control Protocol), které se pro rutinní provoz moc nehodily. No a tak resort obrany USA (DoD, Department of Defense) zadal tamní akademické sféře další výzkumný úkol, který také zaplatil ze svých peněz: vyvinout sadu nových protokolů, vhodných pro rutinní používání ARPANETu. Takovéto zadání přišlo v první polovině sedmdesátých let. V roce 1980 již byla koncepce protokolů TCP/IP připravena, a resort obrany ji odsouhlasil jako "tu správnou" koncepci, na kterou musí celý ARPANET přejít. Na to ponechal ještě dva roky - a k 1. lednu 1983 přestal rodící se Internet používat protokol NCP, a přešel již na výlučné používání protokolů TCP/IP. 4 vrstvy TCP/IPS rodinou protokolů TCP/IP je úzce spojena i představa o počtu a struktuře vrstev, do kterých jsou tyto protokoly "zapasovány". Tuto představu ukazuje následující obrázek, který ji srovnává se sedmivrstvým referenčním modelem ISO/OSI.

představa protokolů TCP/IP

Protokoly TCP/IP tedy předpokládají existenci pouze čtyř vrstev: Aplikační Transportní Síťové (označované též jako "IP vrstva") Vrstvy síťového rozhraní

Z těchto čtyř vrstev však protokoly TCP/IP "obsazují" jen tři nejvyšší. U nejnižší vrstvy (vrstvy síťového rozhraní) se počítá s tím, že zde budou využity takové přenosové mechanismy, jaké jsou k dispozici, a které "pochází odjinud" (tj. nejsou součástí TCP/IP). Může jít třeba o Ethernet, o Wi-Fi, o technologie ATM či FR, nebo o xDSL (ADSL) atd.

Představa vrstev TCP/IP

Síťová vrstva - IP vrstva

Přenosové služby, které zajišťuje vrstva síťového rozhraní, umožňují přenášet "kusy dat" (označované jako rámce) mezi sousedními uzly. Tedy mezi počítači, které mezi sebou mají přímé spojení. Na tom pak staví síťová vrstva, která již zajišťuje přenos "kusů dat" (nyní již označovaných jako pakety) nejen mezi přímými sousedy, ale mezi libovolnými dvěma uzly.

Představa cest v síti

Musí tedy hledat nejvhodnější cestu od odesilatele až ke koncovému příjemci (zajišťovat tzv. směrování, anglicky: routing). Když vhodnou cestu najde, zajistí postupný přenos paketu přes případné mezilehlé uzly. To dělá tak, že pro každý "přeskok" vloží svůj paket do rámce, a požádá vrstvu síťového rozhraní o přenesení rámce i s jeho obsahem k přímému sousedovi. Zde je obsah rámce (paket) vybalen, předán zdejší síťové vrstvě, a ta znovu rozhodne, kterým směrem jej bude předávat dál.

Tento princip naznačuje obrázek. Představa fungování síťové vrstvy

Rodina protokolů TCP/IP "obsazuje" síťovou vrstvu především protokolem IP (Internet Protocol). Ten je pro celou rodinu protokolů natolik významný a charakteristický, že se postaral i o její pojmenování. Ve zkratce TCP/IP je za lomítkem jméno právě tohoto protokolu. Po protokolu IP jsou také pojmenovány pakety, přenášené na úrovni síťové vrstvy - říká se jim IP pakety, nebo také IP datagramy.

Transportní vrstva

Síťová vrstva, alias IP vrstva, je poslední vrstvou (počítáno odspodu), která se ještě vyskytuje ve všech uzlech - jak ve vnitřních uzlech přenosové sítě (v tzv. směrovačích), tak i v koncových uzlech (což mohou být například pracovní stanice uživatelů). Vyšší vrstvy, konkrétně vrstva transportní a vrstva aplikační, pak jsou přítomné již jen v koncových uzlech sítě.

Transportní vrstvu mají již jen koncové uzly sítě

Transportní vrstva má na starosti vzájemnou komunikaci koncových uzlů. Pokud je to po ní požadováno, zajišťuje například spolehlivost přenosů. Tedy to, aby se přenášená data po cestě neztratila, ani nějak

nepoškodila. Kromě toho také transportní vrstva rozlišuje mezi různými entitami v rámci jednoho uzlu. To znamená, že příchozí data rozděluje těm aplikacím, běžícím na daném počítači, kterým jsou určeny. Obdobně přejímá data, určená k odeslání, od jednotlivých počítačů, a předává je k přenosu síťové vrstvě. Ta již nerozlišuje mezi jednotlivými odesilateli a příjemci, a každý uzel sítě považuje za dále nedělitelný celek.

Představa rozlišování různých příjemců a odesilatelů v rámci jednoho uzlu

Na úrovni transportní vrstvy jsou v rámci TCP/IP provozovány hned dva hlavní transportní protokoly: UDP (User Datagram Protocol) TCP (Transport Control Protocol)

Právě protokol TCP je vedle protokolu IP tím, který se dostal do názvu celé rodiny protokolů TCP/IP.

Aplikační vrstva

Na úrovni aplikační vrstvy jsou provozovány jednotlivé aplikace. Nikoli ovšem celé, ale jen ty jejich části, které potřebují být navzájem kompatibilní. Třeba u elektronické pošty jde o celé poštovní servery a ty části poštovních klientů, které zajišťují odesílání, přenos a příjem jednotlivých zpráv. Uživatelské rozhraní, které uživatelům umožňuje zprávy číst, tisknout, různě třídit, archivovat atd., již není součástí aplikační vrstvy a nemusí být standardizováno. Díky tomu pak mohou být uživatelská rozhraní jednotlivých aplikací různá, s různým rozsahem funkcí a různým uživatelským komfortem.

Představa aplikací a aplikační vrstvy

Naopak třeba formát zpráv a jejich přenos musí být důsledně sjednoceny (standardizovány), aby se daly přenášet mezi jednotlivými poštovními servery, a aby jim "rozuměli" všichni poštovní klienti. Filosofie TCP/IP

Chceme-li správně pochopit základní vlastnosti síťové architektury, založené na protokolech TCP/IP, musíme si nejprve říci něco o základní filosofii, ze které vyšli či kterou zvolili autoři TCP/IP. Pomůže nám to i k pochopení toho, proč se právě TCP/IP tak dobře ujalo v reálné praxi a vydrželo bez zásadnějších změn až do dnešních dnů.

Vraťme se znovu do doby, kdy protokoly TCP/IP teprve vznikaly. Když tehdy resort obrany USA zadával akademické sféře úkol vyvinout protokoly TCP/IP, staly se součástí zadání některé konkrétní požadavky.Třeba ten, aby se nepočítalo s žádným centrálním prvkem, na kterém by fungování sítě stálo, ale se kterým by také celé padalo. To je ostatně typické pro uvažování vojáků, kteří se bojí toho, že by nepřítel jako první napadl právě takovýto centrální bod, zničil ho a tím vyřadil z provozu celou soustavu sítí. Pravdou je, že ani dnešní Internet nemá žádný centrální bod, který by jej řídil a bez kterého by nemohl existovat. Je značně distribuovaný, a díky tomu dokáže jako celek fungovat, i když některé jeho dílčí části jsou právě vyřazeny z provozu (nejspíše z důvodu technické závady). Nás ale zajímají protokoly TCP/IP, které nejsou přesně to samé jako Internet. Vznikly sice pro potřeby Internetu a v něm se také nejvíce rozšířily, ale mohou být použity i mimo Internet, v jakékoli třeba i samostatné počítačové síti.

Nespojovaný způsob fungování

Takže tedy: i samotné protokoly TCP/IP předpokládají distribuované řešení nejrůznějších funkcí, důležitých pro fungování celé soustavy sítí. Asi nejlépe je to vidět na způsobu, jakým je v rámci protokolu IP (tj. na úrovni síťové vrstvy) řešeno tzv. směrování, neboli hledání cest v síti, pro potřeby přenosu jednotlivých paketů. Neexistuje zde žádná centrální autorita, která by mezilehlým uzlům (tzv. směrovačům) říkala, kam mají dále předávat jednotlivé pakety, tak aby se dostaly ke svému cíli. Místo toho si potřebné směrovací informace získávají jednotlivé směrovače, ve vzájemné spolupráci. Když některý z nich vypadne, nebo se stane neprůchodným nějaký spoj, ostatní si najdou cestu jak výpadek obejít, resp. jak dopravit pakety na místo jejich určení jinou cestou.

Představa nespojovaného způsobu přenosu

Odpovídá to tzv. nespojovanému (anglicky: connectionless) způsobu fungování, při kterém nedochází k navazování spojení mezi odesilatelem a příjemce, a k vytyčení trasy, po které by se následně přenášela všechna data. Pokud by tomu tak bylo, a došlo by k nějaké změně v síti (třeba k výpadku nějakého dílčího spoje), muselo by se to nejprve zjistit a pak napravit - ukončení existujícího spojení a navázáním nového spojení. U nespojovaného spojení se jednoduše "jede dál", a pro každý paket se nejvhodnější cesta jeho přenosu hledá vždy znovu, podle momentální situace. Díky tomu se může stát, že jednotlivé pakety budou protokolem IP přenášeny ke svému cíli různou cestou, a třeba i dorazí v jiném pořadí, než v jakém byly původně odeslány. Ale to už je na vyšších vrstvách, aby si je správně poskládali zpátky.

Nespojovaný způsob přenosu jednotlivých paketů velmi připomíná fungování běžné listovní pošty. Ta také přenáší jednotlivé dopisy (zásilky) nezávisle na sobě, aniž by předem "navazovala spojení" a dopředu zjišťovala, zda adresát vůbec existuje. Místo toho dopis od odesilatele nejprve převezme, a pak se jej snaží doručit tak, jak nejlépe umí. Také se klidně může stát, že dva současně odeslané dopisy jdou jinou cestou a přijdou svému adresátovi v různou dobu.

Právě kvůli této podobnosti s listovní poštou se také pakety protokolu IP přirovnávají k datagramům, a jsou označovány jako IP datagramy.

Princip maximální snahy, ale nezaručeného výsledkuVelmi významnou charakteristikou síťového protokolu IP, který má na starosti přenos jednotlivých paketů (IP paketů, resp. IP datagramů), je to že negarantuje jejich doručení. Nedokáže totiž vždy zaručit, že bude mít vždy dostatek kapacit (přenosových i výpočetních) k přenesení všech paketů, které by přenést měl. Dokud mu tyto kapacity budou stačit, bude pochopitelně přenášet všechny pakety. Jakmile jich ale bude příliš mnoho, a jemu se nebude dostávat kapacit, má právo zahazovat ty pakety, které již nedokáže přenést. Říká se tomu také princip "maximální snahy …" (anglicky: best effort), kvůli tomu že protokol IP se snaží využít všech prostředků a zdrojů, které má k dispozici. Dodatkem pak je "… ale nezaručeného výsledku", kvůli tomu že když maximální snaha protokolu IP nestačí, dochází k zahazování paketů. Z pohledu jejich odesilatelů a příjemců je pak výsledek paketů skutečně nezaručený. Alternativou k fungování na principu "maximální snahy, ale nezaručeného výsledku …" by bylo garantování kvality přenosových služeb. Tedy situace, kdy konkrétní přenos by měl garantováno, že pro něj budou k dispozici takové a takové zdroje, včetně přenosových a výpočetních kapacit. Pak by se mu nemělo stávat, že na něj zdroje nevystačí a bude nutné některé jeho pakety zahazovat. Na principu garancí a garantovaných přenosových služeb funguje tzv. přepojování okruhů, které je alternativou k přepojování paketů a používá se hlavně v telekomunikačních sítích. Jeho nevýhodou je ale velmi nehospodárné využití dostupných zdrojů. Ty jsou totiž vyhrazeny pro potřeby jednotlivých přenosů, bez ohledu na to zda jsou či nejsou skutečně využity. Když využity nejsou, nemohou být přenechány ostatním přenosům, které by je naopak mohly potřebovat.

Princip paketového přenosu, označovaný také jako "přepojování paketů", je na rozdíl od přepojování okruhů velmi efektivní právě proto, že účelně hospodaří s dostupnými zdroji, výše popsaným způsobem, na principu "maximální snahy ….".

Protokol IP, který funguje na principu "maximální snahy ….", navíc měří všem přenosům stejně. To znamená, že v situaci kdy se mu již nedostávají dostatečné zdroje, zahazuje pakety bez ohledu na to, co jsou zač - od koho pochází, komu mají být doručeny, či co v sobě nesou (jaký typ dat) atd.

Nespolehlivost místo spolehlivosti

Další významnou charakteristikou protokolu IP je to, že funguje způsobem, kterému se říká "nespolehlivý". Ne snad proto, že by se protokol IP nesnažil přenášet data spolehlivě, to opravdu ne. Otázkou je spíše to, jak se má

zachovat, když už dostane nějaká data, která se při přenosu poškodila, typicky v důsledku nějaké chyby při přenosu. Protokol IP, který přijal poškozený paket a měl by jej dále zpracovat, má v principu dvě možnosti: postarat se sám o nápravu, obvykle tak, že si ten samý paket nechá znovu zaslat. Tato varianta přenosu se označuje jako "spolehlivá". nestarat se o nápravu a poškozený paket zahodit. Právě tato varianta je označována jako "nespolehlivá" .

Nespolehlivá varianta přenosu na první pohled nevypadá moc smysluplně. Autoři protokolů TCP/IP ale byli jiného názoru, a protokol IP koncipovali práv jako nespolehlivý. Tedy tak, že když narazí na poškozený paket, smí jej zahodit a nemusí se starat o nápravu. Má to svou logiku v tom, že se zajištěním spolehlivosti by byla spojená nemalá režie. Hlavně opakovaný přenos, který by si příjemce poškozeného paketu vyžádal, by nejen spotřeboval další přenosovou kapacitu, ale hlavně by oddálil přenos dalších dat, a tím zvýšil nerovnoměrnost (nepravidelnost) v jejich doručování. Některý aplikacím přitom právě takovéto zpoždění a nerovnoměrnost může vadit více, než poškození či dokonce ztráta určitých dat.

Například při přenosu multimediálních dat (např. digitalizovaného zvuku či obrazu) je pravidelnost doručování jednotlivých částí dat podstatně důležitější, než jejich občasný výpadek. Lidské ucho či oko většinou ani nezaznamená nějaké drobné zkreslení zvyku či malou chybu v obraze, které velmi rychle odezní. Naopak by zaznamenalo jakoukoli změnu v rychlosti (pravidelnosti) přehrávání zvuku či obrazu. Lze to přirovnat k efektu zrychlování či naopak zpomalování magnetofonového pásku či filmového pásu. To je znát podstatně více, než občasný drobný kaz na pásce/pásku.

Autoři protokolů TCP/IP navíc vyšli z předpokladu, že protokol IP by se měl soustředit na to, co je jeho hlavní úkolem - tedy na přenos dat - a už by se neměl zabývat dalšími věcmi, které pro něj nejsou klíčové. Lze to vyjádřit i oblíbeným sloganem: protokol IP by se měl soustředit na svůj hlavní byznys, a neztrácet čas s podružnými věcmi. Mezi tyto "podružné věci" bylo zařazeno i zajišťování spolehlivosti.

Transportní demokracie

Protokol IP, zajišťující přenos paketů na úrovni síťové vrstvy, tedy funguje nespolehlivě, a také nespojovaně. Skutečně se maximálně soustřeďuje "na svůj byznys", a nedělá nic jiného, než přenáší jednotlivé IP pakety. Počítá přitom s tím, že pokud budou vyšší vrstvy (resp. aplikace) potřebovat něco jiného - ať již spojovaný či spolehlivý způsob fungování, stále tu je ještě transportní vrstva, která může jejich přání vyhovět. Autoři TCP/IP skutečně zabydleli transportní vrstvu dvěma vzájemně alternativními transportními protokoly, mezi kterými si aplikace mohou vybírat.

Mohou zvolit protokol UDP (User DatagramProtocol), který je jen velmi lehkou nadstavbou nad protokolem IP a zachovává jeho způsob fungování - tedy nespojovaný a nespolehlivý. Prakticky to jediné, co k funkčnosti protokolu IP přidává, je rozlišování jednotlivých příjemců a odesilatelů v rámci daného uzlu (podle tzv. čísel portů, na rozhraní mezi transportní a aplikační vrstvou).

Naproti tomu druhý transportní protokol, protokol TCP (Transport Control Protocol), už funguje spolehlivě a spojovaně. Sám sice využívá nespolehlivých a nespojovaných služeb protokolu IP, ale zajišťuje navazování spojení mezi komunikujícími stranami (na úrovni transportní vrstvy), a stará se také o spolehlivost. Jinými slovy, pokud protokol IP něco nedoručí tak jak má, protokol TCP se postará o nápravu /vyžádá si opakované odeslání poškozených či úplně ztracených dat).

Hlavně ale: všechny aplikační protokoly mají na vývěr, zda v rámci transportní vrstvy využijí služeb transportního protokolu TCP, nebo protokolu UDP. Vybírat si mohou například podle toho, zda je pro ně důležitější spolehlivost přenosu (pak asi sáhnou po TCP), nebo zda před spolehlivostí dají přednost spíše rychlosti a pravidelnosti doručování (pak sáhnou po protokolu UDP.

Představa vzájemně alternativních transportních protokolů

IP over everything

Vraťme se ale ještě k protokolu IP a jeho fungování. Jak jsme si již uvedli, na samém počátku, kdy protokoly TCP/IP teprve vznikaly, měly americké univerzity velký zájem připojovat se na zárodečnou síť ARPANET i se svými již existujícími sítěmi. Ty ale byly dosti různorodé, založené na různých přenosových technologiích (odpovídajících vrstvě síťového rozhraní).

Proto autoři protokolů TCP/IP dostali v rámci svého zadání ještě jeden úkol: vyjít takovémuto připojování (resp. propojování) maximálně vstříc a umožnit připojení a provoz protokolů TCP/IP nad jakýmikoli přenosovými technologiemi, schopnými přenášet data.

Dnes, s odstupem 30 let, lze konstatovat že se to autorům povedlo nadmíru dobře. Protokol IP, který "zabydluje" síťovou vrstvu, je skutečně velmi pružný a schopný fungovat "nad čímkoli". Ostatně, vystihuje to i slogan "IP over everything". Nad přenosovými technologiemi vrstvy síťového rozhraní přitom vytváří jakousi "jednotnou pokličku", která zastírá jejich specifické rozdíly a vytváří nad nimi jednotné přenosové prostředí. Díky tomu se pak protokoly vyšších vrstev (transportní vrstvou počínaje) nemusí vůbec zabývat tím, nad jakou technologií nižších vrstev vlastně fungují.

Představa "IP over Everything"

V době vzniku a rozvoje Internetu to mělo zásadní význam pro připojování dalších sítí k ARPANETu. Dnes se této vlastnosti s úspěchem využívá k tomu, aby se lidé mohli připojovat k celosvětovému Internetu opravdu nejrůznějšími způsoby, jaké mají právě k dispozici - třeba přes vytáčenou telefonní linku, před ADSL, přes Wi-Fi, přes kabelovou televizi atd. Ve všech případech je nad uvedenými přenosovými technologiemi nejnižší vrstvy (vrstvy síťového rozhraní) provozován "jednotný" protokol IP, a nad ním již standardním způsobem ostatní protokoly.

IP verze 6

Protokoly TCP/IP byly navrženy opravdu dobře, a v praxi se velmi dobře ujaly. Prakticky bez jakýchkoli zásadnějších změn vydržely až do dnešní doby. Samozřejmě se dále vyvíjely, ale "inkrementálním" způsobem, tj. postupným přidáváním dalších a dalších vlastností a schopností, a nikoli zahazováním celých předchozích řešení a zahajováním "od základů". Snad jedinou výjimkou jsou adresy, používané na úrovni síťové vrstvy (tzv. IP adresy). Pro ně bylo vyhrazeno 32 bitů, což ve své době představovalo značnou redundanci (nadbytečnost). Později ale, vzhledem k fenomenálnímu úspěchu celosvětového Internetu, se spotřeba IP adres zvýšila natolik, že začalo hrozit jejich brzké vyčerpání. Našla se ale různá "úsporná" řešení, která úbytek IP adres výrazně zpomalila.

Přesto se muselo hledat i celkové řešení, které se našlo v podobě zcela nového síťového protokolu IP verze 6 (IPv6). Ten bohužel již není vůči stávajícímu protokolu IP (též: IP verze 4) inkrementální, ale musí jej nahradit. Existují však i scénáře pro jejich vzájemnou koexistenci a postupný přechod od jednoho protokolu ke druhému.

Everything over IP

Velký úspěch protokolů TCP/IP vedl ještě k jednomu zajímavému jevu. K tomu, že snad všechny úspěšné aplikace a služby, které kdy vznikly v nějakém jiném prostředí než pro TCP/IP a Internet, byly časem převedeny (portovány) právě na platformu TCP/IP. Je to ostatně logické, když jde o aplikace které byly původně vyvinuty pro jiné přenosové sítě, a ty již nejsou být rozvíjeny a jsou naopak čím dál tím více nahrazovány právě sítěmi na bázi TCP/IP. Dnes je stav takový, že snad neexistuje žádná alespoň trochu smysluplná a uživatelná aplikace, která by ještě nebyla přenesena na platformu TCP/IP.

Představa "Everything over IP"

Platí to ostatně i pro tak "odlišné" aplikace a služby, jako je přenos živého hlasu a obrazu. Ty byly dlouhou dobu doménou telekomunikačních sítí, fungujících na principu přepojování okruhů. Dnes se ale čím dál tím více prosazují i do síti s přepojováním paketů, a ponejvíce právě do sítí na bázi protokolů TCP/IP. Nepříliš správně se pro celý tento trend ujal slogan "Everything over IP" (doslova "cokoli nad IP", což není úplně pravda, protože mezi protokolem IP a samotnými aplikacemi jsou ještě transportní protokoly (TCP nebo UDP). Nicméně i zkratky typu "něco nad IP" jsou dnes již běžně zažité a také používané. Příkladem může být zkratka VOIP (Voice over IP), označující přenos hlasu prostřednictvím protokolu IP.

Lidé, kteří budují a provozují počítačové sítě, a stejně tak lidé kteří je používají, by měli mít alespoň základní povědomí o vztazích a souvislostech, které se týkají datových přenosů a v rozhodující míře je determinují (určují). Je to vhodné přinejmenším kvůli tomu, aby si lidé neidealizovali schopnosti dnešních datových sítí a neočekávali od nich nekonečně velikou (vysokou) schopnost přenášet data. Naopak, měli by tušit, na čem je schopnost přenášet data závislá a kde jsou její limity - i kam až se lze dostat zdokonalováním technologií, a kde leží hranice, přes které se v principu nelze dostat, ani se sebelepšími technologiemi.

Nic není ideální

Nejen v životě, ale i v elektrotechnice a elektronice platí, že nic není ideální. Takže ani žádné vedení, které přenáší nějaký signál, se k němu nechová ideálně, tak že by jej během přenosu vůbec neovlivňovalo. Naopak: každý přenášený signál je vždy nějak zeslaben (tzv. utlumen), a také nějak zkreslen (tj. je změněn jeho průběh). Otázkou je pouze síla těchto dvou jevů a to, jak významně se na přenášeném signálu projevují. V praxi se pak uplatňují ještě další vlivy, jako např. rušení, přeslechy atd. K lepšímu pochopení příčin útlumu a zkreslení nám může pomoci dnešní první obrázek. Ukazuje tzv. náhradní zapojení obyčejného "kusu drátu", na kterém lze snáze ukázat, jak se ve skutečnosti každé vedení chová. Každé dva obyčejné dráty, vedené v určité délce vedle sebe, se mj. chovají jako kondenzátor. Ten svým vybíjením a nabíjením mění průběh signálu, ale sám nezpůsobuje jeho zeslabení (útlum). K zeslabení (útlumu), které zase nemění průběh signálu (nezkresluje ho) však přesto dochází, a tak do náhradního zapojení patří také rezistor (odpor R), a to jak v sérii, tak i mezi oběma vodiči (svod). Stejně tak musíme do náhradního zapojení přidat ještě indukčnost (cívku L), která také mění průběh signálu, ale nezpůsobuje jeho útlum (zeslabení).

Náhradní zapojení přenosové cesty (vedení)

Výsledný efekt "reálných obvodových vlastností" pak ukazuje další obrázek, na kterém je znázorněna snaha přenést skrze vedení obdélníkový impuls. Ideální přenosová cesta (které v praxi neexistuje) by signál obdélníkového průběhu přenesla bez jakékoli změny. Vliv útlumu u reálné přenosové cesty se projevuje "zmenšením" obdélníků (na výšku), beze změny jejich tvaru (vliv odporu R).

Vliv odporu, indukčnosti a kapacity na přenos obdélníkového signálu

Vliv kapacity C a indukčnosti L pak lze odvodit z toho, že tyto dva prvky svou podstatou působí proti změnám. Například kondenzátor se po určitou dobu nabíjí, nebo zase vybíjí. Na signálu obdélníkového průběhu se to projevuje zaoblováním ostrých hran. To má tendenci měnit signál obdélníkového průběhu (obecně: s "ostrými" zlomy) na signál který se mění jen pozvolna.

Přenos v základním a přeloženém pásmu

Přenášet signál obdélníkového průběhu, a jeho ostré hrany měnit podle toho, zda právě potřebujeme přenést jedničku nebo nulu, je samozřejmě možné. V praxi se to také tak dělá, a říká se tomu přenos v základním pásmu (anglicky: baseband). Není ale těžké nahlédnout, že to nelze dělat na příliš velkou vzdálenost. Zkreslení signálu s

ostrými hranami je totiž tím větší, čím větší je délka vedení - a za určitou hranicí by už příjemce nedokázal správně rozpoznat, co se vlastně původně vysílalo.

Pokud potřebujeme dosáhnout na větší vzdálenost, snažíme se přenášet spíše takový druh signálu, který přenosovým vedením projde co možná nejlépe, přesněji s nejmenším zkreslením. No a nejmenší zkreslení bude mít takový signál, který se mění nikoli skokem, ale naopak co možná nejpozvolněji. V praxi jde o signál sinusového či kosinusového průběhu, kterému se obvykle říká harmonický. Jeho průběh naznačuje obrázek číslo 3.

Představa harmonického signálu

Harmonický signál však sám o sobě nenese žádnou užitečnou informaci. Ta na něj musí být nejprve "naložena", a to způsobem, který se označuje jako modulace. Při té dochází ke změně některého z parametrů přenášeného signálu - ať již jeho frekvence, amplitudy či fáze (podrobněji dále), a příjemce pak detekuje přenášené informace právě z těchto změn. Celkově se pak ale již hovoří o modulovaném přenosu, či o přenosu v přeloženém pásmu. V angličtině se někdy používá i termín "broadband", což ale poněkud koliduje s něčím jiným - s označením vysokorychlostního přenosu.

Šířka pásma

Než se pustíme do podrobnějšího popisu modulace, vraťme se ještě k jedné věci, která souvisí s reálnými vlastnostmi přenosových cest a se zkreslováním a útlumem signálu. Oba tyto negativní vlivy totiž nejsou snad nikdy absolutní, v tom smyslu že by působily stejně na signály jakéhokoli průběhu.

tzv. vanová křivka

Závislost obou faktorů na průběhu obecného signálu je poněkud složitější, ale vcelku snadno si ji lze představit pro harmonické signály o určité frekvenci. Ty totiž buďto přenese (nezkreslí, neutlumí), nebo je nepřenese vůbec. Graficky si to můžeme znázornit na následujícím grafu, jehož charakteristický průběh bývá označován jako tzv. vanová křivka. To proto, že jeho "strany" jsou poněkud zaobleny, v důsledku toho že "míra pokažení" přenášeného signálu se nemění úplně skokem. V každém případě ale lze i na této křivce identifikovat určité "hraniční" frekvence (fmin a fmax), ve kterých se schopnost přenášet harmonický signál výrazně mění:pokud je frekvence harmonického signálu mezi oběma hodnotami (fmin a fmax), je harmonický signál přenesen v dostatečné kvalitě na to, aby mohl být využit pro potřeby přenosu dat pokud je ale frekvence přenášeného signálu mimo uvedený interval (plus minus jeho "zaoblené hrany"), neboli menší než fmin či naopak větší než fmax, pak už je přenášený signál příliš "pokažen" (zkreslen a utlumen) a nedá se využít.

Uvedený rozsah frekvencí, fmin až fmax, se v praxi označuje jako šířka pásma, anglicky: bandwidth. Jak záhy uvidíme, právě tato šířka přenosového pásma je základním faktorem, určujícím míru schopnosti přenášet data.

Vliv šířky pásma na přenos signálu

Vraťme se nyní od pozvolna se měnících signálů harmonického průběhu k signálům obdélníkového průběhu a zkusme si naznačit, jak šířka pásma ovlivňuje jejich přenos. Musíme si k tomu ale vypůjčit jeden z fundamentálních výsledků matematiky, který říká že obecný signál můžeme rozložit na součet (nekonečné řady) harmonických signálů, jejichž frekvence budou vždy celistvým násobkem určité základní frekvence (jednonásobkem, dvojnásobkem, trojnásobkem atd.). V odborném žargonu se hovoří o rozkladu na jednotlivé harmonické složky, či jen na jednotlivé "harmonické".

Nám to ale pomůže v tom, že u těchto harmonických složek (signálů harmonického průběhu) již víme, jak budou přeneseny skrze vedení s určitou konkrétní šířkou přenosového pásma:

některé "harmonické složky" budou přeneseny víceméně bez úhony. Konkrétně ty, jejichž frekvence leží mezi fmin až fmax

ostatní "harmonické složky" naopak neprojdou vůbec. To se v praxi týká hlavně vyšších harmonických složek, s frekvencí vyšší než fmax.

Představa přenosu harmonických složek

Zpět ale k původnímu signálu: ten bude na straně příjemce zpětně složen z těch harmonických složek, které "prošly". Jelikož to určitě nebudou všechny složky (to by byly jen při nekonečně velké přenosové kapacitě), bude se přenesený signál poněkud lišit od signálu původně vyslaného. Jak, to naznačuje následující obrázek. Snaží se ukázat, jak "věrnost" přeneseného signálu závisí na šířce pásma.

Představa rekonstrukce původního signálu z přenesených harmonických složek

Obecně můžeme konstatovat, že čím větší je šířka přenosového pásma, tím více harmonických složek se přenese, a tím více se jich dostane do součtu, který na straně příjemce rekonstruuje původní signál - a tím bude tento přijatý signál věrnější. Platí to samozřejmě i naopak: čím menší (užší) bude šířka pásma, tím méně věrný bude přijatý signál.

Nyní si již můžeme dopředu naznačit, že schopnost přenášet data, ve smyslu maximálně dosažitelné přenosové rychlosti (v bitech za sekundu, resp. v násobcích), bude lineárně závislá právě na dostupné šířce pásma. Intuitivní vysvětlení je takové, že čím bude přijatý signál věrnější (díky větší šířce přenosového pásma), tím na něj budeme moci naložit více dat (ať již modulací v přeloženém pásmu či v základním pásmu), a tím dosáhneme větší rychlosti přenosu dat.

Nepředbíhejme ale, protože se ještě musíme seznámit s několika dalšími skutečnostmí.

Modem a modulovaný přenos

Vraťme se ještě k podstatě modulace. Tedy k tomu, jak na harmonický signál "naložit" (tzv. namodulovat) nějaká užitečná data, a na straně příjemce je zase správně "sejmout". Zajištění takovéhoto modulovaného přenosu dat je úkolem zařízení označovaného jako modem (což vzniklo zkrácením z anglického "modulator - demodulator"). Modem z jedné strany přijímá data nemodulovaná, přenášená v základním pásmu, a z druhé strany je vysílá v modulované podobě, "naložené" na vhodný harmonický signál. Jeho protějšek (modem na druhé straně přenosového vedení) zajišťuje opačný převod (tzv. demodulaci) přijímaných dat.

Představa modemu

Modemů existuje v praxi celá řada, v nejrůznějším provedení. Existují například telefonní modemy, určené pro přenos dat po běžné telefonní lince. Jiný příkladem mohou být DSL modemy, určené pro vysokorychlostní přenosy nad místními smyčkami. Nebo kabelové modemy, zajišťující přenosy dat v sítích kabelové televize atd.

Druhy modulace

Modemy se liší i v tom, jaký druh modulace používají. V úvahu přitom připadají tři základní varianty modulace, a celá řada jejich kombinací.

Základní varianty modulace jsou tři a vychází z toho, že harmonický signál má tři parametry, které lze měnit a tím i využit k "naložení" dat:amplitudu, neboli tzv. rozkmit - pak jde o amplitudovou modulaci

frekvenci (kmitočet, resp. úhlovou rychlost) - pak jde o tzv. frekvenční modulaci fázi (fázový posun) - pak jde o tzv. fázovou modulaci

Představa různých druhů modulace

V praxi je asi nejlépe využitelná fázová modulace, díky tomu že změny fáze se nejlépe detekují. Hlavním problémem demodulace je totiž správné rozpoznání (vzájemné odlišení) jednotlivých stavů, mezi kterými se přenášený signál může měnit.

Pro názornost si to můžeme ukázat na příkladu jedné z kombinovaných modulací, tzv. kvadraturní amplitudové modulace (QAM, Quadrature Amplitude Modulation). Ta využívá tří různých úrovní amplitudy, které kombinuje se dvanácti různými úrovněmi fázového posunu. Výsledkem je celkem 36 možných kombinací, které znázorňuje následující obrázek.

Představa kvadraturní amplitudová modulace

Z těchto 36 stavů se ale využívá jen 16. Konkrétně těch, které jsou "nejdále od sebe" (i ve smyslu obrázku), tak aby šly co nejspolehlivěji odlišit od sebe.

Modulační a přenosová rychlost

Na příkladu kvadraturní amplitudové modulace si můžeme názorně vysvětlit rozdíl mezi dvěma důležitými veličinami: modulační rychlostí a rychlostí přenosovou.

Modulační rychlost vypovídá o tom, jak rychle se mění modulovaný signál, neboli jak rychle (resp. často) přechází z jednoho stavu do druhého stavu. Vyjadřuje se jako četnost takovýchto přechodů za jednotku času (sekundu), a měří se v jednotkách zvaných Baud (zkratkou Bd).

Takže pokud se bude signál měnit například 1000x za sekundu, bude jeho modulační rychlost 1000 Baudů. Modulační rychlosti se někdy říká také "symbolová rychlost". To když s místo o "stavu" přenášeného signálu hovoří o "symbolu".

Podstatné ale je, že modulační rychlost nevypovídá nic o tom, kolik "užitečných dat" se přenese za jednotku času. Vypovídá o tom, kolikrát se za jednotku času přenášený signál změní, ale už neříká nic o tom, kolik bitů jedna taková změna reprezentuje. To záleží až na tom, kolik je různých stavů, mezi kterými přenášený signál přechází, resp. kolik je různých symbolů, které mohou být přenášeny. Jsou-li tyto stavy (různé symboly) dva, pak mohou reprezentovat (nést) jeden bit informace (neboli: dvě různé hodnoty jednoho bitu). Pokud jsou stavy (symboly) čtyři, mohou reprezentovat dva bity (neboli: čtyři různé kombinace hodnot dvou bitů). Je-li stavů (symbolů) osm, mohou reprezentovat tři bity atd. Jistě snadno nahlédnete, jaká zde platí obecná závislost mezi počtem stavů a reprezentovaných bitů: pro n bitů je zapotřebí 2n různých stavů, resp. symbolů, nebo obráceně: n různých stavů (symbolů) stačí pro log2(n) bitů

Pokud tedy vezmeme modulační rychlost, vyjadřující počet změn přenášeného signálu za jednotku času, a vynásobíme ji log2(n), kde n je počet různých stavů (symbolů), pak tím získáme počet datových bitů, které jsou takto přenášeny. To už ale jsme u přenosové rychlosti, která se měří v bitech za sekundu a násobcích.

Jinými slovy, mezi modulační a přenosovou rychlostí platí jednoduchý vztah: v přenosová = v modulační * log2(n)

V případě kvadraturní amplitudové modulace, která pracuje se 16 rozlišovanými stavy (n=16) je tedy modulační rychlost (číselně) čtyřikrát vyšší než rychlost modulační. Jedna změna stavu přitom reprezentuje 4 datové bity.

Modulace v praxi

Abychom ale nezůstávali jen u učebnicových příkladů, ukažme si něco z reálného života. Například následující tabulka ukazuje, jakých přenosových rychlostí dosahují dnešní telefonní modemy, s jakou modulační rychlostí přitom pracují, kolik stavů rozlišují atd.

přenosová rychlost [bitů/s] modulační rychlost [Bd] počet rozlišovaných stavů bitů/ změnu standard2400 600 16 4 V.22bis9600 2400 16 4 V.32 14400 2400 64 6 V.32bis 28800, 33600 2400-3200 512 9 V.34 56000 8000 128 7 V.90,V.92

A ještě jeden příklad z praxe, který se týká takových věcí, jako je ADSL či PLC (Powerline Communications), či různých bezdrátových technologií. Mají společné to, že využívají širší přenosové pásmo (tj. větší šířku pásma), ve kterém se ale mohou vyskytovat další rušící vlivy (vnější rušení, přeslechy atd.). Proto tyto technologie rozdělují celé širší pásmo na větší počet užších částí, a každou z nich využívají samostatně, a navíc inteligentně: v každém dílčím pásmu volí takovou modulační rychlost a takový počet stavů, aby optimálně "vytěžili" dostupné přenosové pásmo, a přitom se vyvarovali výraznějšímu působení negativních vlivů (rušení atd.).

Takže tam, kde jsou podmínky pro přenos výhodnějším zvyšují modulační rychlost i počet stavů přenášeného signálu (a tím i dosahovanou přenosovou rychlost). Naopak tam, kde podmínky jsou horší, modulační rychlost i počet stavů snižují.

Nyquistův teorém

V našem povídání o vzájemných vztazích mezi šířkou pásma, modulační rychlostí a dalšími veličinami nám stále chybí některé významné souvislosti. Například to, jak konkrétně souvisí modulační rychlost s šířkou přenosového pásma. V intuitivní rovině jsme si ukázali, že čím bude šířka přenosového pásma větší, tím kvalitněji bude signál přenesen - a tím častěji jej asi budeme moci měnit, tj. zvyšovat modulační rychlost.

Jak ale najít přesnou závislost mezi šířkou pásma a modulační rychlostí? To se podařilo až Američanovi norského původu Harry Nyquistovi, v roce 1928. Zjistil, že v optimálním případě by modulační rychlost měla být číselně dvojnásobná oproti šířce pásma. Jinými slovy: v modulační = 2 * šířka pásma

Shannonův teorém

Vztah mezi šířkou pásma a modulační rychlostí, vyplývající z Nyquistova teorému, můžeme dosadit i do jednoduché formulky pro přenosovou rychlost. Místo : v přenosová = v modulační * log2(n)pak dostaneme: v přenosová = 2 * šířka pásma * log2(n)

Ovšem šířka pásma je většinou dána použitou přenosovou cestou (přenosovým kanálem), a bývá také adekvátně zpoplatněna - čím větší šířku pásma si někdo nechá vyhradit, tím více za ni také zaplatí. Chceme-li pak zvyšovat přenosovou rychlost, lze to jistě dělat "extenzivně", zvyšováním použité přenosové kapacity. To ale může být drahé. Nabízí se proto zajímavá otázka: ponecháme-li šířku přenosového pásma beze změny (abychom nezvyšovali náklady), je možné libovolně zvyšovat počet stavů přenášeného signálu (hodnotu n)? Pokud by to bylo možné, znamenalo by to, že pouhým zdokonalováním technologie přenosu by se dala libovolně zvyšovat i přenosová rychlost (byť by rostla nikoli lineárně, ale logaritmicky).

Definitivní odpověď na tuto základní otázku našel až zakladatel moderní teorie informace, pan Claudie Shannon. Zjistil, že ani sebedokonalejší technologie přenosu se nikdy nedostanou přes určitou hranici, která je dána právě a pouze: šířkou přenosového pásma "kvalitou" přenosové cesty, vyjádřenou skrze odstup signálu od šumu

Konkrétní závislost maximální přenosové rychlosti na šířce pásma a kvalitě linky (odstupu signálu od šumu) vyjadřuje následující vzoreček, max(vpřenosová) = šířka pásma * log2(1 + signál/šum)

Povšimněte si, že v tomto vzorečku skutečně není žádným způsobem zakomponována dokonalost technologie, nebo alespoň nějaký parametr, který by se dal dokonalostí technologií měnit. To koresponduje s avizovaným závěrem, že jde o principiální limit, zcela nezávislý na dokonalosti technologií které budeme používat.

Jak je to u telefonní linky?

Teoretické závěry pan Shannona si můžeme přiblížit na konkrétním příkladu běžné (tzv. analogové) telefonní linky. Ta má totiž uměle omezenou šířku pásma (pro hlasové hovory) na 3100 Hz, konkrétně od 300 do 3400 Hz. Kvalitní linka přitom nabízí odstup signálu od šumu cca 1000:1. Pokud si tyto hodnoty dosadíme do vzorečku ze Shannonova teorému, vyjde nám jako maximálně dosažitelná přenosová rychlost něco málo přes 30 kbit/s . V praxi přitom existují a běžně se používají modemy pro takovéto analogové linky, které dosahují přenosové rychlosti až 33,6 kbit/s. Je to již ve sporu se Shannonovým teorémem?

Představa datového přenosu po analogové telefonní lince, skrze analogovou telefonní síť

Samozřejmě nikoli. Tyto modemy, vycházející ze standardu V.34, totiž využívají nedokonalostí tzv. vanové křivky, kterou jsme si již jednou kreslili - a využívají i část postranních pásem, kde pokažení signálu ještě není zcela fatální. Vše je ale již "na doraz", takže žádné další zrychlování modemů pro analogové telefonní linky není možné.

Tzv. vanová křivka pro analogovou telefonní linku

Jak je ale potom možné, že dnes existují i telefonní modemy, které slibují přenosovou rychlost až 56 kbit/s? Jsou už tyto modemy ve sporu s Shannonovým teorémem? Opět samozřejmě nikoli. Modemy pro rychlost 56 kbit/s, vycházející ze standardů V.90 či V.92, dokáží fungovat uvedenou rychlostí jen "oproti" digitální telefonní ústředně. Na příslušné místní smyčce (spojující účastníka s ústřednou) pak již neplatí původní frekvenční omezení (300 až 3400 Hz). K dispozici je zde větší šířka pásma, a dosažitelná přenosová rychlost je shora omezena jinými faktory.

Podmínkou k tomu, aby tyto modemy dosahovaly rychlostí vyšších než 33,6 kbit/s (do 56 kbit/s), je to aby v celém řetězci od koncového účastníka až k serveru, ke kterému se připojuje, chyběl jeden A/D převodník. I pak ale lze dosahovat vyšších rychlostí než 33,6 kbit/s jen v jednom směru (ke koncovému uživateli), zatímco v opačném směru je stále maximem buď 33,6 kbit/s (u modemů dle standardu V.90), nebo 48 kbit/s (u modemů V.92).

Představa nasazení modemů pro rychlost 56 kbit/s

Nominální a efektivní přenosová rychlost

V souvislosti s přenosovou rychlostí bychom si měli objasnit ještě jeden aspekt, a to rozdíl mezi nominální a efektivní přenosovou rychlostí. Až dosud jsme se bavili spíše o nominální přenosové rychlosti, kterou je nejlépe si představit jako veličinu, určující jak dlouho trvá přenos jednoho bitu. Například: jde-li o rychlost 1000 bit/s, pak přenos jednoho bitu trvá tisícinu sekundy. V praxi se ale nemusí neustále přenášet jeden bit za druhým. Data se obvykle přenáší po blocích, mezi kterými mohou být různé odstupy, prodlevy atd. Stejně tak je třeba počítat s tím, že zdaleka ne všechny přenášené bity jsou "užitečné". Mnohé z nich jsou různě režijní, a jsou sice nutné pro fungování přenosů - jde například o celé hlavičky přenášených bloků (rámců, paketů, buněk atd.) - ale na druhé straně se nemohou započítávat mezi "užitečná" data (ve smyslu: nikoli režijní).

Pokud bychom se zabývali tím, kolik "užitečných" dat se přenese, pak už se bavíme o efektivní přenosové rychlosti (někdy označované také jako přenosový výkon). Měří se ve stejných jednotkách jako nominální přenosová rychlost, v bitech za sekundu a násobcích. Na první pohled by efektivní přenosová rychlost měla být vždy nižší než rychlost nominální. To proto, že vzniká "odpočítáním" různých prodlev a režijních dat. V praxi tomu také tak často je, a efektivní přenosová rychlost se pohybuje výrazně pod rychlosti nominální, uváděné různými poskytovateli přenosových služeb. Mnohdy je tato efektivní přenosová rychlost významně závislá také na intenzitě provozu, resp. na souběhu aktivit více uživatelů, a její pokles pak svědčí o nedostatečném dimenzování poskytovaných přenosových služeb. Příkladem mohou být tuzemské služby ADSL, jejichž efektivní přenosovou rychlost ukazuje následující tabulka (s měřeními serveru dsl.cz).

Zdroj: www.dsl.cz

Na druhou stranu existují i takové faktory, které efektivní rychlost naopak zvyšují (oproti rychlosti nominální). Jde zejména o kompresi přenášených dat, jejíž účinnost bývá závislá na povaze dat (na míře jejich "komprimovatelnosti").

V praxi, když se vzájemně zkombinují opačně působící efekty - tedy režie, snižující efektivní přenosovou rychlost, a komprese, zvyšující tuto rychlost - to může dopadnout tak i tak. Výsledná efektivní přenosová rychlost může být menší než rychlost nominální, ale také třeba větší.

Dospěli jsme k tomu, že schopnost přenášet data je dána zejména šířkou přenosového pásma, a pak také kvalitou média (linky), vyjádřenou jako poměr mezi užitečným signálem a neužitečným šumem.

Šířka pásma, měřená v hertzích (Hz), je vlastně rozsah frekvencí, které je dané přenosové médium schopné přenášet. Schopnost přenášet data je pak na ní lineárně závislá: čím větší je šířka pásma, tím větší je i schopnost přenášet data. Tuto schopnost ale již vyjadřuje tzv. přenosová rychlost, kterou měříme v bitech za sekundu, resp. v násobcích (kilobitech za sekundu, megabitech za sekundu atd.).

Závislost na kvalitě linky, resp. na poměru mezi užitečným signálem a neužitečným šumem, již je poněkud složitější - ale i zde platí, že čím je "odstup" užitečného signálu od šumu větší (čím je signál silnější, v porovnání se sílou šumu), tím lépe. Konkrétní závislost, vycházejí z tzv. Shannonova teorému, jsme si popsali již minule. Pro připomenutí ale jeden důležitý dovětek: maximální dosažitelná přenosová rychlost, při určité šířce pásma a určitém odstupu signálu od šumu, vůbec nezávisí na dokonalosti technologií a způsobu, jakým přenosové médium využíváme. Takže ani sebedokonalejší technologie nás nedostane přes maximum, vyplývající ze Shannonova teorému.

V reálné praxi ovšem narážíme i na prozaičtější překážky, jako třeba na útlum (zeslabení) signálu, či jeho zkreslení během přenosu. To jsou ale věci, se kterými dokonalejší technologie dokáží pomoci (například vhodným zesilením signálu, použitím signálu vhodného průběhu atd.).

Klasifikace přenosových médií

Než se začneme bavit o vlastnostech jednotlivých přenosových médií, nejprve si je vhodně "rozškatulkujme". V prvním přiblížení si je můžeme rozdělit na "drátová" a "bezdrátová" přenosová média. Nebo jim můžeme říkat také "vodičová" a "éterová".

Drátová (vodičová) média jsou specifická tím, že přenášený signál prochází pouze skrze ně (tzv. jej vedou), a až na nežádoucí vyzařování, které se snažíme maximálně omezit, je signál neopouští. Naproti tomu bezdrátová ("éterová") média předpokládají šíření signálu ve formě elektromagnetických vln otevřeným prostorem, ať již ve všech směrech či jen v určitém konkrétním směru.

Drátová média si můžeme dále rozdělit na metalická (kovová) a optická (přenášející světelné paprsky). Přitom "optická a drátová" jsou optická vlákna, která jsou nejčastěji skleněná (křemíková), ale existují i optická vlákna vyrobená z plastů. Naopak "metalická drátová" média se nejčastěji vyskytují buď v podobě tzv. kroucené

dvoulinky (anglicky: twisted-pair), nebo v provedení tzv. koaxiálních (souosých) kabelů. Existují však i různé hybridy mezi oběma variantami. Bezdrátová média zase nejčastěji dělíme podle toho, na jakých frekvencích (v jakých frekvenčních pásmech) je příslušný signál přenášen, resp. vysílán a přijímán. Pak se hovoří o přenosech mikrovlnných, infračervených, obecněji o rádiových atd. Nebo může být kritériem i způsob bezdrátového přenosu, a pak se hovoří například o satelitních přenosech, pozemních přenosech atd. Poměrně samostatnou kategorií pak jsou bezdrátové optické přenosy (FSO, Free-Space Optics), označované také jako "laserové".

Drátová přenosová média

Přenosové schopnosti "drátový" médií jsou dosti různorodé. Zatímco například u kroucené dvoulinky jsme dnes už mnohde "na doraz", u koaxiálních kabelů stále ještě existují jisté rezervy. Ty ale nejsou nic proti tomu, jaký je přenosový potenciál optických vláken. Ten je skutečně obrovský a dnes jej využíváme jen z velmi malé části. Jedno známé přísloví z branže dokonce říká, že ani pořádně netušíme, jak je tento potenciál vlastně velký.

Něco málo o kapacitních možnostech optických vláken však přeci jen tušíme. Mají totiž k dispozici obrovskou šířku přenosového pásma, danou velikostí a rozpětím frekvencí, které používají. To proto, že optická vlákna přenáší světlo ve viditelném rozsahu, které má frekvenci kolem 108 MHz, resp. 1014 Hz, resp. 100 THz. Naproti tomu kroucená dvoulinka pracuje s relativně nízkými frekvencemi (do stovek MHz), a koaxiální kabel zvládá ještě o něco vyšší frekvence. Ukazuje to ostatně i obrázek č.2, na kterém je znázorněn (na ose Y) také měrný útlum jednotlivých typů přenosových médií. Měrný útlum je přitom veličina, udávající jak médium o příslušné jednotce délky zeslabuje (utlumuje) přenášený signál. Jde ale jen o orientační představu, v praxi velmi záleží na provedení, použitém materiálu atd. Navíc útlum obecné závislí i na frekvenci přenášeného signálu.

Obr. 2: Představa o útlumu u drátových přenosových médií

Spíše než přesné faktografické údaje by nám měl obrázek č. 2 naznačit jednu podstatnou věc: že kroucená dvoulinka má relativně nejhorší přenosové vlastnosti (největší útlum), a tak s ní "dosáhneme" spíše jen na kratší vzdálenosti. S koaxiálními kabely je to již o něco lepší, ale nejdéle se můžeme dostat s optickými vlákny, která mají nejmenší měrný útlum.

Kroucená dvoulinka

S kroucenou dvoulinkou se v praxi můžeme setkat poměrně často, například v rámci telefonních rozvodů (na větší vzdálenosti, z domovů či kanceláří až k telefonním ústřednám), nebo v rámci "počítačových" rozvodů, již spíše na kratší vzdálenosti (desítky metrů, max. 100 metrů).

Obr. 3: Nasazení kroucené dvoulinky v praxi

To dává tušit, že kroucené dvoulinky existuje více druhů. Někdy se hovoří o "telefonní" dvoulince a "datové" dvoulince, ale přesnější je jejich rozdělení do tříd, resp. kategorií. Z "datových" jsou dnes nejpoužívanější dvoulinky: kategorie 3: dimenzované pro signál o frekvenci do 10 MHz kategorie 5: pro signál do 100 až 120 MHz kategorie 6: do 200 MHz

Přenosová rychlost, kterou v praxi na kroucené dvoulince můžeme dosáhnout, je závislá i na tom, kolik párů (dvojic vodičů, resp. dvoulinek) použijeme. Například pro desetimegabitový Ethernet (dle standardu 10BaseT) vystačíme se dvěma páry dvoulinky kategorie 3. Pro stomegabitový Ethernet (100BaseTX) nám stačí dva páry dvoulinky kategorie 5, ale existuje i řešení (100baseT4), při kterém můžeme použít 4 páry dvoulinky kategorie 3. Pro ještě vyšší rychlosti (gigabitový Ethernet atd.) se ovšem používá již jen kategorie 5 či vyšší.

V praxi se přitom používají kabely, které obsahují více párů kroucené dvoulinky současně - nejčastěji jde o 4 páry. V telefonii se pak zle setkat s kabely, které obsahují až stovky párů "telefonní dvoulinky".

UTP a STP

A proč je vlastně dvoulinka kroucená a nikoli rovná? To proto, že každé dva vodiče, vedené vedle sebe, se chovají jako anténa a něco vysílají (vyzařují) do svého okolí, a stejně tak něco ze svého okolí přijímají. K pravidelnému zkroucení obou vodičů po celé délce (nejčastěji 1x každých 7,5 až 10 cm) dochází právě kvůli tomu, aby se tento efekt minimalizoval. Bohužel se nikdy neodstraní úplně, a tak i kroucená dvoulinka stále něco vyzařuje do svého okolí (a také z něj něco přijímá).

Dalším opatřením je použití přídavného stínění, které má vyzařování dále snižovat. Podle toho, zda je či není stínění použito, pak rozlišujeme:

nestíněnou kroucenou dvoulinku (anglicky: UTP, od: Unshielded Twisted Pair), která nemá žádné stínění stíněnou kroucenou dvoulinku (STP, Shielded Twisted Pair), která má samostatné stínění každého páru v kabelu

Pochopitelně stíněná dvoulinka (STP) je dražší než nestíněná, a tak se v praxi používá spíše dvoulinka nestíněná. Někdy se ale lze setkat ještě s třetí variantou, ve které je stínění společné pro všechny páry v rámci daného kabelu. Nechrání tak proti vzájemnému ovlivňování jednotlivých párů, ale chrání alespoň proti vyzařování ven z kabelu. V angličtině je tato varianta označována jak "Screened" (ScTP).

Obr. 4. Nestíněná dvoulinka (kabel se 4 páry UTP)

Koaxiální kabely

Koaxiální kabely byly využívány pro datové přenosy dokonce ještě dříve, než kroucená dvoulinka. Například první standardy Ethernetu vznikly právě s předpokladem použití koaxiálního kabelu, a teprve později se objevila možnost využití kroucené dvoulinky.

Obr. 5: Historicky první náčrtek Ethernet, s tzv. "žlutým" koaxiálním kabelem

Dnes se koaxiální kabely pro datové přenosy zase znovu vrací na výsluní, a to zejména v souvislosti s budování tzv. hybridních sítí (HFC, Hybrid Fiber-Coax), kombinujících optická vlákna právě s koaxiálními kabely. Jde většinou o novější rozvody, u kterých jsou použity (relativně dražší) optické kabely pro překlenutí větších vzdáleností, až například po vstup do jednotlivých domů či jiných objektů. Pro další rozvedení, které již má obvykle "paprskovitý" charakter, by ale použití optických vláken bylo stále ještě příliš nákladné, a tak se realizuje pomocí koaxiálních kabelů. Příkladem mohou být rozvody kabelových televizí. Předností koaxiálních kabelů je to, že jejich chování jako antény (hlavně: vyzařování do okolí, ale také příjem z okolí) je velmi malé. Je to dáno jejich konstrukcí, které také vděčí za své jméno. "Koaxiální", resp. "co-axial" totiž znamená "soustředný", a oba vodiče koaxiálního kabelu skutečně jsou soustředné (mají společný střed).

Obr. 6: Schéma koaxiálního kabelu

Uvnitř koaxiálního kabelu se nachází vnitřní (středový) vodič, kolem kterého je vrstva izolace, a kolem ní pak ve formě vodivého opletení druhý vodič. Jeho střed (středová osa) se přitom shoduje se středem vnitřního vodiče. Podstatné ale je, že druhý vodič (ve formě vodivého opletení) funguje jako účinné stínění po celé délce koaxiálního kabelu, a tím výrazně zmenšuje vyzařování směrem ven.

Optická vlákna

Jak jsme si již uvedli, optická vlákna mají oproti kroucené dvoulince i oproti koaxiálním kabelům zdaleka největší potenciál v přenosu dat, s tím že dnes tento potenciál využíváme stále jen velmi málo. Proto jsou také optická vlákna instalována všude tam, kde je potřeba realizovat větší přenosovou kapacitu, či alespoň vytvořit předpoklady pro budoucí využití takovéto větší kapacity. Na druhou stranu instalace optických vláken je přeci jen náročnější a nákladnější, než u ostatních drátových přenosových médií.

Optická vlákna již ze své fyzikální podstaty přenáší data namodulovaná ("naložená") na světelný paprsek. K vedení tohoto paprsku optickým vláknem se využívá základních poznatků z fyziky, konkrétně tzv. Schnellova zákonu lomu. Ten říká, že když světelný paprsek dopadá na rozhraní dvou prostředí s různou optickou hustotou

(dvou "různě průhledných" prostředí), část paprsku se odráží zpět a část prostupuje dále, do druhého prostředí - jak ilustruje obrázek č. 7.

Obr. 7: Schnellův zákon a princip vedení světelného paprsku optickým vláknem

Záleží ovšem také na rozdílu optických hustot (na rozdílu v "průhlednosti" obou prostředí) a na úhlu dopadu paprsku - pokud je tento úhel dostatečně malý (měřeno od osy vlákna, na obrázku od vodorovné osy), pak se celý paprsek odráží zpět do původního prostředí a nic z něj neprostupuje do druhého prostředí (dochází k úplnému odrazu). No a to už je to, co je pro optická vlákna zapotřebí: stačí vhodně volit materiál obou prostředí (jádra i pláště), a také úhel dopadu světelného paprsku, měřeno od osy vlákna. Pokud bude tento úhel dopadu menší než určitá mezní hodnota (označovaná jako tzv. numerická apertura), bude uvnitř vlákna docházet jen k samým úplným odrazům, a světelný paprsek bude optickým vláknem veden po celé jeho délce.

Mnohovidová a jednovidová optická vlákna

To, co jsme si právě popsali, platí pro tzv. mnohobodová vlákna, skrze která může procházet více svazků paprsků (tzv. vidů) současně. Každý z nich přitom vstupuje do optického vlákna pod trochu jiným úhlem, a proto také "cestuje" po trochu jiné dráze. Na druhém konci vlákna pak díky tomu vystupují jednotlivé vidy s určitým vzájemným posunem (označovaným jako vidová disperze). Příjemce ovšem nevyhodnocuje jednotlivé vidy samostatně, ale pouze jejich součet. Kvůli vidové disperzi pak přijímá původní signál v poněkud deformovaném (zkresleném) tvaru, což ilustruje následující obrázek č. 8.

Obr. 8: Představa vidové disperze

Konstrukčně jsou přitom mnohovidová vlákna řešena tak, že jejich optická prostředí (jádro a plášť) se mění skokovitě (se skokovitým indexem lomu), nebo pozvolna (s gradientním indexem lomu). Podle toho se pak jednotlivé vidy buďto skokovitě odráží, nebo pozvolna "ohýbají".

Obr. 9: Představa mnohobodových vláken se stupňovitým a gradientním indexem lomu

Není jistě těžké nahlédnout, že vidová disperze u mnohobodových vláken bude mít tím více šancí se uplatnit a tím více zkreslit přenášený signál, čím delší bude optické vlákno. Dosah mnohovidových vláken je proto relativně omezený, alespoň oproti tzv. jednovidovým vláknům. Ta již podle svého názvu vedou vždy jen jeden vid, a to zcela bez odrazů. Nedochází u nich tudíž k vidové disperzi, která by zkreslovala přijímaný signál, a tak s nimi lze v praxi dosáhnout na větší vzdálenost - a také dosahovat vyšších rychlostí.

Obr. 10: Představa vedení světelného paprsku skrze jednovidové vlákno

Rozdíl mezi jednovidovými a mnohovidovými vlákny je samozřejmě i v jejich provedení, ceně a náročnosti na manipulaci a instalaci. Jednovidová vlákna jsou obecně tenčí, dražší, křehčí a náročnější na manipulaci (např. na osazení konektory). Naproti tomu mnohovidová vlákna jsou tlustší, lacinější, méně křehká a méně náročná na manipulaci: jednovidová vlákna mají průměr jádra 4 až 10 mikronů (mikrometrů) mnohovidová vlákna mají průměr jádra 50, 62.5 nebo 100 mikrometrů

Optické kabely

Oba druhy optických vláken jsou stále příliš tenké a křehké na to, aby se daly v praxi používat samostatně. Když už, musí být obalena další silnou vrstvou vhodného materiálu, který zabezpečí potřebné mechanické vlastnosti

(například je ochrání proti snadnému zlomu). Spíše se ale větší počty jednotlivých optických vláken sdružují do jednoho konstrukčního celku - optického kabelu. Ten pak zajišťuje také potřebné mechanické vlastnosti (tuhost) a ochranu jednotlivých vláken před poškozením.

Existují přitom i kombinované (hybridní) kabely, které kromě optických vláken obsahují také koaxiální kabely. Ty jsou většinou dostatečně tuhé na to, aby zajišťovaly potřebnou tuhost i pro celý kabel. Kromě nich pak jsou v kabelu umístěna ještě optická vlákna. Po instalování takovéhoto kabelu je možné zpočátku používat třeba jen koaxiální kabel. Když pak vzrostou požadavky na přenosovou kapacitu, je možné začít používat i jednotlivá optická vlákna.

Myšlenka kombinovaných (hybridních) kabelů se snaží reagovat na skutečnost, že v poslední době už nejsou nejvíce nákladné samotné kabely, ale jejich pokládka. Proto nabízí možnost "zakopat do země" něco (optická vlákna), co třeba ještě není aktuálně zapotřebí, ale do budoucna může být - a pak se to dá využít bez toho, že by bylo nutné znovu "kopat do země".

Obr. 11: Koaxiální a optické kabely

Ze stejné úvahy vychází i další dnešní praxe, která také úzce souvisí s optickými vlákny a kabely. Jde v ní o to, že když už se musí "kopat do země", pak se do ní "zakope" více, než je právě potřeba, jako určitá rezerva pro budoucnost. Dokonce to ani nemusí být již hotové kabely, optické ani jiné. Stačí "zakopat" prázdné plastové trubky, tzv. chráničky. Když pak někdy později vyvstane potřeba zřídit nějakou přenosovou kapacitu, stačí těmito chráničkami protáhnout potřebné kabely - a to aniž by se muselo znovu "kopat do země". Dokonce je díky chráničkám možné již jednou položené kabely zase někdy později vytáhnout, a místo nich natáhnout skrze chráničky kabely nové.

Obr. 12: Chráničky a jejich pokládka

Plastová optická vlákna

Optická vlákna má smysl používat i na krátké vzdálenosti, třeba jen na několik metrů - například pro propojování výkonnějších zařízení. V takovém případě by ale klasická "skleněná" optická vlákna byla zbytečným luxusem, navíc s ne zrovna jednoduchou manipulací (náročností na konektorování atd.). Proto se v praxi používají také jiná optická vlákna, nikoli skleněná, ale plastová. Jsou relativně nenáročná na cenu i provedení, a na krátké vzdálenosti mohou nabízet i dostatečně vysoké přenosové rychlosti. Průměr optických vláken je na jedné straně výrazně větší, než průměr vláken skleněných. Na druhé straně ale ani takto větší průměr není v praxi překážkou, ale spíše výhodou, kvůli lepším mechanickým vlastnostem.

Obr. 13: Srovnání průměru jádra (a pláště) jednobodových, mnohovidových a plastových vláken

Vlnový multiplex

Optické přenosové technologie se s postupem času výrazně zdokonalují. Časem se možná dočkáme i čistě optického zpracování dat, ale zatím zůstaňme jen u optických přenosů a přenosových médií. Zde je jasným trendem postupné zvyšování dosahu souvislých optických segmentů (bez zesilovačů), stejně jako zvyšování dosahovaných rychlostí. K ještě výraznějším změnám však dochází v důsledku prosazování techniky, označované jako "vlnový multiplex" (wavelength multiplexing). Ta umožňuje použít jedno optické vlákno pro více (samostatných) přenosů současně. Vlastně jde o jakési rozdělení (odsud: multiplex) optického vlákna na několik samostatně využitelných kanálů. V každém z nich pak lze dosahovat obvykle stejných rychlostí, jako bez takovéhoto dělení. Jinými slovy to znamená, že pomocí vlnového multiplexu lze vynásobit dosahovanou přenosovou kapacitu optického vlákna n-krát, kde n je počet "kanálů", na které je vlákno rozděleno. Vlnový multiplex ve skutečnosti funguje tak, že dokáže oddělit od sebe světelné paprsky různých vlnových délek (odsud také: vlnový multiplex). Přitom takovéto paprsky různých vlnových délek odpovídají světlu o různé barvě, a proto se i zde hovoří o "barvách": v tom smyslu, že vlnový multiplex přenáší skrze optické vlákno různé

barvy, a každá z nich může nést samostatný "náklad" dat (každá může být modulována samostatně). Základní představu naznačuje následující obrázek:

Obr. 14: Představa vlnového multiplexu

Počet barev, používaných v praxi, se pochopitelně také vyvíjí v čase. Dnes jsou běžně dostupné, ve formě komerčních řešení, systémy pracující s desítkami barev. V laboratorních podmínkách však nejsou výjimkou ani tisíce barev na jediném vlákně. Příkladem řešení z praxe mohou být optické sítě EuroRing, které v roce 2001 zprovoznila po celé Evropě i po ČR společnost KPNQwest. Do země zakopala vždy určitý počet chrániček (od 2 do 10), ale optický kabel většinou instalovala jen do jedné z nich. Každý kabel měl 120 vláken, a každé vlákno bylo ještě rozděleno na 80 barev, pomocí vlnového multiplexu. V rámci každé barvy byla přenášena data rychlostí 10 Gbit/s. V přepočtu to odpovídá 800 Gbps na jedno vlákno, a při 120 vláknech v jednom kabelu to představuje úctyhodných 96 Tbps (terabitů za sekundu). V přepočtu na počet obyvatel ČR to vycházelo téměř na 10 Mbit/s na hlavu. Tak obrovskou kapacitu se ale nepodařilo úspěšně prodat, a společnost KPNQwest později zkrachovala. Optické přenosové systémy

Samotná optická vlákna by k přenosu dat samozřejmě nestačila. Na obou jejich stranách musí být instalována vhodná zařízení, zajišťují z jedné strany generování světelných paprsků, a z druhé strany vyhodnocujících jejich příjem. Potřebné zdroje světla a detektory se pochopitelně liší podle toho, o jaké vlákno jde - nejjednodušší plastová i mnohovidová vlákna například vystačí se světelnými zdroji na bázi diod LED.

Naproti tomu jednovidová vlákna vyžadují dostatečně kvalitní laserové zdroje. Obdobně na druhé straně.

Obr. 15: Představa optického přenosového systému

Po doplnění nezbytného zdroje světla a vysílače (pro převod signálu z elektronické do optické podoby), a o detektor a přijímač (pro opačný převod) teprve dostáváme celý ucelený optický přenosový systém. Pokud je použit ještě vlnový multiplex, musím být oba konce vláken osazeny ještě příslušným vybavením pro rozlišování jednotlivých barev a jejich samostatnou modulaci, podle přenášených dat.

Naše dnešní povídání o přenosových technikách začneme tím, co jsou duplexní a simplexní přenosy. Rozdíl mezi nimi se týká toho, zda jsou data přenášena jen v jednom směru (pak jde o simplexní přenos), nebo v obou směrech (pak jde o duplexní přenos).

S tím úzce souvisí i pojmy jako je kanál a okruh, které ale nepochází ani tak ze světa počítačových sítí, jako ze světa telekomunikací a spojů. Jako kanál se označuje taková přenosová cesta, která je pouze jednosměrná (tj. dá s využít pouze k simplexním přenosům). Naproti tomu okruh již je obousměrný, tj. umožňuje duplexní přenos.

Simplex, semiduplex

Příkladem čistě simplexního přenosu může být televizní a rozhlasové vysílání. To klasické (analogové) sice místo digitálních dat přenáší pouze analogový signál, ale i tak názorně ilustruje podstatu "simplexu": přenos probíhá jen jedním směrem, ke koncovým příjemcům. Stejně je na tom i teprve nastupující digitální televizní vysílání, u kterého již lze hovořit o přenosu dat. Pozemní (i satelitní) digitální vysílání, řešené na bázi standardu DVB-T (resp. DVB-S, pro satelit) totiž také počítá jen se simplexním přenosem.

Představa simplexního přenosu

Pokud se tedy v souvislosti s digitálním vysílání hovoří o interaktivitě a interaktivních službách, jako například o možnosti on-line hlasování, nakupování či třeba čtení emailů, pak musí být použit ještě nějaký "externí" přenosový kanál, umožňující přenos v opačném směru, od diváka k tomu, kdo programy připravuje a vysílá. Může to být v zásadě jakýkoli kanál - třeba telefonický (vytáčené připojení k Internetu), mobilní GPRS, ADSL apod.

Představa semiduplexního přenosu

Takové přenosy, které již fungují oběma směry, ale v každém z nich jiným způsobem, se obecně označují jako semiduplexní. Někdy také jako asymetrické, ale to není příliš šťastné. Toto adjektivum se častěji používá k vyjádření rozdílu v rychlostech přenosu v obou směrech, a nikoli v technice přenosu, resp. druhu použitého přenosového kanálu.

Plný duplex, poloviční duplex

I v případě obousměrných přenosů připadají v úvahu různé varianty, mezi kterými je třeba rozlišovat. Někdy je totiž komunikace v obou směrech sice možná, ale nikoli současně. To je případ tzv. polovičního duplexu, který

umožňuje v každém okamžiku přenášet jen jedním směrem. Je to analogie železniční tratě s jednou kolejí - vlaky po ní mohou jezdit oběma směry, ale nikoli současně.

Naproti tomu varianta, kdy je možné přenášet oběma směry současně, je označována jako tzv. plný duplex. V rámci analogie s železnicí by to dopovídalo dvojkolejné trati. Ještě ale k terminologii: někdy se lze i v češtině setkat s anglickými názvy "half-duplex" (poloviční duplex, zkráceně poloduplex), a "full duplex" (plný duplex).

Duplexní a poloduplexní přenosy

Důležité také je uvědomit si, že různé varianty "duplexů" se nemusí týkat pouze schopností přenosových médií a cest (resp. okruhů, v terminologii spojů) jako takových. Mohou vypovídat také o tom, jak jsou tyto schopnosti využívány pro konkrétní přenosy. Například: můžeme mít přenosovou cestu, která je sama o sobě plně duplexní. Z nějakého důvodu ji ale budeme využívat pouze poloduplexně. To znamená, že nad plně duplexní přenosovou cestou budou probíhat pouze poloduplexní přenosy.

Dělat to obráceně, tj. realizovat plně duplexní přenosy nad poloduplexní (či dokonce jen simplexní) přenosovou cestou není v principu možné. Lze to ale snadno obejít: stačí vzít dvě přenosové cesty (ať již poloduplexní či plně simplexní), a každou z nich používat pro přenos jedním směrem. Příkladem mohou být přenosy po optických vláknech, které jsou (bez dalších opatření) pouze simplexní. Stačí ale použít po jednom vlákně pro každý směr, a již je možné realizovat plně duplexní přenosy.

Channel bundling

Další oblíbenou technikou, která souvisí s přenosovými kanály a jejich "duplexností", či spíše "simplexností", je jejich slučování, resp. skládání (známější spíše pod anglickým výrazem "channel bundling", případně "channel bonding"). Jde o to, že v praxi nemusíme mít vždy k dispozici takový přenosový kanál, který by svými parametry (hlavně rychlostí, resp. přenosovou kapacitou) odpovídal potřebám zamýšlených přenosů. Někdy ale můžeme získat takovýchto kanálů více, a používat je souběžně. Vlastně z nich jakoby složit jeden větší (širší, resp. rychlejší) přenosový kanál, který již vystačí našim potřebám. Právě tomu se říká "channel bundling".

Představa channel bundlingu

praxi se s takovýmto spojováním kanálů můžeme setkat například u přípojek ISDN. Ty nabízí přenosové kanály (kanály B, fakticky jde o obousměrné okruhy) o rychlosti 64 kbit/s. Pokud nám tato jejich rychlost nestačí, můžeme je spojovat (na principu channel bundlingu) do větších celků, odpovídajících celistvým násobkům. Tj. vezmeme vždy patřičný počet jednotlivých kanálů a používáme je jako jeden výsledný (sloučený, "bundlovaný") kanál. Pozor ale na to, že právě u ISDN přípojek je použití jednotlivých kanálů standardně zpoplatněno, a to samostatně. Takže když použijeme n kanálů současně, platíme nx více!

Jiným příkladem mohou být mobilní sítě GSM. Ty vlastně také nabízí dílčí přenosové kanály (byť se jim říká timesloty, tj. časové sloty, viz dále), a v každém z nich lze dosáhnout určitou přenosovou rychlost (standardně buď 9,6 kbit/s v případě Oskara a T-Mobile, a 14,4 kbit/s u Eurotelu). Pokud chceme dosáhnout vyšší rychlosti, například v rámci služeb GPRS, musíme použít více takovýchto dílčích kanálů (timeslotů) současně. Kolik jich skutečně využijeme, to záleží na více faktorech: na tom, zda je mobilní síť má momentálně k dispozici, zda je provozovatel sítě (operátor) ochoten je uvolnit (resp. přidělit více timeslotů stejnému uživateli), a také zda naše mobilní zařízení je schopné pracovat s více timesloty současně. Například když se o nějakém zařízení dočtete, že podporuje GPRS se 4+2 timesloty, znamená to, že je schopné využít nejvýše 4 timesloty pro přenosy ze sítě, a nejvýše 2 pro přenosy opačným směrem (do sítě).

Multiplex a inverzní multiplex

Techniku slučování kanálů (channel bundlingu) si můžeme představit jako řešení problému s neexistencí dostatečně velkého (širokého) přenosového kanálu. Místo něj se tedy použije patřičný počet menších (užších) kanálů, mezi které se celkový datový tok rozloží. V praxi ale často nastává i přesně opačný problém: máme jeden větší (širší) přenosový kanál, a potřebujeme jej rozdělit na několik dílčích částí, které by se chovaly jako samostatné a na sobě nezávislé kanály. Tedy tak, aby po nich bylo možné přenášet několik zcela samostatných a na sobě nezávislých datových toků.

Řešení právě popsaného úkolu (rozdělení jednoho přenosového kanálu, případně okruhu, na více částí) se obecně označuje jako "multiplexování", resp. multiplex. Jeho představu obecně naznačuje následující obrázek, který jej dává do protikladu s již popsaným slučováním kanálů (channel bundlingem). Snad je z tohoto obrázku dostatečně zřejmé, proč se technice slučování kanálů někdy říká také inverzní multiplex.

Představa multiplexu a inverzního multiplexu

Frekvenční multiplex

Realizace multiplexu, neboli rozdělení jednoho přenosového kanálu na více samostatně využitelných částí (kanálů), může být v praxi dosaženo více různými technikami, resp. postupy. Ty přitom mohou mít jak analogový charakter, tak i digitální charakter. Příkladem analogové techniky multiplexu je tzv. frekvenční multiplex (anglicky: FDM, Frequency Division Multiplexing). Lze si jej představit tak, že analogový signál na každém ze vstupních kanálů je posunut do jiné "frekvenční polohy" (do jiného rozsahu frekvencí), a to tak šikovně, aby se žádné tyto polohy vzájemně nepřekrývaly. Pak je možné takto frekvenčně posunuté signály jednoduše sečíst (sloučit) do jednoho "širšího" signálu, a ten přenést skrze dostatečně "široký" přenosový kanál. Na druhé straně se pak provede přesně obrácený postup: jednotlivé dílčí signály se zase od sebe oddělí, a vrátí do původní frekvenční polohy (do svého původního frekvenčního rozsahu). Představu ilustruje následující obrázek.

Představa frekvenčního multiplexu

V praxi je ovšem frekvenční multiplex nepříliš výhodný právě kvůli tomu, že jde o analogovu techniku - různé frekvenční posuny, vzájemné slučování a následné oddělování nejsou nikdy ideální, a vždy určitým způsobem znehodnocují přenášený signál. Jde jen o míru tohoto znehodnocení, tak jak ostatně u všech analogových technik.

Již v minulém dílu tohoto seriálu jsme si ukazovali ještě jednu variantu analogového multiplexu - multiplex vlnový (WDM, Wavelength Division Multiplexing). Byl založen na tom, že skrze jedno optické vlákno se přenášelo více "svazků" světla, každý o trochu jiné frekvenci, s tím že každý se choval samostatně (jako samostatný přenosový kanál). V zásadě tedy šlo o specifickou variantu frekvenčního multiplexu.

Připomenutí: představa vlnového multiplexu

Časový multiplex

Z digitálních technik multiplexu je asi nejčastější multiplex časový (anglicky: TDM, Time Division Multiplexing). Ten si můžeme představit tak, že jeden "širší" přenosový kanál rozděluje v čase - vždy jej na krátký časový úsek (časový slot, timeslot) přidělí celý jednomu vstupnímu kanálu, na další krátký časový úsek (časový slot) jej svěří jinému vstupu atd., a tak stále dokola.

Pokud tato představa není zcela srozumitelná, lze si pomocí analogií s vláčkem a vagónky: skrze "širší" přenosový kanál, který je dělen v čase pomocí časového multiplexu, projíždí nekonečně dlouhý vláček. Má nekonečně mnoho vagónků, které jsou všechny stejně velké (uvezou stejně velký náklad), a jsou také pevně

přiřazeny jednotlivým vstupům. Například tak, že první vstupní kanál má vyhrazeny vagónky č. 1, 3, 5, 7 atd., druhý vstup vagónky č. 2, 6, 10, 14 atd., a třetí vstup vagónky 4, 8, 12 atd.

Nebo nějak jinak, v zásadě jakkoli - ale s důležitým dovětkem, že toto přidělení je pevně dáno a předem známo. Příjemce tedy nemusí nikdy přemýšlet o tom, komu patří obsah toho kterého vagónku (časového úseku, resp. slotu). Jelikož zná příslušnou konvenci, okamžitě ví, na který výstup má předat obsah toho kterého vagónku (časového úseku, timeslotu).

Představa časového multiplexuu

Rozdělení celkové přenosové kapacity (přidělení všech vagónků nekonečně dlouhého vláčku) přitom nemusí být vůbec rovnoměrné. Časový multiplex může rozdělovat celkovou přenosovou kapacitu "širšího" přenosového kanálu na různě velké části (různě velké dílčí přenosové kanály). Stále však platí, že toto rozdělení je pevně dáno a nemění se v čase.

Statistický multiplex

Fixní a v čase neměnný způsob rozdělení přenosové kapacity u časového multiplexu může být jak výhodou, tak i nevýhodou. Výhodou je v situaci, kdy jednotlivé vstupy generují rovnoměrné datové toky, bez významnějších odchylek v čase. Pak skutečně má smysl a je efektivní rozdělit celkovou přenosovou kapacitu na příslušný počet částí, a toto rozdělení dále neměnit. Jinak je tomu ale v situaci, kdy se objemy dat, procházející přes jednotlivé vstupu, v čase významněji mění a kolísají. Problém nastává, když je skutečný objem dat k přenesení menší, než bylo původně očekáváno (a odpovídá rozdělení pomocí časového multiplexu). Pak totiž zůstává část přidělené kapacity nevyužita a není možné ji přenechat jinému vstupu, který by ji naopak naléhavě potřeboval, protože právě potřebuje přenést naopak více dat. Pokud je třeba reflektovat měnící se zátěž (datové toky) na jednotlivých vstupech, a podle ní průběžně upravovat rozdělení celkové přenosové kapacity na příslušný počet částí, už je nutné místo časového multiplexu použít multiplex statistický (anglicky: STDM, Statistical Time Division Multiplexing). Jeho podstatu si lze přiblížit tak, že každý časový úsek (resp. vagónek, v analogii se železnicí) nemá pevně a dopředu určeno, jaký náklad bude přenášet. Místo toho může být přidělen podle momentální potřeby tomu vstupu (dílčímu přenosu), který jej právě potřebuje.

To má ale jeden závažný důsledek: příjemce se už nemůže spoléhat na to, že dopředu zná konvenci o rozdělení celkové přenosové kapacity, a tudíž dopředu ví, komu patří obsah toho kterého časového úseku (timeslotu, vagónku). Místo toho musí u statistického multiplexu každý časový úsek sám o sobě a explicitně říkat, jaký obsah přenáší. Spolu s "užitečnými" daty tak musí nést nějakou režijní hlavičku, ve které je potřebná informace o příslušnosti dat obsažena.

Představa statistického multiplexu

Kolísání objemu dat na jednotlivých vstupech, se kterým si statistický multiplex dokáže poradit (zatímco časový nikoli), může mít velmi racionální původ. Je jím zejména použití různých kompresí, který usilují co nejvíce zmenšit objem dat, určených k přenosu. Například při kompresi zvuku (hlasu) či obrazu je úspěšnost komprese, a s ní i velikost komprimovaných dat, závislá na dění na scéně, resp. na průběhu zvuku. Naproti tomu bez použití komprese by generovaný objem dat byl stejný bez ohledu na to, co se na scéně právě děje, zda právě někdo mlčí či naopak mluví atd. Ve stručnosti proto lze konstatovat, že časový multiplex je vhodný pro nekomprimované přenosy, zatímco statistický je vhodný pro přenosy využívající komprese dat.

Kódový multiplex

Pro úplnost se musíme zmínit ještě o jednom dalším druhu multiplexu, kterým je multiplex kódový (CDM, Code Division Multiplexing). Jeho princip si lze nejlépe představit na příkladu rádiových přenosů, s několika na sobě nezávislými vysílači a přijímači, přičemž všechny tyto přijímače a vysílače využívají stejný rozsah frekvencí. Vše pak funguje tak, že každý vysílač svá data nejprve vhodně zakóduje, a pak rovnou vysílá, na stejné frekvenci jako ostatní vysílače. V éteru pak sice dochází ke "smíchání" všech takto vysílaných signálů, ale důležité je, že toto smíchání není nevratné. Naopak, každý přijímač by měl být schopen z přijaté "směsi" vyextrahovat právě to, co vyslal ten konkrétní vysílač, jehož data chce přijímat. Představu ilustruje následující obrázek, který znázorňuje různé signály (složky) prostřednictvím barev.

Představa statistického multiplexu

Vysvětlení toho, proč je "smíchání" jednotlivých signálů v éteru vratné, a jak lze následně vyextrahovat z výsledné "směsi" jednotlivé složky, je poněkud komplikovanější a byl by spíše na samostatný článek. Ve stručnosti si ale můžeme naznačit, že vše je skryto ve způsobu, jakým jednotlivé vysílače kódují vysílaný signál, resp. data. Musí být použito takové specifické kódování (u každého vysílače jiné), které příjemci umožní provést opačný postup (dekódování), a díky němu získat ze "směsi" požadovanou původní složku či složky. Proto také označení "kódový multiplex".

Kódový multiplex má také jednu zajímavou vlastnost, kterou je vhodné zde zmínit. Pokud je použit pro rádiové přenosy, jak jsme si právě naznačili, pak je velmi šetrný vůči přírodním zdrojům, konkrétně vůči použitým frekvencím. Například takový frekvenční multiplex s nimi naopak spíše plýtvá, protože když posouvá jednotlivé složky (dílčím přenosy) do různých frekvenčních poloh, musí mezi nimi dělat i určité nenulové odstupy, aby se vzájemně neovlivňovaly a bylo možné je od sebe zase správně oddělit. Frekvenční multiplex tak vlastně přenáší svou režii do vyšší spotřeby frekvencí. Těch je ale od přírody málo, a tak je nutné s nimi hospodařit co nejefektivněji.

Naproti tomu kódový multiplex "pouští" všechny dílčí přenosy (složky) do jednoho (a tudíž stejného) frekvenčního pásma, kde dochází k jejich vzájemnému smíchání. Režie, která je spojena s jejich opětovným oddělením, jde ale na vrub výpočetní kapacitě jednotlivých odesilatelů, a hlavně příjemců. Oni musí provést příslušné dekódování, a k tomu potřebují příslušnou výpočetní kapacitu (procesor, paměť atd.). Ovšem výpočetní kapacita, na rozdíl od frekvencí, je prakticky libovolně "nafukovatelná" - lze ji přidávat podle potřeby, a její cena navíc postupně klesá.

Multiplex jako metoda řízení přístupu

Kódový multiplex je tedy šetrný vůči vzácným přírodním zdrojům (frekvencím). To je důvod, proč je s oblibou používán i v situaci, kdy určitý počet stanic soupeří o využití jednoho společného přenosového kanálu. K tomu dochází například v mobilních sítích, protože jejich provozovatelé (mobilní operátoři) dostali ve svých licencích k dispozici jen určitý omezený rozsah frekvencí (frekvenčních kanálů), které smí využívat. Proto se operátoři snaží využívat jednotlivé frekvenční kanály opakovaně, a kvůli tomu rozdělují svou síť na buňkyKonkrétně v ČR regulátor (Český telekomunikační úřad) vyčlenil pro potřeby mobilních sítí GSM určitý rozsah frekvencí v pásmu 900 MHz (a později i v pásmu 1800 MHz). Tento rozsah frekvencí pak rozdělil, na principu frekvenčního multiplexu, na jednotlivé frekvenční kanály, vždy o šířce 200 kHz. Celkem jich takto v pásmo 900 MHz vzniklo 124, s tím že regulátor dal každému z mobilních operátorů určitý počet - viz následující obrázek.

Frekvenční kanály, přidělené tuzemským mobilním operátorům GSM v pásmu 900 MHz

Pro nás je ale v tuto chvíli podstatné něco jiného: i v rámci každé buňky jsou frekvenční kanály určitým způsobem sdíleny jednotlivými mobilními stanicemi (terminály), resp. rozděleny mezi ně. No a k tomu je již využit multiplex časový. Když si to hodně zjednodušíme, je každý frekvenční kanál v GSM rozdělen pomocí časového multiplexu na 8 časových slotů (timeslotů).

Představu ilustruje následující obrázek:

Představa frekvenčního a časového multiplexu v GSM, v pásmu 900 MHz

Mobilní telefony v sítích GSM pak při telefonování využívají vždy jeden timeslot pro přenos (digitalizovaného lidského hlasu) v jednom směru, a jeden timeslot pro přenos v opačném směru. Jak jsme si již uvedli, pro datové přenosy se může využívat i více timeslotů současně.

Síť GSM tedy využívá techniky časového multiplexu, k řízení přístupu svých stanic ke společnému přenosovému médiu, v podobě příslušného frekvenčního kanálu. Kvůli tomuto konkrétnímu využití, pro potřeby řízení přístupu (anglicky: Access Control), se pak také hovoří o řízení přístupu na bázi časového multiplexu, zkratkou TDMA (Time Division Multiple Access), nebo o řízení přístupu na bázi frekvenčního multiplexu FDMA (Frequency Division Multiple Access).

Ovšem GSM není jediný standard pro mobilní sítě, který se používá. Vedle něj existují i jiné, využívající úplně jiné metody pro sdílení přenosového média (frekvenčních kanálů) a řízení přístupu jednotlivých stanic, než je časový multiplex, resp. TDMA. Zejména v zámoří jsou oblíbené mobilní sítě, využívající k danému účelu techniky kódového multiplexu. Ten je při daném využití (pro potřeby řízení přístupu) již označován jako CDMA (Code Division Multiple Access). Snad netřeba připomínat, že i v ČR máme jednu CDMA síť - provozuje ji Eurotel, v pásmu 450 MHz, a to výhradně pro datové přenosy (nikoli pro hlas).

TDD a FDD

Na závěr se musíme zmínit ještě o jedné související technice, a to technice tzv. duplexingu. Jak už její název napovídá, jde o způsob, jakým je v bezdrátových sítích řešena komunikace v obou směrech.

Základní možnosti jsou dvě, a ilustruje je následující obrázek: technika tzv. frekvenčního duplexu (FDD, Frequency Division Duplex) předpokládá, že pro každý ze směrů jsou použity samostatné (a tudíž různé) frekvenční rozsahy. Takto je to řešeno například v GSM, kde je fakticky vyhrazeno 2x 124 frekvenčních kanálů: 124 v pásmu 890-915 MHz pro tzv. uplink (směr od mobilního terminálu do sítě), a 124 v pásmu 935 až 960 MHz pro opačný směr, tzv. downlink. technika tzv. časového duplexu (TDD, Time Division Duplex) předpokládá, že pro komunikaci v obou směrech se používají stejné frekvence, ale střídavě v čase. Každý timeslot je vždy použit pro přenos jedním směrem, ale další timeslot již může být využit pro přenos opačným směrem.

Představa frekvenčního a časového duplexu

Zajímavé je, že obě tyto techniky si nejsou zcela rovny, pokud jde o jejich vhodnost pro potřeby datových služeb. V případě hlasových služeb ještě nikoli, protože zde je "spotřeba" přenosových kapacit v obou směrech v zásadě stejná. Ale v případě datových přenosů bývají požadavky asymetrické, konkrétně větší ve směru downlinku (od sítě k uživateli), a menší v opačném směru. Technika frekvenčního duplexu, v rámci které by pro oba směry byl vyhrazen stejný počet frekvenčních kanálů, by pak nebyla nejvhodnější. Naopak technika časového duplexu umožňuje rozkládat celkovou přenosovou kapacitu mezi oba směry podle momentálních potřeb.

Každý přenos digitálních dat je ve své podstatě přenosem jednotlivých bitů. Alespoň na nejnižší úrovni (na úrovni fyzické vrstvy) nás ještě nezajímá, zda jednotlivé bity nějak "patří k sobě" (třeba proto že společně tvoří nějaký datový rámec či paket), a každý z nich přenášíme samostatně a nezávisle na ostatních bitech. Přenos každého jednotlivého bitu ale vždy určitou dobu trvá, resp. má nějakou délku v čase. Pokud by tomu tak nebylo, a přenos každého bitu trval jen nekonečně krátký okamžik, mohli bychom dosahovat nekonečně velkých přenosových rychlostí. Místo toho musíme v praxi počítat s tím, že přenos každého bitu probíhá po určitý časový interval, kterému se ne náhodou říká "bitový interval". Během tohoto bitového intervalu se příjemce musí rozhodnout, zda vyhodnotí přijímaný bit jako 1, nebo jako 0. Můžeme si to představit tak, že někde uprostřed tohoto intervalu příjemce sejme stav přenášeného signálu, a podle něj se rozhodne, zda jde o 1 či 0.

Potřeba synchronizace

Již na této jednoduché představě (o vzorkování přijímaného signálu během bitového intervalu) si můžeme názorně ukázat jedno velké nebezpečí. Příjemce totiž musí správně odměřit začátek i konec každého bitového intervalu, tak aby se správně "strefil" se vzorkováním přenášeného signálu. Asi není těžké nahlédnout, co by se stalo, pokud by příjemce odměřil bitový interval nesprávně, v důsledku pomalejšího, nebo naopak rychlejšího "tikotu" svých hodinek - strefil by se do jiného bitového intervalu a vyhodnocoval (vzorkoval) by stav signálu v době, kdy tento již reprezentuje nějaký jiný bit. Něčemu takovému se říká "ztráta synchronizace", a je to samozřejmě nežádoucí.

Představa ztráty synchronizace mezi příjemcem a odesilatelem

Co je naopak žádoucí, resp. nutné pro korektní přenos dat, je udržování synchronizace během přenosu všech relevantních datových bitů. Můžeme si to představit také tak, že obě strany (odesilatel i příjemce) mají u sebe vlastní hodinky, pomocí kterých odměřují jednotlivé bitové intervaly - a tyto hodinky musí tikat v dostatečném

souběhu (tzv. synchronně), aby se navzájem příliš nerozešly, a nedošlo k výše popisované nežádoucí situaci (ztrátě synchronizace).

Arytmický přenos

Požadavek na zajištění potřebné synchronizace nemusí nutně znamenat, že by pomyslné hodinky na straně odesilatele a příjemce musely tikat ve vzájemném souladu (synchronně) trvale, po libovolně dlouhou dobu. Požadovaného efektu lze dosáhnout i tak, že přenos dat bude probíhat po částech (po určitých skupinách bitů), a potřebná synchronizace bude udržována pouze po dobu přenosu těchto skupin bitů. Má to tu výhodu, že pokud budou uvedené skupiny bitů dostatečně malé, nebudou na přesnost hodinek příjemce kladeny žádné extrémní nároky. Postačí, když se vhodně seřídí na začátku každé jednotlivé skupiny bitů, a vydrží tikat v potřebném tempu alespoň po dobu přenosu této krátké skupiny. Pak se už hodinky příjemce mohou klidně rozejít (ztratit synchronizaci s hodinkami odesilatele), protože na začátku další skupiny bitů dojde k novému seřízení, a vše se opakuje ….

To už jsme si popsali princip tzv. arytmického přenosu. Skupinkám bitů, které jsou tímto způsobem přenášeny, se v praxi říká znaky, a mají vždy pevnou velikost. Dnes nejčastěji 8 datových bitů, ale v úvahu připadá i pevné nastavení na 7, 6, či třeba 5 bitů.

Znak při arytmickém přenosu

Kromě toho se na začátek každého znaku přidává jeden režijní bit, v roli tzv. start bitu. Právě na něm se hodinky příjemce seřídí a začínají odměřovat bitové intervaly. Na konci znaku pak může (ale nemusí) následovat ještě tzv. stop bit, pro zajištění určitého minimálního odstupu od dalšího znaku, a pak také tzv. paritní bit, sloužící potřebám zabezpečení přenosu a umožňující detekovat případné chyby v přenosu.

Při arytmickém přenosu mohou být mezi znaky libovolné odstupy

Zdůrazněme si spíše jinou věc: to, že mezi přenosem jednotlivých znaků mohou být libovolně dlouhé prodlevy. Nemusí tedy být dodržován stejný "rytmus" odesílání jednotlivých znaků (stejné odstupy mezi nimi). Právě tomuto aspektu vděčí tento způsob přenosu za své označení: arytmický.

Arytmický, nebo asynchronní?

Po přečtení předchozích řádků vás možná napadne, zda je popis arytmického přenosu míněn vážně, a zda nejde o nějaký omyl - když v praxi se popsanému způsobu přenosu, se stejně velkými znaky, start bity atd. říká "asynchronní", a nikoli "arytmický".

Je zde skutečně drobný terminologický zádrhel: věcně správně je označení arytmický přenos, ale v praxi se mu neřekne jinak, než asynchronní přenos. Je to tedy další příklad toho, kdy se v počítačové branži říká A, ale myslí se B.

Jiným takovým příkladem je použití zkratky RAM (z anglického Random Access Memory). Ačkoli správně označuje paměť s tzv. přímým přístupem (Random Access), běžně se zkratkou RAM myslí paměť pro čtení i zápis, která je protipólem k paměti ROM (Read Only Memory). Správně by ale paměť pro čtení i zápis měla být označována jako paměť RWM (Read/Write Memory).

Zpět ale k asynchronním a arytmickým přenosům: skutečně asynchronní přenos je takový, který zcela postrádá jakoukoli synchronizaci mezi příjemcem a odesilatelem (proto: a-synchronní). Jak ale potom příjemce pozná, kdy začíná a kdy končí jednotlivé bitové intervaly? Pouze tak, že mu to odesilatel explicitně řekne. Tedy že kromě dvou stavů přenášeného signálu, které reprezentují "užitečné" datové hodnoty 1 a 0, existuje ještě třetí možný stav, který indikuje právě začátek a konec bitového intervalu. Je k tomu tedy zapotřebí alespoň tzv. tříhodnotová logika, což je pro reálně využití problematické.

Představa (skutečně) asynchronního přenosu, s využitím třetího stavu pro oddělení jednotlivých bitových intervalů

Spíše zajímavostí je pak to, že jednotlivé bitové intervaly u (skutečně) asynchronního přenosu mohou být různě dlouhé, jak ostatně naznačuje i obrázek. Otázkou ale je, k čemu by to bylo dobré.

Synchronní přenos

Vedle asynchronního (správně: arytmického) přenosu je běžně používanou variantou také tzv. synchronní přenos, resp. "plně synchronní" přenos. Jak už jeho označení napovídá, je u něj synchronizace mezi odesilatelem a příjemcem udržována dlouhodobě - buďto trvale, nebo alespoň po dobu přenosu (libovolně velkého) datového bloku. Předností je pak vyšší efektivnost přenosu: jelikož se synchronizace neztrácí, ale udržuje trvale, není nutné oddělovat od sebe skupinky bitů (znaky). Místo toho je možné přenášet data "souvisle", po větších datových blocích (v zásadě libovolně velkých). Jak ale dosáhnout toho, aby odesilatel a příjemce zůstali trvale synchronizováni, resp. aby se jejich hodinky nikdy nerozešly a stále "tikaly" v dostatečném vzájemném souladu? Tady už se nedá aplikovat podobný přístup, jako u přenosu asynchronního (správně arytmického): seřídit (zasynchronizovat) obě strany na začátku datového bloku, analogií start bitu, a pak se spoléhat na to, že během přenosu celého bloku se hodinky příjemce nerozejdou více, než je přípustné. To jde u malých znaků, tvořených jen několika bity, ale už ne u datových bloků s stovkách bytů, či ještě delších.

V případě (plně) synchronního přenosu je nutné udržovat synchronizaci průběžně. Tedy průběžně seřizovat hodinky příjemce. Ale jak?

Principiálně nejjednodušší by bylo přenášet tikot hodinek odesilatele až k příjemci, pomocí vhodného "hodinového" signálu (pravidelně se měnícího signálu, který odměřuje tikot hodinek odesilatele). Pak by na straně příjemce bylo vše jednoduché - stav dat by se vyhodnocoval v okamžicích, určených tímto hodinovým signálem.

Představa využití samostatného (hodinového) signálu pro zajištění trvalé synchronizace

Ovšem samostatný hodinový signál, pro zajištění plné synchronizace, je poměrně velký luxus, který si většinou můžeme dovolit jen na krátkou vzdálenost. Ke svému přenosu totiž vyžaduje samostatný vodič (resp. pár vodičů), což je na delší vzdálenost příliš drahé. Proto se v praxi používá spíše jiné řešení, které co do efektu vyjde vlastně nastejno, ale vystačí jen s jedním vodičem. Spočívá v tom, že se použije jen jeden vodič, po kterém se přenáší oba signály (hodinový i "datový") současně, sloučené do jednoho výsledného signálu. Představu ukazuje následující obrázek.

Představa sloučení hodinového signálu a signálu nesoucího data, do jediného signálu

Konkrétních způsobů, jak sloučit hodinový a datový signál do jednoho výsledného signálu, existuje více. Poněkud nesprávně se tomu říká "kódování". Dvě taková často používaná kódování ukazuje následující obrázek.

Jde o kódování Manchester, a tzv. diferenciální Manchester.

Kódování Manchester a diferenciální Manchester

U kódování Manchester, které se používá například v původní desetimegabitové verzi Ethernetu, jsou oba signály sloučeny tak, že v každém bitovém intervalu dochází nejméně k jedné změně signálu. Právě tato změna (uprostřed bitového intervalu) pak nese užitečná data - jde-li o změnu z vysoké úrovně signálu do nízké (ve smyslu obrázku), jde o 0, zatímco hodnota 1 je reprezentována opačnou změnou (z nízké na vysokou úroveň). Současně tato změna slouží i potřebám synchronizace - při každé takovéto změně si příjemce může znovu seřídit své hodinky.

Aby však v každém bitovém intervalu mohlo dojít k takové změně signálu, která potřebným způsobem reprezentuje přenášená data, může být nutná ještě jedna další změna. Například když se přenáší více stejných bitů (více 0, nebo naopak více 1), pak je každý z těchto bitů reprezentován stejně orientovanou změnou. Aby však takováto změna mohla v každém bitovém intervalu nastat, musí být vždy provedena ještě jedna opačná změna - viz předchozí obrázek.

Takže obecně musí na každý bitový interval (datový bit) připadnout dvě změny přenášeného signálu. To je poměrně velké plýtvání, které se nevyhýbá ani druhé variantě - diferenciálnímu kódování Manchester. Zde je hodnota 0 reprezentována změnou signálu (bez ohledu na pointaci této změny), a hodnota 1 naopak absencí změny signálu - a to na začátku bitového intervalu. Delší posloupnost hodnoty 1 by však mohla způsobit ztrátu synchronizace. Proto se u diferenciálního kódování Manchester v každém bitovém intervalu provádí ještě jedna změna (uprostřed bitového intervalu), která tentokráte již slouží pouze potřebám časování. Takže zatímco u "normálního" (nikoli diferenciálního) kódování Manchester slouží jedna hrana oběma účelům současně (a eventuelní druhá hrana vlastně jen připravuje půdu pro novou změnu), u diferenciálního kódování Manchester má každý účel svou vlastní hranu.

Bit stuffingPotřeba dvou změn signálu na každý datový bit, vynucená potřebami synchronizace, je skutečně velký luxus. Ve své podstatě znamená, že "spotřeba" (ve smyslu počtu změn, resp. modulační rychlosti) je dvojnásobná oproti "užitku" (přenosové rychlosti v bitech za sekundu). Něco takového je možné si dovolit tam, kde je přenosové kapacity dostatek, ale to není zdaleka všude. Snaha odstranit naznačené plýtvání je dobře patrná například u Ethernetu, jehož původní desetimegabitová verze používá kódování Manchester, ale jeho rychlejší verze (stomegabitový Ethernet, gigabitový Ethernet atd.) již používají efektivnější metody kódování.

Všechny tuto efektivnější metody jsou přitom založeny na společném principu: místo toho, aby se "jedna změna navíc", nutná k zajištění synchronizace, přidávala ke každému jednotlivému datovému bitu (resp. k "datové" změně signálu), což vlastně představuje 100% režii, přidává se vždy až ke skupince několika datových bitů (resp. "datových" změn signálu). Pokud se například přidává ke čtyřem datovým bitům (změnám) jedna režijní změna pro potřeby zajištění synchronizace, už s místo 4 užitečných změn přenáší změn 5, a to odpovídá režii ve výši 25%. Takovéto konkrétní kódování se pak označuje jako 4B/5B, a používá se konkrétně u stomegabitového Ethernetu.

Pokud bychom v tomto trendu pokračovali co možná nejdéle, mohli bychom se s výší režie limitně přiblížit až k nule. V takovémto ideálním stavu by byly všechny změny využity pro "užitečná" data, s tím že příjemce by udržoval potřebnou synchronizaci právě a pouze podle těchto "datových" změn.I v tomto ideálním stavu bychom ale stále museli myslet na to, že určitá posloupnost dat (v závislosti na použitém způsobu kódování, resp. reprezentování datových bitů prostřednictvím přenášeného signálu) by mohla způsobit, že příjemce nedostane včas žádnou hranu, a jeho hodinky se "rozejdou" více, než je přípustné. Řešení naštěstí není nijak komplikované, a spočívá v umělém zařazení "bitu navíc" těsně předtím, než by ztráta synchronizace hrozila. Naznačuje to i následující obrázek, pro případ že 1 a 0 jsou reprezentovány vysokou, resp. nízkou úrovní signálu, a hodinky příjemce nevydrží v synchronizaci déle, než 7 bitových intervalů. V takovém případě se po každé posloupnosti sedmi bitů napevno zařadí do přenášeného toku dat jeden opačný bit.

Představa bit stuffingu

V angličtině se této technice říká bit stuffing, doslova: vkládání bitů.

Bitstream (bitový proud)

Když už víme, co je (plně) synchronní přenos, můžeme si jej poněkud zobecnit - do podoby jednoduché přenosové služby, realizované fyzickou vrstvou, a označované jako tzv. bitový proud (anglicky: bitstream). Zajišťuje dvoubodové spojení (tj. vede přímo mezi dvěma uzly), je obvykle obousměrná, a chová se jako synchronně fungující roura: z jedné strany se do ní postupně vkládají jednotlivé bity, a z druhé strany zase tyto bity ve stejném pořadí vystupují. Hlavní výhodou takovéto přenosové služby, přenášející nijak nečleněný proudu bitů, je ten že nad ní lze realizovat v zásadě jakoukoli přenosovou službu vyšší úrovně. Tedy nejen přenos dat na principu přepojování paketů (či rámců), ale také přenos dat na principu přepojování okruhů. První možnost je vhodná pro datové služby (v praxi například pro přístup k Internetu), zatímco druhá je zase výhodná pro multimediální služby (například pro přenos hlasu či obrazu), s potřebou garantované kvality a garantovaných parametrů (například přenosového zpoždění a jeho pravidelnosti).

Představa bitového proudu (bitstreamu), a nad kterým je realizován přenos paketů (rámců)

Bitový proud (bitstream) je tedy jakýmsi "ideálním podložím", nad kterým lze budovat široké portfolio služeb - od negarantovaných datových služeb, až po garantované služby, vhodné pro multimédia. Samotný bitstream se dá realizovat například na místních smyčkách (účastnických vedeních), pomocí technologií xDSL.

V ČR však takovýto bitstream není dostupný. Český Telecom, který vlastní prakticky všechny mostní smyčky, nabízí ostatním operátorům až přenosové služby vyšší úrovně, realizované na principu přepojování paketů a fungující negarantovaným způsobem. Jinými slovy: místo samotného "podloží" v podobě bitstreamu, nad kterým by alternativní operátoři mohli implementovat své vlastní přenosové služby (vhodné pro data i pro multimediální přenosy), jim Telecom povinně přidá (a nechá si zaplatit) své vlastní přenosové služby - fungující na principu

přepojování paketů, konkrétně na bázi protokolu IP. Teprve tyto služby pak zprostředkovává alternativním operátorům na velkoobchodní bázi. Rozdíl je v tom, že pokud by alternativní operátoři měli přístup k bitstreamu, mohli by sami určovat to, jaké přenosové služby nad ním vybudují. Pak by například mohli nabízet ADSL přípojky k Internetu s takovými rychlostmi a stupni sdílení (agregace), jaké si zvolí sami. Místo toho jsou vázáni tím, co rozhodl a určil Telecom (např. co do rychlostí a agregace), a co zabudoval do svých přenosových služeb nad bitstreamem.

Isochronní a ne-isochronní přenos

Pro docenění toho, jak univerzální je bitový proud (bitstream), si ještě řekněme co je tzv. isochronní přenos. Samotný přívlastek "iso-chronní" je možné přeložit jako "probíhající ve stejném čase", nebo alespoň "rovnoměrně v čase". Isochronní přenos je tedy takový, který doručuje data dostatečně rychle (s garantovaným maximálním zpožděním) a také pravidelně (s garantovaným maximálním rozptylem doby zpoždění). Naopak "ne-isochronní" je takový přenos, který toto nenabízí.

Jistě není těžké nahlédnout, že multimediálním službám (například živému hlasu a obrazu) svědčí isochronní přenosy, zatímco typickým datovým aplikacím (jako třeba elektronické poště, přenosu souborů, WWW atd.) plně postačují i neisochronní přenosy. Ne-isochronní přitom jsou zejména přenosy na principu přepojování paketů (anglicky: packet switching). Tedy například přenosy, realizované protokolem IP, z rodiny TCP/IP. To proto, že tento přenosový protokol negarantuje, jak dlouho se jednotlivé pakety "zdrží po cestě", zejména uvnitř přepojovacích uzlů (směrovačů). Všem totiž měří stejně, a tak se rychlost "zpracování" každého jednotlivého paketu odvíjí od momentálního souběhu s dalšími pakety, od jiných přenosů. Naproti tomu isochronní jsou přenosy na principu tzv. přepojování okruhů (anglicky: circuit switching). Je to dáno tím, že při přepojování paketů je každému přenosu vyhrazena určitá přenosová kapacita, o kterou již nemusí soutěžit s jinými přenosy. Díky tomu může být "zdržení" dat po cestě dostatečně malé a také dostatečně pravidelné (stejné).

Isochronní způsob fungování zachovává také tzv. časový multiplex, který jsme si popisovali v minulém dílu tohoto seriálu (protože každému dílčímu přenosu pevně vyhrazuje určitou přenosovou kapacitu). Naproti tomu tzv. statistický multiplex již isochronní není, protože obecně negarantuje přenosovou kapacitu žádnému z dílčích přenosů (ale rozděluje ji podle momentální potřeby, s tím že se "nemusí dostat na všechny").

Pokud bychom chtěli nějakým způsobem dodatečně vylepšit přenosové služby na principu přepojování paketů, tak aby se co možná nejvíce blížily isochronnímu způsobu fungování, pak by určité možnosti existovaly. Obecně se tomu říká "zajištění kvality služeb" (QoS, Quality of Service), ale je to drahé a komplikované. Mnohem jednodušší a efektivnější je vybudovat souběžně oba dva druhy služeb - garantované služby isochronního charakteru, a negarantované služby ne-isochronního charakteru - nad takovým "podložím", které jejich souběh umožňuje. A takovýmto podložím je právě bitstream. Ten je svou podstatou sám isochronní, a tak lze jeho kapacitu rovnoměrně rozdělit na dvě části - jednu využít pro isochronní přenosové služby (např. pro potřeby přenosu hlasu a obrazu), a druhou pro ne-isochronní služby (pro datové služby). Nebo ji využít celou pro ne-zcela isochronní služby, ale s lepšími přenosovými parametry. Podstatné je, že možností je celá řada, a nad bitstreamem není žádná z nich vyloučena.

Některé aplikace vyžadují, aby přenosy dat fungovaly spolehlivě a nedocházelo při nich k žádným chybám ani ztrátám. Jiným aplikacím naopak nějaké to poškození dat až tak nevadí, a dávají přednost rychlosti, pravidelnosti a malému zpoždění. Když už je ale spolehlivý přenos požadován, jakým způsobem ho zle zajistit? Co jsou detekční a samoopravné kódy? Jak funguje potvrzování a jaké má varianty?

Na první pohled by se mohlo zdát, že když se někde přenáší nějaká data, mělo by jít o přenos spolehlivý. Tedy takový, který data ani neztratí, ani nedopustí, aby se při přenosu poškodila (změnila). Ostatně, k čemu by pak byl nějaký "nespolehlivý" přenos? Na druhý pohled už to ale tak jasné není. V praxi totiž mohou existovat, a také reálně existují, takové situace a účely, kterým lépe vyhovuje nespolehlivý přenos. Samozřejmě nikoli takový, který nějak samovolně (sám od sebe) zahazuje či poškozuje přenášená data. "Nespolehlivostí" se myslí to, že když už k nějakému problému dojde (něco se ztratí či poškodí), přenosový mechanismus nepovažuje za svou povinnost postarat se o nápravu. Takže s tím, co se ztratilo, si neláme hlavu, a nad tím, noc se poškodilo, mávne rukou (zahodí to) - a hlavně se nezdržuje a pokračuje dál, jako kdyby se nic nestalo.

Spolehlivost může vadit

Naopak, pokud by se jednalo o spolehlivý přenos, měl by ten, kdo ho zajišťuje, v takové situaci plné ruce práce s nápravou toho, co se stalo. Musel by nejprve zjistit, že vůbec došlo k něčemu nežádoucímu - a pak by si musel vyžádat nový (opakovaný) přenos těch dat, která se ztratila či přišla poškozená. To by ale způsobilo poměrně velké zdržení, které by současně nabouralo průběžné doručování přenášených dat. A právě to může někomu (resp. něčemu) docela vadit. Představme si třeba, že jde o přenos nějakého živého obrazu, a tento je přenášen po vzoru filmového pásu - každé políčko jako jeden samostatný blok (paket či rámec). Příjemce potřebuje dostávat takovéto bloky pravidelně, aby je mohl stejně pravidelně zobrazovat (posouvat filmový pás konstantní rychlostí). Pokud by ale došlo na opakování přenosu nějakého bloku (políčka na filmovém pásu), pravidelnost by se okamžitě narušila, a lidské oko by to ihned poznalo. Kolísání rychlosti posuvu filmového pásu lidské oko zaregistruje poměrně spolehlivě. Naproti tomu výpadek či poškození (zkreslení) jednoho políčka na filmovém pásu nemusí lidské oko ani postřehnout. Pak je ale rozumnější oželet nějaký ten výpadek (ztracené políčko) či zkreslení (poškození políčka), před narušením pravidelnosti přísunu dat. Navíc takový dočasný výpadek či zkreslení lze relativně snadno "zaretušovat" (interpolací z předchozích a následujících snímků), díky inteligenci a výpočetní kapacitě na straně příjemce.

Někdy je lepší to, jindy ono

Celkově tedy lze konstatovat, že existují případy a situace, kdy je výhodnější nespolehlivý přenos, který dává přednost pravidelnosti doručování dat, před spolehlivým přenosem. Například v již popisovaném případě multimediálních přenosů (živého zvuku a obrazu). Existují ale i jiné důvody pro preferenci nespolehlivého přenosu před přenosem spolehlivým. Podstata tohoto důvodu je v tom, že ani spolehlivý přenos není nikdy zcela a stoprocentně spolehlivý. I jemu totiž může "proklouznout" nějaká ta chybička v přenášených datech, i když pravděpodobnost je zde opravdu velmi malá. Nicméně mohou existovat i takové aplikace, kterým takováto "nedostatečná spolehlivost" vadí. Třeba takové bankovní aplikace, převádějící peníze z účtu na účet, si musí dávat opravdu velký pozor na každou nulu, desetinnou tečku či čárku atd. Takovéto aplikace si pak obvykle zajišťují spolehlivost samy, na takové úrovni jakou samy potřebují. Problém je pak ale v tom, že není rozumné zajišťovat spolehlivost dvakrát, či dokonce vícekrát (na různých úrovních, resp. vrstvách, "nad sebou"). Ne, že by to nešlo. Jde to, ale je to nevýhodné. Zajištění spolehlivosti sebou totiž přináší nenulovou režii, a to jak co do spotřeby výpočetní kapacity (je nutné zjišťovat, jestli k chybě došlo), tak především co spotřeby přenosové kapacity a přenosového zpoždění (na opakování přenosu poškozených dat). No a pokud se spolehlivost zajišťuje na více vrstvách, režie s tím spojená se v lepším případě pouze sčítá, v horším násobí či kombinuje ještě nevýhodněji. Takže z hlediska režie je jednoznačně výhodnější, aby se spolehlivost zajišťovala jen jednou, a to tam kde je skutečně zapotřebí - a "pod tím" (tj. na nižších úrovních), se spolehlivost nezajišťovala a přenosy fungovaly nespolehlivě.

Asi nejlépe to je vyřešené v rámci rodiny protokolů TCP/IP, kde základní přenosový protokol síťové vrstvy (protokol IP) funguje nespolehlivě. Nad ním, na úrovni transportní vrstvy, pak existují dva transportní protokoly:spolehlivý protokol TCP, Transmission Control Protocol (tj. zajišťující spolehlivost) nespolehlivý protokol UDP, User Datagram Protocol (tj. nezajišťující spolehlivost)

Jednotlivé aplikace si pak mohou svobodně vybrat, který z obou transportních protokolů využijí. Pokud si spolehlivost chtějí zajistit samy, nebo o ni naopak nestojí, vybírají si protokol UDP.

Pokud o spolehlivost přenosů stojí a nechtějí si ji zajišťovat samy, volí protokol TCP.

Představu ukazuje následující obrázek (č. 1).Obr. 1: Aplikace v TCP/IP si samy volí mezi dvěma vzájemně alternativními transportními protokoly, TCP a UDP

Když už tušíme, jak je to se spolehlivostí přenosu dat - že je žádoucí jen někdy, a nikoli vždy - pojďme si nyní říci, jak se jí vlastně dosahuje. Nebo spíše: jak se spolehlivost přenosu zvyšuje (když už víme, že není nikdy absolutní).

I tento úkol si ale musíme rozdělit na dvě samostatné části, abychom se v tom snáze vyznali:na detekci chyb, a na na nápravu detekovaných chyb

Detekcí chyb se rozumí již samotné zjištění toho, že se "něco stalo" - že došlo k nějaké nestandardní situaci, konkrétně k nějaké chybě v přenášených datech. Správně by sem měla patřit také úplná ztráta přenášeného bloku dat (paketu, rámce), ale k tomu se dostaneme záhy. Nyní se soustředíme na to, jak příjemce dokáže rozpoznat, že v přijatých datech je nějaká chyba.

Zabezpečovací údaj

Aby příjemce mohl rozpoznat, zda přijatá data jsou či nejsou v pořádku, musí k nim odesilatel "přibalit" určitý dodatečný údaj, kterému se obecně říká "zabezpečovací údaj". Odesilatel tento zabezpečovací údaj určitým způsobem vypočítá z dat, která mají být odeslána. Pak je přidá k těmto (užitečným) datům, a přenese k příjemci výsledný celek, viz obrázek (č. 2).

Obr. 2.: Představa přenášeného bloku dat, obsahujícího zabezpečovací údaj

Příjemce postupuje obdobně: vezme přijatá (užitečná) data, sám z nich vypočítá zabezpečovací údaj (přesně stejným postupem, jako to dělal odesilatel), a výsledek porovná se zabezpečovacím údajem, který mu přišel od odesilatele spolu s daty. Pokud se oba zabezpečovací údaje liší, může z toho příjemce usuzovat, že se něco po cestě poškodilo, a vyžádat si opakované zaslání týchž dat. Samozřejmě se mohlo stát i to, že se užitečná data přenesla v pořádku, a poškozen byl pouze přenášený zabezpečovací údaj - ale toto příjemce nedokáže rozlišit.

V opačném případě, tj. pokud se oba zabezpečovací údaje shodují, příjemce předpokládá že přenos proběhl bez chyb a pokračuje dál. Opět ale nemá stoprocentní jistotu, že tomu tak skutečně je. Představu ukazuje následující obrázek (č. 3).

Obr. 3.: Představa použití zabezpečovacího údaje při přenosu dat

Mechanismy detekce chyb

Důvod, proč příjemce nemůže mít stoprocentní jistotu o bezchybnosti přenosu, a to ani v případě shody obou zabezpečovacích údajů, je prostý - stoprocentní nejsou již samotné mechanismy detekce, podle kterých je konstruován zabezpečovací údaj, a podle kterých se chyby detekují. I těmto mechanismům může občas nějaká ta chybička utéci (zůstat bez povšimnutí).

Jaké mechanismy se ale používají pro detekci chyb, a jak vlastně fungují? Mezi nejjednodušší, ale bohužel také nejméně účinné, patří tzv. parita. Její princip je jednoduchý: bity, které mají být přeneseny, se doplní o další bit (tzv. paritní bit), který se nastaví tak, aby celkový počet bitů byl buď sudý (pak jde o tzv. sudou paritu), nebo naopak lichý (tzv. lichá parita). Představu (sudé parity) ukazuje následující obrázek (č. 4)..

Obr. 4: Představa sudé parity

Jistě není těžké nahlédnout, že parita dokáže odhalit (detekovat) chybu v lichém počtu bitů. Ovšem chyby v sudém počtu bitů se z pohledu parity vzájemně ruší, a nejsou tedy detekovány. V praxi bývají paritou (paritním bitem) opatřovány relativně malé skupiny bitů, kde pravděpodobnost výskytu chyby je relativně malá. Tedy například jednotlivé byty či slova (dvojice bytů, čtveřice atd.). Příkladem může být asynchronní (správně arytmický) přenos, o kterém jsme si říkali v minulém dílu tohoto seriálu.

V případě přenosu větších datových bloků (rámců, event. paketů) je dnes použití parity spíše vzácností, a to kvůli její relativně malé účinnosti. Ale když už je i zde parita použita, může být použita dvěma různými způsoby (event. současně):jako tzv. příčná parita, kdy je každý byte (či slovo) v přenášeném bloku opatřen vlastním paritním bitem jako tzv. podélná parita, kdy jsou jedním paritním bitem zabezpečeny "stejnolehlé" bity ve všech bytech, resp. slovech přenášeného bloku.

Vše názorně ukazuje následující obrázek (č. 5)..

Obr. 5: Podélná a příčná parita

Na příkladu parity si také můžeme zdůraznit jeden významný aspekt, který souvisí se zajištěním spolehlivosti přenosu. Obě varianty parity totiž umožňují detekovat, ve které části přenášeného bloku k chybě došlo. V případě příčné parity se příjemce dozví, ve kterém bytu (event. slově) přenášeného bloku k chybě došlo, zatímco v případě podélné parity se dozví, ve které skupině "stejnolehlých" bitů se tak stalo. Je ale takováto informace příjemci vůbec k užitku?

Podstatné je, jak bude příjemce reagovat na výskyt nějaké (jakékoli) chyby v přijatém bloku. V případě nespolehlivého přenosu zahodí celý blok a už se o něj dále nestará. V případě spolehlivého přenosu si nechá znovu poslat celý blok. Takže k čemu mu je informace o tom, ve které části přenášeného bloku k chybě došlo? Není mu k ničemu, protože ji nedokáže využít. Stačí mu podstatně méně detailní informace, o tom že někde (kdekoli) v rámci bloku došlo k nějaké chybě (či chybám).

S touto skutečností počítají i další mechanismy, které se již nesnaží "lokalizovat" chybu, a soustřeďují se na lepší (přesnější) detekci jejího výskytu, kdekoli v bloku přenášených dat. Jedním takovým mechanismem je kontrolní součet. Funguje tak, že přenášený blok se chápe jako lineární posloupnost bytů (resp. slov, tj. dvojic či čtveřic bytů), každý prvek této posloupnosti se interpretuje jako číslo, a tato čísla se sečtou. Jako zabezpečovací údaj se pak použije výsledný součet (ořezaný na stejný počet bitů, jaký mají jednotlivé sčítance).

Představu ukazuje následující obrázek (č 6).

Obr. 6: Představa kontrolního součtu

Snad není těžké nahlédnout, že kontrolní součty dokáží detekovat více chyb, než parita. Je to dáno už jen tím, že dvojice chyb se většinou vzájemně neruší, tak jako je tomu u parity. Na druhou stranu stále mohou existovat takové kombinace chyb, které se navzájem vyruší a dávají stejný kontrolní součet, jako nepoškozený blok. Takže i kontrolním součtům mohou některé chyby uniknout.

Nejspolehlivější, a v praxi nejpoužívanější, je detekce chyb pomocí tzv. cyklických kódů, známějších spíše podle anglické zkratky CRC (Cyclic Redundancy Check). Jejich účinnost je přímo vynikající. Dokáží detekovat všechny shluky chyb s lichým počtem bitů, dále všechny shluky chyb do velikost n bitů (kde n je počet bitů zabezpečovacího údaje). Všechny větší shluky chyb pak CRC dokáží detekovat s pravděpodobností 99.99999998%. Výhodou je také poměrně snadná implementace a praktický výpočet zabezpečovacího údaje. Stačí k tomu poměrně jednoduchý obvod, který rychle zajistí potřebný výpočet. Tak kde je potom nějaký háček?

Vlastně nikde. Snad jenom v tom, že v pozadí za celou touto metodou detekce chyb stojí silná matematická teorie. Ta také dává návod na to, jak zabezpečovací údaj konkrétně počítat. Abychom se s tím mohli seznámit, museli bychom zabrousit opravdu hodně hluboko do algebry, na což zde rozhodně nemáme prostor. Proto se ani

nebudeme snažit si nějak zjednodušeně popsat, jak se vlastně takové "CRC-éčko" počítá. Spokojíme se jen s konstatováním, že způsob využití je stejný jako u kontrolních součtů - zabezpečovací údaj se připojí k bloku, přenese spolu s ním, a na straně příjemce se počítá znovu a porovnává s přeneseným. Výsledkem je konstatování, že v bloku jako takovém je (resp. není) chyba. Opět, na rozdíl od parity, není patrné v které části bloku k eventuelní chybě došlo. Rozdíl, oproti kontrolním součtům, je v podstatně větší spolehlivosti, se kterou je eventuelní chyba detekována. Proto se také CRC v praxi používají velmi často.

Mechanismy pro opravu chyb

Výše popisované mechanismy (parita, kontrolní součty i CRC) jsou pouze detekčními mechanismy. Jsou tedy určené pouze k tomu, aby detekovaly výskyt jedné či více chyb. Zjišťovat počet chyb vlastně ani nemusí, protože se od nich očekávají pouze dvě možné odpovědi: "celý blok je v pořádku", a "blok není v pořádku". Další pokračování se totiž vždy týká celého bloku jako takového: buďto je celý zahozen (v případě nespolehlivého přenosu), nebo je vyžádán opakovaný přenos celého bloku (v případě spolehlivého přenosu). Někdy ale je zapotřebí zajistit spolehlivý přenos, resp. zvýšit jeho spolehlivost, a není možné opakovat přenos poškozeného bloku dat. Třeba proto, že vůbec neexistuje možnost přenosu v opačném směru. Nebo proto, že takovýto přenos by neúnosně narušil pravidelnost doručování dat (viz výše). Co dělat v takovémto případě? I zde existuje určité řešení, spočívající v použití takových zabezpečovacích údajů, které dokáží chyby nejenom detekovat, ale také je opravovat (u příjemce). V praxi se hovoří o tzv. samoopravných kódech (nejčastěji jsou v této roli používány tzv. Hammingovy kódy). V angličtině se zase lze setkat se zkratkou FEC, od: Forward Error Control, ve smyslu: dopředná ochrana proti chybám. Proč se ale tato možnost používá spíše vzácně, a přednost se dává opakovanému přenosu poškozených dat?

Problém je v tom, že takovéto samoopravné kódy mají příliš velkou režii. Aby dokázaly opravit byť jen "malé" chyby, musí přenést o hodně více dat. Princip jejich fungování si lze představit tak, že místo jedné "sady" dat jich přenáší hned několik (ve smyslu: dvakrát, třikrát atd. ta samá data), a z nich se u příjemce vybírá tu sada, která se přenesla bez poškození. V praxi to funguje poněkud efektivněji (dat se nepřenáší n x více), ale zase ne o tolik. Proto je celá tato varianta zajištění (zvýšení) spolehlivosti používána jen tam, kde nepřipadá v úvahu opakované zaslání poškozených dat.

Potvrzování

Pojďme nyní zpět k tomu, jak se spolehlivý přenos zajišťuje nejčastěji - skrze opakovaný přenos poškozených dat. Základní podmínkou je zde to, aby se odesilatel vůbec dozvěděl, zda příslušný datový blok byl či nebyl přenesen v pořádku. Z toho si pak již odvodí, zda přenos bloku opakovat či nikoli.

Nutnou podmínkou k tomu, aby se odesilatel dozvěděl cokoli od příjemce, je existence zpětné vazby, resp. možnost přenosu "v opačném směru" (od příjemce dat k jejich odesilateli). V praxi to znamená, že mezi oběma stranami musí existovat obousměrný přenosový kanál, resp. okruh. Ne nutně plně duplexní, ale alespoň poloduplexní. Skrze takovýto obousměrný kanál pak mohou obě strany vést určitý dialog, využívající mechanismus tzv. potvrzování. Potvrzování (anglicky: Acknowledgement) funguje přesně tak, jak napovídá jeho název: potvrzuje, že byl určitý blok dat přenesen. Jde tedy o zprávu, kterou generuje příjemce datového bloku, a přijímá ji odesilatel tohoto bloku. Cestuje tedy v opačném směru, než v jakém je přenášen ten datový blok, který potvrzuje (od příjemce k odesilateli), viz obrázek (č. 7).

Jednotlivé potvrzování

Důležité je, že potvrzení může být jak kladné (potvrzující bezchybný přenos), nebo naopak záporné (signalizující chybně přenesený blok). Podstatné je také to, jak odesilatel s potvrzením nakládá. Jedna základní možnost je taková, že když odesilatel odešle nějaký blok dat, nejprve čeká na odezvu druhé strany. Pokud dostane kladné potvrzení, pokračuje odesláním dalšího bloku (a znovu čeká na potvrzení atd.). Pokud dostane záporné potvrzení, odešle stejný blok znovu. Kromě toho ale musí počítat ještě i se dvěma dalšími možnostmi: s tím, že se mohl ztratit celý přenášený blok, takže příjemce ani neví, že by měl něco potvrzovat. s tím, že se ztratilo samotné potvrzení, které příjemce vygeneroval.

V obou případech si odesilatel musí natáhnout stopky a čekat určitou dobu (po určitý časový limit, v angličtině: timeout). Když do uplynutí této doby nedostane žádné potvrzení, interpretuje to stejně jako potvrzení záporné, a přenos bloku opakuje. Celý právě popsaný postup je označován jako tzv. jednotlivé potvrzování (v angličtině: Stop&Wait ARQ).

Ilustruje ho i následující obrázek (č. 8):Obr. 8: Jednotlivé potvrzování

Snad není těžké nahlédnout, že velikost časového limitu musí být volena velmi pečlivě. Pokud by byla příliš krátká, odesilatel by mohl "předčasně zpanikařit" (a opakovat přenos dříve, než mu potvrzení přijde). Naopak, pokud časový limit byl moc velký, odesilatel by čekal zbytečně dlouho, a přenos by se zbytečně zpomaloval.

Kontinuální potvrzování

Jednotlivé potvrzování je vhodné pouze pro takové sítě, ve kterých "cesta tam a zpět", od odesilatele k příjemci, netrvá dlouho. Tedy tam, kde je malé tzv. přenosové zpoždění. To znamená hlavně v lokálních sítích (sítích LAN). V rozlehlých sítích (sítích WAN) je přenosové zpoždění relativně velké - a kvůli tomu neúměrně narůstají prodlevy, způsobené čekáním na potvrzení každého jednotlivého bloku. Ilustruje to i následující obrázek (č. 9.)

Obr. 9: Vliv přenosového zpoždění při jednotlivém potvrzování

V prostředí rozlehlých sítí je proto výhodnější jiná strategie, označovaná jako kontinuální potvrzování. Od jednotlivého potvrzování se liší v tom, že když odesilatel odešle nějaký blok, nečeká na jeho potvrzení, ale pokračuje odesláním dalšího bloku. Posílá tedy jednotlivé datové bloky stylem "jeden za druhým", a teprve zpětně přijímá potvrzení o tom, jak byly tyto bloky doručeny.

Představu ukazuje následující obrázek (č. 10): Obr. 10: Představa kontinuálního potvrzování

Jak je tomu ale v případě, že odesilateli přijde záporné potvrzení? Nebo že se ani po uplynutí časového limitu (timeoutu) nedočká žádného potvrzení, a musí to interpretovat jako záporné potvrzení? Zde existují dvě možné varianty toho, jak odesilatel reaguje.

První varianta je označována jako tzv. selektivní opakování. Spočívá v tom, že odesilatel zopakuje (znovu odešle) právě a pouze ten blok, který se poškodil či ztratil (ke kterému se vztahuje záporné potvrzení), a dále pokračuje jako kdyby se nic nestalo.

Ukazuje to i následující obrázek (č. 11).Obr. 11: Představa kontinuálního potvrzování se selektivním opakováním

Nevýhodou selektivního opakování je vyšší náročnost na příjemce. Pokud totiž přijme nějaký poškozený blok (nebo jej nepřijme vůbec), ještě nějakou dobu poté musí přijímat následující bloky, které ale nemůže ještě zpracovávat. Místo toho je musí někam ukládat a čekat, až dostane znovu původně poškozený či ztracený blok. Teprve pak může začít zpracovávat i následující., již přijaté bloky.

Uvedený problém řeší druhá varianta kontinuálního potvrzování, označovaná jako opakování s návratem. Spočívá v tom, že když odesilatel dostane záporné potvrzení (nebo mu vyprší časový limit), znovu odešle příslušný blok, a poté pokračuje těmi bloky, které po něm následující (bez ohledu na to, že některé z nich mohly v mezidobí být odeslány). Jinými slovy: vrátí se k poškozenému bloku, a dál pokračuje od něj.

Ukazuje to i následující obrázek (č. 12).Obr. 12: Představa kontinuálního potvrzování s návratem

I varianta "s návratem" ovšem má své nevýhody. Je sice šetrnější vůči příjemci, ale na druhé straně může plýtvat přenosovou kapacitou. Může totiž znovu přenášet takové bloky, které se již jednou přenesly úspěšně (bez chyb).

Samostatné a nesamostatné potvrzování

Na závěr se ještě zastavme u toho, jakou konkrétní podobu mohou mít potvrzení, zasílaná od příjemce směrem k odesilateli. Jedna možnost je taková, že potvrzení jsou zcela samostatná, neboli že jde o principiálně stejné bloky, v jakých se přenáší i samotná data. Mají tedy mj. svou vlastní hlavičku, která určitým způsobem zvyšuje režii na přenos.

Snaha eliminovat tuto režii vedla ke vzniku tzv. nesamostatného potvrzování (anglicky: piggybacking). To spočívá v tom, že příjemce původních dat čeká s jejich potvrzením, dokud " v protisměru" necestuje nějaký jiný datový blok, z nějakého jiného přenosu - a do něj jen "přidá" své potvrzení. Využívá tedy toho, že zmíněný blok "v protisměru", patřící nějakému jinému přenosu, již tak jako tak má svou hlavičku a další náležitosti, a tudíž přírůstek režie na zajištění potvrzení je minimální. Obě varianty ilustruje následující obrázek (č. 13).

Obr. 13: Představa samostatného a nesamostatného potvrzování

I nesamostatné potvrzování však má svá úskalí. Zejména to, že příjemce nemůže čekat příliš dlouho na to, až "v protisměru" bude přenášen nějaký jiný datový blok, do kterého by své potvrzení vložil. Odesilatel o tom totiž neví, a mohl by mu vypršet jeho časový limit (timeout). V praxi se příjemce snaží o nesamostatné potvrzení jen chvíli, a pokud se mu nepodaří, přechází k samostatnému potvrzení (tj. odešle své potvrzení jako samostatný blok).

U rozlehlých sítí (sítí WAN) už jejich samotný název naznačuje, že jednotlivé uzly asi budou více vzdáleny od sebe - a tak se pro jejich vzájemné propojení používají spíše dvoubodové spoje, vedené tak jak je to ekonomicky i realizačně nejsnazší a nejefektivnější. Výsledek pak obvykle připomíná nějaký obecný graf, bez pravidelné (systematické) struktury. V případě sítí lokálních (sítí LAN) však bývá situace diametrálně odlišná. Geografická blízkost uzlů sítí LAN umožňuje jejich propojení nějakým systematickým způsobem - například do kruhu, do hvězdy či stromu, nebo do sběrnice atd. - s využitím takového přenosového média, které má sdílený charakter.

Tedy takového média, které je využíváno více uzly současně. Například k tomu, aby se vysílání jednoho uzlu šířilo k více uzlům (ať již jako tzv. broadcast, tj. ke všem dostupným uzlům, nebo jako tzv. multicast, tj. jen k některým z dostupných uzlů).

Obr. 1: Představa topologií sítí WAN a LAN

Systematická topologie a sdílené médium mají i další výhody, ale také své nevýhody. Tou největší je zřejmě nutnost řídit přístup ke společně sdílenému přenosovému médiu, pro potřeby vysílání. Jak už jsme si řekli, současný příjem je možný, a je dokonce jednou z hlavních předností společně sdíleného přenosového média. Ovšem současné vysílání, dvěma či více uzly, už žádoucí není a je třeba se mu vyvarovat. Ne snad proto, že by současným vysíláním mohlo dojít k nějakému fyzickému poškození přenosového média. To nikoli.

Někdy k současnému vysílání přeci jen může dojít, a pak se hovoří o tzv. kolizi. Při ní dochází k "promíchání" jednotlivých vysílání, která už pak zase nejdou zpětně "oddělit od sebe". Takže kolizím je dobré se vyhýbat, předcházet jim, nebo je úplně vyloučit. No a ten, kdo by to měl zajistit (resp. "to, co by to mělo zajistit"), jsou tzv. přístupové metody, anglicky "access methods". Plným jménem: metody přístupu ke sdílenému médiu.

Klasifikace přístupových metod

Už z pouhé zmínky o kolizích lze vytušit, že přístupové metody mohou pracovat různým způsobem a vycházet z různých principů. Například podle toho, jak se chovají vůči kolizím, je lze dělit na přístupové metody:zcela vylučující kolize (CA, Collision Avoidance) detekující kolize (CD, Collision Detection) bez detekce kolizí

Takže například metody detekující kolize (CD) se obvykle snaží nějak předcházet jejich výskytu, ale nejdou až tak daleko, aby je vyloučily zcela. Takže kolize mohou přesto nastat - a metody s přívlastkem CD je dokáží detekovat a následně i řešit (postarat se o nápravu). Jak záhy uvidíme, přístupová metoda, používaná v oblíbeném Ethernetu, je právě tohoto typu. Jiné přístupové metody naopak fungují striktně v tom smyslu, že žádné kolize nepřipouští.

Obvykle to souvisí i s další jejich vlastností, kterou je řízený (deterministický) charakter. Takovéto deterministické přístupové metody mají "vše pod kontrolou", a výsledek jejich působení je vždy možné predikovat (na základě znalosti výchozího stavu). Alternativou k nim jsou neřízené, alias nedeterministické přístupové metody, které při svém rozhodování používají nějaký náhodný prvek. Pak ale jejich výsledek nelze přesně předikovat (a ze stejné výchozí situace mohou vzniknout různé výsledky). Například již zmiňovaná přístupová metoda Ethernetu je nedeterministická.

Abychom se v tom ale správně vyznali: přístupové metody lze dělit podle různých kritérií. Jedním z nich je celkový přístup ke kolizím, a podle něj se přístupové metody rozpadají na metody vylučující kolizi (CA, Collision Avoidance), detekující kolizi (CD, Collision Detection) a bez detekce kolizí.

Dalším možným kritériem je již zmiňovaná existence náhodného prvku při rozhodování - podle něj s přístupové metody dělí na: deterministické (řízené) nedeterministické (neřízené)

Ještě dalším kritériem pak je to, zda přístupová metoda předpokládá existenci nějakého centrálního prvku (centrální autority, arbitra), který by sám realizoval veškeré rozhodování podle pravidel příslušné přístupové metody, a ostatním uzlům říkal, co a jak mají dělat. Podle toho se pak přístupové metody dají dělit na: centralizované (s centrálním prvkem, resp. centrální autoritou) distribuované (bez centrální autority).

Ani tím se však možnosti klasifikace přístupových metod nevyčerpaly. Ještě dalším možným dělením je to, zda se uzel, usilující o vysílání, nejprve snaží detekovat, zda po společně sdíleném přenosovém médiu právě probíhá nějaké vysílání. Říká se tomu "příposlech nosné", anglicky "Carrier Sense" (CS). Pokud je příposlech nosné používán a uzel zjistí, že právě vysílá někdo jiný, do přenosu sám nevstupuje, aby jej nenarušil. U metod bez detekce nosné se uzel na právě probíhající vysílání neohlíží. Pak ale hrozí nebezpečí, že někomu "skočí do řeči" (naruší právě probíhající vysílán í kolizí).

Důležité také je, že všechna výše uvedená dělení jsou na sobě nezávislá. Takže třeba přístupová metoda, používaná v Ethernetu (viz dále) je nedeterministická, distribuovaná, s detekcí kolizí (CD) a s detekcí nosné. Jmenuje s konkrétně CSMA/CD, což zdůrazňuje i její hlavní vlastnosti.

Centralizované metody

Než se ale pustíme do zřejmě nejznámější přístupové metody CSMA/CD, používané v Ethernetu, zastavme se nejprve u toho, jak mohou vypadat centralizované přístupové metody. Musí mít nějaký centrální prvek, který nějakým způsobem "přiděluje slovo" jednotlivým uzlům sítě, pro potřeby vysílání. Může to dělat i bez toho, aby se snažil nějak zjistit, zda vysílat skutečně chtějí, nebo nikoli - toto právo jim pak jednoduše přiděluje nejspíše nějak cyklicky, aby se dostalo postupně na všechny uzly. Inteligentnější je ale varianta, kdy se centrální autorita zajímá o to, kdo a jak chce vysílat, a právo vysílat přiděluje pouze tomu, kdo o něj má zájem.

O existenci zájmu se centrální autorita může dozvědět dvěma principiálně odlišnými způsoby: na základě výzev (anglicky: polling), kdy se sama pravidelně dotazuje uzlů, zda nechtějí vysílat na základě žádostí, kdy uzly samy žádají centrální autoritu o právo vysílat.

V obou případech je ale "s agendou zjišťování zájmu" spojena nemalá režie, buď ve formě samostatných vedení (pro žádosti či výzvy), nebo alespoň ve formě části přenosové kapacity sdíleného přenosového média, vyhrazené pro daný účel.

Obr. 2: Představa žádostí a výzev

Výhodou centralizovaných přístupových metod je naopak velká pružnost v rozhodování centrální autority. Ta může používat prakticky libovolný algoritmus pro své rozhodování, a dokonce jej může i průběžně měnit, například v závislosti na stavu sítě a průběhu komunikace.

Konkrétním příkladem z praxe může být kabelový Internet, přesněji způsob přenosu dat v kabelových sítích, na bázi standardu DOCSIS. Zde je vždy určitý počet modemů zapojen "do skupiny", v rámci které sdílí jeden společný přenosový kanál, pro oba směry komunikace. K celé skupině kabelových modemů je pak přiřazen jeden prvek CMTS (Cable Modem Termination System). Ten pak řídí veškerou komunikaci v rámci skupiny - na dopředném kanále (směrem ke kabelovým modemům) vysílá vždy pouze on sám. V opačném směru může standardně vysílat vždy jen ten kabelový modem, kterému "udělí slovo" CMTS.

Představa topologie datové části kabelové sítě

CMTS tedy plní roli centrální autority, a zájem jednotlivých kabelových modemů o vysílání (na zpětném kanále) zjišťuje pomocí speciálního rezervačního rámce, který "nechává kolovat" (rozesílá po dopředném kanále, a přijímá po zpětném kanále). V tomto rezervačním rámci může každý jednotlivý kabelový modem vyznačit svůj zájem o vysílání - a následně mu CMTS ve vhodnou dobu udělí slovo.

Představu ukazuje následující obrázek (č. 3.):Obr. 3: Představa principu rezervací , u centralizované přístupové metody používané v kabelových sítích.

Poněkud odlišným způsobem je řešena centralizovaná přístupová metoda v sítích 100VG-AnyLAN. Ty svého času velmi propagovala firma Hewlett-Packard, společně s IBM, a dokonce se původně snažila je prosadit jako 100-megabitovou verzi Ethernetu. Nakonec se tak nestalo, právě kvůli tomu že technologie 100VG-AnyLAN používá jinou přístupovou metodu než klasický Ethernet. Jde o metodu, nazývanou "Demand Priority", a využívající stromovitý charakter kabeláže (viz obrázek č. 4). Podstatné je zde to, že každý uzel má k dispozici (a jen a jen pro sebe) svou samostatnou přípojku k nejbližšímu nadřazenému rozbočovači (tzv. hub-u). Takže pokud právě sám nevysílá, nebo něco nepřijímá, může tuto svou přípojku využít k tomu, aby požádal svůj nadřazený rozbočovač o právo vysílat. No a všechny rozbočovače dohromady (a ve vzájemné součinnosti) pak plní roli centrální autority a podle momentální situace udělují žadatelům (koncovým uzlům) právo vysílat.

Obr. 4: Představa fungování metody Demand Priority, v sítích 100VG-AnyLAN

Distribuované metody

Centralizované přístupové metody mají své výhody, ale i své nevýhody. Největší nevýhodou je asi to, že centrální autorita představuje příslovečné "single point of failure" - neboli jedno místo, jehož vyřazením (poruchou, závadou atd.) je vyřazena z provozu celá síť. Tuto nevýhodu naopak nemají distribuované metody, které nemají žádnou centrální autoritu, a uplatňování pravidel přístupové metody "rozkládají" rovnoměrně mezi všechny uzly. Jinými slovy: když zde není žádná centrální autorita, musí se uzly domluvit mezi sebou, distribuovaným způsobem. Činí tak na základě pravidel, které musí korektně dodržovat všechny uzly. Ve svém vzájemném souběhu pak tato pravidla naplňují příslušnou přístupovou metodu.

I distribuované (decentralizované) přístupové metody se přitom mohou dělit na řízené (deterministické) a neřízené (nedeterministické), s tím že obě tyto dílčí varianty mají smysl. Naopak u centralizovaných přístupových metod měly smysl spíše jen deterministické přístupové metody (zatímco nedeterministické by nepřinášely žádnou výhodu oproti deterministickým). U distribuovaných metod však nedeterministické metody smysl mají. To proto, že jejich implementace může být výrazně jednodušší (lacinější) než implementace deterministických metod.

Lze to ostatně demonstrovat na příkladu Ethernetu, který používá distribuovanou a nedeterministickou přístupovou metodu, a jeho implementace je relativně velmi jednoduchá. Naproti tomu například síť Token Ring používá distribuovanou a deterministickou přístupovou metodu, a jeho implementace je kvůli tomu složitější. S tím pak souvisí i komerční úspěšnost - Ethernet je dnes mnohem rozšířenější než Token Ring.

Token Passing, aneb předávání peška

Popišme si nejprve jednu deterministickou a distribuovanou přístupovou metodu, která je v praxi používána poměrně často. Jmenuje se "Token Passing", a její hlavní princip naznačuje už toto její jméno: existuje zde "něco", čemu se v angličtině říká "Token", a co má význam jakéhosi oprávnění, povolení apod. Někdy se tomu česky říká také "pešek", což zase naznačuje způsob manipulace s tímto Tokenem: jednotlivé uzly si jej postupně předávají, podle určitého pořadí. Toto pořadí musí mít charakter logického kruhu, tak aby pešek obíhal pořád dokola. No a když se zajistí, že obíhat bude vždy jen jeden pešek, pak s ním lze vyřešit i problém přístupu ke sdílenému médiu: právo vysílat bude mít ten, kdo má právě ve svém držení peška. až své vysílání skončí, předá peška dalšímu uzlu v pořadí (v logickém kruhu)

Obr. 5: Představa fungování metody Token Passing

Důležité je, že metoda Token Passing vyžaduje logický kruh, definující způsob předávání Tokenu (peška) mezi jednotlivými uzly. To ale nemusí nutně znamenat, že i fyzická topologie sítě, kde je tato metoda použita, musí být také kruhová. Ostatně, na předchozím obrázku (č. 5) je znázorněna sběrnicová topologie, jako u sítí Token Bus. Pravdou ale že, že v praxi se metoda Token Passing používá nejčastěji v sítích, které skutečně mají kruhovou topologii (například v sítích Token Ring a FDDI).

CSMA/CD - přístupová metoda Ethernetu

Pojďme nyní již tomu, co je pro dnešní praxi asi nejzajímavější - k přístupové metodě CSMA/CD, používané v Ethernetu. Jak jsme si již naznačili, patří mezi:distribuované přístupové metody (tj. nemá žádného centrálního arbitra, resp. centrální autoritu, který by vše řídil) neřízené (nedeterministické) přístupové metody. To proto, že při rozhodování jednotlivých uzlů se v jisté situaci uplatňuje náhodný prvek. přístupové metody využívající příposlech nosné (CS, Carrier Sense). Jednotlivé uzly tedy před začátkem vlastního vysílání poslouchají, zda právě nevysílá někdo jiný přístupové metody s detekcí kolize (CD, Collision Detect). Takže v Ethernetu může ke kolizím docházet, ale tyto jsou následně detekovány, a jsou řešeny

Praktické fungování přístupové metody CSMA/CD, používané v Ethernetu, si můžeme přiblížit následovně (viz též obrázek č. 6): uzel, který má zájem vysílat, nejprve použije příposlech nosné (CS). Pokud zjistí, že právě nikdo nevysílá, může začít vysílat sám. pokud však uzel zjistí, skrze příposlech nosné, že právě někdo vysílá, čeká až toto vyslání skončí (tj. stále sleduje průběh vysílání, skrze příposlech nosné). Jakmile vysílání skončí, uzel začne vysílat sám.

Obr. 6: Představa využití detekce nosné (/CS) v Ethernetu

Důležité je, že skrze uvedené dva body, a zejména pak skrze příposlech nosné (CS, Carrier Sense), se zájemci dokáží vyvarovat toho, aby někomu "skočili do řeči" (narušili nějaké již probíhající vysílání). Tím je výrazně snížena pravděpodobnost výskytu nežádoucích kolizí. Bohužel ale není zcela eliminována, a to je nutné si náležitě zdůraznit. I přes toto chování jednotlivých uzlů může ke kolizím stále docházet. Možné příčiny jsou dvě, a ukazuje je následující obrázek (č. 7).

Obr. 7: Možné důvody pro vznik kolizí v Ethernetu

Méně častou příčinou je souběh dvou uzlů, které ve stejném čase (viz horní část obrázku č. 7). Může se totiž stát, že dva uzly se ve stejnou dobu rozhodnou, že začnou vysílat. Oba zjistí, že žádné vysílání právě neprobíhá, a tak začnou vysílat sami.Častějším důvodem pro vznik kolizí je situace, kterou znázorňuje spodní část obrázku č. 7: dva nebo více uzlů se rozhodne začít vysílat v době, kdy právě probíhá nějaké jiné vysílání. Všichni to zjistí, a tak spořádaně počkají na konec tohoto vysílání - ale pak začnou vysílat všichni najednou. A dojde ke kolizi …

Řešení kolizí v Ethernetu

Co ale s kolizí dál? Jak se má zachovat uzel v situaci, kdy zjistí že jeho vysílání se dostalo do kolize s vysíláním jiného uzlu? Pravidla fungování Ethernetu říkají, že v takové situaci hlavně nesmí zpanikařit a okamžitě přestat vysílat. Pak by se totiž mohlo stát, vzhledem ke konečné rychlosti šíření signálu po sdíleném médiu a jeho nenulové délce, že by tuto kolizi jiné uzly nemusely korektně zaregistrovat. Proto musí uzel kolizi ještě naopak "utvrdit", a po předepsanou dobu naopak ještě vysílat. Teprve pak může uzel začít kolizi řešit. Optimálně tak, aby se ze všech uzlů, které se kolize zúčastnily, vybral jeden a ten získal právo vysílat. Jenže k tomu by se uzly musely mezi sebou umět domluvit - kolik jich je, které to jsou atd., a pak mezi sebou jednoho vybrat.

To ale není možné. Uzly, které se setkaly v kolizi, o sobě neví.

Ani netuší, kolik jich je - zda dva (což je minimum pro kolizi jako takovou), nebo více. Ani nemají k dispozici žádný mechanismus, prostřednictvím kterého by se vzájemně domluvili. Proto to řeší tak, že se spolehnou na náhodu. Vygenerují si náhodné číslo z určitého intervalu, a na dobu danou tímto číslem se odmlčí (a teprve pak zkouší vše znovu). Spoléhají se přitom na to, že jim pomůže právě náhoda - že se různé uzly odmlčí na náhodnou dobu, a poté se při dalším pokusu o vysílání již do kolize nedostanou a odvysílají si svá data. Představu ukazuje následující obrázek (č. 8).

Obr. 8: Představa odmlčení dvou uzlů, zúčastněných na kolizi

Pravdou je, že takto využitý prvek náhody obvykle pomůže, a uzly už se znovu do kolize nedostanou. Jenže problém je v tom, že to není zaručeno. Může se stát i to, že uzly se odmlčí na stejnou dobu (oba si náhodně zvolí stejnou dobu). Nebo, a to je asi pravděpodobnější, se oba odmlčí na různě dlouhou dobu, ale pak stejně musí čekat až skončí nějaké právě probíhající vysílání, a tak se znovu dostanou do kolize, viz obrázek č. 9:

Obr. 9: Představa následné kolize

Pokud ovšem náhoda v prvním kole nepomohla, není nutné ji hned zatracovat. Výhodnější je náhodě pomoci, tak aby měla větší šanci zaúčinkovat. Přístupová metoda CSMA/CD, používaná v Ethernet, to řeší následovně: interval, ze kterého se vybírá náhodná doba pro odmlčení, se při každém neúspěšném pokusu zdvojnásobuje. Dělá se to tak celkem 16x, a teprve pokud se to ani na šestnáctý pokus nepodaří, přístupová metoda to vzdá a ohlásí neúspěch.

Obr. 10: Prodlužování intervalu při následných kolizích

Propustnost řízených a neřízených metod

Pravdou je, že zvětšování intervalu, ze kterého se náhodně volí doba pro odmlčení, snižuje pravděpodobnost výskytu následných kolizí. Na druhou stranu ale ani tento postup negarantuje, že k následným kolizím vůbec nedojde. V praxi je to sice velmi málo pravděpodobné, ale přesto se to může stát: může dojít k tomu, že díky nedeterminismu (náhodnému prvku) v přístupové metodě CSMA/CD se konkrétní uzel nedostane vůbec "ke slovu" (nezíská přístup ke sdílenému médiu, za účelem vysílání). Stejně tak nejde ani garantovat, že se ke slovu dostane nejpozději za nějakou konkrétní dobu T. Opět to lze slíbit jen s nějakou pravděpodobností, relativně vysokou, ale nelze to garantovat. Naproti tomu u řízených (deterministických) přístupových metod obecně lze garantovat, že se nějaký uzel dostane "ke slovu", a obvykle i za jak dlouho. Například u sítí s metodou Token Passing záleží jen na tom, kolik je uzlů v logickém kruhu, a jak dlouho si každý uzel smí nechat peška ve svém držení.

Pro praxi to má jeden velmi významný důsledek: Ethernet, který nedokáže nic garantovat, se nedá použít tam, kde je nutná garantovaná odezva sítě, v reálném čase. Tedy například ve výrobě, při řízení výrobních procesů apod. Zde jsou nutné lokální sítě s řízenými přístupovými metodami. Naproti tomu v běžném kancelářském prostředí minimální (ale ne zcela nulová) pravděpodobnost, že se něco nepřenese včas, vůbec nevadí. Zde naopak Ethernet se svým nedeterminismem drtivě vítězí, protože je jednodušší, a tím i lacinější. A také vlastně rychlejší, protože se nemusí zabývat mnoha složitostmi, na které naopak musí pamatovat sítě s řízenými přístupovými metodami.

Obecně přitom platí, že vytížení (celková propustnost) sdíleného přenosového média závisí nejen na použité přístupové metodě, ale také na intenzitě provozu. Není asi těžké nahlédnout, že při větší zátěži (při větší četnosti požadavků od jednotlivých uzlů na vysílání) bude pravděpodobnost výskytu kolizí růst, a to i kolizí následných. V praxi to dokonce vypadá tak, že od určitého okamžiku se s růstem zátěže propustnost dokonce zmenšuje, právě kvůli kolizím a kvůli tomu, že režie spojená s jejich výskytem a řešením začíná převažovat.

Ukazuje to ostatně i následující obrázek (č. 11), na kterém je názorně vidět, jak se při rostoucí zátěži (na ose X) chová neřízená přístupová metoda (například metoda CSMA/CD Ethernetu), a jak se (obecně) chová řízená přístupová metoda. Pro ní celková propustnost, měřená ve využití sdíleného média pro "užitečné" přenosy, neklesá, ale asymptoticky se blíží k ideálním 100%.

Obr. 11: Chování řízené a neřízené přístupové metody, vzhledem k zátěži (intenzitě požadavků)

K obrázku č. 11 je ovšem nutné přidat jednu velmi důležitou poznámku: při použití neřízených (nedeterministických) metod se předpokládá jejich využití v méně zatížených sítích. Tedy tam, kde intenzita požadavků jednotlivých uzlů na vysílání je relativně nízká. Na obrázku odpovídá tmavěji vyšrafované části. Takže "křivka vytíženosti" se ani nedostane k tomu, aby se začala lámat. Podvrstva MAC

Na samotný závěr si ještě řekněme jednu důležitou věc: kde vlastně jsou všechny přístupové metody implementovány? Na jaké vrstvě, v rámci sedmivrstvého modelu ISO/OSI? Pokud by to mělo být na linkové vrstvě, pak by to už bylo pozdě. Linková vrstva, která zajišťuje přenos celých (linkových) rámců, už musí mít přístup ke sdílenému médiu vyřešen. Takže přístupové metody musí být implementovány pod linkovou vrstvou. Analogická úvaha, byť "s opačným znaménkem", ale platí i pro vrstvu fyzickou: jelikož přístupové metody potřebují ke svému fungování vysílat do sdíleného média jednotlivé bity, musí být implementovány nad fyzickou vrstvou.

Jenže mezi fyzickou a linkovou vrstvou referenčního modelu ISO/OSI už žádná další vrstva není. Autoři RM ISO/OSI přitom ani nepočítali s tím, že by nějaké přístupové metody museli implementovat, protože předpokládali spíše existenci rozlehlých sítí, bez sdílených přenosových médií. Když se pak objevily i sítě lokální, a s nimi i potřeba přístupových metod, už se jim nechtělo zvyšovat beztak vysoký počet vrstev, a vložit mezi fyzickou a linkovou vrstvu ještě jednu další vrstvu. A tak to vyřešili zajímavým "kompromisem" - původní linkovou vrstvu rozdělili na dvě podvrstvy: vyšší podvrstvu LLC (Logical Link Control), která zajišťuje úkoly celé původní linkové vrstvy nižší podvrstvu MAC (Media Access Control), na které jsou implementovány dnes popisované přístupové metody.

Představu obou podvrstev ukazuje také následující obrázek, č. 12:Obr. 12: Rozdělení linkové vrstvy RM ISO/OSI na dvě podvrstvy

V našem putování báječným světem počítačových sítí jsme již prošli dvěma nejnižšími vrstvami referenčního modelu ISO/OSI - nejprve nejspodnější vrstvou fyzickou, a pak druhou nejnižší vrstvou linkovou. Přitom jsme si řekli, že vrstva fyzická má za úkol přenášet jednotlivé bity mezi sousedními uzly, ale nijak je přitom "neskládá dohromady", resp. nezajímá se o to, zda více jednotlivých bitů tvoří nějaký souvislý blok. To zajímá až

bezprostředně vyšší vrstvu linkovou, která využívá přenosových služeb fyzické vrstvy (charakteru "přenes bit"), a s jejich pomocí již přenáší celé bloky dat, kterým se na úrovni linkové vrstvy říká "rámce" (anglicky: frames).

Linková vrstva ovšem stále ještě přenáší své rámce jen mezi sousedními uzly, neboli mezi takovými, které mají mezi sebou přímé spojení. Lze si to představit také tak, že pro vrstvu linkovou je viditelné pouze její bezprostřední okolí (tvořené sousedními uzly), zatímco o dalších (vzdálenějších) uzlech už nemá žádné povědomí.

Představa fungování linkové vrstvy - zná jen své přímé sousedy, a pouze s nimi také komunikuje.

Pokud je ale třeba přenést nějaká data právě k těmto vzdálenějším uzlům, které již jsou mimo "záběr" linkové vrstvy (z pohledu odesílajícího uzlu), pak to linková vrstva neřeší. Místo ní už nastupuje vrstva síťová, která již "dohlédne dále" - která zná topologii celé sítě, či celé soustavy vzájemně propojených sítí, a díky tomu dokáže hledat a nacházet cesty ke kterémukoli cílovému uzlu.

Představa fungování síťové vrstvy - zná již topologii celé sítě, či celé soustavy vzájemně propojených sítí

Co je směrování?

Samotnému hledání cesty ke koncovému příjemci, které síťová vrstva zajišťuje, se říká směrování (anglicky routing). Jde tedy spíše o logickou ("rozhodovací") funkci, jejímž výsledkem je rozhodnutí o konkrétní cestě pro přenos. Jak záhy uvidíme, postup tohoto rozhodování může být založen na opravdu různých principech., přístupech i metodách. Podle toho se pak také hovoří například o centralizovaném směrování, izolovaném či distribuovaném směrování, či směrování hierarchickém atd.

Samotné rozhodnutí o volbě cesty, a s ním i o směru dalšího přenosu (z pohledu každého uzlu "po cestě"), je ale třeba také konkrétně naplnit. Tedy vzít příslušný blok dat (paket, jak se mu říká na úrovni síťové vrstvy), a přenést jej k dalšímu "přestupnímu" uzlu, případné již k samotnému cílovému adresátovi (pokud jde již o konec celé přenosové cesty). Tomu se obvykle říká "forwarding" (v doslovném překladu jakési "předání dál").

Síťová vrstva ovšem sama o sobě nic nepřenáší. To je pouze iluze, vytvořená vrstevnatým charakterem dnešních sítí. Ve skutečnosti totiž síťová vrstva předá svůj paket k přenosu bezprostředně nižší vrstvě, tj. vrstvě linkové. Ta vloží síťový paket do svého rámce (linkového rámce), a ten pak přenáší. Ovšem ani ona jej ve skutečnosti sama nepřenáší, nýbrž nechává si jeho jednotlivé bity přenést od vrstvy fyzické.

Celé to ilustruje následující obrázek. Představa přenosů na úrovni síťové, linkové a fyzické vrstvy

Přímé a nepřímé směrování, směrovač

Jak jsme si již řekli, linková vrstva, které vrstva síťová předává své pakety k přenesení, "dohlédne" jen ke svým bezprostředním sousedům, se kterými má přímé spojení (viz výše). V praxi jsou těmito sousedy všechny uzly, které se nachází ve stejné síti. Pokud se tedy přenáší nějaký síťový paket mezi dvěma uzly v rámci stejné sítě, pak má samotná síťová vrstva značně usnadněnou práci, protože nemusí hledat žádné mezilehlé (resp. přestupní) uzly, přes které by měl paket přejít. Takový paket proto síťová vrstva pouze předá linkové vrstvě, která již je schopna jej doručit cílovému adresátovi (neboť ten je v jejím přímém dosahu). Z pohledu síťové vrstvy se tomu říká "přímé směrování", a zde skutečně má síťová vrstva minimum práce a žádné "přemýšlení".

Složitější je to ale v případě, kdy se koncový příjemce nenachází ve stejné síti, jako právě odesílající uzel. Zde již musí síťová vrstva začít hledat vhodnou cestu ke koncovému příjemci, vedoucí přes jeden nebo několik přestupních uzlů. V užším slova smyslu tedy pouze zde, při tzv. nepřímém směrování, provádí síťová vrstva rozhodování, které jsme si výše označili jako samotné směrování (routing).

Představa přímého a nepřímého směrování

, co síťová vrstva při nepřímém směrování hledá, je uzel, vedoucí z dané sítě "ven", do jiné sítě. Tedy jakýsi "přestupní" uzel, resp. "propojovací" uzel (uzel, který vzájemně propojuje dvě různé sítě, či dokonce více takovýchto sítí). Takovémuto uzlu se říká směrovač (router), a v každé síti, která není zcela izolována od svého okolí, je nejméně jeden. Odpovídá to tzv. katenetovému modelu, v rámci kterého jsou jednotlivé sítě propojeny, pomocí směrovačů, do celé soustavy vzájemně propojených sítí. Na takovémto katenetovém modelu je vybudován například dnešní Internet, ale obecně z něj vychází prakticky všechny počítačové sítě.

Obr. 5: Představa katenetového modelu

Takže každý uzel dané sítě, který chce přenést nějaký svůj paket do jiné sítě (tj. v rámci nepřímého směrování), musí najít vhodný směrovač, vedoucí "z jeho sítě ven". Tomu pak svůj paket "předá dál".

Celý proces postupného předávání se přitom opakuje tak dlouho, dokud se paket nedostane ke svému cíli. I každý směrovač, přes který paket na své cestě prochází, se vždy musí nejprve rozhodnout, zda už je konečný příjemce v jeho přímém dosahu či nikoli. Pokud ano, dochází k přímému směrování (paket je předán linkové vrstvě k přímému doručení koncovému příjemci). Pokud konečný příjemce ještě není v přímém dosahu (tj. nenachází se v žádné síti, do které je směrovač zapojen), pak dochází znovu k nepřímému směrování - směrovač hledá další směrovač (vedoucí do dalších sítí), kterému by paket předal k doručení. Výsledkem je pak cesta, tvořená posloupností takovýchto směrovačů. Přes ně paket postupně prochází, než se dostane ke svému koncovému příjemci. Situaci ilustruje následující obrázek.

Přenos skrze soustavu vzájemně propojených sítí

Kdo směruje?

Pro dokreslení celé představy o fungování síťové vrstvy se ještě zastavme u toho, kdo vlastně provádí směrování, coby logické rozhodování o směru přenosu. Činí tak hlavně směrovače, ale nejen ony. Směrování se obecně účastní i ostatní uzly (koncové uzly), pokud něco odesílají - protože i ony si musí umět vybrat mezi (potenciálně) více směrovači, které vedou "ven" z příslušné sítě. Odesílající uzel se také nejprve rozhoduje mezi

přímým a nepřímým směrováním, a v případě nepřímého směrování vybírá vhodný směrovač. Takže i on by měl mít dostatečné informace na to, aby si při nepřímém směrování dokázal vhodně vybrat.

Například v rodině protokolů TCP/IP, resp. v sítích s těmito protokoly (tedy například v Internetu) je to tak, že každý koncový uzel (například každý osobní počítač atd.) by měl "od narození" znát alespoň jeden směrovač, vedoucí z jeho sítě ven. Pravda, existují sice postupy, které by mu umožnily začít fungovat i bez této znalosti a adresu směrovače si zjistit - ale v praxi se dává přednost tomu, aby každý uzel dostal dopředu (v rámci své konfigurace) potřebnou informaci o alespoň jednom takovém směrovači. Zajímavé je, že snad vždy se pro tento směrovač používá starší (a dnes již nevhodná) terminologie - říká se mu brána, anglicky gateway. Většinou "výchozí brána", resp. default gateway, protože přes ni jsou přenášeny všechny pakety směřující ven z dané sítě, pokud není známo že by měly jít jinou cestou. Příklad nastavení takovéto výchozí brány na počítači s OS Windows ukazuje následující obrázek.

Příklad nastavení výchozí brány

Pokud ovšem výchozí směrovač (výchozí brána) není pro konkrétní cílovou síť tím správným, měl by to on sám poznat a měl by odesílající koncový uzel zpětně informovat o této skutečnosti. Tedy poslat mu vyrozumění ve smyslu: "data, určená pro uzel B, posíláš přes mne nesprávně. Správně by měla přecházet přes směrovač Y, který je ve tvém dosahu". Odesílající uzel, který dostane takovéto "ponaučení", by si jej měl vzít k srdci, a měl by se podle něj chovat - příště by už měl svá data posílat přes správný směrovač. Přitom směrovač, který se nachází v nesprávném směru, by neměl již přijatá data zahodit. Právě naopak, měl by být co nejvíce tolerantní a postarat se o jejich správné doručení. A to i v případě, že si jejich odesilatel nevezme jeho ponaučení k srdci a data stále posílá nesprávným směrem. To vše ale neplatí obecně, nýbrž jen v rámci sítí na bázi protokolů TCP/IP.

Směrování přes nesprávný směrovač (v TCP/IP)

Směrovací tabulky

K tomu, aby se směrovače mohly snáze a rychleji rozhodovat, udržují si potřebné (směrovací) informace v tzv. směrovacích tabulkách. Jejich obsah, resp. organizace, se může lišit, ale v nejjednodušším případě je takový, jak jej ukazuje následující obrázek č. 9: každé jednotlivá položka směrovací tabulky je vyhrazena jedné cílové síti. Součástí položky je pak i informace o tom, jak je cílová síť daleko, a hlavně kudy (kterým "odchozím" směrem) je třeba paket předat, aby se dostal blíže k cílové síti (neboli: kudy pokračuje cesta k této cílové síti).

Představa směrovacích tabulek

S popisovaným obsahem směrovacích tabulek souvisí ještě jedna důležitá skutečnost: směrování, jako rozhodování o dalším směru přenosu, vychází z příslušnosti cílového uzlu k určité síti. Jinými slovy: směruje se podle sítě, a nikoli podle konkrétního uzlu. Proto také jsou jednotlivé položky směrovacích tabulek (alespoň v TCP/IP) vyhrazeny celým cílovým sítím, a nikoli jednotlivým uzlům v těchto cílových sítích. Jinak by totiž počty položek ohromně narostly. Odpovídá to ostatně i rozdílu mezi přímým a nepřímým směrováním: po celé trase přenosu probíhá nepřímé směrování, a v každém kroku se zajišťuje přenos do další sítě jako takové (jako celku). Teprve v poslední (cílové) síti se již nejedná o nepřímé směrování, ale o směrování přímé (v rámci dané sítě). Zde už tedy směrovací tabulka není zapotřebí, protože doručení konkrétnímu uzlu v cílové síti zajistí zdejší linková vrstva.

Existence směrovacích tabulek se přitom netýká pouze směrovačů. Mají je i koncové uzly, protože i ony se podle nich musí rozhodovat při odesílání, přes který "odchozí" směrovač data poslat. Jejich směrovací tabulky ale bývají v praxi podstatně menší. Základem jejich obsahu je informace o existenci výchozí brány, kterou jsme si popisovali výše. Další položky pak do směrovací tabulky koncového uzlu přibývají obvykle postupně, na základě "upozornění" od směrovače, že správný směr vede jinudy (přes jiný směrovač, viz výše).

Adaptivní a neadaptivní směrování

Pojďme nyní k jinému důležitému aspektu: kdo a jak stanovuje a aktualizuje obsah směrovacích tabulek směrovačů? Zde už to totiž je komplikovanější, než u koncových uzlů.

V úvahu zde připadají dvě základní možnosti: "neadaptivní": obsah směrovacích tabulek (směrovačů) je dán apriorně a nemění se. Pak jej může jednorázově stanovit například správce sítě, a veškeré směrování bude následně fungovat vždy stejně. "adaptivní": směrovací tabulky směrovačů jsou na počátku nějak nastaveny, ale jejich obsah se průběžně aktualizuje, tak aby odrážel topologii soustavy sítí a reagoval na její změny.

Každá z těchto dvou variant samozřejmě má své výhody, ale i své nevýhody. Neadaptivní varianta nemá žádnou režii na své průběžné udržování (když k němu nedochází), a je také více odolná vůči eventuelním útokům, které by se snažily mechanismus směrování nějak nabourat. Proto se používá například tam, kde jsou zvýšené požadavky na bezpečnost. Nevýhodou neadaptivní varianty je ale její neschopnost reagovat na změny v síti a její topologii. To při zvýšených požadavcích na bezpečnost může být i výhodou, ale obecně je to nevýhodou, kvůli které lze tuto variantu doporučit jen tam, kde lze předpokládat zcela ojedinělé změny v topologii.

Naproti tomu adaptivní varianta přímo počítá s tím, že bude na eventuelní změny v topologii reagovat. Takže ji lze využít i tam, kde ke změnám dochází relativně častěji. Důležité ovšem je, že s touto adaptivností může být spojena i poměrně velká režie, na výměnu aktualizačních informací (informací o změnách v síti). Zde velmi záleží na tom, jaké varianty směrování (a výměny směrovacích informací) jsou konkrétně použity. Pojďme se proto podívat, jaké možnosti zde připadají v úvahu.

Centralizované směrování

Začněme nejprve poněkud specifickou variantou, označovanou jako centralizované směrování. Jde o řešení, v rámci kterého veškeré rozhodování (o volbě nejvhodnější cesty) provádí jeden centrální prvek, zatímco všechny směrovače již jen mechanicky naplňují jeho rozhodnutí. Lze si to představit také tak, že jednotlivé směrovače přestanou samy přemýšlet, a kdykoli neví co a jak mají dělat, zeptají se centrálního prvku. Tomu se říká "route server", což by se dalo rozepsat jako "server, poskytující jako svou službu informace o cestách". Na konkrétní dotaz tento server odpoví, a směrovač se podle toho zachová. A aby se při dalším paketu nemusel ptát hned znovu, a příliš tak nezatěžoval route server, každou odpověď si po nějakou dobu pamatuje ve své vyrovnávací paměti a podle ní se řídí. Tato doba přitom musí být volena velmi pečlivě. Kdyby totiž byla příliš krátká, pak by se směrovač ptal příliš často a příliš by zatěžoval route server. Naopak, když bude moc dlouhá, hrozí nebezpečí že směrovač nebude včas reagovat na nějakou změnu v topologii. Stále totiž bude vycházet z předchozí odpovědi route serveru, místo toho aby si vyžádal odpověď novou, která by již odrážela příslušnou změnu.

Představa centralizovaného směrování

Výhodou centralizovaného směrování je nulová režie na aktualizační informace, kterými by se jednotlivé směrovače jinak vzájemně informovaly o změnách. Další významnou výhodou je i soustředění veškeré "inteligence" do jednoho místa, což usnadňuje systémovou správu. Na druhou stranu zde ale vzniká "klíčové místo", s jehož výpadkem se celá soustava vzájemně propojených sítí stává nefunkční - jednotlivé směrovače se pak vůbec nedozví, do a jak mají dělat.

Izolované směrování

Další variantou směrování, vedle centralizovaného, je směrování označované jako izolované. To proto, že zde už se rozhodují jednotlivé směrovače, ale skutečně jen samy za sebe, aniž by přitom spolupracovaly s ostatními. Proto přívlastek "izolované". Jde ovšem o celou skupinu různých dílčích variant, mezi které patří mj.: záplavové směrování směrování metodou horké brambory náhodné směrování metoda zpětného učení a další.

Například záplavové směrování, které je v praxi relativně často používané, funguje skutečně tak jak naznačuje jeho název: každý směrovač rozešle přijatý paket do všech směrů, kromě toho odkud přišel. Tím vzniká jakási záplava, která dříve či později dorazí na místo svého správného určení. Současně je ale nutné správně a korektně eliminovat duplicitní pakety, které při záplavovém rozesílání vznikají, aby na místo svého určení dorazil každý paket jen jednou. Výhodou je velká robustnost - pokud existuje alespoň nějaká cesta k cíli, je tímto způsobem nalezena. A vlastně bez toho, aby směrovače vůbec potřebovaly nějaké směrovací tabulky.

Pro zajímavost se zmiňme ještě o metodě horké brambory. Ta se začíná používat (jako náhradní varianta) v situaci, kdy jinak používané směrování se dostává do problémů a směrovači hrozí zahlcení. Když se v některém odchozím směru začínají hromadit pakety, které směrovač nestíhá odeslat, může nastoupit právě směrování metodou horké brambory - směrovač volí odchozí směr nikoli podle toho, kudy by měl paket správně pokračovat, ale podle toho, který odchozí směr je právě nejméně vytížený (tj. kde se "horké brambory" dokáže co nejrychleji zbavit). Když se pak nebezpečí zahlcení podaří odvrátit, směrovač se zase vrací ke svému původnímu způsobu směrování.

Distribuované směrování

V praxi nejčastěji používané varianty směrování však spadají do kategorie "distribuovaných". To proto, že zde není žádný centrální prvek, který by o volbě směru rozhodoval (jako je tomu u centralizovaného směrování), ale celé rozhodování je rozděleno (distribuováno) mezi jednotlivé uzly, které na něm spolupracují (což je zase odlišnost od izolovaného směrování).

Jednou z variant distribuovaného směrování je takové, které je v angličtině označováno jako "vector-distance". To proto, že sousední směrovače si mezi sebou vyměňují celé své směrovací tabulky, i s jejich obsahem (viz výše). Každou položku směrovací tabulky si přitom lze představit jako vektor, který říká že z určitého směrovače se lze dostat do konkrétní cílové sítě takovým a takovým směrem, a že tato síť je tak a tak daleko. Když se pak nějaký směrovač dozví, ze směrovací tabulky svého souseda, že ten je vzdálen od určité cílové sítě X na Y jednotek, připočítá si k tomu svou vzdálenost od souseda, a vyjde mu že on se do sítě X dostane (přes svého souseda) se vzdáleností Y+1 jednotek (například). Právě toto je princip fungování varianty "vector distance", která je v praxi (v sítích TCP/IP) realizována například protokolem RIP (Routing Information Protocol). Ten je ale již poměrně staršího data, a v praxi se tolik nepoužívá.

Používanějším je protokol OSPF (Open Shortest Path First), který ale spadá pod jinou variantu - nikoli již "vector distance", ale "link state". To proto, že zde už si jednotlivé směrovače neposílají mezi sebou žádné vektory se vzdálenostmi, resp. celé své směrovací tabulky. Místo toho si posílají pouze informace o tom, že někde existuje nějaké spojení mezi dvěma uzly (směrovači), a je funkční. Každý směrovač uzel rozešle do celé soustavy vzájemně propojených sítí (obvykle pomocí záplavového směrování) informaci o tom, kdo jsou jeho sousedé a zda jsou pro něj dosažitelní (zda spojení mezi nimi funguje).

Ostatní směrovače, když takto "posbírají" informace o sousedech všech ostatních směrovačů, získají ucelenou představu o skutečné topologii celé soustavy sítí, a mohou si také samy vypočítat nejvhodnější cestu, odkudkoli kamkoli. Důležité také je, že aktualizační informace pak stačí posílat jen při nějaké změně (výpadku spojení, či naopak zřízení nějakého nového spojení mezi dvěma směrovači). Díky tomu je režie na průběžné šíření aktualizačních informací výrazně menší, než u variant "vector distance" - a tak je směrování "link state" (s protokolem OSPF) v praxi použitelné i pro podstatně větší sítě, než první varianta (s protokolem RIP).

V našem průchodu sedmi vrstvami Referenčního modelu ISO/OSI jsme se dostali až na úroveň vrstvy transportní. Ta je v rámci RM ISO/OSI čtvrtou v pořadí, ať již vrstvy počítáme "zdola", nebo "shora". Na transportní vrstvu se přitom můžeme dívat jako na jakousi přizpůsobovací vrstvu mezi trojicí nižších vrstev, orientovaných na přenos dat (vrstev fyzické, linkové a síťové), a trojicí vyšších vrstev, orientovaných už spíše na aplikace a jejich podporu. Naznačuje to ostatně i dnešní první obrázek.

Transportní vrstva v rámci Referenčního modelu ISO/OSI

V rámci síťového modelu TCP/IP transportní vrstva samozřejmě existuje také, ale je teprve druhou (počítáno odshora), resp. třetí vrstvou (odspodu). Jde o důsledek skutečnosti, kterou bychom měli dobře znát již z předchozích dílů tohoto seriálu: že zatímco referenční model ISO/OSI má sedm vrstev, TCP/IP má pouze čtyři vrstvy. A také s nimi vystačí. Navíc svou nejnižší vrstvu, vrstvu síťového rozhraní, TCP/IP samo nijak nedefinuje (ale používá zde řešení pocházející odjinud).

Transportní vrstva v TCP/IP

Ani menší počet vrstev v TCP/IP však nemění nic na tom, že transportní vrstva je první vrstvou (počítáno odspodu), která je přítomná až v koncových uzlech, a nikoli ve vnitřních uzlech sítě (ve směrovačích). Vzhledem k tomu má na starosti vzájemnou komunikaci koncových uzlů, pro kterou se i češtině vžilo označení, pocházející z angličtiny: end-to-end komunikace (doslova: komunikace "konec-konec").

Představa end-to-end komunikace

To, aby se transportní vrstva mohla soustředit na vzájemnou komunikaci koncových uzlů, jí umožňuje bezprostředně nižší vrstva - vrstva síťová. Ta má na starosti hledání vhodných cest v síti, resp. v soustavách vzájemně propojených sítí (přes jednotlivé směrovače), a samozřejmě i doručování dat po takovýchto cestách. Tím vlastně vytváří iluzi (určenou transportní vrstvě), že všechny koncové uzly jsou mezi sebou propojeny

přímo, stylem "každý s každým". Takže transportní vrstva se pak již může soustředit na další aspekty toho, jak si koncové uzly vzájemně vyměňují (předávají) svá data a komunikují mezi sebou. Ale jaké aspekty to vlastně jsou? Co přesně transportní vrstva dělá?To záleží i na tom, co a jak nabízí a poskytuje vrstva síťová - a co a jak na tom má či nemá transportní vrstva měnit, zda a co k tomu má přidávat atd.

Síťová vs. transportní vrstva ISO/OSI

Referenční model ISO/OSI a síťový model TCP/IP se liší i v tom, jakou mají představu o fungování své síťové vrstvy. RM ISO/OSI má blíže k "telekomunikačnímu paradigmatu", v rámci kterého vítězí představa inteligentní a na funkce bohaté sítě ("chytré sítě"), a třeba i jednoduchých ("hloupých") koncových uzlů. Součástí této představy je i to, že přenosy dat na všech úrovních (vrstvách) by měly probíhat spojovaným způsobem, a tedy s navazováním spojení mezi odesilatelem a příjemcem. Dále představa, že přenosy dat na jednotlivých vrstvách by měly být řešeny jako spolehlivé, a tedy starat se o nápravu toho, co se pokazí - jak eventuelních ztrát dat, tak i eventuelních výpadků spojení. Ovšem ne vždy bude tato náprava dokonalá (stoprocentní). Proto se počítá s tím, že tato "náprava" bude pokračovat i na vyšších vrstvách, které se také budou snažit o zajištění (lepší, resp. vyšší) spolehlivosti. Autoři ISO/OSI přitom správně předpokládali, že jejich síťová vrstva bude nasazována v různém prostředí, které se liší četností výpadků spojení a ztrát dat. Například v prostředí lokálních sítí, kde asi lze očekávat relativně málo takovýchto výpadků a ztrát. Nebo v prostředí veřejných datových sítí, kde mohou být nějaké výpadky spojení, ale data by se ztrácet neměla. A stejně tak v prostředí rozlehlých sítí, kde se data mohou ztrácet relativně častěji, a stejně tak může častěji vypadávat spojení.

Kvůli tomu se autoři ISO/OSI rozhodli zavést tři různé varianty (kategorie) síťových protokolů, kategorie A: pro prostředí, kde dochází k minimálním (žádným) ztrátám paketů a minimálním (žádným) výpadkům spojení kategorie B: pro minimální (žádné) ztráty paketů, a občasné výpadky spojení kategorie C: pro prostředí kde jsou občasné ztráty paketů a občasné výpadky spojení

Od transportní vrstvy se pak ve světě ISO/OSI očekává, že bude zachovávat spojovaný způsob fungování, a také že se bude snažit ještě lépe kompenzovat eventuelní výpadky spojení a ztráty dat. Dokonce se od ní očekává i určitá optimalizace, v tom smyslu že se může snažit navazovat více transportních spojení skrze jedno jediné síťové spojení. Motivace pro tuto optimalizaci pochází z prostředí veřejných datových sítí, kde se platilo za zřizování každého jednotlivého (síťového) spojení. Takže schopnost využít jedno takové spojení pro více spojení transportních mohla ušetřit náklady.

Celkově pak transportní vrstva ISO/OSI předpokládala pět různých variant (tříd) transportních protokolů, označovaných TP0 až TP4: třída TP0: je pouze jednoduchou nadstavbou nad síťovým protokolem kategorie A, nemění jeho vlastnosti třída TP1: je nadstavbou nad síťovým protokolem kategorie B, omezuje případné výpadky spojení třída TP2: je nadstavbou nad A, dokáže využít jedno síťové spojení pro více transportních spojení třída TP3: je nadstavbou nad B, omezuje případné výpadky spojení a dokáže využít jedno síťové spojení pro více transportních spojení třída TP4: je nadstavbou nad C, omezuje případné výpadky spojení a ztráty paketů

Celou představu ilustruje čtvrtý obrázek. Představa síťových a transportních protokolů ISO/OSI

Síťová vs. transportní vrstva TCP/IP

Ve světě TCP/IP se uplatňuje "počítačové" paradigma, volající po "hloupé síti a chytrých uzlech". Tedy po maximálním zefektivnění přenosové části sítě, která bude nabízet jen minimum funkcí v co nejjednodušším provedení (proto "hloupá síť"), ale zato je bude realizovat velmi efektivně (rychle). O všechno ostatní, pokud je

to vůbec požadováno, by se měly starat až koncové uzly, na úrovni transportní (nebo aplikační) vrstvy, a nikoli přenosová část sítě (na úrovni vrstvy síťové).

Konkrétním příkladem toho, co je ve světě TCP/IP považováno za něco "ne zcela nezbytného", čím by se síťová vrstva neměla zatěžovat a zpomalovat, je zajištění spolehlivosti přenosů. Tedy kompenzace (náprava) případných ztrát paketů, pokud k nim vůbec dojde. Je-li vůbec spolehlivost přenosů požadována, měly by si ji zajistit koncové uzly samy. Vzhledem k celému paradigmatu ("hloupá síť, chytré uzly") k tomu mají lepší předpoklady než síť jako taková, resp. její síťová vrstva.

Dalším rozdílem oproti ISO/OSI je to, že v TCP/IP se na úrovni síťové vrstvy jednoznačně preferuje nespojovaný způsob fungování, a tedy bez navazování spojení mezi odesilatelem a příjemcem. To má významný důsledek v tom, že nemůže docházet k žádným výpadkům spojení (když žádné takové ani není navazováno). A také není třeba (na síťové vrstvě) ani žádné takové výpadky kompenzovat.

Společným důsledkem obou výše uvedených skutečností (preference nespolehlivé a nespojované komunikace na úrovni síťové vrstvy) je pak to, že TCP/IP nepotřebuje rozlišovat různé kategorie síťových přenosových protokolů, jako RM ISO/OSI (viz jeho kategorie A, B a C). Místo toho vystačí jen s jedním jediným síťovým protokolem, a to protokolem IP. Snad netřeba už tolik zdůrazňovat, že funguje nespojovaně a nespolehlivě - a že dokáže fungovat snad v jakémkoli prostředí (nad jakoukoli přenosovou technologií linkové vrstvy, resp. vrstvy síťového rozhraní).

Představa síťových a transportních protokolů v TCP/IP

V TCP/IP pak nad takto koncipovanou síťovou vrstvou existuje transportní vrstva, která nabízí dva různé transportní protokoly (místo pěti v ISO/OSI). Liší se v tom, zda zachovávají celkový způsob fungování síťového protokolu IP (tj. jeho nespojovaný a nespolehlivý charakter komunikace), nebo zda se jej snaží měnit - na spojovaný a spolehlivý. S oběma takto koncipovanými transportními protokoly jsme se už v předchozích dílech setkali: protokol UDP (User Datagram Protocol): je pouze jednouchou nadstavbou nad protokolem IP a funguje stejně jako on (tj. nespojovaně a nespolehlivě) protokol TCP (Transmission Control Protocol): je už složitější nadstavbou nad protokolem IP, a mění jeho způsob fungování - na spojitý a spolehlivý

Logika existence dvou transportních protokolů, které jsou vzájemně alternativní, je v tom že aplikace si mohou samy svobodně vybrat, který z nich chtějí používat. Například "klasické" počítačové aplikace, jako například přenos souborů, el. pošta atd., preferují zajištění spolehlivosti, a dávají přednost protokolu TCP. Naproti tomu novější multimediální aplikace dávají přednost spíše protokolu UDP, protože ten se nezdržuje zajišťováním spolehlivosti, a dokáže tak přenášet data rovnoměrněji a s menší prodlevou (latencí), než protokol TCP. Příklad preferencí některých aplikací naznačuje obrázek č. 6.

Volba transportních protokolů v TCP/IP

Další úkol transportní vrstvy

Transportní vrstva má obecně (v RM ISO/OSI i v TCP/IP) ještě další úkoly, kromě toho co jsme si popisovali v předchozích odstavcích. Vlastně jsme si to naznačili již v perexu: transportní vrstva je první vrstvou (měřeno "odspodu"), která se již nedívá na jednotlivé uzly jako na dále nedělitelné celky, ale rozlišuje v nich jednotlivé entity, které vystupují buď jako příjemci, nebo jako odesilatelé dat.

Abychom si trochu přiblížili, o co vlastně jde: na jednom počítači může běžet několik aplikací, které komunikují s dalšími uzly v síti, a to nezávisle na sobě. Například uživatel může mít na svém osobním počítači puštěný WWW browser, skrze který právě brouzdá báječným světem WWW. Vedle toho má puštěného i klienta elektronické pošty, skrze kterého přijímá svou elektronickou korespondenci. Tím výčet možností samozřejmě zdaleka nekončí, ale pro nástin podstaty problému stačí alespoň dva různé běžící programy, resp. aplikace.

Představme si totiž, co se má stát v okamžiku, kdy uživatelův počítač přijme nějaká data. Komu mají být předána? Webovému browseru? Nebo emailovému klientovi? Jistě by to mělo záviset na tom, zda přijatá data představují nějakou WWW stránku, zprávu el. pošty, nebo třeba soubory, přenášené prostřednictvím protokolu FTP či něco ještě jiného. Ale kdo by to měl zkoumat, a podle čeho?

Síťová vrstva takovéto otázky neřeší. Pro ni je každý uzel sítě dále nedělitelný celek. Takže když přijme nějaká data pro daný uzel, nezajímá se o to, komu (které aplikaci) patří, a vždy je předá své bezprostředně vyšší vrstvě - vrstvě transportní. Teprve transportní vrstva pak má za úkol rozlišovat, komu - v rámci daného počítače - přijatá data patří, a předat je právě a pouze jemu. Obdobně při odesílaní, kdy transportní vrstva přijímá data - zde také rozlišuje, od koho jsou (a tuto informaci musí vhodným způsobem zachovat pro koncového příjemce dat).

Můžeme si to celé představit také tak, že síťová vrstva vytváří přenosový kanál, který je společně využíván všemi odesilateli, resp. příjemci na daném uzlu, s tím že až transportní vrstva zajišťuje na straně odesilatele potřebné "sloučení" (multiplex) dat od různých odesilatelů, do jednoho datového toku, a na straně příjemce zase potřebné "rozbočení" (demultiplex) těchto dat podle toho, komu jsou určena. Vše naznačuje i následující obrázek č. 7, který je oproti obvyklým konvencím jakoby pootočen o 90 stupňů.

Představa multiplexu a demultiplexu na transportní vrstvě

Jinou představu téhož ukazuje i další obrázek (č. 8), na kterém již lze názorně ukázat jeden významný aspekt, týkající se adresování. Je opět společný pro RM ISO/OSI i TCP/IP, a týká se adresování na úrovni transportní vrstvy.

Představa multiplexu a demultiplexu na transportní vrstvě

Porty a body SAP

Jak již víme, na úrovni síťové vrstvy se používají síťové adresy (v TCP/IP tzv. IP adresy), které identifikují jednotlivé uzly jako celky. Přesněji: identifikují jedno síťové rozhraní, s tím že některé uzly (například směrovače) jich mohou mít více. Rozhodně ale tyto síťové adresy nerozlišují jednotlivé příjemce a odesilatele v rámci daného uzlu. Rozlišování jednotlivých příjemců a odesilatelů má na starosti až transportní vrstva. K tomu také musí používat nějaké konkrétní adresy (transportní adresy), které by měly mít relativní charakter (měly by se vztahovat jen k danému uzlu, resp. rozlišovat jen v rámci tohoto uzlu).

Jak by ale tyto transportní adresy měly vypadat?

Problém je v tom, že na různých systémových platformách (například v prostředí MS Windows, Unixu, Linuxu, MAC OS a dalších) mohou být odesilatelé a příjemci obecně různého typu - mohou to být různé procesy, eventuelně systémové úlohy, vlákna, nebo třeba i rezidentní programy (ještě ve starém MS DOSu). Jejich identifikace v rámci příslušné platformy se může i diametrálně lišit. Někdy mohou být identifikováni čísly, jindy znakovými identifikátory apod. Hlavně ale: příslušné entity (procesy, úlohy atd.) vznikají a zase zanikají dynamicky. Takže není dopředu známo, kdo (jaký proces, úloha atd.) bude kde existovat, a měl by přijímat data, určená například WWW serveru (nebo poštovnímu serveru apod.).

Všimněte si dobře jedné věci: na straně příjemce nejde ani tak o to, kdo je ten kdo nějaká data přijímá, jako spíše o to, že "ten někdo" poskytuje určitou službu - a tudíž přijímá data, určená poskytovateli příslušné služby. Tomu, kdo je v roli klienta (například WWW klienta, a vznáší požadavek na nějakou WWW stránku), může být celkem jedno, jaký konkrétní proces na druhé straně plní roli WWW serveru. Důležité pro něj je, aby někdo takový existoval a fungoval, a aby klient věděl, kam mu poslat svůj požadavek. Takže by se vlastně hodila spíše nějaká adresace ve stylu "příjemcem je ten, kdo poskytuje službu AB", místo adresace ve smyslu "příjemcem je proces s identifikátorem XY". A tak to také v praxi (ve světě RM ISO/OSI i TCP/IP) skutečně chodí.

Příslušné adresování, používané na úrovni transportní vrstvy, však není založeno přímo na představě poskytovatelů služeb. To by nemuselo být až tak šikovné, a třeba by to bylo někdy i omezující. Místo toho je použit jiný koncept, založený na představě "přechodových bodů" mezi transportní vrstvou a vrstvou bezprostředně vyšší (což je ISO/OSI vrstva relační), a u TCP/IP vrstva aplikační. Tyto přechodové body jsou určitou abstrakcí, kterou je nejlépe si připodobnit k vyrovnávají paměti (bufferu) s režimem fronty: z jedné strany se do přechodového bodu určitá data vkládají (zapisují), a z druhé strany se z ní ve stejném pořadí vyjímají (čtou). Představu ilustruje následující obrázek (č. 9).

Představa přechodového bodu (portu) jako fronty

Přechodové body jsou obecně obousměrné (lze si je představit jako dvě samostatné fronty s opačným "směrem"). V prostředí RM ISO/OSI se jim říká "body přístupu ke službám" (SAP, Service Access Points), ale známější asi jsou pod svým označením z prostředí TCP/IP, kde se o nich mluví jako o portech.

Porty vs. procesy

Výhodou portů (přechodových bodů SAP) je tedy to, že jsou abstrakcí - a jako takové mohou být všude (na všech platformách) stejné. To má zásadní výhodu v tom, že s jejich existencí je pak možné počítat "dopředu" (apriori), stejně jako s tím, že mají stejné vlastnosti. Konkrétní způsob jejich realizace na každém jednotlivém uzlu sítě naopak může zůstat skryt. Jednotné (všude stejné) může být i označení portů, resp. bodů SAP, a tím i jejich adresování (na úrovni transportní vrstvy). V prostředí TCP/IP jsou jednotlivé porty adresovány skrze pořadová čísla. Přesněji: pomocí celých nezáporných čísel (0,1, 2, 3, 4 atd.). V praxi se pak hovoří o číslech portů. Třeba o portu číslo 80, o portu č. 25 apod. Takže transportními adresami (relativními adresami na úrovni transportní vrstvy) jsou v TCP/IPO právě tato čísla portů. Důležité ale je uvědomit si, že port (bod SAP) ještě není to samé, jako proces (úloha, vlákno atd.), které skutečně přijímá a zpracovává nějaká data, nebo je naopak generuje. Port je skutečně jen jakýsi "průchozí bod" (s režimem fronty), za kterým je teprve "schována" příslušný proces (úloha atd.). Ovšem když porty existují "dopředu" (apriori), zatímco aplikační entity (procesy, úlohy) vznikají dynamicky, podle momentálních potřeb, musí i jejich vzájemná vazba být dynamická. V praxi to vypadá tak, že když je vytvořen nějaký proces, a ten má nějak komunikovat v prostředí sítě, musí se nejprve "sdružit" (tzv. asociovat) s některým portem. Teprve pak může odesílat svá data (skrze tento port), a také je (skrze tento port) přijímat. Protistrana, která s takovýmto

procesem komunikuje, musí znát číslo příslušného portu, a svá data také adresuje tomuto portu (přesněji: na daný cílový uzel, a v rámci tohoto cílového uzlu příslušnému portu).

Obecně přitom platí, že jeden proces (úloha atd.) může být asociován (sdružen) s více porty. Naopak to ale neplatí: s jedním portem může být sdružen (asociován) nejvýše jeden proces. Důvod je jednoduchý: copak by asi takový port dělal, kdyby přijal nějaká příchozí data? Jak by vybíral mezi dvěma (či dokonce více) procesy, kterým by tato data měl předat?

Představa asociování procesů k portům (v TCP/IP)

Servery a jejich klienti

Ukažme si nyní na konkrétním příkladu, jak celá představa o portech a procesech zapadá do běžné praxe, kdy spolu v prostředí sítě spolu komunikují aplikace a procesy v roli serverů a jejich klientů. Třeba když si uživatel na svém osobním počítači pustí WWW browser, a tomu zadá, že chce navštívit nějakou konkrétní WWW stránku, např. na adrese www.earchiv.cz (kde má svůj osobní archiv autor tohoto seriálu). Webový browser si nejprve nechá přeložit symbolické doménové jméno (www.earchiv.cz) na odpovídající IP adresu, a na ni pak pošle požadavek na stažení konkrétní stránky (např. index.php3). Na cílovém počítači je ale třeba předat příslušný požadavek tomu procesu, který zde plní roli WWW serveru. Klient (uživatelův browser) přitom dopředu ví, že takovýto proces je sdružen (asociován) s portem číslo 80, a tak jej adresuje právě tomuto portu. Proces, který na adrese www.earchiv.cz funguje jako WWW server, tak požadavek dostane, a v odpovědi na něj zašle klientovi požadovanou WWW stránku (index.php3). Přitom také musí uvést nějaké číslo portu, na které má být odpověď klientovi doručena. Server tedy standardně posílá svou odpověď na stejný port (na straně klienta), ze které mu přišel původní požadavek.

Představa aplikačního spojení

Celou situaci s komunikací klienta a serveru názorně ukazuje předchozí obrázek (č. 11), kterým si můžeme znovu připomenout jiný úkol transportní vrstvy, popisovaným v úvodu: měnit nespolehlivý a nespojovaný způsob komunikace (na úrovni síťové vrstvy, pomocí protokolu IP) na spojovaný a spolehlivý (na úrovni transportní vrstvy, pomocí protokolu TCP), nebo jej ponechávat beze změny, jako nespolehlivý a nespojovaný (pomocí protokolu UDP) - podle toho, co si vybere příslušná alikace. Přitom služba World Wide Web (WWW) je příkladem aplikace, která dává přednost spojovanému a spolehlivému přenosu, a využívá tedy služeb transportního protokolu TCP.

Jen pro ilustraci si naznačme ještě to, jak může jeden WWW server současně poskytovat své služby, skrze jeden a ten samý port (číslo 80), více klientům. Když mu všichni posílají své požadavky na stejnou adresu (IP adresa, port č. 80), jak pozná od koho co pochází a kam má zaslat požadovanou WWW stránku? Odpověď je principiálně jednoduchá a stejná pro všechny druhy serverů: u každého požadavku si pamatují, ze kterého spojení přišel. A toto spojení je obecně určeno pěticí údajů: transportním protokolem (v případě WWW jde o TCP) IP adresou a portem na straně klienta IP adresou na portem na straně serveru

Takže když server dostane dva požadavky od klientů na různých počítačích, liší se příslušná spojení už IP adresou klienta. A pokud by snad šlo o požadavky od dvou různých klientů, běžících na stejném počítači (například když má uživatel puštěny dva browsery, případně jen dvě okna či záložky ve stejném browseru), rozliší je alespoň podle různého čísla portu, použitého na straně klienta.

Vše ilustruje i následující obrázek (č. 12)Představa více spojení, vedoucích ke stejnému serveru

V případě, že komunikace mezi klientem a serverem probíhá nespojovaně (prostřednictvím transportního protokolu UDP), je identifikace odesilatelů a příjemců obdobná. Server dokáže rozlišit požadavky různých klientů podle IP adresy a čísla portu (na straně odesilatele), i když zde žádné spojení vůbec nevzniká.

Konvence o tzv. dobře známých portechZastavme se na závěr u jedné důležité drobnosti: jak může webový klient (browser) dopředu vědět, že své požadavky má posílat "svému" serveru na port číslo 80? Jak může vědět poštovní klient, že má odesílanou poštu posílat "svému" serveru na port číslo 25? Jak je tomu pro ostatní služby a aplikace?

Odpověď je taková, že musí existovat určitá konvence, ve výše naznačeném smyslu, a ta musí být dopředu známá všem, kteří ji potřebují znát. To jsou jak ti, kteří programují a provozují servery, tak i ti, kteří píší jejich klienty. Naopak tato konvence nemusí být známa běžným uživatelům. Proč? Například když WWW klient (browser) dostane od svého uživatele pokyn k načtení nějaké konkrétní WWW stránky, automaticky předpokládá, že jej má poslat serveru na port číslo 80, a tak to také dělá. To mu naordinoval (naprogramoval do něj) už jeho autor. Samozřejmě, pokud by uživatel měl jiné přání, a explicitně by si vyžádal zaslání svého požadavku na nějaký jiný port (např. na port č. 8080, skrze URL ve tvaru http://www.earchiv.cz:8080/index.php3), browser by to respektoval. Ovšem aby takový požadavek mohl být korektně přijat a vyřízen, musel by i na cílovém počítači existovat WWW server, asociovaný s příslušným portem (zde: s portem číslo 8080). Při nějakém testování či

ladění tomu tak může být, při běžném rutinním provozu to ale už není zvykem (a WWW server "sedí" na standardním portu č. 80).

Zpět ale k samotné konvenci o tom, který port je k čemu předem vyhrazen: portům, jejichž význam je dopředu stanoven, se v TCP/IP říká příznačně: dobře známé porty (anglicky: well-known ports). Jde obecně o porty v rozsahu od 0 do 1023, a příslušnou konvenci spravuje orgán jménem IANA (Internet Assigned Numbers Autority). Dříve ji publikoval pravidelně (jednou za rok, později každých 6 měsíců) ve formě dokumentu RFC. Dnes je tato konvence zveřejňována již průběžně, na WWW stránkách IANA.

Konkrétně na adrese http://www.iana.org/assignments/port-numbers. Malou část této konvence vidíte v následující tabulce. Port # Popis21 FTP 23 Telnet 25 SMTP 69 TFTP70 Gopher80 HTTP 88 Kerberos110 POP3 119 NNTP 143 IMAP161 SNMPTabulka 1: Část konvence o tzv. dobře známých portech

V našem putování vrstvami Referenčního modelu ISO/OSI, směrem "zdola nahoru", jsme se dostali až k nejvyšším vrstvám, označovaným jako "aplikačně orientované". Jsou to vrstvy, nacházející se nad vrstvou transportní, kterou jsme se zabývali minule.

Jak vidíme na dnešním prvním obrázku, počet těchto vrstev se v ISO/OSI a TCP/IP výrazně liší - a to si určitě zaslouží vysvětlení. Takže proč tomu tak je?

Aplikačně orientované vrstvy v RM ISO/OSI a v TCP/IP

Odpověď je taková, že autoři obou architektur přemýšleli o tom, zda a jak často budou aplikace potřebovat určité funkce (prezentační a relační funkce, viz dále). No a autoři RM ISO/OSI dospěli k závěru, že spíše častěji - a tak považovali za správné poskytnout tyto funkce všem aplikacím, právě formou samostatné prezentační a relační vrstvy. Naopak autoři TCP/IP dospěli při svých výchozích úvahách k závěru, že využití těchto funkcí nebude až

tak časté, a tak se nevyplatí vnucovat je každému (ve formě samostatných vrstev). A pokud je některá aplikace potřebovat bude, ať si je raději zajistí (implementuje) sama, podle svých vlastní představ, ale hlavně ve vlastní režii.

Právě režie je totiž faktorem, který v uvedených úvahách sehrál významnou roli. Každá vrstva už svou samotnou existencí představuje určitou režii, vynakládanou na to, aby data "prošla" skrze takovouto vrstvu. No a pokud by ve většině případů takováto vrstva vlastně s daty nic nedělala, pak by režie na průchod vrstvou byla úplně zbytečná. Proto autoři TCP/IP raději příslušné vrstvy nezařadili do svého vrstevnatého modelu (když usoudili, že funkce těchto vrstev nebudou příliš často využívány). Naopak autorům RM ISO/OSI vyšlo, že když bude příslušné funkce využívat většina aplikací, režie na existenci samostatných vrstev bude účelně vynaložená. Abychom různá rozhodnutí autorů RM ISO/OSI a TCP/IP mohli plně docenit, pojďme si nyní naznačit trochu podrobněji, v čem vlastně spočívají prezentační a relační služby.

Relační vrstva a relační služby

Relační vrstva je v ISO/OSI asi nejvíce kritizovanou vrstvou, kvůli tomu, že toho má relativně nejméně na práci. Původní představa autorů zřejmě byla taková, že v této vrstvě budou soustředěny takové funkce, které usnadňují a podporují vzájemnou interakci komunikujících stran (tzv. relace, anglicky: sessions). Například ve smyslu zajištění bezpečnosti takovéto interakce. Nebo ve smyslu podpory transakčního zpracování, kde je důležité, aby se žádná transakce neprovedla "jen tak napůl", ale vždy jen úplně celá (nebo se naopak neprovedlo vůbec nic). Příkladem může být nějaká finanční transakce, spočívající v odepsání určité částky z jednoho účtu, a připsání téže částky na jiný účet. Tady by skutečně nebylo korektní, aby proběhla jen jedna část transakce (odepsání částky z jednoho účtu), ale už se neprovedly ostatní části transakce (připsání na jiný účet).

Již na tomto prvním příkladu je dobře patrné hlavní dilema: mají být takovéto věci, jako je podpora transakcí, řešeny samostatně, na úrovni relační vrstvy, a tudíž pro všechny aplikace stejně? Nebo je vhodnější, aby si je aplikace řešily samy, podle svých vlastních představa? Tady je vhodné si uvědomit, že třeba bankovní aplikace asi budou mít podstatně přísnější požadavky na "kvalitu" zajištění transakcí, než nějaké jednodušší databázové aplikace, kde nehrozí tak velké následky při nekorektním provedení transakce. I v tomto ohledu zřejmě autoři TCP/IP usoudili, že je lepší, když si podporu transakcí udělá každá aplikace sama, podle svého (hlavně podle svých nároků a požadavků), zatímco autoři RM ISO/OSI byli opačného názoru. Současná praxe dává celkem jednoznačně za pravdu autorům TCP/IP.

Původně uvažované úkoly relační vrstvy samozřejmě nekončily u již zmiňované bezpečnosti a transakčního zpracování. Zahrnovaly například podporu vzájemné synchronizace komunikujících stran (ovšem v jiném smyslu, než jak jsme mluvili o synchronizaci na úrovni fyzické vrstvy). Zde jde kupř. o to, že když při nějakém přenosu většího objemu dat mezi dvěma stranami dojde k výpadku spojení, musí se začít úplně odznova: navázat nové spojení a přenášet data od začátku. Relační vrstva však může nabízet výhodnější možnost: vrátit se k určitému "kontrolnímu bodu" a pokračovat od něj a nikoli od začátku. Takovýchto kontrolních bodů může existovat více, a v přerušené relaci pak lze pokračovat od kteréhokoli z nich. Vlastně ne nutně od kteréhokoli, protože to by bylo moc drahé. Jednotlivé kontrolní body jsou totiž jakési body zotavení, v rámci kterých je uschován celý stav právě probíhající relace (včetně dosud přenesených dat). A to představuje dost velkou režii, kvůli které se starší kontrolní body již mohou "uvolňovat" a není možné se k nim vracet.

Situaci naznačuje následující obrázek, s vedlejšími a hlavním kontrolním bodem (hlavní je ten kontrolní bod, přes který se již nelze vrátit hlouběji do historie relace, ke starším vedlejším bodům).

Představa kontrolních bodů (v rámci probíhající relace)

Do relační vrstvy by nejspíše patřily i takové služby, jaké dnes v rámci TCP/IP zajišťuje protokol SIP. Ten má podporu relací dokonce ve svém názvu, protože jeho jméno je zkratkou od Session Initiation Protocol (doslova: podpora navazování relací). Je z oblasti internetové telefonie, a službám na bázi VOIP slouží k navazování telefonických hovorů. Řeší zejména takové věci, jako je vyhledání volaného (podle telefonního čísla), tak aby k němu mohlo být navázáno transportní spojení a následně veden hlasový hovor. Příznačné ovšem je, že v rámci TCP/IP jde o aplikační protokol - protože, jak již víme, TCP/IP nemá samostatnou relační vrstvu. A docela dobře se bez ní obejde.

Prezentační služby: hlavně konverze

Zatímco u relační vrstvy není úplně snadné vysvětlit, co by vlastně měla mít na starosti, v případě prezentační vrstvy je to naštěstí snazší. Stačí vyjít z následující úvahy: všechny nižší vrstvy (pod prezentační vrstvou) se snaží přenášet data tak jak "stojí a leží", aniž by se jakkoli změnila. Můžeme si to představit také tak, že přenáší skupiny bitů a snaží se, aby se při přenosu nezměnil ani jeden bit. Jenže to nemusí být vždy správné! Proč?

Třeba proto, že ona data mají určitý význam. Může to být například text, mohou to být čísla, nebo nějaké obecnější datové struktury, od jednoduchých vícerozměrných polí až po struktury provázané pointry. Ovšem na různých platformách mohou být stejné texty, stejná čísla, či stejné datové struktury reprezentovány úplně jinak. Třeba jen u textů může být rozdíl v tom, zda jsou jednotlivé znaky kódovány v kódu ASCII, v kódu EBCDIC, nebo v nějakém úplně jiném kódu (Unicode atd.). Nehledě již na různé národní znakové sady (CP xy atd.). Asi není těžké nahlédnout, že v takovém případě musí být přenášené texty vhodně překódovány (obecně: konvertovány, pomocí vhodné konverze). A právě to má na starosti vrstva prezentační: stará se o to, aby přenášená data měla stejný význam pro obě komunikující strany.

Pro dokreslení celé problematiky konverzí se zmiňme ještě o jednom "ještě základnějším" rozdílu, než jakým je kódování jednotlivých znaků v textech. Jde o pořadí bytů (tzv. byte order), přesněji o způsob umisťování vícebytových položek do paměti. Pro jednoduchost si to představme na dvoubytovém slově (tj. na dvou bytech, tvořící jednu položku). Máme-li nějakou dvoubytovou hodnotu, například 1234H (hexadecimálně), můžeme ji uložit do dvou paměťových míst (každém o velikosti jednoho bytu) dvěma různými způsoby: vyšší polovinu bitů (12H) do paměťového místa na vyšší adrese (např. na adrese 1), a nižší polovinu bitů (34H) do paměťového místa na nižší adrese (např. 0), nebo vyšší polovinu bitů (12H) vložíme do paměťového místa na nižší adrese (0), a nižší polovinu bitů (34H) do paměťového místa na vyšší adrese (1).

Představa konvence Little Endian a Big Endian

Obě možnosti jsou stejně smysluplné, a žádná z nich není výhodnější než ta druhá. Pro jejich označení se používají termíny, převzaté z angličtiny: Little Endian, resp. Big Endian. Proč, stojí za malou vsuvku, kterou si můžete přečíst v samostatném boxu (… prosím dát vhodný odkaz na následující text, který tvoří tělo boxu). V běžné praxi jsou obě varianty rozloženy víceméně rovnoměrně: například procesory Intel používají konvenci Little Endian, zatímco procesory Motorola konvenci Big Endian. Variantu Big Endian používají také protokoly TCP/IP.

Tlustokoncoví proti tenkokoncovým, aneb: proč říše Lilliput bojuje proti říši Blefuscu O komplikovanějších věcech se lidé obvykle dohodnou relativně snadno. Ale běda, jak přijde na přetřes něco jednoduchého, až přímo banálního. Něco, čemu rozumí každý. Pak se snad vždy najdou lidé, kteří se potřebují vypovídat - a hlavně vehementně prosazovat to či ono stanovisko (lhostejno které). Někdy jakoby platila nepřímá úměra: čím banálnější je celá kauza, tím větší vášně provází volbu jedné z možných variant. V dnešní době Internetu z toho bývají nekonečné flamewars ("psané" slovní přestřelky), které si v ničem nezadají s dřívějšími formami lidských hádek. Lidská tendence k hádavosti, i nad největšími banalitami, je nejspíše tak stará, jak lidstvo samo. Celý tento nešvar již v 18. století hezky zparodoval Jonathan Switft, ve svých známých Gulliverovách cestách. To když popisoval, jak se jeho hlavní hrdina dostal do říše Blefuscu, která byla právě ve válce s říší Liliput ohledně toho, zda se mají vajíčka rozbíjet na tenčím konci, nebo naopak na tlustším konci. V anglickém originále to je "at the little end" (na užším konci), resp. "at the big end" (na tlustším konci). Proto také Switft ve svém díle označil znesvářené strany jako "Little Endians" a "Big Endians" (v českém překladu jako "tenkokoncoví" a "tlustokoncoví"). Původní inspirací Jonathana Swifta přitom byly náboženské spory mezi Anglií a Francií, přesněji mezi anglikánskou církví a katolickou církví ve Francii, a ve svých Gulliverových cestách chtěl upozornit na malichernost jejich podstaty. Na způsob, jakým Swift zasadil svou kritiku malicherných sporů zasadil do svého literárního díla, si v roce 1980 vzpomněl pan Danny Cohen, když psal odborný text pojednávající o problému kolem pořadí bytů. I on chtěl nějak vyřešit vlekoucí se učené disputace ohledně toho, které pořadí bytů je správné (která varianta ukládání vícebitových položek do paměti je vhodnější). A aby zdůraznil malichernost těchto sporů, které jakoby nebraly konce, vypůjčil si Swiftovu terminologii, a poprvé pojmenoval obě varianty jako "Little Endian" a "Big Endian". Celý svůj text pak nazval velmi příznačně: "On Holy Wars and a Plea for Peace" (O svatých válkách a volání po míru). Napsal to tak hezky a od srdce, že se jím navržená terminologie ujala a používá dodnes. Tlustokoncoví však nabyli na dvoře císaře blefuskuánského tolik vážnosti a zde doma jim jejich strana tajně poskytuje tolik soukromé podpory a tak je podněcuje, že obě říše vedou posledních šestatřicet měsíců se střídavým štěstím krvavou válku. Za tu dobu jsme přišli o čtyřicet znamenitých lodí a mnohem více menších plavidel s třiceti tisíci nejlepších námořníků a vojáků. Počítá se, že nepřítel utrpěl o něco větší škodu než my." Jonathan Switft, Gulliverovy cesty: O stranách podpatkářů a válkách kvůli vejcím

Linearizace a ASN.1 místo XML

Pořadí bytů, alias volba mezi Big Endian a Big Endian, je samozřejmě jen jednou drobnou kapkou do celkové mozaiky toho, co zajišťuje prezentační vrstva. Abychom správně docenili její význam a princip fungování, řekněme si ještě o jedné důležité věci: když má prezentační vrstva přenést nějaká konkrétní data "na druhou stranu", musí je nejprve "zlinearizovat". Tedy převést do takového tvaru, aby mohla být přenesena po lineární (jednorozměrné) přenosové cestě. Například u dvourozměrných polí si to lze představit docela snadno: vezmou s postupně jednotlivé sloupce (nebo naopak řádky), které už lineární jsou, a ty se posílají. Viz obrázek č. 4.

Představa linearizace dvourozměrného pole

V případě vícerozměrných polí je řešení prakticky stejně snadné, byť jen trochu náročnější na představivost. Složitější to ale může být u obecnějších datových struktur. A zdaleka nejsložitější je to pak u datových struktur, provázaných ukazateli (tzv. pointry). Ukazatele totiž nelze přenést vůbec, protože mají pouze "místní význam" u odesilatele. Místo toho je nutné příslušnou datovou strukturu nahradit nějakým ekvivalentem, který již ukazatele (pointry) neobsahuje. To je obvykle možné, ale podtrhuje to význam dalšího úkolu, který musí prezentační vrstva řešit. Tímto úkolem je popsat data, přenášená skrze přenosový kanál, takovým způsobem, aby je příjemce dokázal zase "vrátit do původní podoby". Tedy rekonstruovat je tak, aby pro něj měly stejný význam, jako pro odesilatele.

S určitým zjednodušení si můžeme představit, že prezentační vrstva se tohoto úkolu dokáže zhostit tak, že k přenášeným datům přibalí jakousi "průvodku". Tedy popis toho, co se vlastně přenáší, aby to příjemce dokázal správně "vybalit" a následně "poskládat". Samozřejmě tak musí činit způsobem, který bude předem dohodnutý a známý oběma stranám (jinak by příjemce nerozuměl ani samotné průvodce).

Ve světě ISO/OSI, kde existuje samostatná prezentační vrstva, se za tímto účelem dokonce navrhl samostatný (a tedy vlastně umělý) jazyk, pojmenovaný ASN.1 (Abstrakt Syntax Notation, verze 1). Lze si jej představit jako programovací jazyk, ovšem bez výkonných příkazů, pouze s deklaracemi. Stalo se tak v době, kdy svět ještě neznal jazyk XML, který by se k tomu velmi dobře hodil. Ale je otázkou, zda by jej ve světě spojů použili, i když by býval již existoval. Filosofie autorů Referenčního modelu ISO/OSI totiž byla taková, že všechno museli vymyslet sami. V lepším případě, když už něco šikovného vymyslel někdo jiný, alespoň to potřebovali "posoudit" a vydat jako svůj vlastní standard.

Tušili jste, že třeba takový Ethernet, standardizovaný společností IEEE jako standard (řady) IEEE 802.3, existuje i jako standard ISO/OSI, konkrétně ISO 8803?

Představa "průvodky" v jazyku ASN.1

"Pseudovrstvy" v TCP/IPJak jsme si již uvedli výše, samostatná relační a prezentační vrstva je pouze v Referenčním modelu ISO/OSI, ale v TCP/IP nikoli. Zde se předpokládá, že ta aplikace, která relační či prezentační služby potřebuje, si je zajistí sama, ve vlastní režii. O důvodech jsme se také již zmiňovali (jde hlavně o úsporu režie na samostatné vrstvy). Přesto ale i v TCP/IP existuje jakési alternativní řešení, které velmi připomíná rčení o "zlaté střední cestě" mezi dvěma extrémy (existencí samostatných vrstev a jejich úplnou absencí). Jde o řešení, vzniklé v souvislosti s protokolem NFS (Network File System), který v rámci TCP/IP slouží ke sdílení souborů. Pochází pod firmy Sun Microsystems, a bylo to vlastně úplně první řešení, které vzniklo u komerční firmy (tj. jako její vlastní, tj. "proprietární"), ale pak bylo otevřeno a mohlo se stát otevřeným internetovým standardem. Hlavně ale: i tato aplikace potřebovala zajistit určité relační a prezentační funkce - a tak si je, v duchu koncepce TCP/IP, musela zajistit sama. Ale když už tak udělala, učinila tak způsobem, který je využitelný i jinými aplikacemi, tak aby tyto již nemusely znovu "vynalézat kolo" a znovu si vyvíjet vlastní prezentační a relační funkce. Autoři NFS totiž navrhli vše tak, že samotný protokol NFS je "čistě aplikační", a má " k ruce" dva další samostatné protokoly, které pro něj zajišťují prezentační a relační funkce. Konkrétně jde o protokoly XDR (eXternal Data Representation), a RPC (Remote Procedure Call). Tyto protokoly jsou koncipovány tak, aby mohly být řešeny jako knihovní moduly, které si ostatní aplikace přilinkují, pokud je chtějí využívat - ale pokud je využívat nechtějí, nenesou režii spojenou s jejich existencí (v podobě samostatné vrstvy). Celý efekt naznačuje následující obrázek č. 6: vůči těm protokolům, které protokoly XDR a RPC využívají, se tyto chovají obdobně jako samostatné vrstvy. Ovšem ostatní aplikace jimi neprochází, a tím ani nenesou režii, která by s tím byla spojena.

Představa protokolů XDR a RPC v TCP/IP

Aplikace: v aplikační vrstvě?

Původní představa autorů Referenčního modelu ISO/OSI možná byla taková, že aplikační vrstva bude sloužit k tomu, aby v ní byly provozovány jednotlivé aplikace. Na první pohled to vypadá velmi logicky, ale přináší to jeden zásadní problém: pokud by tomu tak bylo, pak by i všechny aplikace musely být standardizovány, a tudíž všechny podřízeny stejným pravidlům, které by definovaly nejen jejich činnost, ale i vše co s tím souvisí. Ale to by nebylo dobře. Proč? I aplikace určitě musí respektovat určité konvence, a musí se jim důsledně přizpůsobovat. Třeba aplikace, které se účastní práce s elektronickou poštou, musí dodržovat formátování jednotlivých zpráv, musí používat stejně koncipované adresy, stejné mechanismy přenosu zpráv atd. Ale proč by současně měly nabízet jednotné (rozuměj: úplně stejné) uživatelské rozhraní? Proč by měly svým uživatelům vnucovat vždy přesně stejný (standardizovaný) repertoár funkcí? V čem by se pak lišily? Nebo jinak, z opačného pohledu: má smysl standardizovat vzhled uživatelského rozhraní, a předepisovat autorům poštovních klientů, jak mají jejich produkty vypadat? Jaká mají používat okénka, jaké barvy, písma, repertoáry funkcí atd.? Určitě ne.

Takže původní představa, o tom že v aplikační vrstvě budou "umístěny" celé aplikace, vzala brzy za své. Místo toho došlo k jakémusi "roztržení" aplikací na dvě části: na část, které musí být standardizována, proto aby si rozuměla s dalšími aplikacemi, resp. instancemi stejné aplikace (např. s poštovními servery atd.) na část, kterou nemá smysl standardizovat (typicky jde o uživatelské rozhraní aplikace).

Představa vztahu aplikací a aplikační vrstvy

Jak také naznačuje následující obrázek č. 7, v aplikační vrstvě nakonec zůstala jen první z obou výše uvedených částí, zatímco ta druhá již byla "vytlačena" nad aplikační vrstvu, a tím i z dosahu standardizace a jakéhokoli "sešňerovávání". Díky tomu si dnes může každý vybrat například takového poštovního klienta, jaký vyhovuje jeho potřebám - s maximálním komfortem nebo naopak jednoduchého, s grafickým uživatelským rozhraním nebo v řádkovém režimu atd.

Minulý díl tohoto seriálu jsme zakončili konstatováním, že aplikační vrstva není tím místem, kde jsou provozovány celé aplikace. Ve skutečnosti je tomu tak, že v aplikační vrstvě "běhá" jen část aplikací, zatímco zbývající části aplikací byly "vysunuty nad" aplikační vrstvu. Důvod je velmi prozaický: pokud by v aplikační vrstvě byly provozovány celé aplikace, musely by se také celé podřídit jednotným standardům. Tudíž by mohly nabízet jen standardizované (rozuměj: stejné) uživatelské rozhraní, standardizované (tj. stejné) repertoáry funkcí a schopností, standardizované (stejné) ovládání atd. Pak by ale nemělo smysl vytvářet různé verze aplikací (například různé emailové klienty), od různých výrobců a producentů, protože všechny by vypadaly stejně, chovaly by se stejně, stejně by se ovládaly atd. Vlastně by byly úplně stejné.

Rozumným řešením je rozdělit aplikace tak, aby v aplikační vrstvě zůstalo právě a pouze to, co musí být standardizováno a sjednoceno. Tedy například ta část poštovního programu, která zajišťuje vlastní přenos zpráv, a dbá na to, aby jí ostatní části poštovního systému rozuměly, aby používala jednotný formát emailových zpráv atd.

Naopak uživatelské rozhraní a nejrůznější uživatelsky orientované funkce (například pro čtení a psaní samotných zpráv) se již mohou pro různé aplikace lišit.

Obr. 1: Představa vztahu aplikací a aplikační vrstvy

Aplikace a aplikační protokoly

Rozdělení aplikací na dvě části a standardizace těch částí, které zůstaly v aplikační vrstvě, ještě nestačí k tomu, aby aplikace fungovaly skutečně tak jak mají. Například půjde-li o již zmiňovanou elektronickou poštu, musí být nějak vyřešeno předávání zpráv mezi jednotlivými uzly, které se na fungování celého "elektronického poštovního systému" podílejí. Takové předávání zpráv bude řízeno vhodným protokolem, který bude na přenos zpráv specializován.

Obr. 2: Představa aplikačních protokolů

Obecně se takovéto protokoly označují přívlastkem "aplikační", protože fungují v rámci aplikační vrstvy a slouží potřebám aplikací. Konkrétně se pak hovoří například o aplikačním protokolu pro přenos elektronické pošty (kterým je v TCP/IP protokol SMTP, Simple Mail Transfer Protocol), o aplikačním protokolu pro přenos WWW stránek (kterým je v TCP/IP protokol HTTP) atd.

Architektura aplikací a výpočetní model

S aplikačními protokoly úzce souvisí také architektura samotných aplikací. To je opět na delší povídání, které nás čeká v příštím dílu tohoto seriálu, kdy se budeme bavit o tzv. výpočetním modelu. Zde si pouze naznačme, že v prostředí počítačových sítí (a také celosvětového Internetu) je dnes nejčastějším výpočetním modelem model klient/server. Jeho podstatou není nic jiného, než že úkoly, které mají být splněny v rámci nějaké služby, například v rámci elektronické pošty či World-Wide Webu, se rozdělí mezi dvě aplikace - jednu, která plní roli serveru, a druhou, která plní roli klienta. Proto také označení celého tohoto řešení (tzv. výpočetního modelu) termínem "klient/server".

Obr. 3: Představa výpočetního modelu klient/server

Úkolem klienta přitom je zajišťovat styk s uživatelem. Tedy zejména zobrazovat mu požadované výstupy, a přijímat od něj jeho požadavky (vstupy, obvykle zadávané z klávesnice, myši atd.). Úkolem serveru pak je zajišťovat vlastní zpracování, které je v rámci služby zapotřebí, a to až na výzvy klienta (resp. jeho uživatele). Asi nejnázornější je to na

příkladu služby WWW: její server je tím, kdo u sebe uchovává jednotlivé WWW stránky. Sám je ale nikomu nevnucuje. Pouze pasivně čeká, až si některý WWW klient (označovaný také jako browser, či prohlížeč) o nějakou WWW stránku řekne. Pak mu ji server poskytne - a je už na klientovi, aby tuto stránku korektně zobrazil svému uživateli. Když ten si pak vyžádá nějakou jinou WWW stránku (ať již explicitním zadáním její adresy či kliknutím na hypertextový odkaz v právě zobrazované stránce), WWW klient pošle WWW serveru nový požadavek - a vše se opakuje.

Obr. 4: Představa modelu klient/server v rámci služby WWW

Ovšem aby si server a klient správně rozuměli a dokázali spolu spolupracovat tak jak je třeba, musí mezi nimi existovat dvě konvence: konvence o tom, jak budou vzájemně komunikovat. Tuto konvenci naplňuje aplikační protokol, v konkrétním případě služby WWW jde o protokol HTTP (Hypertext Transfer Protocol) konvence o tom, jak budou formátovány a jaký význam budou mít data, která si klient a server vzájemně předávají. V případě WWW jde hlavně o formát WWW stránek, které server zasílá klientovi - ty jsou kódovány v jazyku HTML (HyperText Markup Language). Klient mu musí rozumět natolik, aby podle něj dokázal vytvořit grafickou podobu příslušné WWW stránku (provést tzv. rendering, neboli jakousi "vizualizaci" WWW stránky).

Elektronická pošta jako aplikace

Ukažme si vše ještě na jednom příkladu, a to pro elektronickou poštu (v Internetu). Ta je službou, na jejíž realizaci se podílí poštovní servery (mail servery), zajišťující přenos jednotlivých zpráv, a dále poštovní klienti, kteří uživatelům zprostředkovávají čtení i psaní zpráv. Pro svou vzájemnou komunikaci přitom poštovní servery a poštovní klienti mají k dispozici více aplikačních protokolů. Nejčastější je dnes asi stále řešení, kdy se pro odesílání zpráv (od poštovního klienta k poštovnímu serveru) a pro přenos zpráv (mezi poštovními servery) používá protokol SMTP (Simple Mail Transfer Protocol), a pro stahování zpráv (z poštovních schránek, umístěných na poštovním serveru, do poštovního klienta) se používá protokol POP3. Proč tomu tak je, a proč zde nestačí jen jediný protokol (SMTP), či kde a jak se používají další "poštovní" aplikační protokoly jako je IMAP, si povíme později, v dalších pokračováních tohoto seriálu, až se dostaneme konkrétněji k fungování elektronické pošty jako takové.

Obr. 5: Představa modelu klient/server v rámci elektronické pošty

Teď jen sumarizující obrázek (č. 5), naznačující představu serverů a klientů v rámci celého systému elektronické pošty, a také jedno malé upřesnění: World Wide Web i elektronická pošta jsou službami, a jako takové jsou realizovány (implementovány) konkrétními aplikacemi, s využitím konkrétních aplikačních protokolů atd. V případě WWW existuje jen jeden způsob implementace této služby (ten, který jistě dobře znáte z Internetu, s protokolem HTTP, jazykem HTML atd.).

Ovšem u elektronické pošty je to jinak. Ta je službou, která může být (a je) implementována více různými způsoby, s využitím různých aplikačních protokolů a dalších standardů, na různých platformách atd. Vlastně je možné hovořit o celých ucelených "systémech elektronické pošty", které se shodují v základním účelu (možnosti elektronické poštovní korespondence), ale už se mohou i významně lišit v tom, jak konkrétně to dělají. Ten systém elektronické pošty, který jsme si až dosud popisovali a který se používá v Internetu, je dnes sice dominující, ale není zdaleka jediný. Pokud je třeba jej odlišit od ostatních systémů elektronické pošty, označuje se neformálně jako "SMTP pošta" (kvůli aplikačnímu protokolu SMTP pro přenos zpráv).

Alternativou k SMTP poště, pocházející ze světa ISO/OSI, měl být systém X.400. Moc se ale neujal, i když byl doveden až do stádia veřejně nabízené služby, fungující na komerčním základě. Připomeňme si, že v roce 1995 začal takovouto službu na bázi X.400 nabízet i v ČR Český Telecom, pod názvem CZ.MAIL. Inzeroval ji například pomocí celostránkových inzerátů v celostátních denících, ale i přesto s ní vůbec neuspěl. Nejspíše i proto, že v jeho podání šlo o službu zpoplatněnou: například první 2 KB zprávy, přenášené po Evropě, měly stát 8,40 Kč, a každé další dva kilobity již "jen" 4,80 Kč.

Obr. 6: Veřejná elektronická pošta CZ.MAIL, na bázi X.400 (ze světa ISO/OSI)

Prvotní aplikace pro Internet

Od alternativ k SMTP poště jsme se dostali k tomu, že "není aplikace jako aplikace", a že jedna a ta samá služba (jako například právě elektronická pošta) může být v různém prostředí implementována různě, pomocí různých aplikací, s různými aplikačními protokoly atd. Vraťme se ale k Internetu, který nás ze všech takovýchto prostředí zajímá určitě nejvíce, a řekněme si, jak to bylo s "jeho" aplikacemi, resp. službami. Když se dnešní Internet teprve rodil (přesněji když vznikaly protokoly TCP/IP), počítali jeho autoři se třemi "základními" službami: elektronickou poštou přenosem souborů vzdáleným přihlašováním

Pro zajištění těchto služeb vymysleli tři odpovídající aplikační protokoly, a do protokolů TCP/IP zabudovali vše potřebné, co s tím souvisí. Například pro elektronickou poštu vytvořili celý koncept "SMTP pošty", jehož součástí není jen aplikační protokol SMTP pro přenos zpráv, zmiňovaný výše, ale také další součásti - zejména standard (RFC 822), definující formát poštovních zpráv, formát a význam poštovních adres a další věci.

Přenos souborů

Pro přenos souborů vznikl ve stejné době protokol FTP (což je zkratka od: File Transfer Protocol), umožňující přenášet celé soubory mezi jednotlivými uzly v rámci sítě. Opět ale jde o službu, zajišťovanou pomocí aplikací fungujících v modelu klient/server. Aplikace v roli FTP serveru je "tím, kdo má soubory", zatímco klient je "tím, kdo chce soubory". FTP server běží na nějakém uzlu (z pohledu uživatele celé služby jde o vzdálený uzel), a nabízí ke stažení všechny nebo některé soubory, nacházející se na tomto (vzdáleném) počítači. Stejně tak může nabízet nahrání (uchování, uložení) dalších souborů na uzel, na kterém běží. FTP klient pak běží na uzlu, na kterém pracuje uživatel, a skrze tohoto klienta si stahuje soubory ze (vzdáleného) FTP serveru, nebo naopak nahrává (tzv. uploaduje) své soubory na (vzdálený) FTP server. Lze si to představit také tak, že FTP server vytváří jakési "okno", skrze které jsou "vidět" soubory, umístěné na vzdáleném počítači, a tyto jsou dostupné pro čtení a zápis. Naznačuje to i obrázek č. 7

Obr. 7: Představa přenosu souborů prostřednictvím FTP

Vzdálené přihlašování

Pokud jde o vzdálené přihlašování, to je služba motivovaná zejména potřebou využívat na dálku výpočetní kapacitu a další zdroje vzdálených uzlů. Třeba k tomu, aby správce sítě mohl provést na dálku nějaké úkony (například nějaké změny nastavení) na vzdáleném počítači, a to přímo ze svého počítače, aniž by se musel fyzicky přemisťovat ke vzdálenému počítači. Také běžný uživatel si může skrze vzdálené přihlašování spustit aplikace na vzdáleném počítači, a používat je "na dálku". Je to možné díky tomu, mezi jeho počítačem a vzdáleným počítačem vzniká tzv. vzdálená terminálová relace (jako alternativa k "lokální" terminálové relaci). Její podstatou je přesměrování výstupů (a také vstupů) příslušné aplikace, běžící na vzdáleném uzlu. Místo toho,

aby tato aplikace zobrazovala své výstupu na "místním" monitoru (resp. terminálu), jako u lokální terminálové relace, posílá je po síti na jiný uzel (kde se nachází uživatel), a teprve zde se tyto výstupy zobrazují.

Obdobně se vstupy, které generuje uživatel - generuje je (mačkáním kláves na své klávesnici) tam, kde se nachází, a tyto vstupy jsou po síti zasílání až ke vzdálenému uzlu, kde běží příslušná aplikace, a jsou jí předávány.

Obr. 8: Představa lokální a vzdálené terminálové relace

Způsob, jakým je služba vzdáleného přihlašování realizována v prostředí TCP/IP, ukazuje následující obrázek č. 9. Opět jde o řešení na bázi modelu klient/server, s tím že komunikaci mezi klientem a serverem zajišťuje protokol Telnet. Podle něj se také hovoří o Telnet serveru a Telnet klientovi.

Telnet server "sedí" na vzdáleném uzlu, a má za úkol přesměrovávat výstupy zdejších aplikací na jiné uzly (kde běží Telnet klient). Úkolem Telnet klienta je naopak takovéto výstupy zobrazovat uživateli na jeho displeji. Ten dříve patřil skutečnému terminálu, a proto se také hovořilo o "terminálových relacích". Dnes již uživatelé pracují téměř výlučně s běžnými univerzálními počítači, které funkce a chování jednoúčelového terminálu pouze předstírají (tzv. emulují), pomocí softwarových prostředků. Tuto roli, resp. úkol (tj. softwarovou emulaci terminálu) také plní Telnet klient. Kromě toho samozřejmě musí "sbírat" vstupy od svého uživatele (z klávesnice, případně i od myši), a tyto zase zasílat opačným směrem, k Telnet serveru. Úkolem Telnet serveru je pak "podstrčit" tyto vstupy místní aplikaci, tak aby si myslela, že pochází od nějakého místního uživatele, a vzala je na vědomí a vykonala to, co požadují.

Obr. 9: Představa realizace vzdálených terminálových relací v TCP/IP (protokol Telnet)

Další vývoj v TCP/IP

Další vývoj aplikací a služeb v rámci TCP/IP (a Internetu), po vzniku "prvotní trojice", se ubíral dvěma hlavními směry: obohacováním již existujících aplikací o další možnosti a schopnosti vznikem nových aplikací, realizujících nové služby

Pro první variantu (obohacování již existujících aplikací) je podstatné, že se tak dělo inkrementálním způsobem, a nikoli formou "zahoď stávající a přejdi na nové". Jinými slovy: nové možnosti a schopnosti se postupně přidávaly jako přírůstky k již existujícímu řešení, resp. jako vylepšení toho, co již existuje a používá se, a nikoli cestou vývoje zcela nového řešení, které by nahradilo to dosavadní.

Asi nejlépe bude si vše přiblížit na konkrétním příkladu. Zde se přímo nabízí již zmiňovaná elektronická pošta (SMTP pošta), která původně vznikla jako jednoduchá služba pro přenos krátkých textových zpráv (nezaměňovat s SMS). Nebyla stavěna na přenos rozsáhlých textů, ani na texty v národních abecedách neanglických mluvících uživatelů (u nás: na přenos textů s háčky a čárkami). Počítala pouze s přenosem čistých ASCII znaků, a nedovolovala ani žádné "přikrášlování" textu zpráv, pomocí různých druhů písma, barviček či jiného formátování. Stejně tak neumožňovala ani přikládání příloh (ve formě souborů) ke zprávám.

I tak si ale lidé elektronickou poštu velmi oblíbili, používali ji v čím dál tím větším měřítku - a požadovali její další obohacení, zejména o již zmiňované možnosti formátování textů a přílohy. No a tak odborníci zasedli a vymysleli způsob, jak původní SMTP poštu obohatit tak, aby požadované věci zvládala. Navíc tak, aby to skutečně byl "přírůstek", resp. rozšíření, v tom smyslu že nebude třeba měnit základní způsob fungování celé SMTP pošty, a jen se "něco přidá". Důležitý byl také způsob takovéhoto přidání, založený na principu "když něčemu nerozumíš, tak se tím nezatěžuj a pokračuj dál". Takže když se například rozšířily možnosti formátování zprávy o různé druhy písma, barvy atd., ale "obohacená" zpráva přišla uživateli s poštovním klientem který takovéto rozšíření dosud nepodporuje, neměl by "starý" klient apriorně odmítat s takovou "novou" zprávou pracovat. Místo toho by měl udělat vše proto, aby ji alespoň nějak zpřístupnil svému uživateli. V daném případě tedy zobrazil bez barviček a nestandardních druhů pásma - ale stále v čitelné podobě.

Konkrétní rozšíření systému SMTP pošty, které v tomto duchu vzniklo, se jmenuje MIME (což je zkratka od: Multimedia Internet Mail Extensions).

Nové aplikace

Druhý směr dalšího vývoje, tedy vznik zcela nových služeb a aplikací, pochopitelně již nemůže být inkrementální. I zde ale existuje několik zajímavých momentů, na které je vhodné poukázat. Jde vlastně o určité trendy, které se postupně prosadily.

První z takovýchto trendů se týká způsobu, jakým aplikace vznikají. Původně je vymýšleli lidé z akademické sféry, v rámci orgánu IETF (Internet Engineering Task Force), který také připravuje (po věcné stránce) příslušné standardy. Poměrně brzy se to ale změnilo, a nové protokoly (nejen ty aplikační) začala vymýšlet spíše komerční sféra. Tedy jednotlivé firmy, které investovaly do jejich vývoje, a vytvářely příslušná řešení nejdříve jako svá vlastní (firemní, tzv. proprietární) řešení. S rozvojem Internetu a s růstem jeho popularity ale tyto firmy seznaly, že se jim vyplatí spíše něco jiného - ne držet si tato řešení jako svá vlastní (proprietární) a tím i uzavřená, ale naopak otevřít je a prosadit jako veřejný standard. A tak svá řešení začaly firmy předkládat standardizačním orgánům Internetu (hlavně IETF), a různě lobovat za jejich prosazení.

Prvním aplikačním protokolem, který se takto prosadil, byl protokol NFS (Network File System) pro transparentní sdílení souborů, vyvinutý společností Sun Microsystems (také k němu se v dalších dílech tohoto seriálu dostaneme podrobněji). Dnes takto, tj. v komerční sféře, vznikají prakticky všechny nové věci v rámci TCP/IP a Internetu.

Nejprve diversifikace, pak unifikace

Dalším zajímavým trendem, který se týká vývoje aplikací a služeb, je trend k diversifikaci, neboli ke vniku většího počtu různých a samostatných služeb, resp. aplikací které je implementují. S postupem času se to ale ukázalo jako nepříliš šikovné, a tento trend se obrátil - směrem k unifikaci, přesněji ke snižování počtu samostatných aplikací. Ale nepředbíhejme a vezměme to popořadě.

Zpočátku, v "době diversifikace", lidé vymýšleli nové služby pro kdejaký, často i dosti specifický účel. Například pro vyhledávání souborů v FTP archivech. Nebo samostatnou službu pro vyhledávání osob v adresářích. Nebo pro nabídku toho, co je kde dostupné (jaké soubory, například textové, s obrázky apod.). Ke všem těmto nově koncipovaným službám pak lidé vymýšleli příslušné aplikace, standardizovali příslušné aplikační protokoly, definovali formáty dat a další náležitosti. Takto vznikly například služby jako Archie (pro hledání souborů v FTP archivech), WAIS (pro plnotextové vyhledávání v textových dokumentech), Whois (pro hledání osob v adresářích), Gopher (pro sestavování nabídek toho, co se kde nachází), a také World Wide Web.

Služba WAIS

Některé z těchto služeb uspěly, a známe je a běžně používáme ještě dnes. Příkladem může být stále populárnější služba WWW. Jenže kdo si dne vzpomene, že třeba takový Gopher vznikl zhruba ve stejné době jako WWW, možná o něco dříve, měl v zásadě stejný cíl jako WWW - ale neujal se, v souboji s WWW prohrál na celé čáře, a dnes již patří spíše do učebnic internetové historie? Důvod, proč se tak stalo, je docela zajímavý: nebyl zdaleka tak "sexy", jako World Wide Web. Nenabízel tolik uživatelsky atraktivních možností, jako WWW. Byl strohý, málo barevný a málo grafický, byť na druhé straně byl podstatně efektivnější a méně náročný na nejrůznější zdroje. Ale lidé zkrátka dali přednost hezčímu obalu.

Služba WAIS

To důvod, proč zmizely ze scény ostatní služby a aplikace - jako například Archie, WAIS a další - byl úplně jiný. Tyto "hodně specializované" služby byly relativně náročné na znalosti a schopnosti svých uživatelů, kteří si museli instalovat na své počítače specializované klienty (klientské aplikace) pro tyto služby, museli se je učit ovládat, starat se o ně atd.). Časem ale stejnou funkčnost, navíc v podstatně jednodušším a "jednotném" provedení, dokázaly nabídnout jiné služby, zejména World Wide Web.

Dnes již se třeba hledání čehokoli neřeší přes samostatné a specializované služby, s vlastními aplikacemi, klienty a hlavně postupy, ale přes jednotné vyhledávací služby, jaké nabízí například Google (ale i mnohé další), a které fungují jako nadstavba nad službou WWW. Chcete-li je používat, nepotřebujete žádného speciálního klienta, a nemusíte se učit žádné jeho specifické ovládání. Jen ve svém browseru zadáte příslušnou URL adresu, do

jednoduchého formuláře napíšete co chcete - a pak už je to jen o vaší vlastní šikovnosti a schopnosti zadat vyhledávací dotaz tak, abyste se dobrali kýženého výsledku.

V minulém dílu tohoto seriálu jsme si povídali o aplikační vrstvě a aplikacích, fungujících v prostředí počítačových sítí. Přitom jsme si již dopředu naznačili, že takovéto "síťové aplikace" dnes většinou vychází z modelu, označovaného jako klient/server. Jeho podstatou je rozdělení aplikace na dvě části - klienta a server - s tím že klient zajišťuje komunikaci s uživatelem, zatímco server vykonává "ostatní" funkce, potřebné pro vlastní běh aplikace. A také že obě složky (klient i server) mohou být vzdáleny od sebe a běžet na různých počítačích, vhodně propojených pomocí (jakékoli vhodné) počítačové sítě.

Jak ale již tušíte z perexu dnešního dílu, není to zdaleka jediná možnost toho, jak mohou aplikace fungovat, jak mají být řešeny (např. zda mají být rozděleny na několik částí či nikoli), kde mají mít svá data (a kde je mají zpracovávat), jak mají komunikovat s uživatelem atd. Obecně lze v této souvislosti hovořit o architektuře aplikací, ale zde se přidržíme přeci jen častějšího termínu "výpočetní model". Hlavně se ale seznámíme i s dalšími výpočetními modely, než je model klient/server.

Na počátku bylo dávkové zpracování

Výpočetní modely se samozřejmě s časem vyvíjí, a tento jejich vývoj je z jedné strany "tlačen" požadavky uživatelů, a z druhé strany je "usměrňován" možnostmi technologií, jak softwarových, tak i hardwarových. Historicky první výpočetní modely proto musely být relativně jednoduché a odrážet velmi skromné možnosti prvních počítačů. Zřejmě nejstarším výpočetním modelem je tzv. dávkové zpracování (anglicky: batch processing). To vzniklo v době, kdy počítače byly řízeny děrnými štítky či děrnými páskami, a ještě neměly žádné uživatelské terminály (coby pracoviště pro jednotlivé uživatele). Absence takovýchto terminálů pak nutně znamenala, že uživatelé nemohli být v přímém kontaktu se svými programy - nemohli jim zadávat žádné pokyny skrze klávesnici, myš apod., a také samotné programy nemohly svým uživatelům zobrazovat žádné výstupy (přes obrazovku). Takže třeba editace textů na počítači nebyla z principu možná, a žádné textové editory neexistovaly. Obecně tedy neexistovala možnost interakce, resp. tzv. interaktivita (mezi uživateli a jejich programy). No a tomu se samozřejmě musel přizpůsobit i tehdejší výpočetní model, tj. dávkové zpracování. To je dodnes antonymem (opakem) k interaktivitě.

Dávkové zpracování, které nemá k dispozici interaktivitu, nutí uživatele k tomu, aby všechny své požadavky na zpracování počítačem připravil a přesně vyspecifikoval dopředu. Tedy aby přesně a jasně popsal, který program má být spuštěn, s jakými vstupními daty má pracovat, kam mají být ukládána výstupní data, generovaná tímto programem, a případně jak se má pokračovat (v případě korektního zakončení programu či v případě chyby). Pokud tak uživatel učiní, a k popisu svých požadavků přidá samotný program i všechna vstupní data, vzniká tím tzv. dávka (anglicky: batch). Tu si lze představit jako určitý celek, který pak může být počítačem proveden (zpracován) v zásadě kdykoli, podle toho, "kdy má čas počítač" (a nikoli podle toho, "kdy má čas uživatel"). Jednotlivé dávky, od stejného uživatele i od dalších uživatelů, se obvykle řadily do front, kde čekaly, až na ně dojde řada a budou zpracovány.

Uživatel mezitím čekal, třeba i několik hodin, nebo dokonce dnů, než se dočkal nějakého výsledku zpracování své dávky.

Představa dávky a dávkového zpracování

Dávkové zpracování stále žije

Ačkoli dávkové zpracování vzniklo v určité historické době a reagovalo na tehdejší stav výpočetní technicky, není ještě zdaleka mrtvé. I dnešní operační systémy podporují dávky (dávkové soubory), skrze které lze dopředu připravit (naprogramovat) určité činnosti, a pak je jen ve vhodnou dobu spouštět.

Stejně tak se dnes dávkové zpracování používá třeba v souvislosti se superpočítači. Zde si uživatel (na svém osobním počítači) dopředu připraví svůj výpočet i s daty, které chce zpracovat - a pak vše "zabalí" do jedné dávky a tu pošle ke zpracování superpočítači. Už se tomu ale neříká ani tak dávkové zpracování, jako spíše Remote Job Entry (dálkové zadávání úloh), či Remote Job Execution (dálkové zpracování úloh). .

Model host/terminál

Touhu uživatelů po přímém kontaktu s jejich aplikacemi (interaktivitě) bylo možné splnit až v době, kdy se počítače začaly vybavovat vhodnými terminály, či spíše sítěmi terminálů. To proto, aby s počítačem mohlo pracovat více uživatelů. Jenže to nestačilo. Muselo se vhodně zařídit i to, aby se počítač "věnoval" všem těmto uživatelům současně. I to bylo novum oproti předchozímu dávkovému zpracování, kdy se počítač celou svou kapacitou věnoval vždy jen jedné úloze.

Řešení se nakonec našlo v technice, označované jako "sdílení času" (time sharing). Předpokládá, že počítač se vždy po určitou dobu věnuje jednomu uživateli, pak druhému, pak třetímu atd., a stále dokola. Ovšem ony "určité doby" jsou velmi krátké (např. desítky milisekund) a přepínání tak rychlé, že to jednotliví uživatelé ani nemají šanci postřehnout. Místo toho si mohou myslet, že se celý počítač věnuje právě a pouze jim.

S využitím této techniky již bylo možné vyvinout nový výpočetní model, označovaný jako host/terminál. Pozor ale na to, že slůvko "host" v jeho názvu není odvozeno od českého slova "host" (ve smyslu: být hostem u někoho), ale od anglického "host", což v češtině znamená "hostitel", resp. "být hostitelem někoho, resp. něčeho". Takže je na místě mluvit o hostitelském počítači, který je "hostitelem" pro aplikace, ale i pro data, výpočetní kapacitu a další zdroje.

A právě to je pro celý model "host/terminál" typické a charakteristické - předpokládá, že veškeré zdroje jsou umístěny "na jedné hromadě" (na hostitelském počítači, a tedy centrálně), a zde se s nimi také pracuje. K jednotlivým uživatelům, na jejich terminály, pak "putují" již jen výstupy jednotlivých aplikací, zatímco opačným směrem proudí vstupy od uživatelů, určené jejich aplikacím (hlavně vstupy z klávesnic). Pokud vám to připomíná terminálové relace, popisované v minulém dílu tohoto seriálu, v souvislosti s Telnetem, pak vězte že podobnost opravdu není náhodná.

Představa modelu host/terminál

Monolitické aplikace pro izolovaná PC

Pokrok a vývoj v oblasti hardwaru (i softwaru), který prvním počítačům postupně dopřál terminály (a model host/terminálů), se samozřejmě nezastavil, ale pokračoval dále. Nejprve se ubíral cestou zmenšování hostitelských počítačů, které původně byly opravdu velmi velké. Však se jim také říkalo "střediskové počítače", či převzatě z angličtiny "mainframy". Časem se ale zmenšily do podoby tzv. minipočítačů. Jejich fungování, na bázi modelu host/terminál, se ale nezměnilo, protože stále musely sloužit více uživatelům současně. A ti s nimi pracovali prostřednictvím terminálů.

Lidé ovšem toužili po tom, aby měli počítač jen a jen ke své dispozici, a nemuseli se o něj dělit s nikým jiným. Na to si museli ještě chvíli počkat, ale nakonec to přišlo také. Na trh se dostaly osobní počítače (počítače PC, Personal Computer), které za svůj přívlastek "osobní" vděčí právě tomu, že už mohou být přiděleny jednomu uživateli do výlučného použití. Jenže co s aplikacemi pro takovéto osobní počítače?

Střediskové počítače, minipočítače a počítače PC

Aplikace pro osobní počítače už nemusely počítat s tím, že jejich uživatelé nejsou na hostitelském počítači sami. Nemusely se tedy dělit o dostupné zdroje (výpočetní kapacitu, paměť atd.) s ostatními aplikacemi, které si provozovali ostatní uživatelé, a mohli se na osobním počítači chovat jako jeho výluční páni. Také nemusely čekat na to, ke kterému terminálu si sedne jejich uživatel, aby mu pak posílaly své výstupy právě na tento terminál. Mohly předpokládat, že jejich uživatel s nimi bude komunikovat přes jedinou klávesnici a jedinou

obrazovku, kterou je osobní počítač vybaven. Takže měly vlastně o dost snazší pozici, mohly být relativně jednodušší, a mohly být koncipovány jako monolitické (ve smyslu: "v jednom kuse", nikoli nějak dělené).

Potřeba sdílení

Monolitické aplikace, určené pro osobní počítače, dokázaly nabídnout svým uživatelům poměrně vysoký komfort. Měly ovšem také své nevýhody. Například tu, že kdykoli bylo třeba udělat do nich nějaký zásah (například nahrát nějakou aktualizaci, novou verzi, nějaké nové nastavení atd.), muselo se vše dělat na každém počítači, pro každého uživatele. Obecně tedy n-krát, zatímco dříve, na hostitelském počítači a v rámci modelu host/terminál, stačilo vše udělat jen 1-krát. Nároky na systémovou správu a údržbu tedy obecně vzrostly n-krát, což se s postupem času ukázalo jako zásadní problém. Zejména ve firemním prostředí tím výrazně stouply náklady na podporu uživatelů (v rámci tzv. TCO, Total Cost of Ownership), a vynutily si určitý návrat k centralizovaným výpočetním modelům.

Tedy k takovým, kde jsou aplikace více soustředěny na nějakém centrálním místě.

Aplikace, běžící na vzájemně izolovaných osobních počítačích, neměly mezi sebou žádnou vazbu

Samostatné a vzájemně izolované počítače však měly ještě jednu principiální nevýhodu: neumožňovaly žádné sdílení. Například když více uživatelů chtělo pracovat se stejnými daty, nešlo to - a každému bylo třeba vytvořit a přidělit jeho vlastní kopii požadovaných dat. Něco takového už nešlo udělat například s drahými periferiemi, jako třeba s laserovými tiskárnami. Dát každému k dispozici kvalitní tiskárnu bylo i v době osobních počítačů zbytečným luxusem, místo kterého obvykle nastupovalo sdílení jedné tiskárny více uživateli.

Od extrému k extrému, nebo zlatá střední cesta?

Izolované osobní počítače a jejich monolitické aplikace však nebyly připraveny na žádné sdílení svých zdrojů (včetně periferií). Samy vlastně představovaly jakýsi přeskok od jednoho extrému k extrému přesně opačnému: původní výpočetní model host/terminál totiž byl maximálně centralizovaný, kvůli tomu že všechny zdroje u něj byly soustředěny na jednom (centrálním) místě, na samotném hostitelském počítači. Takže sdílení zde bylo velmi snadné. U izolovaných osobních počítačů to ale bylo přesně naopak - všechny bylo plně distribuované, resp. decentralizované (rozdělené mezi jednotlivé uživatele, na jejich osobní počítače), a naopak nic nebylo společné. Žádné sdílení zde vlastně ani nešlo realizovat, protož nebylo jak.

Hledání zlaté střední cesty mezi dvěma extrémy (úplnou centralizací a úplnou decentralizací)

Lidé však záhy přišli na to, že ani jeden extrém není ideální, a jali se hledat zlatou střední cestu. Ta by v daném případě umožňovala sdílet to, co se hodí sdílet, a současně by umožnila přidělit každému do jeho výlučného vlastnictví a používání to, co se naopak sdílet nemusí.

Sdílet by se mohly například periferie (již zmiňované tiskárny), nebo třeba datové soubory, ke kterým chce mít přístup více uživatelů. Jenže jak to udělat, když izolované počítače nebyly mezi sebou vůbec propojeny?

Model file server/pracovní stanice

Prvním krokem k možnosti sdílení bylo vhodné propojení do té doby izolovaných osobních počítačů. K tomu naštěstí již existovala vhodná technologie, vyvinutá právě pro takovýto účel. Ano, byl to Ethernet, nabízející přenosovou rychlost 10 megabitů za sekundu. To bylo dost na to, aby se alespoň sdílení souborů dalo realizovat transparentním způsobem. Tedy tak, aby z pohledu uživatelů a jejich aplikací "nebylo vidět", a soubory, fakticky umístěné na některém jiném počítači v síti, se mohly "tvářit" a chovat stejně jako soubory lokální, umístěné na daném počítači. Včetně toho, že když s nimi chtěl uživatel (nebo jeho aplikace) pracovat, netrvalo to o nic déle, než u skutečně lokálních souborů.

Představa modelu file server / pracovní stanice

Jenže pro takovéto plně transparentní sdílení souborů, umístěných na jiném počítači, bylo třeba vymyslet také vhodné technické řešení. Takové, které by dovolilo umístit soubory na jedno centrální místo - na počítač, fungující jako tzv. file server, resp. souborový server - ale současně umožnilo ostatním počítačům v síti "vidět je" jako své vlastní soubory. Lze si to představit také tak, že systém souborů file serveru se "promítá" (tzv. mapuje) do systému souborů jiného počítače (tzv. pracovní stanice). Jde skutečně jen o iluzi, která ale naplňuje ušlechtilé cíle: díky ní mohou na pracovní stanici (osobním počítači) běžet monolitické aplikace, které vůbec nepočítají s existencí sítě a nějakých vzdálených počítačů (file serverů). Přesto dokáží pracovat s datovými soubory, které jsou ve skutečnosti umístěné na jiném uzlu sítě (ale vůči nim se tváří jako místní).

A dokonce: i tyto samotné aplikace, které o existenci sítě nic netuší, mohou být jako soubory umístěné centrálně, na file serveru, ale "promítat" se do souborového systému pracovní stanice (osobního počítače), a zde být jako aplikace spouštěny a provozovány. Tento jednoduchý trik pak značně zjednodušuje systémovou správu a údržbu těchto aplikací, protože tu lze realizovat na jednom centrálním místě (na file serveru, kde jsou aplikace uloženy jako soubory), místo na každém jednotlivém počítači. Dodnes se stejné řešení, zde popisované jako "model file server/pracovní stanice", v praxi hojně používá, byť třeba pod úplně jinými jmény. Často se například mluví jen o tzv. síťových discích (vzdálených discích apod.), které plní roli file serveru. Má to i svou logiku: zde popisovaný "model file server / pracovní stanice" vlastně není ani žádným výpočetním modelem. Je zcela záměrně "neviditelný", právě proto aby se mu aplikace nemusely přizpůsobovat. Díky tomu bylo možné hned od začátku používat v prostředí sítě i takové aplikace, které o ní vůbec netušily a myslely si, že pracují na samostatném a izolovaném osobním počítači (který mají navíc samy pro sebe).

Model klient/server

Model file server/pracovní stanice, popisovaný v předchozím odstavci, tedy umožnil používat v prostředí sítě i takové aplikace, které na to nebyly stavěny. Nebylo to ale zadarmo. Každá taková aplikace, která o existenci sítě netušila, a byla (jako soubor) umístěna na centrálním file serveru, musela být při svém spuštění nejprve celá přenesena z file serveru na pracovní stanici. Staral se o to systémový software, zajišťující potřebné "mapování" systémů souborů (aniž si to uživatel a jeho aplikace uvědomovali). Obdobně pro datové soubory, se kterými taková aplikace pracovala - také ty se musely přenášet sem a tam, což mohlo výrazně zatěžovat celou lokální síť jako takovou. Jenže to rozhodně nebylo zadarmo. Byla s tím spojena nemalá režie.

Zdrojem této režie zde byla skutečnost, že data se zpracovávala jinde, než kde byla umístěna. Pro docenění celého problému si jej můžeme ukázat na následujícím příkladu, v záměrně zveličené podobě: představme si databázi velikost například 10 MB, která má být prohledána, zda se v ní nenachází nějaká konkrétní data. Je úplně jedno jaká, ale podstatné je, že výsledkem je jednobitová informace: ano, nebo ne. Pokud je ale takováto databáze umístěna (jako soubor) na file serveru, ale díky modelu file server/pracovní stanice bude prohledávána na pracovní stanici, musí být před samotným prohledáním nejprve celá přenesena (z file serveru na pracovní stanici). Přeneseno musí být obecně všech 10 MB dat, které tuto databázi tvoří.

Teď si ale představme jiný scénář: databáze se prohledá tam, kde se nachází (na centrálním file serveru), a po síti se na pracovní stanici přenese jen jednobitový výsledek celého prohledání. Úspora přenosové kapacity je jasná a obrovská.

Jenže abychom mohli takovýto scénář realizovat, musíte nejprve přinutit tu aplikaci, která databázi prohledává, aby se "přestěhovala" z pracovní stanice přímo na centrální file server. Jenže pak zase nebude moci komunikovat s uživatelem. Takže jinak: rozdělíme aplikaci napůl, a jedna její část (zajišťující komunikaci s klientem) zůstane na pracovní stanici, zatímco druhá část (ta, která bude skutečně prohledávat databázi), se přestěhuje tam, kde se databáze nachází, tedy na centrální server.

Ale to už jsme dospěli k výpočetnímu modelu klient/server, s kterým jsme se seznámili v minulém dílu tohoto seriálu.

Představa rozdělení původně monolitické aplikace na dvě části (v rámci modelu klient/server)

Zopakujme si tedy, že jde o výpočetní model, který již programové počítá s existencí sítě, resp. distribuovaného prostředí, a původně monolitickou aplikaci rozděluje na dvě části: klientskou a serverovou. Pomyslný "řez", který obě části oddělí, se snaží vést tak, aby komunikace mezi klientem a serverem byla co nejméně obsáhlá, tj. aby představovala co nejmenší objemy dat (kvůli zátěži přenosové sítě mezi klientem a serverem).

Server pak zajišťuje potřebné zpracování, které ale provádí vždy až na žádost ze strany klienta. Klient zase zajišťuje veškerou komunikaci s uživatelem - přijímá od něj pokyny, a naopak mu zobrazuje (prezentuje) výsledky zpracování, které zajistil server.

3-úrovňový klient/server

Model klient/server je v současné době zřejmě nejrozšířenější výpočetní model, hojně používaný v běžné praxi. To ale zdaleka neznamená, že by neměl žádné nedostatky a nevýhody, a že by od něj neexistovaly "lepší" verze.

Jednou z nevýhod modelu klient/server je to, že i jeho klientská část je "aplikačně závislá", tj. specifická pro danou aplikaci. To na první pohled nevypadá jako nějaká nevýhoda - ale zkusme si představit, že v reálném provozu uživatelé používají několik aplikací, a od každé z nich musí mít na svém počítači nainstalovaného příslušného klienta. A co navíc: o každého takového klienta se musí někdo starat (správce systému). Komplikované to ale je i pro samotného uživatele, protože i on se musí učit pracovat s několika různými klienty, kteří mohou mít různé způsoby a styly ovládání, úplně jinou logiku atd. Nebylo by tedy lepší, kdyby existoval jeden univerzální klient, který by byl využitelný pro více různých aplikací?

Myšlenka jednoho univerzálního klienta naštěstí není utopií, jak by se na první pohled mohlo zdát. Dokonce v praxi již existuje a používá se. Vyžaduje ale, aby se příslušná aplikace rozdělila nikoli na dvě části, jako u klasického modelu klient/server, ale hned na tři části. Proto se také mluví o "3-úrovňovém modelu klient/server". Jaké tři části to ale mají být?

Možnosti využít jediného univerzálního klienta se dosahuje tím, že se vyčlení (do samostatné části) vše, co je pro danou aplikaci specifické a unikátní. Tím vznikne "prostřední" část, které se ne nadarmo říká aplikační logika. Vedle ní se pak již dají použít dvě univerzální části:databázový server, který především uchovává aplikační data, a dokáže v nich vyhledávat (v praxi jde obvykle o běžný SQL server) prezentační část, která zajišťuje potřebnou "prezentaci" (zobrazování výsledků uživateli, a získávání vstupů od uživatele).

Představa 3-úrovňového modelu klient/server

V praxi plní roli prezentační části nejčastěji běžný WWW prohlížeč (browser). Aplikační logika je pak "schována" za příslušným WWW serverem, a "z druhé strany" je na ni napojen databázový server. V roli praktického příkladu si představme třeba vyhledávání v jízdním řádu: všechny údaje o existujících spojeních jsou uloženy v databázovém serveru (SQL serveru), který v nich dokáže standardním způsobem vyhledávat (pomocí SQL příkazů). Nerozumí ale tomu, co jednotlivé údaje v databázi znamenají, jak spolu souvisí, jak na sebe jednotlivé spoje navazují atd. Všechny takovéto informace, specifické pro aplikaci spočívající ve vyhledávání spojení, jsou soustředěny v aplikační logice. Ta z jedné strany "rozumí" dotazům uživatelů, a "z druhé strany" rozumí datům, obsaženým v databázi. Dokáže tedy správně interpretovat dotazy uživatelů, hledat na ně odpovědi, a tyto odpovědi pak zase zpětně vracet uživatelům. Ovšem o prezentaci těchto výsledků už se stará prezentační část, "postavená" na WWW serveru a browseru. Uživatel klade své dotazy skrze webové stránky (kde zadá svůj dotaz v příslušném formuláři), a také odpovědi na své dotazy dostává v podobě webových stránek, které mu zobrazuje jeho prohlížeč.

Představa aplikace, využívající 3-úrovňový model klient/server

Nepotřebuje tedy žádného specifického klienta pro vyhledávání dopravních spojení, ale pro danou aplikaci (i další aplikace) vystačí jen s jedním klientem - běžným WWW prohlížečem. Navíc může takového univerzálního klienta použít skutečně kdekoli, po celém světě, v dosahu služby WWW. Na závěr si jen zkusme představit, jak by to dnes vypadalo, pokud by neexistoval takovýto 3-úrovňový model klient/server, a pro každé trochu specializované vyhledávání na Internetu by byl zapotřebí samostatný klient!

Problematika výpočetních modelů, kterou jsme se začali zabývat v minulém dílu tohoto seriálu, se týká toho, jak aplikace fungují, jak jsou řešeny (např. zda jsou monolitické, či zda jsou rozděleny na několik částí či nikoli), kde mají uložena svá data a kde je zpracovávají, či jak komunikují s uživatelem atd. Popisovali jsme si také historický vývoj výpočetních modelů, který vedl až ke vzniku dnes zřejmě nejrozšířenějšího modelu klient/server. Ten je přímo šit na míru distribuovaném prostředí počítačových sítí, protože předpokládá rozdělení aplikace na dvě části - serverovou (server) a klientskou (klienta) - s propojením pomocí vhodné sítě.

Na výpočetním modelu klient/server je dnes postavena i většina aplikací, resp. služeb, fungujících v prostředí Internetu. Třeba když se brouzdáte na vlnách báječného světa World Wide Webu, ani si možná neuvědomujete, že k tomu využíváte klientský program (klienta) v podobě webového prohlížeče (browseru), který si na základě našich pokynů vždy vyžádá požadovanou WWW stránku od konkrétního WWW serveru. Nebo že když čtete či píšete své emaily, používáte k tomu poštovního klienta, zatímco samotný přenos zpráv zajišťuje poštovní server.

Také jsme si ale řekli, že model klient/server má i své nevýhody. Například tu, že pro každou aplikaci, resp. službu, musí uživatel používat jiného klienta (jiný klientský program). Aby jich na svém počítači nemusel mít instalováno příliš mnoho, a s každým se nemusel učit pracovat jeho specifickým způsobem, objevilo se i vylepšení klasického modelu klient/serveru, v podobě 3-úrovňového modelu klient/server.

Naše dnešní povídání, o "alternativních" výpočetních modelech, začneme tím, že ani 3-úrovňový model klient/server není jedinou možností, jak se zbavit přehršle různých klientů na vlastním počítači.

Network Centric Computing

Poměrně radikální alternativou (k nutnosti instalovat si na počítači řadu různých klientů) je zařídit vše tak, aby na počítači nemuselo být dopředu nainstalováno vůbec nic. Tedy ani žádní klienti (klientské programy), ani jiné programy, včetně těch monolitických ("v jednom kuse", resp. nedělených na klientskou a serverovou část). Pokud by pak uživatel takového počítače chtěl něco začít dělat, například psát nějaký text, číst si své emaily či brouzdat se webem, vše potřebné by se na jeho počítač stáhlo ze sítě a zde spustilo. A po použití by se to zase zahodilo, jako nějaký papírový kapesník na jedno použití.

Představa počítače NC a modelu Network Centric Computing

Popišme si to celé ještě jednou, tentokráte z jiného pohledu. Jde o řešení, v rámci kterého jsou aplikace umístěny na vhodném serveru, který se nachází někde v síti. Teprve v okamžiku, kdy na uživatelově počítači vznikne potřeba použít nějaký takovýto program, je tento stažen ze sítě (přenesen ze síťového serveru na uživatelův počítač) a zde spuštěn. Vše naznačuje i dnešní první obrázek.

Základem všeho zde tedy je síť (s příslušnými servery), která poskytuje uživatelům vše potřebné, kdykoli si o to řeknou. Snad právě proto se také celému tomuto výpočetnímu modelu říká Network Centric Computing. Tedy něco jako "výpočetní model, jehož středem je síť". Ta je zde skutečně středem všeho, protože s ní stojí a padá možnost smysluplné práce na počítačích uživatelů. Jakmile by síť nefungovala a neposkytovala programy ke stažení a spuštění, uživatelů by jejich počítače byly k ničemu.

Jazyk Java, javovské aplety a javovský virtuální stroj

Stahování programů ze sítě samozřejmě musí probíhat dostatečně rychle, tak aby uživatel nezaznamenal žádné významnější zpoždění od okamžiku, kdy projevil své přání (že chce něco dělat), do okamžiku, kdy je příslušný program stažen ze sítě a spuštěn na jeho počítači. To samozřejmě klade velké nároky na rychlost a propustnost sítě, ze které je program stahován.

Ale není to zdaleka jediný požadavek.

Dalším nezbytným požadavkem je to, aby program, stahovaný ze sítě, vůbec byl schopen běžet na počítači, na který je stažen. A to nemusí být pokaždé stejný počítač! Takže by to měl být nějaký takový tvar programu, který je spustitelný a schopný plnohodnotné práce na různých platformách, na kterých může být uživatelům počítač postaven (tedy třeba na MS Windows, na Unixu, Linuxu, na MacOS atd.).

Takovýmto tvarem programu jsou například aplety jazyka Java, což jsou jakési předkompilované (před-přeložené) programy, uzpůsobené k tomu, aby mohly běžet na různých platformách, včetně různých procesorů a operačních systémů. Vždy ale za podmínky, že na příslušné platformě najdou stejné "domovské prostředí", které pro ně představuje tzv. javovský virtuální stroj (JVM, Java Virtual Machine).

Ten si můžeme představit jako jakýsi "virtuální počítač v počítači". Představa javovského apletu a JVM (Java Virtual Machine)

Tlustý proti tenkému

Možnost stahovat vše potřebné ze sítě na počítače uživatelů, díky modelu Network Centric Computing, má i některé další významné důsledky. Například tu, že výrazně snižuje náklady na správu a údržbu uživatelských počítačů. Díky celému principu fungování tohoto modelu totiž uživatelské počítače mohou být poměrně

jednoduché a "nerozbitné", protože se od nich očekává jen jedna jediná věc: schopnost stáhnout si ze sítě to, co je momentálně potřebné, a pak tomu předat řízení (spustit to a nechat běžet). A po použití (po skončení práce s příslušným programem) to jednoduše zahodit.

To je poměrně zásadní odklon od koncepce, se kterou se setkáváme u běžných pracovních stanic a osobních počítačů. U těch se totiž předpokládá, že na nich budou dopředu instalovány určité programy, tak aby byly pohotově k dispozici, pokud by o ně uživatel projevil zájem. Určitě to dobře znáte ze své praxe: kolik máte na svém počítači nainstalováno nejrůznějších aplikací, které jste už jak dlouho nepoužili (pokud vůbec)? Zcela určitě na vašem počítači jen zabírají místo na disku a další zdroje (třeba i operační paměť, skrze své knihovny).

Můžeme si to představit také tak, že klasický počítač PC je "tlustý" - právě v tom smyslu, že neustále bobtná instalováním dalších a dalších aplikací, které mohou, ale také nemusí být nikdy zapotřebí. Naproti tomu počítač, který si vše potřebné stahuje ze sítě, díky modelu Network Centric Computing, může být "tenký" (ve smyslu: jednoduchý odlehčený). Hovoří se o něm také jako o "tenkém klientovi", ale možná ještě výstižnějším označením je Network Computer, zkratkou NC (neboli: síťový počítač), kvůli vazbě na celý model Network Centric Computing. NC vs. PCSíťové počítače, alias počítače NC, jsou často dávány do protikladu k počítačům PC. Stejně tak se hovoří i o tenkých klientech (NC), jako o protipólu k tlustým klientům (PC).

Pravdou je, že ještě před několika lety se tenkým klientům (počítačům NC) přisuzovala velká budoucnost, a to jednak kvůli nižší pořizovací ceně (díky větší jednoduchosti), i kvůli výrazně nižším nákladům na správu a systémovou údržbu. Mohou to totiž být značně "blbovzdorná" zařízení, na kterých uživatel nemá co pokazit. A pokud by snad přeci jen něco pokazil, pak stačí je vypnout a znovu zapnout - a NC si vše potřebné znovu stáhne ze sítě.

Ovšem praxe představy o masovém zavádění počítačů NC nenaplnila. Jednak proto, že cenový rozdíl oproti klasickému PC se v mezičase stal relativně malým, až zanedbatelným. Stejně tak ale asi i proto, že přepsat rychle všechny skutečně používané aplikace do zcela nové podoby (nejspíše do podoby javovských apletů), se ukázalo jako nereálné. A když už se to někde podařilo, tak se zase zjistilo, že úzké hrdlo přeci jen může být v síti a v její omezené propustnosti, kvůli které by se větší aplikace stahovaly neúnosně dlouho.

Například kanadská firma Corel svého času už prakticky dokončila vývoj celého kancelářského balíku (Corel Office for Java) pro počítače NC a model Network Centric Computing. Pak jej ale sama předčasně ukončila. Mimo jiné kvůli tomu, že stahování celého kancelářského balíku, i z dostatečně rychlé sítě, trvalo neúnosně dlouho. Ovšem ani další podobné pokusy (například od firem IBM či Lotus) nebyly o nic úspěšnější.

Renesance modelu host/terminál?

Výpočetní model Network Centric Computing tedy moc úspěšný nebyl. Možná i proto, že poněkud předběhl svou dobu, a přišel příliš brzy se zcela novým konceptem (konceptem programů, stahovaných ze sítě až na základě skutečné potřeby). To další model, který si nyní popíšeme, na to šel úplně jinak. Jde o výpočetní model, který se jakoby "vrací zpět ke kořenům", k již osvědčenému řešení (výpočetnímu modelu) host/terminál, a snaží se jej upravit tak, aby vyhovoval současným potřebám. Připomeňme si, že model host/terminál předpokládá, že všechny zdroje (programy, data, výpočetní kapacita, periferie atd.) jsou umístěny na jednom centrálním místě, a to na hostitelském počítači (host-u), na kterém také všechny aplikace po svém spuštění běží.

Uživatelé pak s těmito aplikace pracují prostřednictvím terminálů, na které jim jsou zasílány výstupy příslušných aplikací, a ze kterých jsou naopak odesílány zpět vstupy od uživatelů (hlavně z klávesnice), určené těmto aplikacím.

Významnou předností modelu host/terminál bylo to, že vše v něm bylo "na jedné hromadě" (na hostitelském počítači), a to velmi výrazně usnadňovalo systémovou správu a údržbu.

Kdykoli byl potřeba nějaký zásah, dělal se na jednom místě a pro všechny uživatele současně. Nevýhodou modelu host/terminál pak bylo to, že svým uživatelům nabízel jen malý komfort, alespoň z dnešního pohledu. Fungoval totiž jen ve znakovém režimu, a nikoli v grafickém, na který jsou dnes uživatelé zvyklí. Důvody k tomu omezení přitom nebyly principiální, ale ryze praktické: pokud by aplikace, běžící na hostitelském počítači, generovaly své výstupy v grafice, pak objemy dat, které by se musely přenést na terminály

uživatelů, byly neúnosně velké. Dokonce tak velké, že ani při dnešních propustnostech lokálních sítí by jejich přenos nebyl únosný.

Server-based computing

A jak tedy vypadá moderní alternativa k dřívějšímu modelu host/terminál? Místo zastaralého "hostitelského počítače" (v angličtině "host"), již operuje s modernějším pojmem "server". Beze změny je ale to, že na tomto serveru (již ne "hostitelském počítači") jsou soustředěny všechny zdroje, včetně všech aplikací, a zde také tyto aplikace běží. Proto se také o příslušném serveru hovoří také jako o aplikačním serveru. To proto, že jako svou službu poskytuje možnost provozování (běhu) celých monolitických aplikací. Ale jak je to s druhou polovinou původního názvu host/terminál, tedy s terminálem, resp. s terminály?

Také ty se s postupem času změnily. Již to nejsou ony historické terminály, většinou tvořené jen monitorem a klávesnicí. Dnes v roli původních terminálů vystupují opravdu nejrůznější zařízení, od osobních počítačů (případně počítačů NC), přes různé tablety, zařízení PDA, až třeba po mobilní telefony. Skrze všechna tato zařízení, mnohdy velmi mobilní, chtějí být uživatelé ve styku se svými úlohami, které běží na aplikačním serveru.

Představa výpočetního modelu Server-based Computing

Kvůli tomu aplikace, běžící na aplikačním serveru, posílají své výstupy nikoli na klasické terminály, ale právě na takováto zařízení nejrůznějšího provedení. Z nich pak také dostávají od uživatelů pokyny ke svému fungování (vstupy z klávesnice, případně od myši či dotykové obrazovky apod.).

V zásadě ale stále platí, že i tato novodobá zařízení vystupují v roli terminálů - a to vůči aplikacím, běžícím na aplikačním serveru. Z tohoto důvodu se lze setkat i s tím, že místo o aplikačním serveru se hovoří o terminálovém serveru (například v rámci terminologie, používané společností Microsoft).

Ať už ale serveru, na kterém aplikace běží, budeme říkat aplikační či terminálový, podstatný je celý popisovaný výpočetní model. A tomu se říká Server-based Computing, což by se dalo volně přeložit jako "výpočetní model, založený na serverech".

Jak na grafiku?

V čem se ale novodobý model Server-based Computing liší od starého modelu host/terminál? Už jsme si naznačili, že hlavně v grafice, resp. v možností pracovat na koncovém zařízení s grafickém režimu, s grafickým uživatelským rozhraním. Jenže jak se toto slučuje s předchozí poznámkou, že pokud by aplikace generovaly své výstupy v grafice, objem grafických dat by byl tak velký, že by zahltil i dnešní, jinak dosti propustné sítě?

Po pravdě: moc se to neslučuje. Objemy grafických dat jsou zkrátka stále moc velké, a navíc rychle rostou s vyšším rozlišením a barevnou hloubkou grafického uživatelského rozhraní. Takže jak z toho ven?

Klíčem k úspěchu je negenerovat ony obrovské objemy grafických dat na aplikačním (terminálovém) serveru) ale až na koncovém zařízení (terminálu), kde už jejich velký objem nevadí. Jenže jak to udělat?

Princip je poměrně jednoduchý, a sází na jeden zajímavý trik: aplikace, běžící na aplikačním (terminálovém) serveru, negenerují své grafické výstupy samy, ale využívají k tomu služeb grafického subsystému místního operačního systému. Třeba když potřebují někde otevřít nějaké okénko, zadají tomuto grafickému subsystému příkaz ve stylu "otevři okno, na pozici XY, velikosti Z, v barvě B, s pozadím P" atd. No a teprve příslušný grafický subsystém operačního systému generuje vlastní grafická data, která v rastru obrazovky znázorní příslušné okno. Představa přenesení grafického subsystému na koncové zařízení

Podstatou celého triku je pak přestěhování příslušného grafického subsystému z aplikačního serveru na koncové zařízení, používané uživatelem. Mezi aplikačním serverem a tímto zařízením se pak budou přenášet jen ony příkazy ve stylu "otevři okno …", které mohou být opravdu velmi malé (co do objemu dat, nutných pro vyjádření takovéhoto příkazu). No a vlastní grafické data, třeba i "hodně velká", už jsou generována na koncovém zařízení, nemusí se nikam přenášet, a mohou se hned zobrazit. Pro fungování takovéhoto řešení může v praxi stačit opravdu minimální přenosová kapacita mezi aplikačním serverem a koncovým zařízením. Například pro provozování kancelářského balíku, jako je MS Word, stačí k běžné práci i 9,6 kbit/s (na jednoho uživatele).

Panning

Právě popsaný model Server-based Computing skutečně dává uživatelům možnost pracovat na dálku s aplikacemi, které ve skutečnosti běží "někde daleko", na vhodném aplikačním serveru. Třeba na aplikačním serveru, který je umístěn ve firmě, zatímco uživatel se právě nachází se svým notebookem, PDA či mobilem někde na druhé straně zeměkoule. Ale ani to mu nebrání, aby na dálku pracoval se všemi aplikacemi, které jsou dostupné ve formě. Jenže: jak je to se zobrazovacími schopnostmi koncových zařízení (terminálů), které se mohou opravdu výrazně odlišovat? Třeba na displeji PDA či dokonce mobilního telefonu toho lze zobrazit podstatně méně než třeba na displeji notebooku. U původního modelu host/terminál se aplikace ještě snažily samy přizpůsobit možnostem zobrazení na různých terminálech, které se ovšem nelišily až tak zásadně. Jenže zde už to možné není, protože rozdíly jsou opravdu příliš velké.

Proto se u zařízení s malými displeji pracuje s virtuální zobrazovací plochou (tzv. virtuálním desktopem), ze které se do reálného displeje promítá vždy jen část. Aplikace pak přizpůsobuje své výstupy "rozměrům" virtuální

zobrazovací plochy, a nemusí se již starat o to, jak velká (či spíše malá) část z této plochy je momentálně viditelná pro koncového uživatele.

Koncový uživatel si přitom může představovat, že displej jeho zařízení, třeba i velmi malý, je jen jakýmsi průzorem do této virtuální plochy, do které mu aplikace promítá své výstupy. A tímto průzorem může podle libosti hýbat, tak aby se podíval na to, co ho právě zajímá. Říká se tomu obvykle panning.

Příklady a představa panningu

Pravda, takovéto "koukání malým průzorem na velkou plochu" rozhodně není ideální, a nedokáže plnohodnotně nahradit zobrazení na dostatečně velkém displeji. Jenže když jiná možnost právě není po ruce ….

Konkrétní příklady

Konkrétních komerčních řešení, fungujících na bází právě popsaného modelu Server-based Computing, je na trhu více. Asi nejznámější je ale to, se kterým přišla firma Citrix, pod jmény MetaFrame a WinFrame (a využívající protokol ICA pro komunikaci mezi aplikačním serverem a koncovým zařízením v roli terminálu). Po určitém váhání přišel s vlastním řešením také Microsoft, pod názvem MS Terminal Server.

Snad nejstarší je ale řešení, vycházející z Unixu, s názvem X Window (pozor, bez "s" na konci). Jeho filosofie je ale v jednom ohledu specifická a zajímavá natolik, že si zaslouží podrobnější zmínku.

Systém X Window se sám o sobě chová jako aplikace, fungující na modelu klient/Server. Jenže co je server, a co klient, a jaké služby nabízí?

Server systému X Window poskytuje službu, spočívající v grafické vizualizaci. Tedy v zobrazování (vykreslování) v grafickém režimu. Lze si jej tedy představit i jako onen "grafický subsystém", který se přestěhoval z aplikačního serveru na koncové zařízení (terminál). A to platí i pro systém X Window: jeho server se nachází na koncovém zařízení (terminálu), protože své "vykreslování" musí provádět právě zde. Naopak jeho klient je umístěn na aplikačním serveru - a tím , kdo jej využívá, je samotná aplikace, provozovaná koncovým uživatelem. Kdykoli tato aplikace potřebuje něco zobrazit svému uživateli, požádá o to klienta systému X Windows. Ten pak předá příslušný požadavek až na koncové zařízení, svému serveru, a ten již zajistí potřebné vykreslení (zobrazení).

Představa systému X Window

Když si to ale vše představíme, podle dnešního posledního obrázku, je umístění klienta a serveru systému X Window jakoby přesně obrácené, oproti běžným zvyklostem: klient je tam, kde bychom očekávali server, a server zase tam, kde bychom intuitivně očekávali naopak klienta. Ale ono je to vlastně dáno tím, jakou službu server systému X Window poskytuje.

Hitem dnešního světa počítačových sítí je jejich propojování, alias tzv. internetworking. Zde se běžně operuje s pojmy a termíny jako opakovač, přepínač, směrovač či brána, případně rovnou s jejich anglickými ekvivalenty - repeater, switch, router či gateway. A když se k tomu přidá ještě rozbočovač, alias hub, může dojít k pořádnému zmatení. Pokusme se v tom udělat trochu jasno. Počítačové sítě jsou báječnou vymožeností. Naznačuje to ostatně i název celého tohoto seriálu. Jenže ne vždy je jejich přínos a efekt stejný. Velmi rychle totiž roste s tím, jak se příslušná síť zvětšuje, nebo alespoň propojuje s dalšími sítěmi. Určitě to dobře znáte z praxe, třeba u elektronické pošty: mít možnost poslat zprávu emailem kolegovi či kolegyni do vedlejší místnosti, v rámci firemní sítě LAN, je určitě fajn, ale možnost poslat takovou zprávu kamkoli na zeměkouli, skrze celosvětový Internet, je přeci jen něco jiného, co má podstatně větší přínos a efekt.

Dokládá to ostatně i jeden základní poznatek ze světa počítačových sítí, který poprvé formuloval pan Robert Metcalfe, známý jako vynálezce Ethernetu: užitek (užitná hodnota) sítě roste se čtvercem počtu jeho uživatelů! Takže když do nějaké sítě zapojíte dvakrát tolik uživatelů, efekt (přínos) takovéto sítě bude ještě větší než dvojnásobný. V praxi nejde takovýto "rychlejší než lineární" nárůst výsledného efektu vždy exaktně změřit a prokázat, už kvůli jeho obtížné měřitelnosti, ale aspoň intuitivně si to lze představit na jednoduchém příkladu: skupina n lidí může mezi sebou vytvářet n * (n-1) = n2 - n různých jednosměrných vazeb, jako například přímých emailů (od jednoho adresáta k jinému adresátovi) či výzev k on-line komunikaci apod. Ovšem skupina se dvojnásobným počtem členů (2n) už takovýchto vazeb může vytvářet 2n * (2n - 1) = 4*n2 - 2n.

Tento tzv. Metcalfův zákon tak vlastně vysvětluje, proč má dnešní Internet tak obrovský přínos pro celé lidstvo, a to nejen z pohledu vzájemné komunikace mezi lidmi. Jeho dopady lze nejspíše vztáhnout i na další oblasti,

jako třeba na rozvoj obchodu, vzdělanosti, kultury atd. Zřejmě ale s důležitým dodatkem, že jde o potenciál, který ne vždy dokážeme náležitě využít. Nebo dokonce jej ani nechceme využít, a vymýšlíme naopak různé bariéry a překážky.

Síťový efekt jako motivace pro internetworking

V tomto seriálu nadále zůstaneme u počítačových sítí. Otevřeme však další zajímavou kapitolu, kterou je problematika vzájemného propojování sítí, alias tzv. internetworkingu. Něž se ale dostaneme k tomu, jak konkrétně se to dělá, jaké techniky se k tomu používají a jaké nástrahy a překážky se přitom musí překonávat, zastavme se nejprve u toho základního: proč vlastně lidé své sítě propojují? Jakou k tomu mají motivaci?

S jednou významnou motivací jsme se vlastně již seznámili: jde o tzv. síťový efekt, který je popsán právě citovaným Metcalfovým zákonem. Lidé tedy propojují své sítě (mimo jiné) proto, aby dosáhli většího efektu, resp. užitku ze služeb, které v těchto sítích nabízí. A že to neplatí jen pro elektronickou poštu či on-line komunikace, by už pro nás také nemělo být žádným překvapením: třeba když si zřídíte webový server, přístupný jen z vaší lokální sítě, je to něco úplně jiného, než když jej zpřístupníte z celého celosvětového Internetu.

Terminologické okénko: internetworking, internetwork, internet, InternetAnglický termín internetworking je slovesem, které označuje činnost, spočívající v propojování (počítačových) sítí. Výsledkem této činnosti pak je soustava vzájemně propojených sítí, pro kterou má angličtina obecný termín internetwork. Ten se v praxi mnohdy zkracuje na pouhé internet.Termíny "internetwork", resp. "internet" tedy označují obecně jakoukoli soustavu vzájemně propojených sítí, bez toho že by říkaly cokoli o její velikosti, technickém řešení, vlastnických vztazích, možnosti přístupu k takovéto soustavě sítí apod. Takže "internetem" může být třeba to, co máte doma v obýváku, a co vám plně patří. Stejně tak to ale může být i nějaká velká firemní síť, vzniklá propojením několik sítí LAN, rozpínající se třeba i přes několik kontinentů. Stále je to obecný "internet", s definovaným vlastníkem, který určuje co a jak se s jeho sítí smí či nesmí dít. Vedle obecného termínu "internet" pak existuje ještě vlastní jméno "Internet" (psané s velkým počátečním písmenem), které označuje jednu konkrétní soustavu vzájemně propojených sítí, s celosvětovým dosahem - "ten" Internet, který všichni tak rádi používáme. Je charakteristický mimo jiné i tím, že jako celek nikomu nepatří (nemá žádného jednotlivého vlastníka). Své individuální vlastníky mají jen jeho jednotlivé části (dílčí sítě).Není internet jako Internet. Nebo ano?Na termín"internet" je třeba se dívat jako na obecné (druhové, resp. generické) označení, pro jakoukoli soustavu vzájemně propojených sítí. Podobnými generickými označeními jsou třeba pojmy jako televize, dálnice apod. Vedle nich pak existují konkrétní instance televizí (např. Česká televize, TV Nova, TV Prima atd.) či instance dálnic (D1, D5 atd.), které již mají svá vlastní jména, psaná s velkými počátečními písmeny. Zde si asi málokdo bude plést druhové (generické) označení s vlastním jménem jedné konkrétní instance daného druhu a klást mezi ně rovnítko. Tedy tvrdit něco ve smyslu "dálnice = D5", či "televize = TV Nova"). V případě vzájemně propojených počítačových sítí (internetů) je ale situace jiná. Alespoň u nás v ČR jsme už přestali skoro úplně rozlišovat mezi internetem jako obecným (druhovým, generickým) označením na straně jedné, a vlastním jménem jedné konkrétní celosvětové soustavy vzájemně propojených sítí ("tím" Internetem) na straně druhé. Píšeme běžně "internet" (s malým počátečním "i"), ale myslíme tím "Internet" (s velkým počátečním "I").

Další, úzce související motivací pro internetworking, je snaha něco zpřístupnit, obvykle na dálku. Pokud se třeba v jedné firemní síti LAN nachází šikovná tiskárna, a uživatelé jiné firemní sítě LAN na ní chtějí tisknout, musí se nejprve obě sítě vzájemně propojit. Jiným příkladem může být snaha zpřístupnit nějaké skladiště souborů (FTP archiv), nějaký superpočítač s jeho obrovskou výpočetní kapacitou, či jakýkoli jiný síťový zdroj. Možností je nepřeberně.

Potřeba propojení

Další důvody pro internetworking, alias vzájemné propojování sítí, mohou být čistě technické. Při budování sítí snad vždy narazíme na nějaké vzdálenostní omezení, které ale budeme potřebovat nějak překonat. Třeba u klasického desetimegabitového Ethernetu, ještě ve verzi využívající tzv. tenký koaxiální kabel, nesmí být souvislé kusy kabelu (tzv.. segmenty) delší

než 185 metrů. Pokud potřebujeme překlenout větší vzdálenost, musíme použít několik takovýchto segmentů a mezi sebou je vhodně propojit. A to už je vlastně základ internetworkingu.

Základní představa internetworkingu, jako vzájemného propojení dvou (či více) segmentů či sítí

Princip propojení je přitom až trapně jednoduchý: mezi dva kabelové segmenty, které potřebujeme propojit (či celé sítě nebo jejich části), umístíme vhodnou "krabičku". No a ta zajistí vše potřebné. Jednoduché, ne? Takže o čem se dnes budeme až do konce (a ještě příště a přespříště) vlastně bavit?

Opakovače, mosty, přepínače, směrovače, brány …

Jak záhy uvidíme, tak jednoduché to zase není. Velmi totiž záleží na tom, jak funguje ona "propojující krabička" - na jaké vrstvě (sedmivrstvého modelu ISO/OSI) pracuje, jakým způsobem se rozhoduje, co všechno přitom bere v úvahu, na co je zaměřena či přímo optimalizována, jaké techniky ke své činnosti využívá atd. Již teď, v prvním přiblížení, si však můžeme naznačit alespoň něco ze základní terminologie. Nejčastěji jsou totiž "propojovací krabičky" pojmenovávány podle toho, na jaké vrstvě fungují. Pak říkáme, že jde o:opakovač (anglicky: repeater), pokud "krabička" funguje na fyzické vrstvě most (bridge) či přepínač (switch), pokud funguje na vrstvě linkové směrovač (router), pokud funguje na vrstvě síťové brána (gateway), pokud funguje na aplikační vrstvě

Představa propojovacích prvků a jejich označení

Později, v dalších dílech, se seznámíme ještě s dalšími možnými termíny, jako třeba "L3 switch", "L4 switch" či "content switch". Stejně tak si později povíme o dalších propojovacích prvcích, jakými jsou například tzv. firewally či různé proxy brány. Ale teď se jimi ještě nebudeme zatěžovat.

Terminologické okénko: IP Gateway stále žije!Terminologie internetworkingu je dnes již dostatečně ustálená, ale ne vždy je skutečně dodržována a používána konzistentním způsobem. Nejčastější výjimkou je používání termínu "brána" tam, kde je ve skutečnosti myšlen směrovač. Ostatně, dodnes se s tím můžete setkat třeba při nastavování TCP/IP u nejnovější verze MS Windows (viz obrázek): v okamžiku, kdy se po vás chce zadání IP adresy výchozího směrovače, jste vyzváni k zadání adresy výchozí brány.

Nesvalujme ale vinu jen na autory české lokalizace. Stejná terminologická chyba je totiž i v anglickém originále, kde se používá termín Gateway. Důvodem je skutečnost, že používání termínu "IP Gateway" (doslova: IP brána) se zavedlo ještě v ranných dobách Internetu, kdy protokoly TCP/IP teprve vznikaly, a terminologie nebyla zdaleka tak ustálená. Jenže ani od té doby se používání věcně nesprávného termínu IP Gateway nepodařilo vymítit a nahradit věcně správným termínem "IP router" (IP směrovač).

Opakovač je když ….Pojďme se nyní podívat podrobněji na opakovač (anglicky: repeater). Jak už víme, jde o propojovací zařízení fungující na fyzické vrstvě, a typickým důvodem pro jeho použití je překonání "vzdálenostních omezení",vyplývajících z omezené maximální délky kabelových segmentů. Jinými slovy: nemůže-li mít souvislý kabelový segment více jak X metrů, ale my se potřebujeme dostat dále, použijeme dva či více kabelových segmentů (délky nejvýše X) a propojíme je prostřednictvím opakovače, resp. opakovačů.

Později se seznámíme s tím, že například v Ethernetu nemůžeme takto "řetězit" kabelové segmenty pomocí opakovačů libovolně dlouho, ale teď si toho ještě nebudeme všímat. Spíše si řekněme, že při použití opakovačů mohou vznikat i jiná než lineární uspořádání (viz obrázek č. 3), díky tomu že existují i opakovače s více tzv. porty, ke kterým se připojují jednotlivé kabelové segmenty.

Představa opakovače se dvěma a s více porty

A odkud že opakovač dostal své jméno? Od toho, že když přijímá nějaká data z kteréhokoli svého segmentu, okamžitě je rozesílá (jakoby: opakuje) do všech ostatních segmentů, které jsou k němu připojeny.

Představa fungování opakovače

Co ale v případě, pokud by opakovač přijímal data z více segmentů současně, a měl je všechny předávat do všech ostatních segmentů? Například v Ethernetu jsou takovéto nežádoucí situace celkem běžné, a říká se jim příhodně: kolize. Odpovídají situaci, kdy současně vysílá více uzlů, jakoby "proti sobě", a jejich vysílání kvůli tomu vzájemně "koliduje" (ve smyslu: vzájemně se ruší).

Důležité přitom je, že opakovač kolize nezastavuje, ale propouští dále. To pak má (stále v Ethernetu) jeden velmi významný důsledek: všechno, co je propojeno opakovačem, neboli na úrovni fyzické vrstvy, tvoří tzv. kolizní doménu.

Tedy oblast, po které se kolize šíří. Představa kolizních domén (v Ethernetu)

Kolizní doména má v Ethernetu ještě jeden důležitý význam: je to právě ta oblast, ve které je určitá přenosová kapacita sdílena všemi uzly, které se v dané kolizní doméně nachází. Takže když se jedná o klasický desetimegabitový Ethernet, pak oněch 10 Mbit/s sdílí všechny uzly v kolizní doméně. Je to dáno tím, že vysílat touto rychlostí může vždy jen jeden z nich, a nikoli více uzlů současně (protože to už by právě došlo k nežádoucí kolizi).

Kdo pracuje s čím? Opakovač je ve své podstatě jen digitální zesilovač, který z jedné strany přijímá signál představující jednotlivé datové bity, regeneruje tento signál (zesiluje, znovu právně tvaruje) a vysílá dál, do ostatních segmentů. Je navíc zařízením velmi hloupým, protože nevnímá význam jednotlivých bitů, které skrze něj prochází. Tudíž ani nedokáže rozpoznat situaci, kdy by takovéto bity již nemusel předávat (opakovat) do všech segmentů, ale třeba jen do jednoho cílového segmentu (nebo dokonce do žádného).

Představa opakovače jako digitálního zesilovače

Pokud bychom chtěli, aby se propojovací zařízení chovalo inteligentněji, pak už ho musíme nechat fungovat na některé z vyšších vrstev ISO/OSI. Teprve zde totiž může vnímat vzájemné souvislosti jednotlivých bitů, rozpoznávat "že k sobě patří" a že tvoří určitý blok, a podle obsahu tohoto bloku (hlavně podle adres příjemce) pak činit konkrétní rozhodnutí o tom, kam a zda vůbec příslušný blok předat dál.

Než si to dále rozvedeme, naznačme si o jaké bloky se kde jedná. I to je důležitý základ terminologie internetworkingu: opakovač (repeater) pracuje s jednotlivými bity (protože na fyzické vrstvě je přenášeným blokem bit jako takový) most (bridge) a přepínač (switch) pracují s linkovými rámci. Oba totiž fungují na úrovni linkové vrstvy, kde se přenášené bloky označují jako rámce (anglicky: frames). Takže třeba Ethernetový přepínač zpracovává ethernetové rámce. směrovač (router) pracuje s pakety. Funguje na síťové vrstvě, kde se přenášeným blokům říká právě pakety (packets). Takže třeba (IP) směrovač zpracovává IP pakety. brána (gateway) pracuje na úrovni aplikační vrstvy, kde označení přenášených bloků není vždy stejné. Například poštovní brány přenáší jednotlivé poštovní zprávy.

Most a přepínač jsou když …

Jak už tedy víme, mosty (anglicky: bridge) a přepínače (switch) pracují na úrovni linkové vrstvy, "vnímají" jednotlivé linkové rámce, a podle jejich obsahu se rozhodují o tom, jak s

nimi naloží. Zda mají nějaký konkrétní rámec cíleně předat do některého z dalších segmentů (pak jde o tzv. forwarding), nebo zda jej nemají vůbec předávat do žádného jiného segmentu (pak jde o tzv. filtering). Viz též obrázek č. 7.

Představa cíleného předávání (forwarding-u) a filtrování (filteringu)

Nechme v tuto chvíli stranou to, čím přesně se od sebe odlišují mosty a přepínače. K tomu se dostaneme v dalších dílech, v tuto chvíli vezměme zavděk alespoň konstatováním, že mosty jsou starší zařízení, zatímco přepínače jsou zařízení novější. Jinak je ale základní princip jejich práce stejný: pracují s linkovými rámci a podle (linkových, například ethernetových) adres odesilatele a příjemce se rozhodují, jak s rámcem naloží dále. Pro správné zasazení do celého dnešního kontextu si ještě zdůrazněme, že ke každému portu mostu či přepínače nemusíme připojovat jen jeden jediný uzel, ale obecně celý sdílený segment (celou kolizní doménu, viz výše). Vše naznačuje následující obrázek č. 8. K němu si dodejme, že případné kolize z jednotlivých kolizních domén již nejsou přenášeny dále. Mosty a přepínače (na rozdíl od opakovačů) totiž kolize zastavují.

Představa propojení na úrovni linkové vrstvy, pomocí mostů či přepínačů

A co vlastně vzniká, když pomocí mostu či přepínače propojíme několik segmentů (event. samostatných uzlů)? Výsledkem je celek na bezprostředně vyšší vrstvě, neboli jedna síť (anglicky: network). Třeba z pohledu přidělování IP adres je to skupina uzlů, které musí mít stejnou síťovou část své IP adresy. Nebo z pohledu všesměrového vysílání (tzv. broadcastu) je to oblast, kde se takovéto všesměrové vysílání musí šířit ke všem uzlům. Takže se v této souvislosti hovoří o broadcastové doméně (podobně jako "o patro níže" jsme měli kolizní doménu jako oblast, ve které se musela šířit kolize). Z toho nám také vyplývá, že mosty a přepínače sice již nepropouští kolize, ale stále musí propouštět všesměrové vysílání (broadcast).

Směrovač je když …

Jednotlivé sítě, jako skupiny uzlů vzájemně propojené na úrovni linkové vrstvy (pomocí mostů, resp. přepínačů) by stále ještě představovaly izolované ostrůvky, jejichž užitná hodnota (síťová efekt) by byla relativně malá. Tendenci k jejich vzájemnému propojování sítí, alias k internetwotkingu, však můžeme jednoduše vyhovět prostřednictvím směrovačů (router-ů).

Tedy propojením na úrovni síťové vrstvy, kdy propojovací zařízení již "vnímá" jednotlivé síťové pakety (v TCP/IP sítích konkrétně IP pakety), a podle jejich obsahu se rozhoduje jak s nimi naložit - kam daný paket nasměrovat tak, aby se (třeba i postupně) dostal ke svému cíli.

Z našeho dnešního pohledu je přitom podstatné, že pomocí směrovačům propojujeme jednotlivé sítě (networks), s tím že výsledkem takovéhoto propojení je soustava vzájemně propojených sítí, alias (v angličtině) "internetwork", zkráceně pak "internet". No a ceslovětový Internet pak není ničím jiným, než jednou konkrétní (a opravdu hodně velkou) soustavou takto vzájemně propojených sítí.

Představa propojování na síťové vrstvě, prostřednictvím směrovačů

Z představy obrovského celosvětového Internetu, jako jedné konkrétní soustavy vzájemně propojených sítí, si můžeme odvodit také jednu významnou vlastnost směrovačů (router): tyto již nepropouští ani kolize, ani všesměrové vysílání. Pokud by tak snad činily, okamžitě by zaplavily celý Internet.

Rozbočovače, alias hub-y

Na závěr si ještě řekněme o jednom specifickém propojovacím zařízení, které se poněkud vymyká z dosud zavedené terminologie. Jde o tzv. rozbočovač, anglicky: hub. Jeho smysl si nejlépe vysvětlíme na příkladu již zmiňovaného Ethernetu, který původně vznikl s představou použití koaxiálního (česky též: souosého) kabelu.

Podstatné bylo, že na koaxiálním kabelu se daly dělat různé odbočky, na které se připojovaly jednotlivé uzly. Výsledkem pak bylo uspořádání, které ukazuje levá část následujícího obrázku (č. 10). V odborné terminologii se tomu říká "sběrnicová topologie" (topologie "do sběrnice"). Po funkční stránce to přitom odpovídá použití opakovače (který je zde jakoby "zadrátován" skrze odbočky na kabelu). Přechod od koaxiálních kabelů a sběrnicové topologie v Ethernetu ke kroucené dvoulince (a hvězdicové topologii)

První verze Ethernetu, která předurčila všechny jeho základní vlastnosti, vycházela právě z předpokladu použití koaxiálních kabelů a sběrnicové topologie. Jenže časem byl i v rámci Ethernetu koaxiální kabel nahrazen kroucenou dvoulinkou (tzv. twistem), která je jednak lacinější, a má také další příznivější vlastnosti. Ale má také jednu méně výhodnou vlastnost, kterou je to že na kroucené dvoulince nejde dělat odbočky. Může být použita jen pro dvoubodové spoje, mezi dvěma uzly. Jenže jak to pak udělat, když je zapotřebí propojit mezi sebou více jak dva uzly?

Odpověď je principiálně jednoduchá: nelze-li dělat odbočky přímo na kabelu, je nutné je vytvořit elektronickou cestou a provést potřebné "rozvětvení" (či: rozbočení") elektrickými obvody, schovanými do vhodné "krabičky". No a takovouto "krabičkou" je právě zařízení, označované jako rozbočovač, anglicky: hub.

Důležité ovšem je, že rozbočovač nemá přesně předepsáno, jakým způsobem má vlastně "rozbočovat". Přesněji: na jaké vrstvě má propojovat jednotlivé segmenty, které do něj vstupují. Zda se má vůči přenášeným datům chovat jako opakovač, nebo jako přepínač, či dokonce jako směrovač.

V praxi to nejčastěji bývá tak, že rozbočovač funguje jako opakovač, a kvůli tomu se lze běžně setkat s kladením rovnítka mezi oba pojmy, ve smyslu "rozbočovač = opakovač". Ale my si budeme pamatovat, že tomu tak není, a že rozbočovač může fungovat i jinak než jako opakovač. Možná nejnázornější je představa toho, že rozbočovač je prázdné šasi ("skříňka"), do kterého si zákazník teprve přikupuje konkrétní (zásuvné) moduly, realizující jeho logické funkce. No a pak záleží na tom, zda si koupí modul realizující funkci opakovače, přepínače, či směrovače. Nebo dokonce brány?

Jedním z nejtěžších úkolů internetworkingu je správně zvolit velikost jednotlivých sítí. Některé faktory působí na jejich zvětšování, zatímco jiné spíše proti němu. A když už nějaké sítě máme, jAbychom správně porozuměli obsahu dnešního dílu, musíme si nejprve stručně zopakovat něco z toho, o čem jsme si povídali minule. Tehdy byla řeč o základech internetworkingu, a my jsme se seznamovali s tím, jak se říká propojovacím prvkům v závislosti na tom, na jaké vrstvě fungují: opakovač (anglicky: repeater) je to, co propojuje kabelové segmenty na úrovni fyzické vrstvy. most (bridge) a přepínač (switch) fungují na linkové vrstvě směrovač (router) funguje na úrovni síťové vrstvy brána (gateway) funguje na aplikační vrstvě Sdílená přenosová kapacita

O opakovačích jsme si říkali, že jsou to vlastně jen pouhé digitální zesilovače, které vnímají jednotlivé bity, ale už se nezabývají tím, zda tyto bity nějak patří k sobě (například zda tvoří nějaký linkový rámec). Proto si ani nemají z čeho odvodit, kterým směrem (do kterého segmentu) by konkrétní bity měly být předány, a kam by už naopak nemusely být předávány. Opakovače se proto musí chovat ke všem bitům stejně, a to rozesílat je ("opakovat") do všech segmentů, které jsou na ně napojeny.

Takovéto chování opakovačů má ale zajímavé a významné důsledky. Představme si třeba situaci podle dnešního prvního obrázku, na kterém jsou vyobrazeny dva segmenty po dvou uzlech, vzájemně propojené pomocí opakovače. Nevýhoda propojení dvou segmentů pomocí opakovačů: provoz v jednom segmentu zbytečně zatěžuje provoz ve druhém segmentu

Pokud budou v jednom z těchto segmentů vzájemně komunikovat dva zdejší uzly (na obrázku uzly A a B), bude opakovač tuto jejich vzájemnou komunikaci zbytečně předávat také do druhého segmentu. Kvůli tomu už ale v tomto druhém segmentu nebude moci probíhat (ve stejném čase) žádná jiná komunikace. Přesněji: pokud by se ve stejné době pokoušely spolu komunikovat zdejší dva uzly (C a D), jejich data by se "střetla" s daty, které si vzájemně předávají uzly A a B, a všechna přenášená data by se přitom znehodnotila. V Ethernet se tomu k říká kolize.

Praktický důsledek je pak ten, že při propojení pomocí opakovačů se všechny uzly ve všech propojených segmentech společně dělí o dostupnou přenosovou kapacitu. Například u klasického desetimegabitového Ethernet by to znamenalo, že by se všechny uzly dělily právě o těchto 10 Mbit/s. Na každý "vysílající" uzel, resp. komunikující dvojici uzlů, by tak připadla jen n-tá část takto sdílené přenosové kapacity. Pamatujme si tedy podstatný závěr: propojení na úrovni fyzické vrstvy, prostřednictvím opakovačů, vytváří sdílenou přenosovou kapacitu. Segmenty sítě, které takto vznikají, jsou sdílenými segmenty, ve kterých se všechny uzly společně dělí o dostupnou přenosovou kapacitu.

Od sdílené kapacity ke kapacitě vyhrazené

Vytvářet sdílené segmenty je relativně nejlacinější (oproti nákladům na propojování na vyšších vrstvách), a to by mohlo svádět k tendenci vytvářet co možná největší sdílené segmenty (ve smyslu: s co největším počtem uzlů). Jenže to má zásadní háček, kterým je samotná podstata sdílené kapacity: čím více uzlů se bude dělit o jednu společnou kapacitu, tím hůře, protože pak na každý z nich připadne menší podíl na této kapacitě. Ovšem požadavky, kladené na dnešní počítačové sítě, jsou většinou přesně opačně: aby na každý uzel připadala co možná největší přenosová kapacita, resp. co možná největší podíl na dostupné přenosové kapacitě. V optimálním případě by to mělo vypadat tak, aby každá komunikující dvojice uzlů měla jen a jen pro sebe veškerou dostupnou kapacitu, o kterou by se již nemusela s nikým dělit. Například u již zmiňovaného desetimegabitového Ethernet by to znamenalo, že každá komunikující dvojice by měla jen a jen pro sebe oněch 10 Mbit/s. Pak se dalo hovořit o tzv. vyhrazené přenosové kapacitě.

Vyhrazená přenosová kapacita je ale něčím, co je vhodné chápat spíše jako jakousi metu, či ideální cílový stav. Za určitých podmínek se k němu lze skutečně dostat, a záhy si ukážeme jak. Dosažení skutečně vyhrazené kapacity je ale relativně nákladné, a zdaleka ne vždy se vyplatí. Proto mají smysl, a v praxi jsou dokonce nejvíce rozšířené různé kombinace na pomezí mezi oběma extrémy, mezi sdílenou a vyhrazenou kapacitou. Ty se většinou snaží poskytnou co nejvíce přenosové kapacity (tj. na "vyhrazené" bázi) těm nejvytíženějším uzlům, zatímco ty méně vytížené se naopak musí smířit s menší přenosovou kapacitou na sdílené bázi. V zásadě vždy jde o klasický kompromis mezi cenou a požadovaným efektem. Zpět ale k mostům a přepínačům: jak si záhy naznačíme, obě tato zařízení už umožňují přecházet od sdílené přenosové kapacity ke kapacitě vyhrazené. A asi nejzásadnější rozdíl mezi nimi je v tom, jak daleko lze s nimi na této cestě dojít. V případě mostů, které jsou historicky starší, lze dojít jen nepříliš daleko. Zato v případě přepínačů lze dojít naopak hodně daleko, v optimálním případě až k samému cíli: ke skutečně plně vyhrazené kapacitě.

Jak zastavit sdílení?

Cesta, vedoucí od sdílené kapacity k vyhrazené přenosové kapacitě, začíná u toho, jak propojit mezi sebou dva (či více) sdílených segmentů, ale přitom nevytvořit nový a ještě větší sdílený segment. Jde tedy vlastně o to, jak "zastavit" další sdílení, při propojování jednotlivých (sdílených) segmentů.

Snad není těžké nahlédnout, že k takovémuto propojení už nemůžeme použít opakovače. Důvodem je neoptimální chování opakovače, které jsme si popisovali výše: opakovač nedokáže poznat, že určitý provoz by mohl zůstat lokální ve "svém" segmentu, a tak jej (zbytečně) šíří i do dalších segmentů. Tím vlastně "zachovává" sdílenou přenosovou kapacitu. K tomu, abychom dokázali zastavit sdílení přenosové kapacity mezi jednotlivými segmenty, je musíme propojit prostřednictvím inteligentnějšího zařízení, než je opakovač. Musí to být takové zařízení, které již dokáže poznat, odkud data přichází (kdo je jejich odesilatelem) a kam směřují (kdo je jejich příjemcem). Podle toho se pak musí umět správně rozhodnout, jak s nimi naložit.

V úvahu přitom připadají dvě základní možnosti: filtering (filtrování): kdy data mohou zůstat lokální v segmentu kde vznikla, a nemusí být šířena dál do dalších segmentů. Jinými slovy: takováto data může propojovací zařízení zastavit, resp. odfiltrovat, a dále se jimi nemusí zabývat. forwarding (cílené předávání): zde již je, na rozdíl od filtrování, zapotřebí data předat dál, do některého z dalších segmentů. Nikoli do všech ostatních segmentů (kterých může být více), ale jen do toho, kde se nachází příjemce dat. Proto se také hovoří o "cíleném" předávání, které vyžaduje aby propojovací uzel uměl správně identifikovat cílový segment.

Představa forwardingu a filteringu

Opakovače nemohou zajišťovat ani filtering ani forwarding už jen proto, že nemají z čeho získat výchozí informace o odesilateli a příjemci. Všímají si jen jednotlivých bitů - a na této úrovni skutečně "nejsou vidět" žádné adresy odesilatelů a příjemců, ze kterých by se dalo vycházet.

K tomu, aby propojovací zařízení dokázalo rozpoznat, kdo je odesilatelem a kdo příjemcem konkrétních dat, už si musí umět poskládat jednotlivé bity do větších celků (bloků). Nejméně do linkových rámců (anglicky: frames), jak se říká blokům přenášeným na úrovni linkové vrstvy. Musí také rozumět formátu těchto rámců, tak aby si v nich dokázalo najít adresu odesilatele a adresu příjemce daného rámce. Pak také musí rozumět významu těchto adres (správně je interpretovat). V neposlední řadě musí takové zařízení vědět něco i o svém nejbližším okolí, hlavně ve kterém segmentu se nachází ten který uzel. To je totiž nutné pro možnost cíleného předávání (forwardingu).

Jinými slovy: k zastavení sdílení již potřebujeme propojovací zařízení, fungující (alespoň) na úrovni vrstvy linkové. Tedy buď most, nebo opakovač. Oba druhy zařízení již požadované schopnosti mají.

Stejného efektu, tedy "zastavení sdílení", však dosahují i propojovací zařízení, fungující na vyšších vrstvách. Tedy například směrovače a brány. Ale ty už jsou zase zaměřeny spíše na jiné úkoly.

Jak funguje most?

Pojďme si nyní ukázat, jak konkrétně dokáží mosty "zastavit" sdílení přenosové kapacity. Představme si to na následujícím obrázku, který ukazuje propojení dvou sdílených segmentů, nejprve pomocí opakovače (vlevo), a pak pomocí mostu (vpravo). Předpokládejme dále, že spolu komunikují uzly A a B, které se nachází ve stejném segmentu. Při propojení pomocí opakovače (v levé části obrázku) je tento jejich provoz přenášen opakovačem i do druhého segmentu, kde brání současnému provozu dalších uzlů, resp. spotřebovává i "zdejší" přenosovou kapacitu (protože oba propojené segmenty sdílí společnou přenosovou kapacitu). Ovšem pokud je pro propojení obou segmentů použit most, provoz mezi uzly A a B se do druhého segmentu již nepřenáší. Most zde aplikuje filtering, protože si dokáže odvodit, že jde o provoz mezi uzly A a B, které se oba nachází ve stejném segmentu (na obrázku vlevo). To pak také znamená, že ve druhém segmentu (vpravo) mohou současně komunikovat mezi sebou uzly C a D, a most opět nepropouští jejich vzájemný provoz do prvního (levého) segmentu. Zde jsme tedy již dosáhli vytouženého efektu vyhrazené přenosové kapacity: každá z komunikujících dvojic zde má k dispozici a jen a jen pro sebe celou dostupnou kapacitu. V případě desetimegabitového Ethernetu plných (nominálních) 10 Mbit/s.Představa rozdílu mezi propojením pomocí opakovače a pomocí mostu, s dosažením efektu vyhrazené kapacity.

Pozor ale na to, že zdaleka nejsme ještě u cíle. Na následujícím obrázku vidíte situaci, kdy ani most nedokáže sdílení zastavit. Stačí k tomu, aby spolu komunikovaly dvojice uzlů, které se nachází v různých segmentech. Zde pak most nemá co filtrovat, a naopak veškerý provoz musí předávat (forwardovat) z jednoho segmentu do druhého. Takže zde se opět všechny uzly dělí o jednu společnou přenosovou kapacitu.

Propojení pomocí mostu, bez dosažení efektu vyhrazené přenosové kapacity

K čemu sloužily mosty?

Propojení na úrovni linkové vrstvy, prostřednictvím mostů, tedy nedokáže spolehlivě zajistit efekt vyhrazené přenosové kapacity. Ostatně, od mostů se to ani moc neočekávalo. Jak jsme si již uvedli, jsou to relativně starší zařízení, která se používala ještě v době, kdy nebyl tak velký "hlad po rychlosti" (vyšší přenosové kapacitě) jako dnes.

Byla to doba, kdy sdílené segmenty byly spíše větší (ve smyslu: s více uzly), a bylo jich o to méně. Velmi častým případem pak byla potřeba propojit pouze dva takovéto sdílené segmenty mezi sebou, a tomu se konstrukce mostů také přizpůsobovala - typické mosty měly jen dva porty a dokázaly propojit jen dva segmenty. I díky tomu se mohly soustředit na filtrování provozu mezi nimi, zatímco s cíleným předáváním měly minimum práce. Pokud totiž zjistily, že konkrétní rámec nemá zůstat lokální (nemá být filtrován), jednoduše jej předaly do druhého segmentu (a nemusely přemýšlet, do kterého). Proto také již výše zmiňovaná optimalizace mostů na filtering.

Proč jsou zapotřebí přepínače?

S postupem času se ale v počítačových sítích "hlad po rychlosti" prosadil dosti razantně, a vyústil mimo jiné i ve zrychlování samotných přenosových technologií. Například Ethernet se díky tomu dočkal stomegabitové verze, posléze i gigabitové atd. Současně se ale začaly hledat i cesty, jak co nejefektivněji využít takto nabízenou přenosovou kapacitu. Tedy cesty k vyhrazení přenosové kapacity, místo jejího sdílení.

Postup byl přitom takový, že dřívější velké sdílené segmenty (s velkými počty uzlů) se začaly zmenšovat, tak aby na každý uzel v rámci segmentu mohl připadnout větší podíl na celkové kapacitě. Obecně se tomuto procesu začalo říkat segmentace, tentokráte ovšem ve smyslu "rozdělování", či "rozčleňování" (na menší části, označované jako segmenty).

Současně se zmenšováním segmentů pochopitelně rostl i jejich počet. Po propojovacích zařízeních se pak požadovalo, aby jich zvládly propojit více než dva, jako tomu bylo typické pro původní mosty. To dalo vzniknout nejprve "víceportovým mostům" (multiport bridges), které se ale záhy přejmenovaly na přepínače (switches).

Představa segmentace a přechodu od mostů k přepínačům

Celý tento trend ale měl ještě jeden zajímavý důsledek. Pokud se totiž segmenty zmenšovaly, tj. klesal počet jejich uzlů, bylo čím dál tím pravděpodobnější, že uzly v jednotlivých segmentech budou chtít komunikovat více s uzly, které se nachází v jiných segmentech. Jinými slovy, lokální provoz v rámci segmentů začal klesat, a stoupat naopak začal provoz, který bylo třeba předávat z jednoho segmentu do druhého. To ale změnilo i nároky, kladené na propojovací zařízení. Potřeba filtrování ("nepředávání dále") ustupovala spíše do pozadí, protože k němu docházelo méně častěji. Naopak častější začalo být cílené předávání do jiných segmentů (forwarding), a tak začalo hodně záležet na tom, jak dobře a rychle jej přepínač zvládal. Takže zatímco starší mosty byly optimalizovány hlavně na filtering, novější přepínače už musí být optimalizovány na forwarding. Přepínání, alias switching

Proč ale záleží tolik na tom, jak dobře (rychle) přepínač zvládá cílené předávání do jiných segmentů, alias forwading?

Důvod opět souvisí se snahou poskytnout komunikujícím dvojicím uzlů vyhrazenou přenosovou kapacitu, a ilustruje ho následující obrázek.

Představa fungování přepínače

Všimněme si hlavně části obrázku vlevo, kde spolu komunikují dvojice uzlů, a každý z nich se přitom nachází v jiném segmentu. Žádný z nich tedy nesdílí přenosovou kapacitu s žádným dalším uzlem ve svém segmentu. Znamená to pak, že může se svým protějškem komunikovat "plnou rychlostí", s využitím celé dostupné přenosové kapacity?

To ještě záleží na tom, jak funguje samotný přepínač. Pokud "stíhá" předávat všechna data mezi segmenty včas a nemusí je nějak zadržovat či omezovat, tj. pokud nevytváří "úzké hrdlo", pak komunikující uzly mají k dispozici plnou přenosovou kapacitu, odpovídající vyhrazené přenosové kapacitě. Naopak, pokud by přepínač "nestíhal", zpomaloval (omezoval) by komunikaci všech uzlů. Záleží tedy na celkové propustnosti samotného přepínače. Pozor ale na to, že ani dostatečně výkonný a rychlý přepínač ještě nemusí postačovat pro dosažení kýženého efektu vyhrazené přenosové kapacity. V předchozím příkladu jsme totiž použili omezující předpoklad, že z každého segmentu komunikuje vždy jen jeden uzel. To ale v praxi nemusí být vždy splněno (viz pravá část obrázku č. 6), a v příslušném segmentu či segmentech pak stále dochází ke sdílení.

Mikrosegmentace

Naštěstí se ale v procesu segmentace (postupného rozdělování segmentů na stále menší části) dá pokračovat tak dlouho, dokud se segmenty nestanou jednouzlovými (dokud nebudou obsahovat jen jeden uzel). Tomuto stavu se říká příznačně: mikrosegmentace, zřejmě ve smyslu rozdělení na nejmenší možné segmenty.

V případě mikrosegmentace už žádné sdílení přenosové kapacity v rámci segmentu nehrozí, neboť není s kým sdílet. V cestě k dosažení plně vyhrazené přenosové kapacity pak stojí už jen dostatečná propustnost přepínače, který jednouzlové segmenty propojuje.

Představa mikrosegmentace

Povšimněme si také toho, že v případě mikrosegmentace (jednouzlových segmentů) už neexistuje žádný lokální provoz, který by se odehrával jen v rámci daného segmentu. Místo toho veškerý provoz směřuje přes propojovací prvek vždy do některého jiného segmentu. To pak také znamená, že propojovací prvek (přepínač) už neprovádí žádný filtering, ale jen samý forwarding. O důvod více pro to, aby byl na něj optimalizován. Pokud totiž má přepínač "stíhat" a nemá způsobovat žádné zpomalení, musí zvládat přenášet souběžně veškeré datové toky, které jsou k němu připojené uzly schopné generovat. A to už je zase o dimenzování výkonu (přepojovací kapacitě) přepínače, která ani dnes rozhodně není zadarmo.

Jak tomu bývá v praxi

Když už jsme se dostali k ekonomickým aspektům, zůstaňme u nich ještě chvilku. Právě ekonomické důvody totiž rozhodují o tom, zda možnost dosažení plně vyhrazené přenosové kapacity bude skutečně využita, nebo nikoli. Vytváření jednouzlových segmentů je totiž poměrně nákladné (hlavně skrze cenu dostatečně výkonného přepínače), a tak se používá spíše jen u hodně zatížených uzlů, zejména různých serverů. Naopak pro uzly, generující nižší síťovou zátěž (jakými bývají například různé pracovní stanice), se stále využívá přeci jen lacinějšího sdílení přenosové kapacity, resp. sdílené segmenty s více uzly.

Typické řešení, používané v praxi, naznačuje následující obrázek. Ukazuje dva servery, které jsou připojeny přímo na jednotlivé porty (rozhraní) přepínače, a tvoří tak jednouzlové segmenty. Na další porty téhož přepínače pak jsou napojeny sdílené segmenty, tvořené určitým počtem pracovních stanic.

Představa v praxi používaného řešení

Stále tedy jde o určitý kompromis mezi snahou dosáhnout co možná nejvíce vyhrazené přenosové kapacity (pro servery), a nízkými náklady pro připojení pracovních stanic, které musí vystačit se sdílením přenosové kapacity.

Rekapitulace

Zopakujme si na závěr ještě jednou, v čem se mosty a směrovače liší, a v čem se naopak shodují.

Společné mají to, že fungují na úrovni linkové vrstvy, a při své činnosti se rozhodují podle údajů, dostupných na této vrstvě. Tedy především z linkových adres odesilatele a příjemce. Liší se naopak v tom, co se od nich očekává, na co jsou zaměřeny a optimalizovány. Mosty jsou historicky starší, a jsou uzpůsobeny potřebám propojení spíše malého počtu velkých segmentů. Očekává se od nich hlavně to, aby zbytečně nešířily lokální provoz z jednoho segmentu do druhého. Proto jsou optimalizovány hlavně na filtering. Naproti tomu přepínače jsou novějším druhem zařízení, a očekává se od nich, že umožní rozčlenit síť na libovolně malé segmenty (včetně jednouzlových), a dokáží je propojit a předávat (přepínat) mezi nimi linkové rámce tak rychle, aby bylo dosaženo co možná nejvíce z efektu vyhrazené přenosové kapacity. Proto jsou také přepínače optimalizovány na forwarding, neboli na rychlost cíleného předávání linkových rámců do jiných segmentů.

Jak je nejlépe propojit? Kdy použít klasický směrovač, alias router, a kdy raději zařízení zvaná L3 switch, případně L4/7 switch? Jaký problém řeší sítě VLAN?

Problematika vzájemného propojování sítí, alias tzv. internetworkingu, je značně rozsáhlá a má řadu specifických podkapitol. V minulém dílu tohoto seriálu jsme se například zabývali propojováním na úrovni linkové vrstvy, a řekli si o rozdílu mezi mosty (anglicky: bridge) a přepínači (anglicky: switch). Výsledkem pak bylo konstatování, že pomocí přepínačů můžeme maximalizovat propustnost zejména v lokálních sítích (sítích LAN). Konkrétně tak, že ty uzly, které mají mezi sebou komunikovat co možná nejrychleji, propojíme právě na úrovni linkové vrstvy, pomocí přepínačů.

Pro nejvíce vytížené uzly, kterými jsou nejčastěji různé servery, můžeme vyhradit jednotlivé porty přepínačů. Pak má každý server celou přenosovou kapacitu příslušného portu jen a jen pro sebe (jako tzv. vyhrazenou kapacitu). V případě takovýchto "jednouzlových" segmentů pak hovoříme o mikrosegmentaci.

Pro ostatní uzly, které již nemají tak velké nároky, postačí když budou sdílet jeden port přepínače (i s jeho přenosovou kapacitou) s dalšími uzly. K příslušnému portu se pak připojuje celý sdílený segment, realizovaný s využitím opakovače - viz dnešní první obrázek (který byl současně posledním obrázkem minulého dílu). Představa sítě jako soustavy jedno či víceuzlových segmentů, propojených na úrovni linkové vrstvy, pomocí přepínače

Vliv broadcastu, aneb: nic se nesmí přehánět

I v počítačových sítích, stejně jako v životě lidském, však platí že nic se nemá přehánět. A to ani počet uzlů, vzájemně propojených na úrovni linkové vrstvy. Tedy velikost sítě - protože to, co je propojeno na úrovni linkové vrstvy, představuje jednu síť (z pohledu síťové vrstvy). Pokud by jediným významným faktorem byla pouze propustnost, pak by logika věci skutečně velela dělat co možná největší sítě, resp. co největší soustavy uzlů, propojených jen na úrovni linkové vrstvy pomocí přepínačů. Ale v praxi se uplatňují i další faktory, které působí přesně opačně: omezují velikost jednotlivých sítí a požadují spíše jejich zmenšování, než zvětšování. Jde například o to, že při propojení na úrovni linkové vrstvy musí být šířeno všesměrové vysílání (tzv. broadcast). I přepínače tedy mají povinnost rozesílat všesměrové rámce skutečně do všech směrů (portů), které znají - což okamžitě degraduje efekt vyhrazené přenosové kapacity, o který přepínače jinak usilují. Lavina se zastavuje až na hranici sítě, konkrétně na nejbližším směrovači, protože ten již všesměrové vysílání nepropouští (viz obrázek).

Představa šíření všesměrového vysílání uvnitř sítě

Přitom všesměrové vysílání (broadcast) je dnes velmi oblíbenou a používanou technikou, například pro objevování dostupných síťových zdrojů. Třeba pracovní stanice, která hledá nějaký server, jej bude hledat tak, že vyšle svou výzvu jako všesměrový (broadcastový) rámec. Ten pak musí být předán do všech segmentů, propojených na úrovni linkové vrstvy - a tak se lze spolehnout, že pokud takový server v dané sítí existuje, výzva se k němu dostane. Jenže v době, kdy se všesměrový rámec šíří do všech segmentů dané sítě, v nich už nemůže probíhat žádná jiná komunikace.

Obecně přitom platí, že čím více je v dané sítí uzlů, tím větší je pravděpodobnost, že budou generovat nějaké všesměrové (broadcast) rámce, kterými "zahltí" celou síť. Od určité velikosti sítě by se v ní, kvůli samým broadcastům, už nedalo přenášet vůbec nic jiného. Jde tedy o faktor, který působí proti přílišnému zvětšování sítí (neboli toho co je propojeno na úrovni linkové vrstvy, pomocí přepínačů).

Nebezpečný princip fungování

Dalším faktorem, který také působí proti přílišnému zvětšování sítí, je samotný princip fungování přepínačů. Již v minulém dílu tohoto seriálu jsme si popsali, že přepínače jsou optimalizovány na tzv. forwarding, neboli na cílené předávání linkových rámců do příslušných cílových segmentů, a nikam jinam (tj. do žádných jiných segmentů). Jenže toto platí pouze za předpokladu, že přepínač již zná své okolí a ví, kde se cílový uzel nachází. Pokud tuto informaci nemá, musí se chovat v zásadě jako opakovač: musí rozesílat příslušný rámec do všech směrů (segmentů), které zná (které jsou k němu připojeny). Podrobněji viz box "Jak se učí samoučící přepínače".

Jak se učí samoučící přepínače?Přepínače (stejně jako mosty) mají v náplni práce usilovat o tzv. forwarding, neboli o cílené předávání linkových rámců právě a pouze do těch linkových segmentů, kde se nachází příjemce rámce. Jenže to znamená, že musí dostatečně přesně znát své okolí a vědět, kde je ten který uzel umístěn. Ale jak se to dozví? Je nutné je nějak konfigurovat (nastavit), a v rámci toho jim poskytnout potřebnou informaci o jejich okolí? Například v Ethernetu tom není. Ethernetové přepínače (i mosty) jsou řešeny jako plug&play zařízení, která stačí pouze zapnout, a informace o uzlech ve svém okolí si již získají nějak samy. Dokonce se v této souvislosti mluví o "samoučení", v tom smyslu že přepínače se samy naučí znát své okolí. Konkrétní postup učení je principiálně jednoduchý. Kdykoli přepínač přijme linkový rámec z určitého segmentu, může si z toho odvodit, že jeho odesilatel leží právě v tomto segmentu. Takže když pak někdy později přijme jiný linkový rámec, určený stejnému uzlu, přepínač již ví kde se nachází a může mu linkový rámec cíleně předat (tj. předává jej pouze do příslušného segmentu, kde se příjemce nachází, a nikam jinam).

Představa principu samoučení u Ethernetových přepínačů

Otázkou ovšem je, jak se má přepínač zachovat v případě, kdy dosud "není naučen" a neví, kde se příjemce nachází. V takovémto případě raději nic neriskuje a rámec vyšle do všech ostatních segmentů (kromě toho, odkud přišel). V této době se tedy chová jako opakovač - ale většinou ne moc dlouho, protože na takovýto rámec obvykle následuje odpověď v opačném směru, ze které se již "naučí" polohu příslušného uzlu. Problémem však jsou cykly v topologii sítě, kvůli kterým přepínač dostane stejný rámec ze dvou směrů a nemůže si pak být jist, kde se nachází odesilatel rámce. Inteligentní přepínače se však dokáží i s touto situací vyrovnat: rozpoznají, že došlo k zacyklení topologie, a ve spolupráci s ostatními přepínači cyklus samy rozpojí.

Cykly jsou překážkou samoučení Ethernetových přepínačů

Pro mosty platí v zásadě to samé, jako pro přepínače, Snad jen s výhradou inteligentního chování při detekci a rozpojování cyklů, kterým mosty jako historicky starší zařízení nejsou vybavovány.

Přepínače tedy fungují na principu "pokud nevíš kam rámec patří, rozešli ho na všechny strany". To ale může být v některých situacích docela nebezpečné. Třeba pokud nějaký uzel, nejspíše v důsledku vlastní chyby, začne opakovaně posílat rámce na neexistující uzly. Pak je všechny přepínače v dané sítí musí šířit do všech stran, stejně jako všesměrové vysílání (broadcast).

To směrovače, které propojují na úrovni síťové vrstvy, fungují na přesně opačném principu: "předávej dál pouze ty pakety, u kterých víš kam patří". Proto se v případě chyb a různých

nestandardních situací chovají podstatně "bezpečněji" než přepínače. Stejně tak zastavují všesměrové vysílání (broadcast).

Celkově je právě popsaný rozdíl mezi přepínači a směrovači dalším důvodem, proč nedělat sítě (tj. soustavy uzlů, propojené na úrovni linkové vrstvy) moc velké. Lépe je volit sítě "přiměřeně velké" a propojovat je mezi sebou na úrovni síťové vrstvy, pomocí směrovačů. Ovšem co je ono "přiměřeně velké"?

Homogenita sítí

S volbou "přiměřené velikosti" sítě může pomoci další faktor, kterým jsou různé logické vztahy a závislosti. Jde hlavně o otázku přístupových práv a oprávnění uživatelů sítě, které by musí být adekvátně reflektovány. Tedy věci typu "kdo kam smí či nesmí", "kdy tam smí" atd. Takováto práva a další atributy jsou ale obvykle definovány až na úrovni síťové vrstvy, typicky v závislosti na síťové adrese (např. IP adrese) - a nikoli na úrovni linkové vrstvy, kde by musely být vázány na linkové adresy (např. na Ethernetové adresy). Velmi často pak jsou tato práva "generalizována" tak, že jsou definována po celou síť jako takovou, a pro konkrétní uzel jsou odvozována podle jeho příslušnosti do konkrétní sítě. Ve smyslu: "když patříš do té či oné sítě, máš taková a taková práva". Pak je ale samozřejmě nutné volit velikost sítě tak, aby její uzly, resp. jejich uživatelé, vykazovali určitou homogenitu co do svých požadavků a potřeb, a tím i práv, která jim jsou přisuzována. To opět působí spíše proti přílišnému zvětšování sítí, jako celků propojených pouze na úrovni linkové vrstvy. Ne vždy je ale v praxi možné takovýto požadavek na homogenitu respektovat, zejména kvůli fyzickým dispozicím. Přesto i zde existuje řešení, v podobě tzv. virtuálních sítí LAN (VLAN), viz samostatný box.

Jaký problém řeší sítě VLAN?Rozdělit konkrétní počítače do jednotlivých sítí podle toho, k čemu a komu slouží, neboli podle logických kritérií, nebývá vždy možné. Obvykle mají navrch "fyzická kritéria", resp. fyzické umístění, dostupnost kabelových rozvodů a vzdálenost od nejbližšího aktivního prvku (opakovače, přepínače či směrovače). Jednotlivé uzly pak jsou zařazovány do sítí podle toho, kde jsou umístěny. Například podle toho, na kterém patře se nachází, jak naznačuje následující obrázek.

Představa rozdělení uzlů do sítí podle fyzických dispozic

Naštěstí ale existuje řešení, v podobě tzv. virtuálních sítí LAN (zkratkou VLAN). Jde o technické řešení, které umožňuje nebrat ohled na fyzické dispozice, a rozdělovat uzly do sítí podle jiných kritérií (obecně libovolně). Jak to pak může vypadat, ukazuje následující obrázek. Způsob, jakým jsou virtuální sítě LAN (VLAN) realizovány, by ale již byl na delší povídání, které si necháme na jindy. Zcela ve zkratce si ale lze představit, že každý linkový rámec v sobě nese identifikátor "své" virtuální sítě, a pekel toho je s ním také nakládáno.

Představa VLAN

Práva? Až na síťové vrstvě!

Snaha vytvářet homogenní sítě, se stejnými právy a dalšími logickými atributy svých uživatelů, resp. uzlů, má ještě jeden velmi racionální důvod. Je jím skutečnost, že přepínače se takovýmito "logickými záležitostmi"

většinou vůbec nezabývají. Jelikož jsou to zařízení, optimalizovaná na rychlost a usilující o maximální propustnost, a kvůli tomu už nemají čas se při svém rozhodování zabývat dalšími věcmi.

Na takovéto "podrobnější rozhodování", které bere v úvahu i různá přístupová práva a další omezení, mají čas a kapacitu spíše až směrovače, fungující na síťové vrstvě a propojující jednotlivé sítě. Souvisí to i s jejich konstrukcí: jejich "rozhodovací stroj" je většinou implementován softwarově (tj. programovými prostředky), a má tedy více možností jak brát v úvahu různé logické závislosti, než "rozhodovací stroj" přepínačů, který je kvůli požadavku na maximální rychlost "zadrátován" (implementován v hardwaru), a tudíž musí být co možná nejjednodušší.

Zlaté pravidlo 80:20

V minulosti existovalo dokonce určité empirické pravidlo, které říkalo že v "rozumně velké" a dobře navržené síti se cca 80 procent všech datových toků odehrává uvnitř sítě, a pouze zbývajících cca 20 procent směřuje z dané sítě ven. Říká se tomu také "pravidlo 80:20".

Řečeno jinými slovy to také znamená, že nejméně 80 procent přenosů musí zvládnout přepínače uvnitř sítě, zatímco směrovače jsou podstatně méně zatížené, když přes ně prochází jen cca 20 procent provozu, směřujícího ven. I vzhledem k tomu musí být přepínače optimalizovány na rychlost, zatímco směrovače už mají více času věnovat se přenášeným datům podrobněji a zkoumat i takové věci, jako jsou přístupová práva a další logické záležitosti.

Představa pravidla 80:20

Obvyklým způsobem, jak se poměru 80:20 dosahovalo, bylo umístění všech "stejných" uživatelů (resp. jejich uzlů) do stejné sítě, a přidání těch zdrojů, se kterými pracují nejčastěji. Takže pokud šlo například o skupinu účetních nějaké firmy, zapojily se jejich počítače do stejné sítě, a do ní se přidal ještě server provozující příslušnou účetní aplikaci a uchovávající související data. Uživatelé-účetní pak komunikovali hlavně s tímto serverem, případně jen mezi sebou. Ostatní komunikace, směřující již "ven z dané sítě", pak byla podstatně méně častá.

L3 Switching

Jenže dnes, v době Internetu a outsourcovaných řešení, je situace jiná. Dnes už i účetní mohou v podstatně větší míře komunikovat i se svým okolím, ať již v rámci firemního intranetu či celosvětového Internetu. Nehledě na to, že místo "lokální" účetní aplikace, běžící na serveru nestejné síti, mohou využívat na dálku aplikace, které běží někde úplně jinde. Například aplikaci, provozovanou v rámci modelu ASP (Application Service Provisioning) .

Obecným důsledkem, který samozřejmě platí pro všechny uživatele a ne pouze pro účetní, pak je konec platnosti dřívějšího pravidla 80:20. Dnes již tento poměr může vycházet úplně jinak, třeba i obráceně. Tedy tak, že většina provozu naopak směřuje ven z dané sítě, a jen menší část zde zůstává.

To ale přináší významné změny v požadavcích, kladených na směrovače. Nyní už skrze ně prochází podstatně více provozu, který musí "stíhat" zpracovávat dostatečně rychle - a tak se tomu musí přizpůsobovat i jejich konstrukce a způsob fungování. V zásadě nejde o nic jiného, než o optimalizaci na rychlost, podobně jako u přepínačů (anglicky: switch). Například skrze to, že rozhodovací logika směrovačů už není implementována programovými prostředky (v softwaru), ale je stále více "zadrátovávána" (zabudovávána do hardwaru).

Výsledkem pak je nový druh zařízení, pro který se ujalo označení "L3 switch" (od: Layer 3 switch, ve smyslu: přepínač na 3. vrstvě). Z hlediska logiky svého fungování je to stále směrovač, protože funguje na úrovni síťové vrstvy, a rozhoduje se právě a pouze podle síťových adres (adres na síťové vrstvě, například IP adres). Ale jeho rozhodovací schopnosti jsou redukovány na nezbytné minimum, které je nutné pro korektní fungování (v zájmu maximalizace rychlosti). Proto již obvykle nezbývá prostor pro respektování dalších logických závislostí, zejména přístupových práv a dalších oprávnění či omezení. L4 switch

Vedle zařízení, označovaných jako "L3 switch", se v praxi můžeme setkat i se zařízeními, označovanými jako "L4 switch". Proč ale ono "L4", resp. "Layer 4", které odpovídá fungování na úrovni transportní vrstvy?

Jde o to, že při rozhodování o dalším směru přenosu paketu na úrovni síťové vrstvy není možné brát do úvahy to, o jaký druh provozu se jedná. Třeba zda jde o přenos emailů (ve světě TCP/IP pomocí protokolu SMTP) , WWW stránek (pomocí protokolu HTTP), o přenos souborů skrze protokol FTP či skrze některý z protokolů sítí P2P apod. Pokud by takovouto informaci směrovače měly, pak by ji mohly využít k odlišnému směrování datových paketů. Například síťové pakety s elektronickou poštou by mohly cestovat jednou cestou, zatímco pakety s WWW stránkami by mohly cestovat jinudy, nebo alespoň s vyšší prioritou.

Jenže nic z toho nejde, a se všemi síťovými pakety musí směrovače i "L3 switch-e" nakládat stejně - protože na úrovni linkové vrstvy není poznat, které aplikaci patří jejich obsah. Na síťové vrstvě lze poznat pouze to, kterému transportnímu protokolu patří obsah síťového paketu. Tak například ve světě TCP/IP lze z IP paketů poznat, zda jejich obsah patří transportnímu protokolu UDP či TCP - ale už ne to, kterému aplikačnímu protokolu patří obsah UDP datagramu či TCP segmentu.

K rozpoznání emailů od webových stránek a dat dalších aplikací je nutné se dostat alespoň na transportní vrstvu, kde již jsou potřebné informace dostupné. Konkrétně, v prostředí TCP/IP, jde o čísla tzv. portů. Právě ona totiž slouží k určení aplikace, která si má přijímaná data převzít (resp. k určení aplikace, která je na straně odesilatele generovala). Tak například data, představující HTML kód WWW stránek, lze poznat podle portu číslo 80 (na straně odesilatele), protože právě tento port používají WWW servery. Naopak elektronickou poštu lze poznat podle portu či 25, přenos pomocí FTP podle portu 20 atd.

Zpět ale k původní otázce ohledně zařízení "L4 switch": jsou to taková zařízení, která manipulují s přenášenými pakety stále na úrovni síťové vrstvy, ale při svém rozhodování se již "dívají" až na transportní vrstvu (4. odspodu, počítáno v rámci referenčního modelu ISO/OSI), konkrétně na čísla portů, a podle nich se rozhodují.

L4/7 switch, content switch

Za určitých okolností však ke korektnímu rozpoznání aplikačního provozu nestačí ani "dívat se" na transportní vrstvu a rozhodovat se podle čísel portů. Třeba proto, že obvyklá konvence o využití tzv. dobře známých portů (well know ports) nemusí být vždy a za všech okolností dodržována. Například WWW server může být z určitého důvodu "posazen" na jiný port než je tradiční port č. 80 (například při nějakém testování). Ovšem L4 switch pak nedokáže identifikovat příslušná data jako www stránky.

Představa rozkládání zátěže (load balancing) mezi více WWW serverů

Jindy naopak i L4 switch dokáže správně rozpoznat druh provozu, ale stále mu nerozumí natolik, aby s ním dokázal správně naložit. Například pokud bychom se pomocí zařízení L4 switch pokoušeli o tzv. load balancing, neboli o rozložení zátěže mezi několik (jinak identických) WWW serverů, nechali bychom toto zařízení, aby podle momentální zátěže rozdělovalo jednotlivé požadavky na WWW stránky mezi ty právě nejméně vytížené WWW servery. Ovšem takovéto zařízení, které by se "dívalo" jen na čísla portů, by nedokázalo rozpoznat situace, kdy nejde jednotlivé požadavky libovolně "rozhazovat" mezi WWW servery, ale kdy je třena zachovat určitou kontinuitu (a další požadavky v rámci jedné a téže relace směrovat ke stejnému serveru). To je zapotřebí například při persistentních relacích protokolu HTTP verze 1.0, nebo použití tzv. Session ID, při zabezpečené komunikaci pomocí protokolu HTTPS, i v některých dalších případech, které již přesahují rámec tohoto textu. Pro nás je zde podstatné spíše ponaučení, že ne vždy lze vystačit jen s "díváním se" na transportní vrstvu. Někdy je zapotřebí analyzovat celý provoz až na aplikační vrstvě (sedmé odspodu, v rámci referenčního modelu ISO/OSI). Je to samozřejmě již značně náročné, ale existují i taková zařízení, která to dokáží. Říká se jim příhodně: L7 switch.

Častěji se ale můžeme setkat i s označením L4/7 switch, naznačující že jsou využívány informace z obou nejvyšších vrstev TCP/IP (ale při jejich počítání dle sedmivrstvého modelu ISO/OSI). Někdy se ve stejném kontextu používá také pojem "content switch" (doslova: přepínač, řídící se obsahem). Případně i "web switch", což už ale je zaměřeno specificky jen na sledování přenosu www stránek.

Snad žádná jiná přenosová technologie linkové vrstvy neměla v praxi takový úspěch a nedočkala se takového nasazení, jako Ethernet. Vděčí za to kombinaci několika faktorů, včetně své jednoduchosti a přímočarosti, a také rozumnému přístupu svých původních autorů, včasné standardizaci a brzkému "otevření". Dnes už Ethernet přerostl z prostředí lokálních sítí až do sítí metropolitních i sítí rozlehlých. Přitom také podstatně zrychlil, z původních deseti megabitů za sekundu nejnověji na tisícinásobek, na deset gigabitů.

Ethernet je technologií, která z pohledu sedmivrstvého referenčního modelu ISO/OSI patří na linkovou vrstvu, neboť se zabývá přenosem rámců mezi uzly, které spolu přímo sousedí. Zasahuje ale i do vrstvy fyzické, neboť má své vlastní představy o tom, jak se mají přenášet jednotlivé bity. V rámci rodiny protokolů TCP/IP je zařazení Ethernetu ještě jednodušší, protože zde je pro "vše pod síťovou vrstvou" vyhrazena jen jedna vrstva, a to vrstva síťového rozhraní.

Zařazení Ethernetu do sedmivrstvého modelu ISO/OSI a do síťového modelu TCP/IP

Ethernet přitom dokáže velmi dobře spolupracovat právě s protokoly TCP/IP. Má totiž velmi podobnou filosofii jako protokol IP, který se v rámci protokolů TCP/IP používá na síťové vrstvě - a je právě tím síťovým protokolem, který je asi nejčastěji vkládán do Ethernetových rámců. Oba protokoly, tedy jak Ethernet, tak i IP, jsou totiž záměrně koncipovány jako jednoduché a přímočaré protokoly, soustředěné "na svůj hlavní byznys". Ten vykonávají velmi efektivně, a už si příliš nelámou hlavu s tím, co se má stát v různých "krajních situacích".

U Ethernetu je to třeba situace, kdy je více uzlů připojeno k jednomu společně sdílenému segmentu (viz obrázek), a dva či více uzlů by chtěly začít vysílat a odesílat své rámce. To ale nejde, a tak se Ethernet pokouší mezi nimi vybrat jednoho, který by vysílal (a ostatní by počkali). Dělá to ale v zásadě tak, že si jakoby hodí kostkou (neboli: použije náhodný faktor), a podle výsledku vybírá. Je to jednoduché, rychlé a také snadno implementovatelné, a navíc to v drtivé většině situací bohatě postačuje a funguje zcela bez problémů. Ale z pohledu jednotlivých uzlů použití náhody (nedeterminismu) znamená, že chování Ethernetu není dopředu přesně predikovatelné, a jednotlivé uzly nemají žádnou jistotu, že se vůbec dostanou "ke slovu" (že budou moci odeslat svůj rámec). Mohou počítat pouze s pravděpodobností, která se tím více blíží jistotě, čím menší je provoz v daném segmentu. Ale nikdy nejde o skutečnou jistotu.

Právě naznačený nedeterminismus (použití náhodného prvku) je v Ethernetu hluboce zakořeněn a dodnes jej činí nezpůsobilý pro využití tam, kde je požadována garantovaná odezva v reálném čase (jako například při řízení výroby). Na druhou stranu pro drtivou většinu ostatních aplikací, jako třeba pro "kancelářské", "domácí" či "školní" využití vyhovuje více než dobře, a dokáže zde uplatnit již zmiňované přednosti (jednoduchost, přímočarost, rychlost, i snadnost implementace, a s ní spojenou nízkou cenu). Podobně síťový protokol IP také ve většině případů "stíhá" přenášet síťové pakety, ale pokud zátěž přeroste jeho možnosti, moc si s tím hlavu neláme, "přebývající" pakety zahazuje a pokračuje dál.

Určitá podobnost mezi Ethernetem a protokolem IP z rodiny protokolů TCP/IP přitom není úplně náhodná. Mezi autory obou řešení totiž existuje vazba, v osobě Roberta Metcalfa, o kterém jsme se v tomto seriálu již také jednou zmiňovali (v 17. dílu tohoto seriálu, v souvislosti s tzv. Metcalfovým zákonem). Právě Robert Metcalfe totiž vedl skupinu, která "vynalezla" Ethernet - a současně byl členem skupiny, která pod vedením Vintona Cerfa navrhovala samotné protokoly TCP/IP. Snad i proto Ethernet tak báječně "pasuje" k protokolu IP.

Jak se zrodil Ethernet?

Pojďme tedy k historii Ethernetu jako takového. Ta se začala psát počátkem sedmdesátých let minulého století ve vědeckovýzkumném středisku PARC (Palo Alto Research Center) v Kalifornii v USA, který patřil společnosti Xerox. Zde se zrodila celá řada vynikajících nápadů a inovací, jako třeba grafické uživatelské rozhraní (GUI), režim WYSIWYG (What You See Is What You Get), či objektově orientované programování (OOP), RAID či laserový tisk apod. A také se zde zrodily první pracovní stanice, příznačně pojmenované Alto, které byly jakýmsi předstupněm pro pozdější osobní počítače standardu IBM PC. Už tyto pracovní stanice totiž měly značně "osobní" charakter, a mohly být vyhrazeny jednotlivým uživatelům.

Právě pracovním stanicím Alto pak Ethernet vděčí za svůj vznik. Ve středisku PARC jich vyrobili větší počet, načež vnikla potřeba propojit je mezi sebou. Ale vzhledem k jejich počtu to už nešlo udělat tak, jak bylo v té době zvykem pro rozlehlé sítě s několika málo počítači - pomocí dvoubodových spojů, víceméně ad hoc způsobem. A tak vzniklo nové zadání: vyvinout vhodnou technologii, která by jednoduchým a systematickým způsobem propojila větší počet uzlů, nacházejících se velmi blízko sebe, typicky v jedné budově.

Do řešení tohoto úkolu se nakonec pustila skupinka inženýrů, soustředěná kolem Roberta Metcalfa. Navrhla propojit pracovní stanice Alto stylem "do sběrnice", přes jeden segment koaxiálního kabelu, sdílený všemi stanicemi. Mělo to výhodu v tom, že když jeden uzel něco vysílal do tohoto společně sdíleného přenosového média, "slyšely" to současně všechny ostatní uzly a mohly jeho vysílání přijímat. Právě kvůli této vlastnosti - kvůli tomu, že vysílání jednoho uzlu "pronikalo všude", ke všem uzlům - pak Ethernet dostal také své jméno (podrobněji viz samostatný box).

Představa topologie "do sběrnice", využívající sdílené přenosové médium

Proč se Ethernet jmenuje Ethernet?Když v 19. století položil James Clerk Maxwell základy teorie elektromagnetické pole, fyzikům přišlo divné, jak se mohou elektromagnetické vlny šířit i vakuem, kde vlastně "nic není". A tak přišli s pracovní hypotézou, která říkala že i ve vakuu přeci jen "něco je". Jakási všeprostupující substance, kterou nazvali "éter", a skrze kterou by se elektromagnetické vlny mohly šířit i ve vakuu. Poměrně záhy si ale fyzikové tuto hypotézu sami vyvrátili. Známý Michelson-Morleyův pokus dokázal, že "všeprostupující éter" nemůže existovat. A tak se s ním ve fyzice přestalo počítat. Nicméně samotné slůvko "éter" jakoby přežilo, a dodnes se neformálně používá pro označení toho, skrze co se šíří bezdrátové vysílání. Hovoří se například o "vysílání éterem", či o "zaplněném éteru" apod. No a stejně tak si na původní éter vzpomněl i Robert Metcalfe, když měl v roce 1974 nějak pojmenovat to, co vznikalo pod jeho vedení. Stará a velmi záhy vyvrácená hypotéza o éteru ho inspirovala hlavně kvůli všesměrovému způsobu šíření signálu v rámci sběrnicové topologie, kterou on a jeho lidé propojili pracovní stanice Alto. A tak se zrodilo jméno Ethernet, pro jakousi "éterovou síť". Dokonce se z té doby zachoval ještě i Metcalfův pracovní náčrtek, na kterém je sdílené médium (konkrétně koaxiální kabel) explicitně označeno jako éter.

DIX Ethernet

První verze Ethernetu, která spatřila světlo světa ve středisku PARC a skutečně propojovala pracovní stanice Alto, pracovala s přenosovou rychlostí 2,94 Mbit/s, odvozenou od rychlosti procesorů stanic Alto. Ale to ještě zdaleka nebyla ta verze Ethernetu, která doslova dobila svět. Na té museli ve středisku PARC ještě trochu zapracovat, a také ji zrychlit, na rovných 10 megabitů za sekundu. Ale to už se do vývojových přípravných prací zapojily i další subjekty, respektive jejich odborníci. Kromě samotné firmy Xerox se tak na vývoji Ethernetu podílely také společnosti Intel, a DEC (Digital Equipment Corporation). Seřazeno podle abecedy je to trojice DEC, Intel a Xerox, zkratkou DIX. Proto se také o prvních verzích Ethernetu mluvilo a mluví jako o "DIX Ethernetu".

Otevření a standardizace

Všechny tři společnosti, které se na vývoji Ethernetu podílely, si mohly výsledné řešení "nechat pro sebe", jako své vlastní a proprietární, a proti eventuelnímu okopírování jej chránit například patentováním. Pravdou je, že ještě než byly "přizvány do hry" i společnosti DEC a Intel, nechal si Xerox vznikající Ethernet patentovat, a také si zaregistroval samotné jméno Ethernet jako svou chráněnou známku. Patent na "vícebodový komunikační systém s detekcí kolizí" (Multipoint data communication system with collision detection) Xerox podal 31. března 1975. Ovšem ještě než byl tento patent přijat (13.12.1977, jako US Patent #4,063,220, podařilo se Robertu Metcalfovi přesvědčit společnost Xerox, aby vznikající Ethernet neuzavírala a nedělala z něj proprietární technologii, kterou by mohla vyrábět a prodávat právě a pouze ona a nikdo jiný. Pravdou je, že takto by se Ethernet téměř jistě nedočkal takového rozšíření, jaké má dnes. Místo toho Xerox souhlasil jak s tím, že "vezme do hry" další subjekty (DEC a Intel), tak i s tím, že celé vznikající řešení "otevře", zveřejní, a dokonce nechá standardizovat, tj. vydat jako standard.

Jen pro srovnání: Ethernet nebyl jedinou technologií svého druhu, která v uvedené době vznikala, s cílem propojit systematickým způsobem a na malou vzdálenost větší počty uzlů. Jiným příkladem byla technologie Token Ring, kterou vyvíjela společnost IBM. Ta ji ale tak dlouho držela "pod pokličkou", chránila si ji jako své proprietární řešení a odmítala ji náležitě otevřít, až bylo příliš pozdě a Ethernet konkurenční Token Ring jednoznačně převálcoval. Ethernet II vs. IEEE 802.3

Vývoj Ethernetu probíhal prakticky celá sedmdesátá léta. Teprve s blížícím se rokem 1980 usoudili vývojáři ve středisku PARC, že jejich dílo je dostatečně připravené a vyzrálé na to, aby se specifikace Ethernetu mohli předat ke standardizaci. K té si vybrali organizaci IEEE (Institute of Electrical and Electronics Engineers), která se právě počátkem roku 1980 začala zabývat standardizací v oblasti lokálních sítí (sítí LAN). Za tímto účelem také IEEE zřídila svou pracovní skupinu, kterou označila číslem 802 (kde "80" reprezentovalo poslední dvě číslice roku založení, a zbývající číslice "2" odpovídala měsíci - únoru).

Pracovní skupina IEEE 802 si k projednání návrhu na standardizaci Ethernetu vytvořila zvláštní podskupinu, dodnes označovanou jako IEEE 802.3. Ta začala návrh DIX Ethernetu skutečně posuzovat, ale měla k němu určité připomínky, vyžádala si provedení určitých změn v celém návrhu - a s tím návrh vrátila autorům.

Některé z připomínek byly spíše kosmetické, ale jiné už nikoli - a autoři DIX Ethernetu akceptovali jen některé ze vznesených připomínek. Vznikla tak druhá verze DIX Ethernetu, dodnes označovaná jako Ethernet II.

Jenže tato nová verze (Ethernet II) stále nesplňovala všechny představy standardizační pracovní skupiny IEEE 802.3, a ta nakonec (v roce 1983) vydala jako standard něco opět jiného, upraveného podle vlastních představ. A tak se stalo, že náhle existovaly dvě různé verze Ethernetu.

Verze, která byla nakonec vydána jako standard (IEEE 802.3), navíc formálně ani nemohla být pojmenována jako Ethernet. To kvůli tomu, že v té době již měla jméno Ethernet registrované jako svou chráněnou značku společnost Xerox. Proto standardy IEEE 802.3 používají poněkud krkolomné označení sítí "na bázi CSMA/CD". To podle označení přístupové metody, který je pro Ethernet tak charakteristická.

Rozdíl je v rámcíchRozdílů mezi Ethernetem II a standardem IEEE 802.3 ("síť na bázi CSMA/CD") je více, ale nejvýznamnější je asi odlišný formát linkových rámců u obou verzí.

Obecná struktura ethernetového linkového rámce

Obr. Obě verze mají v prvních 12 bytech dvě 48-bitové (ethernetové) adresy, patřící odesilateli a příjemci daného rámce. V tomto se tedy neliší. Rozdíl je až v dalších dvou bytech. V případě Ethernetu II je zde specifikace toho, co je "v nákladové části" rámce. Jde o údaj, kterému se říká "EtherType", a jeho (používané) hodnoty jsou vyšší než 1500. Podle Ethertypu pak příjemce, který "vybaluje" obsah přijatého rámce, pozná komu tento obsah patří. Například pro protokol IP, jehož pakety jsou do ethernetových rámců vkládány asi nejčastěji, je Ethertype roven 0800 (hexadecimálně), resp. 2048 dekadicky. Naproti tomu verze IEEE 802.3 má ve stejných dvou bytech jiný údaj, a sice velikost rámce, počítanou v bytech. Přesněji: velikost nákladové části rámce, bez započítání hlavičky rámce a jeho patičky se zabezpečovacím údajem (tzv. CRC). Zajímavou otázkou určitě je, zda oba druhy Ethernetových rámců mohou koexistovat vedle sebe. Tedy zda příjemce může vždy spolehlivě poznat, zda právě přijal jeden či druhý typ rámce. Odpověď na tuto otázku je naštěstí kladná, a to díky tomu, že velikost Ethernetových rámců nepřesahuje 1500 bytů "užitečného nákladu". A tak se lze orientovat podle hodnoty obsažené v příslušných dvou bytech: pokud je větší než 1500, jde o rámec Ethernet II. Jinak o rámec IEEE 802.3, viz obrázek. Oba typy rámců se přitom používají dodnes. Vedle nich se dokonce používaly ještě dva další typy ethernetových linkových rámců, a to "raw 802.3", a 802.3 SNAP". I ty bylo a stále je možné rozlišit, podle konkrétních hodnot v jejich hlavičce, viz obrázek.

Srovnání ethernetových rámců

Další vývoj Ethernetu

Další vývoj Ethernetu se již odehrával výlučně "po linii" standardizované verze IEEE 802.3, zatímco paralelní DIX Ethernet (resp. Ethernet II) se již dále nevyvíjel. Neznamená to ale, že by Ethernet II byl dnes úplně mrtvý a už jsme se s ním již nemohli nikde setkat. Alespoň něco se z něj totiž stále ještě používá, a to formát linkových rámců (viz samostatný box). Je oblíbený zejména na Uniových platformách.

Pro verze Ethernetu, standardizované v rámci IEEE 802.3 (tedy vlastně "pro sítě na bázi CSMA/CD) se záhy začalo používat také jiné označení. Například první standardizovaná verze je dodnes známá jako "10Base5", kde

číslo 10 znamená rychlost (už šlo o 10 Mbit/s), a číslice 5 značí dosah (ve stovkách metrů). Slůvko "Base" uprostřed celého označení pak říkalo, že jde o přenos tzv. v základním pásmu (Baseband), což fakticky znamenalo že jde o přenos který není modulován (tj. nepoužívá nějakou nosnou harmonickou frekvenci, jejíž modulací by se vyjadřovala přenášená data). Pravdou je, že se časem objevila i verze 10 Broad36, která dosahovala stejné rychlosti 10 Mbit/s, dokonce na vzdálenost 3,6 kilometru, ale po "televizním" koaxiálním kabelu a právě díky použití modulovaného přenosu. Ovšem tato verze je, i přes určité pozdější snahy o její vzkříšení, dnes úplně mrtvá.

Koaxiální Ethernet

Vraťme se tedy k verzi 10Broad5, která měla dosah až 500 metrů. Využívala přitom tzv. tlustý koaxiální kabel, s průměrem 1 cm. Ten měl často žlutou barvu (jakoby podle původního Metcalfova obrázku, viz výše), a tak se mu někdy říkalo i "Yellowcable" (doslova: žlutý kabel).

Tlustý koaxiální kabel byl ale dosti drahý, a také velmi málo ohebný. Ohnout jej do pravého úhlu, například kolem nějakého rohu stěny, bylo nemožné. Naštěstí ale tento kabel nemusel vést k samotným uzlům, protože se na něm daly dělat odbočky, prostřednictvím tzv. transceiverů. Koncové uzly se pak připojovaly až k tzv. drop kabelům, které mohly být až 50 metrů dlouhé, viz obrázek.

Představa připojování uzlů k Ethernetu 10Base5

Nevýhody první verze Ethernetu částečně odstranila verze další, označovaná jako 10Base2. Používala již tenčí koaxiální kabel (o polovičním průměru), a číslice 2 odpovídala tomu, že jeho dosah byl jen 200 metrů. Vlastně až po zaokrouhlení, protož přesně to bylo jen 185 metrů. Navíc reálný dosah byl ještě menší, protože u této verze se na kabelu nedělaly odbočky, ale musel se "dotáhnout" až k síťové kartě, kde byl teprve rozbočen prostřednictvím speciálního konektoru ve tvaru písmene T. Vše naznačuje obrázek.

Představa připojování uzlů k Ethernetu 10Base2

Konektory T a BNC pro Ethernet 10Base2

Ethernet na kroucené dvoulinceKoaxiální kabel byl přenosovým médiem, na kterém Ethernet doslova "vyrostl", a podle kterého se také zformovala jeho celková koncepce. Zejména sdílený charakter koaxiálního kabelu, coby přenosového média, na dlouho předznamenal jeho vlastnosti, i chování jeho přístupové metody. Jenže ani koaxiální kabel nevydržel Ethernetu navždy. Alternativou, která časem koaxiální kabel úplně nahradila, byla tzv. kroucená dvoulinka (anglicky: twisted pair, zkráceně "twist"). Tedy dvojice souběžně vedených vodičů, které jsou pravidelně zkrouceny kvůli tomu, aby se minimalizovalo jejich vyzařování i citlivost na vnější elektromagnetického pole (tj. efekt antény).

Důvod, proč Ethernet přešel na kroucenou dvoulinku, úzce souvisí s tím, jak se v USA budovaly nejrůznější objekty. Tak, že se v nich dopředu instalovaly rozvody pro potřeby telefonie, a tyto se značně předimenzovávaly. Když se pak měly někde instalovat ještě další (koaxiální) kabelové rozvody pro potřeby Ethernetu, lidi zákonitě napadlo: a nemohl by Ethernet místo koaxiálních kabelů používat právě kroucenou dvoulinku, která "už je natažená"?

No, chvíli to trvalo a dalo to určitou práci, ale nakonec se to podařilo: na světě byl standard, který umožňoval fungování Ethernetu po (telefonní) kroucené dvoulince. Příslušné řešení se dodnes označuje jako 10BaseT, a na jeho konci už není číslice ale písmenko T, znamenající "twist". Možná je tomu tak proto, aby nemusela být na konci jen malá jednička. Dosah se totiž také zkrátil, a to na pouhých 100 metrů. Navíc kroucená dvoulinka je v jednom ohledu principiálně odlišná od koaxiálního kabelu: nejdou na ní dělat žádné odbočky, a tak ji lze použít jen pro dvoubodové spoje (tj. jen pro vzájemné propojení dvou uzlů). Jenže na to Ethenret nebyl zvyklý, a předpokládal naopak

sdílené propojení více uzlů stylem "do sběrnice" (viz výše). A tak se místo odboček na kabelu muselo použít rozvětvení pomocí elektronických obvodů, soustředěných do "krabičky", označované příznačně jako rozbočovač (anglicky: hub).

Představa připojování uzlů k Ethernetu 10BaseT

Ani desetimegabitový Ethernet na kroucené dvoulince (10BaseT) však nebyl zdaleka posledním slovem Ethernetu. Ten se s postupem času dočkal dalších podstatných inovací. Například postupného zrychlování, nejprve na 100 Mbit/s, pak na 1 Gbit/s, a nově i na 10 Gbit/s. Stále častěji se přitom začalo přecházet z kroucené dvoulinky na optická vlákna, která skýtala podstatně větší přenosový potenciál.

Jenže brzdou ve zvětšování dosahu Ethernetu byla jeho přístupová metoda (CSMA/CD), jejíž fungování neumožňovalo dosahovat větších vzdáleností ani na optických vláknech. A tak časem vzala za své i tato přístupová metoda, pro Ethernet dříve tak charakteristická. U gigabitového Ethernetu ještě nebyla odstraněna úplně (protože zde stále existuje varianta kde se využívá), ale u desetigigabitového Ethernetu už vzala definitivně dostala vale.

Bez ní sice Ethernet může fungovat jen na dvoubodových spojích, bez opakovačů a jen plně duplexně (neboli tak, aby obě strany mohly vysílat "proti sobě" a souběžně). Ale na oplátku může Ethernet v této podobě dosáhnout na podstatně větší vzdálenosti, třeba i desítky kilometrů. Vlastně už ztratil nějaké principiální omezení na dosah, a ten už dán jen fyzikálními vlastnostmi použitého přenosového média (hlavně jeho útlumem).

Před Ethernetem se tak doslova otevřel zcela nový svět. Původně totiž vznikl jako technologie jen pro lokální sítě (sítě LAN), umožňující propojení jen na krátké vzdálenosti. Ale když s postupem času ztratil svá omezení na dosah, mohl náhle vstoupit do sítí metropolitních, a dokonce i do sítí rozlehlých. Najednou se pak začalo hovořit i o "metropolitním Ethernetu", o "Ethernetu pro operátory" a o dalších jeho mutacích a variantách.