MPKT - Pokročilé komunikační techniky

Transkript

1 1) TCP/IP: vazba mezi RM ISO/OSI a TCP/IP, filozofie vzájemného propojování sítí pomocí TCP/IP, souběh aplikací v TCP/IP a zapouzdřování, úloha síťové vrstvy s IPv4 protokolem, IPv4 adresy a související pojmy, IPv4 datagram, IP tunelování, protokol ICMPv4, protokol UDP, protokol TCP, ARP protokol, DHCP protokol, překlad adres - NAT, jmenný systém DNS, princip protokolů zálohování výchozí brány Vazba mezi RM OSI a TCP/IP TCP/IP je stejně jako RM ISO/OSI síťovou architekturou. 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 postoji jejich tvůrčí. Při koncipování referenčního modelu ISO/OSI měli hlavní slovo zástupci spojových organizací, kteří kladli důraz na vlastnosti sítě (především spojovaný a spolehlivý charakter služeb) s tím, že k síti připojované hostitelské počítače budou mít relativně jednoduchou úlohu. Později se ale ukázalo, že např. právě v otázce zajištění spolehlivosti to není nejšťastnější řešení že 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 1 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. Komunikační síť by ovšem neměla zahazovat pakety bezdůvodně. Měla by naopak vyvíjet maximální snahu přenášené pakety doručit (v angličtině se v této souvislosti používá termín besteffort), a zahazovat pakety až tehdy, když je skutečně nemůže doručit - tedy např. když - 1 -

2 dojde k jejich poškození při přenosu, když pro ně není dostatek místa ve vyrovnávací paměti pro dočasné uložení, v případě výpadku spojení apod. Na rozdíl od referenčního modelu ISO/OSI tedy TCP/IP předpokládá jednoduchou a rychlou komunikační podsíť, ke které se připojují inteligentní hostitelské počítače. TCP/IP předpokládá nespojovaný charakter přenosu v komunikační síti tedy jednoduchou diagramovou službu a obsahuje jen čtyři vrstvy (viz Obr. 10). Filozofie vzájemného propojování sítí pomocí TCP/IP Řešení vzájemného propojování sítí je jedním z prvotních příčin vzniku celé soustavy protokolů TCP/IP. Filosofie TCP/IP od začátku usiluje o co nejuniverzálnější propojení sítí různých typů od lokálních sítí typu Ethernet, Token Ring apod., přes veřejné datové sítě, až po rozlehlé sítě celosvětového dosahu. Klade si přitom za cíl umožnit každému počítači komunikovat s kterýmkoli jiným počítačem, bez ohledu na to, zda mezi nimi existuje přímé spojení, nebo zda jsou například tyto uzly v různých sítích, které jsou vzájemně propojeny jednou nebo několika dalšími sítěmi. Výsledkem je pak jediná soustava vzájemně propojených sítí, v terminologii TCP/IP označovaná obecně jako Internetworking. Z pohledu uživatele by vnitřní struktura této soustavy sítí měla být irelevantní - uživatelé, resp. jejich aplikační programy, se mohou na celý Internetworking dívat jako na jedinou velkou síť, ke které jsou připojeny jednotlivé koncové počítače - v terminologii TCP/IP označované jako hostitelské počítače (host computers, hosts). Ve skutečnosti je výsledná soustava (Internet) tedy jen konglomerátem (dílčích) sítí stejného či různého typu, vzájemně propojených na úrovni síťové vrstvy pomocí zařízení označených někdy nesprávně jako brány (gateway), správně termínem IP router (tj. IP směrovač). Výhodou IP protokolu je, že zavádí jednotný formát adres a způsob adresování i jednotný formát přenášených dat na úrovni síťové vrstvy. Na Obr. 11 je ukázka propojení dvou stanic přes Internet (Host A resp. Host B, kteří sídlí na lokální sítí LAN A resp. LAN B). V dolní části Obr. 11 je vidět na jakých vrstvách jednotlivé prvky pracují, spojitá čára značí reálný průchod dat sítí od Hosta A k Hostu B, přerušovaná čára značí virtuální spoje na jednotlivých vrstvách. (Přerušované čáry vedoucí ze směrovačů v horní části značí cesty k dalším částem Internetu, které v obrázku nejsou pro zjednodušení nakresleny.) - 2 -

3 Souběh aplikací v TCP/IP a zapouzdřování Na Obr. 15 jsou jako př. znázorněny tři současně běžící aplikace, www prohlížeč, ový klient a ftp klient. Každá z těchto aplikací využívá příslušný aplikační protokol, při této volbě služeb jsou to HTTP, např. IMAP a FTP, které jsou schopny uživatelovy požadavky zformulovat do zprávy, kterou bude následně schopna druhá strana komunikace zpracovat, tzv. Application PDU (Protocol Data Unit), tedy protokolová datová jednotka aplikační vrstvy, jednoduše nazývána data. Tyto údaje (pocházející z libovolného z aplikačních protokolů) jsou předávány transportní vrstvě, při volbě protokolů HTTP, IMAP a FTP pouze protokolu TCP, protokol UDP by byl použit v případě volby jiných aplikací. Přidáním hlavičky TCP vznikne TCP PDU, tedy protokolová datová jednotka transportní vrstvy, též nazývaná segment. Transportní vrstva takto vzniklou jednotku předá Internetové vrstvě, v našem příkladu IP protokolu a přidáním IP hlavičky vznikne IP datagram, zkráceně paket. Další postup závisí na použitém síťovém rozhraní, tedy v případě připojení stanice (hosta) na LAN se paketu přidá LAN záhlaví (header) a LAN zápatí (trailer) a vznikne rámec. Tomuto ději se říká zapouzdřování (encapsulation) a struktura výsledné jednotky (rámce) je patrná z Obr

4 Úloha síťové vrstvy s IPv4 protokolem Síťová vrstva (resp. Internetová vrstva realizovaná protokolem IP) v síťovém modelu TCP/IP zajišťuje potřebné směrování mezi jednotlivými dílčími sítěmi, a vyšším vrstvám tak vytváří iluzi jediné homogenní sítě. Sama však musí pracovat se skutečnou vnitřní strukturou resp. způsobem vzájemného propojení. Síťová vrstva se musí vyrovnávat i s konkrétními odlišnostmi jednotlivých dílčích sítí například s odlišným charakterem adres, s různou maximální velikostí přenášených paketů resp. rámců a jejich formátem, s odlišným charakterem poskytovaných přenosových služeb (spojovaných či nespojovaných) apod. Ovladač na úrovni vrstvy síťového rozhraní dokáže odstínit síťovou vrstvu od konkrétního způsobu ovládání příslušné sítě a přesného formátu datových rámců. Není ovšem již v jeho silách zastřít před síťovou vrstvou rozdíl v používaném mechanizmu adresování, resp. zajistit používání jednotných adres ve všech dílčích sítích. Tento jednotný způsob adresování může zajistit ažsíťová vrstva, která provádí tzv. jednotnou abstrakci, tedy sjednocení v: způsob adresování (IP adresy), Adresy, které protokol IP zavádí (IP adresy), jsou 32-bitové (u protokolu IP verze 4). Z pohledu transportní a aplikační vrstvy je lze interpretovat jako lineární (resp. jednosložkové) adresy - což odpovídá představě jediné homogenní sítě. Na úrovni síťové vrstvy se ale interpretují jako dvousložkové, tvořené číslem resp. adresou hostitelského počítače, a číslem resp. adresou (dílčí) sítě, ve které se tento hostitelský počítač nachází. IP adresy jsou pouze abstraktními adresami, které musí být posléze převedeny na skutečné fyzické adresy, protože ovladač na úrovni vrstvy síťového rozhraní, pokud dostane nějaká data k odeslání, musí spolu s nimi dostat i konkrétní fyzickou adresu, na kterou je má odeslat. Sám totiž s IP adresami nepracuje. Jde-li například o lokální síť typu Ethernet, dostane síťová vrstva (od vrstvy transportní) adresu cílového hostitelského počítače ve formě 32-bitové IP adresy, ale příslušný ovladač vrstvy síťového rozhraní musí získat 48-bitovou Ethernetovou adresu. K mechanizmu, jakým se v TCP/IP sítích zjišťuje korespondence mezi IP adresami a konkrétními fyzickými adresami, která se věnuje protokolu ARP. formát datových paketů používaných na síťové vrstvě (IP datagramy), Podobně jako jednotný formát adres a způsob adresování, zavádí protokol IP i jednotný formát přenášených dat na úrovni síťové vrstvy - již zmíněné IP datagramy. Jde o datové pakety, označované jako datagramy proto, že jsou přenášeny pomocí nespojované (datagramové) síťové přenosové služby. Na úrovni vrstvy síťového rozhraní jsou tyto datagramy přenášeny pomocí takových rámců, se kterými příslušná dílčí síť pracuje. Tyto se ovšem mohou obecně síť od sítě lišit. nespolehlivá nespojovaná přenosová služba z pohledu vyšších vrstev (transportní a aplikační). IP adresy Zápis - 4 -

5 32-bitové IP adresy lze vyjadřovat jako celá dvojková čísla. Pro člověka to ale není příliš srozumitelné, a tak se pro symbolický zápis IP adres zavedla konvence, označovaná jako tečkovaná desítková notace (dotted decimal notation). Spočívá v tom, že 32 bitů IP adresy se rozdělí na čtyři části po osmi bitech (oktety), a každá část se pak vyjádří jako celé desítkové číslo bez znaménka (s použitím tečky jako oddělovače jednotlivých částí). Příklad 4.1 Napříkladnepřílišsnadnozapamatovatelný tvar: tak dostává podobu: Maska Jak již bylo uvedeno, IP adresy jsou dvousložkové, tj. tvořené číslem resp. adresou (dílčí) sítě, ve které se hostitelský počítač nachází, a číslem resp. adresou tohoto hostitelského počítače. Jestliže všechny bity, které jsou vyhrazeny pro adresu sítě, budou nahrazeny binární 1 a převedeme takto vzniklé číslo na desítkové číslo podobně jako v předchozím příkladu, dostaneme masku sítě. Příklad 4.2 Adresa IP Adresa sítě (dekadicky) (proč je toto adresa sítěvizpříklad 4.3.) Adresa sítě (binárně) Maska sítě (binárně) Maska sítě (dekadicky) Maska sítě se taktéž často zapisuje tzv. délkou prefixu, která vyjadřuje počet jedniček v masce a píše se s lomítkem za adresu IP. Prefix představuje začátek adresy, který vyjadřuje adresu sítě. Totožné zápisy IP adresy a masky, resp. délky prefixu tedyjsou: / 16 Třídy IP adres Podle počtu bitů (z 32 celkem) využívaných pro adresu sítě a tedy i počtu bitů zbývajících pro uvažované stanice v rámci sítě dělíme IP adresy na třídy, viz Tab. 1. Původní filozofie TCP/IP počítá s malými (C), středními (B) a velkými sítěmi (A). Toto rozdělení se později ukázalo jako příliš hrubé a neefektivní, efektivnější řešení je možné vyčíst v kap o podsíťování

6 Speciální IP adresy Adresa sítě (často označována jako prefix) vznikne tak, že se všechny bity z části pro adresu hosta nahradí binární 0, jedná se o první adresu v rámci dané sítě. Matematicky se tato operace dá popsat logickým součinem jednotlivých bitů IP adresy a masky sítě. Příklad 4.3 Dána IP adresa ; je patrné, že je zetřídy B. Její standardní (výchozí) maska je , tedy adresa sítě je Výpočet: Adresa IP IP binárně Maska sítě (dekadicky) Maska sítě (binárně) Adresa sítě (binárně) Adresa sítě (dekadicky) Všesměrová (broadcast) adresa, je taková IP adresa, jejichž použitím lze poslat paket zároveň všem stanicím v rámci dané sítě. Vznikne tak, že všechny bity tvořící adresu hosta v rámci IP adresy se nahradí binární 1, jedná se tedy o poslední adresu v rámci dané sítě. Adresy použitelné pro koncové stanice v síti, jsou všechny adresy v rámci dané sítě v rozsahu mezi adresou sítě a všesměrovou adresou. Lokální smyčka (loopback), je to softwarová smyčka uvnitř počítače, adresy 127.x.x.x. Pakety s touto adresou nikdy neopustí počítač, vhodné např. pro mezi procesovou komunikaci. Veřejné adresy musí být v rámci celého Internetu unikátní a to je důvod, proč je jich nedostatek (v případě IPv4). Rozsahy vyčleněné pro privátní adresy jsou: Třída A (1 síť o možných hostech) Třída B (16 sítí o možných hostech) Třída C (256 sítí o 254 možných hostech) Lokální linkové adresy, rozsah až V případě, že se stanici nepodaří konfigurovat IP, např. v případě že nefunguje DHCP server, sama si nastaví IP z uvedeného rozsahu

7 IPv4 datagram Jak již bylo uvedeno v úvodu kap. 4.8, síťová vrstva zavádí jednotnou abstrakci i v případě formátu datových jednotek používaných na této vrstvě, tzv. IP datagramy, též nazývané pakety. IP paket je na úrovni síťového rozhraní vždy zabalen do rámce příslušné technologie (Ethernet, ), který se mění, tak jak paket prochází přes dílčí sítě. Zabalený paket však zůstává ve stejném formátu a nemění se, tedy s výjimkou proměnných polí, jako je hodnota čítače, která vyjadřuje životnost paketu (viz dále). Základní struktura paketu je naznačena na Obr. 21. Verze (version) 4 bity, obsahuje verzi protokolu IP a zajišťuje, aby ostatní systémy, které zpracovávají datagram během přenosu, mohly různá pole datagramu správně použít. Verze IPv4 zde má samozřejmě hodnotu 4. Délka záhlaví (headerlength) 4 bity, musí se uvádět, protože záhlaví může mít proměnnou délku v násobcích 32 bitů, kvůli volitelným položkám. Minimum je 5 slov (5 32 bitů = 20 bajtů) délky záhlaví, maximum 60 bajtů, nevyužité pozice musí být vycpány daty bez významu. Typ služby(type ofservice, ToS) 8 bitů, položka měla sloužit ke specifikaci požadované kvality přenosu IP datagramu. Směrování pak mělo brát ohled na hodnotutos a volit z alternativních tras tu, která nejlépe odpovídala požadavkům datagramu. V současnosti se položka používá k podobným účelům nese značku pro mechanizmy zajišťující služby s definovanou kvalitou služby (QoS). Celková délka IP datagramu (totallength) 16 bitů, definuje úplnou délku datagramu včetně záhlaví a uživatelských dat. Maximum je bajtů. Identifikace IP datagramu (identification) 16 bitů, primárně určeno k identifikaci k sobě patřících fragmentů, vždy přiděleno odesílatelem. Příznaky (flags) 3 bity, používají se dva: DF-bit (don t fragment) označuje případný požadavek na nepoužít fragmentace, tj. dodatečného dělení paketu na menší části. MF-bit (more fragments) říká, že datagram byl fragmentován a že bude následovat další část

