Transportní vrstva

Transportní vrstva

Přenosová neboli transportní vrstva segmentuje data do datového proudu a poté je zpětně sestavuje. Její služby tak segmentují a znovu sestavují data z aplikací vyšších vrstev. Zajišťují služby přenosu dat mezi koncovými systémy a dokážou navázat logické spojení mezi odesílajícím a přijímajícím hostitelem datové sítě. Někteří z vás už jistě znají protokoly TCP a UDP (ostatním je podrobně vysvětlím v kapitole 2). Oba pracují právě na transportní vrstvě, přičemž TCP zajišťuje spolehlivé (spojované) služby a UDP nespolehlivé (nespojované). To znamená, že vývojáři mají v sadě protokolů TCP/lP na výběr ze dvou druhů protokolů (podle potřeb konkrétní aplikace). Transportní vrstva poskytuje mechanismy pro multiplexing aplikací horních vrstev, pro navazování spojení a ukončování virtuálních okruhů (spojení). Vyšším vrstvám poskytuje transparentní služby přenosu dat a tak před nimi skrývá detaily závislé na konkrétní síti.

Poznámka Výraz spolehlivá komunikace se používá u transportní vrstvy a znamená, že se při ní používají potvrzení, seřazení dat a řízení toku. Komunikace na transportní vrstvě může být tedy spojovaná nebo nespojovaná. Společnost Cisco klade ale důraz především na spojované protokoly; budeme o nich proto hovořit i v následujících odstavcích textu.

Řízení toku dat

Datovou integritu zajišťuje transportní vrstva díky takzvanému řízení toku dat a díky tomu, že umožňuje uživatelům spolehlivý přenos dat mezi systémy. Řízení toku dat znamená, že odesílající hostitel nemůže na jedné straně spojení způsobit přeplnění bufferů na přijímající straně, jež vede ke ztrátě dat. Spolehlivé přenosy dat využívají mezi systémy spojovanou komunikační relaci a příslušné protokoly zajišťují splnění těchto podmínek:

• Doručené segmenty se po přijetí potvrzují zpět odesilateli. • Jakékoli nepotvrzené segmenty se vysílají znovu. • Segmenty se po příchodu do cíle znovu seřadí do správného pořadí. • Během přenosu udržuje protokol vhodný datový tok a zabraňuje tak zahlcení, přetížení a ztrátě dat.

Protokoly hostitelské vrstvy

Hlavním účelem hostitelské vrstvy je odstínit aplikace na horních vrstvách od detailů fungování sítě. Tato vrstva sděluje vyšší vrstvě "Stačí, když mi dáš svůj datový proud s příslušnými pokyny, a já začnu tvoje informace připravovat k odeslání". Následující sekce popisují dva protokoly této vrstvy:

• TCP (Transmission Control Proto col) • UDP (User Datagram Proto col)

Kromě toho se budeme zabývat některými základními koncepcemi protokolů hostitelské vrstvy a seznámíme se i s čísly portů.

Poznámka Pamatujte, že se stále nacházíme načtvrté vrstvě, a společnost Cisco široce využívá toho, jak lze na vrstvě 4 pracovat s potvrzenimi, řazením paketů a řízením toku.

TCP (Transmission Control Protocol)

Protokol TCP (Transmission Control Protocol) přijímá od aplikací velké bloky dat a dělí je na segmenty. Každý segment očísluje a zařadí, aby cílový zásobník protokolu TCP mohl segmenty znovu uspořádat tak, jak to požaduje příslušná aplikace. Po odeslání těchto segmentů vyčká zásobník protokolu TCP (na vysílajícím hostiteli) na potvrzení relace virtuálního okruhu TCP přijímající strany a opakuje přenos těch paketů, které nebyly potvrzeny. Před tím, než přenášející hostitel v tomto modelu začne odesílat segmenty, kontaktuje zásobník protokolu TCP odesilatele odpovídající zásobník příjemce, aby bylo navázáno spojení. Vytvořená vazba se označuje jako virtuální okruh. Tento typ komunikace se označuje jako spojovaný (connection-oriented). Během počátečního navazování komunikace se obě vrstvy TCP dohodnou rovněž na objemu informací, které se budou předávat. Pak zásobník TCP příjemce odešle zpět potvrzení. Poté, co je vše předem domluveno, může probíhat spolehlivá komunikace. Protokol TCP je plně duplexní, spojovaný, spolehlivý a přesný, ale nastavení všech podmínek přenosu nad rámec kontroly chyb rozhodně není zadarmo. Protokol TCP je velmi komplikovaný a nepřekvapuje, že s ohledem na svou síťovou režii také poměrně nákladný. Vzhledem k tomu, že dnešní sítě jsou mnohem spolehlivější než kdysi, bývá tato zvýšená spolehlivost často zbytečná.

