Filosofie TCP/IP (II.)

Celková filosofie síťového modelu TCP/IP je v mnohem odlišná od filosofie referenčního modelu ISO/OSI. Je to způsobeno především skutečností, že autoři TCP/IP vycházeli z poněkud jiných předpokladů než autoři ISO/OSI. Minule jsme se s těmito odlišnými výchozími předpoklady začali seznamovat, a dospěli až na úroveň síťové vrstvy. Dnes se dostaneme dále.

Nejprve si ale připomeňme hlavní myšlenky a nejdůležitější výchozí předpoklady, které se uplatnily již při návrhu nižších vrstev TCP/IP. Šlo zejména o základní princip, který by se dal charakterizovat sloganem „spíše skromnost, než bohatost", a který dával přednost jednodušším, snáze implementovatelným a mnohdy i efektivnějším řešením. V duchu tohoto principu pak autoři TCP/IP učinili následující rozhodnutí:

• na úrovni síťové vrstvy dali přednost rychlému a robustnímu přenosu dat, před přenosem spolehlivým. V důsledku toho zvolili pro síťovou vrstvu přenos nespolehlivý (který je rychlejší, protože se nemusí zdržovat napravováním případných chyb při přenosech), a současně přenos nespojovaného charakteru (který je robustnější než přenos spojovaný, neboť snáze přežije případný výpadek přenosových cest).
• na ještě nižší úrovni akceptovali fakt, že životaschopné přenosové technologie mohou vznikat i mimo rámec TCP/IP, a že je žádoucí je převzít a využít (a nikoli je apriorně odmítat či alespoň formálně začleňovat do rámce TCP/IP jako vlastní standardy). Z tohoto důvodu TCP/IP nijak nepředepisuje, co má být „pod" síťovou vrstvou - sice zde zavádí samostatnou vrstvu, tzv. vrstvu síťového rozhraní, ale tu nijak nenaplňuje.

Autoři TCP/IP koncipovali svou síťovou vrstvu i s ohledem na fakt, že protokoly TCP/IP mohou být nasazovány v prostředí značně heterogenních sítí, kde budou vzájemně propojeny sítě používající velmi různorodé přenosové technologie (na úrovni vrstvy síťového rozhraní). Ovšem síťová vrstva bude mít za úkol všechna jejich specifika zakrýt, a vytvořit nad nimi jednotné prostředí a jednotné přenosové služby. I z tohoto důvodu bylo mnohem rozumnější vydat se při volbě koncepce síťové vrstvy spíše cestou „minima", společného pro všechny.

Transportní vrstva: ať si každý vybere

Když se autoři TCP/IP rozhodli koncipovat síťovou vrstvu jako nespolehlivou, vycházeli také z předpokladu, že zajištění spolehlivosti by mělo být spíše záležitostí koncových uzlů (než přenosové části sítě), a že by se tedy mělo odehrávat na úrovni vyšších vrstev než je vrstva síťová - která musí být implementována ve všech částech přenosové sítě, zatímco vyšší vrstvy se nachází již jen v koncových uzlech. Jako hlavní kandidát na implementování potřebných mechanismů pro zajištění spolehlivosti se samozřejmě nabízela hned další, bezprostředně vyšší vrstva nad vrstvou síťovou, tedy vrstva transportní. Ale bylo by rozumné to tak skutečně udělat, tedy zabudovat mechanismy pro zajištění spolehlivosti „na pevno" do transportní vrstvy, tak aby je měly k dispozici všechny aplikace?

Autoři TCP/IP dospěli k závěru, že by to nebylo zcela optimální, a to z následujícího důvodu: i aplikace jsou dosti různorodé, a mohou mít různorodé požadavky na přenosové služby. Některé budou spolehlivost skutečně požadovat, zatímco jiné aplikace dají přednost rychlejšímu a pravidelnějšímu přenosu dat před spolehlivostí přenosu (protože fungování mechanismů pro zajištění spolehlivosti způsobuje celkové zpomalení a zavádí nerovnoměrnosti v doručování dat). Pro příklady takovýchto aplikací není nutné chodit daleko - například při přenosu zvuku či obrazu nejsou případné chyby v přenesených datech tak bolestivé, jako případná nerovnoměrnost v jejich doručování. Například lidské oko většinou ani nepostřehne drobný „kaz" v některém ze snímků běžícího filmu, ale okamžitě by postřehlo kolísání rychlosti filmu (tj. nepravidelnosti ve střídání jednotlivých snímků).