8 Posunutí fragmentu od počátku (fragment offset) 13 bitů, indikuje pozici obsahu dat datagramu vzhledem k začátku původního (rozdělovaného) paketu. Doba životadatagramu (Time To Live - TTL) 8 bitů, tato hodnota definuje maximální počet skoků (hops), každý směrovač sníží při zpracování hodnotu položky o 1. Pokud již nelze hodnotu snížit, je paket zahozen. Protokol vyšší vrstvy (protocol) 8 bitů, obsahuje číselnou identifikaci protokolu vyšší vrstvy, který využívá IP datagram ke svému přenosu. Kontrolní součet záhlaví datagramu (headercheck sum) 16 bitů, je použit na záhlaví datagramu, pokud se při kontrole zjistí, že součet nesedí (došlo k chybě), paket se zahodí. IP adresa odesílatele/příjemce paketu (source/destination address) každá 32 bitů, jedná se o logickou adresu v rámci IP protokolu. Volitelné položky záhlaví (options) volitelně až do délky 40 bajtů, nevyužívá se příliš často, některé jsou dokonce zakázány. Např.: - zaznamenej směrovače (recordroute) zjištění kudy paket procházel, - zaznamenej čas (timestamp), - explicitní směrování (loose source routing) umožňuje výslovně zadat, přes které směrovače má být IP datagram dopravován (nemusí být uvedeny všechny), - striktní explicitní směrování (strict source routing) musí být zadány všechny mezilehlé směrovače. Přenášená data (payload) teoreticky až do bajtů délky (v součtu se záhlavím), jsou to údaje, které IP vrstvě předal protokol vyšší vrstvy, tedy např. TCP segment. IP tunelování Existují situace, kdy je nutné umožnit komunikaci počítačů ve vnitřních (firemních) sítích přes veřejný Internet, tj. je nutno propojit několik VPN sítí (Virtual Private Network). Tunelování zapouzdřuje původní IP paket do nového IP paketu, který má novou cílovou adresu, zpravidla bránu druhé VPN. Tato brána IP paket opouzdří a zašle skutečné cílové stanici. Tunelování prováděné ve spolupráci s IPsec protokolem zvyšuje bezpečnost VPN spojení. IP adresy bran na hranicích privátních a veřejných sítí jsou užity ke směrování. Celý obsah paketu včetně vnitřní IP adresy zdroje a cíle hostitelského počítače vnitřní sítě je skrytý vnějšímu světu

9 IP tunelování je velmi užitečné v situaci, kdy jsou dvě počítačové sítě používající stejný síťový protokol (např. IPv4) navzájem propojené sítí s odlišnou verzí protokolu IP, tedy IPv6, případně naopak. (O protokolu IPv6 je pojednáno v kap. 5.) Mezilehlá (transportní) síť pak musí přenášet pakety zabalené do nového záhlaví, aby byla schopna s nimi správně pracovat. Dochází tedy k tunelování původních paketů IPv4. Protokol ICMP Protokol ICMP (Internet Control Message Protocol- doslova protokol služebních hlášení) je služební protokol, což znamená, že nepřenáší žádná uživatelská data. Jedná se o klasický příklad aplikace typu klient-server. ICMP je součástí sady TCP/IP protokolů a slouží k signalizaci mimořádných událostí v síti. Jeho obsah se přenáší přímo v IP datagramech, viz Obr. 25 znázorňující zapouzdřování ICMP v prostředí Ethernetu. ICMP je určen pro informování o nějakém nestandardním stavu při doručování IP datagramů. Generují se např. při zahození datagramu, kdy se IP nestará o nápravu, ale pouze informuje odesílatele, že se tak stalo. Vybrané druhy ICMP zpráv shrnuje Tab

10 Protokol UDP UDP je jednoduchý protokol umožňující nespojovaný (connectionless) a nespolehlivý (nepotvrzovaný) přenos dat v anglické literatuře označováno jako besteffort. Jednotlivým přenášeným jednotkám se při použití protokolu UDP říká obvykle datagramy. Pokud je potřeba potvrzovat doručení, musí to být řešeno na úrovni aplikačního protokolu. Typickým příkladem přenosu využívajícího UDP je technika VoIP (Voiceover IP). Při přenosu hlasových dat není až tak důležité, aby byl doručen úplně každý datagram. Zpravidla totiž obsahuje jen malou část slova a jeho velikost by zbytečně narostla, kdyby měl každý z nich obsahovat mnoha-položkové záhlaví protokolu. Stejně tak je zbytečné, aby se přenášel datagram opakovaně, protože čekání na opakovaný přenos by komunikaci jen zpomalilo. Záhlaví UDP je tedy maximálně jednoduché, jak je patrné z Obr. 26 Protokol TCP TCP je na rozdíl od UDP spojově orientovaný (connectionoriented) a spolehlivý (potvrzovaný přenos) protokol. Mezi komunikujícími stranami nejdříve naváže spojení, až poté zahájí přenos dat. Datové jednotce na úrovni transportní vrstvy a využívající TCP se říká segment. Ztracený nebo poškozený segment je přenášen opakovaně. Zdrojový port (source port) 16 bitů, hodnota indikuje port na straně odesílatele segmentu, vybrané hodnoty portů viz dále. Cílový port (destination port) 16 bitů, hodnota indikuje port na straně příjemce segmentu, není zpravidla shodná se zdrojovým. Pořadové číslo odesílaného bajtu (semence number SEQ) 32 bitů, odesílané bajty se číslují, pole obsahuje pořadové číslo prvního z odesílaných v segmentu. Pořadové číslo potvrzovaného bajtu (acknowledgment number ACK) 32 bitů, jestliže máme obousměrnou komunikaci (což je většina případů), tak strana, která odesílá data, má

11 možnost v rámci hlavičky těchto dat potvrdit přijetí dat od protistrany. Uvádí se hodnota dalšího očekávaného bajtu, tj. např. když poslední správně přijatý bajt je číslován jako 100, pole obsahuje 101. Délka záhlaví (headerlength) 4 bity, délka záhlaví v bajtech. Příznakové bity (flags) 6 bitů, význam jejich nastavení na 1 je: URG (urgent) segment nese naléhavá data ACK (acknowledgment) indikuje, že hodnota uvedená v poli potvrzovaného bajtu je platná (tj. že segment zároveň i potvrzuje přijetí dat). PSH (pushfunction) signalizace, že data mají být ihned po přijetí předány aplikaci a nemá se čekat na přijetí dalších segmentů. RST (reset theconnection) pro řešení situace s duplikáty navazovacích segmentů, k odmítnutí spojení. SYN (synchronizesequencenumber) odesílatel začíná novou sekvenci číslování bajtů, využíváno při navazování spojení, viz dále. FIN (no more data fromsender) odesílatel ukončil přenos dat, využíváno při uzavírání spojení, viz dále. Délka okna (windowsize) 16 bitů, vyjadřuje maximální počet bajtů, které může vysílač odeslat, aniž by čekal na potvrzení od přijímače. Kontrolní součet (TCP checksum) 16 bitů. Ukazatel naléhavých dat (urgent pointer) 16 bitů, pole vyplněno jen když je příznakový bit URG nastaven na 1. Volitelné položky záhlaví (options) pole nemusí být přítomna, jejich délku lze odvodit z celkové délky záhlaví uvedené v příslušné pozici. ARP protokol Základní vlastnosti ARP Dynamický, distribuovaný protokol, schopný reagovat na změny v síti, určen k posílání datagramů na určitý uzel (koncovou stanici nebo směrovač) v lokální síti, kde neznáme její fyzickou/linkovou (MAC) adresu, ale známe adresu IP; v obecném případě zjištění adresy druhé úrovně na základě znalosti adresy třetí úrovně. informace o odpovídajících si adresách se ukládají do tabulky, podle potřeby se obnovují, položky jsou zpravidla uloženy pouze dočasně na několik minut a pak vymazány, protože se mohly stát neaktuální anebo již nejsou potřeba, ARP pracuje mezi linkovou a síťovou vrstvou, používá rámce linkové, např. u Ethernetu je v položce typ hodnota indikující ARP rovna 0x

12 Typ média (Hardware type) 16 bitů, hodnota indikující typ použitého média, např. pro Ethernet je hodnota 0x0001, ATM má 0x0010. Typ protokolu (Protocol type) 16 bitů, hodnota indikuje typ vyššího protokolu, v rámci něhož se logická adresa používá, pro IP je hodnota 0x8000. Délka fyzické adresy (Hardware length) 8 bitů, délka fyzické adresy v bajtech, pro Ethernet 0x06. Délka logické adresy (Protocollength) 8 bitů, délka logické adresy taktéž v bajtech, pro IPv4 adresu 0x04. Operace (Operation) 8 bitů, specifikuje operaci, kterou odesílatel paketu provedl hodnota 0x0001 pro požadavek na zjištění fyzické adresy, hodnota 0x0002 pro odpověď. Fyzická adresa zdroje / hledaná (Sender / target hardware address) délka je specifikována v poli délka fyzické adresy, obsahuje fyzickou adresu zdroje / hledanou. Logická adresa zdroje / hledaná (Sender / targetlogicaladdress) délka je specifikována v poli délka logické adresy, obsahuje logickou adresu zdroje / hledanou. DHCP protokol DHCP je aplikační protokol pro dynamické nastavení parametrů sítě (IP adresa, maska sítě, výchozí brána, DNS servery, ). Funguje na principu klient-server. DHCP server propůjčí tyto parametry sítě síťové stanici na určitou dobu. Po této době musí stanice žádat o adresu znovu. DHCP server u každého klienta eviduje IP adresu a čas, do kdy ji klient smí používat (doba zapůjčení, leasetime). DHCP protokol je rozšířením staršího BOOTP protokolu, který přiděloval IP adresy na neomezenou dobu. DHCP je s BOOTP obousměrně kompatibilní. To znamená, že DHCP klienti dovedou získat nastavení z BOOTP serveru a DHCP server může přidělit IP adresu BOOTP klientovi (zde je třeba opatrnosti, protože BOOTP klient bude jednou přidělenou IP adresu používat užnavždy). DHCP využívá transportního protokolu UDP, klient komunikuje na UDP portu 68, server naslouchá na UDP portu

13 Princip fungování DHCP Na Obr. 37 je naznačen průběh komunikace při použití protokolu DHCP. Po připojení do sítě klient vyšle broadcastem DHCP_DISCOVERY paket. Na ten odpoví DHCP server paketem DHCP_OFFER s nabídkou IP adresy. Klient si z nabídek (teoreticky od několika DHCP serverů v rámci sítě) vybere jednu IP adresu a o tu požádá paketem DHCP_REQUEST (taktéž broadcast). Server mu ji vzápětí potvrdí odpovědí DHCP_ACK. Jakmile klient obdrží DHCP_ACK, může už IP adresu a zbylá nastavení používat. Klient musí před uplynutím doby zapůjčení uvedené v DHCP_ACK obnovit svou IP adresu. To se provádí zkráceně, zasláním DHCP_REQUEST zprávy (přímo DHCP serveru) a server následně odpoví DHCP_ACK s novou dobou zapůjčení. Pokud lhůta uplyne, aniž by klient dostal nové potvrzení, musí IP adresu přestat používat. Protokol definuje i roli tzv. DHCP relay agenta. Používá se v situaci, kdy existují dvě nebo více sítí oddělené směrovačem a jen jedna síť má DHCP server. V takovém případě správce na směrovači zapne relay agenta a nastaví jej tak, aby všesměrové (broadcast) DHCP dotazy ze sítí bez DHCP serveru přeposílal do té sítě, která ho má. Agent k přeposílanému dotazu přidá masku té sítě, kde klienta zaslechl, aby DHCP server poznal, ze kterého adresního rozsahu má klientovi adresu přiřadit

14 Překlad adres - NAT NAT, česky překlad síťových adres, je funkce směrovače pro změnu IP adres paketů jím procházejících, kdy se zdrojová nebo cílová IP adresa převádí mezi různými rozsahy. Nejběžnější formou je, když směrovač IP adresy z nějakého rozsahu mění na svoji IP adresu a naopak tím umožňuje, aby počítače ve vnitřní síti (LAN) vystupovaly v Internetu pod jedinou IP adresou. Tuto funkci podporují prakticky všechny běžné směrovače. Technika překladu (IP) adres tedy umožňuje oddělit intranet od Internetu, což může být z bezpečnostního hlediska výhodné. Směrovač, na kterém běží NAT, musí být schopen navenek nějakým způsobem odlišit provoz jednotlivých stanic z vnitřní sítě do Internetu. To provádí na základě tabulky překladu adres, kterou si po celou dobu spojení drží v paměti. Ve většině případů má k dispozici jen jednu (veřejnou) IP adresu, která je přiřazena na jeho tzv. WAN (Wide Area Network) port a ve vnitřní sítí je více (privátních) IP adres. V tomto případě si směrovač nevystačí pouze se síťovými adresami a musí použít i vyšší (transportní) adresy porty. V případě využití kombinace IP adres a portů není název NAT úplně správný, v takové situaci se jedná o kombinaci služeb NAT s PAT (Port Address Translation), někdy označovanou NAPT (Network Address Port Translation). Název NAT se však v tomto významu běžně používá. NAT můžeme dělit na dva základní druhy: SNAT = Source NAT, překlad zdrojové IP adresy a případně portu. Překlad byl zahájen záměnou zdrojové IP (a portu). Následná záměna cílové IP (a portu) už pouze souvisí s první provedenou změnou a je nezbytná pro správné fungování přenosu. DNAT = Destination NAT, překlad cílové IP adresy a případně portu. Primárně se používá k zveřejnění služby z interní sítě na veřejně přístupnou IP. Technika NAT může byt použita při přenosu paketu i vícekrát. Z jednoho bodu v komunikačním řetězci nelze stanovit, zda po trase někde k překladu dojde nebo ne. Překlad

15 adres může probíhat i mezi verzemi protokolu IP (IPv4 a IPv6) PT = protokol translation, častěji se však setkáme s technikou IP tunelování. Překlad nemusí být vždy nutně mezi veřejnou a privátní IP, může probíhat i tak, že se změní veřejná IP na jinou veřejnou IP adresu, pokud je to výhodné. Stejně tak se může změnit privátní adresa na jinou privátní. Vždy však platí, že jsou zaměňovány adresy ze dvou různých sítí, případně dvou různých podsítí. V některých zdrojích je možné nalézt ještě další způsoby rozdělení, obecně lze konstatovat, že druhů NAT je definováno mnoho. Častým případem je, že jeden konkrétní výrobce hardware implementuje NAT s nějakým konkrétním vylepšením a marketingově ho označí upraveným názvem. Toto však z našeho pohledu není podstatné. Problémy a výhody NATu Z předcházejícího textu je zřejmé, že NAT přináší i jistá omezení. Problém spočívá v tom, že při použití techniky NAT ztrácíme jednu ze základních předností Internetových sítí postavených na sadě TCP/IP obousměrnou konektivitu typu end-to-end. Přímé spojení dvou koncových uzlů je s použitím techniky NAT vždy nějakým způsobem omezeno. To může být problematické pro některé Internetové protokoly, např. FTP (více viz kap ). Nejvíce problematická je situace, kdy oba koncové systémy jsou odděleny od vnějších sítí prostřednictvím NATu. Za určitou nevýhodu je možné považovat i určité časové zpoždění, které s NATem nutně souvisí. Je logické, že překlad adres zabere více času, než jednoduché směrování. Navíc směrovač kromě záměny adres (a případně i portů) ještě musí následně přepočítat kontrolní součty v záhlavích (IP a UDP nebo TCP). Tyto kontrolní součty totiž berou v úvahu i IP adresy a porty. Při jejich změně bez přepočítání kontrolních součtů by došlo v cílové destinaci k zahození paketu. Bezpečnostní výhody NATu již byly uvedeny. V případě použití SNATu může komunikace vzejít pouze z vnitřní sítě. Z vnějšku nemůže být spojení zahájeno (to lze pouze s DNAT), cožuživatele ochrání před mnohými škodlivými útoky. Za velmi podstatnou výhodu se také v případě IPv4 sítí považujeúspora veřejného adresního prostoru. V případě nasazení totiž mohou být za NATem schovány privátní IP adresy, jejichžpoužití může být v rámci celého Internetu neomezeně opakované. Samozřejmě za předpokladu, že tyto sítě jsou do veřejného Internetu připojeny prostřednictvím NATu. Jmenný systém DNS DNS je aplikační protokol využívající transportní porty UDP/53 i TCP/53. Jak bylo uvedeno dříve, IP adresy představují abstrakci na úrovni síťové vrstvy. Větší počet těchto adres je však pro člověka jen těžko zapamatovatelný. DNS tak vytváří ještě vyšší úroveň abstrakce, konkrétně na aplikační úrovni. Síťovým IP adresám je přiřazeno relativně snadno zapamatovatelné jméno (DNS název). Výjimka z tohoto systému je zřejmá samotný DNS server musí být zadán IP adresou, aby bylo možné s ním komunikovat. DNS primárně zajišťuje (decentralizovaným způsobem) překlad jména hostitele (počítače) na jeho IP adresu a naopak. Systém je založenna principu klient server, jedná se o distribuovanou datovou službu. Server DNS není pouze jeden, jsou organizovány hierarchicky, stejně jako jsou hierarchicky tvořeny názvy domén, viz Obr. 41. Vazby mezi jmény počítačů a IP adresami jsou uloženy v DNS databázi, která je celosvětově distribuována. Základní jednotkou systému je tzv. jmenný server (name server), často nazývaný DNS server