Formát segmentu TCP

Horní vrstvy pouze odesílají datové proudy protokolům na transportních vrstvách. Nyní si tedy ukážeme, jak protokol TCP segmentuje datový proud a připravuje jej pro internetovou vrstvu. Když datový proud přijme internetová vrstva, směruje segmenty v rámci datové sítě v podobě paketů. Segmenty zpracovává protokol hostitelské vrstvy přijímaj ícího hostitele, který datový proud rekonstruuje a předá aplikacím či protokolům vyšších vrstev. Formát segmentu TCP je znázorněn na obrázku 2.3. Schéma představuje různá pole v hlavičce paketu TCP. Hlavička TCP má délku 20 bajtů, případně až 24 bajtů včetně možností. Je nutné se seznámit s tím, co každé pole v segmentu TCP znamená:

Source port (Zdrojový port) - číslo portu aplikace na straně hostitele, která odesílá data. (Čísla portů si vysvětlíme dále v této sekci.)

Destination port (Cílový port) - číslo portu požadované aplikace v cílovém hostiteli.

Sequence number (Pořadové číslo) - číslo používané protokolem TCP, které umožňuje znovu uspořádat data ve správném pořadí nebo znovu přenést chybějící či poškozená data na základě procesu označovaného jako řazení paketů (sequencing).

Acknowledgement number (Číslo potvrzení) - následně očekávaný oktet TCP.

Header length (Délka hlavičky) - počet 32bitových slov v hlavičce TCP. Tato hodnota informuje o tom, kde začínají data. Délka hlavičky TCP (i v případě, že zahrnuje další možnosti) je celočíselným násobkem 32 bitů.

Reserved (Vyhrazeno) - vždy nastaveno na nulu.

Code bits (Kódové bity) - řídicí funkce, které slouží k navázání a ukončení relace.

Window (Okno) - velikost okna, které je příjemce ochoten přijmout. Udává se v oktetech. Checksum (Kontrolní součet) - hodnota CRC (cyclic redundancy check), protože protokol TCP nedůvěřuje nižším vrstvám a vše kontroluje. Hodnota CRC ověřuje hlavičku a datová pole.

Urgent (Naléhavé) - pole je platné pouze v případě, že je nastaven ukazatel Urgent v kódových bitech. V kladném případě tato hodnota udává posun oproti aktuálnímu pořadovému číslu (v oktetech), kde začíná první segment dat s nižší prioritou.

Options (Možnosti) - může se rovnat O nebo násobku 32 bitů, pokud se používá. To znamená, že nemusí být uvedena žádná možnost (pole Options má nulovou velikost). Jestliže se však v tomto poli používají jakékoli možnosti, které se v souhrnu nerovnají násobku 32 bitů, je nutné použít vyplnění nulami, aby data začínala na hranici násobku 32 bitů.

Data - předávají se směrem dolů protokolu TCP na transportní vrstvě a zahrnují hlavičky protokolů vyšší vrstvy.

Podívejte se na segment TCP zkopírovaný ze síťového analyzátoru:

TCP - Transp ort Control P r otocol

Source Port : 5973

Destinati on Port : 23

Sequence N u mbe r: 1 4 56389907

Ack Number: 1 2 42056456

Offset : 5

Reserved : %000000

Code : % 0 1 1 0 00

Ack is va l i d

Pus h Reques t

W indow : 613 20

Checksum: Ox6 1a6

Urgent Poi nter : 0

No TCP O p tio ns

TCP Data Area :

vL.5 .+.5.+. 5.+.5 76 4c 19 35 II 2b 19 35 II 2b 19 35 II

2 b 1 9 3 5 +. II 2b 19

F r ame Check Sequence : OxOdOOOOOf

Všimli jste si, že tento segment obsahuje vše, co bylo uvedeno v předchozím popisu? Jak je zřejmé z počtu polí v hlavičce, generuje protokol TCP značnou režii. Vývojáři aplikací se mohou rozhodnout, že kvůli snížení režie dají před spolehlivostí přednost efektivitě. Za tímto účelem byl jako alternativa na transportní vrstvě definován i protokol UDP (User Datagram Protocol).

UDP (User Datagram Protocol)

