TCP a UDP

Síťová vrstva má ve světě TCP/IP (stejně tak jako ve světě ISO/OSI) na starosti přenos datových paketů přes případné mezilehlé uzly až na místo jejich určení, k cílovému uzlu. Rozhodující úlohu přitom hraje tzv. směrování (routing), jak se označuje postup volby dalšího směru přenosu (tak aby datový paket postupně dorazil ke svému cíli). V rámci síťové vrstvy TCP/IP má takovýto přenos včetně směrování na starosti protokol IP (Internet Protocol). Funguje jako nespojovaný, což znamená že přenáší jednotlivé pakety (tzv. datagramy) nezávisle na sobě, podobně jako běžná listovní pošta přenáší jednotlivé listovní zásilky - bez toho, že by navazovala spojení mezi příjemce a odesilatelem.

Transportní vrstva, která se nachází bezprostředně nad vrstvou síťovou, má za úkol "obohacovat" služby síťové vrstvy a přidávat k nim novou kvalitu. Jde jednak o případnou změnu povahy přenosových služeb, typicky z nespolehlivých na spolehlivé, a dále o rozlišování více příjemců a odesilatelů v rámci jednotlivých síťových uzlů. Kromě toho je vhodné si uvědomit, že transportní vrstva je první vrstvou (počítáno od nejnižších vrstev), která není implementována v "přestupních" uzlech propojujících jednotlivé dílčí sítě (tedy v tzv. směrovačích, alias routerech), ale nachází se až v koncových uzlech sítě. Proto také řeší přímou komunikaci koncových uzlů, do které mezilehlé uzly již přímo nezasahují.

Jak koncipovat transportní vrstvu?

Když se autoři protokolů TCP/IP rozhodovali jak koncipovat transportní vrstvu, již věděli že bezprostředně nižší síťová vrstva bude nabízet pouze nespolehlivé přenosy datagramů na nespojovaném principu. Dilema, které museli vyřešit, znělo: má být tento nespojovaný a nespolehlivý charakter přenosu změněn na spolehlivý a spojovaný? Nebo má zůstat takový jaký je, tedy nespolehlivý a nespojovaný? Každá z obou variant přitom měla svá pro a proti: aplikace, které využívají přenosových služeb transportní vrstvy, mohou mít různé požadavky. Některé mohou požadovat spolehlivý přenos, zatímco jiné přenos nespolehlivý. Opodstatnění takovýchto požadavků si zaslouží malou odbočku.

Důvodem pro akcent na nespolehlivost může být požadavek na maximálně rychlé přenosy, u takových aplikací, kterým až tak nevadí nějaké poškození přenášených dat, ale na druhou stranu jim hodně vadí přenosové zpoždění a nepravidelnosti v doručování dat. Přitom právě všechny mechanismy zajišťující spolehlivost působí proti těmto faktorům, protože jejich fungování způsobuje nemalá zpoždění a nepravidelnosti v přenosech (typicky proto, že poškozená data se musí přenést znovu). Jiným důvodem, proč nějaká aplikace dá přednost nespolehlivosti, je relativní charakter spolehlivosti - ta nikdy není absolutní a dokonalá, ale vždy dosahuje jen nějakých 99, 99 apod. procent. - z toho prostého důvodu, že absolutně přesné nejsou již mechanismy detekce, odhalující zda došlo k poškození přenesených dat. Proto spolehlivou přenosovou službu je vždy třeba chápat jako službu, která data přenese spolehlivě s určitou procentuelní přesností (nikdy 100%). V praxi pak mohou existovat i takové aplikace, kterým zmíněná míra spolehlivosti nepostačuje (mohou to být například bankovní aplikace]. Takovéto aplikace si pak spolehlivost musí zajišťovat samy, a pak je pro ně výhodnější, pokud nižší vrstvy fungují jako nespolehlivé - jejich případná snaha o spolehlivost by pouze vytvářela zcela zbytečnou režii.

Transportní protokoly jsou dva