16 Domény a doménová jména Počítače jsou organizovány v hierarchii domén, viz Obr. 41. Doménou je skupina počítačů, které jsou v nějakém vztahu vůči sobě (buď tvoří nějakou organizační jednotku, nebo jsou geograficky blízko sebe). Např. doména.edu je vyhrazena pro americké univerzity, naproti tomu.czsdružuje počítače patřící do České republiky. V doméně se mohou vyskytovat jak koncové počítače, tak subdomény (FirmaA.cz), které se opět mohou dělit (FirmaA.cz > Marketing, Vyroba, Vyvoj), kvůli lepší údržbě a snazší symbolické identifikaci. Doménové jméno se vždy vyhodnocuje zprava doleva, od nejvyšší úrovně (root) po nejnižší. Každý uživatel Internetu dnes považuje za samozřejmé, že doménový název je tvořen několika řetězci znaků oddělených tečkami. V základním systému DNS platí, že celková délka jména může být maximálně 255 znaků a jeden dílčí řetězec maximálně 63 znaky. Takto dlouhé jména se však používají jen v ojedinělých případech, většinou jsou řetězce dlouhé 4 až 10 znaků (utko, vutbr, seznam atd.), s výjimkou root zóny, kde jsou řetězce dlouhé 2 až 4 znaky (cz, int, eu, arpaatd). Povolené znaky jsou pouze písmena (bez diakritiky a nezáleží, zda velká nebo malá), číslice a pomlčky. Platí pravidlo, že pomlčka nemůže být na začátku ani na konci řetězce. Existují i rozšíření, která umožňujípoužívat v systému DNS další znaky. Jestliže se však budeme držet těchto základních pravidel, vyhneme se zbytečným problémům. Zóny Jmenný prostor (namespace) se rozděluje na domény. Doména však může být sama o sobě dosti velká oblast, proto existuje ještě další rozdělení na tzv. zóny, které již zpravidla obsluhují samostatné DNS servery. Data o doméně, která jsou uložena na DNS serveru, se nazývají zónou. Rozdíl mezi doménou a zónou je následující: do domény spadají všechny počítače, které mají společné jméno domény, kdežto do zóny patří pouze ty počítače, které mají společný také primární DNS server. V normálním režimupoužívají koncové počítače protokol UDP, délka paketu je omezena na 512 B, tak aby nehrozila jeho fragmentace. Protokol TCP je používán ke komunikaci mezi dvěma DNS servery k tzv. zónovým přenosům (zone transfer). Zónové přenosy slouží k zálohování DNS databází z primárního serveru na sekundární. (Na primárním serveru správce udržuje databázi a ta se pak automaticky a pravidelně přenáší na sekundární servery zálohy pro případ výpadku primárního serveru)

17 Způsob komunikace v DNS systému Stanice, která chce komunikovat s vyšle dotaz na DNS server (name server), ten se podívá do svých záznamů a v odpovědi zašle IP adresu. Stanice pak již může přímo kontaktovat požadovaný stroj. Pokud DNS server nenalezne potřebný záznam ve své paměti, kontaktuje nadřazený DNS server (pokud takový existuje) nebo kořenový (root) DNS server. Tato komunikace je však klientovi systému DNS skryta a probíhá přímo mezi servery DNS. Resolver Ve skutečnosti je fungování překladu mírně složitější, než bylo popsáno výše. V rámci operačního systémů existuje tzv. resolver. Je to klient, který zprostředkovává stanici (všem aplikacím ftp, www, telnet atd) případné dotazy na DNS servery. Nežresolver kontaktuje DNS server, vždy prověří, zda není požadovaný překlad definován staticky, případně zda daný překlad již nebyl v nedávné době proveden a není uložen v lokální dočasné paměti (cache). Dotazování na DNS server je zpravidla vícenásobné i při jediném překladu. Vysvětlení je podáno na následujícím příkladu. Na DNS serveru se také vyskytuje resolver, který pracuje podobně jako ten na běžné stanici. Pracuje s lokální databází (a cache) a v případě, že při vyřizování dotazu od klienta nenalezne odpovídající záznam, kontaktuje vzdálený (např. nadřazený) DNS server. Jestliže získá odpověď, přepošle ji jako odezvu na původní dotaz klienta. Primární a sekundární DNS servery Data o překladech jsou na DNS serverech uloženy na pevném disku a po jeho spuštění se načtou do paměti. To platí pro primární DNS server v dané zóně. SekundárníDNS server získává data tzv. zónovým transferem, který probíhá v pravidelných časových intervalech. Tato data jsou pak označována jako autoritativní (nezvratná) daný server je pro zodpovězení daného dotazu autoritou. DNS server nevystačí pouze s daty o své zóně, potřebuje i nějaké informace o svém okolí. Jsou to informace o kořenových DNS serverech a případně i dalších serverech DNS. Tato data se označují jako neautoritativní. Jako neautoritativní jsou označeny i DNS odpovědi, které DNS server získal z databáze jiné zóny. DNS server tím dává uživatelide facto najevo, že za danou informaci nemůže sám ručit

18 Kořenové DNS servery Kořenové (root) DNS servery obsluhují root doménu. Tyto servery jsou využívaný běžnými DNS servery k přesměrování na jiné (místní) doménové servery. Způsob, jakým jsou využívány kořenové DNS servery, je patrný z Obr. 43. Popis následuje. V prvním bodě (1) resolver zformuluje dotaz a zašle ho na místní DNS server. DNS server zkontroluje svoje záznamy a v případě, že nalezne hledaný překlad, odpověď odešle. K tomu však v tomto příkladu nedošlo. V dalším kroku (2) proto místní DNS server kontaktuje některý z kořenových serverů s dotazem na překlad, přičemž bude zpravidla odkázán na doménový server nejvyšší domény, v příkladu.cz. Situace se opakuje, místní server kontaktuje doménový server s dotazem na překlad (3) a ten, pokud není sám schopen překladu, provede odkázání na doménový server druhé úrovně, který spravuje konkrétní subdoménu. Pokud tento DNS server již disponuje požadovanou informací, provede se překlad (4), může však i v tomto kroku dojít na odkázání se na jiný (více zanořený) DNS server. Po obdržení informace o překladu si tento záznam místní DNS server uloží do dočasné paměti (5) a poskytne ji klientovi (6), který celý proces inicioval. Věty RR DNS záznamy, tj. informace (nejen) o doménových jménech a odpovídajících IP adresách, jsou uloženy v záznamech nazývaných věty RR (ResourceRecords). V případě, že resolver (DNS klient) požaduje po serveru získání informací, pak požaduje po DNS serveru věty RR podle svých požadavků. Vybrané typy vět RR jsou A (A host address) 32-bitová IPv4 adresa, slouží jako výsledek překladu. NS (Authoritativename server) doménové jméno DNS serveru, který je autoritou pro danou doménu, používá se k přesměrování na jiný DNS server. PTR (Domainname pointer) přenos doménového jména, využito k reverznímu překladu

19 AAAA (IPv6 address) 128-bitová IPv6 adresa, slouží jako výsledek překladu. CNAME (Canonicalnameforan alias) doménové aliasy (další možné názvy domény, které odkazují na stejný stroj). Na typu věty RR je závislá pouze datová část DNS zprávy, záhlaví má obecný formát, jenž je naznačen na následujícím Obr. 44. Formát DNS paketu DNS protokol definuje pouze několik typů operací. Především se jedná o DNS QUERY a DNS QUERY RESPONSE. Význam je zřejmý, první typ je dotazem na překlad, druhý je odpověď. DNS využívá stejný formát paketu jak pro dotaz (query), tak pro odpověď (query response). Délka je proměnná, základních polí může být až pět, povinné je však pouze jedno. Jsou to: HEADER (záhlaví) jediná povinná položka, obsahuje mnoho polí, např. identifikaci dotazu, čísla určující počty dotazů a odpovědí v paketu, typ paketu, informaci o (ne)autoritativnosti odpovědi, případné chybě a další. QUERY (dotaz/dotazy) obsahuje název překládané domény, její typ a třídu dotazu. Typ domény je většinou IN = Internet, Třída dotazu nejčastěji A (požadavek na získání IPv4 adresy), případně požadavek na jinou větu RR (viz vybrané věty RR). ANSWER (odpověď/odpovědi) odpověď se skládá ze stejných tří údajů, jaké byly v dotazu, navíc jsou přidány položky tak, jak je naznačeno na Obr. 43, podle toho o jako větu RR se jedná. AUTHORITY (autoritativní DNS servery) informace o autoritativních DNS serverech (uvedeno ve větách typu NS). ADDITIONAL (doplňující informace) tato sekce obvykle obsahuje IP adresy autoritativních DNS serverů. Další definované operace jsou např. DNS NOTIFY a DNS UPDATE. DNS NOTIFY je mechanizmus, který umožňuje informovat servery o změně dat v zóně. Zpravidla to funguje tak, že primární server touto zprávou vyzve sekundární server k zahájení zónového přenosu, aniž by se čekalo na vypršení dříve stanoveného časového limitu. Dojde tedy k mimořádné synchronizaci databázi mimo pevně stanovený časový rámec. Běžně se používá technika tzv. inkrementálního zónového přenosu, kdy se přenáší pouze změněná data, nikoliv celá databáze. DNS UPDATE umožňuje dynamicky opravovat záznamy v DNS databázi. Záznamy v databázi je tedy možné přidávat, editovat nebo odebírat i vzdáleně

20 Princip protokolů a zálohování výchozí brány Páteřní (tranzitní) počítačové sítě jsou od svých počátků budovány tak, že v topologii existuje mezi dvěma uzly více než jedna cesta. V případě výpadku by tak měla existovat vždy záložní trasa. Toho lze zpravidla docílit prostřednictvím zvýšeného počtu linek a také aktivních prvků. Situace je demonstrována na Obr Jestliže dojde k výpadku jedné z linek nebo jednoho ze směrovačů v tranzitní části sítě, přenos paketů mezi LAN1 a LAN2 je stále možný. O používání funkčních tras a deaktivaci nefunkčních se postará použitý směrovací protokol. Pro fungování lokální sítě je však důležitá i dostupnost výchozí brány, která zprostředkovává komunikaci stanic s okolním světem. Bylo by tedy dobré zálohovat i gateway sítě. Situace je znázorněna na Obr Více směrovačů můžeme do sítě zapojit snadno. Problém nastává v konfiguraci koncových stanic, jelikož IP konfigurace obsahuje pouze jednu IP adresu výchozí brány Když chce stanice komunikovat se svojí výchozí bránou, kterou zná pouze pod IP adresou, využívá k tomu protokol ARP, viz kap Díky zjištění fyzické adresy směrovače (přes protokol ARP), je možné následně odesílat pakety ven ze sítě. V případě, že výchozí brána neodpovídá, nedokáže stanice zjistit sama od sebe, že má komunikovat s jinou výchozí bránou, i pokud taková na síti je. Automatickou konfiguraci zálohování výchozích bran umožňují protokoly pro zálohování brány, anglicky jednoduše redundancy protocols, resp. specifičtější first hop redundancy protocols. Základní myšlenkou všech protokolů je, že řešení těchto problémů provádí síť, resp. směrovače, bez jakékoliv kooperace s koncovými stanicemi. Protokoly redundance výchozí brány dělíme na dvě základní skupiny: protokoly, které umožňují pouze zálohování dostupnosti výchozí brány (HSRP = Hot Standby Router Protocol, VRRP = Virtual Router Redundancy Protocol), protokoly, které umožňují nejen zálohovat zdroje, ale i rozkládat zátěž mezi aktuálně dostupné výchozí brány (load-balancing) (GLBP = Gateway Load Balancing Protocol)

21 Protokoly nadbytečnosti umožňují dvěma (a někdy i více) směrovačům sdílet jednu virtuální IP adresu a virtuální MAC adresu. Tato virtuální IP je pak konfigurována na koncových stanicích a virtuální MAC je odesílána jako fyzická adresa výchozí brány stanicím, prostřednictvím odpovědi na ARP dotazy. Kdo ze směrovačů bude aktuálním držitelem virtuálních parametrů, je následně záležitostí protokolů redundance. Virtuální IP adresy brány je stanicím zpravidla poskytována prostřednictvím standardního DHCP procesu. 2) Multicastový přenos dat: typy přenosu (unicast, broadcast, multicast, anycast), výhody a nevýhody multicastového přenosu dat, podpůrné protokoly multicastu, principy směrování multicastového provozu Typy přenosu Unicast Přenos z jednoho bodu do druhého (one-to-one), z přesně specifikovaného zdroje do jednoznačně identifikovaného cíle. Jedná se pravděpodobně o nejpoužívanější způsob přenosu dat. V případě více příjemců stejných dat je tento způsob neefektivní, viz Obr Broadcast Přenos z jednoho bodu sítě do všech ostatních v rámci sítě nebo podsítě (one-to-all). K tomuto účelu se využívají všesměrové adresy, viz kap Všechny stanice na síti obdrží tuto zprávu a všechny se musí zabývat jejím zpracováním. Výhodou je úspora přenosového pásma a komunikačně snadná dostupnost všech přítomných stanic, nevýhodou je zatížení stanic, kterých se zpráva netýká. V případě velkého podílu všesměrových zpráv na celkovém objemu provozu může jít o velmi významné zatížení, které je třeba omezit. Cestou je rozdělení sítě na podsítě s dílčími broadcastovými zónami. Multicast Tradičně se jedná o přenos z jednoho zdroje ke skupině příjemců (one-to-many). Může však nastat i situace, kdy je zdrojů více, viz dále (many-to-many). Přenos je praktikován s maximální možnou efektivitou, co se týká spotřeby pásma, jelikož se od zdroje vysílá pouze jedna kopie dat, která se postupně cestou k adresátům podle potřeby větví vytvářením kopií. Vytváření kopií je úlohou směrovačů a přepínačů, které musí pro správné fungování celého systému multicast podporovat. To způsobuje vyšší požadavky na síťové prvky. Rozdílnost přenosu dat metodou unicastu a multicastu od jednoho zdroje dat ke skupině příjemců je znázorněna na Obr Jak je patrné z obrázku, efektivita multicastového přenosu má vliv na šířku blokovaného pásma mezi zdrojem dat a R1, dále mezi R1 a R2 a také mezi R2 a S1 a také mezi R2 a S2. Na koncových segmentech již samozřejmě není možné dosáhnout úspory. Ušetřené pásmo je enormní zejména v případech, kdy je počet příjemců na jedné síti vysoký. Využití multicastu tak často významně zvyšuje počet možných (souběžných) příjemců dat, který je v případě unicastu limitován šířkou pásma nejpomalejší linky. Model one-to-many je výhodný zejména pro přenos audia, videa, monitorovací a oznamovací systémy. V případě, že některý z přijímačů potřebuje přenést data zpátky ke zdroji, model přechází v many-to-one. Častější je však many-to-many, kdy může být provoz generován prakticky kýmkoliv ze skupiny