Pokud porovnáte protokol UDP (User Datagram Protocol) s protokolem TCP, zjistíte, že první z nich je v zásadě zjednodušenou ekonomickou verZÍ druhého. Tento model se někdy označuje jako tenký protokol. Podobně jako hubený člověk na lavičce v parku ani tenký protokol nezabírá mnoho místa - v tomto případě vyžaduje menší šířku pásma sítě. Protokol UDP ani nenabízí všechny pokročilé funkce protokolu TCP, ale dokonale plní úkol přenosu informací, které nevyžadují spolehlivé doručení - a konzumuje přitom mnohem méně síťových prostředků. (Protokol UDP je podrobně popsán ve standardu RFC - Request for Comments - 768.)

Poznámka Dokumenty RFC (Requests for Comments) tvoří od roku 1969 souvislou řadu komentářů týkajících se Internetu (původně sítě ARPAnet). Tyto texty se týkají mnoha aspektů počítačové komunikace. Zaměřují se na síťové protokoly, postupy, programy a koncepce, ale zahrnují i poznámky ze schůzí, osobní názory a někdy i vtipy.

V některých situacích je rozhodně rozumné, aby vývojáři dali přednost protokolu UDP před protokolem TCP. Pamatujete si na hlídací protokol SNMP na vyšší procesní/aplikační vrstvě? Protokol SNMP sleduje síť a odesílá příležitostné zprávy a poměrně stabilní tok aktualizací stavu a upozornění, zejména v případě, kdy se používá v rozsáhlé síti. Náklady na navazování, údržbu a ukončování spojení TCP pro každou z těchto krátkých zpráv by způsobily, že jinak funkční a efektivní síť by se okamžitě zpomalila až k nepoužitelnosti! Jiná situace, kdy je vhodné zvolit protokol UDP místo protokolu TCP, nastává, když je spolehlivost již zajišťována na procesní/aplikační vrstvě. Protokol NFS (Network File System) se stará o spolehlivost sám, takže je v tomto případě použití protokolu TCP nepraktické i nadbytečné. Rozhodnutí o výběru protokolu UDP nebo TCP však nakonec musí přijmout vývojář, nikoli uživatel, který chce přenášet svá data rychleji.

Protokol UDP neřadí segmenty a nestará se o to, v jakém pořadí dorazí do cílového umístění. UDP prostě segmenty odešle a dále se jimi nezabývá. Nesleduje tyto segmenty, nekontroluje jejich stav ani neposkytuje potvrzení bezpečného doručení - dá se říci, že segmenty naprosto opouští. Vzhledem k tomu se označuje jako nespolehlivý protokol. To neznamená, že by byl protokol UDP neefektivní, pouze neřeší otázky spolehlivosti. UDP dále nevytváří virtuální okruh ani nekontaktuje cílové umístění před tím, než mu odešle data. Z tohoto důvodu se také považuje za nespojovaný protokol. Protokol UDP předpokládá, že aplikace zajistí spolehlivost svými vlastními metodami a sám žádnou metodu tohoto typu nepoužívá. Vývojář aplikace, který pracuje se zásobníkem protokolu IP, má tedy na výběr: TCP poskytující spolehlivost, nebo UDP urychlující přenosy.

Jestliže tedy například pracujete s technologií přenosu hlasu VolP (Voice over IP), rozhodně není vhodné zvolit protokol UDP. Pokud by totiž segmenty dorazily v nesprávném pořadí (což se v sítích IP stává velmi běžně), jednoduše by byly předány další vrstvě modelu OSI (ministerstva obrany) v libovolném pořadí tak, jak byly přijaty. Výsledná data by byla nesmyslně promíchána. Oproti tomu protokol TCP řadí segmenty tak, aby je bylo možné sestavit zpět přesně ve stejném pořadí. Tuto možnost protokol UDP jednoduše nenabízí.

Formát segmentu UDP

Obrázek 2.4 jasně dokládá mimořádně nízkou režii protokolu UDP v porovnání s vysokými nároky protokolu TCP. Pečlivě se na toto schéma podívejte. Jak se můžete sami přesvědčit, protokol UDP nepoužívá ve své hlavičce okna a ani neposkytuje potvrzení.

Potřebujete rozumět tomu, jaký význam mají jednotlivá pole v segmentu UDP:

Source port (Zdrojový port): Číslo portu aplikace na straně hostitele, která odesílá data.

Destination port (Cílový port): Číslo portu požadované aplikace v cílovém hostiteli.

Length (Délka): Délka hlavičky UDP a přenášených dat.

Checksum (Kontrolní součet): Kontrolní součet kombinace hlavičky UDP s datovými poli.

