Transportní protokoly TCP/IP - I.
Při srovnávání celkové filosofie síťového modelu TCP/IP a referenčního modelu ISO/OSI jsme si již dříve uvedli, že jednou z jejich odlišností je požadavek na spolehlivost přenosových služeb na jednotlivých úrovních. Referenční model ISO/OSI (alespoň ve své původní koncepci) je orientován především na spojované služby spolehlivého charakteru, a předpokládá tudíž zařazení potřebných mechanismů pro zajištění spolehlivosti již do vrstvy síťové. Naproti tomu TCP/IP model považuje zajištění spolehlivosti za úkol koncových účastníků, a zařazuje proto příslušné mechanismy až do vrstvy transportní.Pro správné pochopení podstaty celého problému je třeba si uvědomit, že realizace spolehlivých služeb je spojena s větší režií, než jakou jsou zatíženy nespolehlivé přenosové služby. Nejde přitom jen o větší výpočetní náročnost, ale také o větší nároky na přenosovou kapacitu. Spolehlivost přenosů po ne zcela spolehlivých přenosových cestách se totiž musí zajišťovat vhodnou formou potvrzování (viz 30. díl seriálu), což je ale vždy spojeno s přenosem určitého objemu služebních dat, ke kterému samozřejmě dochází na úkor "užitečných dat".
Jestliže tedy TCP/IP model požaduje na síťové vrstvě pouze nespolehlivou přenosovou službu (realizovanou protokolem IP, viz minulý díl), umožňuje tím současně, aby síťová vrstva pracovala s menší režií, a tudíž rychleji.
Spolehlivost vs. rychlost
Považuje-li síťový model TCP/IP otázku zajištění spolehlivosti za úkol koncových účastníků komunikace, znamená to, že příslušné mechanismy pro její zajištění musí být implementovány ve vyšší vrstvě, než je vrstva síťová. Otázkou ovšem je, zda to skutečně musí být již vrstva bezprostředně vyšší, tedy vrstva transportní - jak jsme dosud předpokládali.
Zařadit potřebné mechanismy pro zajištění spolehlivosti do transportní vrstvy má četné výhody. Především pak tu, že tyto prostředky mohou být v transportní vrstvě realizovány právě jednou, a sdíleny všemi entitami aplikační vrstvy. Pokud bychom naopak tyto prostředky umístili až do vrstvy aplikační, vlastně by to znamenalo, že by si je musela každá entita aplikační vrstvy zajišťovat vždy znovu a sama.
Mohlo by se tedy zdát, že vše hovoří ve prospěch první možnosti. Ale i ta druhá může mít své opodstatnění - existují totiž i takové druhy aplikací, které buď vůbec nepotřebují spolehlivé přenosové služby, nebo naopak nepovažují "spolehlivost" na úrovni transportní vrstvy za dostatečnou, a tak si ji musí zajišťovat samy a znovu. Jinou motivací mohou být otázky efektivnosti - některé aplikace si dokáží zajistit samy takovou míru spolehlivosti, jakou skutečně potřebují, a vykazují přitom menší režii, než jakou na zajištění "úplné" spolehlivosti vyžaduje vrstva transportní. Příkladem takovéhoto druhu aplikací může být distribuovaný systém souborů NFS (Network File System) firmy Sun, velmi oblíbený a značně rozšířený v prostředí operačního systému Unix. Umožňuje, aby jeden uzlový počítač zcela transparentně sdílel soubory jiného uzlového počítače, tedy aby k nim přistupoval naprosto stejně, jako ke svým vlastním souborům. Nemá-li ale docházet k výraznějším časovým rozdílům při přístupu k lokálním a vzdáleným souborům, musí systém NFS pracovat maximálně rychle. Nemůže si proto dovolit používat spolehlivé, zato ale "pomalé" přenosové služby na úrovni transportní vrstvy.
Každý si může vybrat sám
 |
