Báječný svět počítačových sítí. Část třetí síťové architektury

Ve světě počítačových sítí existuje hned několik ucelených „světonázorů“,
neboli celkových pohledů na to, jak by vlastně celá síť měla být koncipována,

jak by měla fungovat a jaké služby by měla poskytovat. Jde vlastně o celé

síťové architektury, které se mohou v mnohém lišit. Jinak se na svět dívá tzv.

referenční model ISO/OSI, jinak zase rodina protokolů TCP/IP, která je dnes asi

nejrozšířenější síťovou architekturou.



Navrhnout a realizovat 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, 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

části jiné. 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ých vrstev má být, co a jak

mají dělat, jak mají fungovat atd. právě v tom se jednotlivé síťové

architektury liší.

Až se záhy dostaneme k tzv. referenčnímu modelu ISO/OSI, zjistíme, že

předpokládá 7 vrstev. Naopak rodina protokolů TCP/IP, na níž 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 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é, ž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 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 mohou 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, 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, 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. 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é plní. 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í, aby se přenášená data dostala až ke

svému cíli. Další vrstva pak rozumí přenášeným datům a zajišťuje fungování

služeb jako elektronická pošta či WWW.

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 nabízí 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.

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 i 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 co protokol, to vrstva a naopak. Jedna vrstva může ke svému fungování

využívat více protokolů, a to i souběžně. Například na jedné vrstvě

(transportní, viz dále) se mohou používat dva různé protokoly, jeden pro

spolehlivý přenos (zabezpečený proti ztrátám a poškození dat), druhý

nespolehlivý (který takto zabezpečen není). 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 předem,

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 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 a přesto si

musí hned napoprvé dobře porozumět. Musí tedy příslušný protokol znát

„odjinud“, a to v jeho definitivní a „závazné“ podobě. Takovouto „předem

známou“ podobu protokolů nabízí 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 instrukce týkající se toho, co se s 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, na obálce je napsá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í 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ě…

Takto vše pokračuje, dokud se obálka nedostane až k nejnižší vrstvě. Teprve ta

totiž něco fakticky přenáší vezme tedy obálku od druhé nejnižší vrstvy

(fakticky určitý blok dat) a celou ji předá, bit po bitu, druhé straně.



Síťové architektury



Pokud 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, dnes jednoznačně nejrozšířenější a

nejpoužívanější. Rozhodně ale není síťovou architekturou jedinou.

Síťové architektury se objevily 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 nikoliv proprietárního, čemu by „nevelela“ jen

jedna firma, ale co by bylo naopak dostatečně otevřené.



Geneze referenčního modelu ISO/OSI



Úkolu vypracovat otevřenou síťovou architekturu se nakonec chopila organizace

ISO (International Organization for Standardization). Ta pochází spíše ze světa

spojů, je mezinárodní organizací pro normalizaci s formálním mandátem od

jednotlivých členských zemí, 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 formuluje 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 vzájemném propojení. Výsledkem byla

i změna názvu toho, co mělo vzniknout. Nyní už šlo o „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

slevit ještě jednou. Připravila sice představu o počtu vrstev a jejich úkolech,

ale již nestihla včas vymyslet jednotlivé protokoly, které by jednotlivé vrstvy

používaly. Proto nakonec zredukovala 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, OSIA) muselo zmizet slovo „Architecture“. Tak

vznikl konečný název Open Systems Interconnection, 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 vznikala u zeleného stolu,

bez kontaktu s realitou a bez respektování toho, co a jak se dá prakticky

implementovat a co se také implementovat vyplatí 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 obsahovat. Když už je nic dalšího

