Rodina protokolů TCP/IP

Historie rodiny protokolů TCP/IP úzce souvisí s historií Internetu, který byl vytvořen v podstatě jako experimentální síť k ověření určitých "technologických" myšlenek - zejména myšlenky realizovat přenos dat nikoli v podobě souvislého proudu (neboli na principu přepojování okruhů, jak bylo tehdy zvykem v celém telekomunikačním světě), ale na principu paketového přenosu.

Snaha přenáset data po malých částech (nazývaných pakety) byla v té době skutečně revoluční myšlenkou a její životaschopnost bylo třeba nejprve ověřit v praxi. No a právě Internet, přesněji jeho předchůdce jménem ARPAnet, byl experimentální sítí, na které se myšlenka paketového přenosu měla v praxi ověřit.

Aby potřebné otestování paketového přenosu bylo vůbec možné, bylo nutné nejprve vyvinout nějaký přenosový protokol schopný přenášet datové pakety. Pro potřeby ARPAnet-u byl proto "narychlo spíchnut" protokol jménem NCP, na kterém byly potřebné myšlenky ověřeny.

Když se tak stalo a ARPANET splnil svou prvotní úlohu, jeho zřizovatelé udělali jedno velmi moudré rozhodnutí - rozhodli se zachovat tuto síť a předat ji do rutinního používání akademické sféře. K něčemu takovému se ale protokol NCP nehodil, a tak bylo rozhodnuto vyvinout pro ARPANET "pořádné" přenosové protokoly, uzpůsobené možnostem a potřebám rutinního fungování. No a těmito protokoly se staly právě protokoly TCP/IP. Vznikly v průběhu 70. let a vyvinula je akademická sféra v USA, za peníze pocházející od provozovatelů původního ARPANETu, kterým byli američtí vojáci (přesněji grantová agentura ARPA, skrz kterou proudily potřebné finanční prostředky ve formě tzv. grantů).

Původní ARPANET, kterému se mezitím začalo říkat Internet, začal přecházet na nové protokoly TCP/IP od roku 1980. Definitivně na ně přešel k 1. 1. roku 1983, kdy se dřívější protokol NCP přestal úplně používat.

V čem je odlišnost?

Stejně jako u referenčního modelu ISO/OSI, je i s rodinou protokolů TCP/IP spojena konkrétní představa o počtu hierarchických vrstev a jejich úloze a poslání. Zatímco RM ISO/OSI má celkem 7 vrstev, protokoly TCP/IP vystačí jen se 4 vrstvami. Odlišný počet vrstev u obou modelů ale není příčinou jejich odlišností, je spíše důsledkem hlubokých filosofických a koncepčních odlišností mezi oběma "síťovými světovými názory". Právě tyto koncepční odlišnosti pak zřejmě rozhodly i o tom, že referenční model ISO/OSI se příliš neprosadil do praxe, zatímco rodina protokolů TCP/IP ano.

V prvním přiblížení by bylo možné konstatovat, že hlavní odlišností je odlišný celkový přístup autorů obou koncepcí. Zatímco autoři RM ISO/OSI usilovali od začátku o dokonalé řešení splňující mnoho různorodých požadavků (a obvykle pak narazili na problémy), autoři TCP/IP šli cestou od jednoduššího řešení směrem k řešení dokonalejšímu, cestou postupného zdokonalování a obohacování. Ve světě TCP/IP se navíc kladl velký důraz na možnost reálné implementovatelnosti navrženého řešení, které se mohlo stát standardem až teprve poté, co prokázalo svou životaschopnost a praktickou realizovatelnost. Ve světě ISO/OSI se otázka praktické realizace dostávala na přetřes až poté, co se nějaký návrh stal standardem a začalo se uvažovat o tom, jak ho implementovat.

TCP/IP nade všechno