Pohybnosti vůči zavedení spolehlivosti do transportní vrstvy však mohou mít i diametrálně odlišnou motivaci - pro některé aplikace nemusí být spolehlivost, realizovaná na úrovni transportní vrstvy, dostatečná a adekvátní jejich potřebám. Zde je třeba si uvědomit, že mechanismy zajišťující spolehlivost nemohou mít nikdy absolutní účinnost a efektivnost, protože absolutně účinné a efektivní nejsou ani mechanismy detekce chyb (umožňující vůbec rozpoznat, že k nějaké chybě došlo). Proto každá spolehlivost je vždy relativní. Může se sice dosti těsně blížit absolutní hranici 100%, ale nikdy se k ní fakticky nedostane. V praxi by se pak mohlo stát, že transportní vrstva by sice zajišťovala spolehlivost přenosu, ale pro určitou aplikaci ne dostatečnou, a tato aplikace by si proto musela zajišťovat potřebnou míru spolehlivosti sama a znovu. Pak by ale bylo zbytečné a neefektivní, aby spolehlivost zajišťovala současně i vrstva transportní.l

Jaký je ale celkový závěr? Má transportní vrstva zajišťovat spolehlivost, nebo naopak nemá? Autoři TCP/IP vyřešili toto dilema skutečně šalamounsky: odpověděli současně „ano" i „ne". Udělali to tak, že pro svou transportní vrstvu navrhli dvě alternativy, resp. dva hlavní transportní protokoly - z nichž jeden (protokol TCP, Transport Control Protocol) zajišťuje určitou míru spolehlivosti a druhý (protokol UDP, User Datagram Protocol) nikoli. Vyšší vrstvy si pak mohou samy vybrat, který z těchto transportních protokolů budou využívat.

Jednou pro všechny, nebo pro každého znovu?

Srovnání vrstev TCP/IP a ISO/OSI

Jakmile se autoři TCP/IP zdárně vyrovnali s dilematem transportní vrstvy, čekalo na ně další závažné rozhodnutí. Tentokráte se týkalo služeb, které jsme si při popisu referenčního modelu ISO/OSI charakterizovali jako „podpůrné" pro jednotlivé aplikace - tedy například služeb zajišťujících konverze přenášených dat, korektní průběh relací apod. Otázka přitom nezněla tak, zda tyto služby mají či nemají smysl. Šlo spíše o četnost požadavků na jejich využití, a v návaznosti na tom o nejvhodnější způsob jejich implementace.

Autoři referenčního modelu ve stejné situaci dospěli k závěru, že služby tohoto typu budou potřebovat všechny aplikace, a tak se rozhodli implementovat je takovým způsobem, aby je měly všechny aplikace k dispozici - a vyhradili pro ně samostatné vrstvy. To pak ale mj. znamenalo, že i režii spojenou s implementací těchto služeb musely nést opět všechny aplikace, včetně těch které podpůrné služby nepožadují a nevyužívají.

Autoři TCP/IP dospěli při stejném rozhodování k opačnému závěru - k přesvědčení, že požadavky na podpůrné služby budou spíše méně časté, a že naopak budou převažovat aplikace které tyto služby využívat nebudou. Pak jim ale také vyšlo, že není moc rozumné implementovat zmíněné podpůrné funkce v samostatných vrstvách, společně pro všechny aplikace - nechť si je implementuje až ta aplikace, která je skutečně potřebuje, a to vlastními silami. No a to je také důvod, proč TCP/IP na rozdíl od ISO/OSI nemá ani relační, ani prezentační vrstvu.

---