Data: Data horní vrstvy.

Protokol UDP stejně jako TCP nespoléhá na vyšší vrstvy a počítá vlastní hodnoty CRC. Pamatujte, že hodnota kontrolního součtu CRC se nachází v poli Frame Check Sequence (FCS). Z tohoto důvodu je uvedena informace FCS.

Následující výpis představuje segment UDP zachycený síťovým analyzátorem:

UDP - User Datagram P rotocol

Source Port : 1 0 85

Destination Port : 513 6

Length : 41

Checksum: Ox7a3c

UDP Data Area :

.. Z ...... 00 Ol 5a 96 00 Ol 00 00 00 00 00 II 0000 00

... C .. 2 . _C . _C 2e 03 00 43 02 1e 32 Oa 00 Oa 00 80 43 00 80

F r ame Check Sequence : OxOOOOOOOO

Všimněte si nízké režie! Pokuste se v segmentu UDP najít pořadové číslo, číslo potvrzení a velikost okna. Nepodaří se vám to, protože tyto hodnoty zde jednoduše nejsou.

Klíčové koncepce protokolů hostitelské vrstvy

Vzhledem k tomu, že už jste získali představu o fungování spojovaného (TCP) i nespojovaného (UDP) protokolu, můžeme nyní shrnout jejich vlastnosti. Tabulka 2. 1 zdůrazňuje některé klíčové aspekty, které byste u těchto protokolů měli mít na paměti. Obsah tabulky byste si měli zapamatovat.

Tabulka 2.1: Klíčové vlastnosti protokolů TCP a UDP

TCP UDP

Řazený Neřazený

Spolehlivý Nespolehlivý

Spojovaný Nespojovaný

Virtuální okruh Nízká režie

Potvrzení Bez potvrzení

Řízení toku dat pomocí oken Bez oken či řízení toku dat

Fungování protokolu TCP lze dobře osvětlit pomocí analogie s telefonními službami. Chcete-Ii s někým mluvit po telefonu, musíte nejdříve s touto osobou navázat spojení, ať už se nachází kdekoli. To je obdobou virtuálního okruhu u protokolu TCP. Když někomu při hovoru sdělujete důležité informace, můžete říci "Představ si" nebo "Rozumíš tomu?". Tyto fráze, které druhou stranu pobízejí, aby zareagovala, velmi připomínají potvrzení u protokolu TCP. Čas od času (zejména při mobilním telefonování) se lidé také ptají "Jsi tam ještě"? Konverzaci ukončují např. pozdravem "Ahoj", aby dali najevo, že telefonát končí. Protokol TCP rovněž poskytuje obdobné funkce.

Oproti tomu použití protokolu UDP se podobá odeslání pohlednice. Jestliže chcete někomu napsat, nemusíte jej nejdříve kontaktovat. Stačí vymyslet zprávu, uvést adresu a hodit lístek do schránky. Můžeme to přirovnat k nespojovanému charakteru protokolu UDP. Zpráva na pohlednici pravděpodobně není životně důležitá, takže nepotřebujete potvrzení jejího příjmu. Ani protokol UDP neposkytuje potvrzení. Podívejte se nyní na další obrázek 2.5, který znázorňuje protokoly TCP a UDP a aplikace, které jsou k jednotlivým protokolům přidruženy.

Čísla portů

Protokoly TCP a UDP musí při komunikaci s vyššími vrstvami používat čísla portů. Tato čísla totiž dovolují rozlišovat různé komunikace, které jsou v síti aktivní ve stejnou dobu. Zdrojový hostitel dynamicky na zdrojové straně přiděluje čísla portů s hodnotou 1 024 a vyšší. Čísla portů do hodnoty 1 023 jsou definována ve standardu RFC 3232 (případně navštivte web www . i ana . o rg), který se zabývá tzv. dobře známými čísly portů. Virtuální okruhy, které nepoužívají aplikaci s dobře známým číslem portu, mají místo toho přidělena náhodná čísla portů z určitého rozsahu. Tato čísla portů identifikují v segmentu TCP zdrojovou a cílovou aplikaci nebo proces.

Obrázek 2.5 dokládá, jakým způsobem protokoly TCP i UDP pracují s čísly portů.

Dále jsou vysvětlena různá čísla portů, které lze použít:

• Čísla nižší než 1 024 se považují za dobře známá čísla portů a jejich definici naleznete v dokumentu RFC 3232.

• Čísla 1 024 a vyšší slouží horním vrstvám k navázání relací s jinými hostiteli a protokol TCP je používá jako zdrojové a cílové adresy v segmentu TCP.