Spojovaný vs. nespojovaný charakter transportních služeb
Spolehlivost a nespolehlivost není jediným rozdílem mezi oběma protokoly transportní vrstvy. Protokol TCP má spojovaný (connection-oriented) charakter, který pracuje s virtuálními okruhy (virtual circuits), a před vlastním přenosem předpokládá navázání spojení mezi odesilatelem a příjemcem. Naproti tomu protokol UDP má nespojovaný (connectionless) charakter, a každý jednotlivý blok dat, označovaný v tomto případ jako uživatelský datagram (user datagram) přenáší samostatně a nezávisle na ostatních datagramech.
Protokol UDP tak vlastně poskytuje na úrovni transportní vrstvy služby stejného charakteru, jaké na úrovni vrstvy síťové poskytuje protokol IP (viz minule), tedy nespolehlivé a nespojované služby. Naproti tomu protokol TCP implementuje pomocí nespolehlivých a nespojovaných služeb na úrovni síťové vrstvy spolehlivé a spojované transportní služby. Jak jsme si již naznačili výše, činí tak s pomocí mechanismu potvrzování (acknowledgement), a tudíž i s nezanedbatelnou režií.
Proud vs. blokově orientovaný přenos
Další odlišností mezi oběma protokoly je pak také forma, jakou své přenosové služby nabízí. Protokol UDP koncipuje svou přenosovou službu jako přenos celých bloků dat. Očekává tedy, že entita aplikační vrstvy, která chce odeslat nějaká data, je sama sestaví do bloku, a ten pak protokolu UDP předá jako jeden celek. Protokol UDP tento blok vezme, umístí jej do svého uživatelského datagramu (viz výše), a přenese opět jako jeden celek. Naproti tomu protokol TCP koncipuje svou přenosovou službu jako tzv. proud (stream) jednotlivých bytů (přesněji: osmic bytů, tzv. oktetů). Odesilatel na jednom uzlovém počítači postupně předává protokolu TCP jednotlivé byty (oktety), a obdobně postupuje i příjemce, který si je na druhé straně zase postupně odebírá. Veškeré členění přenášených dat na bloky a přenos celých těchto bloků zajišťuje protokol TCP plně transparentně. Uživatelé přenosových služeb protokolu TCP tak získávají iluzi, že pracují se službou, která přenáší individuálně jednotlivé byty (oktety).
Stavový vs. bezestavový způsob komunikace
Se spojovaným, resp. nespojovaným charakterem protokolů TCP a UDP úzce souvisí ještě i další aspekt, který je velmi podstatný pro protokoly aplikační vrstvy a pro jejich volbu mezi oběma nabízenými transportními protokoly.
Každý uživatelský datagram (user datagram) - jak je označován blok dat, přenášený na úrovni transportní vrstvy protokolem UDP - je považován za samostatný celek, a vzhledem k nespojovanému charakteru protokolu UDP je také tak přenášen - samostatně, nezávisle na jiných uživatelských datagramech, a bez předchozího navázání spojení mezi příjemcem a odesilatelem. Stejně tak i příjemce chápe uživatelský datagram jako jediný celek, a ne jako součást většího celku. Tomu pak odpovídá i skutečnost, že příjemce nemění svůj stav v závislosti na průběhu komunikace - po přijetí datagramu se nachází ve stejném stavu, v jakém byl před jeho přijetím. Jde tedy o způsob přenosu, který je možné charakterizovat jako bezestavový (stateless).
Naproti tomu každá spojovaná služba má vždy nutně stavový charakter, neboť již pouhým navázáním spojení se příjemce dostává do jiného stavu, než v jakém byl předtím.
Bezestavový způsob komunikace je vzhledem ke své podstatě dobře odolný vůči různým nestandardním situacím, především pak výpadkům a ztrátám dat. Dojde-li například k výpadku přenosových cest či k výpadku příjemce (a je nutné jej znovu spustit, provést tzv. reboot), nejsou nutná žádná specifická opatření pro obnovu původního stavu - v přenosu dat se jednoduše pokračuje dál. Naproti tomu v případě stavového způsobu komunikace mohou být určité nápravné akce zapotřebí, má-li být zachována konzistence právě probíhajících činností, a znovu navázáno přerušené spojení.
S tím pak také souvisí i otázka spolehlivosti - zatímco bezestavové protokoly si mohou dovolit být nespolehlivé (jako UDP), pro jejich stavové protějšky je výhodnější pracovat s dostatečnou mírou spolehlivosti, a tedy nabízet spolehlivé přenosové služby (jako protokol TCP).