22 Anycast Tento méně známý způsob přenosu, česky nazývaný jako výběrový přenos je více popsán až v souvislosti se sadou IPv6, viz kap a Spočívá v tom, že více míst v síti vystupuje pod jednou adresou a komunikace vždy probíhá se zařízením, které je nám nejblíže, případně nejlépe dostupné (one-to-nereast). Výhody a nevýhody multicastu Multicast je řešením dvou spolu souvisejících otázek: Jak co nejefektivněji doručit stejná data více příjemcům tak, aby docházelo k maximálně efektivnímu využívání linek, tj. aby každý datový proud tekl každou linkou maximálně v jedné kopii a duplicity se vytvářely pouze tam, kde je to nezbytně nutné? Jak zajistit, aby uzly a linky, kde není žádný příjemce dat, nebyly příslušným datovým proudem zahlcovány? Výhody multicastu Efektivita oproti unicastu, která je více než zřejmá. Optimalizace zpracování méně paketů znamená jejich rychlejší zpracování na přenosové trase Distribuované aplikace, které jsou často bez multicastu nerealizovatelné Multicastové aplikace zpravidla jako transportní využívají protokol UDP, tj. přenos bez spojení a potvrzování o doručení (best-effort). Z principu není možné použít protokol TCP, který je postaven na mechanizmu budování spojení mezi dvěma komunikujícími stranami. Nevýhody pramení především z nevyhnutelnosti použití protokolu UDP: Multicast postrádá řízení proti zahlcení nestará se o to, zda svojí datovou náročnosti neblokuje kapacitu celé linky, nezpůsobuje zahlcení sítě Vznik nežádoucích duplicitních paketů mohou vzniknout při změně multicastové topologie, aplikace s tím musí počítat Doručení paketů v jiném pořadí ke kterému může dojít taktéž při změně topologie multicastového přenosu

23 Nespolehlivost přenosu pokud je potřeba určitá míra spolehlivosti, musí být řešena na aplikační vrstvě. U některých aplikací určitá míra ztrátovosti nemusí vadit. Možnost nežádoucího odposlechu souvisí s možností snadno se připojit ke skupině a data tak přijímat Podpůrné protokoly Multicastu Z předcházejícího textu by měly být patrné hlavní myšlenky a parametry multicastu. Bystrého čtenáře bezpochyby napadlo, že sám o sobě nemůže multicast fungovat a že musí existovat nějaké komunikační protokoly, které budou systém spravovat. Nejdůležitějšími protokoly jsou IGMP (Internet Group Management Protocol) (kap ) a PIM (Protocol Independent Multicast) (kap ). Nejzásadnější rozdíl mezi těmito protokoly je, že IGMP je určen na výměnu informací mezi koncovými stanicemi a směrovači, zatímco PIM na komunikaci mezi směrovači, jak je vidět z příkladu na Obr Druhy multicastového přenosu Multicastový přenos zpravidla klasifikujeme dle počtu a přesnosti určení zdrojů dat. Rozlišujeme dva druhy - any source multicast (ASM) neboli multicast s různými zdroji dat, také many-tomany. Identifikace skupiny ASM je prováděna prostřednictvím notace (*, G), kde * reprezentuje libovolný zdroj dat, G (group) pak adresu multicastové skupiny. Podrobněji viz dále. - specific source multicast (SSM) neboli multicast se specifickým zdrojem dat, také one-to-many. Identifikace skupiny SSM bývá zapisována ve formátu (S, G), kde S značí zdroj dat (source) a G značí obdobně jako u typu ASM adresu skupiny (group). Podrobněji viz dále. Internet Group Management Protocol (IGMP) Základní úlohou protokolu IGMP je umožnit koncovým stanicím připojení do multicastové skupiny. Protokol tedy slouží ke komunikaci mezi stanicemi a směrovači. Zprávy protokolu IGMP nejsou směrovány Internetem, jejich platnost je omezena pouze na lokální síť. Protokol IGMP existuje v současné době ve třech verzích, přičemž verze 1 je dnes již historická (RFC 1112) a používá se převážně verze 2 (RFC 2236). Tyto dvě verze mohou spolu za určitých okolností koexistovat. Verze 3 je plně funkční, ale oficiálně v tzv. fázi navrhovaného standardu

24 (RFC 3376, resp. RFC 4604 z roku 2006, které popisuje i MLDv2 (Multicast Listener Discovery), což je obdoba IGMP pro IPv6 (konkrétně součást protokolu ICMPv6), více viz kap. 5.8). IGMPv1 První verze protokolu je postavena na jednoduchém principu, že směrovač zasílá do lokální sítě periodicky paket membership query (dotaz na členství) na multicastovou adresu Stanice pak odpovídají na tento dotaz zprávou membership report (zprávy o členství) postupně na všechny adresy skupin, ke kterým se chtějí připojit. V případě, že již stanice nechce být v dané skupině, žádným způsobem o tom router přímo v IGMPv1 neinformuje. Stanice pouze nereaguje na další zprávu membership query. Z předcházejícího je patrné, že každá zpráva směrovače membership query by měla spustit lavinu zpráv membership report od všech členských koncových stanic. To samozřejmě není žádoucí, takže byla vyvinuta technika, která tento jev potlačuje. Klíčovou myšlenkou je, že každá stanice pracuje s určitým náhodným zpožděním pro každou skupinu, jíž je členem. Zprávu membership report tedy neodesílá hned, ale až po vypršení tohoto náhodně zvoleného intervalu. Pokud však stanice zachytí zprávu vyslanou jinou stanicí, která zvolila kratší zpoždění, automaticky nastavuje nový časovač a čeká na jeho vypršení. Tím se zprávy membership report rozprostřou co nejvíce mezi dvě následující membership query. Dokonce může dojít i k tomu, že zprávu membership report nestihnou v daném intervalu odeslat všechny stanice, to však není problém z pohledu směrovače. Pro něj je důležité především, zda existuje alespoň jeden příjemce, a ne už tak jejich celkový počet. Z pohledu přepínačů a funkce IGMP snooping, viz kap , to však není žádoucí. K zastavení multicastového přenosu do lokální sítě dochází z pohledu směrovače až v situaci, kdy nebyla na několik (počet není pevně stanoven) zpráv membership query žádná odpověď od stanic lokální sítě. IGMPv2 Druhá verze vznikla jako odezva na problémy, které ukázalo prvotní nasazení IGMPv1. Hlavním přínosem druhé verze je zpráva, která umožňuje okamžité opuštění skupiny. To je důležité zejména v případě širokopásmových multicastových přenosů a také v situacích, kdy se členství skupin rychle mění. IGMPv2 má velmi jednoduché záhlaví, viz Obr Možné typy zprávy jsou následující čtyři: Membership query dotaz na přijímané skupiny koncových stanic na lokální síti, případně dotaz pouze na konkrétní skupinu, která je specifikována v poli Adresa skupiny Version 2 Membership Report nová verze zprávy, kterou stanice ohlašuje zájem zapojit se do multicastové skupiny Leave group opuštění skupiny Version 1 Membership Report zpráva z první verze protokolu z důvodu kompatibility a možné koexistence obou verzí protokolu

25 Pole časový limit odezvy obsahuje informaci o čase, který stanice mají jako limit pro odeslání své odezvy (membership report). Jednotkou jsou desetiny sekundy. Toto pole má smysl pouze ve zprávě od směrovače, tj. membership query a v ostatních by měla být hodnota tohoto pole nulová. Kontrolní součet je v případě IGMPv2 paketu počítán z celé datové části IP paketu, tedy s výjimkou IP záhlaví. Pole Adresa skupiny nese informaci o adrese multicastové skupiny, v případech, kdy je to smysluplné. To jsou všechny typy zpráv s výjimkou obecného membership query. Popis fungování protokolu ve verzi 2 je obdobný jako pro verzi 1, některé oblasti fungování jsou rozebrány dále. Směrovače využívají protokol IGMP k zjišťování jaké skupiny mají své členy na lokální síti. Směrovač si udržuje seznam takovýchto skupin, informaci o tom, zda existuje alespoň jeden člen skupiny a odpovídající hodnoty časovače. Směrovač ve výchozím stavu posílá do sítě periodicky zprávy membership query a bývá nazýván z pohledu IGMP jako Querier. Obecně platí, že pokud je do lokální sítě připojeno více směrovačů, pouze jeden z nich by měl do této sítě vysílat zprávy membership query. Výchozí hodnota pro opakování zprávy query je 125 sekund, z počátku po (re)startu směrovače, je však žádoucí tento interval výrazně zkrátit, aby se co nejdříve zjistilo, jaké skupiny mají na lokální síti aktivní členy. Z pohledu stanice je pak po přijetí této obecné zprávy (membership query general) zahájen časovač s náhodnou hodnotou zpoždění pro každou skupinu, které je stanice členem. Náhodná hodnota je vybrána z intervalu až do hodnoty uvedené v poli časový limit odezvy zprávy membership query. Standardně je limit 10 sekund. Jestliže je tedy stanice jediným členem dvou skupin na lokální síti, po zprávě membership query odešle první membership report např. po dvou sekundách, druhý např. po osmi sekundách. Na Obr. 4-5 je zachycen provoz reálné stanice na síti. Z obrázku je patrné, že interval mezi dvěma zprávami membership query od směrovače byl skutečně 125 sekund, v okně jsou vidět celkem tři tyto zprávy a vždy i dvě odezvy stanice na tuto výzvu po náhodném časovém intervalu v rozmezí 0 až 10 s. Ve spodní části obrázku je jako ukázka detail obsahu zprávy query od směrovače. Pokud by na síti byl další člen stejné skupiny, také by reagoval na zprávu query. Jedna ze stanic by zvolila menší hodnotu časovače a odeslala tak daný report dříve. Druhá stanice obdrží tento report také a v tuto chvíli zastaví vlastní časovač a zprávu membership report již z důvodu zbytečné duplicity neodesílá. Pokud po nějakou (ne přesně danou) dobu na zprávu směrovače (query) žádná stanice neodpovídá, směrovač to vyhodnotí tak, že skupina již nemá lokální členy a případný provoz této skupiny z vnějšku již nebude do lokální sítě posílat. Z předcházejícího by se mohlo zdát, že stanice musí na možnost nového připojení k multicastové skupině čekat dokud neobdrží zprávu query, a pak teprve odeslat zprávu report. V nejhorším případě by stanice čekala 125 sekund. To je samozřejmě neúnosně dlouhá doba a proto stanice, která se chce nově připojit k nějaké skupině, vysílá zprávu Version 2 Membership report okamžitě a bez vyzvání. Zpravidla se zpráva odesílá pro jistotu několikrát za sebou, z důvodu předcházení chyby způsobené ztrátou paketu. Pokud chce stanice opustit multicastovou skupinu, měla by odeslat jako odezvu na query zprávu leave group. Tato zpráva se odesílá na adresu všechny lokální směrovače, takže ostatní stanice ve skupině ji neobdrží. Z důvodu dlouhého časového prodlení však i zde existuje možnost odeslat zprávu leave group okamžitě bez jakékoliv výzvy

26 IGMPv3 Poslední verze IGMP protokolu je opět navržena tak, aby byla umožněna určitá míra zpětné kompatibility s nižšími verzemi, viz dále. Základním přínosem IGMPv3 je rozšíření schopností příjemců o možnost požadovat nebo filtrovat provoz z individuálních zdrojů v rámci multicastové skupiny. Stanice si tedy mohou vybírat, od koho budou nebo nebudou provoz přijímat, v případě že je těchto zdrojů více. Implementace IGMPv3 musí obsahovat podporu pro následující zprávy: - Membership query nová verze s více informačními poli, viz dále - Version 3 Membership Report nová verze zprávy se složitější strukturou. Umožňuje stanici informovat směrovač o stavu příjmu multicastu, případně o změnách. Zpráva je členěna na tzv. group records, jejichž počet odpovídá počtu skupin, kterých je stanice příjemcem (INCLUDE mode). Slouží také k opouštění skupin (EXCLUDE mode), tj. ukončení příjmu multicastu. Tento typ zprávy je zasílán na adresu , na které naslouchají všechny směrovače schopné zpracovat IGMPv3. Ostatní stanice (členové skupiny) ji tedy neobdrží a musí na zprávu query vždy reagovat. V režimu kompatibility se staršími verzemi jsou zprávy membership report zasílány na multicastové adresy skupin specifikovaných v reportu. Z důvodu kompatibility a beze změn jsou v IGMPv3 zahrnuty i následující tři zprávy: - Version 1 Membership Report - Version 2 Membership Report - Version 2 Leave Group Význam a použití zpráv je analogické verzi 1 a 2. Struktura zprávy membership query byla rozšířena a její podobu lze nalézt na Obr Typ zprávy je v tomto případě samozřejmě membership query (resp. odpovídající hexadecimální kód 0x11). Dále je patrné, že první položky záhlaví verze 3 jsou stejné jako u verze 2 a 1, což opět umožňuje určitou míru zpětné kompatibility. Položky časový limit odezvy, kontrolní součet a adresa skupiny mají stejný význam. Pole Resv (Reserved) není využíváno. Pole S je příznak, který říká směrovači, že má potlačit standardní aktualizace časovačů, které běžně při přijetí provádí. QRV znamená Querier s Robustness Variable a toto pole může obsahovat hodnotu s názvem Robustness Variable. Tato hodnota se využívá pro ladění hodnot časovačů vzhledem k očekávané ztrátovosti paketů na trase

