Počítačové a komunikační sítě

FAKULTA ELEKTROTECHNIKY A KOMUNIKAČNÍCH TECHNOLOGIÍ VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ

Počítačové a komunikační sítě

Garant předmětu: Prof. Dr. Ing. Zdeněk Kolka Autor textu: Prof. Dr. Ing. Zdeněk Kolka

BRNO * 2013

Vznik těchto skript byl podpořen projektem č. CZ.1.07/2.2.00/28.0096 Evropského sociálního fondu a státním rozpočtem České republiky.

FEKT Vysokého učení technického v Brně

2

Autor

Prof. Dr. Ing. Zdeněk Kolka

Název


Vydavatel

Vysoké učení technické v Brně Fakulta elektrotechniky a komunikačních technologií Ústav radioelektroniky Purkyňova 118, 612 00 Brno

Vydání

první

Rok vydání

2012

Náklad

elektronicky

ISBN

978-80-214-5171-1

Tato publikace neprošla redakční ani jazykovou úpravou.


3

Obsah OBSAH ...................................................................................................................................... 3 1

ÚVOD ................................................................................................................................. 6

2

POČÍTAČOVÁ SÍŤ .......................................................................................................... 7 2.1 STRUKTURA SÍTĚ ............................................................................................................. 7 2.1.1 Způsob šíření signálu ................................................................................... 7 2.1.2 Geografický rozsah ...................................................................................... 8 2.1.3 Způsob přenosu dat ...................................................................................... 9 2.2 PROTOKOLY ................................................................................................................... 13 2.2.1 Hierarchie protokolů ................................................................................. 13 2.2.2 Služby ......................................................................................................... 15 2.3 MODELY ARCHITEKTUR POČÍTAČOVÝCH SÍTÍ ................................................................. 16 2.3.1 Referenční model ISO OSI ......................................................................... 16 2.3.2 Model TCP/IP ............................................................................................ 18 2.4 SHRNUTÍ KAPITOLY 2 ..................................................................................................... 20

3

APLIKAČNÍ VRSTVA TCP/IP..................................................................................... 21 3.1 ZÁKLADNÍ PRINCIPY SÍŤOVÝCH APLIKACÍ ...................................................................... 21 3.2 PROTOKOL HTTP ............................................................................................................ 23 3.2.1 Základní princip......................................................................................... 23 3.2.2 HTTP dotaz a odpověď .............................................................................. 24 3.2.3 Proxy .......................................................................................................... 30 3.2.4 Cookies....................................................................................................... 31 3.3 FTP ............................................................................................................................... 31 3.3.1 Aktivní režim komunikace protokolu FTP ................................................. 32 3.3.2 Pasivní režim komunikace protokolu FTP ................................................. 33 3.3.3 Příkazy FTP ............................................................................................... 34 3.4 ELEKTRONICKÁ POŠTA................................................................................................... 35 3.4.1 Architektura ............................................................................................... 35 3.4.2 Formát poštovní zprávy ............................................................................. 37 3.4.3 Protokol SMTP .......................................................................................... 38 3.4.4 POP3 .......................................................................................................... 41 3.4.5 IMAP4 ........................................................................................................ 41 3.4.6 MIME ......................................................................................................... 43 3.5 DNS .............................................................................................................................. 47 3.5.1 Architektura ............................................................................................... 47 3.5.2 Dotazy ........................................................................................................ 49 3.5.3 Záznamy v DNS databázi ........................................................................... 51 3.6 SHRNUTÍ KAPITOLY 3 ..................................................................................................... 52

4

TRANSPORTNÍ VRSTVA ARCHITEKTURY TCP/IP ............................................ 53 4.1 ČÍSLA PORTŮ ................................................................................................................. 53 4.2 PROTOKOL UDP ............................................................................................................ 55 4.3 PROTOKOL TCP ............................................................................................................. 55 4.3.1 Základní principy zajištění spolehlivého přenosu ..................................... 55


4 4.3.2 4.3.3 4.3.4 4.3.5

Segmenty TCP ........................................................................................... 60 Navázání a ukončení spojení ..................................................................... 62 Technika okna ........................................................................................... 64 Zahlcení sítě .............................................................................................. 66 4.4 SHRNUTÍ KAPITOLY 4 .................................................................................................... 70 5

SÍŤOVÁ VRSTVA ARCHITEKTURY TCP/IP...........................................................71 5.1 FUNKCE SÍŤOVÉ VRSTVY ............................................................................................... 71 5.2 ZÁKLADY SMĚROVÁNÍ .................................................................................................. 72 5.2.1 Centralizované směrování ......................................................................... 73 5.2.2 Izolované směrovaní .................................................................................. 73 5.2.3 Distribuované metody směrování .............................................................. 74 5.2.4 Hierarchické směrování ............................................................................ 78 5.3 PROTOKOL IP ................................................................................................................ 79 5.4 IP ADRESA ..................................................................................................................... 83 5.4.1 Původní varianta ....................................................................................... 83 5.4.2 Beztřídní adresování ................................................................................. 84 5.4.3 Privátní IP adresy ..................................................................................... 86 5.4.4 Překlad adres (NAT/PAT) ......................................................................... 87 5.5 SMĚROVÁNÍ V IP SÍTÍCH ................................................................................................ 89 5.5.1 Směrovací tabulka ..................................................................................... 89 5.5.2 Struktura sítě ............................................................................................. 92 5.5.3 Protokol RIP .............................................................................................. 93 5.5.4 Protokol OSPF .......................................................................................... 94 5.6 SHRNUTÍ KAPITOLY 5 .................................................................................................... 96

6

DATOVÝ SPOJ A FYZICKÁ VRSTVA .......................................................................97 6.1 ZÁKLADY PŘENOSU DAT................................................................................................ 97 6.2 PŘENOSOVÁ MÉDIA ....................................................................................................... 98 6.2.1 Kroucený dvoudrát .................................................................................... 98 6.2.2 Koaxiální kabel ....................................................................................... 100 6.2.3 Optické vlákno ......................................................................................... 100 6.3 KÓDOVÁNÍ PRO PŘENOS .............................................................................................. 102 6.4 MECHANISMY PRO PŘENOS DAT .................................................................................. 105 6.4.1 Rámce ...................................................................................................... 105 6.4.2 Detekce chyb ........................................................................................... 106 6.5 SHRNUTÍ KAPITOLY 6 .................................................................................................. 109

7

LOKÁLNÍ SÍTĚ.............................................................................................................110 7.1 PŘÍSTUP KE SDÍLENÉMU MÉDIU ................................................................................... 110 7.1.1 Statické přidělování kapacity kanálu ...................................................... 111 7.1.2 Náhodný přístup ke sdílenému médiu ...................................................... 111 7.2 ETHERNET (IEEE 802.3) ............................................................................................. 115 7.2.1 Architektura ............................................................................................. 115 7.2.2 Ethernet 10Mb/s ...................................................................................... 117 7.2.3 Přepínaný Ethernet ................................................................................. 119 7.2.4 Rychlý Ethernet - 100 Mb/s ..................................................................... 120 7.2.5 Gigabitový Ethernet ................................................................................ 127 7.2.6 Ethernet 10 Gb/s...................................................................................... 130 7.2.7 Napájení po Ethernetu (PoE) .................................................................. 132 7.3 PROPOJOVÁNÍ LOKÁLNÍCH SÍTÍ .................................................................................... 133


5

7.3.1 Most / přepínač ........................................................................................ 135 7.4 SHRNUTÍ KAPITOLY 7 ................................................................................................... 140 8

MULTIMEDIÁLNÍ SÍŤOVÉ APLIKACE ................................................................ 141 8.1 ZÁKLADNÍ PRINCIPY .................................................................................................... 141 8.2 PŘENOSY ULOŽENÝCH MÉDIÍ ....................................................................................... 142 8.2.1 Architektura ............................................................................................. 142 8.2.2 Protokol RTSP ......................................................................................... 143 8.2.3 Distribuční sítě......................................................................................... 144 8.3 MULTIMEDIÁLNÍ PŘENOSY V SÍTÍCH TYPU BEST-EFFORT .............................................. 145 8.3.1 Kvalita služeb........................................................................................... 145 8.3.2 Odstranění jitteru..................................................................................... 146 8.3.3 Potlačení vlivu ztráty dat ......................................................................... 148 8.3.4 Protokol RTP ........................................................................................... 149 8.4 IP TELEFONIE – PROTOKOL SIP .................................................................................... 151 8.4.1 Protokol SIP ............................................................................................. 151 8.4.2 Architektura SIP ...................................................................................... 153 8.5 ZAJIŠTĚNÍ KVALITY SLUŽEB V SÍTÍCH IP ...................................................................... 154 8.5.1 Základní principy ..................................................................................... 154 8.5.2 Mechanismy zajištění kvality služeb ........................................................ 155 8.5.3 Integrované služby a diferencované služby ............................................. 157 8.6 SHRNUTÍ KAPITOLY 8 ................................................................................................... 158

9

BEZPEČNOST SÍŤOVÉHO PROVOZU ................................................................... 159 9.1 ZÁKLADNÍ POJMY ........................................................................................................ 159 9.2 SYMETRICKÁ KRYPTOGRAFIE ...................................................................................... 160 9.2.1 Standardy DES a AES .............................................................................. 161 9.2.2 Proudové šifry .......................................................................................... 163 9.2.3 Kryptografie s veřejným klíčem ............................................................... 164 9.2.4 Autentizace ............................................................................................... 165 9.2.5 Integrita zpráv.......................................................................................... 166 9.2.6 Distribuce klíčů ........................................................................................ 168 9.3 ZABEZPEČENÍ SÍŤOVÉHO PROVOZU .............................................................................. 170 9.3.1 E-mail....................................................................................................... 170 9.3.2 SSL ........................................................................................................... 170 9.4 SHRNUTÍ KAPITOLY 9 ................................................................................................... 172

6


1 Úvod Cílem učebního textu je podat přehledovou informaci o síťové komunikaci pro studenty ne-informatických oborů. Výklad je zaměřen na dvě dominující technologie dneška: sítě na bázi protokolu IP a lokální sítě typu Ethernet. Předmět Počítačové a komunikační sítě (MPKS) zařazen do prvního ročníku magisterského studia oboru Elektronika a sdělovací technika. Bezprostředně nenavazuje na žádný předmět. K jeho absolvování postačují znalosti na úrovni bakalářského studia. Jako samozřejmost se předpokládá alespoň pasivní znalost Angličtiny. Kromě přednášek je součástí výuky i laboratorní a počítačové cvičení. Výklad na přednáškách je orientován směrem odshora dolů. Nejdříve se studenti seznámí s aplikacemi, až potom s detaily síťové komunikace.


7

2 Počítačová síť Cíle kapitoly: • Objasnit základní principy síťové komunikace. • Zavést hierarchický model sítě. Termín počítačová sít používáme k označení vzájemně propojené soustavy autonomních počítačů. Požadavek autonomnosti počítačů vylučuje z definice systémy, které jsou pouze ve vztahu nadřízený-podřízený. Systém s jednou řídicí jednotkou a více podřízenými jednotkami není počítačovou sítí [7]. Podstatnou vlastností sítě je, že funguje jako celek, tvořený nejen technickými prostředky, ale také programovým vybavením a konečně i jistými provozními pravidly a zvyklostmi. Uzly mohou v síti vykonávat funkce, podle kterých je můžeme rozdělit zhruba do dvou tříd: 1. Uzly, které jsou zdrojem nebo příjemcem informace (koncové uzly). Tyto uzly tvoří tzv. rozhraní sítě (network edge). 2. Uzly, které zajišťují komunikaci uvnitř dítě (mezilehlé uzly). Ty tvoří tzv. jádro (network core).

Obr. 2.1:

Představa počítačové sítě [1]

2.1 Struktura sítě 2.1.1

Způsob šíření signálu Z hlediska způsobu šíření signálu existují dva typy komunikačních sítí: a) Sítě s dvoubodovými spoji (point-to-point networks)

Přenosová média propojují vždy dvojici uzlů. Jestliže chtějí spolu komunikovat dva uzly, které nesdílejí jednu linku, musí si informace vyměňovat nepřímo - přes jiný uzel. Lokální, geograficky omezené sítě mají obvykle nějakou regulární topologii. Proti tomu je pro


8

rozlehlé, geograficky nijak neomezované sítě typické, že mívají nepravidelnou, obecnou polygonální topologii.

a) hvězda

b) kruh

Obr. 2.2:

c) strom

d) obecná topologie

Síť s dvoubodovými spoji

b) Sítě se spoji s všesměrovým šířením signálu (broadcast networks) Sem patří především radiové sítě – lokální i např. družicové. Se sdílením kabelového média se dnes setkáme snad pouze u pasivních optických přístupových sítí. Systémy s všesměrovým šířením signálu mají jeden komunikační kanál a ten je sdílen všemi uzly v síti. Musí zde existovat efektivní mechanismy pro koordinaci přístupu ke sdílenému médiu. Začnou-li vysílat dva uzly najednou, pak dojde k znehodnocení přenášené informace. Pakety vysílané kterýmkoli uzlem jsou přijímány všemi ostatními. Adresní pole paketu specifikuje, pro koho je paket určen. Uzel po přijetí paketu zkontroluje adresní pole. Pokud je určen pro jiný uzel, ignoruje jej. Existuje možnost adresovat paket všem uzlům tak, že se do adresního pole umístí speciální kód. Paket vyslaný s tímto kódem je přijat a zpracován každým uzlem zapojeným do sítě (broadcasting). Některé systémy s vysíláním s všesměrovým šířením signálu také podporují vysílání podmnožině uzlů, tzv. skupinové adresování (multicasting).

a) sběrnice

Obr. 2.3:

2.1.2

b) radiové sítě

Sítě s všesměrovým šířením

Geografický rozsah a) Lokální sítě

Lokální sítě, LAN (Local Area Networks) jsou sítě pokrývající typicky prostor budovy, několika budov apod. do vzdálenosti několika kilometrů. Propojují osobní počítače a pracovní stanice se souborovými servery, s tiskárnami, atd. Jejich geografický rozměr je shora omezen a mez je známa předem. To podstatně zjednodušuje aplikaci odpovídajících přenosových technologií. Přenos probíhá vesměs bezporuchově, rychlostí 10Mb/s až 10Gb/s a v podstatě bez zpoždění (maximálně v jednotkách mikrosekund). Většina dnešních lokálních sítí je budována ve stromové topologii.


9

b) Metropolitní sítě Metropolitní sítě, MAN (Metropolitan Area Network) jsou vlastně velké LAN. Používají prakticky obdobných technologií jako LAN, jen jejich topologie je polygonální s důvodu zajištění redundance pro případ výpadku některé části (např. překopání kabelu ve městě, dlouhodobější výpadek napájení, apod.). c) Rozlehlé sítě Rozlehlé sítě, WAN, (Wide Area Networks) mohou pokrývat celý kontinent. Topologie je obecná polygonální.

2.1.3

Způsob přenosu dat

Z hlediska způsobu přenosu dat rozlišujeme sítě s přepojováním okruhů (circuit switching) a sítě s přepojováním datových jednotek (packet switching). Pro datové jednotky se používá obecné označení paket. Popisuje-li se konkrétní komunikace, např. v lokální síti, použije se specifické označení, např. rámec (viz další kapitoly).

Obr. 2.4:

Dělení komunikačních sítí [1]

2.1.3.1 Přepojování okruhů Mezi komunikujícími partnery se vytváří dedikovaná komunikační cesta na úrovni fyzických spojů. Jedná se o přenosový režim původně určený pro klasické telefonní analogové prostředí, ve kterém se při navazování spojení vytvářela mezi koncovými komunikujícími partnery galvanická cesta (okruh - circuit) postupným přepojováním úseků telefonních spojů mezi ústřednami. V novějších systémech se nepřepojují celá vedení, ale jen jednotlivé kanály frekvenčního (FDM) nebo spíše časového (TDM) multiplexu. Důležitou vlastností přepojování okruhů je, že se přenosová cesta zřizuje mezi oběma konci dříve, než se mohou přenášet data. Během tohoto intervalu systém vyhledává a ustanovuje přenosovou cestu. Pro mnohé počítačové aplikace je dlouhá doba zřizování spojení nepřijatelná. Důsledkem existence trvalé přenosové cesty mezi zúčastněnými stranami je, že po zřízení cesty je jediným zdržením při přenosu dat doba šíření signálu, tj. asi 6 ms na 1 000 km. Dalším kladným důsledkem zřízení cesty je, že neexistuje nebezpečí přetížení. Kapacita okruhu je přidělena jen jednomu spojení. Přenášená data nemusejí být formátována do paketů ani nemusejí obsahovat adresu příjemce – mezi komunikujícími stranami existuje fyzický kanál.


10

Neefektivita přepojování okruhů je dána i tím, že přenosové prostředky jsou alokovány spojení trvale, bez ohledu na skutečný datový provoz. 2.1.3.2 Přepojování paketů Alternativní strategií k přepojování okruhů je přepojování paketů. Mezi vysílačem a přijímačem zprávy se předem nezřizuje žádná trvalá přenosová cesta. Když vysílač zprávy má zprávu připravenu pro vyslání, je tato zpráva zapamatována v prvním uzlovém bodu sítě a později je vyslána dál. Tento mechanismus se nazývá princip meziskladů (store-andforward). Datová jednotka se nazývá podle vrstev, které spolu komunikují. síťová vrstva: paket –délka je shora omezena datagram – speciálně pro nespojované služby linková vrstva rámec – proměnná, ale omezená velikost buňka – pevná velikost (speciálně pro ATM) Sítě s přepínáním paketů dělíme na datagramové sítě a na sítě s virtuálními okruhy. V případě datagramové sítě se každý paket (datagram) přenáší nezávisle na ostatních. Musí tedy obsahovat adresu příjemce. Datagramy patřící jednomu přenosu mohou být přenášeny různými cestami v síti. Důsledkem toho je, že mohou být přijaty v jiném pořadí, než byly vyslány. Síť s virtuálním okruhy je svým charakterem bližší síti s přepojováním fyzických okruhů. Před zahájením komunikace musí být zřízen virtuální okruh, tj. nakonfigurovány uzlové body tak, aby pakety patřící danému přenosu procházely v síti stejnou cestou. Síť s virtuálními okruhy tedy zachovává pořadí paketů. Pakety musejí obsahovat jen identifikaci virtuálního kanálu (obvykle kratší údaj než adresa příjemce).

a) Obr. 2.5:

b) Datagramová síť a); síť s virtuálními okruhy b)

Přepojování okruhů a přepojování paketů se v mnoha hlediscích liší. Zásadní rozdíl spočívá v tom, že přepojování okruhů požadované pásmo rezervuje dopředu staticky, zatímco přepojování paketů požadované pásmo přiděluje a uvolňuje dle potřeby poněvadž žádné spoje nejsou vyhrazené pro jedinou cestu. Ovšem právě proto, že žádné okruhy nejsou vyhrazené, náhlé zvýšení vstupní zátěže může meziskladový uzel zaplavit, jeho paměťová kapacita se vyčerpá a pakety se mohou ztrácet. Uvažujme konfiguraci na obr. 2.6. N uživatelů

1 Mb/s

Obr. 2.6:

Sdílení linky 1Mb/s


11

Celkem N uživatelů sdílí linku 1Mb/s. Každý uživatel generuje datový tok 100kb/s a je aktivní jen 10% času. V případě přepínání okruhů za použití časového multiplexu (TDM) by linku mohlo sdílet maximálně 10 uživatelů. Linka by však byla po 90% doby nevyužitá. Uvážíme-li přepínání paketů, tak při počtu 35 uživatelů je pravděpodobnost, že jich komunikuje více než 10, menší než 0,0004. S malou pravděpodobností tedy nastane situace, že požadavky na komunikaci přesáhnou kapacitu linky. Uzlový prvek obsahuje vyrovnávací paměť. Tato paměť se přeplní a nově příchozí pakety musí být zahozeny. Nejsou-li učiněna žádná opatření omezující datový tok generovaný koncovými uzly, tak průvodním jevem paketového přenosu je ztráta dat při přetížení. Takové sítě se označují jako best-effort, tj. mají snahu doručit data, ale nic negarantují. Takto v zásadě pracuje Internet. Při průchodu paketu sítí dochází v každém uzlu a každé lince ke zpoždění. Jedná se o zpoždění nutné ke zpracování paketu, zpoždění vzniklé čekáním ve frontě a zpoždění nutné pro přenos mezi dvěma uzly. Uvažujme základní konfiguraci na obr. 2.7. Uzel (v případě datagramové sítě s IP protokolem se jedná o tzv. směrovač) má jednu výstupní linku pro spojení s uzlem B. Na výstupu je vyrovnávací paměť (buffer).

Obr. 2.7:

Zpoždění v uzlu [1]

Zpracování paketu (dproc) Při příjmu paketu musí směrovač podle obsahu hlavičky rozhodnout o odchozím směru. Podle typu přenosové technologie může být navíc provedena kontrola bezchybného přenosu. U výkonných směrovačů toto zpoždění bývá v řádu mikrosekund. Zpoždění ve frontě (dqueue) Ve vyrovnávací paměti čeká paket na odeslání na odchozí linku. Zpoždění závisí na intenzitě provozu. V případě, že je fronta volná, ke zpoždění vůbec nedojde. Typické hodnoty zpoždění jsou v řádu mikrosekund až milisekund. Přenosové zpoždění (dtrans) Uvažujme paket o délce L bitů a rychlost linky R bitů /sec. Doba potřebná k odvysílání paketu bude L/R. Typické hodnoty zpoždění bývají v řádu mikrosekund až milisekund. Zpoždění v přenosovém médiu (dprop) Uvažujme přenosové médium (optické vlákno, volný prostor, atd) o délce d metrů. Rychlost šíření vlny s je typicky 2 108 m/s pro optické vlákno i metalický kabel a 3 108 m/s pro šíření volným prostorem. Zpoždění vzniklé v médiu bude potom d/s.


12

Celkové zpoždění vznikající v uzlu a odchozí lince bude potom d nodal = d proc + d queue + d trans + d prop .

(2.1)

Velmi proměnná je hodnota dqueue, protože závisí na aktuální intenzitě provozu. Uvažujme, že data přicházejí průměrným tokem a paketů/s. Předpokládejme pro jednoduchost, že délka každého paketu je L bitů a kapacita odchozí linky je R b/s. Průměrný tok příchozích dat je La. Potom můžeme podíl La I= (2.2) R označit jako měřítko intenzity provozu. obr. 2.8 ukazuje závislost zpoždění na intenzitě provozu v případě, že máme k dispozici nekonečně velkou vyrovnávací paměť. Blíží-li se intenzita provozu k hodnotě 1, tak zpoždění roste nade všechny meze. Každé reálné zařízení má omezenou velikost vyrovnávací paměti. Pro I→1 dojde k zaplnění vyrovnávací paměti a tím ke ztrátě některých paketů. Uzel je tedy charakterizován nejenom zpožděním, ale také pravděpodobností ztráty paketu.

Obr. 2.8:

Zpoždění ve vyrovnávací paměti [1]

Celkové zpoždění při průchodu sítí je potom dáno jako součet zpoždění vznikajících v každém uzlovém bodu a na spojovacích linkách mezi uzly.

Obr. 2.9:

Program traceroute

Jednoduchým nástrojem pro zjišťování zpoždění v síti Internet je program traceroute (příkaz tracert ve Windows). Program pracuje tak, že nejdříve vyšle paket, který má nastavenou dobu života (TTL) na hodnotu 1. První směrovač, kterým paket prochází, musí dobu života dekrementovat a v případě, že dosáhne hodnoty 0, tak paket zahodí. Odesílatele


13

paketu o tom informuje zprávou protokolem ICMP. Porovnáním času odeslání paketu a příjmu zprávy ICMP dostaneme zpoždění na cestě ke směrovači. Program vyšle postupně 3 pakety s nastavením TTL=1. Získáme tak 3 hodnoty zpoždění k prvnímu směrovači. Poté vyšle další trojici paketů s TTL=2. Získáme tak zpoždění ke druhému směrovači. Proces pokračuje až k dosažení cílové stanice. Na obr. 2.9 je příklad výstupu programu. Zpoždění by mělo narůstat se „vzdáleností“ od vysílací stanice. Vzhledem k tomu, že zpoždění ve směrovačích je náhodné (závisí na intenzitě provozu), tak je možné, že zpoždění ke vzdálenějším uzlům bude v daný okamžik kratší než údaj na předchozím řádku. Časové údaje, které vidíme ve výpisu programu, jsou pouze vzorky náhodné veličiny.

2.2 Protokoly 2.2.1

Hierarchie protokolů

Aby se zjednodušil návrh počítačových sítí, je většina sítí organizována jako hierarchická posloupnost vrstev, obr. 2.10. Počet vrstev, názvy jednotlivých vrstev, obsah každé vrstvy a funkce každé vrstvy se v různých modelech sítě vzájemně liší. Vždy však platí, že smyslem každé vrstvy je nabídnout jisté služby vyšším vrstvám a přitom před nimi ukrýt podrobnosti o tom, jak jsou nabízené služby implementovány. Vrstva n na jednom uzlu konverzuje s vrstvou n na jiném uzlu. Pravidla konverzace jsou souhrnně nazývána protokol vrstvy n. Entity patřící do odpovídajících si vrstev na různých uzlech se nazývají partnerské entity. Jinými slovy, pomocí protokolu komunikují partnerské entity. Protokol lze definovat jako množinu pravidel řídicích výměnu dat mezi komunikujícími entitami. Protokol je dán: •

syntaxí - formáty dat, způsob kódování, tvar signálových prvků, ...

•

sémantikou - řídicí informace pro koordinaci a reakce na chyby, ...

•

časováním - rychlost přenosu, řazení informací, čekacími dobami, ...

Současné protokoly jsou vesměs strukturované, tj. obvykle se používá hierarchicky uspořádaná rodina protokolů - pro řízení přístupu k přenosovému médiu, pro řízení toku, pro chybové řízení, pro směrování apod. Monolitické protokoly se používají pouze výjimečně. Dále rozeznáváme symetrické protokoly, kdy obě komunikující entity mají stejnou funkci a práva, a asymetrické protokoly, ve kterém má jedna z komunikujících entit vyšší pravomoci (klient-server, ... ).

14


Obr. 2.10: Hierarchie protokolů [7] Ve skutečnosti nejsou žádná data z vrstvy n, n = 2, 3... na jednom stroji do vrstvy n na jiném stroji přenášena nějakou cestou realizovanou přímo na úrovni n. Místo toho každá vrstva předá data a řídicí informace vrstvě, která leží bezprostředně pod ní. To se opakuje tak dlouho, dokud se nedosáhne nejnižší vrstvy. Pod vrstvou 1 je fyzické médium, ve kterém se uskutečňuje skutečná komunikace pomocí vhodných signálů. Mezi každou dvojicí sousedních vrstev je definováno rozhraní. Rozhraní definuje, které primitivní operace a služby nižší vrstva nabízí vyšší vrstvě. Jasně vymezené rozhraní usnadní záměnu jedné implementace určité vrstvy jinou implementací (např. telefonní spoje se nahradí družicovými kanály), poněvadž vše, co se po nové implementaci požaduje je, aby poskytovala stejné služby, jaké poskytovala stará implementace. Množina vrstev a protokolů se nazývá síťová architektura.

Obr. 2.11: Princip komunikace entit ve vrstvách [7] obr. 2.11 ukazuje, jak se zabezpečuje komunikace entit nejvyšší vrstvy z obr. 2.10. Entita (proces) ve vrstvě 3 vytvoří zprávu M. Zpráva se předá z vrstvy 3 do vrstvy 2 podle pravidel služeb definovaných rozhraním vrstev 2/3. Vrstva 2 zprávu jistým způsobem


15

transformuje a předá novou zprávu M2 vrstvě 1 podle pravidel rozhraní vrstev 1/2. Zprávu M2 doplní o záhlaví 2, H2 (header). Záhlaví H2 obsahuje řídicí, protokolové informace definující transformaci M → M2 které umožní vrstvě 2 v cílovém uzlu provést zpětnou transformaci M2 na M. V některých vrstvách lze v záhlavích Hi uchovávat pořadová čísla zpráv nebo jejich částí, která umožní na příjmové straně uspořádat části zprávy do správného pořadí, pokud nižší vrstvy toto pořadí nezachovají. V mnoha vrstvách záhlaví obsahuje rovněž informace o velikostech, časech a další řídicí položky potřebných např. pro zabezpečení proti chybám přenosu. Nižší vrstvy mohou zprávu vyšší vrstvy dělit do samostatně přenášených segmentů a opětovně sestavovat ze segmentů původní zprávu apod. Záhlaví bývají uváděna na počátku přenášené datové jednotky, některé vrstvy, obvykle nejnižší, umísťují část záhlaví i na konec přenášené datové jednotky (zabezpečení apod.). Každá vrstva musí mít mechanismus pro identifikaci, protože v síti je obvykle zapojeno více uzlů a v některých uzlech může běžet více procesů. S identifikovaným partnerem lze navázat spojení. 2.2.2

Služby

Aktivní elementy v každé vrstvě se nazývají entity. Entitou může být program (proces) nebo část technického vybavení (inteligentní v/v čip). Entity ve stejné vrstvě různých strojů se nazývají partnerské entity (peer entity). Entity ve vrstvě N implementují službu použitou vrstvou N+1. Vrstva N se nazývá poskytovatel služby (service provider) a vrstva N+1 se nazývá uživatel služby (service user). Vrstva N může pro zabezpečení svých služeb používat služby vrstvy N-1. Vrstva může poskytovat několik tříd služeb, např. spojovanou nebo nespojovanou komunikaci. U spojované služby je před vlastní komunikací nutné zřídit spojení. Po skončení komunikace pak spojení zrušit. Nutnou podmínkou je, aby protistrana souhlasila se spojením. Naproti tomu u nespojované služby se ihned zahájí komunikace. Netestuje se ani souhlas protistrany se spojením. Každou službu lze charakterizovat její kvalitou. Některé služby jsou spolehlivé v tom smyslu, že nikdy neztratí žádná data ani nezmění jejich strukturu. Spolehlivá služba je obvykle implementována tak, že příjemce každé zprávy potvrzuje její přijetí, takže vysílač si je jistý, že zpráva dorazila do určeného cíle. Proces potvrzování zvyšuje režii a zpoždění. Typickou situací, ve které je žádoucí použití spolehlivé spojované služby, je přenos souborů. Spojované služby bývají vesměs spolehlivé. Pro některé aplikace je zdržení způsobené potvrzováním nepřijatelné. Mezi takové aplikace patří přenos digitalizovaného hlasu. Nespolehlivá služba data doručí s vysokou pravděpodobností, nikoli však stoprocentní. Spojovaný charakter služby neznamená, že jde automaticky o službu spolehlivou. V praxi existují všechny 4 kombinace (spojovaná/nespojovaná – spolehlivá/nepolehlivá).


16

2.3 Modely architektur počítačových sítí 2.3.1

Referenční model ISO OSI

Model je nazván Referenční model propojení otevřených systémů (Open System Interconnection Reference Model, RM OSI), poněvadž se týká propojování systémů, které jsou z definice otevřené, tj. jejich rozhraní a protokoly jsou dány veřejně respektovanými (de jure) normami. Model je definován v normě ISO IS 7498 (1984), resp. ITU X.200. Sám model OSI není sítovou architekturou, poněvadž nespecifikuje přesné služby a protokoly pro použití v každé vrstvě. Jeho význam z dnešního pohledu ustupuje. Byl překonán konkurenčním (a jednodušším) modelem TCP/IP v oblasti globálních sítí. Pro nás bude mít spíše význam jako zdroj terminologie.

Obr. 2.12: Referenční model RM OSI [7] Fyzická vrstva Fyzická vrstva se zabývá přenosem bitů (bez ohledu na jejich význam) komunikačním kanálem. Fyzická vrstva definuje kódování, modulace, přenosové rychlosti, obnovu taktu. Její


17

součástí je také definice mechanického provedení konektorů, impedance vedení, vlnové délky, apod. Vrstva datového spoje Hlavním úkolem vrstvy datového spoje (také linkové vrstvy, spojové vrstvy apod.) je dělit vstupní data na datové rámce (typicky několik stovek bytů), tyto rámce postupně vysílat a případně zpracovávat potvrzovací rámce vysílané zpět přijímačem. Poněvadž fyzická vrstva pouze přijímá a vysílá proud bitů bez ohledu na jejich význam a strukturu, musí hranice rámců vytvářet a rozpoznávat linková vrstva. Toho lze dosáhnout např. připojením speciální bitové posloupnosti na začátek a konec rámce. Náhodný šum na spoji může rámec úplně zničit. V takovém případě může vrstva datového spoje vysílače ve výchozím uzlu na požádání rámec vyslat znovu. Opakované vysílání téhož rámce je zdrojem možnosti vzniku duplikovaných rámců. Duplikovaný rámec by mohl být vyslán např. tehdy, kdyby se zničil potvrzovací rámec vysílaný přijímačem zpět vysílači. Problémy způsobené zničením, ztrátou a duplikováním rámců může řešit vrstva spojů nebo některá vyšší vrstva. Dalším problémem, který vzniká ve vrstvě datového spoje (a stejně tak ve většině vyšších vrstev) je způsob zajištění, aby rychlý vysílač nezahltil daty pomalý přijímač. Je třeba použít regulační mechanismus, řízení toku, který vysílači umožní, aby znal, kolik místa má přijímač ve svých vyrovnávacích pamětech. Často je pro zjednodušení regulování toku dat integrováno s řízením po výskytu chyby. V případě sítí s všesměrovým šířením řeší linková vrstva problém soupeření v přístupu k sdílenému přenosovému médiu z hlediska práva vysílat. Síťová vrstva Klíčovým úkolem vrstvy je určení způsobu směrování toku paketů ze zdroje do cíle. Určení směru může být založeno na statických tabulkách, které se mění zřídkakdy. Může být také určeno při každém zahájení konverzace, např. při zahájení relace, při změně konfigurace sítě, v pravidelných intervalech apod. Také lze směr toku paketů směrovat dynamicky, vždy znovu pro každý paket, podle okamžité zátěže sítě apod. Jestliže se do komunikační podsítě dostane najednou příliš mnoho paketů, budou si na svých cestách vzájemně překážet a vytvářet úzká místa. Zvládnutí takového zahlcení patří rovněž mezi funkce síťové vrstvy. V sítích s přímým (všesměrovým) šířením signálu přenosovým médiem je problém směrování triviální, jejich síťová vrstva je bud velmi tenká, nebo vůbec neexistuje. Transportní vrstva Typickými funkcemi transportní vrstvy jsou příjem dat z relační vrstvy (tj. transportních datových jednotek vzniklých ze zpráv aplikačních procesů případně upravených prezentační vrstvou - viz další odstavce), jejich dělení na přenosové (síťové) datové jednotky - pakety, pokud je to nutné, předávání paketů síťové vrstvě a volitelně zabezpečování, že se všechny části zpráv dostanou ve správném pořadí na druhou stranu. Transportní vrstva také určuje, jaký typ služby se poskytuje relační vrstvě a tím i konečným uživatelům sítě. Nejpopulárnější typ transportního spojení je bezchybový dvoubodový kanál, tzv. virtuální kanál, který doručuje zprávy v pořadí jejich vyslání. Jedná se o spojovanou službu. Mezi další typy transportních služeb patří nespojované služby: přenos samostatných zpráv bez záruky pořadí doručení, datagramy, a vysílání zprávy určené více cílům (broadcasting).


18

Transportní vrstva je ta vrstva, která řeší komunikaci koncových uživatelů. V nižších vrstvách jsou provozovány protokoly pro styk dvou bezprostředních sousedů a nikoli zdrojového a cílového uzlu, které mohou být odděleny mnoha mezilehlými uzly. Relační vrstva Relační vrstva umožňuje, aby si uživatelé (procesy) činní v různých uzlech mezi sebou zavedli relace (session). Relace umožňuje běžný přenos dat tak jako transportní vrstva, mimo to však v některých aplikacích poskytuje i propracovanější služby. Prezentační vrstva Typickým příkladem prezentační služby je kódování dat do tvaru, který odpovídá jisté přenosové cestě. Různé počítače zobrazují znakové řetězce různými kódy (ASCII, EBCDIC), celá čísla různým způsobem (přímý kód, doplňkový kód) atd. Aby spolu mohly komunikovat počítače s různou reprezentací těchž informací, vyměňované datové struktury se definují abstraktně, podle normy pro kódování pro sít. Správa těchto abstraktních datových struktur a konverze ze zobrazení použitého uvnitř počítače do normovaného síťového zobrazení je záležitostí prezentační vrstvy. Prezentační vrstva se zabývá i dalšími hledisky zobrazení dat. Například lze použít zhuštění (kompresi) dat pro zmenšení počtu přenášených bitů nebo kryptografii pro zabezpečení utajení a pro ověření věrohodnosti informací. Aplikační vrstva Aplikační vrstva plní řadu všeobecně potřebných protokolů jako např. přenos souborů, elektronická pošta, vzdálené zadávání úloh, apod.

2.3.2

Model TCP/IP

Zkratka TCP/IP označuje celou soustavu protokolů a ucelenou soustavu názorů o tom, jak by se počítačové sítě měly budovat, a jak by měly fungovat. Hlavní odlišnosti mezi referenčním modelem ISO/OSI a TCP/IP vyplývají především z rozdílných výchozích předpokladů a postojů jejich tvůrců. Při koncipování referenčního modelu ISO/OSI měli hlavní slovo zástupci spojových organizací, které kladli důraz na vlastnosti sítě (především spojovaný a spolehlivý charakter služeb) s tím, že k ní připojované hostitelské počítače budou mít relativně jednoduchou úlohu. Později se ale ukázalo, že například právě v otázce zajištění spolehlivosti to není nejšťastnější řešení - že totiž vyšší vrstvy nemohou považovat spolehlivou komunikační síť za dostatečně spolehlivou pro své potřeby, a tak se snaží zajistit si požadovanou míru spolehlivosti vlastními silami. V důsledku toho se pak zajišťováním spolehlivosti do určité míry zabývá vlastně každá vrstva referenčního modelu ISO/OSI. Tvůrci protokolů TCP/IP naopak vycházeli z předpokladu, že zajištění spolehlivosti je problémem koncových účastníků komunikace, a mělo by tedy být řešeno až na úrovni transportní vrstvy. Komunikační síť pak podle této představy nemusí ztrácet část své přenosové kapacity na zajišťování spolehlivosti (na potvrzování, opětné vysílání poškozených paketů atd.), a může ji naopak plně využít pro vlastní datový přenos. V komunikační síti může docházet ke ztrátám přenášených paketů, a to bez varování a bez snahy o nápravu. Na rozdíl od referenčního modelu ISO/OSI tedy TCP/IP předpokládá jednoduchou (ale rychlou) komunikační síť, ke které se připojují inteligentní hostitelské počítače. Protokol TCP/IP předpokládá nespojovaný charakter přenosu v komunikační síti - tedy jednoduchou datagramovou službou a obsahuje jen čtyři vrstvy, obr. 2.13.


19

Obr. 2.13: Referenční model TCP/IP [9] Vrstva síťového rozhraní Nejnižší vrstva, vrstva síťového rozhraní (Network Interface Layer) (dle OSI spojová vrstva) má na starosti vše, co je spojeno s ovládáním konkrétní přenosové cesty resp. sítě, a s přímým vysíláním a příjmem datových paketů. V rámci soustavy TCP/IP není tato vrstva blíže specifikována, neboť je závislá na použité přenosové technologii. Vrstvu síťového rozhraní může tvořit relativně jednoduchý ovladač (device driver), je-li daný uzel přímo připojen například k lokální síti či ke dvoubodovému spoji, nebo může tato vrstva představovat naopak velmi složitý subsystém, s vlastním linkovým přenosovým protokolem. Vrstva síťová Vyšší vrstva, která již není závislá na konkrétní přenosové technologii, je vrstva síťová, v terminologii TCP/IP označovaná jako Internet Layer (volněji: vrstva vzájemného propojení sítí), nebo též IP vrstva (IP Layer) podle toho, že je realizována pomocí protokolu IP. Úkol této vrstvy je to, aby se jednotlivé pakety dostaly od odesilatele až ke svému skutečnému příjemci, přes případné směrovače resp. brány. Vzhledem k nespojovanému charakteru přenosů v TCP/IP je na úrovni této vrstvy zajišťována nespolehlivá datagramová služba. Transportní vrstva Třetí vrstva TCP/IP je označována jako transportní vrstva (Transport Layer), nebo též jako TCP vrstva (TCP Layer), neboť je nejčastěji realizována právě protokolem TCP (Transmission Control Protocol). Hlavním úkolem této vrstvy je zajistit přenos mezi dvěma koncovými účastníky, kterými jsou v případě TCP/IP přímo aplikační programy (jako entity bezprostředně vyšší vrstvy). Podle jejich nároků a požadavků může transportní vrstva regulovat tok dat oběma směry, zajišťovat spolehlivost přenosu, a také měnit nespojovaný charakter přenosu (v síťové vrstvě) na spojovaný. Přestože je transportní vrstva TCP/IP nejčastěji zajišťována právě protokolem TCP, není to jediná možnost. Dalším používaným protokolem na úrovni transportní vrstvy je protokol UDP (User Datagram Protocol), který na rozdíl od TCP nezajišťuje spolehlivost přenosu. • Protokol TCP realizuje spojovanou spolehlivou službu, tj. příjemce přímo potvrzuje přijímaná data.


20 •

Protokol UDP realizuje nespojovanou nespolehlivou službu, tj. přenáší data pomocí datagramů aniž se zajímá, zda-li byla doručena. Vrstva aplikační

Nejvyšší vrstvou TCP/IP je pak vrstva aplikační (Application Layer). Jejími entitami jsou jednotlivé aplikační programy, které na rozdíl od referenčního modelu ISO/OSI komunikují přímo s transportní vrstvou. Případné prezentační a relační služby, které v modelu ISO/OSI zajišťují samostatné vrstvy, si zde musí jednotlivé aplikace v případě potřeby realizovat samy. V dalším textu bude dána přednost modelu TCP/IP. Názor na nejnižší čtyři vrstvy ISO modelu je v podstatě ustálený. Proto se běžně používá např. označení Layer 2 (nebo L2) pro linkovou vrstvu (např. Ethernet).

2.4 Shrnutí kapitoly 2 V dnešní době jsou dominantně využívány sítě s přepínáním paketů. Tako technika lépe využívá dostupné síťové prostředky. Na druhou stranu přináší problémy se zajištěním kvality služeb (QoS). Použitý komunikační protokol vždy reprezentuje kompromis mezi využitím linek a poskytovanou kvalitou služby. Hierarchický pohled na síť pomáhá zjednodušit proces návrhu protokolů i vývoj hardwarových prvků. Počítačové sítě dneška jsou doménou protokolové sady TCP/IP. Zavádění prvků QoS umožňuje přechod od původních datových přenosů k využití i pro multimediální a telekomunikační aplikace.


21

3 Aplikační vrstva TCP/IP Cíle kapitoly: • Popis základních aplikací sady TCP/IP: www, elektronická pošta, přenosy souborů FTP, služební protokol DNS.

3.1 Základní principy síťových aplikací Síťovou aplikaci tvoří vždy dvě komunikující entity, přesněji řečeno dva vzájemně komunikující procesy (programy) běžící na koncových stanicích. Komunikující strany si vyměňují zprávy, jejichž formát, význam a časování jsou popsané příslušným komunikačním protokolem. V zásadě rozlišujeme dva způsoby komunikace: klient – server a peer to peer (P2P, komunikace rovnocenných uzlů). V architektuře klient – server existuje na jedné straně proces, který je vždy spuštěn, a který očekává na spojení od klienta. Většina síťových aplikací je založena na tomto modelu (např. protokoly http, ftp, smtp, apod.). Klienti spolu navzájem nekomunikují. Označení klient a server platí pro procesy (programy). Často se však označení server používá i pro počítač, na kterém jsou spuštěné serverové procesy. V čisté architektuře peer to peer (P2P) komunikují spolu rovnocenné procesy. Neexistuje zde žádný centrální prvek – server. Tento model je oblíbený pro aplikace na sdílení dat mezi uživateli. Existují i hybridní architektury, kdy klienti potřebují pro navázání spojení služeb serveru (např. ICQ nebo Skype).

L4

AP1 AP2

AP3

UDP

TCP

IP address Obr. 3.1:

port

AP1 AP2

AP3

UDP

TCP

full duplex channel

Vazba transportní a aplikační vrstvy

Na obr. 3.1 je struktura aplikační vrstvy modelu TCP/IP. Nižší vrstvy komunikační hierarchie jsou vždy součástí operačního systému, protože přistupují k hardware a jejich služby jsou sdíleny všemi procesy. V případě TCP/IP jsou součástí OS první čtyři vrstvy, tj. až po transportní vrstvu (L4). Každý program musí k těmto službám přistupovat přes tzv. aplikační rozhraní (API). Pro aplikace k dispozici dvě služby – spojovaná a spolehlivá služba (běžně se označuje názvem protokolu – TCP) a nespojovaná a nespolehlivá služba (UDP). Koncový uzel je v síti IP identifikován svojí IP adresou (32b u stávajícího protokolu IPv4). V aplikační vrstvě však existuje více procesů, které současně komunikují. Pro rozlišení mezi těmito aplikacemi se používá číslo portu. Jedná se v podstatě o adresu v rámci uzlu. Číslo portu je 16-bitové a je


22

samostatné pro TCP a pro UDP. Komunikující proces je charakterizován třemi údaji: IP adresou, protokolem a číslem portu. TCP Služba TCP je spojovaná, tj. před zahájením komunikace musí dojít k otevření komunikačního kanálu, které je realizované výměnou zpráv mezi transportními vrstvami. Komunikační kanál je vždy plně duplexní. Z principu je možná pouze komunikace bod – bod. Po skončení spojení se komunikační kanál prostřednictvím výměny zpráv transportní vrstvy uzavře. Spolehlivosti služby TCP se dosahuje potvrzováním přijatých dat. V případě ztráty dat je provedeno jejich opětovné odvysílání. Je třeba si však uvědomit, že nižší vrstvy Internetu (síťová i linková) pracují na nespojovaném a nespolehlivém principu. Kanál TCP je vytvářen softwarově až na koncových stanicích. Protokol TCP v původní verzi není schopen garantovat přenosovou rychlost ani časování. Z hlediska aplikační vrstvy se služba TCP jeví jako kanál pro přenos neformátovaného proudu dat (byte stream). Odesílatel samozřejmě data vkládá do kanálu po blocích. Stejně tak příjemce čte data po blocích. Velikost těchto bloků však spolu nijak nesouvisí. Např. příjemce může přečíst část většího bloku dat, který se stále ještě přenáší. Vyžaduje-li aplikace komunikaci diskrétními zprávami, tak určení hranice mezi zprávami musí být realizováno v samotném protokolu. Velmi častá je textová komunikace, kdy přirozeným oddělovačem zpráv je znak konce řádku. UDP Protokol UDP poskytuje nespojovanou a nespolehlivou službu. Před zahájením komunikace není třeba otevírat kanál. Doručení dat příjemci není garantováno. UDP je vhodný pro komunikační protokoly založené na výměně diskrétních zpráv, které tolerují jejich eventuální ztrátu. Protokol UDP je možné využít pro tzv. hromadné vysílání (multicast) využívání v multimediálních aplikacích. UDP dělí přirozeným způsobem data do bloků. Příjemce čte datagramy přesně tak, jak byly odvysílány. Vždy načte celý datagram. Jen pořadí datagramů se může (teoreticky) lišit. Každý komunikační protokol požaduje jistou kvalitu služeb poskytovanou nižšími vrstvami komunikační hierarchie. Kvalitu služby můžeme posuzovat podle více hledisek: - spolehlivost přenosu – některé aplikace vyžadují zcela spolehlivý přenosový kanál (např. přenos souborů, www stránek apod.). Existují však i aplikace, které tolerují jistou ztrátu dat (např. IP telefonie a jiné multimediální služby). - požadavky na přenosovou rychlost – multimediální služby vždy vyžadují jistou garanci minimální přenosové rychlosti. Naopak přenosy souborů nejsou na změnu přenosové rychlosti citlivé (tedy kromě doby trvání přenosu). - časování - služby pracující v reálném čase kladou požadavky na maximální přenosové zpoždění a na variabilitu tohoto zpoždění (jitter). Tabulka uvádí požadavky na transportní vrstvu pro některé významné aplikace [1].


23

3.2 Protokol http 3.2.1

Základní princip

Existují 3 verze protokolu – 0.9, 1.0 a 1.1. V dnešní době je dominantní verze 1.1 (RFC 2616). Základní architekturou komunikace v protokolu http je komunikace klient/server. V případě, že se navazuje přímé spojení protokolem TCP mezi klientem a serverem (obr. 3.2), uživatel zapíše do okna prohlížeče identifikátor objektu (URI), jež chce prohlížet, a klient nejprve z identifikátoru objektu vyřízne jméno serveru, které přeloží za pomoci DNS na IP-adresu. Poté klient naváže s takto získanou IP-adresou serveru spojení protokolem TCP. Do vytvořeného kanálu TCP vloží prohlížeč http dotaz, na který v témže spojení server odpoví. Prohlížeč následně zobrazí odpověď uživateli. Každá webová-stránka se většinou skládá z řady objektů. Každý objekt je nutné z webového serveru stáhnout jedním http dotazem. V protokolu http starších verzí se pro každý dotaz vždy navazovalo nové TCP spojení. Takže prvním dotazem se stáhl základní text stránky, ve kterém byla řada dalších odkazů, jež bylo nutné stáhnout pro zobrazení stránky. V dalším kroku se navázalo s webovým-serverem pro stažení každého objektu jedno TCP spojení. Tato strategie vede k vytvoření špičky v zátěži přenosové cesty.

Obr. 3.2:

Architektura http [1]


24

Protokol http verze 1.1 implicitně předpokládá, že TCP spojení bude mezi klientem a serverem navázáno jedno pro celou sadu dotazů (tzv. perzistentní spojení). Je možné jej samozřejmě uzavřít po jednom dotazu i po více dotazech. Klient může dokonce odeslat v jednom spojení více dotazů, aniž by čekal na vyřízení předchozího dotazu (tzv. pipelining). Komunikace v protokolu http se zásadně skládá z dotazu a odpovědi. Relace mezi klientem a serverem je tvořena vždy pouze dotazem a odpovědí na tento dotaz. Říkáme, že http je bezstavový protokol. Skutečnost, že protokol http neumožňuje delší dialog než jeden dotaz a bezprostřední odpověď na něj, je jistým omezujícím limitem. Prakticky může nastat následující situace: uživatel chce pomocí protokolu http nakupovat ve virtuálním obchodním domě na Internetu. Vybere si zboží, které si uloží do virtuálního nákupního košíku, a ten si nese během svého nákupu. Informace o stavu „nákupu“ je uchovávána na straně klienta prostřednictvím tzv. cookies. Na obr. 3.3 jsou časové diagramy tří základních metod komunikace protokolem http. Předpokládejme, že stránka obsahuje N objektů a „vyřízení“ každého dotazu včetně navázání spojení trvá včetně přenosu čas RTT (round-trip time). Předpokládá se dominantní zpoždění na přenosových linkách.

init

initiate TCP connection RTT

init

RTT request 1

request file

time to transmit file

RTT

time to transmit file

RTT

request 1 request 2 request 3

request 2

file received time

Pipelining time

neperzistentní Obr. 3.3:

time

time

time

time

perzistentní perzistentní+pipelining Způsoby komunikace protokolem http [1]

Klasická varianta komunikace otvírá pro stránku samotnou a všechny objekty vždy nové spojní. Celkový čas pro načtení stránky bude (nejhorší varianta) t1 = ( N + 1) 2 RTT . (3.1) U perzistentní varianty pak t2 = ( N + 2) RTT . (3.2) Komunikace s překrýváním (pipelining) bude vyžadovat čas t3 = 2 RTT . (3.3)

3.2.2

HTTP dotaz a odpověď

Identifikátorem objektů ve webovém světě jsou tzv. URI (Uniform Resource Identifiers). URI mohou být: Uniform Resource Names (URN), Uniform Resource Locators (URL) a Uniform Resource Characteristics (URC). V praxi se setkáváme pouze s URL.


25

Jednotlivé aplikační protokoly mají své schéma URI (RFC-1738): <schéma>: kde <schéma> může mj. být: http Protokol http ftp Protokol FTP mailto Odeslání elektronické pošty (protokol SMTP) nntp Protokol NNTP (diskusní skupiny) Telnet Odkaz na relaci protokolem Telnet file Soubor (např. na disku) Ve schématu (nikoliv v celém URI) nezávisí na tom, použijeme-li velké nebo malé písmeno, tj. ftp je totéž jako FTP či Ftp. V celém URI se mohou vyskytovat pouze znaky kódu US-ASCII. V případě, že je nutné zadat jiný znak, uvede se tento znak znakem % následovaným šestnáctkovým vyjádřením znaku. Např. mezera je „%20“ (2016=3210). V šestnáctkovém vyjádření znaku můžeme psát jak velká písmena, tak i malá písmena pro šestnáctkové číslice A až F. Znaky „;“, „/“, „?“, „:“, „@“, „=“ a „&“ jsou vyhrazeny pro speciální použití, tj. mají-li se použít v nějakém řetězci, musí být konvertovány do šestnáctkové soustavy a uvozeny procentem. Schéma http http://<server>:<port>/?<dotaz>#

Uživatel a heslo slouží pro autentizaci klienta. Heslo se obecně nedoporučuje zadávat v URI. Není-li heslo zadáno, protokol http si jej vyžádá dodatečným dialogem. V případě, že se za jménem uživatele uvede dvojtečka, za kterou okamžitě následuje název serveru, zadali jsme jméno uživatele a prázdný řetězec jako heslo. Je-li zadáno jméno uživatele (resp. jméno uživatele a heslo), pak jméno serveru musí začínat znakem @. Port protokolu TCP je uveden za dvojtečkou. Chceme-li použít implicitní port 80, neuvedeme ani dvojtečku, ani číslo portu. Cesta obsahuje identifikaci souboru skládající se z (virtuálních) adresářů oddělených opět lomítkem a jména souboru. Za otazníkem následuje řetězec dotazů. Dvojitý kříž specifikuje odkaz na fragment webové-stránky. Webová-stránka může být větší, než je okno na obrazovce. Webovou-stránku je možné rozdělit na fragmenty, jejichž počátek je identifikován jako . Pokud chceme, aby od levého horního okraje obrazovky byl zobrazován právě , použijeme uvedený odkaz. Příklady: 1.

http://server.firma.cz

je dotazem anonymního klienta na obsah kořenového adresář serveru server. firma. cz. 2.

http://[email protected]

je dotazem uživatele novak na obsah kořenového adresáře serveru server.firma.cz. Pokud je pro tohoto uživatele požadováno serverem heslo, bude vyžádáno následným dialogem. 3.

http://server.firma.cz/cgi-bin/formular.exe?pole1=%20&pole2=hod2

Anonymní uživatel spustí program formular.exe z adresáře cgi-bin. Tomuto programu bude předán řetězec pole1=%20&pole2=hod2. Jedná se o formulář obsahující dvě pole:


26

pole1 a pole2. pole1 obsahuje mezeru (mezera je šestnáctkově 20) a pole2 obsahuje hodnotu hod2. 4.

http://server.firma.cz/adrl/adr2/dokument.htm#odstavec5

Anonymní uživatel požaduje zobrazit obsah dokumentu dokument.html z adresáře /adrl/adr2. Přitom si při zobrazování tohoto dokumentu přeje, aby byl zobrazen začátek fragmentu odstavec5. Nezačíná-li URI názvem schématu, jedná se o relativní URI. Relativní URI je vždy vztaženo k nějaké bázi - nějakému absolutnímu URI. Bází může být URI zobrazovaného dokumentu nebo případně i předešlého dokumentu, tj. URI dokumentu, ze kterého byl odkaz proveden. V případě, že žádné takové URI neexistuje, může být použito implicitní URI celé aplikace. Relativní URI může obsahovat v cestě dokonce znak ,,.“ a znak „..“ pro odkaz na aktuální a nadřízený adresář. Struktura http dotazu (i odpovědi) se na první pohled liší pouze v prvním řádku. První řádek dotazu obsahuje tzv. metodu a první řádek odpovědi obsahuje tzv. stavový řádek. • •

• •

HTTP dotaz se skládá (obr. 3.4) z: Metody. Protokol http verze 1.1 podporuje metody: GET, POST, HEAD, OPTIONS, TRACE, CONNECT, PUT a DELETE. Metody PUT a DELETE nebývají implementovány. Záhlaví, které je tvořeno jednotlivými hlavičkami. Každá hlavička začíná klíčovým slovem (např. Host: ). Klíčové slovo je ukončeno dvojtečkou následovanou mezerou. Za mezerou pak mohou následovat parametry hlavičky. Celá hlavička je vždy ukončena koncem řádku CRLF. Pouze jediná hlavička je povinná, a to hlavička Host. Prázdného řádku. Přenášených dat (volitelně).

Obr. 3.4:

Struktura a příklad http dotazu [3]

Metoda má v protokolu http verze 1.1 vždy tvar: HTTP/1.1 GET / HTTP/1.1 kde verze protokolu je 1.1, což je tč. aktuální verze. Uvedení verze je povinné. Pokud bychom uvedli jen název metody a URI, jednalo by se o dotaz v protokolu HTTP verze 0.9.


27

Metoda GET Metoda GET slouží k dotazování klienta na konkrétní informace (stránky) uložené na serveru. Metoda GET může teoreticky obsahovat i data, avšak tato možnost bývá zřídka využívána (data se přenesou jako součást dotazu – za otezníkem).

C: C: C: S: S: S: S: S: S: S: S: S: S: S: S: S: S: S:

Příklad komunikace (C = klient, S = server): GET / HTTP/1.1 Dotaz na výchozí stránku Host: www.vutbr.cz Prázdný řádek ukončující záhlaví HTTP/1.0 200 OK Date: Wed, 20 Dec 2000 17:20:18 GMT Last-Modified: Mon, 10 Apr 2000 07:14:43 GMT Content-Length: 2855 Server: Apache/1.2b10 ETag: "e9ed-b27-38f17f63" Accept-Ranges: bytes Content-Type: text/html Prázdný řádek ukončující záhlaví odpovědi <TITLE>VUT v Brně

HTML dokument

V protokolu http verze 1.1 je povinná hlavička Host, která obsahuje jméno serveru. Je to nutné pro techniku virtuálních serverů, kterou využívají poskytovatelé www hostingu. Existuje řada jmen (např. www.firma1.cz, www.firma2.cz, atd.), která ukazují na stejnou IP adresu serveru poskytovatele. Hlavička Host právě umožňuje rozlišit, s jakým virtuálním serverem si uživatel přeje komunikovat. Odpověď na metodu GET / (hlavní stránka) je samozřejmě pro každý virtuální server jiná. Odpověď obsahuje několik zajímavých hlaviček: • Date: Datum a čas, kdy byla odpověď vytvořena. • Last-Modified: Čas poslední modifikace zdroje (webové-stránky). • Content-Length: Délka dat odpovědi v bajtech. • Accept-Ranges: Informace o tom, že server akceptuje dotazy, které jsou zaslány v několika částech (velikost částí se udává v bajtech). • ETag: Jednoznačně identifikuje verzi odpovědi. Pokud je v paměti Cache odpověď stejné verze jako na serveru, jsou obě odpovědi shodné. Metodou GET můžeme pokládat též podmíněné dotazy za využití hlaviček IfModified-Since, If -Unmodified-Since, If-Match, If-None-Match a If-Range. Tyto dotazy umožňují přenášet data odpovědi jen v případě, že podmínka v dotazu je pravdivá. Hlavičky If-Modified-Since a If-Unmodified-Since vyhodnocují datum poslední modifikace. C: GET / HTTP/1.1 C: Host: www.vutbr.cz C: If-Modified-Since: Mon, 10 Apr 2000 07:14:43 GMT


28 C: S: S: S: S:

HTTP/1.1 304 Not Modified Date: Sat, 23 Dec 2000 19:07:48 GMT Server: Apache/1.2b10 ETag: "e9ed-b27-38f17f63"

A jelikož se příslušná stránka nezměnila, vrátí nám server pouze hlavičku s informací o tom, že se stránka nezměnila. V opačném případě použijeme hlavičku If-Unmodified-Since. Metoda POST Metodou POST odesíláme na server data (např. pole HTML-formuláře). Metoda HEAD Metoda HEAD požaduje pouze hlavičku odpovědi bez dat. Metoda TRACE Je jakousi obdobou příkazu traceroute. Určuje, kolik je mezi naším a cílovým počítačem proxy nebo bran. Metoda OPTIONS Metoda OPTIONS se používá ke zjištění komunikačních vlastností serveru či požadovaného URI. V případě, že se dotazujeme na vlastnosti celého serveru, použijeme místo URI hvězdičku: C: OPTIONS * HTTP/1.1 C: Host: www.vutbr.cz C: S: HTTP/1.1 200 OK S: Date: Sat, 23 Dec 2000 19:11:22 GMT S: Server: Apache/1.2b10 S: Content-Length: 0 S: Allow: GET, HERD, OPTIONS, TRACE HTTP odpověď HTTP odpověď začíná stavovým řádkem ve tvaru: Kde verze je verzí protokolu http, ve které je odpověď formulována. Výsledkový kód specifikuje úspěšnost/neúspěšnost operace a poznámka textově objasňuje výsledek operace. Za stavovým řádkem následuje opět záhlaví tvořené hlavičkami. Záhlaví je ukončeno prázdným řádkem, který odděluje záhlaví od přenášených dat. Příklad stavového řádku (kladná odpověď): HTTP/1.1 200 OK Výsledkové kódy jsou trojciferné. První cifra určuje druh odpovědi: • lxx - informativní odpověď, zpracování pokračuje dále. • 2xx - akce proběhla úspěšně.

Počítačové a komunikační sítě • • •

29

3xx - přesměrování, tj. další akce se bude tykat jiného URI. 4xx - chyba klienta (např. syntaktická chyba v dotazu). 5xx - chyba serveru (např. chyba CGI-skriptu).

Některé výsledkové kódy: 100 Continue 101 Switching Protocols 200 OK 300 Multiple Choices 301 Moved Permanently

403 Forbidden 404 Not Found 405 Method Not Allowed 406 Not Acceptable 414 Request-URI Too Large 415 Unsupported Media Type 501 Not Implemented 502 Bad Gateway

Ostatní hlavičky Hlavičky Accept Hlavičkami Accept, Accept-Charset, Accept-Encoding a Accept-Language sděluje klient ve svém dotazu své možnosti. Každá z těchto hlaviček může obsahovat několik eventualit oddělených čárkou. U každé možnosti může být za středníkem uvedena kvalita (q). Kvalita je číslo mezi 0 a 1. Čím vyšší má eventualita kvalitu, tím více ji klient preferuje (implicitně se předpokládá q=1). Pro specifikaci eventuality je možné uvést hvězdičku označující všechny možnosti. Hlavičkou Accept klient specifikuje podporované typy médií. Např.: Accept: text/*;q=0.3, text/html, image/jpeg;q=0.7, model/vrml, */*;q=0.1

Říká, že klient upřednostňuje: 1. model/vrml s kvalitou 1, 2. text/html s kvalitou 1, 3. image/jpeg s kvalitou 0,7, 4. libovolný text s kvalitou 0,3, 5. libovolné médium s kvalitou 0,1. Hlavičkou Accept-Charset klient specifikuje podporované znakové sady: Accept-Charset: iso-8859-5, unicode-l-l;q=0.8, *;q=0.1 Říká, že klient upřednostňuje znakovou sadu iso-8859-5 (s kvalitou 1), dále s kvalitou 0.8 podporuje znakovou sadu unicode-l-1. Jinak podporuje libovolnou znakovou sadu s kvalitou 0.1. Přesměrování Může se stát, že požadovaný objekt byl přemístěn na jiné URI (např. na jiný server či do jiného adresáře). V takovém případě server vrátí stavový řádek s výsledkovým kódem 3xx a hlavičkou: Location: nové-URI HTTP/1.1 301 Moved Permanently


30

Location: http://www.firma.cz/soubor

3.2.3

Proxy

Proxy je systém skládající se ze dvou částí: 1. Ze serverové části, která přijímá požadavky klienta jakoby je přijímal cílový server. Požadavky však vzápětí předá klientské části. 2. Z klientské části, která převezme požadavky od serverové částí, naváže TCP spojení s cílovým serverem a předá jménem klienta požadavky cílovému serveru k vyřízení. Takto se Proxy jeví uživateli. Avšak uprostřed Proxy mezi serverovou a klientskou částí je ještě skryta vlastní logika Proxy. Proxy totiž rozumí aplikačnímu protokolu (v našem případě protokolu http) a s přijatým požadavkem od klienta může provést několik operací: 1. Může přepsat požadavek (resp. odpověď), tj. změnit data aplikačního protokolu. 2. Odpovědi může ukládat do paměti Cache (např. na disk). Pokud proxy obdrží v budoucnu stejný požadavek (např. i od jiného klienta), může tento požadavek vrátit rychleji přímo z paměti, aniž by navazovala spojení s cílovým serverem. Díky používání dynamických stránek, stavových transakcí a zabezpečovaných spojení a v neposlední řadě zvýšení propustnosti komunikačních linek začíná význam paměti Cache na Proxy ustupovat. 3. Může zjišťovat, zdali je klient oprávněn takový požadavek provést (např. podle IP adresy). Může požadovat autentizaci.

Obr. 3.5:

Činnost Proxy [3]

Na obr. 3.5 je schematicky znázorněna činnost proxy. Klient naváže TCP komunikaci se serverovou částí proxy na portu uvedeném v konfiguraci klienta (např. 8080). Do takto vytvořeného TCP spojení vloží klient svůj http požadavek:


31

GET http://www.server.cz/soubor.htm HTTP/1.1 Host: www.server.cz Proxy ve své paměti Cache prověří, nemá-li odpověď na tento požadavek náhodou k dispozici. V případě, že požadavek v paměti Cache nebyl nalezen, předá požadavek klientské části na vyřízení. Klientská část proxy naváže spojení s cílovým serverem protokolem TCP a předá mu požadavek jménem klienta. Server vrátí odpověď. Pokud je odpověd přípustné uložit do paměti Cache, uloží ji tam. Proxy předá odpověď klientovi. 3.2.4

Cookies

Protokol http je bezstavový. To neumožňuje udržet mezi klientem a serverem relaci skládající se z řady odpovědí a dotazů. Není možné předat nějakou informaci mezi dvěma dotazy na server. RFC-2965 řeší tento problém zřízením jednoduché relace, během které je možné, aby informace z odpovědi byly předány do dalšího dotazu. Tyto informace se nazývají cookie. Server ve své odpovědi hlavičkou Set-Cookie2 předá klientovi stavovou informaci. Klient pak může tuto informaci ve svém dalším dotazu zopakovat. Moderní prohlížeče dovolují cookies zakázat (pak ovšem přestanou některé stránky pracovat). Příklad použití: 1. Klient vejde úvodní stránkou http://www.virtualni.obchodni.dum.cz/obchod/vstup do virtuálního obchodního domu, tj. klient odešle http dotaz: C: GET /obchod/vstup HTTP/1.1 2. Server přiřadí klientovi identifikaci při vstupu pomocí hlavičky Set-Cookie2: S: HTTP/1.1 200 OK S: Set-Cookie2: Zakaznik="007"; Version="1"; Path="/obchod" 3. Klient si vybere zboží. V dotazu na server „zopakuje“ dosavadní obsah cookie C: POST /obchod/saka HTTP/1.1 C: Cookie: Version="1"; Zakaznik="007"; Path="/obchod" 4. Server vrátí identifikaci vybraného zboží: S: HTTP/1.1 200 OK S: Set-Cookie2: Version="1"; Zbozi="sako_O5"; Path="/obchod" 5. Klient dorazil na pokladnu a přeje si potvrdit objednávku: C: POST /obchod/doprava HTTP/1.1 C: Cookie: Version=“1“; Zakaznik="007"; Path="/obchod"; Zbozi="sako_05"; Path="/obchod" 6. Serveru už zbývá jen potvrdit objednávku: S: HTTP/1.1 200 OK Tím je relace skončena.

3.3 FTP Protokol FTP (RFC-959, 2228, 2640) slouží pro přenos souborů v počítačových sítích na bázi protokolu TCP/IP. Architektura protokolu FTP je znázorněna na obr. 3.6. Uživatel


32

pracuje s uživatelským rozhraním. To bývá bud jako příkazový řádek programu ftp, nebo jako grafická utilita či internetový prohlížeč. Uživatelské rozhraní předává požadavky vrstvě interpretu příkazů. Interpret příkazů pak komunikuje se serverem v příkazech definovaných normou FTP. Architektura protokolu FTP je zvláštní. Protokol FTP používá dva kanály typu klient/server: • Příkazový kanál, kterým klient zasílá na server své požadavky, např. na výpis adresáře či stažení souboru. Server vždy očekává požadavky příkazového kanálu na portu 21/tcp. • Datový kanál, kterým se přenášejí požadovaná data (výpis adresáře či obsah souboru). U datového kanálu je právě jistá zvláštnost v tom, že se může role serveru a klienta obrátit. Proto rozeznáváme dva režimy komunikace protokolu FTP: aktivní a pasivní. klient uživ rozhraní interpret příkazů přenos dat

server příkazy odpovědi přenos dat

soubory

Obr. 3.6:

3.3.1

interpret příkazů přenos dat soubory

Architektura FTP

Aktivní režim komunikace protokolu FTP

Aktivní režim komunikace protokolu FTP je standardním režimem komunikace. Na obr. 3.7 je znázorněna výměna zpráv. Klient si přeje navázat spojení se serverem infoserv.ripe.net. Klient nejprve požádá správu volných portů na svém lokálním počítači o přidělení volného portu. Je mu přidělen nějaký port větší než 1023 (klientský port). Na tomto portu naváže TCP spojení s portem 21/tcp serveru. Vytvoří se tak příkazový kanál. Uživatel např. zadal příkaz DIR pro podrobný výpis aktuálního adresáře na serveru. Pro zaslání výpisu adresáře ze serveru na klienta se zřídí datový kanál. Právě aktivní režim je charakteristický tím, že datový kanál je zřízen zvláštním způsobem: 1. Klient požádá správu volných portů svého operačního systému o přidělení volného portu. Je mu přidělen např. port 1035 desítkově. (Číslo portu je pak přenášeno ve dvou bajtech: tj. 1035 je 04 0B šestnáctkově. V protokolu FTP se však každý bajt uvádí desítkově, tj. 4 a 11.) 2. Klient odešle příkazem PORT šest desítkových čísel obsahujících svou IP adresu a port, tj. odešle 194, 149, 105, 131, 4, 11. 3. Server naváže protokolem TCP spojení s klientem o IP-adrese a portu uvedeném v příkazu PORT. Tj. server navazuje spojení s klientem! Nyní klient odešle příkaz LIST pro výpis adresáře. Všimněte si, že zatímco uživatel v uživatelském rozhraní zadal příkaz „DIR“, tento příkaz byl pro interpret příkazů konvertován do příkazu LIST protokolu FTP. Po přenesení výpisu adresáře se datový kanál uzavře.


33

V případě klienta pro příkazový řádek je možné dát příkaz debug. Uživatel pak podrobně vidí komunikaci v příkazovém kanálu. Pro relaci z obr. 3.7 dostáváme: ftp> dir -> PORT 194,149.105,131,4,11 200 PORT command successful. --> LIST 150 Opening ASCII mole data connection for /bin/ls. total 922 -r-r-r1 ftp ftp 86 Mar 24 1992 soubor1.bin -r-r-r1 ftp ftp 89 Apr 24 1996 soubor2.bin ........ 226 Transfer complete. ftp: 1356 bajtů přijato za 0,92sekundy 1,47kB/s

Obr. 3.7:

3.3.2

Aktivní režim FTP [3]

Pasivní režim komunikace protokolu FTP

Mnohdy může vadit, že se spojení pro datový kanál navazuje ze strany serveru na klienta (např. v případě použití firewallu). Tento problém odstraňuje pasivní režim komunikace, kdy klient navazuje spojení jak pro příkazový kanál, tak i pro datový kanál, obr. 3.8. Do pasivního režimu se přechází příkazem pasv. Server sdělí klientovi, na jakém portu očekává spojení. Připomeňme si, že spojení TCP je plně duplexní. Ačkoli kanál otevřel klient, tak zápis a uzavření provede server.


34

Obr. 3.8: 3.3.3

Pasivní režim FTP [3]

Příkazy FTP

Příkazy protokolu FTP jsou přenášeny textově (v ASCII). Příkaz je vždy tvořen klíčovým slovem (např. USER). Klíčově slovo mohou následovat parametry oddělené mezerou. Příkaz je ukončen znaky CR LF. Příkaz FTP (přenášený sítí) USER jméno PASS heslo CWD QUIT PASV TYPE kód RETR cesta STOR cesta DELE cesta MKD cesta RMD cesta LIST [cesta]

Obvyklý příkaz příkazového řádku user cd quit pasv ascii, binary get put delete mkdir rmdir ls

Význam Jméno uživatele Heslo (přenáší se otevřeně) Nastavení aktuálního adresáře na serveru Ukončení spojení Přechod do pasivního režimu Specifikace typu přenášeného souboru Stažení souboru ze serveru Přenesení souboru na server Zrušení souboru Vytvoření adresáře Zrušení adresáře Výpis obsahu adresáře

Je třeba však rozlišovat mezi příkazy zadávanými uživatelem a příkazy protokolu FTP. Např. pro výpis adresáře uživatel programu ftp zadá příkaz DIR, avšak ten je konvertován na příkaz LIST protokolu FTP. Na jednotlivé klientem zadávané příkazy server odpovídá hlášením s trojciferným návratovým kódem následovaným volitelným textovým objasněním návratového kódu. Trojciferný návratový kód má tvar: xyz


35

x - může nabývat hodnot: 1 Pozitivní odpověď při zahájení nějaké akce. 2 Pozitivní odpověď na provedení příkazu. Klient může zadat další příkaz. 3 Pozitivní odpověď, na kterou musí klient udělat konkrétní akci. Např. po zadání jména uživatele je vyžadováno heslo. 4 Negativní odpověď při chybě. Po odstranění chyby je možné příkaz zadat znovu. 5 Permanentní negativní odpověď. Např. o nepodporovaném příkazu. y - může nabývat hodnot: 0 Syntaktická chyba. 1 Informativní hláška. 2 Chyba spojení. 3 Chyba autentizace. 4 Nespecifikovaná chyba. 5 Chyba signalizována souborovým systémem. z - blíže určuje chybu. Příklady: 125 Data connection already open; transfer starting. 230 User logged in, proceed. 331 User name okay, need password. 452 Insufficient storage spase in system. 502 Command not implemented.

3.4 Elektronická pošta 3.4.1

Architektura

Základní představa architektury elektronické pošty (obr. 3.9) na Internetu pochází z poloviny 70. let. Tehdy uživatelé seděli u terminálů, ze kterých spouštěli poštovní klienty. Poštovní klient nemá nic společného se síťovou komunikací. Poštovní klient je v podstatě pouze specializovaný textový editor. Tento textový editor umí uživateli zobrazit obsah zprávy z poštovní schránky, umí manipulovat se zprávami v poštovní schránce. Poštovním klientem je dále možné zprávu pořídit a odeslat. Odesláním se opět nerozumí nějaká síťová komunikace, ale uložení zprávy do fronty zpráv. Fronta zpráv je pak pravidelně procházena SMTP klientem, který navazuje spojení se vzdálenými SMTP servery, jimž zprávu předá. SMTP server přijme zprávu a zjišťuje, je-li určena pro jeho lokální uživatele. V případě, že nikoliv, pak zprávu opět uloží do poštovní fronty. Tu obsluhuje jeho poštovní klient, jenž se pokouší zprávu doručit směrem k adresátovi. V případě, že adresát je lokálním uživatelem systému, pak SMTP server uloží přijatou zprávu do poštovní schránky adresáta.


36

Obr. 3.9:

Architektura SMTP [3]

Internetová pošta má díky ukládání odchozí pošty do fronty a ukládání příchozí pošty do poštovní schránky jednu zásadní vlastnost. Není nutné okamžitě navazovat spojení na příjemcův systém v době odeslání pošty. Příjemcův systém může být i vypnut v době, kdy odesilatel zprávu odesílá. Nepodaří-li se klientovi SMTP poštu odeslat, ponechá ji ve frontě. Obvykle maximálně 2-7 dní. Poté se pošta vrací odesilateli jako nedoručená.

Obr. 3.10: Protokoly POP3 a IMAP4 [3]


37

S příchodem osobních počítačů přišel zvrat i v používání elektronické pošty. Ve svém jádru elektronická pošta zůstala zachována, avšak uživatel již nemusí pracovat s terminálem poštovního serveru (přes Telnet na svém PC). Zatímco při odesílání pošty z PC lze použít protokol SMTP, pro příjem pošty z poštovního serveru na PC není protokol SMTP vhodný. Zvolila se proto jiná strategie, znázorněná na obr. 3.10. Uživatel má svou příchozí poštovní schránku (INBOX) na poštovním serveru. Tj. z hlediska protokolu SMTP je poštovní server cílovou stanicí. Pro práci s poštovní schránkou uživatele na poštovním serveru jsou k dispozici dva protokoly: • Protokol POP3. Jedná se o velice jednoduchý protokol, pomocí kterého pracuje uživatel Offline. Tj. z poštovního serveru si uživatel stáhne příchozí poštu na své PC a ukončí TCP spojení se serverem. Teprve po stažení pošty uživatel pracuje s jednotlivými poštovními zprávami. V případě, že chce uživatel poštu odeslat, použije protokol SMTP. • Protokol IMAP4. Jedná se o komplikovaný protokol, který umožňuje pracovat nejen Offline, ale i Online. Uživatel může mít navázáno spojení s poštovním serverem delší dobu a být serverem průběžně informován o změnách ve své poštovní schránce. Protokolem IMAP4 je možno také synchronizovat poštovní schránky na PC a na serveru. V případě, že chce uživatel poštu odeslat, použije také protokol SMTP. Poslední možností je, když poštovní klient běží na vzdáleném počítači a uživatel je ovládá přes html rozhraní. V adrese [email protected] značí „firma.cz“ doménu. Nejedná se o konkrétní počítač – poštovní server. Informace o tom, který server obsluhuje doménu je uložena v databázi DNS v tzv. MX záznamu (MX = Mail Exchanger“). firma.cz.

IN MX 10 mh.firma.cz.

*.firma.cz. IN MX 10 mh.firma.cz. MX záznamy slouží k přesměrování pošty na konkrétní poštovní server - v našem případě centrální poštovní server mh.firma.cz. Druhý řádek říká, že veškerá pošta končící řetězcem ,,.firma.cz“ se má směrovat také na server mh.firma.cz. Jinou eventualitou je, že nepoužijeme hvězdičku, ale v DNS vyjmenujeme subdomény druhé úrovně. 3.4.2

Formát poštovní zprávy

Formát poštovní zprávy je specifikován normou RFC-822. Zpráva se skládá ze záhlaví a těla zprávy. Záhlaví je od těla zprávy odděleno jedním prázdným řádkem (CRLF). Záhlaví i tělo zprávy jsou tvořeny pouze ASCII znaky! Záhlaví se skládá z jednotlivých hlaviček. Hlavička začíná klíčovým slovem ukončeným dvojtečkou. Za klíčovým slovem mohou následovat parametry. Hlavička se ukončuje koncem řádku, tj. CRLF. Přehled některých hlaviček z RFC-822 Hlavička Význam Received: Tuto hlavičku připisuje na počátek e-mailu každý e-mailový server, kterým zpráva prochází. Čteme-li hlavičky Received: odspodu nahoru,


38

From Reply-To: To: X-

zjistíme celou trasu, přes kterou zpráva šla. V této hlavičce se mohou vyskytovat slova: • from - počítač, ze kterého byla zpráva přijata, • by - počítač, kterým byla zpráva přijata, • via - fyzická cesta, • with - sífový nebo poštovní protokol, • id - příjemcova identifikace zprávy, • for - pro koho je zpráva určena (naříklad je-li adresátem distribuční list, pak se zde zachová původní adresát - tj. distribuční list). Od Odpověď zasílejte na Adresát Uživatelsky definovaná hlavička (uživatelem se rozumí autor software). Např. X-Mailer se často používá pro specifikaci programu, kterým odesilatel odesílá zprávu.

Příklad: Received: from palcat.feec.vutbr.cz (palcat.feec.vutbr.cz) by ant.feec.vutbr.cz (envelope-from [email protected]) (8.13.8/8.13.7) with ESMTP id l44Bae3D008479 for ; Fri, 4 May 2007 13:36:40 +0200 Received: from smtp.lam.cz (smtp.lam.cz [213.194.207.201]) by palcat.feec.vutbr.cz(envelope-from [email protected]) (8.13.8/8.13.7) with ESMTP id l44BaT4l033241 for ; Fri, 4 May 2007 13:36:30 +0200 Received: from OFFICENO (schoralekm.lam.cz [212.71.169.227]) by smtp.lam.cz (Postfix) with ESMTP for ; Fri, 4 May 2007 13:44:14 +0200 Reply-To: From: "Roman Lustig (icomputing.cz)" To: Subject: Mathcad nabidka spoluprace Date: Fri, 4 May 2007 13:36:33 +0200 Text mailu

Hlavička Received, kterou přidal první server, je poslední. Hlavička Received před ní je hlavičkou, kterou přidal další server atd.

3.4.3

Protokol SMTP

Vlastní protokol SMTP (Simple Mail Transfer Protocol) je poměrně jednoduchý protokol. Jednotlivé příkazy jsou textové v kódu ASCII. Klient navazuje spojení protokolem TCP se serverem na portu 25. Klient vkládá do takto vytvořeného kanálu příkazy a server odpovídá odpovědí obsahující trojciferný stavový kód, následovaný textovým popisem chyby. Příkazy klienta jsou čtyřznaková slova. Nezávisí na tom, zda se použijí velká či malá písmena (či jejich kombinace). Příkaz může být následován parametrem, který je oddělen mezerou. Příkaz je zakončen koncem řádku CRLF.


S: C: S: S: S: C: S: C: S: C: S: C: C: C: S: C: S:

39

220 foo.com Simple Mail Transfer Service Ready EHLO bar.com 250-foo.com greets bar.com 250-8BITMIME 250 HELP MAIL FROM:<[email protected]> 250 OK RCPT TO:<[email protected]> 250 OK DATA 354 Start mail input; end with . Blah blah blah... ...etc. etc. etc. . 250 OK QUIT 221 foo.com Service closing transmission channel

Obr. 3.11: Konverzace protokolem SMTP

Příkaz HELO klient MAIL FROM: odesilatel RCPT TO: příjemce DATA RSET VRFY adresa EXPN adresa HELP [příkaz] QUIT TURN

Popis Klient se představuje serveru jménem počítače. Příkaz by se měl používat na počátku dialogu klienta se serverem. Odesílatel Příjemce (tento příkaz se opakuje pro každého příjemce). Začátek vlastní zprávy. Zpráva končí řádkem, který obsahuje jen znak „tečka“. Aktuální translace bude abnormálně ukončena (veškeré přenesené informace ve FROM a TO budou zahozeny). Dotaz, zda příjemce zná uvedenou adresu. Server vrací plné jméno uživatele a jeho přesnou poštovní identifikaci. Obdoba VRFY, ale umí pracovat nejen s jednotlivými uživateli, ale i s celý¬mi seznamy uživatelů. Ukončení spojení Přepnutí role serveru a klienta. Jelikož se tento příkaz nepovažuje za bezpečný, nepoužívá se.

Některé údaje, jako je odesilatel a příjemce, se zadávají dvakrát. Jednou jsou zadány v záhlaví zprávy (v hlavičkách), podruhé v příkazech protokolu SMTP (např. v příkazech MAIL a RCPT). Údaje ze záhlaví zprávy jsou z hlediska transportu zprávy Internetem druhořadé. Protokol SMTP totiž nepřepravuje pouze záhlaví zprávy, prázdný řádek a text zprávy. Přepravuje ještě tzv. SMTP obálku zprávy. Obálka zprávy právě obsahuje údaje např. z příkazů MAIL a RCPT. Pro přepravu zprávy mezi SMTP servery je tak důležitá SMTP obálka. Rozšířením protokolu SMTP vznikl protokol ESMTP (Extensions SMTP). Princip rozšíření specifikuje RFC-1869. Základním problémem jakéhokoliv rozšíření je jeho zpětná komptabilita. Zatímco protokol SMTP zpravidla začíná svůj dialog příkazem HELO, tak ESMTP použije příkaz EHLO. Server buď odpoví:


40 • •

že se klient musel splést ve jméně příkazu. Odesilatel si okamžitě uvědomí, že server je „pouze“ SMTP, a pokračuje příkazem HELO; stavovým kódem 250 („že je vše v pořádku“). Klient okamžitě pozná, že server je ESMTP. Navíc server ve své odpovědi uvede, které rozšiřující příkazy podporuje: C: S: S: S: S: S: S: S: S: S:

ehlo pc.firma.cz 250-dns.terminal.cz Hello pc.firma.cz, .... 250-EXPN 250-VERB 250-BBITMIME 250-SIZE 8388608 250-DSN 250-ONEX 250-ETRN 250 HELP

8BITMIME Toto rozšíření je určeno pro přenos zpráv MIME obsahující osmibitová data. Pokud server nepotvrdí, že podporuje tento osmibitový přenos, SMTP klient nesmí odeslat na server zprávu, jejíž tělo obsahuje jiné znaky než ASCII. Může však před odesláním zprávu kódovat např. Base64, čímž ji převede do sedmibitového tvaru. SIZE Toto rozšíření je určeno pro specifikaci délky zprávy. Server ve své odpovědi na příkaz EHLO, zpravidla vrací toto rozšíření s číselným parametrem, který desítkově specifikuje, jakou maximálně dlouhou zprávu je ochoten akceptovat (do délky zprávy se započítávají konce řádků, ale nikoliv samotný příkaz DATA). ETRN Toto rozšíření se používá např. pro firemní servery připojené komutovanou linkou. V případě, že se firma připojí komutovanou linkou, může dát poštovnímu serveru poskytovatele příkaz ETRN, aby prohledal frontu a ihned odeslal čekající zprávy do firemního serveru. DSN Elektronická pošta v Internetu negarantuje doručení zprávy. Z nejrůznějších příčin může být zpráva na své pouti Internetem ztracena. Je možné si nechat doručení zprávy automatizovaně potvrdit: • Rozšířením DSN (Delivery Status Notifications), které notifikuje doručení poštovní zprávy do schránky uživatele na serveru. • MIME rozšířením realizovaným hlavičkou Disposition-Notification-To. Toto rozšíření notifikuje zobrazení zprávy příjemcem. Prakticky je rozdíl v obou mechanismech v tom, že rozšíření DSN interpretuje ESMTP server, tj. ESMTP server generuje notifikační zprávu. Kdežto MIME je interpretováno až poštovním klientem. Tj. notifikační zprávu generuje poštovní klient. Skutečnost, zda poštovní klient podporuje jedno z těchto rozšíření, či dokonce obě, závisí na tvůrci tohoto softwaru.

Počítačové a komunikační sítě 3.4.4

41

POP3

Post Office Protocol verze 3 (RFC-1939) je jednoduchý protokol, kterým si uživatel může ze své poštovní schránky na poštovním serveru stáhnout zprávy do lokálních poštovních schránek na svém PC. Je určen pro práci offline s poštovním serverem. Klient navazuje spojení na TCP port 110 serveru. Po navázání spojení se server představí a čeká na autentizace uživatele. Základní autentizace je jménem a heslem uživatele. V případě, že autentizace proběhne s kladným výsledkem, komunikace přechází do transakčního stavu, kdy klient může pracovat se zprávami ve své poštovní schránce na serveru. I když klient např. zruší některé zprávy ve své poštovní schránce na serveru, během transakčního stavu je takové zrušení ještě odvolatelné. Na závěr relace přejde klient do stavu UPDATE, kdy se provedou veškeré změny v jeho poštovní schránce na serveru trvale. Server na zadávané příkazy vrací odpověď začínající bud znakem + v případě, že je kladná, nebo znakem - v případě signalizace chyby. Na obr. 3.12 je ukázka konverzace protokolem POP3. První část je tzv. autentizační stav. Příkazem USER a PASS zadává uživatel své jméno a heslo. V transakčním stavu příkaz LIST vrací seznam jednotlivých zpráv v poštovní schránce (co zpráva, to jeden řádek). U každé zprávy je uvedeno její pořadové číslo a její velikost. Příkazem RETR stahujeme zprávu ze serveru na PC; jako parametr se použije číslo zprávy, která se má stahovat. Příkazem DELE se ruší zpráva v poštovní schránce na serveru. Jako parametr se zadává číslo rušené zprávy. Ukončení relace se provede opět příkazem QUIT. V tomto okamžiku se provede fyzické zrušení všech zpráv označených jako zrušené. Problémem původní verze POP3 je přenos hesla v otevřeném tvaru. Existuje však možnost využít POP3 ve spojení s SSL. S: C: S: C: S:

+OK POP3 server ready user bob +OK pass hungry +OK user successfully logged

C: S: S: S: C: S: S: C: C: S: S: C: C: S:

list 1 498 2 912 . retr 1 <message 1 contents> . dele 1 retr 2 <message 1 contents> . dele 2 quit +OK POP3 server signing off

on

Obr. 3.12: Konverzace protokolem POP3 3.4.5

IMAP4

Protokol IMAP (Internet Message Access Protocol) verze 4 je specifikován RFC-2060. IMAP4 je sofistikovaný protokol určený pro práci s poštovními schránkami na serveru z PC v

42


režimu online. V jednom okamžiku můžeme pracovat se svými poštovními schránkami z více aplikací. Server protokolu IMAP používá port 143/tcp. Během práce s poštovní schránkou (během navázaného TCP spojení) může jiná aplikace změnit obsah poštovní schránky (např. SMTP server zapíše do schránky nově příchozí poštu). Tyto události (jako připsání nových zpráv na konec poštovní schránky) jsou do navázaného spojení serverem signalizovány. Prakticky může klient zjišťovat příchod nové zprávy tak, že na server odešle prázdný příkaz NOOP. To server vybudí k akci podívat se, zda nedošlo ke změnám v poštovní schránce. Příkazy IMAP4 se zadávají v ASCII (obdobně jako v případě protokolů SMTP, POP3 apod.). V protokolu IMAP4 může být zadávána řada příkazů a odpovědi na jednotlivé příkazy mohou přicházet ze serveru v libovolném pořadí. Proto klient příkazy čísluje a server do své odpovědi zopakuje číslo příkazu, na který odpovídá. Je věcí klienta, jak příkazy identifikuje (čísluje). Identifikace příkazu je obecně řetězec (nemusí to být ani číslo). Jednoznačnost identifikace je rovněž věcí klienta. C: 0000 CAPABILITY S: * CAPABILITY IMAP4 IMAP4REV1 SCAN SORT AUTH=LOGIN S: 0000 OK CAPABILITY completed Klient očísloval svůj dotaz řetězcem 0000, za kterým následuje vlastní příkaz (v našem případě příkaz CAPABILITY). Za příkazem mohou následovat jeho parametry. Server odpovídá dvěma druhy odpovědí: 1. Nečíslovanými odpověďmi, které mají na místě čísla příkazu/odpovědi hvězdičku. Tyto nečíslované řádky v podstatě nesou informaci, kterou klient požadoval. 2. Číslovanými odpověďmi, které začínají číslem příkazu a sdělují, jak příkaz dopadl (OK, NO-neúspěšně, BAD-chybný příkaz)

Obr. 3.13: Stavy protokolu IMAP4 [3]


43

Na obr. 3.13 jsou popsány jednotlivé stavy v protokolu IMAP4. Po navázání spojení zpravidla nastane „neautentizovaný stav“, kdy je nutná autentizace klienta (nebo ukončení příkazem LOGOUT). Výjimkou je situace, kdy server okamžitě po navázání klientovi sdělí, že je již předem s přihlášením automaticky autentizován (PREAUTH). V autentizovaném stavu může klient pracovat s poštovními schránkami na serveru jako se soubory, tj. může poštovní schránku vytvořit, zrušit, přejmenovat apod. Příkazem SELECT (nebo EXAMINE) klient otevře konkrétní poštovní schránku a přejde do režimu „Otevřená schránka“, ve kterém může pracovat s jednotlivými položkami otevřené poštovní schránky (např. položky přenést ze serveru na klienta apod.). Příkazy CAPABILITY, NOOP a LOGOUT jsou na stavu nezávislé, proto je možné je zadávat kdykoliv. Příkazem LOGIN se uživatel přihlašuje pomocí jména a hesla. Po úspěšném provedení příkazu LOGIN se přejde do autentizovaného stavu.

3.4.6 MIME Formát zpráv protokolu SMTP definovaný normou RFC-822 umožňoval přenášet data pouze formátu US-ASCII. Standard MIME (Multipurpose Internet Mail Extension, RFC-2045 až 2049) je možné využít pro posílání textu jiných znakových sad, formátovaného textu, obrázků, zvuků, obecně binárních souborů včetně možnosti šifrování a elektronického podpisu. • • • • • • •

MIME zavádí hlavičky: MIME-Version - přítomnost této hlavičky elektronické pošty indikuje, že je zpráva sestavena podle MIME, tj. dle RFC2045 až RFC2049. Dnes se užívá verze 1.0. Content-Type - specifikuje typ a podtyp dat posílaných v těle zprávy (text, audio, video, virtuální realita). Content-Transfer-Encoding - specifikuje použité kódování, pomocí kterého je zpráva převedena do formátu vyhovujícího přenosovému mechanismu (do ASCII). Content-ID - identifikace zprávy použitelná v možném odkazu. Content-Description - textový popis obsahu. Content - řetězec - je rezervováno pro budoucí použití v MIME. Content-Disposition – je hlavička specifikovaná normou RFC-2183. Hlavička Content-Type

Hlavička popisuje typ dat obsažených v těle zprávy tak, aby klient, který tuto zprávu obdrží, mohl zvolit vhodný způsob prezentace obsahu zprávy. Hlavička má tvar: Content-Type: typ/podtyp; parametry Content-Type: image/jpeg Jména typů, podtypů a parametry jsou nezávislé na tom, zda je píšeme velkými nebo malými písmeny.


44

Obr. 3.14: Možné typy dat v MIME Hlavička Content-Transfer-Encoding Binární data není možné zpravidla poslat přímo. Proto je potřeba definovat mechanismus převodu – kódování, jakým se data převedou do kódu US-ASCII, tj. do 7bitového tvaru. Použitý typ kódování je uveden právě v hlavičce Content-TransferEncoding: • quoted-printable • base64 • 7bit – data nejsou kódována, jsou v krátkých řádcích, obsahují pouze znaky USASCII. • 8bit – data nejsou kódována, řádky jsou krátké, ale mohou se vyskytnout i znaky, které nejsou US-ASCII. • binary – data nejsou kódována, tok bitů není dělený na řádky. Celkový počet přenášených bitů musí být dělitelný osmi. Prakticky nelze použít pro SMTP. • x-rozšíření - experimentální kódování (určeno pro vývojáře). Hodnoty 8bit, 7bit a binary nepředstavují žádné kódování. Tyto hodnoty jsou užitečné jako indikace typu dat. MIME definuje dva kódovací mechanismy: Quoted-printable a Base64. Quoted-printable Toto kódování je určeno pro data, která z větší části obsahují znaky US-ASCII. Výsledkem kódování je text, který je i bez dekódování z velké části pro člověka čitelný. • Bajty s desítkovou hodnotou od 33 do 60 a od 62 do 126 včetně jsou nahrazeny znaky US-ASCII (od ! do < a od > do ~). Jinými slovy: znaky, které jsou US-ASCII, se nekódují, tj. ponechávají se beze změny. Rovněž konce řádků se ponechávají. • Ostatní bajty se nahrazují znakem "=" následovaným šestnáctkovou hodnotou bajtu. Např. znak „á“ se nahradí „=E1“. • Bajty s hodnotou 9 a 32 jsou nahrazeny znaky tabulátor a mezera. Nesmí být na konci řádku.

Počítačové a komunikační sítě • •

45

Konec řádky je vyjádřen CRLF. Zakódovaná řádka musí mít maximálně 76 znaků. Pokud je řádka delší použije se měkký konec řádky, tj. vloží se znak „=“ a konec řádky.

Tento způsob kódování není příliš úsporný. V případě, že všechny přenášené znaky jsou ne US-ASCII, pak se přenášená data zvětší na trojnásobek. Base64 Kódování Base64 je určeno pro kódování obecných binárních data, která nemusí být čitelná pro člověka. Kódovaná data jsou pouze o třetinu delší než data původní. Kódovací algoritmus je jednoduchý. Používá tabulku base64 o 64 znacích (a znak "="). Pro kódování 64 znaků je třeba 6 bitů (26=64). Znak "=" (6510) se používá ke speciálnímu účelu pro označení výplně na konci textu. Z hlediska kódování se na zprávu nehledí jako na proud osmic bitů (bajtů), ale jako na proud šestic bitů. Každá šestice se pak kóduje podle tabulky base64, obr. 3.15.

Obr. 3.15: Kódování base64 [9] Na začátku kódování se kódovaný text rozdělí na sekvence 24 bitů (trojice bajtů). Každá trojice bajtů se rozdělí na 4 šestice bitů. Každá šestice reprezentuje jeden znak v abecedě base64. Kóduje se zleva doprava. Každých 6 bitů je nahrazeno odpovídajícím znakem z tabulky znaků abecedy base64. Všechny znaky pro konec řádky a jiné znaky, které nejsou obsaženy v tabulce base64, musí být dekódovacím programem ignorovány, mohou indikovat chybu přenosu. Zbude-li na konci textu po rozdělení méně než 24 bitů, doplní se nulové bity zprava. Přidání na konec je indikováno znakem "=". Např. poslední blok má dva bajty (16 bitů), pak se prvních dvanáct bitů kóduje normálně dle tabulky Base64. Zbylé 4 bity se doplní dvěma binárními nulami na 6 bitů a výsledek se rovněž kóduje Base64. Avšak na konec se přidá jeden znak „=“ signalizující doplnění výplní dlouhou dva bity.


46 Znaky v hlavičce, které nejsou ASCII

Znaky, které nejsou ASCII, by se v žádném případě neměly vyskytnout v záhlaví zprávy. RFC-2047 řeší otázku, jak do parametrů hlaviček dodat znaky, které nejsou ASCII. Syntaxe parametru hlavičky obsahujícího znaky, které nejsou ASCII, je: =?charset?kódování?řetězec?= kódování je buď b pro base64 nebo q pro quoted printable. From: =?iso8859-2?q?V=E1clav Vopi=E8ka?=

Kompozitní typy v Content-Type Zpráva může ve svém těle nést: • několik dílčích zpráv, pak je použito hlavičky (Content-Type: multipart). • Dlouhá zpráva může být transportována jako několik kratších (Content-Type: message). • Jiným případem je situace, že poštovní server z nějaké příčiny nemůže poštovní zprávu předat dále směrem k adresátovi pro chybu v doručování zprávy. V takovém případě poštovní servery často tuto skutečnost signalizují adresátovi poštovní zprávou, která se skládá ze dvou částí: z části specifikující chybu a části obsahující původní zprávu (nebo alespoň počátek původní zprávy). Tělo zprávy multipart obsahuje několik různých částí - několik dílčích zpráv. Každá část těla celkové zprávy začíná úvodním oddělovačem, pak následují hlavičky této části, prázdný řádek a vlastní tělo dílčí zprávy. Poslední část je ukončena koncovým oddělovačem. Oddělovač je speciální sekvence znaků, která se nesmí vyskytnout nikde uvnitř částí. Oddělovač se definuje v záhlaví celé zprávy v hlavičce Content-Type parametrem boundary. Jednotlivé dílčí zprávy nejsou interpretovány podle RFC-822. Mohou, ale také nemusí obsahovat hlavičky (prázdný řádek za záhlavím však musí být vždy uveden). Pokud nejsou hlavičky u části uvedeny, uplatní se implicitní hlavičky ze záhlaví celé zprávy. • •

• •

Existuje několik podtypů: Multipart/Mixed - je určen pro zprávy, které obsahují nezávislé části, které je potřeba svázat v daném konkrétním pořadí (např. přílohy emailu). Multipart/Alternative - Zpráva tohoto typu obsahuje několik částí, přitom všechny části obsahují shodné informace, pouze tvar je odlišný. Např. táž zpráva jednou napsaná v US-ASCII, potom v ISO-8859-2 a nakonec třeba v html. Příjemcův software musí rozpoznat, které formy je schopen zobrazit, a vybrat z nich tu nejlepší. Multipart/Parallel - Klientem mají být všechny části prezentovány uživateli současně. Např. zvuk na pozadí obrázku. Multipart/Signed a Multipart/Encrypted - Multipart/Signed je určen pro elektronicky podepsanou zprávu; specifikuje zprávu skládající se ze dvou částí: zprávy a elektronického podpisu této zprávy. Subtyp Multipart/Encrypted specifikuje zprávu v elektronické obálce (šifrovanou zprávu). Skládá se opět ze dvou částí: z informací o použitém způsobu šifrování (např. verzi šifrovacího software) a z šifrované zprávy.


47

Obr. 3.16: Struktura standardní zprávy a zprávy typu multipart/mixed [3]

3.5 DNS 3.5.1

Architektura

Všechny aplikace, které zajišťují komunikaci mezi počítači, používají k identifikaci komunikujících uzlů IP-adresu. IP adresy se obtížně pamatují, navíc se pro stejné rozhraní mohou v čase měnit. Proto se pro označení používají symbolická, tzv. doménová jména (domain names). Jedna IP-adresa může mít přiřazeno i několik doménových jmen. Vazba mezi jménem počítače a IP adresou je definována v DNS databázi. DNS (Domain Name System) je celosvětově distribuovaná databáze. Jednotlivé části této databáze jsou umístěny na tzv. name serverech. Zahájení komunikaci proto vždy předchází překlad doménového jména na IP adresu. Jedině IP adresu name serveru takto nejde získat. Musí být nastavena přímo číselně nebo ji počítač získá protokolem DHCP. Celý Internet je rozdělen do tzv. domén, tj. skupin jmen, která k sobě logicky patří. Domény specifikují, patří-li jména jedné firmě, jedné zemi apod. V rámci domény je možné vytvářet podskupiny, tzv. subdomény. Z jednotlivých jmen domén a subdomén je pak složeno doménové jméno uzlu. Např. uzel se jménem pc120.firma.cz je uzel se jménem pc120 v subdoméně firma domény cz.


48

Obr. 3.17: Překlad doménového jména [3] Doménové jméno se zkoumá zprava doleva. Nejvyšší instancí je tzv. root doména, která se vyjadřuje tečkou zcela vpravo (tato tečka bývá vypouštěna). V root doméně jsou definované generické domény (Top Level Domains – TLD): edu, com, net, org, mil, int a arpa, které se používají převážně v USA, a dále podle normy ISO-3166 dvojznakové domény jednotlivých států. Pro Českou republiku je vyhrazena doména cz. Doména cz se dělí na subdomény pro jednotlivé organizace: vutbr.cz, muni.cz atd. Subdomény se mohou dělit na subdomény nižší úrovně. Např. feec.vutbr.cz pro FEKT atd. Subdomény obsluhují jako prvky počítače. Jména tvoří stromovou strukturu. Jméno je uváděno v tečkové notaci: řetězec.řetězěc.řetězec....řetězec kde první řetězec je jméno počítače, další jméno nejnižší vnořené domény, další vyšší domény atd. Pravidla pro doménová jména: • Celé jméno maximálně 255 znaků, řetězec pak maximálně 63 znaků. • Řetězec se může skládat z písmen, číslic a pomlčky. Pomlčka nesmí být na začátku ani na konci řetězce. • Z hlediska uložení a zpracování v databázi jmen (databázi DNS) se velká a malá písmena nerozlišují.

Obr. 3.18: Stromová struktura DNS [3] Zóna Doména je skupina počítačů, které mají společnou pravou část svého doménového jména. Doména je např. skupina počítačů, jejichž jméno končí cz. Doména cz je však velká. Dělí se dále na subdomény např. vutbr.cz, eunet.cz a tisíce dalších. Každou z domén druhé


49

úrovně si většinou spravuje na svých name serverech majitel domény nebo jeho poskytovatel Internetu. Data pro doménu druhé úrovně např. vutbr.cz nejsou na stejném name serveru jako doména cz. Část domény, jejíž data jsou uložena na jednom serveru (a spravována jednou autoritou), se nazývá zóna. Na obr. 3.19 zóna ISP1 odpovídá doméně ISP1. U ISP2 byla správa subdomény X2 svěřena jinému subjektu. Zóna ISP2 je tedy tvořena doménou ISP2 se všemi subdoménami s výjimkou těch, jejich správa byla delegovaná jinam (X2).

Obr. 3.19: Zóny [9] Každé zóně tedy přísluší nejméně jeden DNS server. Informace o kořenové doméně (nad TLD) je uložena celkem v 13 tzv. root name serverech označených písmeny a až m. Počet 13 je počet logických serverů (IP adres). Za mnoha z nich se skrývají až desítky fyzických počítačů. Kořenové servery jsou rozmístěny po světě (viz http://www.rootservers.org). V kořenových serverech je jen informace o tom, které servery jsou autoritativní k dané top-level doméně. Na jejich spolehlivém provozu je závislý chod celého Internetu. a Verisign, Dulles, VA c Cogent, Herndon, VA (also Los Angeles) d U Maryland College Park, MD k RIPE London (also Amsterdam, g US DoD Vienna, VA Frankfurt) Stockholm (plus 3 i Autonomica, h ARL Aberdeen, MD other locations) j Verisign, ( 11 locations) m WIDE Tokyo e NASA Mt View, CA f Internet Software C. Palo Alto, CA (and 17 other locations)

b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA

Obr. 3.20: Umístění kořenových serverů 3.5.2

Dotazy

Přeložení jména na IP-adresu zprostředkovává tzv. resolver. Resolver je klient, který se dotazuje name serveru. Jelikož je databáze celosvětově distribuována, nemusí nejbližší name server znát odpověď, proto může tento name server požádat o pomoc další name servery.


50

Získaný překlad pak name server vrátí jako odpověď resolveru. Veškerá komunikace se skládá z dotazů a odpovědí. Name server po svém startu načte do paměti data pro zónu, kterou spravuje. Primární name server načte data z lokálního disku, sekundární name server dotazem typu zone transfer získá pro spravované zóny data z primárního name serveru a rovněž je uloží do paměti. Tato data primárního a sekundárního name serveru se označují jako autoritativní (nezvratná). Dále name server načte z lokálního disku do paměti data, která nejsou součástí dat jeho spravované zóny, ale umožní mu spojení s root name servery a případně s name servery, kterým delegoval pravomoc pro spravování subdomén. Tato data se označují jako neautoritativní.

Obr. 3.21: Jmenný server a resolver [2] Jak name server, tak i resolver používají paměť cache. Během práce do ní ukládají kladné odpovědi na dotazy. Tato data jsou neautoritativní – pouze šetří čas při opětovných dotazech. Každý záznam v databázi DNS má definovánu dobu, po kterou může být uložen ve vyrovnávací paměti (tzv. dobu života). Potom musí být záznam v cache smazán a znovu získán z autoritativního zdroje. root DNS server

root DNS server

2

2 3

TLD DNS server

3 7

4

6 TLD DNS server

5 local DNS server

local DNS server

dns.cvut.cz

dns.cvut.cz

1

8

requesting host

7

6

1

authoritative DNS server gate.feec.vutbr.cz

4

8

requesting host

authoritative DNS server gate.feec.vutbr.cz

pc120.cvut.cz

pc120.cvut.cz

a)

5

krel.feec.vutbr.cz b) Obr. 3.22: Iterační a) a rekurzivní dotaz b)

krel.feec.vutbr.cz


51

Existují dva typy dotazů: rekurzivní a iterační, obr. 3.22. Není-li požadovaná informace ve vyrovnávací paměti (cache), tak se tazatel obrátí na jeden z kořenových serverů se žádostí o informaci o name serveru pro top-level doménu, např. cz (v root serverech samozřejmě nejsou informace o všech počítačích v Internetu). V případě iteračního dotazu poté tazatel kontaktuje name server pro cz s žádostí o informaci o name serveru pro vutbr.cz, atd. Nakonec dojde k autorizovanému serveru pro cílovou doménu a od něj získá požadovanou IP adresu (nebo jiné informace). V případě rekurzivního dotazu je kompletní překlad ponechán na dotazovaném serveru. Rekurzivní metoda je typická při komunikaci resolver – lokální DNS server. 3.5.3

Záznamy v DNS databázi

Informace o doménových jménech a jim příslušejících IP adresách, stejně tak jako všechny ostatní informace distribuované pomocí DNS, jsou uloženy v paměti DNS serverů ve tvaru zdrojových vět (Resource Records – RR). Name server naplňuje svou paměť několika způsoby. Autoritativní data načte ze souborů na disku, nebo je získá pomocí dotazu zone transfer z paměti jiného serveru. Neautoritativní data získává postupně z paměti jiných serverů, tak jak vyřizuje jednotlivé DNS dotazy. V případě, že DNS klient (resolver) potřebuje získat informace z DNS, pak požaduje po name serveru věty RR podle zadaných požadavků. • • • •

• •

Všechny věty RR mají stejnou strukturu: NAME – Doménové jméno. TYPE – Typ věty. CLASS – Třída věty. TTL – Time to live. 32bitové číslo udávající dobu, po kterou může být tento RR udržován v cache serveru jako platný. Po vypršení této doby musí být věta považována za neplatnou. Hodnota 0 zabraňuje neautoritativním serverům uložit RR větu do cache. RDLENGTH – 16bitové číslo specifikující délku pole RDATA. RDATA – Vlastní data ve tvaru řetězce proměnné délky. Formát tohoto pole závisí na typu a třídě RR.

Obr. 3.23: Struktura věty RR [3] Doménová služba je realizována jednoduchým protokolem typu dotaz – odpověď. Klient pošle dotaz serveru a server na dotaz odpoví. Jistou komplikací je komprese jmen,


52

která se provádí proto, aby byly DNS pakety co nejúspornější. Name server standardně očekává dotazy jak na portu 53/udp, tak na portu 53/tcp. Na rozdíl od drtivé většiny ostatních aplikačních protokolů využívá DNS jako transportní protokoly UDP i TCP. Dotaz i odpověď jsou přenášeny vždy stejným transportním protokolem. U dotazů na překlad (tj. žádosti o RR record) je dávána přednost protokolu UDP. V případě, že je DNS odpověď delší než 512 B, vloží se do odpovědi pouze část informací nepřesahující 512 B a v záhlaví se nastaví bit TC, specifikující, že se jedná o neúplnou odpověď. Klient si může kompletní odpověď vyžádat protokolem TCP. Některé typy vět: Typ Anglický název A A host address Authoritative name NS server Canonical name for CNAME an alias HINFO

Host information

MX

Mail exchange

Význam pole RDATA 32bitová IP adresa Doménové jméno name serveru, který je autoritou pro danou doménu. Doménové jméno specifikující synonymum k NAME. Obsahuje dva znakové řetězce. První obsahuje popis HW a druhý popis SW , který je používán na počítači NAME. Obsahuje dvě pole. První 16bitové pole bez znaménka obsahuje preferenci a druhé obsahuje doménové jméno mailového serveru.

3.6 Shrnutí kapitoly 3 V aplikační vrstvě protokolové sady TCP/IP jsou jak uživatelské, tak služební aplikace, které komunikují buď protokolem TCP (spolehlivá služba) nebo protokolem UDP (datagramová nespolehlivá služba). Kapitola 3 pojednává o nejdůležitějších „klasických“ aplikacích: web, elektronická pošta a přenosy souborů. Ze služebních protokolů je pak popsán systém DNS, který reprezentuje distribuovanou databázi symbolických jmen a IP adres internetových uzlů.


53

4 Transportní vrstva architektury TCP/IP Cíle kapitoly: • Podrobný popis protokolu TCP

4.1 Čísla portů Na obr. 4.1 je struktura transportní vrstvy (L4). Pro aplikační vrstvu nabízí dvě služby: spojovanou a spolehlivou službu (TCP) a nespojovanou nespolehlivou službu (UDP). Využívá přitom služeb síťové vrstvy IP, která poskytuje pouze jedinou nespolehlivou datagramovou službu. Spolehlivý a spojovaný charakter TCP je vytvářen softwarově na koncových uzlech.

port AP1

L4 L3

AP2

AP3

UDP

AP1

AP2

UDP

TCP IP

AP3

TCP IP

IP address

connectionless and unreliable channel "best-effort service"

Obr. 4.1:

Transportní vrstva

Na obr. 4.2 je uvedeno názvosloví používané pro označení přenášených datových jednotek oběma protokoly. Terminologie však není jednotná, velmi často se používá obecné označení paket. vrstva aplikační transportní síťová síťové rozhraní Obr. 4.2:

TCP tok bytů segment datagram rámec

UDP zpráva datagram datagram rámec

Názvosloví datových jednotek [5]

Transportní vrstva zajišťuje spojení mezi aplikacemi (procesy), zatímco síťová vrstva zajišťuje spojení mezi uzly. Síťová vrstva tedy adresuje celý uzel (IP adresa), transportní vrstva musí zajistit demultiplex mezi aplikace pomocí čísel portů. Číslo portu je tedy adresou procesu v rámci uzlu. Rozhraní mezi transportní a aplikační vrstvou, tj. identifikace vyššího (aplikačního) protokolu, který bude poskytovanou transportní službu používat, se označuje číslem portu.


54

Port je abstrakce (kladné celé číslo), kterou využívají protokoly transportní vrstvy k rozlišení konkrétního cílového aplikačního procesu běžícího na daném počítači. Server očekává požadavky klientů na známých portech, zatímco klient přiděluje komunikaci libovolná čísla portů mimo rezervovanou oblast. Proces na straně klienta si při spuštění vyžádá číslo portu od operačního systému. Známá čísla portů jsou uvedena v http://www.iana.org/assignments/port-numbers.

on-line

databázi

IANA

na

adrese

Čísla portů pro služby TCP a UDP jsou na sobě nezávislá, ale normálně jsou shodná pro stejnou službu pro oba protokoly. Tento přístup je pouze s ohledem na pohodlí, protokoly samotné to nijak nevyžadují. Porty nesou označení z intervalu desítkových čísel {0; 65 535} (pole číslo portu v datové jednotce UDP nebo TCP má délku 16 bitů). Některá čísla portů pevně přiděluje IANA (ve dvou kategoriích), jiná si dynamicky volí procesy: - známé porty (well-known) se pohybují v rozmezí celých čísel 0 až 1023 a jsou pro aplikační protokoly pevně dané (konkrétní hodnoty přiděluje IANA a jsou uvedeny v databázi http://www iana.org/assignments/port-numbers); umožňují jednoznačnou identifikaci aplikace a zjednodušují tak proces spojení; - registrované porty v intervalu 1024 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, nejsou nikde registrovány a volí si je klientské procesy náhodně, umožňují odlišit klientskou stranu od strany serveru, kdy více klientů tak může komunikovat se serverem a používat stejnou aplikaci. Porty jsou typicky podpořeny vyrovnávací pamětí, takže pokud data dorazí dříve, ne připraven je přijmout, nebudou ztracena. Protokolový software umístěný uvnitř systému umisťuje příchozí pakety pro daný port do konečně dlouhé fronty, dokud nevyzvedne. Na obr. 4.3 je ilustrováno využití portů. V průběhu obousměrné komunikace se používá stále stejná dvojice portů, ale zdrojové a cílové číslo portu se zaměňuje pro každý směr.

Obr. 4.3:

Využití portů při komunikaci [1]

Navázané spojení je jednoznačně charakterizováno pěti parametry: IP adresami a čísly portů obou stran a typem protokolu (UDP nebo TCP). To znamená, že např. více klientů může


55

komunikovat se stejným portem serveru (např. portem 80 u http serveru). To platí i při otevření více oken prohlížeče se stránkami na stejném serveru. Každé okno dostane přidělený jiný dynamický port. Tedy alespoň jeden ze zmíněných pěti parametrů se bude odlišovat.

4.2 Protokol UDP Protokol UDP realizuje nespojovanou službu, tj. nenavazuje spojení. Odesílatel odešle UDP datagram příjemci a už se nestará o to, zdali se datagram náhodou neztratil (o to se musí postarat aplikační protokol). UDP datagramy jsou baleny do IP-datagramu, jak je znázorněno na obr. 4.4. Je patrné, že záhlaví UDP protokolu je velice jednoduché. Obsahuje čísla zdrojového a cílového portu (čísla portů protokolu UDP nesouvisí s čísly portů protokolu TCP). Pole délka dat obsahuje délku UDP datagramu (délku záhlaví + délku dat). Minimální délka je tedy 8, tj. UDP datagram obsahující pouze záhlaví a žádná data. Zajímavé je že pole kontrolní součet nemusí být povinně vyplněné. Výpočet kontrolního součtu je tak v protokolu UDP nepovinný.

Obr. 4.4:

Záhlaví UDP datagramu [3]

I když je délka vyjádřena 16-bitovým číslem, tak je doporučeno, používat datagramy o maximální délce 512B. Tím je zajištěno, že nižší vrstvy nebudou muset datagram rozdělit na menší segmenty. Segmentace totiž smaže hlavní výhodu UDP – jednoduchost a nízkou přenosovou režii.

4.3 Protokol TCP 4.3.1

Základní principy zajištění spolehlivého přenosu

Uvažujme paketovou komunikaci dvou stanic přes nespolehlivý kanál tvořený průchodem přes více vnitřních uzlů sítě. Při přenosu může dojít ke ztrátě dat, duplikaci nebo dokonce ke změně pořadí. Ke ztrátě dat může dojít z důvodu vzniku chyby při přenosu (paket je pak při kontrole zahozen) nebo přeplněním vyrovnávacích pamětí ve vnitřních uzlech. Komunikační protokol musí řešit dva základní problémy - řízení toku – odesílatel dat nesmí zahltit příjemce. Prosté zahazování paketů na straně příjemce při přetížení vede na plýtvání síťovými prostředky – zahozená data se musí znovu přenést. Řízení toku musí omezit rychlost odesílání dat. - chybové řízení – při ztrátě dat nebo chybě musí být zajištěno opakované odvysílání.


56

Oba mechanismy jsou založené na potvrzování došlých dat. V praxi se více používá kladné potvrzování. Potvrzuje-li se každý paket zvlášť, pak hovoříme o metodě Stop-and-Wait, při potvrzování více paketů se pak jedná o metody s plovoucím oknem (Sliding Window). Neobdrží-li odesílatel kladné potvrzení, tak je to známkou ztráty dat – automaticky data znovu odvysílá. Hovoříme proto o metodě ARQ (Automatic Repeat reQuest). 4.3.1.1 Protokol Stop-and-Wait Uvažujme nejdříve, že při přenosu nedochází k chybám. Princip řízení toku protokolem Stop-and-Wait spočívá v potvrzování přijetí každého paketu. Přenášené pakety tak není teoreticky třeba číslovat. Při přenosu nemůže dojít k záměně pořadí. sender

receiver

first packet bit transmitted, t = 0

first packet bit arrives RTT

ACK arrives, send next packet, t = RTT + L / R

Obr. 4.5:

Komunikace protokolem Stop-and-Wait

Uvažujme přenos paketů délky L vedením s přenosovou rychlostí R (uvažujeme pro jednoduchost přímé spojní mezi komunikujícími stanicemi). Počátek časové osy položíme na začátek vysílání paketu. Doba potřebná na odvysílání paketu bude L t tran = . (4.1) R Odpověď (ACK) přijde za čas RTT (Round-Trip Time). V čase RTT+ttran dorazí odpověď k odesílateli a může zahájit vysílání dalšího paketu. Přenosová linka se využívá jen po dobu vysílání paketu (ttran). Můžeme tak definovat míru využití linky jako podíl ttran L/R . U= = (4.2) RTT + t ran RTT + L / R Uvažujme případ, kdy komunikujeme pomocí paketů délky 1kB linkou 1Gb/s na vzdálenost d = 3000km (uvažuje se jen zpoždění šířením ve vláknu). Čtenář si snadno spočítá, že při uvážení indexu lomu vlákna 1,5 bude RTT = 30ms. Vysílání paketu vyžaduje ttran = 8µs. Míra využití linky tak vychází U = 0,00027, tj. efektivní tok 270kb/s ! Naproti tomu u 100Mb/s Ethernetu pro d = 100m a rámec 1kB vychází U = 0,99 . Pro zvýšení míry využití u delších linek by bylo nutné zvětšit délku paketu. Takový paket však bude pravděpodobněji zasažen chybou. Navíc má velikost paketu své technické meze. Metoda Stop-and-Wait je vhodná pro „krátké“ linky, kde RTT < L/R.


57

4.3.1.2 Protokol Stop-and-Wait ARQ Při uvažování ztráty paketů je třeba do protokolu Stop-and-Wait zabudovat mechanismus, který zajistí opakované vysílání. Uvažujeme, že není použita technika dopředného zabezpečení, ale příjemce je schopen pouze detekovat chyby. Mohou nastat tyto eventuality - příjemce potvrdí kladně přijetí paketu (ACK), - příjemce potvrdí záporně přijetí chybného paketu (NAK), - potvrzení nepřijde (ztráta dat nebo potvrzovacího paketu) – po uplynutí časového intervalu (timeout) bude vysílání zopakováno. Vysílač vysílá další paket po obdržení kladného potvrzení. Po uplynutí časového limitu nebo příjmu NAK opakuje vysílání posledního paketu. Časový limit musí mít dostatečnou délku, jinak dojde k opakovanému vysílání paketu dříve, než se přijme jeho kladné potvrzení.

Obr. 4.6:

Protokol Stop-and-Wait ARQ [1]

Je vidět, že může dojít k duplikaci paketů, pokud došlo ke ztrátě ACK. Komunikační protokol musí být navržen tak, aby byla možnost rozpoznání duplikátu, obr. 4.6. Z hlediska míry využití spoje samotné ARQ nepřináší žádnou výhodu.


58

4.3.1.3 Protokoly s plovoucím oknem Protokoly tohoto typu umožňují jistou míru dočasné nezávislosti rychlosti vysílání paketů na rychlosti jejich odebírání na straně cílového uzlu. Pakety se pak musí potvrzovat individuálně. Aby bylo možné sledovat, který paket již je potvrzen, je třeba je číslovat. Bez omezení na obecnosti budeme dále předpokládat, že se při přenosu zachovává pořadí paketů, pakety se mohou ztrácet, nikoli předbíhat. Vysílající uzel si udržuje vysílací okno, ve kterém je udržován seznam pořadových čísel paketů, které vyslal a přijímající uzel mu je dosud nepotvrdil. Přijímající uzel si udržuje přijímající okno, které odpovídá paketům, které lze přijmout. Obecně platí, že obě okna nemusí míst stejnou horní a dolní mez a nemusí mít stejnou šířku, ta ani nemusí být konstantní v průběhu přenosu. Velikost okna určuje potřebnou velikost vyrovnávací paměti. Při vysílání paketu se horní hrana vysílacího okna posouvá o 1. Při příjmu potvrzení se dolní hrana okna posouvá o 1. Poněvadž odeslané pakety se mohou při přenosu pokazit nebo zničit, musí si vysílající uzel odeslané a nepotvrzené pakety udržovat ve vyrovnávací paměti. Její velikost odpovídá rozměru jeho okna. Jakmile se vysílací okno otevře na maximální šířku, další vysílání je pozastaveno do doby, než se nějaká vyrovnávací paměti uvolní.

Obr. 4.7:

Princip plovoucího okna [2]

Přijímající okno definuje pakety, které lze přijmout. Chybně přijaté pakety se ignorují. Jakmile se přijme paket, jehož pořadové číslo odpovídá dolní hraně okna, tento se předá ke zpracování, odešle se jeho potvrzení a okno se rotuje o 1. Přijímající okno si stále udržuje svoji šířku. Pokud má šířku 1, akceptují se pakety docházející výhradně v jejich pořadí odesílání. Větší přijímací okno umožňuje přijímat pakety i mimo pořadí. Vyšší vrstvy však vždy musí dostat data ve správném pořadí, bez ohledu na rozměr přijímajícího okna. Odvození využití linky vychází ze stejných předpokladů jako v případě metody Stopand-Wait. Uvažujme vysílací okno o velikosti N paketů. Právě tolik paketů je možné


59

odvysílat bez nutnosti čekat na potvrzení. Situace je naznačena na obr. 4.8. Přímo tak dostáváme využití linky N L/R , (4.3) RTT + L / R kde L je velikost paketu a R přenosová rychlost. Při zvyšování velikosti okna nastane situace, že vysílání bude probíhat neustále, tj. U = 1. Hraniční velikost okna se vypočte tak, že ve vztahu (4.3) se položí čitatel roven jmenovateli U=

RTT R +1 . (4.4) L Další zvyšování velikosti okna již nepřinese zvýšení rychlosti. Vzorec (4.3) je proto nutné mírně korigovat N min =

NL / R   U = min1, (4.5)  .  RTT + L / R  Vyjádříme-li si velikost okna v bitech W =N L, a uvážíme-li situaci RTT>>L/R, pak bude pro efektivní komunikační rychlost platit W . Ref = R U ≈ (4.6) RTT sender

receiver

last bit transmitted, t = L / R

RTT

first packet bit arrives last packet bit arrives, send ACK

ACK arrives, send next packet, t = RTT + L / R

Obr. 4.8:

K výpočtu efektivnosti metody plovoucího okna

Pokud je komunikační spoj poruchový, některé z přijatých paketů mohou být zničeny. Přijímač musí mít možnost požádat o získání zničených paketů. To řeší dva protokoly: Go-Back-n Protokol „návrat o n“ definuje maximální šířku přijímacího okna 1. Nepřijme se tudíž žádný jiný paket, než ten, který následuje po posledně přijatém. Ostatní přijímač ignoruje a nepotvrzuje. Vysílač si měří časový limit pro získání potvrzení každého odeslaného paketu a pokud takový limit uplyne, odvysílá všechny dosud odvysílané a nepotvrzené pakety znovu. Může se pochopitelně stát, že bude opakovaně vysílat i pakety, které dorazily do cíle neporušené, ale z důvodu špatného pořadí byly ignorovány. Na poruchovém spoji se dostupná efektivní šířka pásma snižuje.


60 Selective reject

Protokol se selektivním opakováním připouští, aby přijímací okno mělo šířku větší jak 1. Přijímající strana přijímá i dobře přenesené pakety následující po ztraceném nebo poničeném paketu, stále však potvrzuje poslední správně přenesený paket podle pořadí (ACK i - 1). Jakmile vysílač podle uplynutí časového limitu zjistí, že došlo k chybě, opakovaně odešle pouze požadovaný paket i, ne však jeho již odeslané a dosud nepotvrzené následníky. Jakmile přijímající strana zjistí, že má správně přijatu delší posloupnost paketů, potvrdí paket s nejvyšším pořadovým číslem. Lépe se využívá šířka pásma spoje, zvyšují se však nároky na paměť na straně přijímače.

4.3.2

Segmenty TCP

Protokol TCP přenáší neformátovaný proud bytů, který se pro účely přenosu musí rozdělit na tzv. segmenty, obr. 4.9. Jelikož TCP segmenty jsou baleny do IP datagramů, který má pole délka dlouhé 16 bitů, tak TCP segment může být dlouhý maximálně 65535 minus délka TCP-záhlaví. IP-datagram se vkládá do linkového rámce. Použije-li se příliš velký TCPsegment, který se celý vloží do velkého IP-datagramu, který je větší než maximální velikost přenášeného linkového rámce (MTU), pak IP protokol musí provést fragmentaci IPdatagramu. Fragmentace zvyšuje režii, proto je cílem vytvářet segmenty takové velikosti, aby fragmentace nebyla nutná.

Obr. 4.9:

Segmentace dat [3]

TCP segment je část z toku dat tekoucích od odesílatele k příjemci. Pořadové číslo odesílaného bajtu (SEQ) je pořadové číslo prvního bajtu TCP segmentu v toku dat od odesílatele k příjemci (TCP segment nese bajty od pořadového čísla odesílaného bajtu až do délky segmentu). Tok dat v opačném směru má samostatné (jiné) číslování svých dat. Jelikož pořadové číslo odesílaného bajtu je 32 bitů dlouhé, tak po dosažení hodnoty 232-1 nabude cyklicky opět hodnoty 0. Číslování obecně nezačíná od nuly (ani od nějaké určené konstanty), ale číslování by mělo začínat od náhodně zvoleného čísla. Naopak pořadové číslo přijatého bajtu (ACK) vyjadřuje číslo následujícího bajtu, který je příjemce připraven přijmout, tj. příjemce potvrzuje, že správně přijal vše až do pořadového čísla přijatého bajtu mínus jedna. Délka záhlaví vyjadřuje délku záhlaví TCP segmentu v násobcích 32 bitů (4 bajtů). Délka okna vyjadřuje kolik dat je příjemce ještě schopen přijmout, tj. přírůstek pořadového čísla přijatého bajtu, který bude příjemcem ještě akceptován.


61

Obr. 4.10: TCP segment [3]

• • • • • •

V poli příznaků mohou být nastaveny následující příznaky: URG – TCP segment nese naléhavá data. ACK – TCP segment má platné pole „Pořadové číslo přijatého bajtu” (nastaven ve všech segmentech kromě prvního segmentu, kterým klient navazuje spojení). PSH – Zpravidla se používá k signalizaci, že TCP segment nese aplikační data, příjemce má tato data předávat aplikaci. Použití tohoto příznaku není ustáleno. RST – Odmítnutí TCP spojení. SYN – Odesílatel začíná s novou sekvencí číslování, tj. TCP segment nese pořadové číslo prvního odesílaného bajtu (ISN). FIN – odesílatel ukončil odesílání dat. Přijetí TCP segmentu s příznakem FIN neznamená, že v opačném směru není dále možný přenos dat. Jelikož protokol TCP vytváří plně duplexní spojení, tak příznak FIN způsobí jen uzavření přenosu dat v jednom směru. V tomto směru už dále nebudou odesílány TCP segmenty obsahující příznak PSH (nepočítaje v to případné opakování přenosu).

V dalším textu bude kombinace nastavených příznaků zapisována podle prvních písmen z názvu příznaku. Pokud je příznak nenastaven, pak místo něj napíšeme tečku. Např. skutečnost, že TCP segment má nastaveny příznaky ACK a FIN a ostatní příznaky nenastaveny, zapíšeme: .A…F . Kontrolní součet je důležitý z hlediska zabezpečení integrity přenášených dat. Tento kontrolní součet se počítá z TCP segmentu doplněného o pseudozáhlaví, podobně jako u UDP. Kontrolní součet vyžaduje sudý počet bajtů, proto v případě lichého počtu se data fiktivně doplní jedním bajtem na konci. Povinné položky TCP záhlaví tvoří 20 B. Za povinnými položkami následují volitelné položky. Volitelná položka se skládá z typu volitelné položky, délky volitelné položky a hodnoty. Délka TCP záhlaví musí být dělitelná čtyřmi. V případě, že délka záhlaví by nebyla dělitelná čtyřmi, pak se záhlaví doplňuje prázdnou volitelnou položkou – NOP. Jelikož pole délka záhlaví je pouze 4 bity dlouhé, tudíž záhlaví může být dlouhé maximálně 15x4=60 bajtů. Povinné položky zaberou 20 bajtů, takže na volitelné zbývá nejvýše 40 bajtů.


62

Okno inzerované příjemcem má v TCP záhlaví vyhrazeny 2B. Příjemce proto může inzerovat okna pouze v rozmezí 0 až 65535. Taková okna jsou u gigabitových sítí příliš malá. Řešením je použití volitelné položky „zvětšení okna” v záhlaví TCP segmentu. Tato volba může být použita pouze v segmentech inicializujících spojení, tj. v segmentech s příznakem SYN. Pomocí volitelné položky „zvětšení okna” se oba konce spojení dohodnou na zvětšení okna v intervalu 0 až 14. Označme toto zvětšení jako n. V každém směru spojení může být dohoda jiná. Hodnota velikosti okna je pak w2n, kde w je inzerovaná hodnota v hlavičce.

4.3.3

Navázání a ukončení spojení

Protokol TCP využívá k transportu dat Internetem protokol IP, avšak nad tímto protokolem zřizuje spojovanou službu. Musí řešit problémy navázání a ukončení spojení, potvrzování přijatých dat, vyžádání ztracených dat, ale také problémy průchodnosti přenosové cesty. 4.3.3.1 Navazování spojení Předpokládejme spojení klient – server. Klient začíná navazovat spojení odesláním prvního TCP segmentu (1), obr. 4.11, kde je port odesílatele 1458 a port příjemce 4433.

Obr. 4.11: Navazování spojení [3] Klient vygeneruje náhodné číslo v intervalu 0 až 232-1, které použije jako startovací pořadové číslo odesílaného bajtu (SEQ). V našem případě bylo vytvořeno SEQ=145165778. Skutečnost, že klient právě vytvořil startovací pořadové číslo odesílaného bajtu vyznačí v TCP segmentu nastavením příznaku SYN (….S.). Během spojení již pořadové číslo odesílaného bajtu bude vždy vyjadřovat číslo odesílaného bajtu, tj. nemůže být znovu vygenerováno. Klient nemůže v žádném dalším TCP segmentu během tohoto spojení nastavit příznak SYN. Segment (1) je prvním segmentem v TCP komunikaci, proto nemůže potvrzovat žádná přijatá data. Pole ACK nemá platný význam (bývá vyplněno binárními nulami) a nemůže být tedy ani nastaven příznak ACK (příznak ACK je nastaven ve všech dalších TCP segmentech až do ukončení spojení).


63

Součástí segmentů (1) a (2) je volitelná položka záhlaví TCP segmentu MSS (Maximum segment size). Tato položka oznamuje druhé straně maximální délku datové části TCP segmentu jakou si přeje přijímat (aby se pokud možno zamezilo fragmentaci IPdatagramu). Tato volba se může vyskytovat pouze v TCP segmentech s nastaveným příznakem SYN. Implicitně se MSS používá 536 bajtů. Tato hodnota je používána pro spojení mimo lokální síť (přes WAN). Pro linkový protokol Ethernet II je maximální délka datové části rámce rovna 1500, po odečtení hlaviček dostáváme MSS=1460. Druhý segment již potvrzuje přijatá data – má nastaven příznak ACK na hodnostu pořadového čísla následujícího bajtu, který očekává. Zároveň nese náhodně vygenerované číslo SEQ. Třetí segment rovněž potvrzuje data, hodnota ACK je nastavena na číslo následujícího očekávaného bajtu. Třetí a další segment již nemůže nést volitelnou položku záhlaví MSS (maximální délka segmentu). Třetím segmentem končí navazování spojení. Někdy se proto také „česky” říká, že protokol TCP potřebuje pro navázání spojení „třífázový handshaking” (pro ukončení spojení pak „čtyřfázový”). Po navázání spojení je možné data přenášet oběma směry (TCP je plně duplexní spoj). Skutečnost, že TCP segment nese aplikační data je vyjádřena nastavením příznaku PSH. Ne všechny TCP segmenty musí nutně nést aplikační data, tj. mít nastaven příznak PSH (.AP…). Může se stát, že jeden konec spojení odesílá data, avšak druhý konec nemá momentálně žádná data k odeslání. I když druhý konec nemá co posílat, tak musí potvrzovat přijatá data. Takové potvrzování provádí TCP segmenty s nenastaveným příznakem PSH (.A….), tj. segmenty bez dat. V každém okamžiku je spojení v tzv. stavu (LISTEN, SYN_SENT, apod.), obr. 4.11. Pokud se spojení naváže, pak klient i server přecházejí do stavu ESTABLISHED, tj. spojení navázáno. V tomto stavu si mohou oba konce současně předávat data. Spojení a jejich stavy snadno vypíšete na vašem počítači (ať se jedná o UNIX či Windows) příkazem: netstat -a 4.3.3.2 Ukončování spojení Ukončit spojení může libovolná strana. Strana, která první odešle TCP segment s příznakem FIN (ukončení spojení) provádí tzv. aktivní ukončení spojení (active close), druhé straně nezbývá než provést pasivní ukončení spojení (passive close). Teoreticky je možné i současné ukončení spojení. Provede-li jedna strana aktivní ukončení spojení, pak již nemůže odesílat data (nemůže odeslat TCP segment s příznakem PSH). Druhá strana však může v odesílání dat pokračovat až do té doby, dokud neprovede sama ukončení spojení. Mezidobí od aktivního ukončení spojení do ukončení spojení nazýváme polouzavřeným spojením (half close). Pro řádné uzavření spojení jsou nutné čtyři TCP segmenty. Segment (6) startuje aktivní uzavření spojení nastavením příznaku FIN. Segment (7) potvrzuje uzavření spojení druhou stranou, tj. provádí pasivní uzavření spojení. Většinou segment (7) obsahuje též příznak FIN a dochází tím ke startu uzavření celého spojení. Obrázek však znázorňuje obecný případ, kdy segment (7) příznak FIN neobsahuje, protože tato strana chce pokračovat ve spojení, tj. chce použít polouzavřené spojení pro přenos aplikačních dat. Strana, která spojení uzavřela již nemůže odesílat žádná data (jí odesílané segmenty nemohou obsahovat příznak PSH).


64

Obr. 4.12: Ukončování spojení [3] Obr. 4.12 ukazuje stavy při ukončování spojení. Ve stavu FIN_WAIT2 strana zůstává do té doby, dokud protějšek nezašle TCP segment s příznakem FIN, tj. do přechodu do stavu TIME_WAIT. Pokud aplikace nepočítá s přenosem dat v polouzavřeném spojení, a spojení je nečinné po 11,25 minuty, pak operační systém automaticky změní stav spojení na CLOSED. Odesláním TCP segmentu (9) je potvrzeno úplné ukončení spojení. Tento segment již není potvrzován, proto strana zůstává ve stavu TIME_WAIT po dobu 2 minut (některé implementace TCP/IP zkracují tuto dobu až na 30 s). Tato doba by totiž měla přibližně odpovídat dvojnásobku doby života TCP segmentu v síti. Strana, která odeslala segment (9) přechází do stavu CLOSED až po uplynutí zmíněného intervalu. 4.3.3.3 Odmítnutí spojení Spojení se odmítá nastavením příznaku RST (Reset) v záhlaví TCP segmentu. Generuje se např. když klient požaduje spojení se serverem na portu, na kterém žádný server neběží. To je rozdíl oproti protokolu UDP. Pokud je zaslán UDP datagram na port, kde neběží žádný server, pak systém odpoví ICMP zprávou nedosažitelný port.

4.3.4

Technika okna

Protokol TCP používá techniku plovoucího okna. Číslo SEQ v hlavičce udává relativní pořadové číslo prvního bajtu segmentu. Číslo ACK udává relativní pořadové číslo dalšího očekávaného bajtu. Potvrzuje tím, že všechny předchozí bajty byly přijaty správně. V každém segmentu také protistrana v položce WIN signalizuje, kolik bajtů ještě může přijmout (tj. kolik zbývá prostoru v jeho vyrovnávací paměti). Velikost okna se tedy může během přenosu dynamicky měnit. Odesílatel nesmí poslat více dat, než povoluje položka WIN. Na obr. 4.13 jsou analyzovány některé scénáře ztráty segmentu při přenosu. V případě a) došlo ke ztrátě segmentu s potvrzením (tento segment zároveň může v opačném směru přenášet data). Po uplynutí časového limitu byl segment odvysílán znovu.

Počítačové a komunikační sítě Host A

Host B

=100 AC K

X

loss Seq=9 2

, 8 byte

Host B

Seq=9 2

s data

, 8 byte s data Seq= 100, 20 by tes d ata

Seq=92 timeout

, 8 byte

Host A

s data

Sendbase = 100 SendBase = 120

=100 AC K

SendBase = 120

time

0 10 K= 120 C A ACK= Seq=9 2

, 8 byte

Seq=92 timeout

Seq=9 2

timeout

65

AC

s data

20 K=1

time

b) předčasný timeout

a) ztráta segmentu

Host A Host A

Host B

timeout

Seq=9 2

Seq=1 0

, 8 byte

Seq=9 2

, 8 byte s data Seq= 100, 20 by tes d ata Seq=1 20, 8 bytes data 0 0 1 K= AC 00 K=1 AC

s data

=100 AC K 0, 20 bytes data

X

loss =120 AC K

SendBase = 120

time

Host B

Seq= 100, 20 by tes d a

time

AC

ta

28 K=1

c) kumulativní potvrzení d) „fast retransmit“ Obr. 4.13: Některé scénáře ztráty dat V případu b) byl časový interval pro čekání příliš krátký. Příjemce obdrží duplikovaná data. V případě c) došlo ke ztrátě potvrzení ACK=100. Nicméně další potvrzení ACK=120 dorazilo v pořádku. TCP potvrzuje data kumulativně, tj. ACK=120 potvrzuje přijetí všech dat až k pořadovému číslu 119. Na tuto ztrátu segmentu nemusí odesílatel vůbec reagovat ! V případě d) došlo ke ztrátě segmentu SEQ=100. Další segment se přenesl. Příjemce však stále potvrzuje přijetí prvního segmentu (ACK=100). Přijetí stále stejného ACK je pro odesílatele známkou ztráty segmentu. V rámci TCP je definován algoritmus „fast retransmit“, kdy po přijetí tří stejných potvrzení odesílatel pošle ztracený segment (na obrázek se 3 stejné


66

ACK nevešly). Další data má již příjemce k dispozici, potvrdí proto celý usek pomocí ACK=128. Jedná se v podstatě o metodu Selective-Repeat. Bez fast-retrans,mit se TCP chová jako Go-Back. Pro potvrzovací mechanismus je důležitá volba čekacích intervalů. Příliš dlouhé timeouty vedou v případě ztráty dat ke zdržování přenosu, příliš krátké hodnoty pak ke zbytečné duplikaci dat. V TCP je čekací interval určován průběžně na základě vyhodnocení zpoždění při přenosu. Měří se hodnota RTT (viz kap 4.3.1). Jedná se v podstatě o náhodnou veličinu, ze které se vypočítává průběžně stření hodnota (RTT) a rozptyl (DEV), resp. jeho odhad.

Obr. 4.14: RTT na reálném spoji [1] Používá se průměr s exponenciálním „zapomínáním“ (RFC 2988) RTTnew = 0,875 RTTold + 0,125 RTTi ,

DEVnew = 0,75 DEVold + 0,25 RTTi − RTTnew Pro timeout se pak použije hodnota t timeout = RTT + 4 DEV .

4.3.5

(4.7)

(4.8)

Zahlcení sítě

4.3.5.1 Řízení síťové zátěže Řízení síťové zátěže (congestion control) je úplně jiný typ řízení přenosového provozu než řízení toku dat. Jeho cílem je udržení nejvýše takového množství paketů v síti, resp. v její části, aby nedocházelo k neúměrným časovým prodlevám ve frontách. Ze závěrů teorie hromadné obsluhy vyplývá, že jakmile se dosáhne 80 a více % využití kapacity přenosových cest, velikost front může dramaticky narůstat i v případě, že rychlost příchodu paketů do uzlu je nižší než rychlost jejich vysílání. Proto je potřeba zabraňovat neomezenému nárůstu front paketů v mezilehlých uzlech, tj. řízením toku dat mezi uzly je potřeba udržovat dostatečnou volnou rezervu v kapacitě vyrovnávacích pamětí pro opakované přenosy. Vyrovnávacích pamětí v uzlech je konečný počet. Jsou-li všechny vyrovnávací paměti v uzlu plné a do uzlu přicházejí další pakety, je nutné přicházející pakety zapomínat. Zdroj


67

těchto paketů je bude vysílat znovu, prakticky navíc k těm, které by vysílal i v případě normálního provozu. Pro opakované vyslání se uzel rozhodne např. na základě skutečnosti, že do jisté doby neobdrží potvrzení příjmu paketu. Tak se opakovaně vysílá stále více a více paketů a zůstává stále méně a méně šířky pásma pro přenos nových paketů. Celková propustnost rychle klesá. Navíc může docházet k opakovanému přenosu i již úspěšně přenesených paketů, poněvadž může docházet i ke ztrátám potvrzení. Nakonec si sít vyčerpá přenosovou kapacitu opakovanými přenosy a propustnost sítě klesne prakticky na nulu. Situaci ilustruje obr. 4.15.

Obr. 4.15: Zahlcení sítě [2] Techniky, které zamezují zahlcení, můžeme rozdělit na explicitní a implicitní. Při explicitním způsobu dochází k výměně informací mezi uzlem a „sítí“. U implicitních technik uzel sám detekuje, že dochází k zahlcení a omezí rychlost vysílání. Implicitní metody Pokud dojde k zahlcení sítě, tak vzroste zpoždění paketů při přenosu a zároveň vzroste míra jejich ztrátovosti. Koncový uzel musí být schopen detekovat tuto situaci. Boudou-li všechny koncové uzly schopné omezit generovaný datový tok po detekci zahlcení, tak dojde k uvolnění sítě. Implicitní metodu realizují koncové uzly bez přímé účasti vnitřních uzlů sítě. Implicitní technika je efektivní v datagramových sítích (např. Internet). V těchto sítích neexistuje žádný logický spoj, který by mohl být regulován. Naproti tomu takový logický spoj existuje mezi dvěma uzly komunikujícími protokolem TCP. Implicitní metoda pro zamezení zahlcení je proto přímo zabudovaná do protokolu TCP. Explicitní metody Síť upozorní uzel na zahlcení a ten omezí generování toku. Obvykle se tato metoda používá u spojovaných sítí a řídí toky jednotlivých spojení. Existuje několik přístupů: - Příznak zahlcení – síť nastaví v přenášených paketech příznak zahlcení. Koncový uzel by měl omezit generování toku. - Kreditový systém – síť indikuje, jaký objem dat může uzel odvysílat v daném logickém spoji. Pokud je kredit vyčerpán, tak se vysílání zastaví. Tato metoda se používá pro regulaci toku mezi koncovými uzly. - Omezení rychlosti – síť poskytuje explicitní limit přenosové rychlosti. Tato metoda je implementovaná v ATM.

68


4.3.5.2 Řízení zátěže v TCP Řízení zátěže řeší vztah odesílatel-síť. Na straně odesílatele se proto zavádí druhé okno. Toto okno se snaží specifikovat, kolik může odesílatel odeslat nepotvrzených dat, aniž by došlo k zahlcení sítě. Toto okno na straně odesílatele se anglicky nazývá Congestion Window (zkratkou CWND). Odesílatel postupně zvyšuje CWND. CWND však nelze zvyšovat neomezeně. Hranice, za kterou už je větší pravděpodobnost zahlcení, se označuje SSTHRESH. Internet však budeme chtít využívat maximálně, tj. budeme chtít najít největší použitelné CWND (to bude někde nad SSTHRESH). SSHTRESH má smysl udržovat pouze v násobcích velikosti odesílaného segmentu (MSS). Odesílatel odesílá vždy jen takové množství nepotvrzených dat, které nepřevyšuje okno inzerované příjemcem (WINDOW) ani nepřevyšuje CWND, tj. odesílá jen nejvýše min(WINDOW,CWND) nepotvrzených dat. 4.3.5.3 Pomalý start CWND se určuje dynamicky. Při otevření spojení nejprve odešle jeden segment a vyčká na jeho potvrzení. Pokud potvrzení obdrží, pak vyšle dva segmenty. Pokud potvrzení obdrží, pak odešle čtyři atd. Jedná se o exponenciální řadu 2n.

Obr. 4.16: Pomalý start a vyhýbání se zahlcení [3] Pochopitelně, že po několika krocích se odesílatel dostane do situace, kdy síť zahltí a potvrzení nedostane, tj. musí opakovat odesílání segmentů, protože se segment ztratil. V takovém okamžiku se CWND zmenší na polovinu a tato hodnota se také nastaví do veličiny SSTHRESH (pokud by SSTRESH mělo být menší než dva segmenty, pak se nastaví na velikost dvou segmentů). Po první ztrátě se CWND zvyšuje lineárně pouze o (MSSxMSS/CWND + MSS/8) počítáno v celočíselné aritmetice. Toto „drobné zvětšování” CWND se nazývá algoritmus vyhýbání se zahlcení (Congestion Avoidance Algorithm). Odesílatel udržuje pro každé spojení aktuální hodnoty proměnných MSS, WINDOW, CWND i SSTHRESH. MSS je určeno příjemcem v okamžiku navazování spojení. WINDOW určuje příjemce dynamicky během spojení – specifikuje množství dat, která se mu vejdou do vyrovnávací paměti. 4.3.5.4 Ztráta segmentu Během spojení se velikost CWND řídí algoritmem AIMD (Additional Increase Multiplicative Decrease).


69

Pokud dojde ke ztrátě segmentu (příjemce obdrží třetí duplikát), pak: • nastaví SSHTRESH na CWND/2, • zopakuje odeslání TCP segmentu, • nastaví CWND na SSHTRESH+3xMSS (tj. CWND klesne prakticky na polovinu). Poté CWND opět roste lineárně. Pro velikost okna jsou tak typické oscilace podle obr. 4.17.

Obr. 4.17: Typické oscilace CWND [1] Přenosová rychlost u metody plovoucího okna je dána jako Ref ≈ W / RTT . Velikost okna osciluje mezi 50% a 100% jisté „maximální“ hodnoty. Průměrná rychlost je pak Ravg =

0,75W . RTT

(4.9)

4.3.5.5 Rozložení šířky pásma Uvažujme konfiguraci podle obr. 4.18. Dvě stanice sdílejí společnou pomalou linku, uk které dojde k zahlcení. Důsledkem zahlcení je ztráta segmentů, na kterou ovladače protokolu TCP na obou stanicích zareagují podle algoritmu AIMD, tj. sníží přenosovou rychlost. Je možné ukázat, že v tom případě se kapacita odchozí linky rozdělí rovnoměrně mezi obě stanice. Proces je možné ilustrovat diagramem na obr. 4.18. Každá osa představuje datový tok jedné stanice. Z kteréhokoli výchozího bodu dokonverguje „pracovní bod“ do stavu, kdy je rychlost rozdělena na poloviny. Podobnou vlastnost nemá protokol UDP, který se především v poslední době používá na přenos multimediálních signálů. Při vysokém podílu provozu UDP dojde k tomu, že vlivem mechanismu AIMD dojde ke zpomalení TCP.


70

Obr. 4.18: Sdílení společné (pomalé) linky [1]

4.4 Shrnutí kapitoly 4 Transportní vrstva Internetu zahrnuje dva protokoly: UDP a TCP. Protokol UDP je velmi jednoduchý. Prakticky jen přidává hlavičku k přenášeným datům. Je vhodný pro aplikace využívající přenos diskrétních zpráv, kde zabezpečení řeší až aplikační vrstva. V poslední době se protokol UDP využívá pro přenos multimediálních dat. Velkou výhodou je možnost současného „vysílání“ více odběratelů dat (multicasting), což není principálně možné s protokolem TCP. Protokol TCP poskytuje spojovanou a spolehlivou službu. Spolehlivost se vytváří softwarově na koncových stanicích. Vlastní přenos přes síť protokolem IP je nespolehlivý. TCP je velmi propracovaný komplexní protokol, který obsahuje kromě řízení toku i implicitní mechanismy proti zahlcení sítě.


71

5 Síťová vrstva architektury TCP/IP Cíle kapitoly: • Objasnit principy adresování a směrování v sítích s protokolem IP.

5.1 Funkce síťové vrstvy Síťová vrstva má za úkol dopravu dat mezi koncovými systémy. Existuje v každém uzlu uvnitř sítě. Topologie rozlehlých sítí má tvar obecného polygonu. Mezi komunikujícími stanicemi existuje více cest. Hlavní funkcí síťové vrstvy je nalezení optimální cesty v síti. Tento proces nazýváme směrováním. application transport network data link physical

network data link physical

network data link physical network data link physical



network data link physical network data link physical

Obr. 5.1:


application transport network data link physical

Síťová vrstva [1]

Pro ustanovení spojení mezi dvěma koncovými partnery v síti je potřeba, aby se oba partneři mohli na sebe vzájemně odkazovat. Každé zařízení identifikovatelné na sítové úrovni má proto svoji jedinečnou síťovou adresu. Sítová vrstva paketové sítě může plnit buďto spojovanou službu udržováním virtuálních kanálů nebo nespojovanou datagramovou službu. Spojení, virtuální kanál, se ustanovuje mezi koncovými uzly komunikace, na jeho ustanovování a udržování se podílí všechny uzly, které leží na optimální cestě mezi nimi. Virtuální kanál zaručuje doručení dat se zachováním pořadí, bez duplikátů apod. Datagram se naopak dopravuje nezávisle na ostatních. Jednotlivé datagramy komunikace dvou konkrétních partnerů se mohou dopravovat po různých cestách, jejich volba se řeší nezávisle na sobě dynamicky. To sice způsobuje zvýšení režijních ztrát vyvolaných opakovaným řešením směrování, tj. hledáním cesty k cílovému, adresovanému uzlu, ale současně to usnadňuje adaptivnost směrování z hlediska poruch sítě (výpadky uzlů, spojů, jejich přetížení apod.).

72


5.2 Základy směrování Směrovací algoritmy řídí průchod paketů sítí od zdrojového k cílovému uzlu. Budeme se zabývat směrováním v sítích s přepojováním paketů, tj. v sítích s trvale ustanovenými fyzickými komunikačními cestami, jejichž přenosová kapacita se dynamicky plně využívá pro přenos jednotlivých zpráv. Okamžiky, ve kterých se provádí rozhodování o směrování toku paketu mezi uzly, závisí na tom, zda se cesta paketu od odesilatele k adresátovi stanovuje opakovaně (dynamicky) vždy v každém mezilehlém uzlu znovu, nebo zda se stanovuje pro jistou posloupnost paketů na jistou dobu jednorázově. V prvém případě komunikační software poskytuje tzv. datagramovou službu, ve druhé případě službu virtuálních okruhů. V datagramových sítích mohou dva po sobě následující pakety procházet různými cestami, nezaručuje se jejich doručení, pořadí, duplikace apod. Směrování se provádí zvlášť pro každý paket. Spolehlivost přenosové služby se v takovém případě zabezpečuje až v koncových uzlech přenosu. V sítích s virtuálními kanály se směrování provede pouze při ustanovení virtuálního kanálu. Všechny pakety vysílané virtuálním kanálem postupně projdou touto cestou a potom je virtuální kanál zrušen nebo přesměrován. Hlavní funkce směrovacích algoritmů je výběr cesty mezi různými dvojicemi (zdrojcíl). Existuje více způsobů klasifikace směrovacích algoritmů. Jednou možností je jejich rozdělení na: - centralizované směrovací algoritmy, kdy všechna směrovací rozhodnutí provádí jeden centrální uzel, - distribuované směrovací algoritmy, kdy je výpočet směrovacích cest rozdělen mezi uzly sítě, které si nezbytné informace mezi sebou vyměňují, - izolované směrovací algoritmy, kde uzly vzájemně nespolupracují. Rozhodnutí o nejvhodnější cestě provádí každý uzel sám, a to na základě takových informací, které dokáže získat bez spolupráce s ostatními uzly. Jiná klasifikace směrovacích algoritmů se provádí podle toho, zda algoritmus mění směrovací cesty podle okamžitého stavu provozu v síti. - Statické směrovací algoritmy cestu danou relací mezi zdrojem a cílem stanovují pevně, bez ohledu na podmínky provozu. Mění se pouze v případě poruchy linky nebo uzlu. Tento typ algoritmů nemůže dosáhnout vysoké propustnosti, pokud se podmínky provozu podstatně mění. Doporučuje se bud pro velmi jednoduché sítě a nebo pro sítě, ve kterých efektivnost provozu není důležitá. Směrovací tabulky může vytvářet např. správce sítě. - Většina paketových sítí používá některou formu adaptivního dynamického směrování, kdy se cesty použité ke směrování zátěže mezi zdrojem a cílem mění v závislosti na stavu spojů. Směrovací algoritmy se vesměs opírají o jednoduché metody z teorie grafů. Typickým příkladem je problém nejkratších cest. Uvažujme síť jako matematický graf, kde jednotlivé uzly odpovídají vrcholů grafu a hrany představují linky, obr. 5.2. Každé hraně (lince) přiřadíme číslo, které značí „cenu“ přenosu. Např. to může být převrácená hodnota přenosové rychlosti, zpoždění, počet přeskoků k cíli, apod. V teorii grafů se tomuto číslu říká délka hrany nebo váha. Obecně se váha linky může lišit podle směru komunikace. Nyní je možné formulovat úlohu směrování: Je dána "délka" každého spoje v síti a cílem je najít cestu spojující dva dané uzly minimální celkové délky.


73

Typický příkladem dynamického směrovacího algoritmu je Bellman-Fordův algoritmus, který řeší problém nejkratších cest. Hledá nejkratší cesty z daného zdrojového uzlu ke všem ostatním uzlům nebo ze všech uzlů k jedinému cílovému uzlu [7], [2]. Na distribuované formě tohoto algoritmu je založen směrovací protokol RIP. Na obr. 5.2 jsou nalezené nejkratší cesty z uzlu 1 ke všem ostatním. Výsledkem činnosti směrovacích algoritmů jsou směrovací tabulky jednotlivých uzlů, podle kterých se řídí předávání paketů. Příklad je na obr. 5.2. V levém sloupci je cílová adresa, v pravém sloupci pak sousední uzel, kam se má paket poslat. Přijme-li určitý uzel paket, pak podle cílové adresy tohoto paketu vyhledá ve směrovací tabulce sousední uzel, kterému paket odešle. Např. uzel 1 přijal paket adresovaný uzlu 6. Odešle jej do uzlu 3 (poslední řádek tabulky). Odtud se dostane do uzlu 5 a pak do uzlu 6.

Obr. 5.2:

5.2.1

Síť jako matematický graf s ohodnocenými hranami a směrovací tabulka uzlu 1

Centralizované směrování

Adaptivní algoritmus může být koncipován tak, že veškeré informace o aktuálním stavu celé sítě se průběžně shromažďují v jediném centrálním bodě, tzv. směrovacím centru (RCC, Routing Control Center), které pak na jejich základě samo přijímá všechna potřebná rozhodnutí, a ostatním uzlům je oznamuje. Výhodou je možnost optimálního rozhodování na základě znalosti skutečného stavu celé sítě. Problém je ovšem v tom, že má-li být centralizované směrování opravdu adaptivní, tedy má-li průběžně reagovat na aktuální stav sítě, musí být vyhledávání nejvhodnějších cest prováděno dostatečně často. Vlastní hledání cest je samo o sobě operací značně náročnou na výpočetní kapacitu. Síť je ohrožena výpadkem směrovacího centra. Nezanedbatelná není ani zátěž přenosových cest, kterou představuje neustálý přísun aktuálních informací o stavu sítě do směrovacího centra, stejně tak jako zpětná distribuce výsledků.

5.2.2

Izolované směrovaní Lavinové (záplavové) směrování (flooding)

Je řešeno tak, že v každém uzlu je paket rozmnožen do všech linek a výjimku té, odkud paket přišel. Testuje se však nejdříve, zda paket už v tomto uzlu nebyl. Pokud ano, zruší se. Tato metoda je velmi odolná vůči poruchám sítě a navíc zaručuje, že paket přijde k adresátovi za nejkratší možnou dobu (zkouší se totiž všechny cesty i nejkratší). Samozřejmě je velkou nevýhodou dostatečné zátěž sítě mnoha zbytečnými přenosy. Lavinové směrování proto připadá v úvahu pouze u sítí s malou hustotou provozu. Další možné použití je nalezení


74

nejrychlejší cesty mezi dvojicí uzlů z hlediska okamžitého stavu sítě charakterizovaného stupněm zahlcení (délkami front paketů) v jednotlivých uzlech. Z jednoho uzlu se vyšle krátký testovací paket, který si pamatuje, kudy procházel. První takový paket, který dojde k cíli, obsahuje momentálně nejrychlejší cestu, kterou je však nutné sdělit i vysílajícímu uzlu. Tato metoda se také používá pro výměnu informací mezi jednotlivými směrovači u distribuovaných algoritmů. Zpětné učení Předpokládá, že každý uzel si do svých směrovacích tabulek průběžně poznamenává, ze kterého směru dostává pakety, pocházející od jiných uzlů. Tím se postupně "učí", ve kterém směru se tyto uzly nalézají. Když pak sám potřebuje odeslat nějaký paket jinému uzlu, vyšle jej tím směrem, ze kterého dříve přijal paket, pocházející od téhož uzlu. Metoda vyžaduje síť, která netvoří smyčky (stromová struktura). Je proto vhodná pro lokální sítě. Dojde-li k výpadku určité přenosové cesty, kterou se jednotlivé uzly již "naučily", komunikace přestane probíhat. Řešení spočívá v mazání záznamů z tabulky po nějaké době a jejich opětovné obnovení. Náhodné směrování Má význam spíše teoretický. Pakety nejsou v uzlech rozmnožovány, ale náhodně odesílány s tím, že za určitou dobu dojdou k cíli. Pohybují se tak v síti chaoticky. Existují úpravy, kdy různými pravděpodobnostmi pro jednotlivé linky uzlu lze realizovat provoz více méně deterministický s ponecháním rezervy pro případy chyb linek nebo uzlů. Metoda značně zatěžuje síť. Algoritmus horké brambory Uzel se snaží zbavit každého paketu resp. datagramu co možná nejrychleji. Sleduje proto počet paketů, které čekají ve frontě na odeslání jednotlivými směry, a nový paket zařadí do té fronty, která je momentálně nejkratší. Uzel se tedy nerozhoduje podle adresy, ani nehledá nejkratší cestu pro přenos paketu, pouze se jej snaží co nejrychleji zbavit ve víře, že po jisté době přeci jen dojde ke svému cíli. V praxi se ovšem algoritmus horké brambory spíše kombinuje s jinými algoritmy resp. metodami - nejčastěji je používán jako jejich doplněk, který se uplatní až v okamžiku, kdy počet paketů v některé frontě překročí určitou únosnou mez. Zdrojové směrování Každý paket v sobě nese kompletní informaci o uzlech, kterými má projít. Tento seznam sestavuje odesílatel, který musí sestavit vhodnou cestu. Je to možné udělat např. tak, že záplavovou metodou pošle průzkumný paket, který zaznamenává uzly, kterými prošel. Paket, který první dojde k cíli, prošel optimální cestou. Pošle se napět odesílateli a ten adresy v něm použije pro zdrojové směrování.

5.2.3

Distribuované metody směrování

Jakmile probíhá výměna stavových informací mezi jednotlivými uzly sítě, je možné efektivně implementovat distribuovanou verzi algoritmu hledání nejkratších cest v síti. Používají se dva základní směrovací algoritmy: algoritmus vektorů vzdáleností (DVADistance Vector Algorithm), algoritmus stavu spojů (LSA- Link State Algorithm).


75

Distance Vector Algorithm Algoritmus vektorů vzdáleností se jinak také nazývá Ford-Fulkersonův, podle autorů, kteří poprvé tento typ algoritmu popsali. Tento algoritmus byl poprvé použit při směrování v první paketové síti ARPANET už v r. 1969.

výchozí stav

po 1. iteraci Obr. 5.3:

Činnost algoritmu DVA [9]

Základem algoritmu je, že každý směrovač si vypočítává vzdálenost ke každému dostupnému cíli. A to na základě informace, kterou obdrží pouze od svých sousedů (nikoli na základě znalosti topologie celé sítě). Takže se celé směrovací tabulky pravidelně (nejčastěji každých 30 až 90 s) vyměňují výhradně mezi sousedy a následně je každý směrovač aktualizuje podle nových informací. Na obr. 5.3 je naznačen princip činnosti algoritmu DVA. Levý sloupec směrovací tabulky je cíl, prostřední cena (vzdálenost) a v pravém je směr, kam se paket odešle. Na počátku znají směrovače jen cestu ke svým bezprostředním sousedům. Řádky s otazníky ve skutečnosti neexistují – směrovač o uzlech vůbec neví. V prvním kroku směrovače předají obsah své tabulky všem svým bezprostředním sousedům. Směrovací


76

tabulky se postupně naplňují. Když směrovač doplňuje řádky do své tabulky, tak se prostřední sloupec (vzdálenost) zvýší o „délku“ linky, přes kterou informace přišla. Směrovače neznají celou strukturu sítě, ale zajímá je jen ta odbočka, která vede k cíli a je nejkratší. Nevědí nic o dalších směrovačích na cestě (kromě nejbližšího souseda) a nic o sítích, jimiž cesta k cíli vede. Protokoly založené na tomto směrovacím algoritmu jsou velmi náchylné na vznik směrovacích smyček, tj. zacyklení uživatelských paketů při použití nesprávné cesty. Vzhledem k dlouhé době, než se směrovače sjednotí ve své informovanosti o dostupnosti sítě (sítí), se může stát, že se směrovače se starší informací snaží o existenci cesty přesvědčit ty, které „vědí“ o nedostupnosti sítě. Známkou postupného předávání chybných informací je neustálé zvyšování metriky dané cesty (count to infinity). Na obr. 5.4 je příklad takové situace. Uzel B informuje uzel C, že od něj vede cesta do A s metrikou 1. Na základě této informace je uzel C schopen odesílat pakety do uzlu A s metrikou 2 (=1+1). Dojde-li k poruše linky mezi A a B, tak uzel B dostává informaci od uzlu C, že má spojení na A s metrikou 2. Za normálních okolností by uzel B tuto informaci ignoroval, protože má spojení do A s „lepší“ metrikou 1. Nyní ale tuto informaci použije pro svou tabulku, ve které se objeví, že do A vede cesta přes C s metrikou 3. Tabulku odešle do uzlu C, který opět zvýší metriku. Celý proces se periodicky opakuje.

A 1

B

A1A A3C

1

C

A2B A4B

Obr. 5.4:

• •

•

• •

Počítání do nekonečna

Pro překonání těchto problémů byly do DVA zabudovány další pomocné mechanismy: Stanovení limitu délky cesty (nejčastěji 15 skoků). Rozložený horizont (split horizon) - základní myšlenka je jednoduchá: není třeba informovat sousední směrovač o cestách, které vedou přes něj samotný a o nichž nás informoval sám, proto se ve skutečnosti neposílají celé směrovací tabulky, ale jen jejich část omezená právě o tyto cesty; „Otrávená“ zpětná informace (poison reverse) - při detekci pomalu se zvyšující metriky cesty do některé cílové sítě se tato síť prohlásí za nedostupnou, neboť vzniká silné podezření na rozsáhlé zacyklení směrovacích informací; zatímco rozložený horizont ošetřuje zacyklení směrovacích informací mezi sousedy, mechanizmus otrávené zpětné informace zabezpečuje směrování proti rozsáhlým smyčkám ve výměně zastaralých a nesprávných směrovacích informací; Spouštěná aktualizace (trigger update) - na základě detekce změny v topologii sítě se ihned tato dílčí informace posílá dalším směrovačům bez čekání na další periodickou výměnu směrovacích tabulek; Zadržovací časovač (hold-down timer) - jakmile směrovač obdrží informaci o nedostupnosti některé sítě, pak po dobu stanovenou časovačem (obvykle třikrát delší, než je periodicita výměny směrovacích tabulek) ignoruje většinu (nepravdivých) informací o možné cestě k této síti; jak za přijatelnou informaci považuje tu, kterou


77

mu stejný soused, jenž byl zdrojem informace o nedostupnosti sítě, sděluje návrat cesty do původního stavu. Směrovací protokoly založené na algoritmu vektorů vzdáleností patří k jednodušším, ale stále používaným protokolům v nepříliš komplikovaných topologiích. Patří mezi ně především protokol RIP. Link State Algorithm Algoritmus stavu spojů byl použit pro směrování později než algoritmus vektorů vzdáleností, aby lépe vyhověl jednomu ze základních požadavků na spolehlivé směrování: rychlé konvergenci. Konvergence je doba, po kterou se směrovače po změně v síti o této změně vzájemně informují a přepočítávají svoje směrovací tabulky, než se ve svém rozhodnutí všichni ustálí. Rychlá konvergence je u algoritmu stavu spojů zajištěna okamžitým vysláním informace o jakékoli změně v síti a jejím rychlým doručením všem směrovačům. Každý směrovač musí vědět o všech existujících směrovačích v síti a současně jim musí dát vědět sám o sobě. Tato informace o všech rozhraních, tedy o stavu spojů vycházejících ze směrovače, se vydá prostřednictvím paketu LSP (Link State Packet). Směrovač si nejprve na základě všech obdržených informací vybuduje celkový pohled na síť, tj. její mapu (topologickou databázi). Pak může spustit výpočet nejkratší cesty do každé dostupné sítě, takže se vidí jako kořen stromu představujícího strukturu sítě. K výpočtu se využívá modifikovaný Dijkstrův algoritmus SPF (Shortest Path First), který se pak provádí při každé změně topologie sítě. Výsledek výpočtu je podklad pro směrovací tabulku, obsahující nejkratší cesty ke všem dostupným síťovým uzlům. Na obr. 5.5 je graf reprezentující síť, který si uzel v1 sestavil na základě příjmu LSP. Strom nejkratších cest (označen šedou barvou) byl stanoven algoritmem SPF.

Obr. 5.5:

Strom nejkratších cest [2]

I když protokoly LSA nejsou tak náchylné ke vzniku směrovacích smyček, přesto mohou nastat problémy v synchronizaci směrovacích informací. Každý paket LSP proto obsahuje údaj o čase jeho vyslání, aby bylo zřejmé, která informace je nejčerstvější. Kromě toho podporují tyto pakety rovněž autentizaci, aby se vyloučilo záměrné narušení směrovacích informací. Na bázi LSA pracuje např. protokol Open Shortest Path First (OSPF) pro IP.


78 5.2.4

Hierarchické směrování

Pro velmi rozsáhlé sítě je výměna aktualizačních informací neúnosná, nehledě na rozsah směrovacích tabulek, které vyžadují velmi rozsáhle operační paměti směrovačů. Řešením tohoto problému může být použití hierarchického (doménového) adresování. Myšlenka hierarchického adresování vychází z principů známých z telefonního systému. Tam např. platí, že v telefonním čísle určuje několik prvních číslic oblast, zbývající číslice pak účastnický přístroj v dané oblasti. Kód oblasti slouží pro směrování mezi oblastmi, kód účastníka pro směrování uvnitř oblasti. Hierarchické adresování ilustruje obr. 5.6. V síti jsou zavedeny 4 adresovací domény, sítové adresy jsou 4-ciferné. Prvé dvě cifry určují doménu, zbývající dvě cifry pak uzel v doméně.

Obr. 5.6:

Doménové adresování [7]

Možnou formu směrovací tabulky v uzlu S2 ilustruje obr. 5.6. I když v síti existuje 9 adresovatelných míst, v tabulce je pouze 5 řádků. Pro směrování do domén se používá řádek domény, pro směrování v rámci domény se používá řádek adresovatelného místo v doméně. Přínosem hierarchického adresování je snížení paměťové náročnosti implementace směrovacích tabulek. Tím se sníží i režie jejich prohlížení při vytváření virtuálního kanálu nebo při směrování datagramu. Stejný princip směrování je využit v rámci směrování v Internetu. Hierarchie může být vícestupňová. Hierarchické adresování patří svým charakterem do statických metod.


79

5.3 Protokol IP Data jsou od odesílatele k příjemci dopravována (směrována) přes směrovače (router). Na cestě od odesílatele k příjemci se může vyskytnout cela řada směrovačů. Každý směrovač řeší samostatně směrování k následujícímu směrovači. Data jsou tak předávána od směrovače ke směrovači. Z angličtiny se počeštil v tomto kontextu termín následující hop (next hop), jako následující uzel kam se data předávají. Hopem se rozumí buď následující směrovač nebo cílový stroj. IP-protokol je protokol, umožňující spojit jednotlivé lokální sítě do celosvětového Internetu. Od protokolu IP dostal také Internet své jméno. Zkratka IP totiž znamená InterNet Protocol, tj. protokol spojující jednotlivé sítě. Později se místo InterNet začalo psát Internet. • • • •

IP-protokol je tvořen několika dílčími protokoly: Vlastním protokolem IP. Služebním protokolem ICMP sloužícím zejména k signalizaci mimořádných stavů. Služebním protokolem IGMP sloužícím pro dopravu adresných oběžníků. Služebními protokoly ARP a RARP, které jsou často vyčleňovány jako samostatné, na IP nezávislé protokoly, protože jejich rámce nejsou předcházeny IP-záhlavím.

V IP-protokolu má každé síťové rozhraní alespoň jednu IP-adresu, která je v případě IPprotokolu verze 4 čtyřbajtová, a v případě IP-protokolu verze 6 šestnáctibajtová. Základním stavebním prvkem WAN je směrovač (anglicky router), kterým se vzájemně propojují jednotlivé LAN do rozsáhlé sítě. Jako směrovač může sloužit běžný počítač s více síťovými rozhraními a běžným operačním systémem nebo specializovaný přístroj. Schopnost předávat datové pakety mezi síťovými rozhraními směrovače se nazývá jako předávání (forwarding). 5.3.1.1 IP datagram

Obr. 5.7:

IP datagram [3]

Na obr. 5.7 je zobrazen IP datagram: Verze (version) U protokolu verze 4 je rovna hodnotě 4.


80

Délka záhlaví (header length) obsahuje délku záhlaví IP-datagramu dělenou čtyřmi. V případě, že by záhlaví nevyšlo na násobek čtyř, pak se na násobek čtyř doplní nevýznamnou výplní. Maximální délka záhlaví IP-datagramu je tedy 15x4=60B. Jelikož po vinné položky mají 20 B, tak na volitelné položky zbývá maximálně 40 B. Typ služby (type of service – TOS) slouží pro specifikaci kvality přenosu IP datagramu. Většinou ji směrovače ignorují. Celková délka IP-datagramu (total length) obsahuje celkovou délku IP-datagramu v bajtech. Jelikož je tato položka pouze dvojbajtová, tak maximální délka IP-datagramu je 65535 bajtů. Identifikace IP-datagramu (identification) obsahuje identifikaci IP-datagramu, kterou do IP-datagramu vkládá operační systém odesílatele. Tato položka se společně s příznaky (flags) a posunutí fragmentu (fragment offset) využívá mechanismem fragmentace datagramu. Příznaky

DF – Do not fragment - zakázaná fragmentce MF – More fragments - datagram není posledním fragmentem

Doba života datagramu (time to live – TTL) slouží k zamezení nekonečného toulání IPdatagramu Internetem. Každý směrovač kladnou položku TTL snižuje alespoň o jedničku. Není-li už možné hodnotu snížit, IP-datagram se zahazuje a odesílateli IP-datagramu je tato situace signalizována protokolem ICMP. Protokol vyšší vrstvy (protocol) obsahuje číselnou identifikaci protokolu vyšší vrstvy, který využívá IP-datagram ke svému transportu (např. 1-ICMP, 6-TCP, 17-UDP,...). Kontrolní součet z IP-záhlaví (header checksum) obsahuje kontrolní součet, avšak pouze ze záhlaví IP-datagramu a nikoliv z datagramu celého. Problém s kontrolním součtem spočívá v tom, že když směrovač změní nějakou položku v záhlaví IPdatagramu (např. TTL změnit musí), tak musí změnit i hodnotu kontrolního součtu, což vyžaduje jistou režii směrovače. Volitelné položky jsou využívány ojediněle a zpravidla směrovače bývají nakonfigurovány tak, aby IP datagramy s použitými volitelnými položkami byly zahozeny. 5.3.1.2 Fragmentace IP-datagramy jsou baleny do linkových rámců. Linkové protokoly umožňují přenášet ve svých datových rámcích data pouze do určité maximální velikosti. Tato maximální velikost dat, která lze vložit do jednoho linkového rámce se označuje MTU (Maximum Transfer Unit). Když IP-datagram dorazí na směrovač z něhož směrem k příjemci vede linka, která má menší MTU než je velikost datagramu. Pokud má datagram nastaven příznak DF (nefragmentovat), tak jej směrovač zahodí a odesílatele informuje zprávou ICMP. Pokud je fragmentace povolena, tak pak směrovač dělí delší IP-datagramy na fragmenty, jejichž celková délka je menší nebo rovná MTU následující linky. Každý IP-datagram má ve svém záhlaví svou identifikaci, kterou dědí i jeho fragmenty. Díky identifikaci příjemce pozná, ze kterých fragmentů má datagram složit. Nikdo jiný než příjemce není oprávněn z fragmentů skládat původní datagram, tj. ani např. směrovač ze kterého vede linka s takovým MTU, do kterého by se celý datagram již vešel. Důvod je prostý, Internet negarantuje, že jednotlivé fragmenty půjdou stejnou cestou (ani negarantuje pořadí v jakém dojdou). Takže směrovač, který by se pokoušel datagram sestavit by mohl být na závadu spojení, protože fragmentů, které by šly jinou cestou by se nikdy nedočkal.


81

Obr. 5.8:

Fragmentace IP datagramů [1]

5.3.1.3 Protokol ICMP Protokol ICMP je služební protokol, který je součástí IP-protokolu. Protokol ICMP slouží k signalizaci mimořádných událostí v sítích postavených na IP-protokolu. Protokol ICMP svoje datové pakety balí do IP-protokolu, tj. pokud budeme prohlížet přenášené datagramy, pak v nich najdeme za linkovým záhlavím záhlaví IP-protokolu následované záhlavím ICMP paketu. Protokolem ICMP je možné signalizovat nejrůznější situace, skutečnost je však taková, že konkrétní implementace TCP/IP podporují vždy jen jistou část těchto signalizací a navíc z bezpečnostních důvodů mohou být na směrovačích mnohé ICMP signalizace zahazovány. Záhlaví ICMP-paketu je vždy osm bajtů dlouhé. První čtyři bajty jsou vždy stejné a obsah zbylých čtyř závisí na typu ICMP-paketu. První čtyři bajty záhlaví obsahují vždy typ zprávy, kód zprávy a šestnáctibitový kontrolní součet. Formát zprávy závisí na hodnotě pole Typ. Pole Typ je hrubým dělení ICMP-paketů. Pole Kód pak specifikuje konkrétní problém (jemné dělení), který je signalizován ICMP-protokolem.

Obr. 5.9:

ICMP paket [3]

Některé typy zpráv • Echo - je jednoduchý nástroj protokolu ICMP, kterým můžeme testovat dosažitelnost jednotlivých uzlů v Internetu. Žadatel vysílá ICMP-paket „Žádost o echo“ a cílový uzel je povinen odpovědět ICMP-paketem „Echo“. K vysílání paketů slouží program ping dostupný ve všech OS • Nedoručitelný IP-datagram - Nemůže-li být IP-datagram předán dále směrem k adresátovi, pak je zahozen a odesílatel je protokolem ICMP o tom uvědomen zprávou „Nedoručitelný IP-datagram“. • Sniž rychlost odesílání - Jestliže je síť mezi odesílatelem a příjemcem v některém místě přetížena, pak směrovač, který není schopen předávat dále všechny IPdatagramy signalizuje odesílateli Sniž rychlost odesílání. Odesílatel pak v případě, že


82

•

používá protokol TCP snižuje rychlost odesílání TCP segmentů. V případě protokolu UDP se zprávy ignorují. Čas vypršel (time exceeded) - Tento typ zahrnuje dva velmi odlišné případy. Pro kód=0 signalizuje, že položka TTL by byla na směrovači snížena na nulu, tj. že je podezření, že IP-datagram v Internetu zabloudil, proto bude zlikvidován. Pro kód=1 signalizuje, že počítač adresáta není schopen v daném čase sestavit z fragmentů celý IP-datagram.

Vyčerpávající popis je možné nalézt v [3]. 5.3.1.4 Protokol ARP a RARP Chce-li stanice na lokální síti komunikovat protokolem IP s jinou stanicí na téže síti, pak ji v protokolu IP adresuje čtyřbajtovou IP-adresou. IP-datagram musí být zabalen do linkového rámce – např. do ethernetového rámce. K tomu je potřeba linkovou (6B) adresu příjemce. Protokol ARP (Address Resolution Protocol) řeší vazbu mezi linkovou a síťovou adresou. Protokol ARP řeší problém zjištění linkové adresy stanice ze znalosti její IP-adresy. Řešení je jednoduché, do LAN se vyšle linkový oběžník (linková adresa FF:FF:FF:FF:FF:FF) s žádostí, aby se stanice s danou IP adresou „ohlásila“. Stanice IP2 takovou žádost uslyší a odpoví. V odpovědi uvede svou linkovou adresu HW2. ARP-paket je balen přímo do Ethernetu, tj. nepředchází mu žádné IP-záhlaví. Protokol ARP je vlastně samostatný, na IP nezávislý protokol. Proto jej mohou používat i jiné protokoly, které s protokoly TCP/IP nemají nic společného.

Obr. 5.10: Paket protokolu ARP [3] Pole typ linkového protokolu specifikuje linkový protokol používaný na LAN. Linkovému protokolu Ethernet II je vyhrazeno číslo 1. Seznam přidělených čísel je uveřejněn na http://www.iana.org. Typ síťového protokolu specifikuje typ síťového protokolu, používají se stejná čísla jako v protokolu Ethernet II, tj. IP-protokol má přiděleno číslo 80016. Pole HS určuje délku linkové adresy a pole PS délku síťové adresy. Standardně je tedy HS=6 a PS=4. Pole operace určuje o jakou operaci jde. Žádost (ARP request) má hodnotu 1 a odpověď (ARP reply) má hodnotu 2. Toto pole je definováno rovněž pro reverzní překlad (protokol RARP), kdy RARP žádost používá hodnotu 3 a RARP odpověď hodnotu 4. Pak již následuje linková adresa odesílatele, IP-adresa odesílatele, linková adresa příjemce (v dotazu vy plněna nulami) a IP-adresa příjemce. Odpověď je uložena do cache (ARP cache). Je možné ji vypsat příkazem arp -a Nejčastěji mají položky v cache dobu života 2 minuty, pokud nebyly podruhé použity. Při každém použití se doba prodlužuje o 2 min. Protokolem ARP je také možné odeslat žádost s vyplněnou IP-adresou odesílatele i příjemce a také s oběma vyplněnými linkovými adresami. Takovou žádost slouží k otestování, zdali neexistuje na lokální síti stanice se stejnou IP adresou. V případě, že se obdrží odpověď,


83

tak se uživateli signalizuje zpráva „Duplicate IP address sent from Ethernet address xx:xx:xx:xx:xx:xx”. To pochopitelně signalizuje chybu v konfiguraci jedné ze stanic používajících tuto adresu.

5.4 IP adresa Protokol IP verze 4 používá IP-adresu o délce čtyři bajty. IP-adresa adresuje jednoznačně síťové rozhraní systému. Pokud má systém více síťových rozhraní, pak každé rozhraní má svou IP adresu. Je možná i opačná varianta, kdy na jedné síťové kartě (fyzicky jednom síťovém rozhraní) podporujeme několik IP-adres. IP-adresa je tvořena čtyřmi bajty. IP-adresa se zapisuje „tečkovou“ notací, kde jednotlivé bajty se mezi sebou oddělují tečkou. Usnadňuje se tím zápis, jinak tečky nic neznamenají. IP-adresa se skládá ze dvou částí: adresy (lokální) sítě a adresy počítače v (lokální) síti.

Obr. 5.11: Struktura IP adresy Počet možných IP adres rozhraní v síti je vždy 2n-2, kde n je počet bitů tvořících adresu počítače (jsou vyloučeny samé nuly a samé jedničky v adrese počítače). 5.4.1

Původní varianta

Až do roku 1993 byla hranice mezi první a druhou částí dána pevně. Adresy byly rozdělené do pěti tříd (A - E). Adresy se organizacím přidělovaly po třídách (A – C). Třída A B C

1. bajt IP-adresy 0sssssss 1-12710 10ssssss 128-19110 110sssss 192-22310 1110mmmm 224-23910 >23910

D E

• • • •

2. bajt IP-adresy

3. bajt IP-adresy

4. bajt IP-adresy

adresa počítače ssssssss

adresa počítače

ssssssss

ssssssss

mmmmmmmm

adresa počítače

mmmmmmmm mmmmmmmm

Třída A: celkem 126 sítí (0 a 127 mají zvláštní význam). V každé síti je 224-2 adres pro počítače. Třída B: celkem 214 sítí a v každé síti 216-2 počítačů. Třída C: 222 sítí a v každé síti 28-2 počítačů. Třída D: nejvyšší čtyři bity prvního bajtu mají hodnotu 11102. Zbytek IP-adresy se pak už nedělí na adresu sítě a adresu počítače. Zbytek IP-adresy tvoří adresný oběžník (multicast).


84 •

Třída E je rezerva Některé adresy mají speciální význam:

Typ adresy 0.0.0.0 00…0.počítač síť.00…0 síť.11...1 (samé jedničky na místě adresy počítače) 11...1 (samé jedničky, tj. desítkově 255.255.255.255) 127.cokoliv

Význam Tento počítač na této síti. Počítač na této síti Adresa sítě jako takové Všeobecný oběžník (broadcast) zasílaný do sítě síť – možno poslat i na vzdálenou síť Všeobecný oběžník na lokální síti (limited broadcast) – směrovače jej nepředávají dále Programová smyčka (loopback) – nikdy neopouští počítač, zpravidla se používá adresa 127.0.0.1

Každé síťové rozhraní má alespoň jednu jednoznačnou adresu (unicast), kromě toho celý systém má jednu adresu programové smyčky 127.0.0.1. Počet adres v síti třídy A i B je velmi vysoký na to, počítače mohly tvořit jednu LAN. Proto byla zavedena možnost v rámci organizací síť dále rozdělit na tzv. podsítě. Pro určení hranice uvnitř adresy se musí použít maska. Síťová maska určuje, které bity v IP-adrese tvoří adresu sítě. Síťová maska je opět čtyřbajtové číslo. Toto číslo vyjádřené v dvojkové soustavě má v bitech určujících adresu sítě jedničky a v ostatních bitech nuly.

Obr. 5.12: IP adresa a maska [3] Např. IP = 147.229.150.86, MASKA = 255.255.255.0 adresa sítě je 147.229.150.0, adresa rozhraní je 86 5.4.2

Beztřídní adresování

Používání tříd vedlo na plýtvání adresami. Proto v roce 1993 vyšly normy RFC-1517 až 1520, kde se přestalo na sítě hledět přes třídy, ale výhradně přes síťové masky. Příslušné směrovací mechanismy se pak nazývají CIDR (Classless InterDomain Routing). Síťová maska je standardně tvořena zleva souvislým blokem jedniček (je možný případ tzv. nespojité masky tvořené více bloky, ale spíše jen jako teoretická možnost). Stačí proto uvádět jen počet bitů. Síťové části adresy říkáme prefix. Počet jedniček v masce je pak délka prefixu.


85

síť 147.229.150.0 s maskou 255.255.255.0 se napíše jako 147.229.150.0/24 5.4.2.1 Agregace adres Jedním z problému třídních adres byla rostoucí zátěž směrovačů. Každé síti odpovídá jeden řádek směrovací tabulky. Např. pro všechny (bývalé) třídy C dostáváme teoreticky až 222 řádků. Beztřídní adresování umožňuje posouvat hranici uvnitř IP adresy. Na obr. 5.13 je příklad využití tzv. agregace adres. Bez agregace by ve směrovací tabulce směrovače muselo být 8 řádků pro Organizaci 0 – Organizaci 7. Každá organizace má přidělenou síť s délkou prefixu 23. Na adresu počítačů tak zbývá 9 bitů, tj. 512-2 pozic. Organization 0

200.23.16.0/23 Organization 1

200.23.18.0/23

Organization 2

200.23.20.0/23

Organization 7

. . .

. . .

ISP 1

“Send me anything with addresses beginning 200.23.16.0/20”

router

200.23.30.0/23 ISP 2

“Send me anything with addresses beginning 199.31.0.0/16”

Obr. 5.13: Agregace adres [1] Rozepíšeme-li si třetí byte adresy sítí binárně org 0 org 1

200.23.0001 0000.0 200.23.0001 0010.0

org 7

200.23.0001 1110.0

tak vidíme, že označené bity vyčerpaly všechny možné kombinace. Do sítě ISP1 musí být tedy přeposílány všechny pakety bez ohledu na stav těchto tří bitů. Záznam v tabulce může být jen jeden: 200.23.16.0/20 , tj. hranice se posune o tři bity doleva (dostaneme tzv. supersíť) Pokud by organizace neměly přidělené adresy tvořící jeden blok, tak uvedená agregace by nebyla možná. Možnost agregace tedy závisí na vhodném přidělování IP adres. 5.4.2.2 Maska variabilní délky Přidělením adresy sítě je organizaci přidělen rozsah využitelných IP adres. Z praktických důvodů je často nutné přidělenou síť rozdělit na menší podsítě, tj. hranici uvnitř adresy posunout o jeden nebo více bitů vpravo. Nově vzniklé podsítě mohou mít stejnou nebo rozdílnou masku. Použití rozdílné masky se označuje jako VLSM (Variable Length Subnetwork Mask) Případ stejné masky - rozdělení na 4 podsítě (posun o 2 bity): 194.149.115.0/24


86 poslední byte 00 00 00002 = .0 * 01 00 00002 = .64 10 00 00002 = .128 11 00 00002 = .192 *

*) První a poslední podsíť je nejednoznačná. Samé nuly označují adresu podsítě a samé jedničky oběžník na podsíti. Použití těchto adres je možné (RFC 1878), avšak ve spojení s některými směrovači může přinést komplikace.

Dostaneme tak 4 podsítě 194.149.115.0/26 194.149.115.64/26 194.149.115.128/26 194.149.115.192/26 Na adresu počítače zbylo 6 bitů. V každé podsíti může být 26-2 = 62 IP adres rozhraní, tj. 194.149.115.1 až 194.149.115.62 194.149.115.65 až 194.149.115.126 194.149.115.129 až 194.149.115.190 194.149.115.193 až 194.149.115.254 Při použití nestejné masky je možné některou podsíť dále rozdělit. Rozdělíme např. druhou podsíť na další čtyři: 00 00 00002 = .0 01 00 00002 = .64 + 0 = .64/28 01 01 00002 = .64 + 16 = .80/28 01 10 00002 = .64 +32 = .96/28 01 11 00002 = .64 + 48 = .112/28 10 00 00002 = .128 11 00 00002 = .192 Podsítě 194.149.115.0/26 194.149.115.128/26 194.149.115.192/26 jsou stejné jako v případě konstantní masky. Menší podsítě mají délku prefixu 28 bitů. Na adresy rozhraní zbývají 4 bity, tj. dostáváme 24-2 = 14 adres. Rozsahy IP adres tak budou: 194.149.115.65 až 194.149.115.78 194.149.115.81 až 194.149.115.94 194.149.115.97 až 194.149.115.110 194.149.115.113 až 194.149.115.126 5.4.3

Privátní IP adresy Pro uzavřené podnikové sítě jsou podle RFC1918 vyhrazené adresy sítí

Počítačové a komunikační sítě 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16

87

10.0.0.0 až 10.255.255.255 172.16.0.0 až 172.31.255.255 192.168.0.0 až 192.168.255.255

Použití těchto adres navíc zvyšuje bezpečnost, protože v Internetu jsou nepoužitelné (nesměrují se). O přidělení adres v těchto rozsazích není třeba nikoho žádat.

5.4.4

Překlad adres (NAT/PAT)

NAT je v současnosti jedním z nejčastěji používaných mechanismů sloužících ke zpřístupnění internetového připojení v lokálních sítích. NAT je mechanismus, který se spouští na hraničních směrovačích umístěných např. na hranici mezi firmou a Internetem. NAT umožňuje v procházejících IP datagramech překládat IP-adresy na jiné IP-adresy. Např. IPadresy vnitřní firemní sítě na oficiální adresy Internetu a naopak. Využití tohoto řešení má následující výhody: • NAT šetří adresní prostor – mnoho počítačů může mít jednu veřejnou IP adresu, na které je bude vidět; • Při využití NAT ve firmě je velmi jednoduché změnit poskytovatele Internetu; • NAT „automaticky” vytváří svého druhu firewall, který neumožní nekontrolované propojování počítačů z internetu s těmi v lokální síti; Bohužel však některé protokoly v prostředí NAT hůře pracují (např. ftp, ipsec).

Obr. 5.14: Jednoduchý NAT [6] 5.4.4.1 Jednoduchý NAT Jednoduchý NAT je určen pro navazování relace z vnitřní sítě do Internetu. Směrovač má k dispozici blok veřejných adres přidělený poskytovatelem Internetu. V odchozích paketech pak směrovač přepisuje adresy vnitřní sítě na adresy z uvedeného bloku. U příchozích paketů pak zase adresy přepisuje opačně.

88


5.4.4.2 Rozšířený NAT (NAPT, PAT) Rozšířený NAT neboli NetworkAddress and Port Translation (NAPT nebo PAT) umožňuje šetřit přidělené IP adresy. Umožňuje totiž, aby více IP adresám ve vnitřní síti byla přidělena jedna společná IP adresa z bloku adres od poskytovatele Internetu. NAPT používá položky tabulky NAT rozšířené o čísla portů a typ protokolu. Na obr. 5.15 je znázorněn příklad takové komunikace. Počítač 10.0.0.3 chce z portu 1024 navázat spojení protokolem TCP na server 194.149.105.18. Pomocí rozšířené tabulky NAT je IP adresa odesilatele přeložena z 10.0.0.3 na 195.47.40.13 a port je ponechán 1024. Během tohoto spojení chce počítač 10.0.0.4 z portu 1024 navázat spojení se serverem 194.149.105.86. IP adresa 10.0.0.4 je přeložena rovněž na adresu 195.47.40.13, ale port 1024 je již použit, takže je přeložen na 1025. Tabulka na obr. 5.15 znázorňuje zmíněnou situaci, kdy jsou různí klienti vnitřní sítě překládáni na stejnou IP-adresu, přesto je spojení určeno jednoznačně - obě spojení se liší číslem portu klienta.

Obr. 5.15: Rozšířený NAT [6] 5.4.4.3 Dvojitý NAT Dvojitý NAT slouží k řešení kolizních IP-adres, tj. situace, kdy ve vnitřní síti používáme IP-adresy, které jsou v Internetu přiděleny někomu jinému. V tomto případě již obecně nelze ve vnitřní síti přepravovat libovolné IP-adresy Internetu. Někdy se tento typ překladu označuje INAT podle Illegal NAT. Ve vnitřní síti používáme interval IP-adres 194.149.10.0/24 přidělený jiné firmě. Shodou okolností chceme komunikovat s webovým serverem www.firma.cz, který má IPadresu 194.149.10.18, která je v kolizi s IP-adresami vnitřní sítě. Prvním krokem je vždy překlad jména (www.firma.cz) na IP-adresu pomocí DNS serveru. Klient vygeneruje příslušný DNS dotaz. IP-adresa odesilatele (194.149.10.17) musí být v dotazu přeložena směrovačem na adresu 195.47.40.13, která je z bloku oficiálně přidělených adres poskytovatelem Internetu. Nyní DNS dotaz dorazí na DNS server, který vrací odpověď. V DNS odpovědi je ale uvedena IP-adresa 194.149.10.18, která je v kolizi s IP-adresami vnitřní sítě. Proto směrovač vezme z bloku nesměrovatelných adres adresu 10.0.0.1, na kterou přeloží IP-adresu serveru www.firma.cz. Nyní již může klient začít navazovat spojení se serverem www.firma.cz. Ten má z pohledu klienta adresu 10.0.0.1, která je směrovačem přeložena na oficiální adresu 194.149.10.18.


89

Obr. 5.16: Dvojitý NAT [6]

5.5 Směrování v IP sítích 5.5.1

Směrovací tabulka

Modelem sítě na bázi protokolu IP (tedy Internetu) je soustava sítí, které jsou navzájem spojené pomocí směrovačů. Každá síť se může dělit na podsítě. Na nejnižší úrovni uvidíme strukturu podle obr. 5.17. Síť je tvořena soustavou počítačů propojených na linkové vrstvě (tedy bez účasti směrovače, např. pomocí ethernetového přepínače). Každé rozhraní včetně rozhraní směrovače má svoji IP adresu se stejnou síťovou částí. Jednotlivá rozhraní směrovače musí patřit do jiných sítí. IP (sub)net

IP (sub)net

gateway

IP (sub)net

router Obr. 5.17: Soustava spojených sítí

Při komunikaci rozeznáváme dva způsoby doručení paketu. Shoduje-li se síťová část adresy příjemce a odesílatele, tak se provede tzv. přímé doručení. Odesílatel protokolem ARP zjistí linkovou adresu příjemce, IP paket zabalí do linkového rámce a odešle příjemci. V případě, že se síťové části adresy neshodují, tak se provede tzv. nepřímé doručení. Přísně vzato, odesílatel nezná strukturu adresy příjemce. Porovnání provede podle svojí síťové masky. Odesílatel zabalí paket do linkového rámce a odešle do tzv. brány (gateway), tj. do směrovače. Adresa příjemce v linkovém rámci je adresa směrovače. Adresa příjemce v IP paketu je IP adresa konečného příjemce (teď neuvažujeme použití NATu). Směrovač je zařízení, které předává IP datagramy z jednoho svého rozhraní do jiného rozhraní. Činnost směrovače (předávání – forwarding) je řízena směrovací tabulkou. Tabulka


90

se obvykle vytváří dynamicky jako výsledek činnosti směrovacích algoritmů. Může však být také zkonfigurována staticky. if2 if1 přepínač směrovač

if0

10.5.2.1

komu: 10.5.2.1

10.1.2.0/24

Obr. 5.18: K popisu činnosti směrovače Na obrázku směrovač obdržel IP datagram adresovaný stanici 10.5.2.1 a musí rozhodnou, do kterého rozhraní jej musí přeposlat. Rozhraní jsou označena jako if0 – if2. Směrovač má tabulku Síť 192.168.1.0 10.1.2.0 10.5.1.0 10.5.0.0 … 0.0.0.0

Maska 255.255.255.0 255.255.255.0 255.255.255.0 255.255.0.0

Next Hop 192.168.254.5 Lokální rozhraní 10.10.10.2 10.5.5.5

Síťové rozhraní if1 if0 if2 if1

Metrika

0.0.0.0

10.10.10.2

if2

1

4 0 3 2

Směrovací tabulka má v prvním sloupci IP adresu cílové sítě. Představme si pro jednoduchost, že směrovací tabulka je podle prvního sloupce sestupně tříděna podle délky prefixu. To umožní snadno aplikovat základní pravidlo směrování: Více specifická adresa cílové sítě má přednost před méně specifickou. Více specifickou adresou sítě se rozumí adresa, která má v síťové masce více jedniček. V případě, že by se ve směrovací tabulce našly dvě či více cest k cíli, pak se zvolí více specifická cesta. V případě, že se najdou dvě stejně specifické cesty, pak se zvolí cesta s nejnižší metrikou (cenou). V případě, že jsou řádky směrovací tabulky sestupně tříděny, pak stačí směrovací tabulku procházet od shora dolů. Na každém řádku se vezme síťová maska, kterou se bit po bitu vynásobí IP adresa příjemce. Výsledek se porovná s prvním sloupcem. Pokud se výsledek nerovná IP adrese sítě v prvním sloupci, pak se přejde na zpracování následujícího řádku. Pokud se výsledek shoduje s IP adresou v prvním sloupci, pak se ještě otestuje následující řádek, zdali ve směrovací tabulce neexistuje ještě k cíli jiná cesta, (pak by vstoupila do hry metrika). Sloupec Next hop je IP adresa rozhraní dalšího směrovače, kam se paket předá. V případě místního doručování se paket doručuje přímo příjemci. Sloupec síťové rozhraní určuje, přes jaké rozhraní se bude paket posílat. Směrovač má tedy najít, kam odeslat IP-datagram o adrese 10.5.2.1. Prochází směrovací tabulku:


91

1. Řádek: 192.168.1.0 | 255.255.255.0 Vynásobením bit po bitu cílové adresy 10.5.2.1 s maskou 255.255.255.0 obdržíme 10.5.2.0, což se nerovná IP adrese sítě v prvním sloupci (ta je 192.168.1.0). Přecházíme na vyhodnocení následujícího řádku. 2. Řádek: 10.1.2.0 | 255.255.255.0 Vynásobením bit po bitu cílové adresy 10.5.2.1 s maskou 255.255.255.0 obdržíme 10.5.2.0, což se nerovná IP-adrese sítě v prvním sloupci (ta je 10.1.2.0). Přecházíme na vyhodnocení následujícího řádku. ......................... 4. Řádek: 10.5.0.0 | 255.255.0.0 Vynásobením bit po bitu cílové adresy 10.5.2.1 s maskou 255.255.0.0 obdržíme 10.5.0.0, což se rovná IP-adrese sítě v prvním sloupci (ta je 10.5.0.0). Budeme proto náš IP datagram vkládat do rozhraní if1 a předávat jej dalšímu směrovači o IP-adrese 10.5.5.5. Pokud by se jednalo např. o Ethernet, pak by bylo třeba zjistit linkovou adresu směrovače o IP adrese 10.5.5.5 protokolem ARP. Jedná se vždy o místní doručování. Poslední řádek obsahující v prvním sloupci 0.0.0.0 s maskou 0.0.0.0 se nazývá default. Tímto implicitním směrem jsou pak odesílány všechny IP datagramy, pro které nevyhovoval žádný jiný řádek směrovací tabulky (řádek vyhovuje každé IP adrese). Implicitní směr ve směrovací tabulce může a nemusí být – závisí to na správci, jak tabulku naplnil. Implicitní směr používají např. organizace pro cestu do Internetu. Internet

dest. network

next hop

192.168.3.0/24

direct

192.168.4.0/24

direct

192.168.5.0/24

direct

0.0.0.0/0

192.168.5.1

192.168.5.1 192.168.5.0/24

192.168.3.0/24 192.168.4.0/24

Obr. 5.19: Implicitní směr Na obr. 5.20 je ukázán princip agregace adres směřující ke zmenšení počtu řádků směrovací tabulky. Výše popsaný princip směrování umožňuje, aby (teoreticky) adresy jednotlivých sítí spolu vůbec nesouvisely. Pak samozřejmě počet řádků směrovací tabulky odpovídá počtu sítí. Při vhodné volbě adres (kap. 5.4.2.1) je možné pomocí agregace snížit počet řádků tabulky. Čím je tabulka rozsáhlejší, tím je náročnější její procházení, tj. roste režie směrování.


92

Obr. 5.20: Agregace adres ve směrovací tabulce Příkaz netstat –r vypisuje obsah směrovací tabulky. Ve Windows je tabulka setříděna vzestupně, takže se musí procházet zdola nahoru. Trochu nezvyklé je, že rozhraní (interface) se jmenují svou IP adresou. V následujícím výpisu směrovací tabulky mělo PC rozhraní o IP adrese 194.149.104.121. IP datagramy adresované adresátovi 194.149.104.121 se mají vkládat do rozhraní 127.0.0.1 - jedná se o adresu lokálního síťového rozhraní. Active Routes: Network Address 0.0.0.0 127.0.0.0 194.149.104.64 194.149.104.121 194.149.104.255 224.0.0.0 255.255.255.255

Netmask 0.0.0.0 255.0.0.0 255.255.255.192 255.255.255.255 255.255.255.255 224.0.0.0 255.255.255.255

Gateway Address 194.149.104.126 127.0.0.1 194.149.104.121 127.0.0.1 194.149.104.121 194.149.104.121 194.149.104.121

Interface Metric 194.149.104.121 1 127.0.0.1 1 194.149.104.121 1 127.0.0.1 1 194.149.104.121 1 194.149.104.121 1 194.149.104.121 1

Síť 224.0.0.0 s maskou 224.0.0.0 označuje všechny adresné oběžníky (včetně rezervy IP adres, tj. IP-adresy tříd D a E). Koncový uzel teoreticky nepotřebuje směrovací tabulku pokud by měl jediné rozhraní.

5.5.2

Struktura sítě

Zatímco subsítě se používají na LAN, tak supersítě se používají pro agregace IP-adres. Agregace IP adres je výhodná pro směrování a pro administrativu při přidělování IP-adres. V současné době je při pohledu z velké vzdálenosti Internet soustavou vzájemně propojených poskytovatelů Internetu. Dva poskytovatelé si mohou vyměňovat IP-datagramy mezi sebou, existují však i tranzitní poskytovatelé, kteří přes sebe IP-datagramy tranzitují.


93

Neříká se, že se Internet dělí na poskytovatele, ale z hlediska dopravy IP datagramů se Internet dělí na autonomní systémy (AS). Každý poskytovatel má pak přidělen jeden nebo více autonomních systémů. Poskytovatelé Internetu jsou správci autonomního systému. Správci AS žádají o intervaly IP adres (viz agregace), které přidělují sobě a svým zákazníkům. Jednotliví poskytovatelé jsou pak i se svými zákazníky součástí konkrétního AS.

Obr. 5.21: Struktura Internetu [3] V rámci AS se požívají vnitřní směrovací protokoly (RIP a OSPF), mezi jednotlivými AS pak vnější protokoly (BGP).

5.5.3

Protokol RIP

RIP patří do kategorie algoritmů typu DV (Distance Vector). Sousední směrovače si vyměňují řádky svých směrovacích tabulek. Pokud je nová cesta z přijaté tabulky kratší než původní, je tato původní cesta nahrazena novou s uvedením odpovídajícího směrovače jako následujícího souseda na cestě do cílové sítě. Stejně tak, pokud je v přijaté tabulce uvedena nějaká cesta, která se v původní směrovací tabulce vůbec nevyskytuje, je do ní nově zařazena. Takže se celé směrovací tabulky pravidelně každých 30s vyměňují výhradně mezi sousedy a následně je každý směrovač aktualizuje podle nových informací. Základní směrovací tabulku (tj. seznam síťových rozhraní směrovače, jejich adresy a masky) nakonfiguruje správce. Konvergence je doba, po kterou se směrovače po změně v síti o této změně vzájemně informují a přepočítávají svoje směrovací tabulky, než se ve svém rozhodnutí všichni ustálí. V případě RIP je konvergence pomalejší. RIP je také náchylný na vznik smyček (tj. paket bloudí stále dokola v síti, než se vyčerpá jeho doba života). Jako metriku (pro porovnání dvou cest) používá RIP počet směrovačů k cíli. Maximální hodnota je 15. Cesta k cíli je vždy přes nejmenší počet směrovačů. RIP je vhodný pro menší homogenní sítě. Dnes se používá verze 2, která podporuje VLSM i autentizaci. Zaslání falešné zprávy RIP do směrovače by ochromilo síť. Zprávy RIP mohou přijímat i stanice jako tzv. pasivní účastníci.


94

Obr. 5.22: Start vytváření směrovacích tabulek protokolem RIP [5]

5.5.4

Protokol OSPF

Protokol OSPF (Open Shortest Path First) patří do kategorie algoritmů LS (Link State). Každý zúčastněný směrovač má k dispozici úplnou informaci o topologii celé sítě, resp. její části. Každý si udržuje vnitřní mapu ve formě grafu, jehož uzly jsou směrovače sítě a jehož hrany reprezentují jejich vzájemné přímé propojení - ohodnocení jednotlivých hran odpovídá metrice, tedy přenosovým vlastnostem příslušného spoje. Místo přenášení celých směrovacích tabulek směrovače v rámci OSPF provádějí následující dvě činnosti: • aktivně testují stav všech sousedních směrovačů periodickou výměnou krátkých zpráv zjišťujících, zda je příslušný soused dostupný • periodicky šíří stavové informace o spojích všem ostatním směrovačům.


95

Obr. 5.23: Vytváření tabulek protokolem OSPF [5] Jednou z největších výhod algoritmu LS je, že výpočet nejkratších cest provádí každý směrovač autonomně a na základě týchž dat jako ostatní (zaručená konvergence odolnost vůči vytváření směrovacích cyklů). Další výhodou je, že protože vlastní zprávy o stavu spojů obsahují pouze informace o přímých sousedech daného směrovače, jejich velikost nezávisí na počtu sítí. Také reakce na změnu topologie sítě je v podstatě okamžitá (limitována pouze rychlostí šíření zpráv). Směrování je založené na jediné bezrozměrové metrice, obecně označované cena. Cena spojů ve složené cestě odpovídá propustnosti spojů, nákladů na spoje apod. Cenu spoje (z pohledu směrovače vlastně rozhraní) stanovuje správce. OSPF vypočítává „nejkratší“ cesty do všech dostupných existujících sítí. Protože je možné přiřadit různou cenu rozhraním sousedních směrovačů připojených k téže síti, nemusí být zvolena stejná cesta v obou směrech. OSPF je ve srovnání s RIP vhodnější pro větší sítě. Na rozdíl od RIP podporuje OSPF rozložení provozu v síti mezi cesty se stejnou celkovou cenou. Používá se jeden ze dvou mechanizmů rozložení provozu: po paketech (pakety jsou cyklicky směrovány po cestách se stejnou cenou), nebo podle cílové adresy (pro každou novou cílovou adresu se přidělí další možná cesta téže hodnoty, tzn. všechny pakety pro danou adresu jdou stejnou cestou). OSPF také podporuje směrování podle typu služeb (pole ToS) IP. Tak pro každý typ služby, tj. zpoždění, propustnost, spolehlivost nebo cena, mohou existovat různé optimální cesty k témuž cíli.

96


5.6 Shrnutí kapitoly 5 Hlavním úkolem protokolu IP síťové vrstvy je doručení datagramů mezi komunikujícími stanicemi. V rámci protokolu IP je prováděno tzv. směrování, tj. nelezení optimální cesty přes jednotlivé uzly Internetu. Zpravidla mezi příjemcem a odesílatelem existuje více různých cest. V měřítku globální sítě je směrování realizováno jako distribuovaný a adaptivní algoritmus, který reaguje na aktuální stav linek, včetně jejich zátěže. Zavedení technologie privátních sítí a adresního překladu (NAT) snížilo poptávku po nových IP adresách. To je důvod, že přechod na nový protokol IPv6 je velmi pozvolný.


97

6 Datový spoj a fyzická vrstva Cíle kapitoly: • Základní typy přenosových médií. • Protokoly linkové vrstvy.

6.1 Základy přenosu dat Uvažujme model přenosové soustavy na obr. 6.1. Úkolem vysílače je převod vstupního digitálního signálu do formy vhodné pro přenos kanálem. V elementárním případě se může jednat o pouhé zesílení (přenos v základním pásmu) nebo naopak velmi složité zpracování (např. u systémů OFDM). Na straně přijímače dochází k opačnému procesu. vstupní data

přenášený signál

vysílač

Obr. 6.1:

přijímaný signál

přenosové méduim

výstupní data

přijímač

Model komunikace

Budeme uvažovat lineární přenosový kanál s těmito parametry: • Útlum je dán zmenšením výkonu signálu. Udává se v dB. Rozeznáváme útlum napětí, proudu a výkonu. Např. útlum výkonu se vypočítá: A = 10 log (Pin / Pout) V tomto případě útlum o 3 dB znamená jeho snížení na polovinu. • Zkreslení (lineární) – změna amplitudy a fáze jednotlivých harmonických složek signálu oproti vstupnímu signálu • Šum – náhodný signál generovaný uvnitř kanálu (bílý šum, tepelný šum, impulsní šum) • Přeslechy – signály generované mimo kanál • Šířka pásma – pásmo, které je schopno médium přenášet (v Hz). Může být výrazně vyšší, než skutečně využívaná šířka pásma během přenosu. Při přenosu rozlišujeme modulační a přenosovou rychlost. Modulační rychlost udává počet změn signálu přenášeného kanálem za jednu sekundu. Udává se v Baudech [Bd]. Přenosová rychlost udává množství informace přenesené za jednu sekundu. Měří se v bitech za sekundu [b/s]. Vztah mezi oběma rychlostmi závisí na počtu stavů V, kterých může signál nabývat C = RBaud log 2 V .

(6.1)

Nyquist dokázal, že jestliže libovolný signál proběhl filtrem fungujícím z hlediska potlačených frekvencí jako dolní propust s šířkou pásma B, lze filtrovaný signál zpětně úplně zrekonstruovat tehdy, když jej budeme vzorkovat 2B krát za sekundu. Rychlejší vzorkování než 2B krát za sekundu nemá smysl, poněvadž složky o vyšších frekvencích, které by takové


98

vzorkování mohlo obnovit, byly odfiltrovány. Jestliže je signál tvořen V diskrétními úrovněmi, Nyquistova věta říká: Cmax = 2 B log 2 V [b/s] . (6.2) Například bezporuchový kanál s šířkou pásma 3kHz nemůže přenášet binární (tj. dvouúrovňové) signály vyšší rychlostí než 6000 b/s. Počet stavů není možné libovolně zvětšovat, protože spolu s užitečným signálem přijímáme i šum a přeslechy. Rozlišení mezi jednotlivými stavy se tak stává obtížnější. Definujeme poměr signál šum S , (6.3) N kde S je výkon signálu a N výkon šumu. Shannon odvodil vztah pro nejvyšší možnou rychlost přenosu dat v kanále s poruchami, jehož šířka pásma je B a jehož poměr signál-šum S/N (Shannonova věta): N dB = 10 log10

S  Cmax = B log 21 +  [b/s]. (6.4)  N Například, kanál se šířkou pásma 3000 Hz a s poměrem signálu k šumu 30dB (typické parametry telefonního systému) nemůže nikdy přenášet rychlostí více než 30000 b/s, bez ohledu na to, kolik by se použilo úrovní signálu. Shannonův výsledek byl odvozen pomocí důkazů teorie informace a má velmi obecnou platnost.

6.2 Přenosová média Média můžeme rozdělit na média vodičového typu a bezdrátová. V případě bezdrátových médií rozlišujeme optický a radiový přenos, i když se liší jen frekvencí nosné. přenosová média vodičového typu

bezdrátová

(guided media)

(wireless)

optická

metalická

„radiová“ (dnes ≈100GHz)

koaxiální kabel (nesymetrický, „coax“)

kroucený pár

optická (IrDA, FSO)

(symetrický, „twist“)

Obr. 6.2:

6.2.1

Dělení přenosových médií

Kroucený dvoudrát

Nejstarším a stále nejrozšířenějším přenosovým prostředím je kroucený dvoudrát (twisted pair). Kroucený dvoudrát tvoří dva izolované měděné vodiče, typicky o průměru od 0,3 do 0,8 mm. Vodiče jsou závitovitě zkrouceny kolem sebe. Kroucením se zmenší


99

elektrická interference mezi dvojicemi vodičů umístěnými blízko sebe (dva paralelní vodiče vytvářejí jednoduchou anténu, kroucený pár ne). Nejrozšířenější aplikací kroucených dvoudrátů je telefonní systém. Téměř všechny telefony jsou spojeny s telefonní ústřednou krouceným dvoudrátem. Kroucené dvoudráty se mohou pokládat na vzdálenosti několika kilometrů bez zesilování signálu. Je-li položeno více kroucených dvoudrátů paralelně na dostatečnou vzdálenost, např. všechny spoje mezi obytným domem a telefonní ústřednou, jsou tyto spoje svázány dohromady a uzavřeny do ochranného obalu kabelu. Kdyby nebyly jednotlivé páry v takovém svazku krouceny, mohly by se vzájemně ovlivňovat, nezamezilo by se přeslechům. Šířka pásma krouceného dvoudrátu závisí na tlouštice vodiče a na vzdálenosti, na kterou se data přenášejí. Při přenosu hlasu na místních smyčkách dochází k zeslabení asi 0,5 až 1 dB/km, proto je 6 km horní mez vzdálenosti mezi zesilovači. Na krátké vzdálenosti lze využít šířku pásma až v jednotkách MHz (systémy xDSL). Telefonní společnosti používají kabely z kroucených dvoudrátů pro spojení telefonních ústředen s účastníky, používají je ale s šířkou pásma 3100 Hz. Kabel typu kroucený dvoudrát nachází také široké využití pro lokální sítě na vzdálenosti do 100 m. Norma EIA-568 definuje kategorie kabelů podle šířky pásma signálu, který je možné přenést. Kabel je tvořen čtyřmi páry. Category 5 Class D

Category 3 Class C Bandwidth

16 MHz

100 MHz

Category 5E 100 MHz

Category 6 Class E

Category 7 Class F

250 MHz

600 MHz

6a – 500MHz

(1000MHz)

Cable Type

UTP

UTP/FTP

UTP/FTP

UTP/FTP

SSTP

Link Cost (Cat 5 =1)

0.7

1

1.2

1.5

2.2

UTP=Unshielded twisted pair FTP=Foil twisted pair (někdy ScTP) SSTP=Shielded screen twisted pair

Obr. 6.3:

Kategorie a provedení kabelů [2]

Pokud je kroucený dvoudrát tvořen pouze dvěma izolovanými vodiči, hovoříme o nestíněném krouceném dvoudrátu, (UTP). Pokud je umístěn do ochranného obalu, který dále redukuje vliv signálových interferencí, hovoříme o stíněném krouceném dvoudrátu, (provedení FTP nebo STP). Kabely CAT6 mají uvnitř plastový profil, který zajišťuje vedení jednotlivých párů pro zlepšení přeslechových parametrů. Třída CAT6e byla nově vytvořena pro 10Gb/s Ethernet. Pro horizontální rozvody se používají kabely s vodiči s plným průřezem (drát), pro pohyblivé přívody pak lanka. Kabely pro pohyblivé přívody mají poněkud horší vlastnosti.


100

Obr. 6.4:

6.2.2

Provedení kabelů CAT5 (prov. UTP), CAT6 (prov. FTP) a CAT7

Koaxiální kabel

Dalším běžně používaným přenosovým prostředím je koaxiální kabel. Širší použití mají dva typy koaxiálních kabelů. 50ohmový kabel se používá pro digitální přenos v základním pásmu frekvencí. 75ohmový kabel se používá pro analogový přenos v přeloženém pásmu. V obou případech je koaxiální kabel tvořen jádrem z tuhého měděného vodiče, které je obaleno izolačním materiálem. Izolátor je uzavřen do válcového vodiče, který má často formu tkané mřížky. Vnější vodič je ukryt do ochranného plastikového obalu. Vnější vodič zabezpečuje, že signál v jádru není prakticky ničím ovlivňován. Útlum vykazují koaxiální kabely relativně malý (3 dB/km). Nevýhodou koaxiálního kabelu je jeho relativně vyšší cena a složitější instalace. V oblasti dálkových spojů byl koaxiální kabel vytlačen kabelem optickým. Dnes se kromě rozvodů kabelové televize používá pro datové přenosy do několika Gb/s na krátké vzdálenosti. 6.2.3

Optické vlákno

Optický přenosový systém má tři složky: přenosové médium, světelný zdroj a detektor. Přenosové médium je velmi tenké skleněné vlákno nebo vlákno z plastu. Světelným zdrojem je buďto LED nebo laserová dioda, oba zdroje po připojení elektrického proudu vysílají světelné impulsy. Informace je přenášena ovlivňováním optického výkonu (nekoherentní komunikace). Data lze přenášet jedním kanálem až do rychlosti ≈10Gb/s (laser). Detektorem je fotodioda která, jakmile na ni dopadne světlo, generuje elektrický impuls. Vedení světla ve vláknu je založeno na totálním odrazu na rozhraní jádra a pláště, které jsou vyrobené z materiálů s rozdílným indexem lomu.


Obr. 6.5:

101

Typický průběh útlumu a konstrukce vlákna [2]

Pro komunikaci se používají tři vlnové délky dané tzv. okny na křivce útlumu 850nm, 1300nm a 1550nm. Rozeznáváme 2 druhy vláken Vícevidové vlákno (gradientní) Jádro má průměr přibližně 50µm nebo 62,5µm, plášť typicky 120µm. Útlum vlákna je řádu 1dB/km při vlnové délce 1300nm. Přenosovou rychlost omezuje disperze (nestejná rychlost šíření jednotlivých složek optického signálu). Ukazuje se, že součin využitelné šířky pásma a délky vedení je víceméně konstantní. Nazývá se modální šířka pásma. Pro gradientní vlákna je typická hodnota 1000MHz.km (na 1300nm). Tento typ vlákna se používá na kratší vzdálenosti (např. do 2km na 125Mb/s). Je ovšem také levnější. Jako zdroj záření lze použít LED i laser. Výběr používaných vlnových délek je omezen vlastnostmi materiálu vlákna. Vlnové délky 850, 1300 a 1550nm odpovídají minimům útlumu v materiálu jádra.

Obr. 6.6:

Typické parametry mnohavidových vláken [8]

Jednovidové vlákno Díky malému průměru jádra (kolem 9µm) se ve vláknu šíří jen jeden vid. Díky tomu a použitím laseru velmi podstatně klesne disperze. Typická hodnota je 100GHz.km. Útlum vlákna je řádu 0,25dB/km (na 1550nm). Tento typ vlákna umožňuje bez opakovače běžně překlenout vzdálenost do 100km. Přenosovou rychlost nelze zvyšovat do nekonečna. Limitujícím faktorem je potřeba několika převodů z elektrické do optické oblasti a naopak. Pro další zvyšování přenosové rychlosti se dnes používá paralelní přenos na více vlnových délkách – tzv. vlnový multiplex. Tak je možné dosáhnout přenosové rychlosti v řádu terabitů za sekundu.


102

6.3 Kódování pro přenos Uvažujme přenosový řetězec z obr. 6.7, kdy je mezi dvěma místy přenášen bitový proud. Data nejdříve procházejí kodérem, který každému bitu nebo skupině přiřadí jistý signálový prvek. Nejjednodušší operací je přiřadit symbolu 1 napětí +V a symbolu 0 napětí 0V. Takový kód (NRZ) je ovšem nevhodný pro přenos, protože jeho stejnosměrná složka závisí na přenášených datech a navíc v případě přenosu dlouhé posloupnosti by na straně přijímače došlo ke ztrátě synchronizace. Používají se proto důmyslnější kódy. Na výstupu kodéru máme signál v základním pásmu. Pokud to kanál dovoluje, tak lze přenášet přímo tento signál. Jinak je nutné pomocí modulace přizpůsobit signál přenosovému pásmu kanálu a provést tak přenos v přeloženém pásmu. Na straně přijímače je proveden opačný postup.

Obr. 6.7:

Kódování a modulace

Pro výběr vhodného schématu obecně platí, že odstranění složek o vysokých frekvencích snižuje požadavky na potřebnou šířku pásma. Pokud se ze spektra odstraní stejnosměrná složka, nemusí být vysílač a přijímač fyzicky přímo propojen, pro jejich galvanické oddělení lze použít např. transformátory (sníží se interference apod.). Některá kódovací schémata usnadňují vymezení bitových intervalů přímo průběhem signálu, takže nevyžadují použití externí synchronizace zvláštními hodinami a usnadňují detekci chyb. Mezi základní kódovací formáty patří následující případy. Při popisu platí, že H značí vysokou úroveň signálu, L značí úroveň nízkou. NRZ-L Nonreturn-to-Zeroo-Level 0=H 1 =L NRZI Nonreturn-to-Zero-Inverted 0 = na počátku bitového intervalu žádný přechod 1 = na počátku bitového intervalu přechod Manchester 0 = uprostřed bitového intervalu přechod z H na L 1 = uprostřed bitového intervalu přechod z L na H


103

Differential Manchester vždy přechod uprostřed bitového intervalu 0 = na začátku bitového intervalu přechod 1 = na začátku bitového intervalu žádný přechod

Obr. 6.8:

Některé dvoustavové kódy [2]

Kód NRZ je nejjednodušší z kódů této třídy, často se používá pro vyjádření binární informace na vstupu kodéru jiného, složitějšího digitálního signálu. Signál kódovaný podle NRZ obsahuje stejnosměrnou složku a neobsahuje žádné synchronizační prostředky, což neumožňuje přenos dlouhých sekvencí stejných symbolů. Mnohdy se dává přednost kódovacím metodám nazvaným dvoufázové (biphase), které zaručují v každém bitovém intervalu alespoň jeden přechod mezi polaritami napětí signálu. To sice zvyšuje modulační rychlost a tudíž i potřebnou šířku pásma, ale signál je vnitřně synchronizován, neobsahuje stejnosměrnou složku a absence přechodu v daném čase indikuje chybu. Typickými příklady těchto kódů jsou Manchester nebo diferenciální Manchester, které jsou použity v řadě lokálních sítí. Při kódování typu Manchester se každá bitová perioda rozdělí na dva stejné intervaly. Bit s hodnotou 1 je vysílán tak, že v prvním intervalu má napětí vysokou úroveň a ve druhém má nízkou úroveň. Bit s hodnotou 0 je vysílán opačným způsobem: nejprve nízká úroveň, pak vysoká úroveň. Tento postup zaručuje, že ve středu každé bitové periody dojde k přechodu a přijímač s vysílačem se může synchronizovat. Nedostatkem kódování typu Manchester je, že požaduje ve srovnání s přímým zobrazováním bitů dvojnásobnou šířku pásma, poněvadž impulsy mají poloviční šířku.


104

Obr. 6.9:

Spektrální náročnost jednotlivých kódů [2]

Menší nároky na šířku pásma mají kódy využívající více stavů (minimálně 0 a +-V). Patří sem kódy pseudoternární a AMI.

Obr. 6.10: Třístavové kódy Bipolar-AMI 0 = žádný signál 1 = kladná / záporná úroveň alternující po následujících 1 Pseudoternary 0 = kladná / záporná úroveň alternující po následujících 0 1 = žádný signál Oba kódy si však neporadí s dlouhou posloupností nul (AMI) nebo jedniček (pseudoternární). Aby se nezvyšovaly nároky na šířku pásma, vznikly kódy B8ZS a HDB3, které ošetřují tuto eventualitu, jen když k ní dojde.


105

B8ZS Kód je založen na AMI. Pokud se v posloupnosti vyskytne 8 nul tak je tato osmice zakódována jako 000+-0-+ když poslední puls byl + 000-+0+- když poslední puls byl HDB3 Sleduje výskyt čtyř po sobě jsoucích nul, které kóduje v závislosti podle počtu pulsů od poslední substituce (sudý – S nebo lichý – L) 000- (pro S) +00+ (pro L) když poslední puls byl – 000+ (pro S) -00- (pro L) když poslední puls byl + Blokové kódy přiřadí skupině vstupních bitů jinou (větší) skupinu bitů. Např. u kódu 4B/5B existuje celkem 24 = 16 čtveřic na vstupu, kterým se přiřadí vhodně vybrané pětice z celkového počtu 25 = 32. Tak je možné vyloučit např. pětice samých nul, apod.

6.4 Mechanismy pro přenos dat 6.4.1

Rámce

Mezi typické činnosti linkové vrstvy patří strukturování proudu bitů na protokolární datové jednotky - rámce. Tok rámců lze snadněji řídit než tok dat, pohotověji se vyhodnocuje chybovost přenosu apod.

preambule řízení

data

ukončení

Obr. 6.11: Obecná struktura rámce Mezi typické úkoly linkové vrstvy patří • rozpoznání začátku a konce a rámce – synchronizace, • řízení toku zabraňující zahlcení přijímače, • chybové řízení – reakce na výskyt chyby při přenosu, • identifikace komunikujících partnerů, organizace provozu Protokoly dělíme na znakově a bitově orientované. Znakově orientované protokoly jsou takové, kde přenos probíhá po skupinách bitů – znacích. Typickým představitelem je přenos dat po asynchronní sériové lince. Daleko častěji užívané bitově orientované protokoly se používají tam, kde se data přenášejí jako proud bitů bez nutnosti členění na „znaky“. Přijímač musí rozpoznat začátek a konec bloku bitů (sdružených znaků). Pro tento účel se běžně používá úvodní a koncový bitový vzorek preambule a ukončení. Formát rámce se liší podle toho, zda se jedná o znakově nebo bitově orientovaný přenos. V případě znakově orientovaného přenosu tvoří preambuli a ukončení posloupnost smluvených znaků (např. DLE STX z abecedy ASCII). Příchodem preambule je přijímač vybuzen k činnosti a odebírá data, dokud nerozpozná znaky ukončení. Je třeba ošetřit případ, kdy přenášená data obsahují sekvenci odpovídající preambuli nebo ukončení.


106

V případě bitově orientovaného přenosu preambuli i ukončení tvoří smluvený bitový vzorek a transparentnost se dosahuje při vysílání vkládáním pomocných bitů a jejich vypouštěním při příjmu, tak aby se uvnitř rámce neobjevila kombinace odpovídající preambuli nebo ukončení.

6.4.2

Detekce chyb

V systémech přenosu dat převažuje použití mechanismů zabezpečení proti chybám založených na detekci chyby při přenosu a následném vyvolání akcí vedoucích k opakování chybně přeneseného rámce před použitím mechanismů zabezpečujících automatickou opravu chyby na straně přijímače. Režijní ztráty jsou nižší. Nechť Pb je pravděpodobnost bitové chyby při přenosu (nebudeme uvažovat shluky chyb). Pravděpodobnost, že bude rámec obsahující F bitů přenesen bezchybně je P1 = (1 − Pb ) F .

(6.5)

Pravděpodobnost chybně přijatého rámce pak bude P2 = 1 − P1 . (6.6) -6 -3 Např. pro Pb = 10 a F = 1000 dostáváme P1 = 0,999 a P2 = 10 . Princip metod detekce chybně přijatého rámce je následující: k rámci vysílač přidá redundantní informaci, tzv. kód detekce chyby, který se vypočítá jako hodnota nějaké (jednosměrné, hašovací) funkce původně přenášených bitů. Přijímač provede stejný výpočet a výsledky porovná. Neshoda indikuje chybu přenosu. Chybové řízení je více než detekce chyby. Patří do něj rovněž její případná oprava, resp. reakce na jejich výskyt. Informace může být během přenosu z jednoho místa na druhé ztracena nebo poškozena. Pro detekci je možné použít např. tyto mechanismy: • parita (příčná a podélná) • prostý součet • cyklická redundantní kontrola (CRC) 6.4.2.1 Paritní kontroly Bitový vzorek přenášený komunikačním kanálem se zabezpečí paritou tedy tak, že se k přenášeným bitům vzorku přidá paritní bit, který svojí hodnotou zabezpečuje, že počet 1 ve vzorku je lichý, lichá parita, nebo sudý, sudá parita. Samostatně zabezpečovaným vzorkem může být např. posloupnost bitů, do které je zakódován znak zprávy. V případě asynchronního přenosu se používá lichá parita, v případě synchronního přenosu sudá parita. Vertikální parita se uplatňuje na každý znak zprávy zvlášť. Proto každý znak musí být doplněn paritním bitem. Mezi odesílatelem a příjemcem je třeba učinit dohodu o tom, zda se bude používat sudá nebo lichá parita. To znamená, že počet jedniček ve znaku je, nebo se udělá, sudý nebo lichý. Dojde-li k lichému počtu, např. k 1 bitové chybě, příjemce je schopen toto rozpoznat a podat o tom zprávu. Dojde-li k sudému, např. ke dvěma bitovým chybám najednou, pak je vertikální parita neodhalí. Hovoříme o zbytkové chybě, resp. o pravděpodobnosti zbytkové chyby. Kontrola podélné parity se provádí v rámci celé zprávy nebo v rámci její nějak definované části. Po ukončení zprávy nebo její části se vyšle řídicí znak, který obsahuje součet modulo 2 všech bitových vzorků, které prošly vedením během právě končícího textového režimu. Tento znak se nazývá znak LRC (Logitudinal Redundancy Check) a je vytvářen vysílající stanicí tak, že bitové řetězy všech znaků, včetně znaku LRC, obsahují


107

lichý nebo sudý počet jedniček, podle toho co je domluveno s přijímající stanicí. Výpočet LRC požaduje pro svoji realizaci technické prostředky. Nejedná se o nějak mocnou metodu, často se však používá v kombinaci s vertikální paritou. Znaku LRC se říká rovněž znak kontroly bloku, BCC (Block Check Character). Zavedeme pravděpodobnost pb jako pravděpodobnost bitové chyby, pl jako pravděpodobnost správně přijatého rámce, p3 jako pravděpodobnost detekce chybného rámce a p2 bude pravděpodobnost neodhalení chybného rámce. Uplatněním pravidel kombinatoriky lze získat kvantifikaci jednotlivých pravděpodobností: , ,

(6.7)

, kde Nb a Nc jsou postupně počet bitů v zakódovaném znaku, včetně paritního a počet znaků v rámci. Paritní kontrola podstatně sníží pravděpodobnost přijetí rámce s nedetekovanými chybami, p2, pravděpodobnost přijetí správného rámce se použitím paritní kontroly významně nezmění. Sudé počty chyb při přenosu bloku paritní kontrola totiž neodhalí. Podstatným vylepšením paritní kontroly je kombinace obou předchozích metod. Ke každému znaku je přidán bit vertikální parity, VRC, a další paritní bit tzv. podélné parity, LRC, se generuje pro každou bitovou pozici přes všechny znaky v rámci. K rámci se tak přidá další „paritní znak“. Měření ukazují, že přidáním podélné parity se chybovost sníží až o 4 řády ve srovnáním s aplikací pouhé příčné parity. Je zřejmé, že p3 je stále nenulová, poněvadž se opět neodhalí sudý počet týchž bitových chyb ve znaku v sudém počtu znaků.

Obr. 6.12: Kombinace vertikální a podélné parity [7] 6.4.2.2 Cyklická redundantní kontrola, CRC Vysílač generuje ke k-bitovému rámci n-bitovou redundantní bitovou posloupnost kontrolní posloupnost rámce, FCS (Frame Check Sequence), tak, aby k+n bitů bylo dělitelných nějakým předem určeným číslem. Přijímač tímto číslem přijatý rámec vydělí a získání nenulového zbytku je indikací chyby. Zabezpečovaná zpráva je tedy vysílačem opět doplněna o nadbytečnou, redundantní informaci, počet přidávaných bitů je větší než u paritní kontroly, typicky 12 nebo 16. Jak LRC, tak i CRC se mnohdy nazývá i znak kontroly bloku, BCC. Při hledání FCS/BCC vysílač chápe všechny vysílané znaky jako jediné binární číslo. Toto číslo dělí (modulo 2) konstantou (polynomem) a získá podíl a zbytek. Zbytek je brán jako znak FCS/BCC. Možná implementace metody při n = 4 je následující:


108

k-bitovou zprávu M vyjádříme jako polynom proměnné X s binárními koeficienty odpovídající bitům zprávy. Pro zprávu M = 110011 je tedy M(X) = X5 + X4 + X + 1. • Vysílaný rámec T bude mít k + n bitů, prvních k bitů je zpráva M posledních n bitů T označíme F (jde o FCS). Platí T = 2nM + F. • Nechť předdefinovaný n + l bitový dělitel P = 11001 (dělitel P závisí na typech očekávaných chyb, jeho krajní bity musí být jedničkové), pak P(X) = X9 + X3 + 1. • CRC proces (Cyclic Redundancy Check) spočívá v následujícím postupu: 1. vysílač polynom 2nM vydělí polynomem P a zbytek R použije jako FCS (ten je n-bitový), tedy vysílaný rámec je T = 2nM + R. 2. přijímač polynom T vydělí polynomem P a pokud se T při přenosu chybou nezměnil, získá nulový zbytek. Mezi typické polynomy P používané pro detekci chyb patří polynom definovaný ITU-T pro 8bitové znaky: CRC–ITU-T = X16+X12+X5+1 poskytující 16bitovou FCS, resp. podobný široce používaný polynom: CRC -16 = X16+X12+X2+1 •

V lokálních sítích norma IEEE-802 předpisuje používat polynom generující 32bitovou FCS: CRC -32 = X32+X26+X23+X22+X16+X12+X11+X10+X8+X7+X5+X4+X2+X +1 Lze ukázat, že CRC detekuje: • všechny jednobitové chyby, • všechny dvoubitové chyby, pokud P má alespoň tři členy, • všechny liché počty chyb, pokud P obsahuje činitel X + 1, • všechny dávkové chyby, pokud délka chybového intervalu je kratší než délka FCS, • většinu delších dávkových chyb (pravděpodobnost neodhalení shluku chyb je ). Výpočet dělení polynomů je relativně složitý, lze jej však realizovat technickými prostředky pomocí posuvného registru. V praxi se tento způsob používá téměř výhradně. Schéma ilustruje obr. 6.13 pro CRC zabezpečení polynomem X5+X4+X2+1. Obvod obsahuje posuvný registrů a n sčítaček modulo 2. Sčítačka se aplikuje nebo ne podle toho, zda se v zabezpečovacím polynomu objevuje či neobjevuje odpovídající člen. Na počátku CRC výpočtu jsou posuvné registry prázdné. Při vysílání se rámec počínaje nejvyšším bitem bit po bitu vkládá na vstup. Kdykoli přijde na levý konec obvodu 1, odečítá se (XOR) od 4. a 5. bitu v rámci příštího posuvu (binární dlouhé dělení). Tento proces se opakuje přes celý rámec doplněný o n (=4) prázdných bitů. Po zpracování posledního bitu, posuvný registr obsahuje vzorek zbytku, FCS. Na příjmové straně se použije stejná logika, do registru se vsouvá T a výsledkem po bezchybném přenosu bude nulový obsah posuvného registru.

Obr. 6.13: Výpočet CRC pomocí posuvného registru [7] Na obr. 6.14 je graf ukazující pravděpodobnost, že pomocí CRC32 nebude odhalena chyba v Ethernetovém rámci. Číslo n udává délku rámce v bitech, na ose x je chybovost fyzické linky.


10-9

109

probability of undetectable error

2-32

-10

10

10-11 n= 512 n= 1024 n= 2048

10-12 10-13

n= 4096 n= 8192 n=12144

10-14 10-15 10-5

10-4

10-3

10-2

10-1 BER

Obr. 6.14: Zbytková chybovost Ethernetu

6.5 Shrnutí kapitoly 6 V oblasti lokálních sítí je dnes nejpoužívanějším médiem kroucený pár. Ve variantě UTP6a a UTP7 dovoluje dosáhnout při paralelním využití čtyř párů rychlosti až 10Gb/s. Pro delší vzdálenosti je nutné použít optická vlákna. U lokálních sítí 10Gb/s se již výrazně projevuje disperze vícemódových vláken i na vzdálenosti desítek metrů. Od jednoduchých kanálových kódů se přechází v základním pásmu na víceúrovňová schémata, která vyžadují poměrně náročné zpracování signálu na straně vysílače i přijímače. Na linkové úrovni jsou data přenášena v rámcích. Podle charakteru sítě jsou rámce doplněné o ochranu proti chybám.


110

7 Lokální sítě Cíle kapitoly: • Metody přístupu ke sdílenému médiu. • Síť Ethetnet: varianty, aktivní prvky, propojování.

7.1 Přístup ke sdílenému médiu Mechanismy pro sdílení média jsou důležité především v lokálních sítích, poněvadž mnoho lokálních sítí používá jako základ svojí komunikace právě kanál s mnohonásobným přístupem. Proti tomu rozlehlé sítě používají vesměs dvoubodové spoje, výjimku tvoří např. družicové rozlehlé sítě. Protokoly pro řízení přístupu uzlů k přenosovému médiu se zařazují jako nejnižší podvrstva linkové vrstvy. Tato podvrstva se nazývá řízení přístupu k médiu, MAC (Medium Access Control). Metody řízení přístupu můžeme rozdělit na statické a dynamické. Princip statických přístupových metod spočívá v tom, že danému přenosu je po celou dobu komunikace či dokonce stále vyhrazena určitá přenosová kapacita. Naproti tomu u dynamických metod je celá přenosová kapacita k dispozici všem přenosům a jednotlivé zdroje se musí o přidělení možnosti vysílat určitým způsobem ucházet. Tento princip je vlastní sítím se spojováním paketů. Metody můžeme rozdělit na • deterministické – metody garantují maximální zdržení, než se stanice dostane k vysílání a umožňují implementaci priorit o s centrálním přidělováním – v síti existuje centrální uzel, který uděluje koncovým stanicím oprávnění k vysílání na žádost (koncová stanice žádá centrální uzel o právo vysílat) nebo na výzvu (centrální stanice se dotazuje koncových stanic, zda nechtějí vysílat) o distribuované – stanice si předávání pověření k vysílání (Token Ring) • náhodné – přístup ke sdílenému kanálu je náhodný proces (Aloha, CSMA, /CD, /CA) Typické topologické struktury lokálních sítí jsou: Sběrnice Základním prvkem sběrnicové sítě je úsek přenosového média - segment sběrnice, ke kterému jsou připojeny stanice sítě. Přenosovým médiem je nejčastěji koaxiální kabel nebo symetrické vedení (krouceny dvoudrát). U optických vláken je realizace odboček obtížná. Hvězda Stanice sítě jsou připojeny k centrálnímu uzlu samostatnými linkami. Centrální uzel označovaný jako hub (v překladu "střed loukoťového kola" ) signál přicházející z jedné linky rozděluje do ostatních linek hvězdy. Rozlišujeme pasivní hub, ve kterém je signál pouze dělen (odporovým děličem), a aktivní hub (vícevstupový opakovač); ve kterém je přijatý signál upravován tak; aby měl na výstupních linkách požadovanou úroveň a časování. Topologie hvězda s pasivním centrálním uzlem často nacházíme u optických sítí.


111

Kruh U kruhových sítí jsou komunikační stanice propojeny spoji, které jsou využívány pouze jednosměrně. Signál vyslaný jednou stanicí je postupně předáván ostatními stanicemi kruhu (základní prvkem stanice je krátký posuvný registr) a po oběhu sítí se vrací ke stanici, která jej odeslala. U kruhových sítí jsou pravidelně používány deterministické, metody řízení, zvýšení spolehlivosti lze dosáhnout použitím dvou protisměrných kruhů nebo kombinací kruhové topologie s přepojováním.

7.1.1

Statické přidělování kapacity kanálu

Přidělování kapacity sdíleného média kanálu mezi více uživatelů lze implementovat multiplexováním signálů (FDM, TDM, CDM, ...). Existuje-li N uživatelů (komunikujících dvojic uzlů apod.), dostupná kapacita se rozdělí na N stejně širokých částí a každému uživateli se přidělí jedna její část. Poněvadž každý uživatel má svůj vlastní kanál, uživatelé se neovlivňují. Takový jednoduchý a efektivní mechanismus přidělování lze použít pouze když se jedná o malý nebo alespoň neměnný počet uživatelů a každý z nich má trvalé nároky na přenos (např. telefonní ústředny). Je-li počet uživatelů velký a navíc se mění, resp. jsou-li jejich požadavky na přenos nárazové, způsobuje použití multiplexu problémy. Jestliže se spektrum rozdělí do N intervalů a o komunikaci se zajímá méně než N uživatelů, promrhá se velká část využitelného spektra. Jestliže si přeje komunikovat více jak N uživatelů, některým z nich se z důvodu nedostatečné šířky pásma žádost odmítne i přesto, že někteří uživatelé, kterým byla šířka pásma přidělena, vysílají nebo přijímají jen zřídka. Ve většině počítačových systémů je přenos dat mimořádně nárazový (běžný poměr špičkové a průměrné zátěže bývá 1000:1). Tudíž, většina kanálů bude většinu doby v klidu.

7.1.2

Náhodný přístup ke sdílenému médiu

7.1.2.1 Aloha Nejjednodušší metodou náhodného přístupu je prostá Aloha, která byla poprvé použita v roce 1971 pro řízení rádiové sítě na Havajské universitě. Stanice, která má rámec připravený k odeslání, začne vysílat bez ohledu na případné obsazení kanálu jiným přenosem. Důsledkem jsou pochopitelně kolize. Rámce poškozené při kolizi je nutné opakovat (v praxi je tato skutečnost indikována vypršením časového limitu, do kterého měl být příjem potvrzen), prodleva před zahájením dalšího pokusu musí být volena náhodné, aby nedošlo k opakování kolize. Budeme-li měřit vstupní tok sítě počtem rámců, které mají být přeneseny, a tento tok označíme S, je zřejmé, že v ustáleném stavu je tento tok roven toku výstupnímu (rámce přenesené sítí). V důsledku kolizí a z toho vyplývající nutnosti opakovat poškozené rámce je celkový tok vnucovaný stanicemi kanálu vyšší, označujeme ho G. Vztah obou toků za předpokladu, že opakující stanice nesmí generovat nový rámec, lze vyjádřit jako [8] (7.1) S = Ge −2G . Průběh této závislosti uvádí obr. 7.1. U metody prostá Aloha lze dosáhnout využití kapacity kanálu až 18.4 %, při dosažení odpovídající zátěže je každý rámec v průměru vyslán třikrát.


112

Podstatného zvýšení průchodnosti sítě lze dosáhnout jednoduchou modifikací metody Aloha. Stanicím dovolíme zahájit vysílání pouze v okamžicích, které definují začátky časových úseků postačujících pro odeslání jednoho rámce. Metodu označujeme jako taktovaná Aloha (Slotted Aloha). Maxim průchodnosti je 36%, obr. 7.1.

Aloha

Obr. 7.1:

Průchodnost systému Aloha [8]

Výhodou metod Aloha je okamžité odvysílání rámce. Překročí-li však zátěž určitou mez, zvýší se počet opakovaných rámců a silné poklesne pravděpodobnost přenosu nepoškozeného kolizí. Síť přechází do tzv. zablokovaného stavu, ze kterého se nelze bez modifikace parametrů sítě dostat. 7.1.2.2 Metody CSMA Metody Aloha byly navrženy pro rádiové sítě a nevyužívaly možnosti zjistit obsazenost přenosového kanálu před zahájením vlastního vysílání. U lokálních sítí, které se vyznačují malým zpožděním signálu a dokonalou slyšitelností stanic, však taková informace dovolí podstatné omezit pravděpodobnost kolize. Metody, které znalost obsazení kanálu využívají, nazýváme metodami náhodného přístupu s detekcí nosné - CSMA (Carier Sense Multiple Access). Naléhající CSMA Stanice, která používá metodu naléhající CSMA (persistent CSMA, 1-persistent CSMA), před odesláním rámce testuje stav kanálu. Je-li kanál obsazen, stanice odloží vysílání na okamžik, kdy se kanál uvolní. Je-li kanál volný, tak zahájí vysílání. Zjevnou nevýhodou této jednoduché metody je riziko kolize stanic, které čekají na uvolnění kanálu. Poměrně vysoké riziko se projeví nižší průchodnosti kanálu (zhruba 53 %). Nenaléhající CSMA Stanice, která používá metodu nenaléhající CSMA (non-persistent CSMA), před odesláním rámce testuje stav kanálu. Je-li kanál volný, stanice zahájí vysílání. Pokud je kanál obsazen, stanice počká náhodné zvolenou dobu a znovu testuje stav kanálu. Postup opakuje do odeslání rámce. Volbu náhodné prodlevy obvykle převádíme na volbu náhodného násobku taktu, který obvykle vybíráme tak, že odpovídá době průchodu signálu sběrnicí. Metoda dobře využívá kapacitu kanálu, cenou je však velký počet nutných pokusů a tedy i velké zpoždění při přenosu. p-naléhající CSMA


113

Stanice, která používá metodu p-naléhající CSMA (p-persistent CSMA), před odesláním rámce testuje stav kanálu. Je-li kanál volný, stanice zahájí vysílání. Pokud je kanál obsazen, stanice počká na uvolnění kanálu. Byl-li kanál volný nebo se právě uvolnil, začne stanice s pravděpodobností p vysílat a s pravděpodobností q = 1 - p odloží další činnost o krátký časový interval (může odpovídat délce šíření signálu médiem). Po uplynutí této doby celou činnost opakuje až do úspěšného odeslání rámce. Volba parametru p dovolí optimálně nastavit využití kanálu a střední zpoždění rámce vzhledem k zátěži. Pro p = 1 metoda přechází v naléhající CSMA, pro p→0 se sice průchodnost kanálu blíží hodnotě S = 1, ale střední doba přenosu rámce roste nade všechny meze.

Obr. 7.2: Propustnost metod CSMA [8] Metody CSMA jsou použitelné pouze v sítích s malým rozsahem, ve kterých se pohybuje v mezích 0 < a < 0,1. Pro rozsáhlé lokální sítě efektivita koeficient metod klesá a pro hodnoty a→1 je dokonce horší než pro metody Aloha.

Obr. 7.3:

Efektivita metod CSMA [8]

7.1.2.3 Metody CSMA/CD Metody CSMA nejsou schopné zabránit kolizi, je-li časový interval mezi zahájením vysílání dvou stanic menší než jistá mez, daná konečnou rychlostí šíření signálu v kanále, vzdáleností stanic a rychlostí reakce detekčních obvodů. U naléhající CSMA je navíc při větší zátěži velice nepříjemné, že dojde-li během vysílání rámce více než jeden další požadavek, je výsledkem kolize (bezprostředně po uvolnění kanálu). Kolize, které u dlouhých rámců blokují po dlouhou dobu přenosový kanál, snižují dosažitelnou průchodnost. Zlepšení lze dosáhnout,


114

dokážeme li je detekovat a předčasné zastavit vysílání. Příslušné metody označujeme jako CSMA/CD (Carrier-Sense Multiple Access with Collision Detection). Použití metod CSMA/CD vyžaduje použít kanálu, na kterém lze kolizi zjistit. Například sledováním napětí na médiu, které je buzeno proudovými zdroji vysílačů (Ethernet 10BASE5) nebo sledováním signálu na krouceném páru přijímače (10BASE-T). Stanice, která má připravený rámec k vyslání a detekuje klid na sdíleném kanále po definovanou dobu označovanou jako kolizní slot, zahájí vysílání synchronizační posloupnosti a odešle vlastní rámec. Stanice, která chce vysílat, ale indikuje provoz na médiu, musí počkat na uvolnění média a uplynutí ochranného intervalu (kolizního slotu). Teprve potom může stanice zahájit vysílání. Uvedený postup odpovídá naléhající CSMA. Pokud stanice vstoupila do kolize a tuto skutečnost rozpoznala, přeruší vysílání rámce, ale ještě před uvolněním média odešle kolizní posloupnost (jam). Tato posloupnost zajistí, že kolizi rozpoznají všechny kolidující stanice. O opakované vysílání se stanice pokusí až po určité, náhodné zvolené době. Náhodná volba odmlky brání periodickému opakování kolize. Pokud by se kolize opakovala a stanice další pokus zahájila po sice náhodné zvolené době, ale se stejnou střední hodnotou prodlevy, mohlo by při větším počtu stanic dojít k situaci, kdy kolize zcela zablokují užitečnou činnost kanálu a síť se z tohoto stavu bez vnějšího zásahu nedostane. Metoda CSMA/CD je použita u Ethernetu. Při zjištění kolize je další pokus plánován na r-tý kolizní slot (slot = dvojnásobek doby šíření signálu po sběrnici), kde r je náhodné zvolené číslo z intervalu 0 < r <= 2k . Exponent k je odvozen z počtu neúspěšných pokusů o odeslání rámce, k = min(n,10). Po šestnácti pokusech je o nemožnosti odeslat rámec (zřejmé jde o poruchu média nebo stanice) informován ovladač a/nebo aplikační program. Tato metoda řízení je označována jako exponential back-off. 7.1.2.4 Řízený přístup - logický kruh řízený příznakem oprávnění Kruh je hlavní alternativou topologie LAN vůči sběrnici. V podstatě jde o cyklické propojení opakovačů jednosměrně orientovanými spoji. Data se kruhem vysílají sekvenčně, bit po bitu po vícebitových dávkách - rámcích opatřených alespoň adresou cílového uzlu. Kruh může být pouze logická topologie. Z hlediska údržby je výhodnější topologie hvězdicová. Vlastní „kruhové“ propojení je realizováno centrálním prvkem – hubem, obr. 7.4.

Obr. 7.4:

Fyzická a logická kruhová topologie [9]

Když logický kruh inicializuje činnost, může začít vysílat rámce např. uzel s nejvyšší adresou. Jakmile takový uzel rámec vyšle, předá povolení vysílat svému nejbližšímu sousedovi tak, že mu pošle speciální řídicí rámec nazývaný příznak oprávnění (token). Příznak oprávnění se šíří po logickém kruhu cyklicky, přičemž vysílat smí rámce jen ten uzel,


115

který vlastní příznak oprávnění. Poněvadž příznak oprávnění vlastní pouze jediný uzel, nedojde nikdy ke kolizi.

7.2 Ethernet (IEEE 802.3) 7.2.1

Architektura

Standard IEEE 802.3 definuje fyzické médium, algoritmus přístupu a formát přenášených rámců. Architektura definovaná standardem odpovídá obr. 7.5.

Obr. 7.5:

Architektura standardu Ethernetu IEEE 802.3

Ethernet obsazuje fyzickou a linkovou vrstvu. Linková vrstva se dále dělí na vrstvu MAC (Medium Access Control) řídící přístup ke sdílenému médiu (avšak sdílení se dnes již prakticky nepoužívá). Po MAC je vrstva PHY zajišťující kódování, obnovu taktu, kompenzaci přeslechů, apod. MAC komunikuje s PHY přes standardizované čistě digitální rozhraní (AUI, MII, GMII). MAC je tedy čistě číslicový obvod, zatímco PHY je analogověčíslicový sytém. Na obr. 7.6 je Ethernetový rámec. Na počátku má synchronizační preambuli (součást fyzické vrstvy), při které se synchronizují všechny stanice přijímající rámec. Na konci rámce je kontrolní součet CRC-32, ze kterého lze zjistit, nebyl-li rámec přenosem poškozen. Dále obsahuje šestibajtovou linkovou adresu příjemce a odesílatele. Další informací je údaj o vyšším protokolu, pro který je blok dat určen (u Ethernetu II), nebo údaj o délce a údaj definující přesněji odesílatele a adresáta v rámci počítače a sloužící potvrzování (u Ethernetu IEEE 802.3, strukturu a využití tohoto údaje definuje protokol logické vrstvy LLC IEEE 802.2). Minimální délka rámce je 64 bajtů (bez preambule). Datové tedy pole musí být


116

minimálně 46 bajtů dlouhé, takže v případě, že je potřeba přenášet méně dat, tak se datové pole zprava doplní bezvýznamnou výplní.

Ethernet II

Obr. 7.6:

Rámec Ethernetu (formáty Ethernet II a 802.3) [10]

Fyzická adresa je šestibajtová. První tři bajty specifikují výrobce síťového adaptéru a zbylé tři bajty jsou v podstatě výrobní číslo. Adresy jsou proto celosvětově unikátní. Toto platí pouze pro tzv. globální adresy, které jsou uloženy v permanentní paměti síťové karty. Při inicializaci karty ovladačem lze kartě sdělit, aby nepoužívala tuto adresu, ale adresu jinou. V rámci firmy tak lze používat vlastní systém linkových adres. Síťová karta může používat globálně jednoznačnou adresu nebo jednoznačnou adresu v rámci firmy. Kromě těchto jednoznačných adres existují ještě oběžníky. Všeobecný oběžník (adresa se skládá z 48 jedniček) je určen pro všechny stanice na LAN. Adresný oběžník (má nastaven nejnižší bit prvního bajtu na jedničku) je určen pouze některým stanicím na LAN, stanicím, které akceptují uvedenou adresu. Nultý a první bit prvního bajtu linkové adresy mají specifický význam, obr. 7.7. Nultý bit specifikuje, zdali se jedná o jednoznačnou adresu nebo adresu oběžníku. První bit specifikuje, zdali se jedná o globálně jednoznačnou adresu.

Obr. 7.7:

Struktura MAC adresy [3]

S výjimkou 10Gb Ethernetu implementují všechny varianty metodu CSMA/CD pro přístup ke sdílenému médiu. Stanice, která má připravený rámec k vyslání a detekuje klid na sdíleném kanále po dobu alespoň povinné mezirámcové mezery (9,6µs pro 10Mb/s, 0,96 µs pro 100Mb/s a 96ns pro 1Gb/s), zahájí vysílání synchronizační posloupnosti a potom odešle


117

vlastní rámec. Stanice, která chce vysílat, ale detekuje provoz na médiu, musí počkat na uvolnění média a uplynutí ochranného mezirámcového intervalu (naléhající CSMA). Stanice, která vstoupila do kolize a tuto skutečnost rozpoznala, se pokusí o opakované vysílání po náhodné zvolené době se střední hodnotou rovnou délce kolizního intervalu (51,2µs pro 10Mb/s, 5,12µs pro 100Mb a 4,096µs pro 1Gb/s). Náhodná volba odmlky brání periodickému opakování kolize stanic. Pokud k opakované kolizi dojde, stanice prodlužuje střední dobu prodlevy na dvojnásobek. Po deseti neúspěšných pokusech přestane prodlevu prodlužovat a po šestnácti hlásí závadu vyšším vrstvám obsluhy. Postup označovaný jako Exponential Back-off je navržen tak, aby zajistil stabilitu sítě pro alespoň 1024 stanic. To je také limit, který stanovuje norma pro skupinu segmentů propojených opakovači - kolizní doménu. Přístupová metoda Ethernetu CSMA/CD se opírá o informace, které je stanice schopna získat pozorováním sítě. Vzhledem ke konečné době šíření signálu v přenosovém médiu a ke zpožděním v opakovačích se však jedná o informace nepřesné čímž efektivita metody CSMA/CD klesá s rostoucí vzdáleností stanic. Proto je standardem omezena jak vzdálenost po médiu tak i počet opakovačů mezi každými dvěma stanicemi. Překročení limitů může být důvodem podstatného zvýšení počtu kolizí a počtu poškozených rámců a tím i výsledného snížení průchodnosti sítě. V režimu plného duplexu se metoda CSMA/CD nepoužívá.

7.2.2

Ethernet 10Mb/s

7.2.2.1 10BASE2 Pro propojení používá koaxiální kabel o průměru 5mm a impedanci 50Ω s jednoduchým opletením (Thin Ethernet Cable, RG 58A/U nebo RG58C/U). Maximální délka segmentu je 185m. Transceiver (MAU) je u 10BASE2 většinou integrován přímo na desce řadiče Ethernetu. Na vývod karty je připojena rozbočka ve tvaru písmene T, segment je tvořen propojovacími kabely mezi rozbočkami jednotlivých karet, na konce segmentu musí být připojeny zakončovací odpory. Na jeden segment je možné připojit nejvýše 30 stanic, nejmenší vzdálenost mezi nimi je 0,5 m. Výstavba segmentu s použitím tenkého kabelu je sice jednoduchá, přináší však jedno podstatné nebezpečí. Tím je přerušení segmentu náhodným rozpojením konektoru uživatelem.

Obr. 7.8:

Prvky sítě 10BASE2 [8]

7.2.2.2 10BASE-T (IEEE 802.3i) Koaxiální kabely jako médium pro výstavbu sítí Ethernet se již nepožívají. Důvodem je pře chod k "levnějšímu" a univerzálnějšímu kabelu UTP (Unshielded Twisted Pair) a k odlišnému způsobu vytvoření sdíleného kanálu úseky UTP kabelu o délce do 100 m (přesněji do 90 m pevného rozvodu a dvakrát 5 m pohyblivý kabel pro připojení zařízení) propojují jednotlivé stanice s vícevstupovým opakovačem (tzv. hub). Ten je středem hvězdice tvořené


118

skupinou až osmi, dvanácti, šestnácti nebo i více stanic a vytváří analogii segmentu technologií 10BASE2.

Obr. 7.9:

Struktura sítě 10BASE-T [8]

Ze čtyř párů kabelu UTP jsou využity dva, jeden pár přenáší signál od stanice k opakovači, druhý přenáší signál ve směru opačném. Kabel UTP musí splňovat podmínky na šířku pásma, charakteristickou impedanci a přeslech. Podmínky splňují kabely UTP Cat.3 (Voice Grade) a s rezervou dnes běžnější kabely UTP Cat.5. Jako konektor (zásuvky karet, zásuvky pro pevný rozvod, zástrčky na kabel) slouží plochý konektor EIA RJ45, obr. 7.10. Zapojení pinů se liší u terminálu (síťová karta) – zapojení MDI a u aktivního prvku – zapojení MDI-X, aby bylo možné použít přímý kabel. Při spojení rovnocenných zařízení je nutné použít kabel překřížený (spojí se 1,2 – 3,6 a 3,6 – 1,2). Každé zařízení je připojeno ke kabelu pomocí oddělovacích transformátorů (to platí i pro 100Mb a 1Gb Ethernet). Typické zapojení je na obr. 7.11.

Obr. 7.10: Zapojení přímého kabelu UTP-5 pro přenos po dvou párech Alternativním přenosovým médiem jsou optická vlákna podle 10BASE-FL. Ta dovolí prodloužit vzdálenosti mezi opakovači, nebo mezi stanicí a opakovačem na 400m. Jako označení pro opakovač 10BASE-T se vžilo označení hub. Opakovač předává signál přijatý od jedné ze stanic po elektrické úpravě stanicím ostatním, kromě stanice nebo opakovače, od nichž je přijímán. Stará se tak o vytvoření sdíleného kanálu. Příjem signálu při vlastním vysílání je pro stanici indikací kolize. Opakovače lze mezi sebou propojovat, buď opět kabely UTP, segmenty koaxiálního kabelu nebo optickými spoji.


119

Obr. 7.11: Typické elektrické zapojení rozhraní pro UTP kabel Sdílený kanál vytvářený vícevstupovým opakovačem 10BASE-T nebo strukturou z nich složenou přináší proti sběrnicovému propojení počítačů podstatnou výhodu: odpojení stanice nemůže ovlivnit chod zbytku sítě. Logika moderních opakovačů 10BASE-T dovolí odizolovat i stanici, která by u sběrnicového Ethernetu svou poruchou narušila funkci celé sítě (například trvalým vysíláním signálu).

7.2.3

Přepínaný Ethernet

Mosty (bridge) Ethernetu dovolují rozdělit rozsáhlejší sít' na kolizní domény, provoz v jedné části sítě nemá vliv na provoz v části druhé a součtový tok v síti může být vyšší, než je limit v každé z kolizních domén. U víceportových mostů (switch-přepínač), které propojují více kolizních domén, se objevuje další zajímavý efekt. Přenos rámců mezi dvěma kolizními doménami přes takový most neblokuje jiný přenos mezi jinými dvěma kolizními doménami přes týž most. Při větším počtu portů a možnosti rozdělit sít' na menší kolizní domény (segmentaci sítě) je tento efekt silnější. V krajním případě se můžeme dostat až k situaci, kdy na každý port přepínače je připojena jediná stanice a takto využívané přepínače jsou propojené dvoubodovými spoji (v síti nejsou víceportové opakovače ani sběrnicové segmenty s více než dvěma připojenými prvky), mluvíme o mikrosegmentaci. Taková sít' funguje prakticky stejné jako každá jiná sít' bod-bod s přepojováním paketů. Pouze místo paketů jsou zde přepojovány rámce Ethernetu a s ohledem na jednodušší topologii (pro provoz je využitelná pouze stromová podsít' získaná použitím Spanning-Tree algoritmu podle IEEE 802.1d) se zjednodušuje směrování. Rámce přijaté z jednotlivých vstupů jsou ukládány do pamětí přepínače, po rozhodnutí o způsobu odeslání a případné úpravě směrovací tabulky (přepínač se učí rozložení stanic v síti) převedeny do front na výstupech a odesílány do výstupních kanálů. Tento postup je označován jako Store-and-Forward. Určitou nevýhodou techniky Store-and-Forward je zpoždění, způsobené tím, že rámec může být vysílán do výstupního kanálu až po jeho dokončeném převzetí. Zpoždění lze


120

eliminovat, dovolíme-li přepínači zahájit vysílání do neobsazeného výstupního kanálu okamžité jakmile přepínač přečte adresu příjemce (prvních šest slabik rámce za preambulí). Využití této myšlenky je známé jako technika Cut-Through a dovolí snížit zpoždění rámce při průchodu přepínačem až na 12 µs (proti 58-1220 µs u metody Store-and-Forward, kde záleží na délce rámce). Zpoždění platí pro rychlost 10Mb/s. Pro vyšší rychlosti se úměrně zkracuje.

store-and-forward

cut-through

Obr. 7.12: Metody přepínání [10]

Metoda Cut-Through má však i zápory. Patří mezi ně skutečnost, že odeslán je i rámec, u kterého bude při jeho příjmu zjištěna chyba CRC (v době, kdy přepínač zahajuje vysílání předávaného rámce, ještě nebyl zabezpečovací kód na konci rámce přijat). Další problém vyvolávají kolize na vstupech, přepínač zahájí vysílání rámce, který nebude díky zafungování detekce kolize přijat celý. Tento problém lze poměrně jednoduše řešit tak, že vysílání zahájíme až po převzetí dostatečného počtu znaků, tedy až budeme mít jistotu, že přijímaný rámec dojde celý (bylo přijato 64B a vysílání rámce již nepřeruší detekce kolize). Úprava metody Cut-Through, která brání předání krátkých fragmentů rámců na výstup (a jejich dalšímu šíření sítí) je označována jako Fragment-Free a typické minimální zpoždění přepínače je 58 µs. Duplexní provoz Při použití přepínače jako aktivního prvku již není třeba, aby stanice monitorovala příchozí směr pro určení kolize. Tuto linku je možné využit pro normální přenos. Spojení stanice-přepínač může pracovat v režimu plného duplexu. Rozlehlost sítě již není limitovaná časovými požadavky na velikost kolizní domény. Maximální délka mikrosegmentu (PC-switch nebo switch-switch) je dána jen požadavkem na maximální přípustný útlum. Pro vedení UTP je to standardních 100m, pro optická vlákna pak až 100km bez použití opakovače (100Mb/s, jednovidové vlákno).

7.2.4

Rychlý Ethernet - 100 Mb/s

Ethernet 100BASE-T je určen pro kabelové rozvody UTP/FTP Cat.5 (modifikace 100BASE-T4 vystačí dokonce i s UTP Cat.3) a vícevidová optická vlákna (62.5/125 µm a 50/125 µm). Specifikace rychlého Ethernetu pod označením IEEE 802.3u byla schválena v červnu 1995. Rychlý Ethernet je založen na efektivnějším využití přenosového média. Kódování Manchester je u technologií 100BASE-TX/FX nahrazeno efektivnějším kódováním 4B5B, doplněným o víceúrovňové kódování pro přenos po metalických vedeních (MLT-3


121

Multi-Level Transmit). Ještě výraznějšího zvýšení efektivity dosahují technologie 100BASET4 a 100BASE-T2.

Obr. 7.13: Efektivita kódování u technologií rychlého Ethernetu [8] Vzdálenost mezi stanicí a koncentrátorem je, pokud použijeme metalický kabel, stejné jako u sítě 10BASE-T, do 100 m. Optické vlákno dovolí jít až na 412 m (mezi dvěma stanicemi nebo mezi stanicí a přepínačem) při poloduplexním a na 2000 m při duplexním provozu. U poloduplexního přenosu je omezením doba šíření signálu médiem: signál musí proběhnout médiem do nejvzdálenéjšího místa sítě a zpět (včetně časů potřebných pro elektroniku koncových prvků a opakovačů) za dobu potřebnou k odeslání 512 bitů (5,12µs). Rychlý Ethernet definuje tři rozdílné realizace fyzického kanálu. Základem jsou kanály 100BASE-TX - dva páry kabelu UTP/FTP a 100BASE-FX - dvojice optických vícevidových vláken. Zajímavým doplňkem normy je standard 100BASE-T4, který využívá tří párů kabelu UTP Cat.3 k přenosu dat a čtvrtého páru k detekci kolize. Později byl doplněn standard 100BASE-T2, který vystačí i u kabelů Cat.3 se dvěma páry. S ohledem na různá řešení fyzického rozhraní (PMD - Physical Medium Dependent) je pro rychlý Ethernet definováno rozhraní mezi fyzickou vrstvou a vrstvou MAC. To je označováno jako MII (Medium Independent Interface) a má šířku čtyř datových bitů. Pro toto rozhraní je sice definován čtyřicetipinový konektor, avšak v praxi je využíváno pouze jako standard rozhraní obvodů na desce plošného spoje. Často je zcela skryté uvnitř integrovaného obvodu. 7.2.4.1 100BASE-TX Základní technologií rychlého Ethernetu je 100BASE-TX. Vyžaduje použití UTP/FTP kabelu Cat. 5, jeden pár je využit pro vysílání a druhý pro příjem, obr. 7.14.

Obr. 7.14: Využití párů u technologie 100BASE-TX Základní kódování 4B5B je doplněné o převod na třístavový signál (MLT-3 MultiLevel Transmit).

122


Obr. 7.15: Kódování MLT-3 Třístavový signál MLT-3 dovolí dosáhnout na běžné kabeláži UTP/FTP Cat.5 přenosové rychlosti 100Mb/s (vzhledem ke kódování 4B5B je modulační rychlost 125MBd). Schéma celého řetězce je na obr. 7.16.

Obr. 7.16: Signálový řetězec 100BASE-TX a 100BASE-FX 7.2.4.2 100BASE-T2 Snaha o další vylepšení technologie, schopné přenášet data rychlostí 100Mb/s po jediném páru při zachování mezní modulační rychlosti 25 MBd, vedla k návrhu standardu 100BASE-T2. Tento standard má v oblasti rychlého Ethernetu okrajový význam, použitá metoda kódování však byla využita u přenosu gigabitového Ethernetu po kabelech UTP/FTP.

Obr. 7.17: Kódování PAM-5


123

Princip kódování PAM-5 (5-level Pulse Amplitude Modulation) je poměrné jednoduchý, obr. 7.17. Čtveřice bitů rozhraní MII je převedena na dvojici pětihodnotových symbolů. Ty jsou jako pětiúrovňový signál přeneseny po obou použitých párech. Vedení dovoluje současný (duplexní) přenos v obou směrech, zpracování signálu, zahrnující scrambling a konvoluční kódér, se opírá o procesor DSP. 7.2.4.3 100BASE-FX/SX Metalická vedení jsou dodnes nejlevnější variantou kabeláže lokálních sítí. Technologie rychlého Ethernetu však již předpokládá použití optických vláken, konkrétně vícevidových optických vláken datových (62.5/125 µm) nebo telekomunikačních (50/125 µm). Aby bylo možné překlenout vzdálenosti shodné s technologiemi 10BASE-FL/FB, používá 100BASEFX světlo o vlnové délce 1300nm. Při poloduplexním přenosu je vzhledem k vidové disperzi a použití mnohavidových vláken nejvyšší vzdálenost omezena na 412 m. Na větší vzdálenost, až do 2 km, je nutné pracovat v plném duplexu. Datový signál je pro přenos 100BASE-FX kódován obdobné jako u 100BASE-TX, tedy nejdříve přeložen kodérem 4B5B, vlastní signál optického vlákna je z výstupu kodéru 4B5B získán překódováním NRZI (jednička je reprezentována změnou, nula je beze změny). Použitý kód 4B5B zaručuje nejvýše tři nuly za sebou), obr. 7.16. Technologie 100BASE-SX je modifikací rychlého Ethernetu, pracuje na 850nm. Zařízení mohou, pro omezení vidovou disperzí a tedy i při duplexu, komunikovat rychlostí 100Mb/s na vzdálenost nejvýše 300 m. Výhodou 100BASE-SX proti technologii 100BASEFX jsou také poněkud levnější vysílací a přijímací diody. Existují i rozhraní (nestandardizovaná) pro jednovidová vlákna. Při duplexním provozu je tak možné překlenout vzdálenost až 100km. 7.2.4.4 Aktivní prvky Zvýšení přenosové rychlosti při zachování ostatních vlastností Ethernetu (metoda přístupu CSMA/CD, formáty rámců) si pochopitelné vyžádalo určitou cenu, a tou je snížení maximálně překlenutelné vzdálenosti dané velikostí kolizního intervalu 5,12µs. Ta je u sítě s opakovači omezena na o něco více než 300 m (a to pouze při použití optického vlákna). Pokud jde o vícevstupové opakovače, rychlý Ethernet definuje dva odlišné typy. První z nich (Class I) umožňuje použití různých fyzických rozhraní na vstupech a smí být mezi stanicemi jediný. Druhý typ opakovače (Class II) pracuje se stejnými fyzickými rozhraními, mezi stanicemi smí být nejvýše dva opakovače tohoto typu, navzájem propojené na vzdálenost do 5m. Výstavba dnešních sítí rychlého Ethernetu se výhradně opírá o přepínače, která umožňuje bezkolizní duplexní provoz. Na dvoubodovém propojení přepínačů nebo na dvoubodovém připojení stanic a serverů k přepínači je tak k dispozici dvojice jednosměrných komunikačních kanálů, každý o rychlosti 100Mb/s s možností překlenout (optickým vláknem) vzdálenost do 2000 m. Příklad dnes běžné topologie sítě uvádí obr. 7.18. U přepínaných sítí s rychlostí 100 Mb/s a rychlejších se silně projevuje problém známý z oblasti přepojovaných sítí - zahlcování přepínačů při absenci mechanismů řízení toku. Nevýhodou rychlého Ethernetu zůstává stromová topologie sítě (se záložními kanály a výběrem kostry algoritmem Spanning Tree IEEE 802.14) a z ní vyplývající omezení na přenosovou rychlost. Proti jiným moderním sítím chybí synchronní nebo isochronní režim

124


výhodný pro multimediální aplikace. Při vhodném návrhu sítě (mikrosegmentaci) se však tento nedostatek nemusí vždy vážné projevit.

Obr. 7.18: Typická konfigurace přepínaného Ethernetu 7.2.4.5 Automatická konfigurace Řada standardů dovolujících přenos signálu rychlého Ethernetu, spolu s možností konfigurovat jednotlivá rozhraní do různých režimů, by značně komplikovala konstrukci sítí. Podstatné zlepšení přináší automatická konfigurace parametrů, i když v určitých situacích i ta může selhat. Automatická konfigurace zařízení propojených metalickým kabelem je založena na náhradě impulsů, které slouží u technologie 10BASE-T k testování správného propojení zařízení a případně k automatickému prohození vysílacího a přijímacího páru, posloupnostmi impulsů, které informují o schopnostech zařízení.

Obr. 7.19: Testovací pulsy (a - 10BASE-T) a identifikační posloupnosti (b) Posloupnosti identifikačních impulsů jsou přenášeny ve stejném odstupu jako původní testovací pulsy. Každá posloupnost přenáší šestnáct jednobitových parametrů zakódovaných jako přítomnost nebo nepřítomnost datových impulsů v posloupnosti. Řešení předpokládá možnost prodloužení posloupnosti o další šestnáctibitová slova. Datové pulsy jsou v posloupnosti odděleny hodinovými pulsy, celkové je základní posloupnost tvořena až 33 pulsy, obr. 7.20.


125

Obr. 7.20: Identifikační pulsy

Obr. 7.21: Význam identifikačních bitů Jednotlivé identifikační pulsy vyjadřují schopnost zařízení pracovat s určitými standardy (10BASE-T, 100BASE-TX, 100BASE-T4) a režimy provozu (poloduplex, duplex), obr. 7.21. Pro jednoznačný výběr je definována priorita standardů a režimů, současné je zajištěna kompatibilita se staršími zařízeními 10BASE-T, která identifikační posloupnosti neznají. Protože ne všechna zařízení rychlého Ethernetu musí být vybavena detekcí identifikačních posloupností, je celý mechanismus automatického nastavení doplněn o tzv. paralelní detekci. Zařízení vybavené identifikačním mechanismem musí být schopné rozpoznat typ signálu vysílaný protějškem, který nepoužívá identifikační posloupnosti, a přizpůsobit se mu. 7.2.4.6 Řízení toku Přepínače v síti Ethernet zvyšují sumární průchodnost sítě, je s nimi však spojen jeden problém: kapacity přepínačů jsou konečné a při přetížení některého z rozhraní může dojít ke ztrátám rámců, které není kam uložit. Výrazné zvýšení kapacity pamětí přitom není řešením, oddálí riziko ztrácení paketů, ale za cenu zvýšeného zpoždění rámců čekáním ve frontách rozhraní. U přepínačů s rozhraním v poloduplexním režimu se ztrátám rámců můžeme bránit odmítáním rámců, které není kam uložit. Lze toho dosáhnout dvěma metodami, které označujeme jako backpressure: - vyvoláním kolize na vstupním rozhraní přepínače, z něhož nechceme přebírat rámce, - vysíláním výplňových rámců do rozhraní, z něhož nechceme přebírat rámce.

126


Nevýhodou první metody je skutečnost, že opakovaná kolize vede na ustupování, nelze proto rychle reagovat na zlepšení situace, navíc po překročení limitu kolizí v sekvenci může dojít k indikaci výpadku linky a jejímu případnému vyjmutí z topologie sítě. Výhodou je pouze možnost rozlišit rámce, které mají být směrovány do zahlcených výstupů, od rámců, které problémy nevyvolávají. Druhá metoda dovoluje sice rychlou reakci na zlepšení situace, protějšek může začít okamžité po uvolnění média vysílat, v žádném případě však není možné diferencovat mezi rámci. Podstatným problémem obou metod je skutečnost, že zahlcení jednoho přepínače je vede k přenesení problému na jeho okolí. Důsledkem se může stát zahlcení rozsáhlejších částí sítě a v důsledku i omezení datových toků, které přes přepínač, který zahlcení vyvolal nevedly. Backpressure metody jsou použitelné pouze u poloduplexních spojů, u duplexu jsou z principu nepoužitelné. Proto byla pro řízení toku navržena podstatné pružnější metoda opírající se o přenos řídících MAC rámců - rámců PAUSE.

Obr. 7.22: Struktura řídícího MAC rámce [9] Rámce PAUSE se od datových rámců liší polem Type, ve kterém najdeme typ protokolu 0x8808, a které označuje skutečnost, že se jedná o řídící rámce MAC vrstvy. Rámce PAUSE jsou jedním konkrétním typem řídících rámců MAC, pole Opcode je u nich nastaveno na hodnotu 0x0001. Rámce PAUSE musí být směrovány všem zdrojům ve směru konkrétního rozhraní, pro tento účel je vyhrazena multicast adresa 01:80:C2:00:00:01. Alternativně lze rámce vysílat s unicast adresou konkrétního zdroje dat a tak selektivně omezit tok o sítě. Nejdůležitější údaj přenášený v PAUSE rámci je informace o době, po kterou chceme pozastavit vysílání do spoje. Tento čas se udává jako násobek doby potřebné pro vyslání 512 bitů, tato volba vychází z alternativního využití obvodů u poloduplexu používaných pro mechanismus exponenciálního ustupování. Pominou-li důvody pro pozastavení vysílání, lze rámcem PAUSE s nulovou hodnotou doby pozastavení vysílání okamžité uvolnit. U vysokorychlostních spojů (mechanismus je navržen i pro gigabitový Ethernet a technologie ještě rychlejší) je nutné brát v úvahu zpoždění linek a množství dat, které do nich mohlo být vysláno (například kapacita dvou kilometrů gigabitového spoje je 20000 bitů). U řízení toku v lokálních sítích odlišujeme dva typické scénáře. U prvního jsou špičky přenosu krátkodobé a nemají svůj zdroj převážné na jedné straně spoje. V takovém případě je rozumné dovolit symetrické řízení toku, tedy oba prvky na spoji si mohou v případě hrozícího zahlcení posílat rámce PAUSE. Alternativní asymetrické řízení toku je vhodné u koncových zařízení, hraniční přepínač sítě se omezením datového toku ze stanice může bránit přetížení sítě, stanice proti tomu nemůže ztěžovat práci zbytku sítě blokováním toku.


7.2.5

127

Gigabitový Ethernet

Technologicky se gigabitový Ethernet (IEEE 803.z) opírá o ověřené technologie vyvinuté původně pro spoje Fiber Channel. Podobné jako standard rychlého Ethernetu předpokládá gigabitový Ethernet více typů přenosového média. Základním médiem je vícevidové vlákno (62,5 µm, 50 µm) pracující na vlnové délce 850 nm (1000BASE-SX). Alternativní vlnovou délkou pro vícevidové vlákno je 1300 nm (1000BASE-LX), na této vlnové délce lze využívat i jednovidová vlákna a překlenout vzdálenosti i více než 3 km. Pro propojování zařízení na vzdálenost do 25 m lze využít kabel typu Twinax, dvoudrátové vedení s dobře definovanou impedancí proti vnějšímu plášti (1000BASE-CX). Dodatečné byl standard gigabitové Ethernetu rozšířen i na typické přenosové médium pomalejších sítí, na kabely UTP/FTP (1000BASE-T) - IEEE 802.3ab. Přehled modifikací standardu a překlenutelné vzdálenosti při duplexním provozu uvádí obr. 7.23. Standard gigabitového Ethernetu zachovává ještě představu sdíleného kanálu, a i když je takové použití zcela výjimečné, vedlo k úpravě chování vysílačů média i k úpravě formátu rámců (prodloužení signálu, vysílání bloku rámců, definice Jumbo rámců).

Obr. 7.23: Varianty gigabitového Ethernetu [8] Pro správnou činnost detektoru kolize, který je využíván u poloduplexních spojů, je požadavek, aby doba vysílání nejkratšího rámce byla delší, než dvojnásobek doba potřebná k průchodu signálu mezi dvěma neodlehlejšími body spoje (včetně zpoždění aktivních prvků). To při 1 Gb/s a délce rámce 512 bitů omezuje průměr kolizní domény na cca 25 m, tedy hodnotu nižší, než jsou vzdálenosti běžné ve strukturované kabeláži. Standard gigabitového Ethernetu se s tímto problémem vyrovnal změnou chování vysílače, který musí zůstat v


128

provozu nejen po dobu potřebnou k odeslání rámce (nejméně 64 B a preambule), ale po dobu odpovídající odeslání 512 B a preambule. Mechanismus je označován jako Carrier Extension. Při „prodlužování“ rámce jsou vysílány symboly výplně definované v kódu 8B10B.

Obr. 7.24: Prodloužení rámce pomocí výplně [8] Pouhé prodloužení doby vysílání u kratších rámců by pochopitelné vedlo ke snížení efektivity. Zlepšení lze dosáhnout tím, že vysílači umožníme odeslat sekvenci více rámců. Tento mechanismus je označován jako Frame Bursting.

Obr. 7.25: Shlukové vysílání krátkých rámců – Frame Bursting Stanice smí zahájit vysílání dalšího rámce do vypršení časovače, který definuje nejkratší dobu vysílání (512 B po vyslání úvodní preambule). Jednotlivé rámce jsou přitom odděleny mezirámcovou mezerou IFG/ (InterFrame Gap) o délce 96 bitů a každý rámec začíná svou vlastní preambulí. Efekt mechanismu Frame Bursting je pro krátké rámce velmi výrazný. Zatímco pouhé prodloužení práce vysílače vede ke snížení využití kanálu na 12 %, při vysílání sekvencí rámců se můžeme vrátit k hodnotě 76 % dosažitelné na pomalejších sítích Ethernet (vliv délky preambule a mezirámcové mezery). Technologie gigabitového Ethernetu (kromě 1000BASE-T) kódují data pro přenos kódem 8B10B. Jde o kód převzatý, stejné jako další prvky řešení, ze standardu Fiber Channel. Tento kód dovoluje úplnou eliminaci stejnosměrné složky a zaručuje dostatečné množství synchronizační informace. 1000BASE-SX Přenosovým médiem je vícevidové optické vlákno 50/125 µm nebo 62.5/125 µm a vlnová délka 850 nm. Dosah je omezen disperzí vlákna. Pro vlákna s modální šířkou pásma 500MHz.km dosahuje 550m (tak zní požadavek normy, skutečná délka udávaná výrobcem konkrétního zařízení může být vyšší).


129

1000BASE-SX 1000BASE-LX Obr. 7.26: Dosahy 1000BASE-SX a LX 1000BASE-LX Alternativním optickým médiem gigabitového Ethernetu je optické vlákno využívané na vlnové délce 1310 nm, určitou nevýhodou je obvykle vyšší cena tohoto rozhraní. Standard 1000BASE-LX předpokládá využití vícevidových vláken 50/125 µm nebo 62.5/125 µm na vzdálenosti do 550 m. Při použití jednovidových vláken se lze bez větších problémů dostat až nad 5 km. Někteří výrobci nabízejí i nestandardní rozhraní, např. 1000BASE-ZX, LH, LLX. Na vlnové délce 1550nm je možné překlenout vzdálenost až 70km. 1000BASE-CX Pro propojování zařízení gigabitového Ethernetu na velice krátkou vzdálenost (jednotky metrů) lze využit, ve srovnání s optikou levnějšího přenosového média, metalického vedení označovaného jako Twinax. Jde o stíněný kroucený dvoudrát obdobný kabelu STP, ale s přesněji definovanou impedancí. Stejné jako u optického signálu je signál vystupující z kódéru 8B10B vysílán kódováním NRZI (napěťová diference na straně vysílače je 1,1 – 2,0V).

Obr. 7.27: Kabel Twinax 1000BASE- T Technologie 1000BASE-T se od ostatních technologií gigabitového Ethernetu liší způsobem kódování datového signálu. Pro přenos jsou využívány všechny čtyři páry kabelu UTP/FTP v plném duplexu, data jsou kódována kódem PAM-5 a přenášena jako pětiúrovňový napěťový signál.

Obr. 7.28: Kódování PAM-5


130

Pro přenos jednoho bajtu dat potřebujeme jedinou změnu úrovně na každém ze čtyř párů. Pro dosažení přenosové rychlosti 1000Mb/s nám postačuje modulační rychlost 125MBd. Dostatečné množství napěťových změn potřebné pro synchronizaci hodin přijímače a optimální detekci signálu zajišťuje scrambler a konvoluční kodér předcházející vlastnímu čtyřdimenzionálního PAM-5. Napěťové úrovně signálu vysílače jsou 1Vpp. Šířku pásma, potřebnou pro přenos takového signálu, je schopen poskytnout běžný kabel UTP/FTP. S ohledem na nutnost oddělit vlastní signál od signálu protějšku při duplexním provozu je však potřeba dodržet hodnoty doplňkových parametrů označovaných jako Return Loss (podíl signálu odraženého vlivem impedančních nerovnoměrností média a konektorů), ELFEXT (Equal Level Far-End Crosstalk - přeslech ze sousedního páru měřený na vzdáleném konci kabelu) a PSELFEX T (Power Sum ELFEXT - celkový přeslech z ostatních párů měřený na vzdáleném konci kabelu). Tyto parametry jsou zaručovány u moderních kabelů kategorie Cat.5e a lepších, které splňují doporučení ANSI/TIA/EIA-TSB 95 (Technical Service Bulletin). Kabeláže s takovými kabely, instalované v souladu s doporučením ANSI/TIA/EIA568-A nebo lépe ISO/IEC11801 (ten již s parametry Return Loss, ELFEXT a PSELFEXT pracuje) by měly provoz 1000BASE-T dovolit. Obrázek obr. 7.29 dokumentuje účinnost kanálového kódování. Pro přenos je potřeba prakticky stejná šířka pásma na u pomalejšího Ethernetu 100BASE-TX.

Obr. 7.29: Obsazení spektra

7.2.6

Ethernet 10 Gb/s

Modifikace technologie Ethernet na vyšší přenosové rychlosti mnohem častěji využívají plné duplexního provozu a přepojování. Jejich přenosová rychlost výrazné překračuje hodnoty potřebné většinou koncových zařízení, a spolu se schopností překlenout větší vzdálenosti (jednotky až desítky kilometrů) jsou chápány jako technologie metropolitních sítí, ale i sítí rozsáhlejších. Typickým příkladem takového posunu je zvýšení přenosové rychlosti na 10Gb/s. Tyto sítě už jsou často využívány i jako alternativa k typickým WAN technologiím. Standard desetigigabitového Ethernetu IEEE 802.3ae zahrnuje řadu variant využívajících různých přenosových kanálů. Na rozdíl od technologií pomalejších je podporován výlučně plně duplexní provoz. Metoda CSMA/CD se již nevyužívá.


131

Obr. 7.30: Optická rozhraní 10G Ethernetu Technologie gigabitového Ethernetu je použitelná jak pro velice malé sítě SAN (Storage Area Networks), tak pro klasické sítě lokální (LAN), metropolitní (MAN) a rozsáhlé (WAN). Této škále aplikací odpovídá i rozsah použitých technologií, obr. 7.30. Rozhraní –LX4 vyžívá přenos čtyřmi paralelními kanály vlnového multiplexu. Ostatní rozhraní jsou sériová, která mají dvě základní varianty. Prvou je vlastní kódování signálu optického média, druhou je využití přenosových kanálů synchronního multiplexu SDH. Nativní kódování pokrývá potřeby sítí SAN, LAN a MAN. Na krátké vzdálenosti sítí SAN (do 65 m) postačí použít vícevidová vlákna a vlnové pásmo 850 nm. Ve vlnovém pásmu 1300 nm je dosažitelná vzdálenost 300 m. Druhou hranicí jsou vzdálenosti kolem 40 km dosažitelné s jednovidovými vlákny a vlnovou délkou 1550 nm. Slučitelnost technologie desetigigabitového Ethernetu s technologiemi telekomunikačních sítí SDH zajišťuje formátování rámců Ethernetu do rámců SDH (varianta 10GBASE-SW, LW, EW). Přenosová rychlost kanálu OC-192, který může být použit pro přenos rámců desetigigabitového Ethernetu na libovolné vzdálenosti je cca 9,26 Gb/s.

Obr. 7.31: Umístění Ethernetových rámců v nákladovém prostoru rámce SDH Desetigigabitový Ethernet má definovaná i dvě metalická rozhraní. 10GBASE-CX4 je metalickou variantou rozhraní –LX4. Přenos probíhá čtyřmi kabely Twinax na vzdálenost maximálně 15m. Standard 10GBASE-T byl schválen v roce 2006. Kanálové kódování je založeno na 1G Ethernetu. Využívá kód PAM-16 (3.2b na symbol). Plné délky 100m se podaří dosáhnou s kabely CAT6 (stíněný), CAT6a (nestíněný) a CAT 7. Dosah při použití kabelu CAT6 je kolem 50m.


132 7.2.7

Napájení po Ethernetu (PoE)

Norma 802.3af zavádí možnost napájení malých zařízení (webkamery, WiFi AP, IP telefony) přímo po datovém rozvodu (kabelu UTP). Maximální příkon takového zařízení je 15W. Z důvodu omezení vlivu odporu vedení a přechodových odporů konektorů RJ-45 se používá vyšší napětí 44 – 57V. Po konverzi na 5 V ve spotřebiči získá uživatel proud cca 2,5A (při účinnosti měniče 90%). Připojená zařízení můžeme charakterizovat těmito parametry: Způsob napájení byl zvolen tak, aby se zachovala možnost používání starších síťových prvků a zároveň bylo možné použít PoE i pro 1Gb Ethernet, který využívá všech 8 žil (4 páry) vodiče CAT5e, obr. 7.32.

Obr. 7.32: Princip rozvodu napájecího napětí Pro přenos napájecího napětí jsou využívány přímo vodiče určené pro datové signály, což je dáno samotným provedením fyzické vrstvy Ethernetu. V Ethernetu jsou signály přenášeny pomocí kroucených párů, které jsou připojeny na signálové transformátory v zařízeních na obou koncích vodiče. Tyto transformátory mají na své vnitřní straně vyvedeny středy vinutí, které jsou podle původní specifikace Ethernetu spojeny přes oddělovací transformátory se zemí zařízení. Pokud však tento střed vinutí připojíme na jinou stejnosměrnou úroveň, nestane se nic jiného, než že datový signál na výstupu ze zařízení bude mít vůči zemi jinou stejnosměrnou hodnotu, neboť na druhém konci vodiče se nachází týž transformátor. Pro rozvod se tak použijí 2 páry vodičů. Díky připojení do středu vynutí nedochází k nežádoucímu stejnosměrnému sycení jádra transformátoru. IEEE802.3af specifikuje tři varianty napájení po datovém vedení: • Napájení po datových signálech z aktivních prvků – jsou využívány dva páry vodičů a napájení je připojeno na středy vinutí oddělovacích transformátorů. • Napájení po volných vodičích z aktivních prvků – napájení se rozvádí dvěma nevyužívanými páry vodičů (jen pro 10Mb a 100Mb Ethernet). • Napájení z vloženého zařízení (jednoportový injektor) – napáječ je vložen do přenosové cesty. Aktivní prvek je spojen s napáječem, který doplní napájecí napětí a znovu vyvede všechny vodiče na výstupní konektor (jen pro 10Mb a 100Mb Ethernet).


133

Obr. 7.33: Tři způsoby napájení podle 802.3af Pro snížení vlivu úbytků napětí na vedení je možné napájet koncové zařízení po všech čtyřech párech, avšak pro zachování kompatibility je třeba dodržet párování vodičů. Stávající trend prodávaných zařízení s podporou standardu PoE preferuje variantu napájení po nevyužívaných párech, které umožňuje v 10 a 100Mb sítích zachovat větší izolační pevnost (dle 802.3 1500V). Napájecí zdroj pro PoE provádí nejdříve detekci tzv. signatury, což je paralelní kombinace rezistoru 19 – 26,5kΩ a kapacity 50-120nF (pro malá napětí do 10V). Pak je při napětí 15,5-20V podle odběru proudu určena třída zařízení. Teprve pak je připojeno napětí 48V. Třídy zařízení pro PoE třída maximální příkon 0 15,4W 1 4,0W 2 7,0W 3 15,4W 4 rezerva (= tř. 0)

detekce 0 – 4mA 9 – 12mA 17 – 20mA 26 – 30mA 36 – 44mA

7.3 Propojování lokálních sítí Při použití sdíleného média lze propojit pouze omezený počet stanic. Omezení je dáno jednak délkou jednoho úseku přenosového média a také maximálním počtem opakovačů mezi


134

stanicemi. Při větších požadavcích na rozlehlost sítě, na počet stanic nebo na kombinaci různých síťových technologií se musí jednotlivé menší sítě mezi sebou propojit prvkem, který převede komunikaci z jedné sítě do sítě druhé. Sdílené médium se v dnešní době s výjimkou radiových sítí prakticky nepoužívá. Rozdělení stanic do více sítí, pokud možno tak, aby se co nejvíce přenosů uskutečnilo uvnitř sítí, dovolí dosáhnout vyšší celkové průchodnosti (zvyšuje kapacitu sítě) a nižší doby odezvy. Poruchu v jedné lokální síti lze v propojovacím prvku rozpoznat, její vliv se ve zbytku soustavy neprojeví. Izolace sítě proti poruchám v jejích částech zvyšuje spolehlivost. Provoz mezi stanicemi jedné sítě není propojovacím prvkem zbytečně do druhé sítě přenášen, propojovací prvek tak zajišťuje ochranu komunikace stanic proti odposlechu - zvyšuje bezpečnost. Stanice, které náležejí do jedné kolizní domény (soupeří o médium) vytvářejí segment sítě – jsou propojeny na úrovni fyzické vrstvy. Segment je tvořen jednotlivými úseky vedení spojenými případně opakovačem. Víceportový opakovač se nazývá rozbočovač – hub. Jednotlivé segmenty jsou propojeny mostem. Víceportový most se nazývá přepínač. V dnešní době se v případě Ethernetu používá mikrosegmentace – segment je tvořen jednou stanicí připojenou přímo k přepínači. V mikrosegmentu nemohou nastat kolize. Přepínač využívá pro svou činnost linkové (MAC) adresy. Říkáme, že propojuje segmenty na linkové úrovni (L2 switch). Takto propojeným segmentům se říká síť. Jednotlivé sítě, obecně nestejného typu, jsou propojeny pomocí směrovačů. Směrovače využívají adresy síťového protokolu (např. IP), který je provozován nad linkovými protokoly jednotlivých sítí. Soustava propojených sítí se nazývá intersíť (internet). Globální intersíť na bázi protokolu IP je pak Internet (s velkým „I“). směrovač

síť

segment

přepínač (most) síť

rozbočovač (opakovač)

mikrosegment

síť

Obr. 7.34: Propojené sítě (intersíť – internet)


135

Most / přepínač

Most je zařízení původně určené na propojení dvou segmentů sítě. Přepínač propojuje více segmentů. Je také výkonnější a implementuje více funkcí. Přepínání je realizováno pomocí HW. Z hlediska funkce není mezi mostem a přepínačem rozdíl. Most/přepínač přijímá všechny rámce z propojovaných segmentů a u každého z nich se rozhoduje, zda ho přenese do jiného segmentu, nebo zda ho bude ignorovat (adresát je v segmentu, z něhož byl rámec přijat). Při rozhodování se most řídí MAC adresou příjemce a směrovacími tabulkami, ve kterých má uloženy informace o rozmístění stanic v sítích připojených k mostu. Adresu MAC (a pochopitelné ani v MAC rámci přenášená data) běžný most nemění. Lze ho tedy použít pro propojení sítí respektujících jeden formát rámců, a lišících se nejvýše médiem. Pozn.: Mosty mohou brát v úvahu při svém rozhodování o tom, zda rámec přenést, i další informace, například typ rámce Ethernetu, adresu odesílatele nebo adresáta. Pak mluvíme o selektivní filtraci, produkty jednotlivých výrobců se v této oblasti značné liší. Mohou existovat i prvky, které propojují sítě s různým formátem rámců ale se stejnou adresací (např. Ethernet, IBM Token Ring a FDDI). Ty jsou označovány jako translační mosty (translation bridges). Tabulky mostu by mohly být statické, definované například správcem sítě. Každé doplnění stanice nebo přemístění stanice mezi sítěmi, by pak vyžadovalo zásah správce sítě. Výhodnější je, může-li si most vytvářet směrovací tabulky během své práce sám. Most, který takto pracuje, označujeme jako transparentní. Modifikování směrovacích tabulek je založeno na metodě zpětného učení. Každý rámec sítě má ve své hlavičce uloženu MAC adresu odesílatele. Most si informaci o odesílající stanici paketu ukládá do směrovací tabulky, později ji využívá při převzetí rámců pro tuto stanici. Funkce transparentního mostu je definována normou IEEE 802.1; most pracuje na následu jiclm principu: 1. Sleduje veškerý provoz v segmentech, které propojuje. Vede si evidenci stanic, jejichž adresy jsou uvedené jako adresy odesílatele. Tato evidence má formu směrovací tabulky (Forwarding Database). Pro každou adresu, která se objevila v poli odesílatele rámce, je ve směrovací tabulce uvedena síť, ze které zpráva s touto adresou přišla. Ukládaní do tabulky je označováno jako učení. 2. Na každou zprávu, která je přijata mostem z některé připojené sítě, most reaguje některým ze tří způsobů: • Zpráva určená pro stanici, o níž most ví, že leží ve směru, odkud byla zpráva přijata, je zahozena. • Zpráva určená pro stanici, o níž most ví, že leží v jiném segmentu síti, než ze které byla zpráva přijata, je mostem převedena do tohoto segmentu. • Zpráva určená všem stanicím (broadcast) nebo zpráva určená stanici, kterou most dosud nezná, je rozeslána do všech směrů, kromě směru, ze kterého přišla. Moderní přepínače kromě své základní funkce implementují řadu přídavných funkcí (viz další kapitoly). Obsahují také WWW, resp. terminálové rozhraní pro správu. Rozsah paměti MAC adres je řádu tisíců na jeden port. Na trhu jsou i zařízení, která kombinují funkci přepínače a směrovače. O technice přepínání blíže pojednává kap. 7.2.3.

136


7.3.1.1 Protokol Spanning Tree Transparentní most pracuje pouze v sítích se stromovou strukturou, v níž uzly reprezentují mosty a hrany reprezentují propojované lokální sítě. V propojených sítích nesmí vzniknout uzavřená smyčka. Pokud potřebujeme propojit sítě více mosty a zajistit tak odolnost proti jejich výpadkům, musí být tyto mosty schopné vypnout některá svá rozhraní a vytvořit tak stromovou strukturu. Postup, kterého mosty při takovém omezování topologie využívají, je označován jako Spanning Tree algoritmus.

Obr. 7.35: Spanning-Tree algoritmus [8] Blokované porty mostů zůstávají v záloze pro případ výpadku některého mostu nebo sítě. Algoritmus výběru kostry se opírá o jednoznačnou číselnou identifikaci mostů, distribuovaný výběr fungujícího mostu s nejnižší identifikací a o nalezení stromu nejkratších cest s vybraným uzlem jako kořenem. Je standardizován specifikací IEEE 802.1d/x. Vlastní algoritmus výběru kostry ilustruje obr. 7.35. Opírá se o jednoznačnou identifikaci mostu, opřenou např. o výrobcem přidělené adresy řadičů Ethernetu a o cenu výstupu (ohodnocení výstupních portů). Služební rámce, které si mosty si mezi sebou vyměňují při konstrukci kostry, mají zvláštní formát a jsou označovány jako BPDU (Bridge Protocol Data Unit). Prvním krokem algoritmu je výběr kořene. Každý z mostů může rozeslat rámec BPDU s vlastní identifikací do všech připojených sítí. Každý z mostů tak může zjistit, zda je jeho identifikace nejnižší a je tedy kořenem kostry. Most - kořen kostry rozesílání rámců BPDU periodicky opakuje. Kořen kostry v rozesílaném rámci uvádí jako cenu cesty cenu přiřazenou příslušnému výstupu. Rozhraní, na kterém most sousedící s kořenem přijímá jeho rámce BPDU, označujeme jako root port (na obr. 7.35 je toto rozhraní označeno písmenem R). K údaji o ceně cesty v rámci BPDU most přičte cenu svého výstupu a rámec vyšle dál. Jako výsledek opakování tohoto kroku může každý z mostů určit svůj root port. Pro každý z propojovaných segmentů sítí je dále potřeba určit most s nejnižší cenou cesty ke kořeni kostry. To je snadné vzhledem k údaji o ceně cesty v rámcích BPDU. Rozhraní tohoto mostu označujeme jako vyhrazené (Designated), označeno písmenem D. Rozhraní R (root port) a D (designated port) vytvářejí kostru, ostatní rozhraní přecházejí do blokovaného stavu a neúčastní se přenosu datových rámců (rámce BPDU však přijímají a


137

vysílají). Přechod mezi blokováním portu a jeho běžnou činností je poněkud komplikován nutností zabránit nekorektnímu přenosu datových rámců při změnách topologie. Přechod z provozního stavu do blokování proběhne okamžité, přechod z blokovaného stavu do provozního stavu je řízen časovačem. Rozesílání rámců BPDU kořenem stromu je periodické (perioda je označována jako Hello Time). Při běžném provozu mosty evidují, že je vše v pořádku; výpadek některého z mostů nebo portů může vyvolat změnu root portu a vyhrazeného rozhraní. Protokol Spanning Tree (STP) podle normy 802.1d je schopen rekonfigurovat síť po změně do 30 – 40 sekund. Norma 802.1w definuje rychlejší variantu – Rapid Spanning Tree (RSTP), která je schopna obnovit spojení do 2 – 3 sekund. 7.3.1.2 Virtuální sítě Virtuální sítě (VLAN - Virtual LAN) je tvořena skupinou stanic, mezi kterými je zajištěna komunikace. Mechanismus virtuální sítě zajišťuje, že data příslušející komunikaci stanic určité skupiny se nedostanou ke stanicím, které do skupiny nepatří. VLAN je logická sít nezávislá na fyzickém rozmístění.

Obr. 7.36: Virtuální sítě [9] Technické řešení virtuální sítě zahrnuje dvě roviny. VLAN v rámci přepínače znamená definici skupiny portů, mezi kterými mohou být předávány rámce. Při propojení dvou a více přepínačů jsou rámce vyslané stanicí příslušející k určité skupině ve vstupním přepínači označeny identifikátorem skupiny a přenášeny přepínanou sítí podobné, jako rámce neoznačené. Výstupní přepínače sítě před předáním rámce koncovému zařízení zkontrolují, zda toto zařízení přísluší ke skupině určené identifikátorem skupiny přenášeným v označeném rámci. Pokud zjistí shodu, jednoduše označení z rámce odstraní a rámec předá adresátovi. V opačném případě není rámec koncovému zařízení doručen a přepínač ho zahodí. Značkování rámců si vyžádalo změnu formátu, což řeší normy 802.1q a 802.1p. Obě využívají společný formát rámce, rozšíření rámce zahrnuje jednak identifikátor virtuální lokální sítě, jednak údaj o prioritě datového toku (802.1p).

Obr. 7.37: Formát rámců 802.1p/q [9] Pro identifikaci skutečnosti, že rámec je vybaven údajem podporujícím VLAN (tag) slouží šestnáctibitový identifikátor protokolu VLAN - TagID s hodnotou 0x8100. Následující

138


šestnáctibitové pole obsahuje tříbitový údaj o prioritě P, který dovoluje rozlišit osm úrovní priority. Přepínač podporující doporučení IEEE 802.1p pak upřednostňuje při zařazování do front portů rámce s vyšší prioritou, určitým druhům provozu (například hovorové služby, přenos videosignálu) tak lze zajistit potřebnou kvalitu provozu (doručení do časového limitu). Virtuální lokální sítě jsou rozlišeny dvanáctibitovým identifikátorem VLAN ID, což dovoluje vytvořit na jedné fyzické LAN až 4096 LAN virtuálních. Příznak C (Canonical Format Identi fier) má pro Ethernet hodnotu 0. Určitým problémem je zajištění komunikace mezi virtuálními LAN. Směrovač propojující logické podsítě postavené na VLAN by bez vestavěné podpory IEEE 802.lq musel být připojen ke dvěma nebo více portům sítě. Podpora standardu IEEE 802.lq přímo ve směrovači dovoluje pracovat přímo s rámci VLAN. Směrovač je pak do fyzické sítě připojen jediným rozhraním. VLAN sítě lze vytvářet podle několika síťových znaků: • podle portů přepínače, • podle MAC adresy, • podle síťové adresy nebo protokolu, • podle skupinové adresy (multicast). Nejčastější případ je definice členství ve VLAN je podle portů přepínače. Správce přiřadí port do určité VLAN. Při eventuelním přesunu stanice se musí přepínač překonfigurovat. Rozdělení stanic do virtuálních sítí podle fyzické adresy může být proti tomu užitečné pro sítě podporující mobilní koncová zařízení. Ta se pak mohou pohybovat v dosahu celé fyzické LAN. V multiprotokolových sítích mohou být přiřazeny uzly do jednotlivých VLAN podle provozovaných síťových protokolů nebo např. v sítích s protokolem TCP/IP podle adresy podsítě. Ačkoliv se zde pracuje s informacemi síťové vrstvy, je důležité si uvědomit, že se nejedná o jejich využití pro směrování. I když přepínač musí prohlédnout paket k určení IP adresy a tím členství ve VLAN, neprovádí žádné směrovací výpočty. Přepínač nevyužívá směrovací protokoly a i na VLAN definovanou podle informací ze třetí, síťové vrstvy se musíme dívat jako na síť s plochou topologií. Implicitně všechny mosty a přepínače podporují v základní filtrační službě přepínání rámců se skupinovými adresami, na všechny aktivní porty (Flooding), podobně jako je tomu u veřejných rámců (broadcast). Nárůst používání multimediálních video-konferenčních služeb, potom logicky vedl k zahlcování přepínaných sítí, šířením multicast provozu na všechny porty sítě. Standard IEEE 802.1d zavádí rozšířenou filtrační službu umožňující předávání multicast provozu jen pro registrované uzly sítě. Filtrační tabulka je doplněna o nový typ položek GPE (Group Registration Entries), obsahujících přiřazení portů ke skupinovým adresám. Přiřazení je realizováno procesem registrace. Rámec, který je odeslán na vybranou skupinovou adresu, se přenese jen na ty porty mostu, na kterých jsou již registrováni členové této skupiny. Registrace členů skupiny a automatizovaná údržba rozšířených filtračních tabulek je zabezpečována protokolem GMRP (GARP Multicast Registration Protocol) v rámci generického protokolu GARP. Protokol používají koncové uzly a přepínače sítě (mosty) na registraci skupinových adres podle požadavků aplikační vrstvy (např. videokonferenční služby). Pomocí služby "Join" se registrují k této adrese koncové uzly požadující konkrétní aplikační službu. Přepínač provede protokolem GMRP propagaci registrace na všechny porty. Další šíření skupinových


139

rámců probíhá jen na registrovaných portech. Skupinu je možné pomocí služby „Leave“ opustit.

join/leave

Obr. 7.38: Skupinové vysílání v LAN 7.3.1.3 Stanovení priority v přenosu rámců

Obr. 7.39: Třídy CoS [4] Požadavky na přenos multimediálních služeb, obrazu a hlasu si vyžádaly úpravu standardu IEEE 802.1d. Po poslední revizi z roku 1998 je jeho přímou součástí také doporučení IEEE802.lp s podporou prioritního režimu zpracování rámců přepínači a mosty sítí LAN podle jejich přiřazení k dané třídě kvality služby. Cílem přidělení priority jednotlivým rámcům je dosažení definované propustnosti, zaručené šířky pásma a maximálního zpoždění rámců (latency) pro specifickou třídu kvality služby (CoS). Celkově zavádíme 7 tříd kvality služeb a jim odpovídajících priorit, obr. 7.39. Princip činnosti při stanovení priority v přenosu u přepínačů či mostů je založen na použití několika samostatných front (max. 7) přiřazených prioritám na straně výstupních portů. Most do nich ukládá rámce podle jejich priority ze záhlaví IEEE 802.1q. Rámce jsou odesílány na výstupní port tak, aby se nepřekročily definované parametry třídy služby (např. zpoždění 10 ms). Pro jednu frontu je režim bez stanovení priority. Při použití dvou front mohou být třídy přiřazeny takto: 1-BE,EF,BK; 2-VO,VI,CL,NC. Pro tři fronty následovně 1BE,EF,BK; 2-VI,CL 3-V0, NC. 7.3.1.4 Agregace portů Technika agregace portů 802.3ad (Link Aggregation Control Protocol) se používá, pokud potřebujeme zvýšit kapacitu spojení. Spočívá v přenosu dat několika paralelními kanály. Na obr. 7.40 je ukázáno propojení dvou přepínačů několika linkami. Porty, které takto

140


propojujeme, musí být patřičně nakonfigurované, jinak zareaguje protokol Spanning Tree a zůstane aktivní pouze jedna linka. Skupina „paralelních“ linek se nazývá trunk. Porty, které budou tvořit trunk, musí správce nakonfigurovat. Alternativně lze použít protokol LACP, který umožňuje automatické zformování trunku při vícenásobném propojení dvou přepínačů. Při provozu pak přepínač rozkládá zátěž mezi jednotlivé linky tvořící trunk.

trunk

Obr. 7.40: Agregace portů

7.4 Shrnutí kapitoly 7 Ethernet se postupně stává technologií pro metropolitní i globální sítě. Komunikační rychlost je podle varianty od 10Mb/s do 10Gb/s. Dnes se výhradně používají tzv. přepínače jako aktivní prvky. Ethernet má tedy charakter standardní sítě typu bod-bod s přepínáním paketů (zde rámců). V rámci linkové vrstvy se neprovádí směrování. Přepínače používají metodu zpětného učení, která vyžaduje stromovou strukturu sítě (bez smyček). Fyzická topologie může smyčky obsahovat, avšak algoritmus Spanning-Tree nadbytečné linky odpojí. Při případné poruše některé aktivní linky jsou tyto odpojené úseky aktivovány, by bylo obnoveno spojení.


141

8 Multimediální síťové aplikace Cíle kapitoly: • Objasnit základní principy multimediálních aplikací pro TCP/IP. • IP telefonie. • QoS v sítích IP

8.1 Základní principy Multimediální aplikace (přenos videa a audia) přinášejí specifické požadavky na síťovou infrastrukturu u sítí s přepínáním paketů. Tyto aplikace jsou citlivé na zpoždění vznikající při přenosu, respektive na proměnlivost zpoždění. Oproti klasickým datovým přenosům jsou multimediální přenosy méně citlivé k občasné ztrátě dat. Za multimediální službu nelze považovat prosté stažení avi nebo mpg souborů z internetu. V tomto případě se jedná o klasický datový přenos. V zásadě můžeme rozdělit aplikace do tří základních skupin: • Distribuce „uložených“ dat. Jedná se o službu, kdy jsou multimediální data uložena na centrálním serveru, odkud je uživatelé mohou „přehrávat“. Tato služba je podobná klasickému přehrávání z CD nebo DVD. U provedení příkazů pro zastavení přehrávání nebo skoky v médiu se toleruje doba odezvy řádově v sekundách. Další typickou vlastností je, že klienti připojení k serveru získávají data z různých míst multimediálního souboru. • Distribuce živých dat (streaming), např. živé televizní nebo rozhlasové vysílání. Jedná se o vysílání v reálném čase, tudíž klienti nemohou „převíjet“ záznam. Pro distribuci dat ke klientům je možné využít techniku IP broadcastu. Zpoždění, které vzniká přenosem, může být v řádu až do 10 sec. Z hlediska kvality služby hodnota zpoždění není kritická. • Přenosy v reálném čase – audio a video konference. V dnešní době populární aplikací je IP telefonie. Pro služby v reálném čase je kritické zpoždění vznikající při přenosu. Např. pro telefonní hovor zpoždění přesahující 400 ms způsobí podstatné zhoršení kvality (zpoždění vnáší velmi rušivý prvek do hovoru). Síť IP byla původně určená pouze pro datové přenosy, kde otázky časování nejsou podstatné. Internet byl vystavěn na principu best – effort, který sice vede na efektivní využívání přenosových prostředků, ale nezabraňuje přetížení sítě, které se projevuje zvýšením ztrátovosti paketů. Využití pro multimediální přenosy vyžaduje implementaci dodatečných mechanismů: Rezervace zdrojů Jedná se v podstatě o techniku virtuálních kanálů. Před zahájením samotného přenosu musí být mezi koncovými stanicemi zřízen virtuální kanál. Na všech směrovačích, které tento kanál vytvářejí, dojde k rezervaci kapacity na základě požadavku vzneseném při otvírání kanálu. Do této kategorie patří technika integrovaných služeb (IntServ), kterou vyvíjí organizace IETF. Jedná se o řešení, jehož implementace je velmi nákladná, protože musí být provedena ve všech směrovačích.


142 Prioritní mechanismy

Jednotlivým přenosům je přiřazena různá priorita (multimédiím vyšší, datovým přenosům nižší). Dostupná přenosová kapacita je potom rozdělovaná podle priorit. Tento mechanismus v zásadě nevyžaduje sestavování spojení. Do kategorie prioritních mechanismů patří technika diferencovaných služeb (DiffServ) organizace IETF, technika MPLS a technika SBM (Subnet Bandwidth Management). Předimenzování spoje Klasická síť typu best – effort poskytuje uspokojivé služby, pokud je využívána na zlomek své kapacity. Řešení, které je použitelné v případě lokálních sítí, spočívá v dostatečném dimenzování infrastruktury. Tato metoda je však nepoužitelná pro rozsáhlé sítě (WAN) z ekonomických důvodů.

8.2 Přenosy uložených médií 8.2.1

Architektura

Na obr. 8.1 je model komunikace typu klient – server. Klient (různé typy softwarových přehrávačů) poskytuje funkčnost podobnou klasickému DVD přehrávači. Uživatel toleruje rychlost odezvy na příkazy v řádu sekund. Komunikaci můžeme rozdělit na dvě části: přenos řídících příkazů a přenos vlastních multimediálních dat. Pomineme-li různá uzavřená firemní řešení, tak pro řízení přenosu se používá protokol RTSP (Real-Time Streaming Protocol). Pro přenos multimediálních souborů potom protokol RTP (Real-Time Protocol).

Obr. 8.1:

Přenosy uložených médií [1]

Na straně klienta musí dojít k odstranění časové nepravidelnosti (jitteru) a eventuelní korekci chyb. V případě přehrávání uložených médií je možné použít jak dopřednou korekci (FEC), tak i metody ARQ. Na obr. 8.2 je znázorněn proces odstranění časové nepravidelnosti při přenosu. Předpokládejme, že je použita metoda komprese s konstantním datovým tokem. Datový proud je rozdělen do paketů stejné velikosti. Generování dat je tak znázorněno schodovitou křivkou na obr. Při přenosu dochází ke zpoždění proměnné délky. Na straně klienta tedy vzniká nepravidelnost v dodávce dat. Na vyrovnávání této nepravidelnosti je třeba využít vyrovnávací paměť. Dekomprese (přehrání) jednotlivých paketů bude zpožděno


143

constant bit rate video transmission

variable network delay

client video reception

constant bit rate video playout at client

buffered video

Cumulative data

oproti jejich příjmu. V případě přehrávání uložených dat se jedná o zpoždění typicky 2 – 5 sec. Velikost zpoždění spolu s průměrnou přenosovou rychlostí určují požadavky na velikost vyrovnávací paměti.

client playout delay

time

2 - 5 sec

Obr. 8.2:

8.2.2

Vyrovnání časové nepravidelnosti u klienta [1]

Protokol RTSP

Protokol je určen pro řízení přehrávání. Neřeší vlastní přenos multimediálních dat, chybové řízení ani použité metody komprese. Je definován normou RFC 2326. Jako transportní vrstvu může použít TCP i UDP. Multimediální obsah je popsán prostřednictvím meta souboru, obr. 8.3. Přehrávání multimediálního obsahu bývá často kombinováno s www prohlížečem. Pomocí metody GET protokolu HTTP je meta soubor přenesen ke klientovi. Klient (přehrávač na základě informací z meta souboru naváže spojení s media serverem. Twister <session> <switch>

Obr. 8.3:

Metasoubor s popisem obsahu

V příkladu meta souboru je pomocí odkazů rtsp:// definována adresa příslušných mediálních souborů. Jsou zde nabídnuty dvě alternativní audio stopy, ze kterých si může klient vybrat. U každého souboru je uvedena i použitá metoda komprese. Komunikace protokolem RTSP je založena na podobném principu jako u protokolu HTTP, s tím rozdílem, že se jedná o komunikaci stavovou. Používají se textové příkazy. Spojení začíná metodou SETUP, ve které klient oznámí, na kterém portu očekává


144

multimediální přenos protokolem RTP. Příkaz PLAY slouží k iniciaci vlastního přehrávání. Server začne zasílat data na port definovaný v metodě SETUP. Příkaz PAUSE dovoluje zastavit přehrávání. Příkaz TEARDOWN ukončuje přenos. V uvedeném příkladu jsou multimediální data přenášena protokolem RTP. Není to však jediná možnost. Protokol RTSP je možné využít i s jinými přenosovými protokoly. C: SETUP rtsp://audio.example.com/twister/aud Transport: rtp/udp; compression; port=3056; S: RTSP/1.0 200 1 OK Session 4231 C: PLAY rtsp://audio.example.com/twister/audio Session: 4231 Range: npt=0C: PAUSE rtsp://audio.example.com/twister/aud Session: 4231 Range: npt=37 S: 200 3 OK

Obr. 8.4:

8.2.3

Příklad komunikace protokolu RTSP [1]

Distribuční sítě

Existence jediného distribučního místa pro uložená multimediální data přináší problémy se zatížením sítě. Vzhledem k tomu, že data jsou ke klientům přenášena z různých míst v záznamu, není možné použít techniku broadcastu. Řešení spočívá ve vytvoření více distribučních míst, na kterých je udržována přesná kopie dat s centrálním úložištěm. Distribuční servery jsou umístěny „blíže“ k zákazníkům. Může se jednat o blízkost geografickou i z hlediska topologie sítě. Distribuční sítě jsou v dnešní době využívány např. i k distribuci update softwarových produktů. Z hlediska klienta by byla nepraktická nutnost nastavovat adresu „nejbližšího“ serveru. Jednou z běžně využívaných metod je kombinace distribuční sítě s DNS. Servery tvořící distribuční síť jsou definovány v jedné DNS zóně. Autoritativní server poskytuje odpověď na žádost o překlad podle IP adresy tazatele. Existuje tedy jediné doménové jméno. Konkrétní IP adresa pak závisí na geografické poloze klienta. HTTP request for www.foo.com/sports/sports.html

Origin server

1 2 3

DNS query for www.cdn.com

CDNs authoritative DNS server HTTP request for www.cdn.com/www.foo.com/sports/ruth.mpg

Nearby CDN server

Obr. 8.5:

Využití DNS v distribuční síti [1]


145

8.3 Multimediální přenosy v sítích typu best-effort 8.3.1

Kvalita služeb

V telekomunikačních sítích je primárním parametrem kvalita služby (QoS). V datových sítích na bázi IP je však primárním parametrem poskytnutí dané služby. Data jsou zpracovávána podle modelu best-effort: jednotné zacházení se všemi pakety. Obecně je QoS definováno v doporučení ITU-T I.350, a lze jej rozdělit na základní pojmy kvalita služby a výkonnost sítě [11]. • Kvalita služby (Quality of Service, QoS) se zabývá popisem vlastností sítě z pohledu uživatele. Kvalita služby je obecně definována jako celkový efekt výkonnosti služby, který určuje stupeň uspokojení uživatele služby. • Výkonnost sítě (Network Performance, NP) se zabývá popisem vlastností sítě z pohledu provozovatele sítě. Výkonnost sítě je definována jako schopnost sítě nebo její části poskytovat funkce vztahující se ke komunikaci mezi uživateli. Výkonnost sítě je považována za technickou část kvality služeb. Pro popis kvality služeb a výkonnosti sítě slouží zvolená množina parametrů. Z primárních parametrů, tj. na sobě nezávislých, jsou odvozovány parametry sekundární. • Primární parametr je parametr, který je určen na základě přímého pozorování referenčních událostí na přístupovém bodu služby nebo prvcích komunikačního rozhraní. • Sekundární parametr je určen na základě pozorovaných hodnot jednoho nebo více primárních parametrů a rozhodovacích úrovní pro daný primární parametr. Sekundární parametry popisují události, které vznikají, pokud hodnota primárního parametru překročí prahovou hodnotu (např. stavy dostupnosti a nedostupnosti služby) Kvalita služeb IP sítí je definována doporučením ITU-TY.1540. Primární parametry definovány pro datovou sít s IP protokolem jsou: • Zpoždění přenosu paketů (IP Packet Transfer Delay, IPTD) - je čas, který uplyne od odeslání paketu zdrojovým uzlem po její přijetí na uzlu cílovém; zahrnuje zpoždění na přenosové trase a na zařízeních, které jsou její součástí. Z IPTD je možné určit průměrné zpoždění přenosu paketů a změnu zpoždění. • Poměr chybných paketů (IP Packet Error Ratio, IPER) - poměr počtu chybně přenesených paketů k celkovému počtu přenesených paketů ze zvolené množiny paketů. IPER =

•

• •

(8.1)

Poměr ztracených paketů (IP Packet Loss Ratio, IPLR) - poměr počtů ztracených paketů k počtu přenášených paketů ze zvolené množiny paketů. IPLR =

•

Nerr NOK + Nerr

N LOST N trans

( 8.2 )

Poměr nežádoucích paketů - poměr počtu nevyžádaných paketů přijatých během daného časového úseku dělený dobou časového úseku. Propustnost paketů (IP Packet Throughput, IPPT) - počet úspěšně přenesených paketů během definovaného časového úseku dělený dobou časové ho úseku. Propustnost oktetů (Octet Based IP Packet Throughput, IPOT) - počet oktetů v paketech, které byly úspěšně přeneseny během definovaného časového úseku dělený dobou časového úseku.


146

Minimální počet paketů, které by měly být zahrnuty do vyhodnocování dostupnosti služby, nebyl definován a je stále ve stavu výzkumu. Minimální doba trvání, po kterou je vyhodnocována dostupnost služby byla provizorně zvolena na 5 minut. Tab. 1:

Třídy služeb podle ITU-T Y.1541

U pper bound on m ean IP T D U pper bound o n 1 -1 0 - 4 q u a n tile o f IP D V -m in . IP D V U pper bound o n IP L R U pper bound o n IP E R

C la s s 0 re a l-tim e

C la s s 1 in te ra c tiv e

150 m s

400 m s

C la s s 2 C la s s 3 nonin te ra c tiv e 1 s U n s p e c ifie d

50 m s

50 m s

1 s

U n s p e c ifie d

0 .0 0 1

0 .0 0 1

0 .0 0 1

U n s p e c ifie d

0 .0 0 0 1

0 .0 0 0 1

0 .0 0 0 1

U n s p e c ifie d

Jako modelový příklad multimediální aplikace si uveďme IP telefonii. Předpokládejme, že hlasový signál je kódován metodou PCM (tj. bez komprese). Data jsou generována rychlostí 8 kB/s. Datový proud je přenášen v paketech délky 160 B. Průměrná opakovací perioda paketů bude tedy 20 ms. Při přenosu dochází ke ztrátě paketů a přenosové zpoždění je proměnné v důsledku časově proměnné zátěže směrovačů. V následujících odstavcích budou popsány typické techniky, které uvedené problémy řeší pouze na straně klienta. Nevyžadují tedy zásah do síťové infrastruktury.

8.3.2

Odstranění jitteru

Celkové zpoždění při přenosu vzniká jako akumulace zpoždění ve směrovačích a přenosových trasách. Proměnlivá složka zpoždění vzniká ve vyrovnávacích pamětech směrovačů, kde závisí na aktuální intenzitě provozu. Z hlediska koncového bodu toto proměnlivé zpoždění vystupuje jako náhodná veličina, kterou můžeme charakterizovat střední hodnotou a rozptylem, obr. 8.6. pdft

rozptyl

Obr. 8.6:

t střední hodnota Přenosové zpoždění jako náhodná veličina

Pro přenos multimediálních dat v reálném čase se preferuje transportní protokol UDP. Tento protokol je nespojovaný a nespolehlivý. Na rozdíl od TCP neobsahuje mechanismus pro snížení odesílací rychlosti v případě přetížení sítě. Ztráta paketů může vyvolat v případě


147

TCP pokles rychlosti pod mez danou použitou kompresí. Došlo by tak k úplnému přerušení komunikace. Metoda ARQ zabudovaná v TCP sice nahradí ztracené pakety, ale ty budou k dispozici s časovým zpožděním, které neumožní jejich přehrání. Datagramy UDP musejí být doplněny sekvenčními čísly pro detekci ztráty a časovými razítky pro určení přesné polohy na časové ose. Odstranění jitteru na straně klienta může být provedeno pouze využitím vyrovnávací paměti, tj. zpožděním přehrání. Na obr. 8.7 je časový diagram znázorňující proces zpracování dat u klienta. Předpokládejme, že je paket vygenerován v čase ti a přehrán v čase ti+q. Při volbě q se řeší dva protichůdné požadavky. Z hlediska odstranění časové nepravidelnosti je vhodné zvolit q co nejvyšší. Z hlediska multimediálního přenosu v reálném čase je třeba volit naopak q co nejnižší. Např. v případě IP telefonie celkové zpoždění nad 400 ms způsobuje degradaci kvality hovoru. Na obrázku jsou vyznačené dva případy volby q. V případě q1 je zpoždění příliš nízké pro odstranění časové nepravidelnosti. I když uvažujeme bezztrátový přenos, tak na obrázku je ukázáno, že může nastat situace, kdy paket dorazí příliš pozdě a již nemůže být přehrán (klient pravděpodobně provede interpolaci dat). Dochází tak k faktické ztrátě paketů. Volba q2 je pak dostatečná pro odstranění přenosového zpoždění. packets

loss

packets generated packets received

playout schedule p' - r playout schedule p-r

time r p

Obr. 8.7:

p'

Zpracování dat na straně klienta [1]

Zpoždění závisí mimo jiné na počtu směrovačů a délce vedení mezi komunikujícími stranami. V případě pevného zpoždění by bylo nutné zvolit hodnotu, která bude vyhovovat nejhoršímu možnému případu síťové komunikace. Tato hodnota bude pravděpodobně tak vysoká, že např. způsobí degradaci kvality hovoru. Proto je žádoucí, aby zpoždění na straně klienta bylo adaptivně měněno podle aktuálních charakteristik komunikace. Metoda je založena na odhadu střední hodnoty a rozptylu zpoždění na základě analýzy časových razítek v paketech. Označme ri okamžik přijetí i-tého paketu. Průměrné zpoždění je potom dáno jako plovoucí průměr d i = (1 − u )d i −1 + u (ri − ti ) , (8.3) kde u je pevně zvolená konstanta, např. u = 0,01. Odhad střední hodnoty dává větší váhu aktuálním datům. Rozptyl zpoždění je pak odhadován podle vztahu vi = (1 − u )vi − 1 + u ri − ti − d i , (8.4) Okamžik přehrání paketu je určen podle vztahu pi = ti + d i + Kvi , (8.5) kde K je kladná konstanta, např. K = 4. Průměrné zpoždění ve vyrovnávací paměti je potom dáno jako


148 qi = di + Kvi .

8.3.3

(8.6)

Potlačení vlivu ztráty dat

Metody ARQ nejsou vhodné pro aplikace pracující v reálném čase. Ztrátu paketu řeší jeho opětovným vysláním. To ale značně narušuje pravidelnost dodávky dat. Ztracený paket bude sice k dispozici, ale s velkým zpožděním. Jak obrazový, tak zvukový signál vykazují značnou nadbytečnosti. Na straně příjemce je možné tedy tolerovat jistou míru ztráty dat. Chybějící úseky se nahradí např. opakováním předchozích nebo interpolací. Další možností je použít metody dopředné korekce, resp. prokládání. Je třeba si uvědomit, že při přenosu dochází ke ztrátě celých paketů. Příjem poškozeného paketu je velmi málo pravděpodobný. Dopředná korekce proto musí zajistit obnovení paketu nebo jeho části a nikoli jen obnovu jednotlivých bitů. 8.3.3.1 Pakety kontrolních součtů V RFC 2733 je definována metoda použitelná pro přenos paketů stejné délky. Ke každým n přeneseným paketům je sestrojen jeden paket, jehož každý bit je tvořen součtem (modulo 2) příslušných bitů n původních paketů. pn + 1 = p1 ⊕ p 2 ⊕ ..... ⊕ pn . (8.7) Tato metoda umožňuje plně obnovit jeden paket z n+1 přenesených. Uvažujme např. skupinu 4 paketů p1 – p4. K nim je sestrojen zabezpečovací paket p 5 = p1 ⊕ p 2 ⊕ p 3 ⊕ p 4 . (8.8) Při přenosu došlo ke ztrátě p2. Z vlastností součtu mod 2 (logická operace XOR) přímo vyplývá p 2 = p1 ⊕ p 2 ⊕ p 3 ⊕ p5 . (8.9) Tato metoda zvyšuje požadavek na přenosovou rychlost o 1/n. Navíc je na straně příjemce nutné k obnově dat uložit všech n+1 paketů. Kromě nároků na paměť to prodlužuje i zpoždění zpracování dat na straně příjemce.

Obr. 8.8:

Využití záložního datového toku [1]


149

8.3.3.2 Záložní datový tok Jinou metodou je paralelní vysílání hlavního datového toku a záložního toku (vyšší komprese, nižší rychlost). Na obr. 8.8 je ukázáno schéma řazení bloků obou proudů do paketů. Záložní datový tok je zpožděn. Při eventuelní ztrátě dat je chybějící úsek nahrazen ze záložního proudu následujícího paketu. 8.3.3.3 Prokládání Smyslem prokládání je rozložit chybějící úsek do více kratších segmentů, které se na straně příjemce lépe nahrazují (interpolují). Na obr. xxx je ukázán příklad prokládacího schématu. Každý blok původního datového proudu je rozložen na n stejných úseků. Paket je sestaven např. z prvních úseků n po sobě jdoucích paketů. Další paket z druhých úseků atd. Metoda prokládání nezvyšuje požadavky na přenosovou rychlost, ale vnáší do přenosu další zpoždění nutné k sestavení původního bloku z n po sobě jdoucích paketů.

Obr. 8.9:

8.3.4

Prokládání [1]

Protokol RTP

Protokol RTP (RFC 3550) je standardním prostředkem pro přenos multimediálních dat, který využívá pro transport službu UDP. Multimediální proud je rozdělen na segmenty. Ke každému segmentu je přidána hlavička RTP a je vložen do datagramu UDP. RTP není přímo svázán s žádnou konkrétní metodou komprese, neřeší eventuelní ztrátu paketů, ani zajištěni kvality služeb. V podstatě se jedná pouze o přidání nutných hlaviček do UDP. Na obr. xxx je zobrazena hlavička RTP. Protokol UDP umožňuje broadcast.

Obr. 8.10: Hlavička RTP [1] Význam polí: • Sekvenční číslo (16b) – každý paket má sekvenční číslo o 1 vetší než předchozí. Toto pole slouží k identifikaci ztráty paketů.


150 • •

•

Časové razítko (32b) – časové razítko je odvozeno od vzorkovací periody. Čas je tedy vyjádřen jako celistvý násobek jistého časového kvanta. Synchronizační pole SSRC (32b) – identifikuje zdroj datového toku. Mezi dvěma stanicemi může být přenášeno paralelně více datových toků. Samotná IP adresa proto nestačí pro identifikaci zdroje. Hodnota SSRC je pro dané spojení generována náhodně. Typ nákladu (7b) – hodnota určuje použitou kompresi dat.

Součástí RTP je i řídící protokol RTCP (RTP Control Protocol). Každý účastník RTP spojení (a to i v případě broadcastu) vysílá pravidelně pakety RTCP. Protokol RTCP využívá číslo portu vždy o 1 vyšší než RTP. Pakety obsahují tzv. zprávy, ve kterých každý účastník informuje o počtu přijatých paketů, ztrátě dat, jitteru, apod. Odesílatel datového proudu tyto informace může využít pro optimalizaci své činnosti nebo pro diagnostické účely. Např. odesílatel může v případě zvýšené ztrátovosti paketů přejít na nižší přenosovou rychlost, tj. použít metodu s vyšší kompresí. Každý paket RTP obsahuje pole indikující typ komprese. Změnu je tedy možné provést během přenosu. Jiné použití spočívá v časové synchronizaci audio a video proudu v případě, že se přenášejí samostatně. Časová razítka udávají vždy jen relativní čas ve vztahu ke vzorkovací periodě. Ve zprávách RTCP je potom vazba mezi časovým razítkem a reálným časem. Tuto informaci využije příjemce pro přesnou synchronizaci datových toků.

Obr. 8.11: Zasílání zpráv RTCP [1]


151

Jistý problém představuje RTCP v případě multicastu. Agregovaný datový tok velkého množství klientů může překročit datový tok vlastního RTP proudu. Protokol RTCP se snaží limitovat přenosovou rychlost tak, aby nepřekročila 5 % celkové kapacity spojení.

8.4 IP telefonie – protokol SIP 8.4.1

Protokol SIP

IP telefonie přestavuje jednu z velmi perspektivních aplikací. Existuje celá řada komunikačních protokolů jak uzavřených (Skype),tak i otevřených (SIP, H.323, aj.). Kromě unifikace hlasových a datových služeb IP telefonie umožňuje mobilitu koncových uživatelů. Uživatel, resp. jeho telefonní číslo není vázáno na konkrétní IP adresu. Jedním z velmi rozšířených protokolů je SIP (Session Initiation Protocol, RFC 3261). SIP je pouze signalizační protokol, přenos hovorových dat probíhá nejčastěji protokolem RTP. SIP používá nejčastěji port 5060 a jako transportní službu může využívat jak UDP, tak TCP.

Obr. 8.12: Navázání přímého spojení [1] Na obr. 8.12 je časový diagram komunikace v případě, že je známa IP adresa volaného. Spojení začíná zprávou INVITE zaslanou na port 5060 volaného účastníka. Součástí INVITE je SIP adresa volaného ([email protected]), IP adresa volajícího (nemusí být shodná s odesílací adresou paketu) a nabídka formátů pro kompresi audio signálu. Volaná strana odpoví zprávou OK, kde indikuje svoji IP adresu (opět nemusí být shodná s adresou v paketu)

152


a způsob audio komprese. Navázání spojení je ukončeno zprávou ACK. Hovorový signál je přenášen protokolem RTP. Metoda komprese se v každém směru může lišit. V uvedeném příkladu byla známa IP adresa volaného. Jeho SIP adresa tedy byla sip:[email protected] Daleko běžnější je však adresa v symbolickém tvaru sip:[email protected] Získání IP adresy je provedeno pomocí DNS. V databázi DNS stačí přidat k záznamům domény větu typu SRV. Poněkud komplikovanější situace nastává v případě, že je účastník identifikován pouze klasickým telefonním číslem (podle standardu E.164). Z telefonního čísla přímo nevyplývá doména ani IP adresa. Jedno z možných řešení představuje systém ENUM, což je v podstatě zobecnění DNS. Služba DNS umožňuje i reverzní překlad, tj. nalezení doménového jména ke známé IP adrese. Tento mechanismus je základem systému ENUM. Formát zpráv vychází z protokolu HTTP, obr. 8.12. SIP definuje vlastní hlavičky. V těle zprávy se přenášejí data protokolu SDP (Session Description Protocol), která popisují přenos hovorových dat. V případě protokolu HTTP je v těle přenášen vlastní html kód.

• • • • • •

Některé metody SIP: INVITE – žádost o sestavení spojení. Může být přijata, odmítnuta nebo přesměrována. ACK – potvrzení INVITE finálním příjemcem zprávy (volaným). BYE – ukončení spojení. CANCEL – ukončení nesestaveného spojení. Uživatel nezdvihl telefon. REGISTER – registrace IP adresy koncového zařízení. OPTIONS – dotaz na možnosti serveru. INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 167.180.112.24 From: sip:[email protected] To: sip:[email protected] Call-ID: [email protected] Content-Type: application/sdp Content-Length: 885 c=IN IP4 167.180.112.24 m=audio 38060 RTP/AVP 0

SDP

Obr. 8.13: Zpráva protokolu SIP (tělo obsahuje zprávu SDP) Konkrétní metody komprese audio signálu nejsou součástí SIP ani RTP. Nicméně v praxi se spektrum používaných kodeků prakticky ustálilo. V tabulce jsou vypsány ty nejpoužívanější. Sloupec MIPS udává nutný výpočetní výkon pro kompresi (v milionech operací za vteřinu), sloupec CBR udává bitovou rychlost. Sloupec NEB udává požadovanou přenosovou rychlost v případě použití Ethernetu. Segmenty datového proudu se musí doplnit příslušnými hlavičkami. Tyto hlavičky zvyšují požadavky na přenosovou rychlost. Porovnáním hodnot sloupce NEB je vidět značný podíl režie u kodeků s vysokým stupněm komprese. Poslední sloupec MOS udává stupeň subjektivní kvality přenosu.

Počítačové a komunikační sítě Tab. 2:

8.4.2

153

Používané kodeky

Architektura SIP

Na obr. 8.14 jsou základní komponenty architektury SIP. Spojení navazuje koncové zařízení prostřednictvím tzv. SIP serveru (proxy serveru). Tento server může obsluhovat doménu, firemní síť, resp. síť poskytovatele. Proxy server využívá služeb DNS pro zjištění IP adresy. Předpokládá se, že i na straně volaného je proxy server. Dalším prvkem architektury je registrační server, který udržuje databázi uživatelů a jejich IP adres. Každé koncové zařízení se k tomuto serveru registruje. Během sestavování příchozího hovoru slouží databáze ke zjištění momentální IP adresy volaného účastníka. Po navázání spojení je hovorový signál přenášen protokolem RTP přímo mezi koncovými účastníky. Jednotlivé servery nemusejí být fyzické počítače, ale jenom spuštěné programy na jednom počítači.

Obr. 8.14: Základní prvky SIP a proces navázání spojení [2]


154

Proces sestavení spojení: 1. Koncové zařízení volajícího odesílá do proxy serveru příkaz INVITE. 2. Proxy server odpoví koncovému zařízení zprávou TRYING, což je informace, že probíhá proces sestavování spojení. 3. Proxy server pomocí DNS zjistí IP adresu, na kterou bude dále směrovat příkaz INVITE. Nejčastěji se jedná o proxy server volaného. 4. Proxy server volaného účastníka odpovídá zprávou TRYING. 5., 6. Proxy server volaného dotazem na registrační server zjistí IP adresu volaného. 7. Proxy server odesílá příkaz INVITE do koncového zařízení účastníka. 8., 9. 10. Koncové zařízení odpovídá zprávou RINGING, která se postupně dostane až do koncového zařízení volajícího účastníka. Volající účastník slyší vyzváněcí tón (ten je ovšem generován mikroprocesorem až v jeho telefonním přístroji). 11., 12., 13. Volaný účastník zdvihá sluchátko a odpovídá zprávou OK. 14. Poslední krok navázání spojení je zaslání zprávy ACK přímo na adresu volaného. Vlastní přenos protokolem RTP probíhá přímo mezi koncovými zařízeními. Při sestavování spojení může proxy server odpovědět zprávou o přesunu volaného účastníka. Sestavení spojení tedy obecně může probíhat několika skoky přes proxy (resp. redirect) servery.

8.5 Zajištění kvality služeb v sítích IP 8.5.1

Základní principy

Síť na bázi protokolu IP pracuje na principu best – effort. Negarantuje žádnou kvalitu služeb. Techniky pro přenos multimediálních dat aplikované pouze na straně příjemce (vyrovnávací paměť, časová razítka, FEC) řeší problém pouze částečně. Nemohou zabránit zahlcení sítě, kdy prudce vzroste ztrátovost paketů a zpoždění. Aby se zabránilo této situaci, musí být proveden zásah do samotné architektury sítě IP. Tato kapitola popisuje techniky integrovaných a diferencovaných služeb. V této oblasti stále probíhá vývoj. Některé prvky popisovaných technik jsou již implementovány ve směrovačích. Jejich využívání má často omezený charakter nebo je pouze experimentální.

Obr. 8.15: Modelová situace [1] Uvažujme modelový příklad na obr. 8.15. Kapacitu linky 1,5Mb/s sdílejí dvě aplikace. Na stanici H1 je provozována audio aplikace s trvalým tokem 1Mb/s. Na druhé stanici H2 je


155

provozován klient FTP, který generuje nárazový provoz. Tento provoz může vést k zahlcení směrovače a tím k znemožnění provozování audio aplikace. Řízení kvality služeb (QoS – Quality of Service) je založeno na několika základních principech: • Značení a klasifikace paketů – směrovač R1 musí mít možnost přiřadit prioritu jednotlivým datovým tokům (a stejně tak ostatní směrovače). IP paket musí být proto označen, pro jaký typ služby je využíván. I v rámci protokolu IPv4 existuje v paketu pole Type–of–service (TOS). Značení paketů nemůže být ponecháno z bezpečnostních důvodů jen na jejich odesílateli. Obecně hovoříme o procesu klasifikace paketů, který probíhá např. na vstupu do směrovače. Ke klasifikaci se využívají IP adresy i čísla portů. • Izolace datových toků – přiřazení priorit datovým tokům nezabrání zahlcení směrovače. Musí existovat mechanismus, který je schopen na vstupu do sítě omezit datový tok. Z hlediska co nejefektivnějšího využívání síťových prostředků je žádoucí, aby nevyužitá část přidělené kapacity jedné službě byla rozdělena pro další přenosy. • Odmítnutí spojení – garantovaná přenosová kapacita nemůže nikdy přesáhnout fyzickou kapacitu linky. Musí proto existovat mechanismus, kdy síť odmítne z kapacitních důvodů další spojení. Klasická IP síť tento mechanismus nemá. 8.5.2

Mechanismy zajištění kvality služeb

Zajištění kvality služeb musí být provedeno na úrovni směrovačů. Mezi mechanismy patří správa front, omezování rychlosti a klasifikace paketů. 8.5.2.1 Zpráva front Na obr. 8.16 je znázorněna nejjednodušší varianta vyrovnávací paměti na odchozím směru směrovače. Jedná se o datovou strukturu FIFO (First -In-First-Out), tj. frontu. Do fronty jsou ukládány pakety určeny k odvysílání v pořadí, v jakém byly přijaty. Plánovač vybírá z fronty postupně pakety a vysílá je na linku. V případě přeplnění fronty musí být příchozí pakety zahazovány. Existuje několik typů mechanismů zahazování. Příchozí paket může být přímo odmítnut nebo může být do fronty umístěn místo jiného paketu s nižší prioritou nebo může být z fronty vyřazen jiný paket náhodně. V dalším rozboru budeme předpokládat, že nedojde k zahlcení fronty.

Obr. 8.16: Výstupní jednoduchá fronta (FIFO) [1] Implementace priorit do vyrovnávacích pamětí spočívá ve vytvoření samostatných front pro každou třídu paketů, obr. 8.17. V rámci jedné třídy platí mechanismus FIFO. V případě, že plánovač pracuje na principu Round-Robin, tak z každé fronty postupně vybírá po jednom paketu. Je-li daná fronta prázdná, tak se ihned pokračuje další frontou. Efektem této metody je pouze to, že např. datový tok s nižší prioritou nemůže zahltit frontu s vyšší prioritou.

156


Velkého použití v praxi doznala metoda Weighted fair queuing (WFQ). Počet vybraných paketů z fronty závisí na prioritě. Např. na Obr. 8.17 jsou dvě fronty. Plánovač může z nejvyšší fronty vybrat dva pakety (pokud tam jsou přítomny) a z fronty s nižší prioritou jeden paket. Tak je možné rozdělit celkovou kapacitu linky nerovnoměrně mezi jednotlivé třídy.

Obr. 8.17: Fronty s prioritami [1] 8.5.2.2 Omezení přenosové rychlosti Důležitým mechanismem v zajištění kvality služeb je omezení datového toku na vstupu do sítě. Kriterium musí být vždy založeno na průměrné hodnotě přes zvolený časový interval. Uvážíme-li např. linku 100 Mb/s a konkrétní datový tok (posloupnost paketů patřící ke konkrétnímu spojení dvou uzlů), tak okamžitá přenosová rychlost tohoto toku bude buď 100 Mb/s (paket se přenáší), nebo 0 (přenášejí se jiné pakety). Kritérium může být založeno na průměrné hodnotě (průměr přes delší časové období), na špičkové hodnotě (průměr přes kratší časové období) nebo na velikosti dávky, kterou může zdroj dat nárazově odeslat. Na obr. 8.18 je ilustrována často využívaná metoda „děravého vědra“ (Leaky Bucket). Základem je „vědro“ s kapacitou b žetonů. Do vědra přitékají žetony rychlostí r žetonů/s. Když je přijat paket, tak aby mohl být dále zpracován, musí být z vědra vytažen jeden žeton. V případě, že je vědro prázdné, bude paket zařazen do fronty než se ve vědru nějaký žeton objeví. Alternativou je zahození paketu v případě prázdného vědra.

Obr. 8.18: Metoda „děravého vědra“ (Leaky Bucket) [1]


157

Je zřejmé, že dlouhodobá střední rychlost komunikace je rovna r paketů/s. V případě nárazové komunikace v časovém intervalu t může být odesláno maximálně (rt+b) paketů. Metoda děravého vědra tedy omezuje dlouhodobou střední rychlost a velikost krátkodobé dávky.

Obr. 8.19: Kombinace „děravého vědra“ a správy front typu WFQ [1] Uvažujme nyní kombinaci metody děravého vědra a metody WFQ pro správu front, obr. 8.19. Rychlost vstupu do každé fronty je omezena mechanismem děravého vědra. Je možné dokázat [1], že kombinací obou mechanismů bude shora omezeno zaplnění fronty. To znamená, že u každé fronty bude předem známa maximální hodnota čekací doby, tj. maximální zpoždění při průchodu paketu směrovačem. Je tedy možné pro jednotlivé třídy garantovat kvalitu služeb včetně zpoždění.

8.5.3

Integrované služby a diferencované služby

Integrované služby (IntServ) jsou sadou doporučení IETF, která zavádějí do sítě IP komunikaci s technikou virtuálních okruhů. Zatím tato doporučení nejsou implementována v širším měřítku. Základním prvkem architektury je možnost rezervace přenosové kapacity na každém směrovači pro danou komunikaci. Vlastní komunikaci proto musí předcházet sestavení spojení, kdy na základě signalizace protokolem RSVP dojde k rezervaci zdrojů na všech směrovačích (nebo odmítnutí spojení v případě nedostatečné kapacity). Na obr. 8.20 je naznačen mechanismus sestavení spojení.

Obr. 8.20: Sestavení spojení u IntServ [1]

158


IntServ zavádí dvě hlavní třídy služeb: garantované služby a služby s řízenou zátěží. V případě garantovaných služeb je pomocí techniky děravého vědra a WFQ garantováno maximální zpoždění vznikající ve směrovači. Služby s řízenou zátěží jsou přenášeny jako v případě nezatížené sítě. Dochází tedy k velmi malé ztrátě paketů, avšak kvalitativní parametry přenosu nejsou garantovány. Tato třída je určena pro multimediální aplikace, které byly vyvinuty pro současný Internet pracující na principu best–effort. Tyto aplikace pracují velmi dobře na nezatížené síti, avšak jejich funkce se zhoršuje při rostoucí zátěži. Projekt integrovaných služeb je velmi ambiciózní a tím i komplikovaný. Jedním z problémů je škálovatelnost. Každý směrovač musí udržovat informaci o probíhajících přenosech a pro tyto přenosy zajišťovat QoS. V případě velkých směrovačů pro páteřní sítě toto může vyžadovat velmi značný výpočetní výkon. IntServ definuje navíc poměrně omezený počet tříd služeb. Projekt DiffServ je méně ambiciózní. Je založen pouze na principu priorit a tím vyžaduje menší změnu fungování směrovačů v Internetu. Architektura DiffServ má dva základní prvky: Rozhraní sítě: klasifikace paketů a úprava přenosové rychlosti. Hraniční směrovač provádí klasifikaci paketů. Využívá přitom IP adresy, čísla portů a typy protokolů z hlaviček paketů. Výsledek klasifikace je zapsán do hlavičky paketu. Další funkcí je omezení přenosové rychlosti. Uživatel má stanovenou maximální, resp. střední komunikační rychlost. Pakety, které tuto rychlost přesahují, mohou být zpracovávány rozdílně, např. mohou být uměle zpožďovány, což omezuje komunikační rychlost. Jinou možností je jednoduché zahození paketu hraničním směrovačem. Konkrétní chování závisí na nastavení parametru DiffServ. Jádro sítě: předávání paketů. Parametry přenosu paketů mezi dvěma směrovači (přidělená kapacita, zpoždění) závisí na třídě uvedené v hlavičce paketu. V současnosti jsou definovány dva způsoby předávání: expedited forwarding a assured forwarding. První metoda zajišťuje pro danou třídu minimální přenosovou rychlost. Jednotlivé třídy jsou od sebe izolovány. Druhá metoda rozděluje provoz do čtyř tříd, kde každá třída má garantovanou minimální přenosovou rychlost a kapacitu vyrovnávacích pamětí. V rámci každé třídy jsou pakety rozděleny do tří podskupin, které se liší prioritou při nutnosti zahazovat pakety u přeplněných front.

8.6 Shrnutí kapitoly 8 Multimediální apikace vyžadují po síťové infrastruktuře kromě spolehlivého přenosu i garanci minimální přenosové rychlosti a časování (pravidelnosti dodávky dat). V současné době je síť IP využívána pro multimediální aplikace zahrnující i hlasovou službu IP telefonie. V lokálních sítích se problém sezajištěním kvality spojení řeší předimenzováním kapacity sítě nebo prioritami v rámci Ethernetu. V případě globálních sítí je již nutný zásah do samotného protokolu IP (služby IntServ) nebo vyžití prioritních mechanismů (DiffServ).


159

9 Bezpečnost síťového provozu Cíle kapitoly: • Objasnit základní principy kryptografie. • Zabezpečení síťového provozu, SSL, IPsec.

9.1 Základní pojmy • •

•

•

Bezpečnost síťového provozu je postavena na několika základních principech: Utajení – jen určený příjemce musí být schopen porozumět přenášeným datům. Odposlech elektronické komunikace je z principu nezjistitelný. Přenášená data musejí být šifrována. Autentizace – jak příjemce, tak odesílatel musí být schopni potvrdit svoji identitu. Autentizace je založena na znalosti „tajemství“ (hesla), znalosti algoritmu (např. vlastnictví autentizačního „kalkulátoru“), nebo v dnešní době na některém biometrickém znaku uživatele. Integrita zprávy a průkaznost autorství – zpráva může být při přenosu modifikována nebo dokonce podvržena. Integrita je zajišťována pomocí kryptografických kontrolních součtů. Ve spojení s kryptografií s veřejným klíčem je možné prokázat uživateli i autorství zprávy. Omezení přístupu – součástí bezpečnosti síťového provozu je i možnost řízení přístupu k síťovým zdrojům (např. zákaz komunikace z jistých IP adres).

Uvažujme základní komunikační schéma na obr. 9.1. Komunikující uživatelé se standardně jmenují Alice a Bob (podle prvních písmen abecedy). Data před zašifrováním se nazývají „otevřený text“ (plaintext nebo cleartext), i když se jedná o přenos čistě binárních dat. Po zašifrování dostáváme „šifrovaný text“ (ciphertext).

Obr. 9.1:

Základní model komunikace [1]

Dále se předpokládá, že existuje třetí strana (Trudy), která může odposlouchávat přenášené zprávy, mazat je a do přenosového kanálu vkládat své zprávy. Alice pro zašifrování zprávy použije klíč KA. Proces šifrování označíme jako c = KA(m), kde m je otevřený text. Na straně příjemce Bob použije pro dešifrování zprávy klíč KB,


160

m = KB(c) = KB(KA(m)). Šifrovací algoritmus je předpis, jehož vstupem je zpráva a šifrovací klíč. Výstupem je potom zašifrovaná zpráva. Existují dvě základní kryptografická schémata: Symetrická kryptografie – obě komunikující strany sdílejí stejný klíč KAB, který musí být utajen. Šifrování na straně odesílatele napíšeme jako c = KAB(m). Dešifrování na straně příjemce pak, m = KAB(c) = KAB(KAB(m)). Kryptografie s veřejným klíčem – každý uživatel má dvojici klíčů: veřejný klíč KB+ a tzv. soukromý klíč KB-. Soukromý klíč musí být utajen, veřejný klíč je naopak známý všem. Při zasílání zprávy použije odesílatel pro zašifrování jeho veřejný klíč příjemce c = KB+(m). Příjemce potom použije pro dešifrování svůj soukromý klíč m = KB-(c) = KB-(KB+(m)). Kryptografie s veřejným klíčem je založena na principu nemožnosti invertovat šifrovací algoritmus. I když třetí strana zná šifrovací klíč a šifrovaný text, tak je technicky nemožné získat otevřený text. Z hlediska dešifrování zpráv třetí stranou mohou nastat tři základní situace: Ciphertext-only – třetí strana zná pouze zašifrovanou zprávu, Known-plaintext – třetí strana zná otevřený i zašifrovaný text, Chosen-plaintext – třetí strana je schopna donutit uživatele k zašifrování zvolené zprávy, jejíž struktura zjednoduší dešifrování.

9.2 Symetrická kryptografie Jako nejjednodušší příklad si uveďme tzv. substituční šifru:

Obr. 9.2:

Substituční tabulka

Každému znaku otevřeného textu je přiřazen znak zašifrovaného textu. Klíčem k šifrování i dešifrování je tabulka sama. Uvažujeme-li dešifrování zprávy metodou hrubé síly, pak útočník musí vyzkoušet všechny možné permutace abecedy. V případě tabulky na obr. 9.2 je těchto permutací 26!. Tab. 3 uvádí, jak dlouho by takové dešifrování trvalo. Nicméně v případě této substituční šifry existují elegantnější metody. Např. je možné použít tzv. frekvenční analýzu, která je založena na nestejné pravděpodobnosti výskytu konkrétních znaků v otevřeném textu (např. znak „e“ se vyskytuje nejčastěji, x prakticky vůbec).

Počítačové a komunikační sítě Tab. 3:

161

Použití metody hrubé síly [2]

Moderní metody jsou založeny na binárním klíči. Délka klíče pak určuje náročnost provedení útoku hrubou silou. Musí být volena tak, aby po dobu, po kterou má zpráva platnost, byl útok technicky neproveditelný.

9.2.1

Standardy DES a AES

Standard DES (Data Encryption Standard) byl zaveden v roce 1977 (v USA). Jedná se o tzv.blokovou šifru. Otevřený text musí být rozdělen na 64-bitové bloky. Výsledkem šifrování každého bloku je 64 bitů zašifrované zprávy. Do šifrovacího algoritmu vstupuje i 64-bitový klíč, který však obsahuje 8 paritních bitů, takže délka klíče je 56 bitů. Na obr. 9.3 je naznačeno základní schéma DES.

Obr. 9.3:

Základní schéma DESu [1]

Kromě vstupní a výstupní permutace bitů je šifrování založeno na 16-ti identických blocích, do kterých vstupuje vždy 48 vybraných bitů z 56-ti bitového klíče. Každý blok


162

(slangově „runda“) představuje tzv. Feistelovu strukturu. Data jsou rozdělena na dva 32bitové bloky L a R. Jednu rundu můžeme popsat následujícími vztahy. ,

(9.1) . F je kombinační logická funkce, jejímž vstupem je 32-bitů šifrovaného textu a 48-bitů šifrovacího klíče. Algoritmus funkce F je samozřejmě známý, nikdy však nebyly zveřejněny principy, na kterých je algoritmus založen. Stejnou strukturu je možné použít i pro dešifrování (postupuje se od L2, R2 k L1, R1). Funkce F nemusí být invertibilní. , (9.2) . Výsledek plyne z vlastnosti součtu mod 2 (operace XOR). DES je možné realizovat samozřejmě softwarově i jako blok integrovaného obvodu (např. periferie tzv. kryptografických procesorů). V dnešní době DES již není bezpečnou šifrou. V roce 1999 v rámci soutěže pořádané firmou RSA trvalo jeho dešifrování 22 hodin za použití sítě počítačů propojených Internetem a specialisovaných hw bloků postavených na obvodech FPGA. Proto byl standard DES modifikován tak, že data jsou šifrována trojitým průchodem za použití jiných klíčů. Jedná se o algoritmus Triple-DES (3DES). Bloková šifra může pracovat v několika režimech. Základní režim Electronic Code Book (ECB) je založen na prostém rozdělení zprávy na 64-bitové bloky. Každý blok je šifrován nezávisle na ostatních blocích. Nevýhodou této metody je, že stejným vstupním datům odpovídá i stejný šifrovaný text, což může usnadnit prolomení šifry. Za bezpečnější se považuje tzv. řetězový režim Cipher Block Chaining (CBC), obr. 9.4. Zašifrovaný text předchozího bloku je sečten (operace XOR) s následujícím blokem otevřeného textu. Pro první blok je použit náhodně vygenerovaný inicializační vektor. V praxi se využívá více variant řetězení.

Obr. 9.4:

Bloková šifra v řetězovém režimu (CBC)

Metoda AES (Dvanced Encryption Standard) byla zavedena v roce 2001 jako nástupce DES. Používá velikost bloků 128 bitů. Délka klíče může být 128, 192 nebo 256 bitů. Útok hrubou silou je v dnešní době technicky neproveditelný.


163

Proudové šifry

Na rozdíl od blokových šifer je každý bit zprávy šifrován samostatně. Bitová posloupnost otevřeného textu je sčítána s pseudonáhodnou posloupností ki (keystream). ci = mi ⊕ ki . (9.3) Na straně příjemce je zašifrovaná posloupnost sečtena se stejnou pseudonáhodnou posloupností mi = ci ⊕ ki = (mi ⊕ ki ) ⊕ ki . (9.4) mi Obr. 9.5:

+

ci

ki Princip proudové šifry

Generování pseudonáhodné posloupnosti může být nezávislé na šifrované zprávě (tzv. synchronní režim) nebo do něj může otevřený text vstupovat (tzv. autosynchronizační režim). Na obr. 9.6 je uvedeno schéma šifry A5/1, která se využívá pro mobilní komunikace. Počáteční stav posuvných registrů jednoznačně definuje generovanou pseudonáhodnou posloupnost. Tento stav je vytvořen ze šifrovacího klíče.

A5/1

RC4 Obr. 9.6:

Proudové šifry A5/1 a RC4

Základem šifry RC4je pole S o délce 256 bytů. Počáteční stav se vygeneruje předpisem

kde key je klíč. Vlastní pseudonáhodná posloupnost bytů se potom generuje předpisem


164 9.2.3

Kryptografie s veřejným klíčem

Kryptografie je založena na existenci dvou klíčů, veřejného a soukromého, obr. 9.7. Zpráva zašifrovaná veřejným klíčem může být dešifrována pouze soukromým klíčem, který zná jen příjemce, m = KB-(KB+(m)). Nejznámější metodou je algoritmus RSA pojmenovaný po jeho tvůrcích (Rivest, Shamir, Adleman). Algoritmus má dvě základní části: generování dvojice klíčů a vlastní šifrování a dešifrování. Volba klíčů probíhá v následujících krocích: 1. Zvolí se dvě velká prvočísla p a q. V dnešní době se doporučuje, aby binární reprezentace těchto čísel měla délku 1024 bitů. 2. Vypočítá se n = p q, z = (p-1) (q-1). 3. Zvolí se číslo e < n takové, že s číslem z nemá žádný společný dělitel. 4. Najde se číslo d takové, aby e d - 1 bylo beze zbytku dělitelné číslem z. To znamená, že e d mod z = 1. 5. Dvojice (n, e) je veřejný klíč, dvojice (n, d) je soukromý klíč.

Obr. 9.7:

Kryptografie s veřejným klíčem [1]

Zprávu určenou k zašifrování interpretujeme jako číslo m < n (tj. bitová posloupnost otevřeného textu se interpretuje jako číslo). Zašifrovaný text obdržíme za použití veřejného klíče matematickou operací (9.5) c = m e mod n . K dešifrování se použije soukromý klíč a stejná operace. (9.6) m = c d mod n . Z uvedeného postupu vyplývá velmi významná vlastnost algoritmu RSA + − − + (9.7) K B ( K B (m)) = K B ( K B (m)) . Veřejný a soukromý klíč je možné zaměnit, tj. data je možné zašifrovat soukromým klíčem a dešifrovat klíčem veřejným. Příklad šifrování pomocí RSA Zvolená prvočísla: p = 5, q = 7 → n = p q = 35, z = (p-1) (q-1) = 24 e = 5 nemá společný dělitel s číslem z = 24 d = 29 splňuje podmínku e d mod z = 1 Dvojice (35,5) je veřejný klíč, dvojice (35,29) je soukromý klíč.


165

Otevřený text je tvořený jediným znakem „l“, jež bude reprezentován pořadovým číslem anglické abecedy, tj. m = 12. c = me mod n = 125 mod 24 = 248 832 mod 24 = 17 Proces dešifrování: m = cd mod n = 1729 mod 35 = 481968572106750915091411825223071697 mod 35 = 12 Šifrovací metody s veřejným klíčem jsou pomalejší ve srovnání se symetrickými metodami. Udává se, že DES je 100 násobně rychlejší oproti RSA při softwarové implementaci a 1000 až 10000 násobně rychlejší při implementaci v hardware. Proto se často RSA využije pouze k zašifrování náhodně vygenerovaného symetrického klíče a vlastní zpráva se šifruje symetrickou metodou tímto klíčem. Příjemce pomocí RSA dešifruje symetrický klíč a pro vlastní zprávu použije rychlou symetrickou metodu. Bezpečnost metody RSA je založena na neexistenci algoritmu, který pro známé číslo n dokáže najít prvočísla p a q (n = p q). Nikdy však nebylo dokázáno, že taková metoda nemůže existovat. Proto se v dnešní době doporučuje délka klíče 1024 bitů (tj. 300 dekadických míst).

9.2.4

Autentizace

Autentizace je proces, kdy dochází k prokázání identity protistraně. Autentizační algoritmus musí počítat s možností podvržení zprávy třetí stranou a také s možností opakovaného vysílání zachycených dat. Z toho důvodu musí metoda autentizace využívat prvek náhodnosti. Autentizaci je možné založit jak na symetrických algoritmech, tak na algoritmech s veřejným klíčem. 9.2.4.1 Autentizace s využitím symetrické metody Na obr. 9.8 je základní schéma. První zpráva obsahuje žádost Alice o autentizaci. Bob vygeneruje náhodné číslo R a zašle je Alici. Alice toto číslo zašifruje pomocí symetrického klíče KA-B a odešle zpět. Bob provede dešifrování tímtéž klíčem a porovná výsledek s vyslaným číslem R. Shoda je důkazem, že odesílatel znal klíč KA-B. Při dalších autentizacích se číslo R nesmí opakovat. Jinak by bylo možné pouze použít zachycenou odpověď KA-B(r). Tento autentizační mechanismus vyžaduje, aby obě strany sdílely stejný symetrický klíč. Je-li jediným prostředkem komunikace síť, tak pouze s použitím symetrických metod není možné klíč bezpečně přenést.

Obr. 9.8:

Autentizace s využitím symetrické metody [1]


166

Obr. 9.9:

Autentizace s veřejným klíčem a její slabina [1]

Na obr. 9.9 je varianta autentizace s využitím nesymetrické kryptografie. Bob generuje číslo R, které Alice zašifruje svým soukromým klíčem. Po té zašle Bobovi svůj veřejný klíč, kterým je možné zprávu dešifrovat. Hlavní slabinou tohoto mechanismu je, že není zaručena vazba mezi uživatelem a jeho veřejným klíčem. Stejně dobře se může Trudy vydávat za Alici.

9.2.5

Integrita zpráv

Smyslem kontroly integrity zprávy je zabránit její modifikaci třetí stranou. Kontrola integrity není šifrování. Zpráva se může přenášet v otevřeném tvaru a může být pouze doplněna o kryptografický kontrolní součet. Pak hovoříme o tzv. digitálním podpisu. Teoreticky by bylo možné pro digitální podpis využít nesymetrické šifrovací techniky. Autor zprávy by tuto zprávu zašifroval svým soukromým klíčem. Přenášel by se zašifrovaný text c = K-(m) Příjemce by provedl dešifrování veřejným klíčem autora zprávy. Úspěšné dešifrování by potvrdilo: 1. integritu zprávy, 2. autora zprávy (tj. držitele příslušného soukromého klíče), Vzhledem k velké výpočetní náročnosti se tato metoda nepoužívá. Digitální podpis je založen na technice tzv. kryptografických kontrolních součtů (hašovacích funkcí). Princip spočívá v tom, že se z libovolně velké zprávy spočte kontrolní součet (fingerprint – „otisk“ zprávy) o délce řádově stovek bitů. Na tento kontrolní součet již mohou být snadno aplikovány nesymetrické metody. Hašovací funkce je jednosměrný algoritmus, který ke zprávě m sestrojí kontrolní součet H(m). Základní podmínkou je tzv. bezkoliznost algoritmu. Je třeba si uvědomit, že délka zprávy je mnohem větší než délka kontrolního součtu. Uvážíme-li všechny možné kombinace bitů tvořících zprávu jisté délky, tak je zřejmé, že nutně musí existovat více zpráv se stejným kontrolním součtem. Kolizi tedy nazýváme situaci, kdy dvě různé zprávy mají stejný kontrolní součet. Bezkolizností je nazývána podmínka, která požaduje, že k známé zprávě x musí být výpočetně nemožné sestrojit zprávu y se stejným kontrolním součtem, tj. aby H(x) = H(y).


167

Obr. 9.10: Princip digitálního podpisu [1] Na obr. 9.10 je uvedeno základní schéma digitálního podpisu. Autor spočte kryptografický kontrolní součet H(m) jím vytvořené zprávy. Kontrolní součet zašifruje svým soukromým klíčem KB-(H(m)). Zpráva doplněná o zašifrovaný kontrolní součet se nazývá zpráva s digitálním podpisem. Na straně příjemce se použije veřejný klíč autora k dešifrování kontrolního součtu. Dešifrovaný kontrolní součet se porovná s kontrolním součtem znovu spočteným pro zprávu m. Shoda prokazuje jak integritu, tak autorství zprávy. Hašovací funkce V praxi se používá několik typů hašovacích funkcí. Známý je algoritmus MD5 (RFC1321), jehož výsledkem je 128 bitový kontrolní součet. Před několika lety byla však objevena slabina tohoto algoritmu, která umožňuje relativně výpočetně snadno modifikovat zprávu tak, aby měla stejný kontrolní součet. MD5 tedy nesplňuje podmínku bezkoliznosti.

Obr. 9.11: Výpočet SHA-2-512 [2] Z toho důvodu se dnes používá skupina algoritmů SHA (Secure Hash Algorithm). Algoritmus SHA-1 generuje 160 bitový kontrolní součet. Algoritmy SHA-2 mohou generovat


168

součty o délce 256, 384, 512 nebo 224 bitů. Algoritmus je sestrojen tak, že každý bit kontrolního součtu je funkcí všech bitů původní zprávy. Je tedy výpočetně nemožné vysledovat souvislost mezi strukturou zprávy a kontrolním součtem. Na obr. 9.11 je pro ilustraci uveden výpočet SHA-2 s délkou 512 bitů. Původní zpráva je rozdělena na bloky s délkou 1024 bitů. Každý blok je zpracován samostatně na kontrolní součet 512 bitů. Výsledky jsou pro všechny bloky sečteny (operace XOR). Jiná metoda zajištění integrity zprávy je založena na symetrické kryptografii. Původní zpráva se zašifruje za použití symetrické metody klíčem K. Část zašifrovaného textu se připojí k původní zprávě jako „kontrolní součet“. Příjemce musí znát symetrický klíč K. Pak zašifruje přijatou zprávu a příslušnou část porovná s kontrolním součtem, který byl ke zprávě připojen.

9.2.6

Distribuce klíčů Symetrická kryptografie

V případě použití symetrických metod se musí obě strany nejdříve dohodnout na šifrovacím klíči. Bezpečné předání tohoto klíče je nutnou podmínkou k zajištění bezpečnosti vlastní komunikace. Pro řešení tohoto problému může být použita tzv. důvěryhodná třetí strana. V případě symetrické kryptografie hovoříme o distribučním centru (Key Distribution Center-KDC). Základní mechanismus komunikace je na obr. 9.12. Každý uživatel sdílí s KDC symetrický šifrovací klíč. Uživatelé navzájem neznají své šifrovací klíče. Znalost klíče tedy prokazuje identitu uživatele.

Obr. 9.12: Distribuce klíče pro symetrickou metodu [1] Alice generuje zprávu obsahující informaci o tom, že chce komunikovat s Bobem. Tuto zprávu zašifruje symetrickým klíčem, který sdílí s distribučním centrem (KA-KDC(A,B)). KDC zprávu dešifruje (tím potvrdí identitu odesílatele), náhodně vygeneruje jednorázový klíč R1. Tento klíč zašifruje za použití klíče, který sdílí s Bobem (KB-KDC(A,R1)). Sestaví zprávu, která obsahuje samotný klíč R1 i jeho zašifrovanou verzi pro Boba. Tuto zprávu zašifruje klíčem pro Alici. Alice po dešifrování bude znát klíč R1. Zašifrovanou podobu klíče přepošle Bobovi. Nyní obě strany mají k dispozici dočasný šifrovací klíč R1, aniž by museli znát navzájem své klíče, které sdílí s KDC. Na tomto principu je např. vystavěn systém Kerberos. Symetrická kryptografie Hlavním problémem použití symetrické kryptografie je prokázání vazby mezi uživatelem a jeho veřejným klíčem. Kdokoli totiž může zveřejnit svůj klíč a vydávat jej za klíč někoho jiného.

Počítačové a komunikační sítě Bob’s public key Bob’s identifying information

+ KB

169 digital signature (encrypt) CA private key

K CA

+

KB certificate for Bob’s public key, signed by CA

Obr. 9.13: Funkce certifikační autority [1] Řešení bylo nalezeno ve využití tzv. certifikační autority (CA), obr. 9.13. Osoba nebo zařízení si u certifikační autority registruje svůj veřejný klíč. Procedura spojená s ověřením identity je dána předpisem certifikační autority. Po ověření identity vystaví CA certifikát, který obsahuje veřejný klíč uživatele KB+ spolu s dalšími informacemi o jeho identitě. Tento dokument CA podepíše svým soukromým klíčem (tj. spočte hash a zašifruje jej soukromým klíčem). Pro veřejné použití platí pro CA standard X.509. Součástí tohoto standardu je i definice syntaxe certifikátu. Mimo jiné certifikát obsahuje informaci o použitých kryptografických metodách, uvedení doby platnosti a definici za jakým účelem byl vydán. Standard definuje i možnost revokace certifikátu. Integrita certifikátu uživatele se ověřuje pomocí veřejného klíče CA, který je uveden v certifikátu samotné certifikační autority. Veřejný klíč CA musí být zjištěn z důvěryhodného zdroje (např. i prostřednictvím publikování v tisku). Certifikát může být podepsán vyšší certifikační autoritou. Vytvoří se tak hierarchie certifikátů. Na vrcholu stojí kořenová certifikační autorita, které se musí důvěřovat. Vydávání a používání certifikátů vytváří tzv. infrastrukturu veřejného klíče (PKI - RFC3279-3281). Na obr. 9.14 je ukázka kořenového certifikátu VUT v Brně, který je vydán pro účely ověření identity serverů při komunikaci https a pro šifrování emailu.

Obr. 9.14: Kořenový certifikát VUT (obsahuje veřejný klíč CA VUT)


170

9.3 Zabezpečení síťového provozu 9.3.1

E-mail

Na obr. 9.15 je naznačeno schéma generování e-mailové zprávy, které splňuje podmínku utajení, autentizace autora a zajištění integrity. Nejdříve je zpráva m podepsána pomocí soukromého klíče odesílatele (ke zprávě je připojen podpis KA-(H(m)) ). Po té je náhodně vygenerován symetrický šifrovací klíč KS, který je platný jen pro přenos této konkrétní zprávy. Podepsaná zpráva ( m, KA-(H(m)) ) se zašifruje tímto klíčem. Samotný dočasný šifrovací klíč KS se zašifruje veřejným klíčem příjemce, KB+(KS). U příjemce proběhne opačný proces. Nejdříve svým soukromým klíčem zjistí dočasný šifrovací klíč KS. Pomocí něj dešifruje podepsanou zprávu a digitální podpis ověří veřejným klíčem odesílatele. Veřejný klíč může být získán na základě certifikátu podepsaného důvěryhodnou certifikační autoritou. Výsledkem šifrování je binární zpráva. Pro přenos pomocí e-mailu musí být zakódována např. algoritmem Base64. Na tomto principu pracuje např. program PGP (Pretty Gooe Privacy) nebo standard S/MIME (RFC2632 – 2634). -

KA

m

.

H( )

-

.

KA( )

-

KA(H(m))

+

KS

.

KS( )

+

m KS

+

.

KB( )

+

KB

Internet

+

KB(KS )

Obr. 9.15: Vytvoření zabezpečené emailové zprávy [1]

9.3.2

SSL

SSL (Secure Sockets Layer) se používá pro zabezpečení komunikace na aplikační vrstvě. V hierarchii protokolů leží SSL mezi transportní a aplikační vrstvou. SSL bylo vyvinuto firmou Netscape v roce 1994. Z verze SSL 3.1 byl odvozen standard TLS (Transport Layer Security, RFC 2246).

Obr. 9.16: Struktura SSL [2]


171

SSL se snaží dojednat bezpečný přenosový kanál, a pokud se to nepodaří, žádná data přenesená nejsou. Nejznámější uplatnění SSL je u zabezpečeného HTTP (HTTPS) podporované většinou webových prohlížečů. SSL podporuje obousměrnou autentizaci, ale používá se většinou pouze jednosměrně, kdy prohlížeč na autentizaci webového serveru používá certifikát X.509 vydaný pro doménové jméno serveru. Tak má webovým prohlížeč jistotu, že komunikuje skutečně s daným serverem, a současně se může vygenerovat klíč pro danou relaci zabezpečující komunikaci mezi uživatelem a serverem. Přehled hlavních protokolů nad TLS/SSL a jejich příslušných portů je uveden v tabulce SSL zajišťuje autenticitu odesilatele, integritu a šifrování aplikačních dat při jejich přenosu přes veřejnou IP síť. SSL vyžaduje spolehlivý transportní protokol, tedy TCP. SSL používá kombinaci šifrování veřejným a soukromým klíčem: asymetrické šifrování se používá v průběhu počáteční fáze pro autentizaci a generování klíčů dané relace, a soukromý klíč se pak využívá pro šifrování zpráv. Architektura SSL se skládá z vrstvy Record Layer a tří služebních protokolů: Vrstva záznamů (record layer) je zodpovědná za fragmentaci (do bloků o max. délce 16384 bytů) a někdy kompresi aplikačních dat, šifrování a integritu dat prostřednictvím algoritmů symetrických klíčů, obr. 9.17. Klíče se stanoví při průběhu počátečního dojednávání (protokol handshake), které používá algoritmy asymetrického šifrování na vytvoření hlavního soukromého klíče (master secret) mezi klientem a serverem. Tento klíč se pak dále využívá pro odvození šifrovacích klíčů, inicializačních vektorů a klíčů autentizačního kódu zpráv (MAC), které se využívají na vrstvě záznamů. Tab. 4:

Protokoly podporované SSL [5]


172

Obr. 9.17: Funkce vrstvy záznamů [2] Handshake protokol zodpovídá za sestavení spojení, autentizaci a vytvoření klíčů. Protokol pro navázání spojení je složitý a má mnoho variací. SSL nabízí autentizaci jak klientů, tak serverů. SSL je velmi flexibilní, protože umožňuje využití řady algoritmů pro dohodu na klíčích (RSA, DH), šifrování (RC4, DES, 3DES, AES) a hashování (MD5, SHA). Aby nedocházelo k nějakým negativních interakcím mezi jednotlivými algoritmy, specifikace popisuje kombinace těchto algoritmů (cipher suites) z hlediska jejich bezpečnostních vlastností. Protokol CCS (change cipher spec) se používá na signalizaci úspěšného navázání spojení protokolem handshake, tedy signalizaci pro zahájení šifrování toku dat. Protokol alert má za úkol informovat o jakýchkoli chybách protokolu.

9.4 Shrnutí kapitoly 9 Internet byl původně budován jako akademická síť. Do protokolu IP nebyly zahrnuty žádné bezpečnostní mechanismy. Drtivá většina současné komunikace probíhá v otevřené (nešifrované) podobě. V kapitole jsou objasněny principy symetrické a asymterické kryptorafie. Je ukázano zabezpečení na aplikační i transpotní úrovni.


173

Seznam použité literatury (nutné citovat dle normy) [1]

KUROSE, J. F., ROSS, K. W., Computer Networking (3rd ed.). Pearson Education (Addison Wesley), Boston, USA, 2005.

[2]

STALLINGS, W. Data and Computer Communications (8th Edition). Prentice Hall, 2006.

[3]

DOSTÁLEK, L. , KABELOVÁ, A. Velký průvodce protokoly TCP/IP a DNS (4. vydání). Computer Press, Brno, 2005.

[4]

KÁLLAY, F., PENIAK, P. Počítačové sítě a jejich aplikace LAN/MAN/WAN (2. vydání). Grada, Praha, 2003.

[5]

PUŽMANOVÁ, R. TCP/IP v kostce. Kopp, 2004.

[6]

DOSTÁLEK, L. a kol. Velký průvodce protokoly TCP/IP: Bezpečnost (2. vydání). Computer Press, Brno, 2005.

[7]

STAUDEK. J. Počítačové sítě. Přednáškové materiály, MU Brno.

[8]

JANEČEK, J., BÍLÝ, M. Lokální sítě. Skriptum ČVUT Praha, 2003.

[9]

www.earchiv.cz

[10]

BOHÁČ, L. Komunikace v datových sítích. Přednášky ČVUT.

[11]

BEZPALEC, P. Kvalita služeb datových sítí z hlediska VoIP. Sborník semináře Teorie a praxe IP telefonie, Praha, 2006

Report "Počítačové a komunikační sítě"

Your name

Email

Reason

Description

Copyright © 2025 ADOC.PUB. All rights reserved.
About Us | Privacy Policy | Terms of Service | Copyright | Contact Us | Cookie Policy

Sign In

Email

Password

Remember me Forgot password?

Our partners will collect data and use cookies for ad personalization and measurement. Learn how we and our ad partner Google, collect and use data. Agree & close

Počítačové a komunikační sítě

Recommend Documents