Autoři protokolů TCP/IP vyřešili dilema mezi spolehlivým a nespolehlivým způsobem fungování transportní vrstvy doslova šalamounsky: rozhodli se umístit do transportní vrstvy dva přenosové protokoly, které jsou vzájemně alternativní. Jeden z nich, jménem UDP (User Datagram Protocol), zachovává nespolehlivý a nespojovaný způsob fungování protokolu IP na úrovni síťové vrstvy, a je jeho velmi jednoduchou nadstavbou. Naproti tomu druhý protokol, TCP (Transmission Control Protoco) je mnohem radikálnější, protože mění nespolehlivý a nespojovaný charakter síťového protokolu IP na spojovaný a spolehlivý. Důležité přitom je, že aplikace si mohou samy svobodně vybrat, který z těchto protokolů zvolí.

Ještě jeden rozdíl

Dalším zajímavým rozdílem mezi protokoly TCP a UDP je představa o fungování přenosového mechanismu, kterou vytváří svým uživatelům - tedy jednotlivým aplikacím z aplikační vrstvy. Protokol UDP zachovává původní představu "blokového přenosu", neboli očekává od aplikací že mu budou předávat data určená k přenosu již v "nařezané" formě, neboli rozdělená na vhodně velké bloky (a protokol UDP si pak tyto bloky pouze vloží do svých datagramů).

Naproti tomu protokol TCP vytváří aplikacím iluzi spojitého přenosového proudu, který přenáší jednotlivé byty. Protokol TCP v zásadě vytváří "přenosovou rouru", do které jedna aplikace z jedné strany postupně vkládá jednotlivé byty, a druhá aplikace si je z druhé strany zase byte po bytu odebírá. Ve skutečnosti data samozřejmě necestují jednotlivě, byte po bytu, ale také po celých blocích, vkládaných do IP datagramů - potřebné členění na bloky však zajišťuje protokol TCP ve své režii a zcela transparentně, tak aby si to aplikace vůbec neuvědomovaly. Konkrétně to protokol TCP dělá tak, že pracuje s vhodně velkou vyrovnávací pamětí (tzv. bufferem), do které postupně ukládá jednotlivé byty. Jakmile je buffer naplněn, je jeho obsah odeslán jako blok (vložený do IP datagramu), a na druhé straně je vybalen a umístěn do obdobného bufferu, ze kterého si příslušná aplikace pak již může odebírat data byte po bytu.

Porty

Jedním z důležitých úkolů transportní vrstvy - a tudíž i každého transportního protokolu - je rozlišovat mezi různými odesilateli a příjemci v rámci téhož uzlu. Zde je vhodné si uvědomit, že bezprostředně nižší vrstva síťové se na každý uzel dívá jako na nedělitelný celek, a tomuto pohledu odpovídá i význam adres používaných na úrovni síťové vrstvy (IP adres). Datové pakety (IP datagramy), opatřené určitou IP adresou, jsou vždy určeny přijímajícímu uzlu jako takovému. V praxi je ale nutné rozlišovat v rámci každého uzlu celou řadu možných příjemců (i odesilatelů) - běží-li například na jednom uzlu více aplikací, které komunikují po síti, pak je nutné zajistit aby každá z nich dostávala právě a pouze "svá" data, a nikoli data patřící jiné aplikaci. Stejná úvaha platí i v situaci, kdy na jednom uzlu pracuje více uživatelů (kteří mohou používat stejné aplikace). Stejně tak to platí i v případě, kdy příjemcem či odesilatelem je některý systémový program (démon, proces apod., podle systémové platformy). Vždy je potřeba opatřit přenášená data informací, umožňující rozlišit kdo v rámci odesílajícího uzlu je jejich původcem (odesilatelem), a kdo je jejich příjemcem v rámci cílového uzlu.

Zmíněná informace má nejčastěji povahu relativní adresy, která se "připojuje" k absolutní adrese (síťové adrese, vyjadřující uzel jako celek). V konkrétním případě protokolů TCP/IP je "absolutní" adresou IP adresa, a "relativní" adresou tzv. číslo portu.