27 Další pole s názvem QQIC (Querier's Query Interval Code) obsahuje informaci o hodnotě odstupu (počet sekund) mezi vysláním dvou po sobě jdoucích zpráv query směrovače. Položka počet zdrojů obsahuje podle očekávání informaci o počtu zdrojů přítomných ve zprávě specifikovaných v dalších položkách, jejichž počet právě závisí na hodnotě zmiňovaného pole. Zpráva membership query má v IGMPv3 tři možné podtypy: - Obecný dotaz (general query) směrovač zjišťuje kompletní stav v lokální síti, co se týká existence příjemců multicastu a skupin. Zpráva je odesílána na všeobecnou multicastovou adresu Dotaz na konkrétní skupinu (group-specific query) směrovač zjišťuje stav příjmu pouze jedné konkrétní multicastové skupiny. Zpráva je odesílána na adresu konkrétní skupiny. - Dotaz na konkrétní skupinu a zdroj (group-and-source-specific query) směrovač zjišťuje, zda jsou na lokální síti zájemci o příjem konkrétní multicastové skupiny od zdroje(ů), který(é) jsou specifikovány v polích zdrojová adresa [1] až [N]. Stejně jako v předcházejícím případě, zpráva je odeslána na adresu konkrétní skupiny. Fungování IGMPv3 není třeba detailně popisovat, jelikož v základních myšlenkách je totožné s IGMPv2, které již bylo popsáno. Pouze jsou přidány některé nové možnosti a je také při implementaci v souvislosti s vývojem posledních let myšleno i na určité způsoby obrany proti útokům, např. možností zapouzdřit zprávy do IPsec. Z důvodu poměrně velké složitosti se v praxi častěji setkáme spíše s IGMPv2, než s třetí verzí. Protocol Independent Multicast (PIM) PIM je jeden z nejpoužívanějších multicastových směrovacích protokolů, který je výrobci směrovačů poměrně dobře podporován. Hlavním úkolem PIM je tvorba distribučních stromů, jak sdíleného typu, tak nejkratší cesty jak bylo popsáno v kap Protokol PIM neobsahuje žádný vlastní mechanizmus na zjišťování topologie sítě, ale využívá informace standardních unicastových směrovacích protokolů. PIM tedy nezasílá mezi směrovači žádné multicastové směrovací aktualizace tabulek apod. Jak vyplývá z názvu protokolu, PIM je nezávislý na použitém směrovacím protokolu, může fungovat stejně dobře nad OSPF nebo např. RIP. Protokol PIM aplikuje směrovací informace především v rámci mechanizmu RPF (Reverse Path Forwarding), jenž byl popsán v kap V IPv4 pak ještě existuje Multicast Source Discovery Protocol (MSDP), který umožňuje výměnu PIM informací mezi jednotlivými doménami autonomními systémy (AS) (o AS je pojednáno v kap. 6). PIM totiž sám o sobě není schopen pracovat přes autonomní systémy, ale pouze uvnitř nich a aby bylo možné pracovat i se skupinami se členy ve více AS, musí existovat právě protokol MSDP, který umožňuje výměnu

28 informací o skupinových zdrojích. Úloha MSDP27 je tedy podobná úloze protokolu Border Gateway Protocol (BGP, kap. 6.4) v klasickém směrování. Jelikož členství ve skupině se v čase mění, mění se skupina příjemců a protokol PIM na tuto situaci musí umět reagovat. Je to dynamický protokol. Základní dva režimy protokolu PIM jsou - PIM Sparse Mode (PIM-SM) - PIM Dense Mode (PIM-DM) Dense a Sparse v překladu znamená hustý resp. řídký a váže se k množství příjemců multicastu v dané oblasti. Pokud je pravděpodobnost výskytu alespoň jednoho člena skupiny vysoká, skupina se považuje za dense, v opačném případě za sparse28. Při nasazení PIM-DM se předpokládá, že síť byla vystavěna tak, že bude možné směrovat mnoho multicastových přenosů a zejména se v ní bude nacházet mnoho příjemců. Síť je na začátku zaplavena multicastovým přenosem (nazývá se push mechanizmus) a ve větvích, kde se nenachází žádný příjemce, musí dojít k následnému potlačení (prune) tohoto přenosu. Funguje to následovně: Jestliže se za daným směrovačem nenachází žádný příjemce konkrétní multicastové skupiny, směrovač to musí dát vědět svému sousedovi a přenos do této větve bude následně zastaven. Situace se periodicky opakuje, jelikož potlačení má z důvodu dynamiky systému pouze časově omezenou platnost (3 minuty). Směrovač, který příjme multicast provoz také vždy testuje, zda přišel od zdroje po optimální trase (RPF) a pokud ne, pakety zahazuje. Lze totiž předpokládat, že tyto pakety dorazí nebo spíše již dorazily po optimální trase. Primárně je PIM-DM určen pro tvorbu stromů nejkratší cesty (SPT) a standardně není možné ho nasadit na tvorbu sdílených stromů. PIM-DM je vhodné použít v případech, kdy zdroj a příjemci jsou blízko v rámci topologie nebo i geograficky, nejlépe přímo na lokální sítí. PIM-DM je již v současné době považován za překonaný a není masově využíván. Při nasazení PIM-SM se primárně předpokládá, že multicast nebude v síti převažovat a každá větev se v případě aktivního příjemce musí explicitně přidat do stromu (zpráva PIM join) a také případně odebrat (zpráva PIM prune), pokud již nejsou aktivní příjemci. Navíc platí, že zpráva join se musí zasílat opakovaně po určité době, aby se potvrdila platnost příjmu skupiny v dané větvi. PIM-SM je primárně založen na distribučním stromu sdíleného typu (ale je možné ho využívat i pro stromy nejkratší cesty, v který může přenos přejít několika kroky). PIM-SM je založen na tzv. pull mechanizmu. V případě nasazení PIM-SM nedochází k pravidelnému zaplavování sítě a PIM-SM je proto doporučován k nasazení zejména pro rozsáhlé sítě. V praxi je možné ho využívat jak pro sítě s intenzivním, tak i občasným multicastovým provozem. Informace o RP by měla být nakonfigurována na každém routeru sítě. Směrovače, za kterými jsou zdroje multicastových dat, mají tedy informaci o RP a multicastová data od zdrojů zasílají na RP. Data jsou zabalena do zprávy, která je poněkud nešťastně označovaná jako PIM Register. RP tuto zprávu rozbalí a zasílá prostřednictvím distribučního stromu k příjemcům, resp. z pohledu RP pouze na koncové směrovače, které pak lokální distribuci již řeší samostatně. Každý směrovač je schopen informovat RP o aktivních příjemcích ve svém okolí (o kterých ví prostřednictvím IGMP v IPv4 sítích a prostřednictvím MLD v IPv6 sítích (viz kap )). RP tak ví, do kterých větví má zahájit multicastový přenos. PIM-SM je v současné době asi nejpoužívanějším protokolem. Protokol PIM existuje celkem ve čtyřech variantách, další dvě, které rozebereme pouze stručně, se nazývají: - Bidirectional PIM (BIDIR-PIM) vhodný pro aplikace typu many-to-many, varianta PIM- SM. Distribuční stromy jsou v tomto případě obousměrné, zatímco u PIM-SM jsou jednosměrné. Zjednodušení stromu si vysvětlíme na příkladu. Pokud budeme mít videokonferenci s deseti účastníky, u PIM-SM bude vytvořeno celkem 11 stromů. Deset stromů odpovídá cestám od zdrojů (všichni účastníci) k RP (upload) a poslední strom pak

29 představuje sdílený strom pro distribuci dat k účastníkům (download). Naproti tomu u BIDIR-PIM bude vytvořen pouze jeden sdílený a obousměrný strom. To zjednodušuje implementaci, efektivita směrování však může být nižší. - PIM source-specific multicast (PIM-SSM) varianta PIM-SM, při které se vytváří pouze SPT pro konkrétní zdroje a nevyžaduje aktivní RP pro tyto skupiny. Při doručování hraje roli adresa zdroje a tato technika je určena především pro přenosy, kde vysílá jeden zdroj a příjemců je celá řada, typicky IPTV nebo IP rádio. PIM-SSM skupiny mají vlastní adresní rozsah, což umožňuje jejich snadné rozlišení. Principy směrování multicastu Distribuční stromy Předcházející kapitoly popisovaly práci s multicastem na lokální síti, provoz se však musí nějakým způsobem dostat na hraniční směrovač LAN. Cestě od zdroje dat k adresátům přes směrovače s podporou multicastu se říká strom (tree), případně distribuční strom. Tvorba takovéhoto stromu není jednoduchá úloha a provádí ji zpravidla multicastový směrovací protokol, jako je např. Distance Vector Multicast Routing Protocol (DVMRP), Multicast Open Shortest Path First (MOSPF), Core-Based Trees (CBT) nebo zejména Protocol Independent Multicast (PIM), viz kap Obecně je cílem těchto protokolů vytvořit co nejefektivnější strom. Pohledů na efektivitu takovéhoto stromu je hned několik (vzdálenost resp. počet skoků, cena, spolehlivost, šířka pásma) a proto nelze říct, který protokol je nejlepší, jelikož vždy záleží na konkrétní aplikaci a podmínkách. Důležité je, aby ve stromu neexistovaly žádné směrovací smyčky, které by způsobily cyklení paketů bez šance na dosažení adresátů. Stromy dělíme bez ohledu na multicastové směrovací protokoly na dva základní druhy: Shortest Path Tree (SPT) neboli strom nejkratší cesty, někdy též nazývaný jako source rooted tree, což znamená, že kořenem (root) stromu je vždy zdroj dat, resp. přesněji řečeno první směrovač připojený ke zdroji dat. Tento kořenový směrovač pak data posílá nejkratší cestou dál přes další směrovače až k příjemcům dané skupiny. Z popisu je zřejmé, že takovýto strom pak musí existovat pro každý zdroj dat. Ilustrativní situace je znázorněna na Obr Shared Tree sdílený strom u nějž je kořen umístěn někde uprostřed stromu a zdroje svá data posílají nejdříve na tento kořen (např. u PIM-SM je to zpráva PIM Register, viz kap ), který se pak stará o jejich distribuci prostřednictvím jediného stromu. Strom existuje jeden pro všechny zdroje. Kořenu se někdy také říká rendezvous point (RP). Je zřejmé, že pak veškerý multicastový provoz prochází vždy přes tento bod, což na něj samozřejmě klade zvýšené výpočetní nároky. Přenos navíc nemusí vždy probíhat příliš efektivně, jelikož může existovat lepší cesta mezi zdrojem a příjemcem dat, než ta přes RP. Směrovače, které mají v sítích na svých rozhraních nějaké příjemce skupiny se u RP hlásí o příjem dané skupiny. (Např. u protokolu PIM-SM je to zpráva PIM Join, viz ). Tato zpráva je posílána na unicastovou adresu RP směrovače. Jak tato zpráva prochází sítí přes dílčí směrovače, tak si tyto routery ukládají informaci o tom, že opačně touto cestou pak mají danou skupinu distribuovat. Sdílený strom vzniká tedy poměrně snadno, jelikož zpráva žádosti o příjem skupiny je směrována standardně na základě unicastových směrovacích protokolů. Ukázková situace je znázorněna na Obr SPT stromy jsou používány v případech, kdy hlavním argumentem pro přenos je jeho rychlost a minimální počet skoků od zdroje k členům skupin. Směrovače si však musí pamatovat (pro každý zdroj zvlášť) informace o cestě. U sdílených stromů je pak hlavním přínosem úspora procesorového času a hlavně paměti na běžných směrovačích, které se nemusí zabývat tvorbou a

30 ukládáním distribučních stromů pro jednotlivé zdroje, existuje pouze jeden, který však nemusí být vždy optimální. Z prvního obrázku (SPT) je patrné, že cesta od zdroje k příjemci je vždy co nejkratší, zatímco na druhém obrázku je vidět, že v případě použití pevného RP velmi záleží na jeho umístění vzhledem ke zdrojům dat. Může pak i docházet k paradoxní situaci, že data jsou po jedné lince přenášena tam i zpět, aniž by šlo o chybu. Správná volba umístění RP je tedy velmi podstatná. Tak je tomu v případě zdroje dat č. 1 na Obr U dílčích protokolů, např. PIM-SM pak existují techniky, jak tento nežádoucí jev potlačit a po zahájení přenosu přes RP cestu zefektivnit, to je však již nad rámec tohoto textu. Technika Reverse Path Forwarding Základní myšlenkou unicastového směrování je přeposílání informací směrem k příjemci a na základě adresátovy IP adresy, která je v paketu uložena jako cílová IP. V multicastovém přenosu je situace odlišná. Důvodem je zejména to, že cílová adresa je v tomto případě reprezentována

31 adresou skupiny. Základní myšlenka směrování multicastu spočívá v směrování provozu pryč od zdroje a nazývá se Reverse Path Forwarding (RPF), což je možné přeložit jako směrování na základě zpáteční cesty. Standardní unicastové směrování probíhá tak, že směrovač ve své směrovací tabulce hledá záznam, podle kterého by mohl paket předat na jedno ze svých rozhraní a v jedné kopii odeslat. Ochrana proti vzniku směrovacích smyček je dána použitým směrovacím protokolem. (V případě, že ke vzniku smyčky přesto dojde, zafunguje mechanizmus doby života paketu (TTL), jež způsobí, že paket bude po nějaké době cyklení vždy zahozen.) RPF je mechanizmus, který multicastovým směrovačům umožňuje správně předávat pakety skrz distribuční stromy a navíc se vyvarovat vzniku směrovacích smyček. Směrovač s RPF u každého paketu sleduje, zda směr, odkud paket přišel, odpovídá cestě ke zdroji dat dané skupiny26. Pokud ano, tak se podívá, které jeho další rozhraní směřují k příjemcům, a na ty pošle kopie paketu. Pokud paket dorazí ze směru, který neodpovídá cestě ke zdroji dat, paket je zahozen. K určení, kterým směrem se nachází zdroj dat, se využívají standardní směrovací protokoly, resp. záznamy v aktuální platné unicastové směrovací tabulce směrovače. Zdrojem se v tomto případě myslí buď přímo zdroj dat v případě SPT stromů a nebo RP v případě sdíleného stromu. Situaci zjednodušeně demonstruje Obr ) IPv6: způsoby zavádění IPv6, datagram IPv6, adresace v IPv6, funkce ICMPv6 protokolu, automatická konfigurace adres v IPv6 síti Způsoby zavádění IPv6 Základní překážkou v rychlém zavádění IPv6 je především jeho nekompatibilita s IPv4. Bylo proto navrženo několik mechanizmů umožňujících hladký přechod od IPv4 k protokolu IPv6. Souvisí zejména s následujícími technikami:

32 Souběh Internetových protokolů IPv6 a IPv4 (dual stack) software a hardware podporuje plně oboje. To samozřejmě vede k zvýšení nákladů na vývoj zařízení, ladění a tím pádem i koncovou cenu. Na Obr. 5-2 je pro aplikační protokol 1 použit IPv6 a naopak pro aplikační protokol 3 použit IPv4. Souběh IPv6 a IPv4 představuje jedinou možnou cestu pro nejbližší roky, problémem však zůstává neustávající potřeba adres IPv4, stanice mají totiž adresy obojího typu (IPv4 i IPv6). Tunelování, tedy většinou zapouzdření IPv6 paketu do IPv4. Tunelování bylo popsáno v kap Technika umožňuje komunikaci přes sítě s odlišnou verzí protokolu IP. Existují dva základní typy tunelů a to explicitně konfigurované a automaticky vytvářené. Jak název napovídá, explicitní tunel musí správce ručně nakonfigurovat a zprovoznit, např. pro konkrétní požadovanou trasu, zatímco automatický tunel se vytváří samočinným mechanizmem, bez přímého zásahu administrátora. Nejznámějším zástupcem automaticky vytvářeného tunelu je technika 6to4, což je zkrácený název pro Connection of IPv6 Domains via IPv4 Clouds, dále se můžeme setkat s tunelovacími protokoly Teredo, ISATAP a 6rd (IPv6 rapid deployment), více viz literatura nebo Internet. Na Obr. 5-2 je pro aplikační protokol 2 přímo na straně hosta prováděno tunelování IPv6 protokolu přes IPv4. Tunelování IPv6 do IPv4 je všeobecně problematické33. Překlad adres podobný technice NAT, s tím rozdílem, že při překladu se zaměňuje IPv4 adresa za IPv6 adresu nebo opačně. Obecně se technika nazývá NAT-PT (Network Address Translator - Protocol Translator), zajímavý je především nástupce NAT64, více lze nalézt na Internetu. Hlavním cílem NAT64 je především zpřístupnit čistě IPv6 sítím původní svět IPv4. Tento protokol musí spolupracovat s DNS64, což je protokol, který provádí nezbytné manipulace s IPv6 adresami (které potřebuje čistě IPv6 stanice) a IPv4 adresami cílů (reálnými v IPv4 Internetu). NAT64 nemusí vůbec spolupracovat s celou řadou end-to-end aplikací, u kterých jsou např. využívány proprietární komunikační protokoly. Datagram IPv6 Struktura základního záhlaví IPv6 je schematicky naznačena na Obr. 46. Verze (version) 4 bity, stejně jako u IPv4 obsahuje verzi a zajišťuje, aby ostatní systémy, které zpracovávají datagram během přenosu, mohly různé pole datagramu správně použít. Verze IPv6 zde má samozřejmě hodnotu 6. Třída provozu (trafficclass) 8 bitů, toto pole umožňuje nastavit prioritu paketu přepravní třídu. Cílem je, aby prostřednictvím této položky dokázala IP síť zaručovat kvalitu služeb. Využití tohoto pole však ještě není přesně definováno a hrozí proto, že dopadne podobně jako pole ToS u IPv4, jehož využití bylo ze začátku minimální

