pro návrat na domovskou stránku klikni
tiráž článku
Vyšlo v týdeníku CHIPweek č. 27/96, 2. července 1996
Modul: Referenční model ISO/OSI>
v rámci seriálu Principy počítačových sítí
díl/část č.: 5

předchozí část  |  první část  |  další část
Rok: 1996
Měsíc: 27
Den: 01
sdílení a tisk
související články

Dělba práce v RM ISO/OSI (II.)

Nejspodnější tři ze sedmi vrstev referenčního modelu ISO/OSI jsou orientovány na přenos dat. Naproti tomu tři nejvyšší vrstvy mají za úkol vycházet vstříc jednotlivým aplikacím a poskytovat jim podpůrné služby. Ale jaké služby to vlastně jsou? A jaký význam má zbývající vrstva, vsazená mezi obě skupiny po třech vrstvách?

Začněme nejprve onou vrstvou „mezi", tedy čtvrtou vrstvou počítáno od spodu i od shora, neboli vrstvou transportní. Její poslání lze shrnout následovně: je zde od toho, aby vyrovnávala rozdíly mezi schopnostmi tří spodních přenosových vrstev a požadavky tří vyšších, aplikačně orientovaných vrstev. Tedy například to, aby z nespolehlivých přenosových služeb, jaké nabízí přenosový subsystém tvořený třemi nejnižšími vrstvami, vyrobila spolehlivou službou, jakou požadují horní, aplikačně orientované vrstvy. Či aby z nedostatečně spolehlivé služby vyrobila službu více spolehlivou. Nebo aby z nespojovaných přenosových služeb udělala služby spojované, pokud je vyšší vrstvy preferují před službami spojovanými.

Proč je ale něco takového vůbec zapotřebí? Když budou vyšší vrstvy požadovat určitý druh přenosových služeb, proč se tomuto požadavku raději nepřizpůsobí rovnou tři nejnižší přenosové vrstvy, a proč se místo toho ještě zavádí další čtvrtá vrstva, která má rozdíly zakrýt? Jednou možnou odpovědí je to, že „provozovatel" vyšších vrstev nemusí mít možnost ovlivnit chování a vlastnosti tří nejnižších vrstev - představme si to na příkladu využití veřejné datové sítě. Jejím uživatelem je někdo jiný než její provozovatel, a jednotliví uživatelé zde nemají většinou moc šancí mluvit do toho, jak veřejná datová síť (zajišťující funkci tří nejnižších vrstev ISO/OSI) funguje a jaké služby nabízí. Navíc, kdyby jejich požadavky byly protichůdné, ani by nebylo možné vyhovět jim všem současně. Uživatelé si proto mohou pouze „zakoupit" takové přenosové služby, jaké jim jsou nabízeny, a pokud chtějí něco jiného, musí si to upravit sami - a právě od toho je zde vrstva transportní.

Transportní vrstva zajišťuje komunikaci koncových uzlů

Představa veřejné datové sítě, do které uživatelé nejen „nemohou mluvit", ale do které obvykle ani „nevidí", nám přichází vhod i při zdůraznění dalšího důležitého aspektu transportní vrstvy: tato je implementována až v koncových uzlech, a nikoli v „přestupních uzlech" v rámci přenosové části sítě (tedy například „uvnitř" veřejné datové sítě). Je to tedy vrstva, která se může zabývat pouze vzájemnou komunikací koncových uzlů, neboli koncových účastníků komunikace, a netýká se „přestupních uzlů". Transportní vrstvu tedy najdeme v koncových počítačích, ale nikoli již ve směrovačích (routerech), mostech či dokonce opakovačích.

S právě naznačeným charakterem transportní vrstvy, vyskytující se až na koncových uzlech a nikoli v uzlech „přestupních", pak souvisí ještě jeden další a nesmírně důležitý aspekt: tři nejnižší, přenosově orientované vrstvy, chápou všechny uzly sítě jako dále nedělitelné celky. To znamená, že pokud někam doručí nějaká data, doručí je vždy uzlu jako takovému. Zde ale tato data mohou mít mnoho různých příjemců - mohou patřit různým programům, procesům či úlohám, které na tomto uzlu právě běží nebo alespoň běžet mají. Po třech nejnižších vrstvách tedy musí nastoupit někdo, kdo data doručená uzlu jako takovému převezme, zjistí komu patří a zařídí jejich cílené předání konkrétnímu příjemci v rámci daného uzlu. No a i to je úkolem transportní vrstvy.

Co jsou relace?

Nejnižší ze tří aplikačně orientovaných vrstev RM ISO/OSI je vrstva relační. Její roli by šlo odbýt poukazem na to, že se zabývá vedením relací. Ale co to vlastně taková relace je?