Jedním ze základních požadavků, které byly nastoleny na samém začátku prací na celkové koncepci TCP/IP, byl požadavek na možnost vzájemného propojení různých sítí. Tedy požadavek na to, aby prostřednictvím protokolů TCP/IP bylo možné vzájemně propojit i takové sítě, které mohly být vybudovány i na dosti odlišných principech a základních přenosových technologiích (tedy například sítě Ethernet, Token Ring, dnes FDDI, ATM, sítě s dvoubodovými spoji atd.).

Po protokolech TCP/IP se tedy od začátku požadovalo, aby "běhaly" co možná nejlépe nad nejrůznějšími protokoly nejnižších vrstev (které v rámci referenčního modelu ISO/OSI spadají do fyzické a linkové vrstvy), a také aby se apriorně neuzavíraly možnosti využít i takové přenosové protokoly, které budou teprve v budoucnu vyvinuty. Takovýto požadavek přitom v sobě nutně nesl i akceptování faktu, že životaschopné (a uživateli skutečně používané) přenosové technologie mohou vznikat i mimo rámec světa TCP/IP. A také že není nutné znovu vynalézat již jednou vynalezené, ale že stačí již existující přenosové technologie pouze využít. Autoři RM ISO/OSI ve stejné situaci použili opačný přístup - považovali za nezbytné sami vyvinout i veškeré přenosové technologie, nebo alespoň formálně převzít a vydat jako svůj standard takové technologie, které přeci jen vznikly někde jinde (to je třeba případ Ethernetu a dalších technologií pocházejících od společnosti IEEE - standardy IEEE řady 802 byly vydány současně i jako standardy ISO 8802). K tomu ale samozřejmě referenční model ISO/OSI potřeboval fyzickou a linkovou vrstvu, zatímco síťový model TCP/IP tyto vrstvy nepotřebuje a nemá.

Pro přesnost a formální správnost ale dodejme, že síťový model TCP/IP přeci jen má nejnižší vrstvu, která svým "dosahem" pokrývá současně fyzickou i linkovou vrstvu referenčního modelu ISO/OSI. Je to vrstva označovaná jako vrstva síťového rozhraní (network interface layer). Důležité je ale to, že TCP/IP tuto vrstvu ponechává prázdnou a sám ji nijak "nezabydluje" konkrétními protokoly (nýbrž předpokládá, že na úrovni této vrstvy budou použita řešení vyvinutá mimo rámec TCP/IP).

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

Bohatost, nebo spíše skromnost?

Síťový model TCP/IP tedy nijak nevymezuje, jaká konkrétní přenosová technologie bude použita na úrovni vrstvy síťového rozhraní - a v důsledku toho pak ale nemůže sám nic předpokládat o vlastnostech této technologie. Nemůže tedy dopředu počítat s tím, že půjde o takovou technologii, která je relativně spolehlivá a nedochází u ní ke ztrátám či poškození dat příliš často, nebo že naopak jde o přenosovou technologii, která ztrácí data častěji. Podobně nemůže předpokládat nic ani o dalších vlastnostech, jako třeba o rychlosti přenosu, přenosovém zpoždění, maximální velikosti přenášených bloků apod.

Na druhé straně ale má TCP/IP za úkol nabídnout (na úrovni vyšších vrstev než je vrstva síťového rozhraní) stejné možnosti, podmínky i stejný způsob práce - tedy vlastně zakrýt případná specifika konkrétních síťových technologií a vytvořit nad nimi jednotné prostředí, nabízející jednotné služby, jednotný způsob adresování apod.