33 Identifikace toku dat (flow label) 20 bitů, označení toku dat, umožňuje zjednodušení směrování, protože spolu související pakety mají nastavenou stejnou hodnotu a na jejím základě může tedy směrovač paket odeslat stejnou cestou jako předcházející. Jedná se však o experimentální záležitost, která ještě není standardně implementována. Přidělení této značky probíhá u odesílatele paketu a tato hodnota se nesmí v průběhu přenosu změnit. Hodnota 0 značí, že paket nepatří k žádnému toku. Celková délka přenášených dat (payloadlength) 16 bitů, délka přenášených dat bez velikosti základního záhlaví. Informace je o počtu bajtů. Maximální délka tedy může být až 64 kb. Pokud to nedostačuje, je nutno použít rozšiřující záhlaví tzv. jumbo obsah, viz dále. Další záhlaví (nextheader) 8 bitů, informace o vnořeném záhlaví, např. rozšiřující záhlaví pro přenos informace mezi směrovači, které (volitelně) následuje za IPv6 adresami (konec základní hlavičky). Pokud se další záhlaví nepoužívá, ukazuje na protokol vyšší vrstvy (zpravidla TCP nebo UDP). Limit počtu skoků (hop limit) 8 bitů, odpovídá položce TTL u IPv4. Maximální počet skoků, které smí paket absolvovat, směrovače tuto hodnotu postupně dekrementují. Základním cílem je, aby nedošlo k zacyklení paketů a ty, které není možné doručit, byly vždy rychle odstraněny ze sítě. IPv6 adresa odesílatele/příjemce paketu (source/destinationaddress) každá 128 bitů. Z popisu je zřejmé, že celková délka základního záhlaví je 40 B. Tato délka je pevně dána, na rozdíl od protokolu IPv4, kde byla délka proměnná. Základní část záhlaví IPv4 má délku 20 B, což je polovina velikosti IPv6 záhlaví. Vzhledem k čtyřikrát delším adresám u IPv6 to však neznamená velký nárůst. Malý přírůstek velikosti záhlaví je dán vyřazení nadbytečných položek ze základního záhlaví. Konkrétně se jedná o pole rozšiřujících voleb, délka záhlaví, kontrolní součet a fragmentace. Některé operace lze provádět pomocí rozšiřujících záhlaví. Tyto záhlaví se

34 řetězí za sebe a jedno vždy odkazuje na následující, podobně jako v základním záhlaví. Nejedná se přímo o odkaz (ukazatel), tak jak ho známe z některých programovacích jazyků. Informace spočívá v číselné hodnotě, která identifikuje typ dalšího záhlaví. Fragmentace je v současné době poměrně málo častý jev. Většinou se totiž na lokální úrovni používá Ethernet, který zvládá pakety až do délky 1500 B. IPv6 počítá s tím, že sítě zvládnou alespoň 1280 B. Proto se fragmentace nepředpokládá a byla odsunuta (pro speciální případy) do zvláštního rozšiřujícího záhlaví. Kontrolní součet na IP vrstvě verze 6 již není prováděn vůbec. Výpočet a jeho kontrola v každém uzlu zbytečně zpomalovaly směrovací proces. Za dostatečnou je považována kontrola, která je standardně prováděna na linkové vrstvě. Pokud by tato kontrola nestačila, je nutné implantovat ještě další na vyšší než síťové vrstvě. Adresace Sada IPv6 rozšiřuje adresní prostor na Podstatnou změnou v IPv6 je, že jedno rozhraní běžně využívá více než jednu IPv6 adresu. V IPv6 jsou definovány tři druhy adresování, které mají odlišné chování: individuální (unicast) adresy identifikující jednotlivá síťová rozhraní, tak aby na ně mohly být zasílány pakety. skupinové (multicast) jsou určeny pro adresování skupin. Platí, že pakety odeslané na tuto adresu by měly být doručeny všem členům skupiny. Tyto adresy zastupují i všesměrové (broadcast) adresy, které nejsou v rámci IPv6 definovány samostatně. V rámci adresního prostoru jsou definovány speciální skupiny, které reprezentují např. všechny uzly na dané lince atd. výběrové (anycast) také označují skupinu adresátů, rozdíl je však v tom, že pakety se posílají pouze jedinému jejímu členu, zpravidla tomu, který je nejblíže. Tento typ existuje i v IPv4. IPv6 adresy jsou zapisovány jako 8 skupin 4 hexadecimálních číslic oddělených dvojtečkou např: 8000:0000:0000:0000:0ABC:DEF1:0345:789A resp. zkrácený zápis 8000::0ABC:DEF1:0345:789A resp. 8000::0ABC:DEF1:0345:789A Některé z přechodových mechanizmů mezi IPv4 a IPv6 vyžadují možnost zapsat do IPv6 adresního pole IPv4 adresu. Tyto adresy se nazývají IPv4-mapované adresy. Pravidlo pro jejich zápis je takové, že prvních 80 bitů jsou nuly, dalších 16 bitů 1, zbývajících 32 bitů je IPv4 adresa. Formální zápis je tedy např.: ::FFFF: Podobně jako u IPv4 je i u IPv6 definován tzv. prefix, tj. začátek adresy, který představuje adresu sítě (nebo podsítě). Jeho délka se pak běžně zapisuje za lomítko umístěné za IP adresou, např. 8000::ABC:DEF1:345:789A / 64 U IPv6 adres jsou definovány speciální typu adres:

35 Globální individuální adresy jsou adresy pro běžné použití, zastupující dnešní IPv4 adresy veřejného typu. Slouží tedy k identifikaci určitého síťového rozhraní v celém Internetu. Při přidělování rozsahů adres zákazníkům je nezbytné, aby probíhalo hierarchicky. Snahou je, aby číselně blízké rozsahy byly i v rámci fyzické topologie blízko sebe. To následně umožňuje při pohledu zvenčí efektivně agregovat směrovací tabulky a zrychlit tak celý směrovací proces. IPv6 adres může být obrovské množství, což samo o sobě znamená enormní nárůst směrovacích tabulek a zpomalení celé směrovací úlohy (na globální úrovni). Právě kvůli maximálnímu možnému zjednodušení byla zavedena pevná struktura globální individuální adresy, která je naznačena na Obr. 48. Délky jednotlivých částí jsou definovány obecně, v obrázku uvedené hodnoty jsou ty, které jsou v současné době platné. Globální směrovací prefix odpovídá de facto adrese sítě v IPv4. Celkem těchto prefixů může být Identifikátor podsítě je určen k rozlišení jednotlivých podsítí v rámci celé sítě. Rozdělení na podsítě je důležité např. z pohledu rozdělení celé sítě na o něco menší a lépe spravovatelné jednotky. V rámci každé sítě může být až 2 16 podsítí. Identifikátor rozhraní slouží k odlišení koncových stanic v rámci lokální sítě. V této koncové sítí pak může být až 2 64 stanic. Toto číslo je tak velké, že nemůže nastat situace, že by společnost v rámci své lokální sítě adresy vyčerpala. Samozřejmě je možné i v rámci tohoto velkého rozsahu vytvářet další podsítě. Nepočítá se ale s tím, že by to byla běžná praxe. Informace o těchto podsítích se však nesmí (a ani nemohou) dostat až na globální úroveň. Na globální úrovni je totiž maximální možná délka prefixu stanovena pevně na 64 bitů. Důvod je zřejmý čím kratší prefix, tím méně možných kombinací a záznamů ve směrovacích tabulkách a tím rychlejší je směrování. Identifikátor rozhraní se přiděluje buď náhodně a má jenom omezenou platnost (po časovém intervalu se generuje nová adresa), nebo se generuje pomocí standardu IEEE EUI-64. Tento standard používá fyzickou adresu zařízení. Fyzická adresa tvoří 48 nejméně významných bitů IPv6 adresy, poté je připojena konstanta FFFE a adresa se potom doplní na potřebnou délku. Dále se jeden bit v prvním bajtu změní z 0 na 1, což indikuje to, že adresa je určena pro globální použití. Povinné adresy IPv6 U koncové stanice jsou povinné tyto IPv6 adresy: Lokální linková adresa pro každé rozhraní, všechny individuální a výběrové adresy, které byly přiděleny, lokální smyčka, skupinové adresy pro všechny uzly, což je registrovaná adresa, na kterou uzly pravidelně posílají zprávy, že stále chtějí multicast přenos přijímat, skupinová adresa pro vyzývaný uzel pro všechny přidělené individuální a výběrové adresy; adresa, na které daný uzel přijímá multicast, všechny skupinové adresy, jejichž je členem. ICMPv6 funkce ICMP (Internet ControlMessageProtocol) je i ve verzi 6 režijním (servisním) protokolem Internetu. Nepřenáší žádná uživatelská data, jeho zavedení je ve všech implementacích a aktivních prvcích s podporou IPv6 povinná. Protokol ICMP se využívá pro ohlašování chybových stavů, testování dostupnosti síťové vrstvy a také k výměně určitých provozních informací. V rámci IPv6-35 -

36 se tento protokol používá také k tzv. objevování sousedů (viz kap.5.6), podpoře správy multicastových skupin, překladu adres a zajištění mobility. Základní formát ICMPv6 zprávy je naznačen na Obr. 51. Položka typ určuje základní druh zprávy, další položka (kód) pak umožňuje tento typ blíže specifikovat vytváří se tzv. podtypy. Položka tělo zprávy pak závisí na konkrétním typu a délka tohoto pole je tudíž proměnná. Přehled vybraných typů ICMPv6 zpráv je možné nalézt v Tab. 14. ICMPv6 má po mnoha negativních zkušenostech s ICMP protokolem ze sítí IPv4 přímo implementovaná i určitá bezpečnostní opatření. Implementace ICMPv6 protokolu by správcům měla umožňovat nastavit určité kvantitativní parametry protokolu. Jsou to povolený průměrný počet ICMP zpráv za jednotku času anebo maximální podíl zpráv ICMP na celkové šířce pásma. Prostřednictvím těchto nastavení lze zabránit zahlcení prvku nebo linky. Další možností je, že ICMP zpráva může mít bezpečnostní záhlaví, které poskytuje možnost autentizace komunikující strany. NeighborDiscovery(ND) - překlad logických adres na skutečné, který je v sítích IPv4 zajišťován samostatným protokolem ARP. Fyzické adresy potřebujeme, abychom byli schopni komunikovat v rámci lokální sítě

37 Automatická konfigurace Sada IPv6 přichází s poměrně revoluční myšlenkou jak automaticky konfigurovat koncové stanice. Z IPv4 sítí známe především protokol DHCP (o jeho nástupci je řeč v kap. 5.11), který je založen na jednoduchém principu klient-server. Tomuto způsobu získání síťových parametrů se říká stavová konfigurace. Zcela novou myšlenkou IPv6 je však bezestavová adresní konfigurace (Stateless Address AutoConfiguration = SLAAC). Základním principem je, že směrovač do sítě vysílá opakovaně (ale v náhodně stanovených okamžicích) potřebné informace (viz dále) pomocí ICMPv6 zprávy 134 ohlášení směrovače. Stanice má možnost o tyto informace i aktivně požádat, opět pomocí ICMPv6 zprávy, konkrétně výzvy směrovači (133). Stanici si pak na základě těchto informací sama stanoví svoji (globální) IPv6 adresu, resp. její část identifikátor rozhraní (nejnižších 64 bitů). Tato adresa může být dvojího typu buď EUI-64 nebo náhodná, jak bylo popsáno v kap Parametry, které jsou obsaženy v ohlášení směrovače, jsou následující - Životnost implicitního směrovače údaj o čase, jak dlouho bude tento směrovač ještě implicitní. - Omezení počtu skoků údaj, který mají stanice ve svých paketech používat. - Příznakové bity o M (Managed address configuration) signalizuje, že v síti je přítomen DHCPv6 server, který přiděluje adresy. Pokud je tento příznak nastaven, stanice kontaktují DHCPv6 a pokusí se získat adresu (ta však může mít nízkou prioritu používání oproti např. dočasné adrese). o O (Other stateful configuration) pokud je tento příznak nastaven a není nastaven předchozí, pak to znamená, že konfigurace se provádí kombinovaně, tj. že adresa a prefix se nastavuje automaticky a další parametry ve spolupráci s DHCPv6 (např. adresy DNS serverů). o Pokud jsou bity M i O nastaveny na 0, není DHCPv6 přítomno. o H (Home agent) slouží pro podporu mobility, směrovač dává najevo, že může pracovat ve funkci domácího agenta pro místní síť. Více v kap. o mobilitě (kap. 5.12). - Trvání dosažitelnosti parametr ovlivňuje, jak dlouho po ověření dostupnosti určité stanice bude tato dostupnost ještě považována za platnou. - Interval opakování je interval mezi dvěma výzvami sousedovi. - Volby další údaje, které může směrovač ohlašovat. Jsou to např. MTU (Maximum Transfer Unit) dané sítě, fyzická adresa směrovače, adresa (prefix) sítě, případně i více prefixů, doba platnosti prefixu jak dlouho se adresa, která je na něm založena může používat, příznakové bity související s prefixem, z nichž asi nejzajímavější (A = Autonomous addressconfiguration) umožňuje zakázat stanicím automatickou bezestavovou konfiguraci. Tyto parametry umožňují stanicím v síti vědět, kde se nacházejí, jak se mají chovat, aby komunikace probíhala optimálně, a kdo je implicitní směrovač, tj. kam mají směrovat provoz, který míří mimo lokální síť. Kromě výše uvedeného je možné využívat ohlášení směrovače i k zlepšení fungování sítě v oblasti směrování. Uzel si udržuje tyto parametry:

38 - Cache paměť cílů směrovací informace pro konkrétní cílové adresy, záznamy typu <cíl; další skok>, tak jako v běžné směrovací tabulce. - Seznam prefixů seznam získaný od směrovače nebo směrovačů, který následně slouží především k posuzování, zda je daná stanice ve stejné síti. - Seznam implicitních směrovačů informace o všech směrovačích, které o sobě tvrdí, že jsou implicitní. Jestliže tedy chce stanice odeslat paket, nejdříve se podívá do paměti cílů, zda nenalezne odpovídající (explicitní) záznam. Pokud ne, na základě seznamu prefixů zjišťuje, zda je stanice lokální nebo vzdálená. Jestliže je lokální, předání je pak založeno na zjištění fyzické adresy stanice, jak bylo popsáno dříve. Jestliže je vzdálená, je třeba zvolit vhodný směrovač ze seznamu implicitních směrovačů a na ten pak paket poslat. Pokud je zvolený směrovač nevhodný, má směrovač možnost o tom stanici informovat zprávou ICMPv6 přesměrování (137). V této zprávě je pak i informace o tom, kudy by měly být pakety správně zasílány a uzel by si měl tento údaj správně uložit do své paměti cílů. K normálnímu fungování většiny stanice v síti chybí již pouze jedna věc adresa(y) DNS serveru(ů). Základní mechanizmy automatické konfigurace (ND) tuto věc postihují teprve nedlouho. Do ohlášení směrovače je možné přidat rožšiřující pole obsahující adresy rekurzivních DNS serverů, což celý proces velmi usnadňuje, pokud je toto v konkrétní implementaci již dostupné. Jinou variantou pak je, že informace o DNS je doplněna stavovou cestou, tj. pomocí protokolu DHCPv6. DHCPv6 Protokol DHCP (Dynamic Host ConfigurationProtocol) zajišťuje koncovým stanicím stavovou konfiguraci potřebných síťových parametrů. U nového DHCPv6 se nevyužívají broadcastové adresy. Systém je podle očekávání postaven na multicastu, tak jako většina hromadných služeb v IPv6. Identifikace stanic je u DHCPv6 postavena na tzv. DUID (DHCP UniqueIDentifier). Tento identifikátor by měl být jednoznačný a stálý pro všechny klienty a servery. Pro rozlišení jednotlivých rozhraní v rámci jednoho klienta je pak využíván další identifikátor IA (Identity Association). IA představuje shluk konfiguračních informací přidělených jednomu rozhraní. Tento shluk je opatřen jednoznačným identifikátorem IAID. První zpráva, kterou při aktivaci DHCPv6 systému stanice vyšle na první z multicastových adres (ff02::1:2), je výzva (solicit). Tato zpráva má stejný význam jako DHCP discoveryz verze 4. K odeslání stanice použije svoji lokální linkovou IPv6 adresu, kterou si generuje sama. Odpověď na tuto výzvu se jmenuje ohlášení serveru (advertise). V tomto ohlášení jsou již obsaženy konfigurační parametry, které je server ochoten následně klientovi přidělit. Těchto ohlášení může klient obdržet i více a následně si z nabídek vybírá. Přednost by měl dát nabídkám od serverů s nejvyšší prioritou, pokud je takových nabídek více, tak si může vybrat podle potřeby. V další fázi klient zašle žádost (request) o jím vybranou nabídku. Tato žádost se opět zasílá na skupinovou adresu ff02::1:2. Server, který nabízel vybranou konfiguraci, odpoví (reply). Tato zpráva obsahuje definitivní konfigurační parametry a povoluje stanici tyto parametry použít. Stejně jako u DHCPv4 i zde je časová platnost parametrů omezena a klient musí před jejím uplynutím žádat o obnovení

