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

Transkript

FAKULTA ELEKTROTECHNIKY A KOMUNIKAČNÍCH TECHNOLOGIÍ
VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ
Garant předmětu:
Prof. Dr. Ing. Zdeněk Kolka
Autor textu:
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
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
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
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>:<na schématu-závislá-část>
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://<uživatel:heslo><server>:<port>/<cesta>?<dotaz>#<fragment>
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 <fragment>. Pokud chceme, aby od levého horního okraje obrazovky
byl zobrazován právě <fragment>, 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:
<Název metody> <URI> 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
<HTML>
<HEAD>
<TITLE>VUT v Brně</TITLE>
</HEAD>
<TABLE>
<TR><TD>
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:
<Verze> <Výsledkový kód> <Poznámka>
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ě.
•
•
•
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 <[email protected]>; 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
Received: from OFFICENO (schoralekm.lam.cz [212.71.169.227])
by smtp.lam.cz (Postfix) with ESMTP
Reply-To: <[email protected]>
From: "Roman Lustig (icomputing.cz)" <[email protected]>
To: <[email protected]>
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 <CRLF>.<CRLF>
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.
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.
•
•
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?= <[email protected]>
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.
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.
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]
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
network
data link
physical
network
data link
physical
Obr. 5.1:
network
data link
physical
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í
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
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
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
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
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)
7.3.1
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ů
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.
<title>Twister</title>
<session>
<group language=en lipsync>
<switch>
<track type=audio
e="PCMU/8000/1"
src = "rtsp://audio.example.com/twister/audio.en/lofi">
<track type=audio
e="DVI4/16000/2" pt="90 DVI4/8000/1"
src="rtsp://audio.example.com/twister/audio.en/hifi">
</switch>
<track type="video/jpeg"
src="rtsp://video.example.com/twister/video">
</group>
</session>
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.
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.
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).
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ý.
9.2.2
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.
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.
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

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

Transkript

Podobné dokumenty

Rottweiler klub

5. Počítačové sítě

stažení.

Dezinfekční a čisticí roztoky pro ultrazvukové systémy a sondy

Výuka Hardware IT4 - eBooks na SŠT AGC as

Technologie počítačových sítí - Katedra technické a informační

Zde - profiprint.cz

Počítačové sítě

Základy transportního protokolu TCP

na sítě - Vrstevnice

Dezinfekční a čisticí roztoky pro ultrazvukové systémy a sondy

úvod do počítačových sítí i. - Katedra informatiky

PDF technický prospekt - CPD

odkaz

zde

Anglicko-český / česko-anglický slovník matematické terminologie

IT_420 Komunikační technologie a služby

English-Czech dictionary of mathematical terminology

Internetová telefonie (VoIP) a protokol SIP

PKO-vypisky ke zkousce