Transportní vrstva Transportní vrstva odpovídá v podstatě transportní vrstvě OSI, protože poskytuje mechanismus pro koncový přenos dat mezi dvěma stanicemi. Původně se proto tato vrstva označovala jako vrstva koncová (end-to-end nebo bost-to-hosf). Nabízí transportní službu se spojením nebo bez spojení za použití jednoho ze dvou protokolů: Transmission Control Protocol (TCP, RFC 793) - poskytuje transportní službu se spojením včetně řízení koncového spojení ( spolehlivý protokol ), User Datagram Protocol (UDP, RFC 768) - poskytuje transportní službu bez spojení ( nespolehlivý protokol ). Kromě transportních protokolů jsou k této vrstvě přiřazeny některé směrovací protokoly, jako RIP a BGP. Rozhraní (SAP) mezi transportní a aplikační vrstvou, tj. identifikace aplikačního protokolu, který bude poskytovanou transportní službu používat, se označuje číslem portu: známé porty se pohybují v rozmezí celých čísel 0 až l 023 a jsou pro aplikační protokoly pevně dané (konkrétní hodnoty přiděluje IANA); registrované porty v intervalu l 024 až 49 151 (registruje je IANA a jsou obvykle využívány pro běžné uživatelské procesy a aplikace); dynamické nebo soukromé porty se pohybují v rozmezí 49 152 až 65 535. Transmission Control Protocol Transmission Control Protocol (TCP) poskytuje virtuální okruh mezi koncovými aplikacemi, tedy spolehlivý přenos dat, který nebyl zajištěn datagramově orientovaným IP. TCP přijímá informace od vyšší vrstvy jako souvislý tok bytů dat (byte-stream), který musí rozdělit do transportních segmentů délky odpovídající velikosti datagramu IP, a ty předá síťové vrstvě. Vykonává další funkce transportní vrstvy, jako řízení koncového zabezpečení a datového toku, řízení koncového spojení. TCP využívají ke své práci aplikační protokoly, jako např. FTP či TELNET. Vlastnosti podporované transportním protokolem TCP: spolehlivá transportní služba - doručí adresátovi všechna přenášená data tak, jak je odesílatel vyslal (tzn. bez ztráty nebo zkreslení dat či duplicitních paketů) s využitím pozitivního potvrzování (na základě pořadových čísel bytů) a opětovných přenosů (PAR, Positive Acknowledgement with Retransmission); služba se spojením - fáze navázání spojení mezi dvěma procesy (potřebuje výměnu 3 segmentů), přenosu dat a ukončení spojení (potřebuje výměnu 4 segmentů); efektivní využití přenosových kanálů - vysílání s využitím vyrovnávacích pamětí, kdy odesílatel začne vysílat, až se nashromáždí dostatek dat nebo po vypršení časového limitu, zamezení zahlcení příjemce i sítě; transparentní přenos libovolných dat vyššího protokolu; plně duplexní spojení (současný obousměrný přenos dat) - potvrzení o správném příjmu TCP segmentu je součástí datového TCP segmentu vysílaného opačným směrem (piggybacking); rozlišení mezi více potenciálními adresáty (procesy) na daném počítači -pomocí portů.
Řízení toku TCP Řízení toku TCP se realizuje několika spolupracujícími mechanismy: velikostí okna, pořadovými čísly oktetů dat, potvrzováním. Záhlaví TCP segmentu obsahuje pole okno, které specifikuje, kolik oktetů dat se může přenést od odesilatele k příjemci bez průběžného potvrzování doručení jednotlivých segmentů. Minimální velikost okna je l segment, a to vyžaduje potvrzovat příjem každého jednotlivého segmentu. Protože tento způsob přenosu je neefektivní, využívá se větší šíře okna, tj. většího množství segmentů, které se mohou odeslat ihned za sebou a teprve poté získat na jejich doručení potvrzení. Po obdržení potvrzení jejich příjmu může odesilatel vyslat opět skupinu segmentů podle velikosti okna. Tento mechanismus TCP se nazývá klouzavé okno (sliding window), protože vysílací okno se jakoby posunuje o příslušný počet segmentů dál v řadě segmentů čekajících na odeslání. Typické hodnoty velikosti okna TCP jsou 8 192 bytů (stanice) a 24 000 bytů (velké servery). Posílání segmentů TCP s pořadovými čísly a jejich potvrzování
Velikost okna není pevná hodnota, nedohaduje se při navazování spojení pro celou dobu spojení. Velikost okna lze v průběhu komunikace specifikovat průběžně, takže velikost inzerovaného okna je dynamická. Každé potvrzení, které specifikuje počet přijatých oktetů, zároveň obsahuje informaci, kolik dalších oktetů je příjemce připraven akceptovat (např. podle aktuální velikosti pamětí), takže vysílající strana pak upraví (zvětší/zmenší) velikost svého vysílajícího okna (ovšem tak, aby zůstala konzistentní vzhledem k předchozí poloze). TCP odpovídá na zahlcení sítě (ztráty paketů) dynamicky snížením velikosti okna vysílání, čímž se sníží propustnost. Poté postupně zvyšuje velikost okna do původní hodnoty, pokud opět nedojde ke ztrátě dat. TCP také pomáhá vyvarovat se přetížení a zahlcení sítě tzv. pomalým startem, kdy každé nové spojení zahajuje vysláním jednoho segmentu (šířka okna zahlcení, congestíon window). Po přijetí potvrzení doručení tohoto segmentu se okno zahlcení dvojnásobně zvětší. S každým dalším potvrzením se velikost okna zahlcení zvyšuje exponenciálně (do kapacity okna příjemce). Proto nemůže dojít k tomu, že by otevřením nového spojení s velkými nároky na přenosové kapacity sítě došlo k zahlcení sítě. Potvrzování doručených oktetů dat provádí přijímající stanice na základě pořadových čísel segmentů. Potvrzení je pozitivní, tzn. potvrzuje se příjem všech oktetů předcházejících číslu potvrzení (to je číslo oktetu, které se očekává jako další). Potvrzení od cílové stanice slouží pro vysílající stanici k tomu, aby bud' pokračovala ve vysílání (pokud veškeré odeslané segmenty byly doručeny), nebo aby zajistila opětovné vyslání segmentů od čísla specifikovaného v posledním potvrzení. Příklad je uveden na obrázku. Většinou se vysílají všechny další segmenty (v počtu do velikosti okna), neboť tímto jednoduchým pozitivním potvrzováním lze obtížně specifikovat pouze chybějící segmenty. V případě ztráty potvrzení o doručených segmentech na cestě od příjemce zpět k odesilateli dojde po vypršení časomíry k opětovnému odeslání segmentů a vysílající stanice je vyšle všechny znovu (v počtu podle nastavení okna). Příjemce na základě jejich obdržení vygeneruje potvrzení a duplicitní segmenty zahodí. TCP rozlišuje tři fáze komunikace: navázání spojení - mechanismus trojitého potřásání rukou (three way hand-shaking), prvním krokem je vyslání synchronizačního segmentu (žadatelem o spojení) s označením SYN v poli řízení TCP a specifikací startovního pořadového čísla, odpovědí je segment s potvrzením přijetí počátečního segmentu a nastavení startovního pořadového čísla pro opačný směr vysílání, závěr navazování spojení činí potvrzení příjmu odpovědi cílovou stanicí; každému přenosu podporovanému protokolem TCP tak předchází výměna tří segmentů navazování spojení, než dojde k vyslání prvního segmentu s uživatelskými daty; přenos dat - fáze ihned navazující na fázi navázání spojení, zahrnuje přenos segmentů na základě pořadových čísel, pozitivního potvrzování a opětovného vysílání, pokud je třeba; ukončení spojení - musí být provedeno z obou stran. Pokud je provedeno pouze z jedné strany, může druhá stanice dále posílat data, dokud sama spojení také neukončí. Ukončení spojení se provádí nastavením bitu FIN v poli řízení segmentu. Vzhledem k požadavku navázání spojení s cílovou stanicí TCP nepodporuje vysílání na všeobecnou ani skupinovou adresu IP.
Navazování spojení TCP Ukončení spojení TCP Formát segmentu TCP Délka segmentu TCP není omezena, proto může docházet k další fragmentaci protokolem síťové vrstvy, IP. Záhlaví segmentu TCP o 20 oktetech obsahuje následující pole: zdrojový port - identifikuje zdrojový aplikační proces (známým nebo uživatelským číslem portu), cílový port - identifikuje cílový aplikační proces (známým nebo uživatelským číslem portu), pořadové číslo - číslo prvního oktetu dat v segmentu, číslo potvrzení - specifikuje pořadové číslo oktetu dat, které očekává jako následující, délka záhlaví - délka záhlaví v násobcích počtu 32 bitů, funkce řízení - každý ze šesti bitů tohoto pole má svůj přidělený význam související s datovým spojením: URG označuje urgentní data pro přednostní doručení SYN je žádostí o navázání spojení ACK označuje platnost pole s číslem potvrzení RST požaduje opětovné navázání spojení PSH požaduje okamžité doručení segmentu protokolu vyšší vrstvy FIN je žádostí o ukončení spojení šířka okna - velikost okna (počet oktetů, které lze vyslat bez průběžného potvrzení), kontrolní součet - zabezpečení přes celý segment (včetně tzv. pseudozáhlaví), označení urgentních dat - specifikuje poslední oktet urgentních dat,
volitelné možnosti - doplňkové informace, např. maximální velikost segmentu. Formát segmentu protokolu TCP Pseudozáhlaví, používané pro zabezpečení segmentu (nejen TCP, ale i UDP), obsahuje některé informace z IP datagramu: zdrojovou a cílovou IP adresu, číslo protokolu a délku původního segmentu. Pseudozáhlaví je pro účel výpočtu kontrolního součtu fiktivně předřazeno před vlastní TCP/UDP záhlaví (ale neposílá se spolu se segmentem). Pole délka segmentu však obsahuje pouze délku původního segmentu TCP nebo UDP a nezahrnuje pseudozáhlaví. Pseudozáhlaví segmentu TCP/IP
User Datagram Protocol User Datagram Protocol (UDP) poskytuje nespolehlivou transportní službu pro ty aplikace, které nepožadují zabezpečení přenosu v takovém rozsahu, jako je poskytuje TCP (ověření doručení v pořadí, zajištění opakovaného přenosu), nebo pro transakčně orientované aplikace (dotaz-odpověd), pro něž může být navazování spojení příliš zdlouhavé. UDP neposkytuje spolehlivý koncový přenos dat, nemá fáze navazování a rušení spojení, proto hned první segment UDP obsahuje uživatelská data. Zprávy zpracovává obdobným způsobem jako TCP, pouze záhlaví je kratší, protože neobsahuje pole pro informace o velikosti okna, číslech segmentů a potvrzení. UDP je transportní protokol podporující vysílání na všeobecnou adresu IP (255.255.255.255) a na skupinové adresy. UDP např. používají aplikační protokoly SNMP, DNS nebo BOOTP. Formát segmentu UDP UDP má jednoduchý formát segmentu (správně, ale nejednoznačně označovaný jako datagram), naznačený na obrázku. Formát segmentu protokolu UDP Záhlaví protokolu UDP se skládá z následujících polí: zdrojový port - identifikuje zdrojový aplikační proces (známým nebo uživatelským číslem portu), cílový port identifikuje cílový aplikační proces (známým nebo uživatelským číslem portu), délka - délka celého segmentu v násobcích počtu 32 bitů, kontrolní součet - zabezpečení přes celý segment včetně tzv. pseudozáhlaví Datová jednotka UDP se již dále v IP nefragmentuje, proto platí jednoznačné mapování segmentu UDP do datagramu IP. Datagram IP pak může být fragmentován podle potřeb spojové vrstvy. Protože všechny implementace TCP/IP musí podporovat minimální velikost datagramu 576 bytů a maximální délka záhlaví IP verze 4 je 60 bytů, UDP datagram o délce 516 bytů podporují všechny implementace. UDP používá podobně jako TCP čísla portů k identifikaci aplikačních protokolů. Číslo portu je 16bitová hodnota, čísla pod l 024 jsou specificky přidělena jednotlivým protokolům pracujícím nad transportní vrstvou (RFC 1700) a vyšší čísla jsou přidělována procesům na klientech podle potřeb. Číslo portu je pro každý aplikační protokol jedinečné, bez ohledu na to, zda protokol používá v transportní vrstvě UDP a TCP (aplikační protokoly, které mohou využívat jedné nebo druhé služby, mají proto přiděleno jedno číslo portu, protože transportní protokol se specifikuje v čísle protokolu). Zpracováno podle: PUŽMANOVÁ, Rita. Moderní komunikační sítě od A do Z. 2. aktualiz. vyd. Brno : Computer Press, 2006. 430 s. ISBN 80-251-1278-0
PETERKA, Jiří. Aplikační vrstva. EArchiv [online]. 2004 [cit. 2008-10-06]. Dostupný z WWW: <http://www.earchiv.cz/a92/a227c110.php3>.