39 4) Autonomní systémy z hlediska směrování, dělení protokolů. Protokol BGP a parametry směrování. Podstata multihomingu. Peering a tranzit. Autonomní systémy Autonomní systém představuje souhrn sítí pod společnou správou, kde se používá společná směrovací strategie. Celý AS se obvykle skládá z menších oblastí (sítí). Každý autonomní systém musí mít přiřazeno unikátní 16-bitové číslo (přiděluje organizace IANA). V rozsahu 16-bitového čísla může být teoreticky maximálně pouze autonomních systémů. AS číslo jsou navíc vyhrazeny pro privátní účely, takže jejich použití v rámci Internetu není možné. AS 0, a jsou vyhrazeny organizací IANA a není taktéžmožné je použít v běžném prostředí Internetu. Zbývá tedy mnohem méně než možných autonomních systémů a tento počet se blíží svému vyčerpání. Proto IANA začala nedávno alokovat i 32-bitové čísla autonomních systémů, ve formě X.Y, kde X je 16-bitové číslo, stejně tak jako Y. Původní autonomní systémy se tak stávají 0.Y, kde Y je původní číslo autonomního systému v 16-bitovém prostředí. Přechod na 32-bitové prostředí však vyžaduje podporu (nejen) směrovacích protokolů, které informace o AS přenášejí. Aby mělo rozdělení na AS smysl, musí mezi nimi existovat jednotný systém předávání směrovacích informací, v pevně daném formátu. Lze to jednoduše shrnout slovy: v rámci svéhovlastního (autonomního) systému má každý možnostzajistit si přenos a aktualizacisměrovacíchúdajůpodlesvého, ale navenek musí všichnipostupovatjednotně. IGP protokoly (Interior Gateway Protocols) Všechny protokoly, používané pro přenos směrovacích informací mezi jednotlivými bránami (směrovači) uvnitř autonomního systému, se souhrnně označují jako protokoly IGP (InteriorGatewayProtocol). Mezi používané IGP protokoly patří např.: RIPv2 (RoutingInformationProtocolverze 2), EIGRP (EnhancedInteriorGatewayRoutingProtocol), OSPF (Open ShortestPathFirst), IS-IS (IntermediateSystem to IntermediateSystem). EGP protokoly (Exterior Gateway Protocol) Pro vzájemnou komunikaci mezi autonomními systémy byl navržen protokol EGP (ExteriorGatewayProtocol). Ten vychází z představy, že v rámci každého autonomního systému je minimálně jedna brána pověřena předáváním směrovacích informací navenek. Tato brána, jejíž výběr je plně v moci správce příslušného autonomního systému, je pak označována jako externí brána (exteriorgateway). Prostřednictvím protokolu EGP pak tato brána komunikuje s externími bránami jiných autonomních systémů. Protokol EGP umožňuje, aby se jeden autonomní systém nejprve dohodl s jiným, že si směrovací informace vůbec budou vyměňovat (nebo si je také mohou odmítnout předávat). Dále umožňuje, aby jednotlivé autonomní systémy pravidelně testovaly dostupnost druhých autonomních systémů (tj. testovaly, zda spojení s nimi je průchodné). Hlavním úkolem protokolu EGP však je pravidelný přenos směrovacích údajů a informací o průběžných změnách mezi autonomními systémy. BGP protokol Protokol EGP je v současné době nahrazen protokolem BGP (BorderGatewayProtocol), aktuálně ve verzi 4 (dokument RFC 4271). Protokol BGP je pro fungování Internetu jako celku nesmírně

40 důležitý, přestože se s ním běžný koncový uživatel nesetkává. Spojení mezi hraničními směrovači je nakonfigurováno ručně (nevzniká automaticky, je nezbytný zásah administrátora) a pro přenos se využívá spolehlivý protokol TCP port 179. Protokol BGP je tedy aplikačním protokolem. BGP je schopné provozu v plně decentralizovaném prostředí současného Internetu a podporuje přenos směrovacích informací o sítích s beztřídní (classless) maskou, tj. i o podsítích vzniklých rozdělením původních tříd A, B, C. BGP může být využito i ke směrování v rámci autonomního systému, potom se nazývá vnitřní (Internal) BGP ibgp. Nejčastějším případem interního použití je potřeba přenosu směrovacích informací mezi dvěma nebo více externími (hraničními) branami v rámci jednoho AS. To umožňuje, aby BGP mohlo správně rozhodnout, jaký směr pro směrování zvolit, pokud existuje více možností. Nutnou podmínkou je v takovém případě, aby byly hraniční směrovače propojeny každý s každým. To může být u opravdu velkých sítí problematické, proto vznikla technika tzv. reflektorů, ta je však nad rámec tohoto textu. V případě použití BGP protokolu mezi autonomními systémy se pak někdy využívá název ebgp (Exterior BGP), většinou však postačí jednoduše BGP. Možná situace pěti propojených autonomních systémů je naznačena na Obr Interně v rámci jednotlivých autonomních systémů se používá některý z IGP protokolů (viz kap. 6.2), např. v AS1 je to OSPF. Pro přenos mezi autonomními systémy je nasazeno ebgp. V případě, že je nezbytné přenášet směrovací informace v rámci AS, využije se ibgp, jako např. v AS3, který by pravděpodobně představoval tranzitní AS (viz kap , která se věnuje tranzitu). Směrování u BGP Protokol BGP si v paměti směrovače vytváří svoji vlastní směrovací tabulku nazývanou Loc-RIB (LocalRoutingInformation Base), odděleně od hlavní směrovací tabulky směrovače, kde mohou být uloženy případně i záznamy dodané jiným směrovacím protokolem. Pro každého svého souseda, s kterým má BGP router navázané spojení si udržuje tabulku Adj-RIB-In (AdjacentRoutingInformation Base, Incoming), která obsahuje NLRI obdržené od tohoto souseda (resp. pouze ty záznamy, které dosud nebyly zpracovány) a také udržuje tabulku Adj-RIB- Out(AdjacentRoutingInformation Base, Outgoing), kde se nachází průběžně připravované NLRI k odeslání tomuto sousedovi. Jestliže do tabulky Adj-RIB-In při komunikaci se sousedním směrovačem přibude nová cesta do určité destinace, proces BGP se musí rozhodnout, zda aktualizovat starší záznam v Loc-RIB (pokud se tam již nějaký nachází). Rozhodovací proces souvisí s parametry, které jsou popsány níže. Základním testem, na základě kterého může BGP přidat cestu přijatou v NLRI Update do

41 Loc-RIB, je dostupnost následujícího uzlu (NEXT_HOP), který je uveden v této zprávě. K tomuto směrovači tedy již musí mít rozhodující se směrovač aktivní cestu, již umístěnou ve směrovací tabulce celého směrovače. Pokud taková cesta neexistuje, nemůže být NLRI informace z příchozí zprávy použita. Protokol BGP využívá k rozhodnutí o směrování tyto parametry: druh cesty k dané síti počet procházených AS parametr AS_PATH. skupina administrátorem definovaných pravidel o váha (weight) viz Příklad 6.2, o místní preference (local preference) parametr LOCAL_PREF, viz Příklad 6.3. o výstupní diskriminátor MED (Multi Exit Discriminator) parametr MULTI_EXIT_DISC. Atributy váha a místní preference ovlivňují, kudy půjde provoz ven z konfigurované sítě (stejně jako AS_PATH), parametr MED ovlivňuje, kudy půjde provoz dovnitř konfigurované sítě. Největším problémem BGP pravděpodobně je exponenciální růst Internetové směrovací tabulky, se kterou pracují nejvýznamnější směrovače v Internetu. Internetovou směrovací tabulkou, neboli globální BGP tabulkou se myslí souhrn všech autonomních systémů, které nepotřebují ke správnému fungování směrovacího procesu mít nakonfigurovanou také výchozí bránu, která by se použila v případě, že by žádný exaktní záznam ve směrovací tabulce nevyhovoval při hledání cesty do cílové destinace. Těmto autonomním systémům se často říká default-free zone(dft). Neznamená to však, že by směrovače v této zóně měly ve svých směrovacích tabulkách cesty do všech sítí Internetu a že by ve všech těchto směrovačích byla směrovací tabulka stejná. Díky technikám jako je filtrování cest(ekonomické, bezpečnostní, technické důvody) a agregace cest se daří udržet velikost tabulek v rozumných hodnotách (cca 320k zaznamů).agregce spočívá v shrnutí několika směrovacích informací do jedné souhrnné. Peering Veřejný a privátní peering Peering je další z technik souvisejících s problematikou velkých sítí. Peering představuje pojem pro přímé propojení administrativně samostatných sítí, zpravidla propojení nezávislých autonomních systémů. Typickým příkladem jsou poskytovatelé Internetového připojení (ISP = Internet Service Provider). Hlavním důvodem tohoto propojení je umožnit výměnu dat mezi uživateli propojených sítí, což je vzájemně výhodné. Základním předpokladem k peeringu dvou sítí je jejich fyzické propojení a dohoda o výměně směrovacích informací, zpravidla prostřednictvím protokolu BGP. Peering datových sítí se liší od propojování sítí v telekomunikacích ve způsobu financování. V telekomunikacích jsou běžné poměrně vysoké propojovací poplatky, které mají pokrýt náklady související s přenosem hovoru v jiné síti, účtované na základě délky hovoru. Při peeringu se žádné poplatky přímo za přenášený datový provoz z/do jiné sítě neúčtují. Peering se dělí na dva druhy: veřejný peering(public peering) propojení více než dvou stran, na úrovni druhé vrstvy, často je využit Ethernet. Tyto místa se nazývají exchangepointsnebo častěji Internet exchanges(ix). Do těchto uzlů jsou pak připojeny až stovky sítí (autonomních systémů). Uzel může být v nejjednodušším případě tvořen pouze jedním přepínačem, ve skutečnosti je však zpravidla topologie uzlu mnohem složitější. V situaci, kdy je připojeno velké množství sítí do jednoho bodu, je zřejmé, že nemůže být nikdy

42 dosaženo maximálních hodnot přenosových rychlostí. Veřejný peering je tedy vhodný především pro snadné propojení s velkým množstvím (často menších) sítí. privátní peering(privatepeering) přímé propojení pouze dvou sítí, zpravidla také na druhé vrstvě. Propojovací linka je v tomto případě vyhrazena pouze pro jedno konkrétní spojení a není sdílena dalším stranám. Přímé spojení má význam, jestliže je mezi dvěma konkrétními sítěmi velký datový provoz, kvůli kterému stojí za to provozovat přímé propojení. Není však možné, aby byly všechny autonomní systémy propojeny navzájem privátně, počet spojení by totiž byl obrovský. Tranzit Kromě peeringu existuje ještě starší způsob, jak mohou být dvě nezávislé sítě (autonomní systémy) propojeny. Nazývá se tranzit. Tranzit spočívá v představě, že všechny koncové autonomní systémy jsou připojeny k velké páteřní sítí, která zajišťuje tranzit datového provozu a přímé propojení těchto koncových sítí neexistuje. Páteřní síť je samozřejmě také autonomním systémem. Dnes již pojem tranzit nutně nesouvisí s topologií tzv. páteřní sítě, ale spíše způsobem přenosu dat mezi dvěma autonomními systémy, kdy jeden z nich poskytuje druhému připojení do dalších autonomních systémů. Tranzit se skládá ze dvou souvisejících služeb. Mějme situaci, kdy máme síť jednoho ISP, ke které jsou připojeni zákazníci se svými sítěmi. Tento ISP je připojen k jinému autonomnímu systému za účelem tranzitu. První službou je, že poskytovatel (zastupující své zákazníky) oznamuje připojenému autonomnímu systému (zastupujícímu de facto zbytek Internetu) informace o routách k sítím svých zákazníků a tím umožní provoz do sítě zákazníků (inboundtraffic) z celého Internetu. Druhou službou je informování sítí zákazníků o routách do Internetu, často formou informace o výchozí bráně. Tato služba umožní zákazníkům odchozí provoz (outboundtraffic). Rozdílnost od peeringu spočívá v tom, že přes peeringové spojení dvou ISP prochází pouze přenos mezi zákazníky těchto dvou sítí, zatímco při tranzitu přes toto propojení může procházet i přenos směřující z/do jiného autonomního systému. Tranzit zpravidla není zdarma, je poskytován za úplatu. 5) Procesy a systémy: teorie konečných automatů a její způsoby reprezentace a využití, způsoby komunikace a synchronizace mezi procesy, problém producent-konzument a jeho řešení. Teorie konečných automatů a její způsoby reprezentace a využití Úvod do teorie konečných automatů Když vytváříme specifikaci systému (např. viz kap ), je dobré si stanovit určité základní požadavky na techniku formálního popisu, jako jsou např.: - Tvorba jednoznačných, jasných a stručných specifikací - Možnost verifikování specifikace - Snadný vývoj implementací ze specifikace, přičemž specifikace by měla být implementačně nezávislá Zejména rozsáhlé systémy vyžadují jednoznačný popis. Jedním z možných prostředků jak toho dosáhnout je i teorie konečných automatů

43 Každý systém lze popsat pomocí stavů vstupních veličin X, kde X se mění v závislosti na čase, a pomocí výstupních veličin Y, jejichž hodnoty jsou zpravidla závislé na vstupních veličinách. Skupinu vstupních veličin X označme jako vstupní vektor, podobně skupinu výstupních veličin Y jako výstupní vektor systému. U našeho systému zároveň předpokládáme obecné vnitřní stavy, tj. stavy ve kterých se systém aktuálně nachází, značené Q. Situaci ilustruje Obr Počet vstupních a výstupních proměnných, stejně tak jako vnitřních stavů je konečné diskrétní číslo, v obrázku značeno m pro počet vstupních veličin, n pro počet výstupních veličin a r pro počet možných vnitřních stavů. Kombinační sítě Kombinační sítě (Obr. 8-3) jsou charakterizovány jednoznačným přiřazením výstupní kombinace na každou vstupní kombinaci. Systémy popsané pomocí kombinační sítě tedy nemají definované žádné vnitřní stavy a skládají se pouze z: - Vstupů, které jsou tvořeny vstupním vektorem X = (x1, x2,, xm) - Výstupů, které jsou tvořeny výstupním vektorem Y = (y1, y2,, yn) - Funkce f, která určuje jednoznačný převod vstupního vektoru X na výstupní vektor Y. Funkce může být definována matematicky, převodní tabulkou apod. Sekvenční sítě Sekvenční sítě, na rozdíl od kombinačních, mají nějakým způsobem zakomponovanou vnitřní paměť, která jim umožňuje udržovat si informaci o vnitřním stavu systému Q. Hodnoty výstupního vektoru pak nezávisí pouze na vstupním vektoru, ale zároveň i na stavu systému tak, jak ilustruje Obr Z logiky věci vyplývá, že sekvenční systém musí pracovat diskrétně, nelze ho uvažovat jako spojitý. Systém pracuje sekvenčně, tj. po krocích, označíme-li např. vektor jeho vnitřního stavu Qn v kroku n, v dalším kroku bude vnitřním stavem Qn+1, atd