Port je nejlépe si představit jako přechodový bod na rozhraní mezi transportní a aplikační vrstvou, který je jednoznačně identifikovatelný (svým číslem, tedy tzv. číslem portu). Samotný port však není ani odesilatelem, ani příjemcem - tím je entita aplikační vrstvy (například systémový proces, aplikace úloha apod.), která se "přidruží" k příslušnému portu a skrz něj komunikuje s entitami transportní vrstvy (které implementují protokoly TCP či UDP). Alternativou by mohlo být to, aby příslušná relativní adresa identifikovala přímo příslušné aplikace (aplikační procesy, systémové úlohy atd.). Ty ale vznikají často dynamicky, na základě momentální potřeby (např. když si uživatel spustí nějakou úlohu), a bylo by nutné šířit po síti informace o jejich momentálním vzniku či zániku. Proto se zvolilo řešení s přestupními body (porty) na rozhraní mezi transportní a aplikační vrstvou, které mohou mít statickou povahu - i staticky přidělená čísla - a to podle svého významu. Například port č. 80 je vyhrazen pro WWW servery, takže když nějaký uzel funguje jako WWW server (tj. je na něm provozován program plnící roli WWW serveru), je nutné mu zasílat konkrétní požadavky právě na zmíněný port č. 80, odkud on si je bude přejímat a vyřizovat.

Důležité je, že takovéto přiřazení čísel portům s konkrétním významem může být učiněno apriorním způsobem a zveřejněno formou závazného standardu, tak aby se tím mohli počítat tvůrci síťového programového vybavení - například ten, kdo programuje nějaký WWW browser, může díky tomu přesně vědět, jakým způsobem má WWW klient (browser) vznášet své požadavky vůči předem neznámému WWW serveru.

Portům, které mají takto předem stanovený význam (a předem přidělená čísla), se říká "dobře známé porty" (well-known ports). Původně pro ně byla vyhrazena čísla do 256, ale dnes jim jsou přidělována již i vyšší čísla, do 1024.

Kromě dobře známých portů se používají i takové porty, které vznikají dynamicky, na základě momentální potřeby, a také dynamicky zanikají (zatímco u dobře známých portů si lze představit, že existují trvale). Takovéto dynamické porty slouží pro dočasnou komunikaci dvou entit (např. aplikací), které již spolu "navázaly" kontakt, typicky přes nějaký dopbřeznámý port. Například při přenosech souborů pomocí protokolu FTP je požadavek na přenos nejprve adresován FTP serveru na dobře známý port č. 21, ale pro faktický přenos je zřízen dynamický port, skrz který pak proudí příslušná data, a po skončení přenosu tento port zase zaniká.

Vrátíme-li se zpátky k protokolům TCP a UDP, práce s porty a odpovídající rozdělování dat mezi nimi patří do jejich náplně práce. V případě protokolu UDP, který je jen nejjednodušší možnou nadstavbou nad protokolem IP, je dokonce možné konstatovat že takovéto rozdělování je skoro to jediné, co dělá navíc.

Třetí transportní protokol?

Již u protokolu IP (viz minulý díl) jsme si říkali, že jedním z jeho nedostatků je jeho neschopnost poskytovat různým druhům přenášených dat různé podmínky - například některým datům garantovat nižší přenosové zpoždění a větší pravidelnost v doručování, na úkor takových dat, která nejsou na podmínky přenosu tolik citlivá. Stejná námitka se nutně musí uplatnit i vůči oběma transportním protokolům, které samy využívají přenosových schopností protokolu IP k realizaci svých služeb.

Možným řešením, které se již rýsuje na obzoru, je třetí transportní protokol, určený právě pro takovéto "citlivá" data náročná na kvalitu přenosu. Jde o protokol jménem RTP (Real-Time Protocol), který si lze představit jako alternativu k protokolům TCP a UDP (i když fakticky jde o protokol fungující "nad" protokolem UDP).

K fungování protokolu RTP je ale nutné změnit chování síťové vrstvy, a to takovým způsobem, aby zde byla vyhrazena určitá přenosová kapacita právě pro takovéto "přednostní" přenosy (protože jinak se protokol IP bude chovat vůči všem přenášeným datům stejně). Potřebné vyhrazení přenosové kapacity na úrovni síťové vrstvy má na starosti protokol s příznačným názvem RSVP (Resource reServation Protocol).