V následujících sekcích si rozebereme výstup analyzátoru s ukázkou relace TCP.

Relace TCP: Zdrojový port

Následující výpis dokumentuje relaci TCP zaznamenanou analytickým softwarem OmniPeek:

TCP - Transport Control Protocol

Source Port : 5973

Destinati on Port : 23

Sequence Number: 1 4 56389907

Ack Number: 1 2 42056456

Offset : 5

Re s e rved : %000000

Code : % 0 110 00

Ack is valid

Push Request

Window : 6 1 320

Checksum: Ox61a6

Urgent Pointer : 0

No TCP Options

TCP Data Area :

vL.5.+.5.+.5.+.5 76 4c 19 35 II 2b 19 35 II 2b 19 35 II

2 b 1 9 3 5 +. II 2b 19

Frame Check Sequence : OxOdOOOOOf

Všimněte si, že zdrojový hostitel určuje hodnotu zdrojového portu, která se v tomto případě rovná 5973. Cílový port má hodnotu 23, která sděluje přijímajícímu hostiteli účel zamýšleného spojení (Telnet). Při pohledu na tuto relaci vidíte, že zdrojový hostitel nastavuje zdrojový port na číslo od 1 024 do 65535. Proč však zdroj pokaždé volí jiná čísla portů? Díky tomu lze totiž rozlišit relace s různými hostiteli. Pokud by server neměl od odesílajícího hostitele jedinečné číslo, jak by věděl, odkud informace pochází? Protokol TCP a protokoly vyšších vrstev nerozlišují odesílajícího hostitele podle hardwarové a logické adresy jako protokoly linkové a síťové vrstvy. Místo toho používají čísla portů. Snadno si můžete představit, jaký zmatek by nastal na straně přijímajícího hostitele, kdyby všichni hostitelé požadovali připojení k FTP pomocí stejného čísla zdrojového portu!

Relace TCP: cílový port

Ve výstupu analyzátoru někdy pouze zjistíte, že zdrojový port má číslo vyšší než 1 024 a cílový port patří mezi dobře známé porty, jak je patrné v následujícím sledování:

TCP - T ransport Control P rotocol

Source Port : 1 1 44

Destinati on Port : 80 Wo rld Wide Web HTTP

Sequence Number: 9356570

Ack Numbe r: O

Offset : 7

Rese rved : %000000

Code : %00 0010

Sy nch Sequence

Window : 8192

Checksum O x 57E7

Urgent Pointer: 0

TCP Options :

O p tio n Type : 2 Maximum Segment Size

Length : 4

MSS : 536

Opti on Type : 1 No Opera t i o n

Option Type : 1 No Opera t i o n

Option Type : 4

Length : 2

Opt Value:

No More HTTP Data

Frame Check Seque nce : Ox4369 7363

Je zřejmé, že zdrojový port má číslo vyšší než 1 024, ale cílový port se rovná 80. Jedná se tedy o službu HTTP. Server (přijímající hostitel) může cílový port v případě potřeby změnit. V předchozím sledování je na cílové zařízení odeslán paket "syn". Sekvence syn sděluje vzdálenému cílovému zařízení, že zdroj požaduje vytvoření relace.

Relace TCP: Potvrzení paketu Syn

Další sledování ukazuje potvrzení paketu syn:

Všimněte si údaje Ack is va1id, který znamená, že zdrojový port byl přijat a zařízení souhlasilo s tím, že s výchozím hostitelem vytvoří virtuální okruh. Na tomto místě se opět můžete přesvědčit, že odpověď serveru obsahuje zdrojový port 80 a cílový port 1 144 odeslaný z původního hostitele. Vše je tedy v pořádku. Tabulka 2.2 uvádí seznam běžných aplikací založených na sadě protokolů TCP/IP, jejich dobře známá čísla portů a rovněž protokoly transportní vrstvy, které každá aplikace či proces používá. Je důležité, abyste si tuto tabulku osvojili. Všimněte si, že systém DNS pracuje s protokoly TCP i UDP. Konkrétní zvolený protokol závisí na požadované operaci. Aplikací, které mohou používat oba protokoly, je sice více, ale tento příklad byste si rozhodně měli pamatovat.

Tabulka 2.2: Klíčové protokoly založené na protokolech TCP a UDP

Poznámka Protokoly TCP/IP a model ministerstva obrany 117 Protokol TCP je spolehlivý díky řazení, potvrzení a řízení toku dat (posunu oken). Protokol UDP spolehlivost neposkytuje