Jak ale má být voleno toto jednotné prostředí? Má být spíše bohatší, má oplývat funkcemi a schopnostmi, nebo má být naopak skromnější? Bude-li bohatší, bude složitější, náročnější a dražší této bohatosti dosáhnout pomocí "málo bohaté" přenosové technologie na úrovni vrstvy síťového rozhraní. Hlavně se pak ale může stát, že takováto "bohatost" bude zbytečná a že vyšší vrstvy ji nebudou požadovat. Bude ale mít tato situace nějaké nepříjemné důsledky? Když někdo nebude chtít využít dostupné "bohatosti", bude nějak omezen i při použití těch "méně bohatých" prostředků a funkcí? Odpověď je bohužel kladná - s implementací "bohatosti" (například spolehlivého způsobu fungování) je vždy spojena určitá nenulová režie. Pokud vyšší vrstvy "bohatost" nepotřebují a nevyužívají, příslušnou režii nesou stále.

Autoři TCP/IP se proto rozhodli pro skromnost, která na druhé straně umožňuje dosahovat vyšší efektivnosti. Podobné rozhodnutí pak přijali i na dalších místech resp. na úrovni dalších vrstev, takže jde spíše o obecnější princip, kterým je celý síťový model TCP/IP doslova prodchnut - zatímco třeba referenční model je prodchnut spíše opačným principem neboli snahou o apriorní bohatost, byť za cenu méně efektivního fungování.

Síťová vrstva

Když měli autoři TCP/IP vymyslet koncepci síťové vrstvy, která by překryla všechny konkrétní přenosové technologie z vrstvy síťového rozhraní a vytvořila nad nimi jednotné prostředí, samozřejmě aplikovali výše popsaný princip "spíše skromnost než bohatost". Pak jim zcela zákonitě vyšlo, že síťová vrstva by se měla soustředit především na co možná nejrychlejší přenos dat, a nikoli na zajištění spolehlivosti a případných dalších "bohatých" funkcí. Představa autorů, dobře korespondující s principem skromnosti, totiž byla taková, že právě spolehlivost si lépe a efektivněji zajistí ti, kdo ji budou skutečně potřebovat. Tedy až vyšší vrstvy, případně až jednotlivé aplikace.

Autoři TCP/IP proto zabydleli síťovou vrstvu protokolem, který funguje jako nespolehlivý - což je třeba chápat tak, že se sice snaží o bezchybný přenos, ale když se mu to nepodaří a někde se něco ztratí či poškodí, nepovažuje za svou povinnost postarat se o nápravu (a místo toho očekává, že o případnou nápravu se postarají vyšší vrstvy).

Zmíněný protokol dostal jméno Internet Protocol (zkratkou IP), což nesouvisí ani tak s Internetem jako takovým (který v době vzniku TCP/IP byl ještě zárodečným Arpanetem), jako spíše se skutečností, že má na starosti vzájemné propojení jednotlivých dílčích sítí (čímž vzniká obecný "internet", s malým "i").

Dalším charakteristickým rysem protokolu IP je jeho nespojovaný charakter - jde tedy o takový protokol, který při přenosu dat nepočítá s apriorním navázáním spojení mezi odesilatelem a příjemcem, a místo toho posílá všechna data "na blind", obdobně jako jsou odesílány jednotlivé dopisy běžnou listovní poštou. Však se také v této souvislosti hovoří o přenášených blocích dat jako o datagramech (IP datagramech) a o nespojovaném způsobu přenosu jako o datagramové službě.

Motivaci pro nespojovaný charakter protokolu IP je nutné hledat v celkovém požadavku na robustnost protokolů TCP/IP a jejich schopnost přežít nenadálé výpadky sítě - dojde-li totiž někde k náhlému přerušení nějaké přenosové cesty, přenos spojovaného charakteru to ovlivní zásadním způsobem (a je nutné provést složitější nápravné akce, vrcholící navázáním nového spojení). Naproti tomu přenos nespojovaného charakteru to ovlivní mnohem méně - zde je každý jednotlivý blok dat (datagram) přenášen samostatně, svou vlastní cestou, a tak jsou v případě výpadku jedné možné cesty další datagramy snadno směrovány jinudy.

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 "napevno" 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ů).

Pochybnosti 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 nedostateč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í.

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.

Protokoly a vrstvy TCP/IP

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

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.