nenapadalo, vše sečetli a udělali z toho závazný standard. Teprve následně (a

často to byli jiní lidé) se začali zamýšlet nad tím, zda a jak by šlo vše

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… než se ale našly a prosadily 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 v souboji s protokoly TCP/IP prohrál (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 ani nemá smysl se zmiňovat. To

určitě ne. Některé z protokolů, které byly vyvinuty pro ISO/OSI a (dodatečně)

dosazeny do jeho referenčního modelu, se skutečně používaly 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. Protokol X.500 zase

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 referenční model ISO/OSI a to hlavně jeho vrstvový model je dodnes

základem pro většinu učebních textů, jež 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 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ň

interpretují, snaží se tedy vycházet vstříc potřebám jednotlivých aplikací.

Mezi těmito dvěma trojicemi pak existuje ještě jedna vrstva, která má fungovat

jako jakési přizpůsobení, resp. přizpůsobovací vrstva.

Jen pro srovnání rodina protokolů TCP/IP má pouze čtyři vrstvy a také si 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 na přenášeném médiu znázorněny zda a jak jsou kódovány či modulovány, jak

je vyř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. Bere se v úvahu 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áší, 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 musí zajistit korektní rozpoznání

začátku i konce každého jednotlivého rámce.

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, s nimiž má přímé spojení (a nikoli takové, které vede

zprostředkovaně přes jiný uzel). Lze si to představit i 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.

Na linkovou vrstvu však mohou být kladeny ještě kromě samotného přenosu

linkových rámců další požadavky. 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.

Po linkové vrstvě může být také požadováno, aby zajišťovala spolehlivý přenos

tedy aby kontrolovala, zda při přenosu nedošlo k nějaké chybě. 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 tedy 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ů jako na obrázku. Velmi brzy se ale na scéně objevily také lokální sítě

(LAN), které mají sdílenou topologii, protože používají sdílené přenosové

médium. Tedy takové, k ně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 „promíchání“ signálů od více

vysílajících uzlů.

V takových 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:

l(vyšší) podvrstvu řízení linkového spoje (podvrstvu LLC, z anglického Logical

Link Control), která dělá v zásadě vše, co původní linková vrstva,

l(nižší) podvrstvu řízení přístupu ke sdílenému médiu (podvrstvu MAC, z

anglického Media Access Control), jež implementuje přístupovou metodu.



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 přes mezilehlé uzly, do dalších sítí.

To už ale má za úkol vrstva síťová. Blokům dat, které přenáší, se říká pakety

(anglicky packets). 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.

Metod, jak hledat nejvhodnější cestu k cílovému uzlu, existuje celá řada a

jejich podrobnější popis 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, jež vedou z

daného uzlu (kromě příchozího směru). Tím sice vznikají duplicitní pakety,

které je třeba následně eliminovat, ale je zaručené, že se „záplava“ dříve či

později dostane ke svému cíli.

Promyšlenější algoritmy směrování hledají cestu k cílovému uzlu jinak, 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.



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 uzlech

mezilehlých, propojujících jednotlivé 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 případných chyb při přenosu), zatímco vyšší vrstvy požadují

spolehlivý přenos. Nižší vrstvy také fungují tzv. nespojovaně (nenavazují

spojení na začátku přenosu), zatímco vyšší vrstvy naopak chtějí fungovat

spojovaně.

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. UDP nemění

způsob fungování protokolu IP (také funguje nespojovaně a nespolehlivě), ale

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, rozlišování různých

příjemců a odesilatelů v rámci každé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é 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.

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ě 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,

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é funkce buď nejsou vůbec zapotřební, nebo sice

zapotřebí jsou, ale stejně si je vyšší vrstvy (hlavně vrstva aplikační) zajistí

podle svého.



Prezentační vrstva



Prezentační vrstva má již 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, čísel s plovoucí desetinnou

čárkou (a obecně pro všechny datové struktury), případně pro pouhé uložení

vícebitových dat v paměti. I zde existují dvě různé konvence (označované jako

Little Endian a Big Endian), mezi nimiž je třeba řádně rozlišovat.

Pokud se 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 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. V praxi by všechna okénka musela být

stejná (standardizovaná), stejné (standardizované) by musely být i 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á smysl standardizovat a tím podřídit společným konvencím, 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í, tisku,

odpovídání atd. zajišťuje část aplikace, která již je „nad“ aplikační vrstvou a

tudíž již nemusí být standardizována.