44 Sekvenční sítě jsou tedy definovány prostřednictvím: - Vstupů, které jsou tvořeny vstupním vektorem X = (x1, x2,, xm) - Výstupů, které jsou tvořeny výstupním vektorem Y = (y1, y2,, yn) - Vnitřních stavů, které jsou dány pamětí obsahující informace o předešlých stavech, značeno taktéž vektorem Q = (q1, q2,, qr), kde r může být chápáno jako kapacita paměti. Počet vnitřních stavů je stejně jako počet možných vstupů a výstupů konečný, odtud pochází název konečné automaty - Operací, pro každé n 0 síť spočítá pomocí vstupního vektoru Xn v daném kroku a aktuálního vnitřního stavu Qn nový vnitřní stav Qn+1. Výstup Yn je dán pomocí Xn a Qn. V systému jsou tedy definovány dvě (obecně odlišné) funkce: o Přechodová funkce Qn+1 = f1 (Xn, Qn) o Výstupní funkce Yn = f2 (Xn, Qn) Jinými slovy, stavem konečného automatu S se rozumí popis v bodě n, tedy množina (Xn, Qn, Yn), což není nic jiného než aktuální vstupy, vnitřní stav a výstupy. Cesta v síti je založena na aktuálním vnitřním stavu a vstupu. Následníkem je takový vnitřní stav Q, do kterého systém přejde. Přímým následníkem je stav, do kterého konečný automat přejde bezprostředně, nepřímý následník je stav, který vyžaduje nejméně dvěma přechody. Jak částečně vyplývá z předchozího textu, algoritmus sekvenční sítě musí mít následující vlastnosti: - Determinizmus poskytované řešení musí být jednoznačné - Hromadnost musí poskytovat možnost řešení (třídy) skupiny úloh - Konečnost počet vnitřních stavů je omezen Skupina dříve uvedených veličin (X, Y, Q, f1, f2) bývá ještě poměrně často doplněna o šestý symbol počáteční stav S0, který popisuje stav systému (sekvenční sítě) na počátku. Grafická reprezentace automatů Velmi častým způsobem zápisu konečných stavových automatů je zápis ve formě grafů. Mezi jeho přednosti patří zejména přehlednost a dobrá čitelnost. Takovýto graf se skládá z: - Uzlů které jsou zaznačeny kroužky a reprezentují jednotlivé vnitřní stavy Qi, případně i hodnotu výstupního vektoru Yi (viz dále) - Orientovaných spojnic spojují vždy jednosměrně dva uzly Mealyho automat U Mealyho automatu platí, že každý uzel určuje jeden stav Q i. Existuje tolik uzlů, kolik existuje stavů. Pro daný pár stavů Q i, Q j existuje nula, jeden nebo i více přechodů zapsaných pomocí orientovaných křivek. Nad spojnici bývá zaznačeno, jaká událost (vstup X i ) přechod vyvolala a za lomítkem pak odpovídající výstup Y i. Jinými slovy lze říci, že výstup závisí jak na aktuálním stavu, tak na vstupu. Ilustrativní příklad je znázorněn na Obr. 99. Mooreho automat Naproti tomu u Moorova automatu platí, že každý uzel určuje nejen stav Q i, ale i odpovídající výstup Y, který je tak možné přímo považovat za funkci stavu, což je formálně zapsáno jako Y(Q i ). Nad spojnicí bývá naznačen pouze vstup X i, který změnu stavu vyvolal. Situace je ilustrována na Obr Jinými slovy lze říci, že výstup automatu vychází pouze z aktuálního stavu, přechody mezi stavy zajišťuje vstup. Výhodou Moorova automatu je snadná čitelnost

45 popisu chování dané sítě z grafu, popis systému pomocí Mealyho automatu však může být v určitých případech stručnější. Nyní si pomocí Mealyho i Mooreho automatu zakresleme předcházející Příklad 8.1, jež jsme v kap zapisovali pomocí tabulek. Situace je znázorněna na Obr Oba tyto grafy nám umožňují přehledně zapsat funkci detektoru binární sekvence 101, již na první pohled je jejich funkce zřejmější než z tabulkového zápisu. Výše uvedený a různými metodami popisovaný příklad je možné považovat za naprosto triviální. Existují stavové automaty s mnohem větším počtem stavů, případně vstup X nese více hodnot a ty jsou vyjádřeny vektorem, jak bylo uvedeno v úvodu kapitoly, X = (x1, x2,, xm), podobně může být i výstup Y taktéž definován vektorem, Y = (y1, y2,, yn). Situace se pak samozřejmě komplikuje a grafický zápis již nemusí být tak přehledný jako na Obr Obecně je možné prakticky libovolný (a nejen) telekomunikační systém specifikovat chováním konečného automatu a zapsat výše uvedenými způsoby. V některých případech samozřejmě nevystačíme pouze s jedním stavovým automatem, ale v systému jich existuje více, běží paralelně, závisle nebo nezávisle na sobě. Jejich počet je dán počtem procesů, které daný systém používá. Komunikace mezi procesy Paralelní aplikace nebo distribuovaný systém je zpravidla tvořen množstvím spolupracujících procesů, z nichž každý zabezpečuje vykonávání určité funkce. Je naprosto zřejmé, že mezi procesy existuje potřeba výměny informací potřeba komunikace. Komunikace mezi procesy představuje klíčový bod v reprezentaci systému a je to také jedna z forem vzájemné spolupráce procesů (viz dále). V praxi rozlišujeme, zda jsou všechny procesy

46 soustředěny do jednoho bloku (vykonávány na jednom procesoru) nebo jsou distribuovány do více bloků (procesorů). Je také velmi důležité, zda komunikace bude probíhat mezi systémem a jeho okolím nebo uvnitř systému. Nejzákladnější rozdělení způsobů komunikace mezi procesy je na dva způsoby: - Asynchronní způsob komunikace - Synchronní způsob komunikace Asynchronní způsob komunikace Asynchronní způsob komunikace spočívá v odeslání zprávy procesem bez zdržení jeho dalšího průběhu, tj. když je zpráva předána vysílacím procesem k odeslání komunikačnímu prostředku, vysílací proces se o osud zprávy dále nestará. Vše probíhá bez ohledu na to, zda je zprávu schopen přijímací proces zpracovat. Tento způsob komunikace má výhodu v tom, že proces odesílající zprávu není dále zdržen např. do okamžiku příjmu potvrzení (může neustále pracovat) a je také méně zatěžována komunikační síť. Zřejmou nevýhodou je, že proces není informován o tom, jak, kdy a zda vůbec bylo uskutečněno předání zprávy, což může být v některých případech kritické. Synchronní způsob komunikace Synchronní způsob je takový způsob, kdy vysílací proces je ve své činnosti pozdržen do té doby, dokud není přijímací proces schopen zprávu přijmout. K výměně informace dojde až po synchronizaci procesů. Hlavním problémem tohoto způsobu komunikace je riziko tzv. uváznutí, kdy jeden z procesů čeká na spojení s protějším procesem a ten neexistuje nebo případně nepožaduje výměnu informace. Tato situace se obvykle řeší vyvoláním časové výjimky. Naopak výhodou je, že proces, který zprávu odeslal, ví, že jeho zpráva byla příjemci předána. Je zřejmé, že synchronní přenos zpráv komplikuje systém přenosu zpráv tím, že v době, kdy proces čeká (např. na potvrzení o přijetí zprávy), se mohou vyskytnout nové události, vyžadující přenos zpráv apod. Na Obr je graficky znázorněna v předcházejícím textu popisovaná rozdílnost mezi asynchronním a synchronním způsobem komunikace

47 Formy synchronizace mezi procesy Dva na sobě nezávislé procesy je možné považovat za asynchronní, což znamená to, že kroky jednoho procesu jsou nezávislé na krocích druhého procesu. Takovéto procesy nejsou schopny vzájemné spolupráce, a proto nás z pohledu komunikačních technologií nebudou příliš zajímat. Procesy, které vzájemně spolupracují, je možné považovat za synchronní a musí mezi nimi existovat určitý způsob synchronizace. Pod pojmem synchronizace procesů si můžeme představit to, že v určitých situacích na sebe musí procesy čekat, např. dokud jeden z nich nedokončí určitou operaci, nemohou ani ostatní pokračovat. Synchronizaci lze zabezpečit více způsoby: - Synchronizace komunikací - Synchronizace následkem konkurence - Synchronizace následkem spolupráce Synchronizace komunikací Synchronizace komunikací mezi více procesy jednoho (distribuovaného) systému předpokládá všestranné šíření informací a procesy jsou tak synchronizovány centrálně. To znamená, že jeden proces šíří zprávy všestranně do svého okolí pro sousedící procesy, z nichž každý tuto zprávu přijme. Rozlišujeme několik podtypů: a) synchronizace událostí Pod pojmem událost rozumíme pouze tzv. "synchronizační impulz", tj. zprávu, která nenese žádnou informaci. Procesy se tak synchronizují pouhou výměnou tohoto impulzu. Jako základní příkazy si lze představit např.: čekej_na_událost(s); pošli_událost(s); kde S značí signál neboli synchronizační impulz. b) synchronizace zprávou V tomto případě ponese synchronizační impuls i zprávu. V systému se pak mohou objevit dva příkazy: čekej_zprávu(z); pošli_zprávu(z); kde Z značí zprávu. c) synchronizace pomocí času Existují situace, kdy odezva (očekávaná událost či zpráva z vnějšího prostředí) musí přijít do určité doby nebo pouze v daný čas. V takovém případě je možné obecně doplnit body a) a b) o dva typy časových údajů. Můžeme tedy zavést operaci typu: očekávej_signál (S, T1, T2); kde S je událost či zpráva, kterou smí proces přijmout v časovém intervalu T1 až T2. Na základě časové operace lze odvodit další kombinace časové synchronizace: očekávej_signál (S, T1); znamená, že signál S může přijít teprve po době T1. očekávej_signál (S, T2); znamená, že signál může přijít do doby T2. očekávej_signál (T1); znamená, že vykonávání procesu se má pozastavit o dobu T1. Příkazy, ve kterých se objevuje doba T2, jsou velmi nebezpečné. Pokud totiž nepřijde událost či zpráva do vypršení této doby, dojde k uváznutí procesu. V praxi se tato situace řeší tak, že

48 po vypršení doby T2 je vyvolána příslušná "časová výjimka". Proces tak začne vykonávat činnost, která ošetří vzniklou situaci, tj. že do zvolené doby nebyla provedena synchronizace. Synchronizace následkem konkurence Synchronizace následkem konkurence je způsobena přístupem různých procesů k omezenému množství zdrojů v systému. Procesy soutěží o přidělení sdílených prostředků, jejichž množství je v systému omezeno. Příkladem mohou být tiskárny, disky, paměť, procesor nebo prostý výpis na obrazovku. Tento problém se nazývá vzájemné vyloučení procesů, neboť s požadovaným zdrojem může pracovat současně pouze jeden proces. Pro realizaci tohoto principu se používá řídící abstrakce, která se nazývá kritické sekce, více viz kap Ta obsahuje zpravidla dvě části, mechanizmus přidělení a manipulace s prostředkem a mechanizmus uvolnění prostředku. Synchronizace následkem spolupráce V případě synchronizace následkem spolupráce je běh procesu závislý na chodu jiných procesů. Systém pak musí umožnit vstup vnějších událostí do systému, což je obvykle řešeno pomocí obsluhy přerušení. Rozeznáváme dva základní způsoby: - synchronizaci na základě podmínek V tomto případě je postup zpracování procesu pozdržen, dokud není splněna jistá podmínka systému. Zde můžeme rozlišovat dva typy systémů, první jsou centralizované systémy, což jsou systémy obsahující globální proměnné v centralizované paměti. Jedná se např. o konstrukci semaforu nebo monitoru boolean proměnné (viz další kapitoly), kdy jsou budovány fronty procesů nad těmito proměnnými. Druhým typem je synchronizace na základě podmínek u distribuovaných systémů. V tomto případě se synchronizace provádí výměnnou zpráv mezi sousedícími procesy. Jako problém se zde jeví, když jeden proces je synchronizován několika jinými procesy. Tehdy se musí vyhodnocovat několik přijatých zpráv. Dalším problémem je nenulový čas přenosu zprávy nesoucí hodnotu. - synchronizaci na základě komunikace - Tato část již byla pojednána v samostatné kapitole , je možné ji ale považovat i za formu synchronizace následkem spolupráce. Procesy si navzájem vyměňují údaje, které rozhodují o dalším vývoji systému. Způsob předávání zpráv závisí na tom, zda jsou všechny procesy soustředěny do jednoho procesoru nebo jsou distribuovány do více procesorů, přičemž každý procesor může mít vlastní skupinu procesů. U distribuovaných systémů lze tak vytvářet různě složité komunikující systémy s různými závislostmi mezi jednotlivými částmi. Výhoda rozdělení úlohy na samostatné procesy má za následek zjednodušení jejich popisu, je však zaplacena časovou ztrátou při komunikaci a duplikací přenášením stejné informace na více míst. Vždy je nutno zvážit množství informace, kterou si procesy musí vyměňovat, aby se nestalo, že výhody plynoucí ze souběžného provádění programů, budou zcela potlačeny časovou ztrátou při komunikaci

49 Problém Producent Konzument Zaměřme se nyní na nutnost vzájemného vyloučení procesů nad sdíleným prostředkem (objektem). Příkladem nutnosti použití vzájemného vyloučení procesů může být i přenos zprávy přes sdílenou oblast paměti. Tu si lze představit jako sdílený prostředek, který používají procesy Producent a Konzument, přičemž proces Producent do ní data zasílá a proces Konzument data odebírá. Situace je ilustrována na Obr Nebude-li přístup obou procesů ke sdílené oblasti žádným způsobem koordinován, může dojít k následujícím situacím: 1) Jestliže zápis do sdílené oblasti paměti skončil dříve, než bylo zahájeno čtení, pak budou získána správná a aktuální data, tedy všechno proběhlo tak jak mělo. 2) Jestliže čtení dat ze sdílené oblasti paměti je ukončeno dříve, než je zahájen jejich zápis (přepis novými daty), je získán předchozí zápis dat. 3) Jestliže čtení dat ze sdílené oblasti probíhá současně se zápisem dat (pokud je to vůbec možné), tj. nad sdílenou oblastí pracují oba procesy, je výsledek značně nejistý. 4) Jestliže jsou další data zapisována do sdílené oblasti paměti v situaci, kdy proces konzument dosud předcházející data nepřečetl, pak dojde k jejich ztrátě. Z 1) až 4) je zřejmé, že pouze situace v bodu 1) přináší správný výsledek, výsledky v ostatních případech jsou chybné a nežádoucí. Proto je vhodné zabezpečit takovou synchronizaci, aby proces Producent mohl zapsat data pouze do prázdné sdílené oblasti a proces Konzument mohl číst jen ze zaplněné sdílené oblasti. Je nezbytné použít takové prostředky, které zajistí synchronizaci procesů při práci nad sdílenou oblastí paměti. Tento případ musí platit nejen pro sdílenou oblast paměti, ale i pro jiné typy sdílených prostředků, než je sdílená oblast, která může být představována např. globální proměnnou