Představme si analogii s telefonním hovorem - jednou vytočený hovor (představující analogii spojení na úrovni transportní vrstvy) můžete využít k dialogu s jedním konkrétním účastníkem na druhé straně, a posléze bez zavěšení předat hovor jiné dvojici (třeba manželkám?), která se bude bavit o něčem jiném. Jednou věcí je tedy existence a trvání telefonního hovoru, a jinou věcí je dialog, který prostřednictvím telefonního hovoru vedete. Za hovor platíte Telecomu, který nezajímá o čem se po telefonu bavíte. Dialog s druhou stranou je zase něco, co pouze uskutečňujete prostřednictvím telefonu, ale co by principiálně mohlo probíhat třeba jako rozhovor z očí do očí, nebo formou dopisování, prostřednictvím vysílaček apod. A naše relace na úrovni relační vrstvy je právě takovýmto dialogem.

Relační vrstva tedy má na starosti vedení relací, resp. řízení jejich průběhu - použijeme-li znovu analogii z dialogem vedeným po telefonu, stará se například o to, aby si účastníci dialogu vzájemně neskákali do řeči. Nebo aby po náhlém výpadku spojení a opětovném vytočení telefonního hovoru nemuseli začínat od začátku, a mohli se vrátit k některému z předchozích bodů - „kdeže jsme to přestali, než to spadlo"?

Pokud vám takto naznačené úkoly relační vrstvy připadají poněkud vágní a nepříliš obsažné, nejste sami. Podobný názor má i většina kritiků referenčního modelu ISO/OSI.

Potřeba konverzí

Prezentační vrstva, pátá počítáno zdola, nebo také prostřední z trojice aplikačně orientovaných vrstev, má již mnohem srozumitelnější a zřetelněji definované úkoly. Ty vychází z pozorování, že když někdo někam přenese určitá data a dá si velmi záležet na tom, aby každý jednotlivý bit došel v přesně takovém tvaru v jakém byl odeslán, nemusí to vůbec být v pořádku. Jedné a téže posloupnosti bitů, bytů či slov totiž mohou různé počítače přisuzovat různý význam. Mohou například používat různé způsoby kódování znaků (jeden kód ASCII, druhý EBCDIC), různé formáty čísel v pohyblivé či pevné řádové čárce, obecně jiné datové formáty. Aby takovéto uzly přenášená data také shodně interpretovaly (tj. přikládaly jim shodný význam), mohou být nezbytné určité konverze. No a ty zajišťuje právě prezentační vrstva.

Prezentační vrstva má však na starosti i některé další, související úkoly - stará se i o správně „zabalení" přenášených dat. Představme si například vícerozměrná pole, záznamy, nebo ještě obecnější datové struktury. Jak takovéto „vícerozměrné" objekty přenést jednorozměrným (lineárním) přenosovým kanálem, který je k dispozici? Zde opět musí nastoupit prezentační vrstva, která na straně odesilatele vícerozměrné objekty přetransformuje na jednorozměrné - ale musí to učinit tak, aby to prezentační vrstva na straně příjemce správně rozpoznala a dokázala „zlinearizovaným datům" dát jejich původní podobu, a hlavně původní význam. Snad nejvíce práce pak má prezentační vrstva s tzv. ukazateli (pointry), které se s oblibou vyskytují v obecnějších datových strukturách (strukturách provázaných těmito pointry) - tyto ukazatele, které ukazují z jednoho místa na jiné místo (ovšem v adresovém prostoru odesilatele!!) nemá vůbec smysl přenášet.

Aplikační vrstva

Obrázek 1.
Čtyři nejvyšší vrstvy ISO/OSI
Původní představa tvůrců RM ISO/OSI ohledně aplikační vrstvy byla taková, že její součástí budou všechny konkrétní aplikace, používané v prostředí sítě. To se ale ukázalo jako neschůdné, zejména z následujícího důvodu: aplikací je hodně, neustále jich přibývá, a pokud by měly být přímo součástí aplikační vrstvy, musely by být pokryty standardy, které by přesně definovaly jejich chování i všechny jejich vlastnosti. No a vyvíjet takové množství standardů bylo nad síly autorů RM ISO/OSI. Navíc by něco takového ani nebylo moc vhodné, protože by to znamenalo například i standardizovat uživatelská rozhraní aplikačních programů, a tím značně svázat ruce a tvůrčí rozlet autorům těchto aplikacím. Proto nakonec v aplikační vrstvě zůstaly jen takové části aplikací, jaké má smysl standardizovat (typicky jejich společné části, zajišťující základní funkčnost - například přenos zpráv u elektronické pošty), zatímco ostatní části (zejména týkající se uživatelského rozhraní) se „vystěhovaly" nad aplikační vrstvu a přestaly být její součástí.


© Jiří Peterka, 2011, profil na Google+