Síťový model TCP/IP

Referenční model ISO/OSI, kterým jsme se v našem seriálu dosud zabývali, je všeobecně považován za koncepci resp. síťovou architekturu, která do budoucna převládne a stane se dominující. Není ale zdaleka koncepcí jedinou, a své budoucí postavení si musí teprve vybojovat. V současné době je největším "rivalem" referenčního modelu ISO/OSI soustava protokolů TCP/IP.

Řekne-li se dnes TCP/IP, je to obvykle chápáno jen jako označení dvou přenosových protokolů, používaných v počítačových sítích s počítači na bázi Unixu, konkrétně protokolů TCP (Transmission Control Protocol) resp. IP (Internet Protocol). Ve skutečnosti ale zkratka TCP/IP označuje celou soustavu protokolů, ne nutně vázanou na operační systém Unix, přičemž TCP a IP jsou sice nejznámější protokoly této soustavy, ale zdaleka ne protokoly jediné. Správnější je ale považovat TCP/IP za ucelenou soustavu názorů o tom, jak by se počítačové sítě měly budovat, a jak by měly fungovat. Zahrnuje totiž i vlastní představu o tom, jak by mělo být síťové programové vybavení členěno na jednotlivé vrstvy, jaké úkoly by tyto vrstvy měly plnit, a také jakým způsobem by je měly plnit - tedy jaké konkrétní protokoly by na jednotlivých úrovních měly být používány. Ve smyslu definice, kterou jsme si zavedli ve 23.kapitole, je tedy TCP/IP síťovou architekturou.

Pohled do historie

Počátky TCP/IP se datují do konce 60. let, a jsou úzce spojeny s činností účelové agentury ARPA (Advanced Research Projects Agency) ministerstva obrany USA, která si nové protokoly nechala vyvinout pro svou počítačovou síť ARPANET. Na vývoji celé soustavy protokolů, financovaném prostřednictvím tzv. grantů ministerstva obrany (účelových dotací na výzkum) se pak podílela počítačově orientovaná pracoviště předních univerzit USA. Svou dnešní podobu získaly nové protokoly zhruba v letech 1977-79, a brzy poté na ně začala postupně přecházet i vlastní síť ARPANET, která se posléze stala zárodkem a páteří celého konglomerátu sítí, nazývaného dnes příznačně Internet.

Agentura ARPA (mezitím přejmenovaná na DARPA) se pak snažila prosadit nově vytvořené protokoly (a vlastně i celou ucelenou síťovou architekturu) do praktického života i mimo síť ARPANET, především pak do akademického prostředí. Většina univerzitních počítačových pracovišť v USA v té době provozovala nějakou verzi tzv. BSD Unixu, pocházející ze střediska Berkeley Software Distribution (BSD) na University of California v Berkeley. Agentura DARPA si proto nechala u přední americké firmy Bolt, Beranek and Newman (BBN) na zakázku vyvinout implementaci TCP/IP protokolů pod operační systém Unix, a univerzitě v Berkeley přispěla výzkumnými granty na začlenění těchto protokolů do univerzitou distribuovaných produktů. Tím se protokoly TCP/IP prosadily do BSD Unixu, a posléze pak i do ostatních verzí Unixu buď přímo jako jejich standardní součást, nebo jako volitelný doplněk (option). Díky své popularitě se však záhy dostaly i na jiné platformy, a dnes jsou implementovány snad ve všech výpočetních prostředích, od osobních počítačů PC s operačním systémem MS DOS až např. po sálové počítače (mainframes) firmy IBM a operační systém VM.

Pro svůj úzký vztah k síti Internet je soustava protokolů TCP/IP někdy označována také jako Internet protocol suite (doslova: soustava protokolů Internetu), nebo též Department of Defense (DoD) protocol suite, což naopak zdůrazňuje vztah k ministerstvu obrany USA.

Filosofie TCP/IP

Hlavní odlišnosti mezi referenčním modelem ISO/OSI a TCP/IP vyplývají především z rozdílných výchozích předpokladů a postojů jejich tvůrců. Jak jsme si již naznačili v předchozích dílech našeho seriálu, při koncipování referenčního modelu ISO/OSI měli hlavní slovo zástupci spojových organizací. Ti pak nově vznikajícímu modelu vtiskli svou vlastní představu - především spojovaný a spolehlivý charakter služeb, poskytovaných v komunikační podsíti (tj. až do úrovně síťové vrstvy, včetně). Jinými slovy: ISO/OSI model počítá se soustředěním co možná nejvíce funkcí, včetně zajištění spolehlivosti přenosů, již do komunikační podsítě, která v důsledku toho bude muset být poměrně složitá, zatímco k ní připojované hostitelské počítače budou mít relativně jednoduchou úlohu. Později se ale uzalo, že například právě v otázce zajištění spolehlivosti to není nejšťastnější řešení - že totiž vyšší vrstvy nemohou považovat spolehlivou komunikační podsíť za dostatečně spolehlivou pro své potřeby, a tak se snaží zajistit si požadovanou míru spolehlivosti vlastními silami. V důsledku toho se pak zajišťováním spolehlivosti do určité míry zabývá vlastně každá vrstva referenčního modelu ISO/OSI.

Tvůrci protokolů TCP/IP naopak vycházeli z předpokladu, že zajištění spolehlivosti je problémem koncových účastníků komunikace, a mělo by tedy být řešeno až na úrovni transportní vrstvy. Komunikační podsíť 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. Komunikační podsíť tedy podle této představy nemusí být zcela spolehlivá - může v ní 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: best effort), a zahazovat pakety až tehdy, když je skutečně nemůže doručit - tedy např. když dojde k jejich poškození při přenosu, když pro ně není dostatek 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 (ale rychlou) komunikační podsíť, ke které se připojují inteligentní hostitelské počítače.

Další odlišnost od referenčního modelu ISO/OSI spočívá v názoru na to, jak má komunikační síť vlastně fungovat. Zatímco model ISO/OSI počítá především se spojovaným přenosem - tedy s mechanismem virtuálních okruhů, TCP/IP naopak předpokládá nespojovaný charakter přenosu v komunikační podsíti - tedy jednoduchou datagramovou službou - což ostatně vyplývá i z představy co možná nejjednodušší komunikační podsítě.

 

Čtyři vrstvy TCP/IP

Zatímco referenční model ISO/OSI vymezuje sedm vrstev síťového programového vybavení, TCP/IP počítá jen se čtyřmi vrstvami.

Nejnižší vrstva, vrstva síťového rozhraní (Network Interface Layer) (někdy též: linková vrstva resp. Link Layer) má na starosti vše, co je spojeno s ovládáním konkrétní přenosové cesty resp. sítě, a s přímým vysíláním a příjmem datových paketů. V rámci soustavy TCP/IP není tato vrstva blíže specifikována, neboť je závislá na použité přenosové technologii.

Vrstvu síťového rozhraní může tvořit relativně jednoduchý ovladač (device driver), je-li daný uzel přímo připojen například k lokální síti či ke dvoubodovému spoji, nebo může tato vrstva představovat naopak velmi složitý subsystém, s vlastním linkovým přenosovým protokolem (např. HDLC apod.). Vzhledem k velmi častému připojování jednotlivých uzlů na lokální sítě typu Ethernet je vrstva síťového rozhraní v rámci TCP/IP často označována také jako Ethernetová vrstva (Ethernet Layer).

Bezprostředně vyšší vrstva, která již není závislá na konkrétní přenosové technologii, je vrstva síťová, v terminologii TCP/IP označovaná jako Internet Layer (volněji: vrstva vzájemného propojení sítí), nebo též IP vrstva (IP Layer) podle toho, že je realizována pomocí protokolu IP. Úkol této vrstvy je v prvním přiblížení stejný, jako úkol síťové vrstvy v referenčním modelu ISO/OSI - stará se o to, aby se jednotlivé pakety dostaly od odesilatele až ke svému skutečnému příjemci, přes případné směrovače resp. brány. Vzhledem k nespojovanému charakteru přenosů v TCP/IP je na úrovni této vrstvy zajišťována jednoduchá (tj. nespolehlivá) datagramová služba.

Třetí vrstva TCP/IP je označována jako transportní vrstva (Transport Layer), nebo též jako TCP vrstva (TCP Layer), neboť je nejčastěji realizována právě protokolem TCP (Transmission Control Protocol). Hlavním úkolem této vrstvy je zajistit přenos mezi dvěma koncovými účastníky, kterými jsou v případě TCP/IP přímo aplikační programy (jako entity bezprostředně vyšší vrstvy). Podle jejich nároků a požadavků může transportní vrstva regulovat tok dat oběma směry, zajišťovat spolehlivost přenosu, a také měnit nespojovaný charakter přenosu (v síťové vrstvě) na spojovaný.

Přestože je transportní vrstva TCP/IP nejčastěji zajišťována právě protokolem TCP, není to zdaleka jediná možnost. Dalším používaným protokolem na úrovni transportní vrstvy je například protokol UDP (User Datagram Protocol), který na rozdíl od TCP nezajišťuje mj. spolehlivost přenosu - samozřejmě pro takové aplikace, které si to (na úrovni transportní vrstvy) nepřejí.

Nejvyšší vrstvou TCP/IP je pak vrstva aplikační (Application Layer). Jejími entitami jsou jednotlivé aplikační programy, které na rozdíl od referenčního modelu ISO/OSI komunikují přímo s transportní vrstvou. Případné prezentační a relační služby, které v modelu ISO/OSI zajišťují samostatné vrstvy, si zde musí jednotlivé aplikace v případě potřeby realizovat samy.

 

TCP/IP a vzájemné propojování sítí

Způsob, jakým je v referenčním modelu ISO/OSI řešena otázka vzájemného propojování sítí, jsme si naznačili ve 40. kapitole. Z nejrůznějších materiálů o referenčním modelu však lze vycítit, že tato problematika do něj byla zapracována spíše až na poslední chvíli, a rozhodně nepatří mezi nejsilnější stránky celého referenčního modelu ISO/OSI. V případě TCP/IP je tomu jinak - vzájemné propojování sítí stejného i odlišného typu bylo jedním z výchozích předpokladů celé soustavy protokolů TCP/IP, a je v ní také řešeno mnohem systematičtěji, než v referenčním modelu ISO/OSI.

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če, bez ohledu na to, zda mezi nimi existuje přímé spojení, nebo zda jsou například oba uzly různých sítí, 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 internet (s malým "i", viz též 38. kapitola). Z pohledu uživatele by však vnitřní struktura této soustavy sítí měla být irelevantní - uživatelé, resp. jejich aplikační programy, se mohou na celý internet 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).

Brány, čili IP směrovače

Ve skutečnosti je ovšem výsledná soustava - internet - stále jen konglomerátem (dílčích) sítí stejného či různého typu, vzájemně propojených pomocí propojovacích zařízení. Tato propojovací zařízení se přitom v terminologii TCP/IP označují jako brány (gateway), Podobně jako referenční model ISO/OSI, předpokládají i protokoly TCP/IP, že propojení jednotlivých dílčích sítí bude realizováno na úrovni síťové vrstvy. Podle obvyklých definic, které jsme si uvedli ve 38. kapitole, jsou pak ale brány (v terminologii TCP/IP) ve skutečnosti spíše směrovači (routers). Tento dosti nepříjemný terminologický konflikt se některé novější odborné prameny snaží řešit zavedením výstižnějšího termínu IP router (tj. IP směrovač).

Úloha síťové vrstvy

Je to tedy právě síťová vrstva (resp. tzv. IP vrstva, realizovaná protokolem IP, viz minule), která 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 však 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. Pro každou síť či každý přenosový kanál, na který je brána připojena, má samostatný ovladač na úrovni vrstvy síťového rozhraní.

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 mechanismu 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.

Jednotná abstrakce

Síťová vrstva, resp. protokol IP, který se pro její realizaci používá, vytváří jednotnou abstrakci všech dílčích sítí, která umožňuje pracovat s jediným typem virtuální sítě, namísto s více či méně odlišnými dílčími sítěmi. Tato jednotná abstrakce spočívá nejen v zavedení jednotného způsobu adresování, ale také v jednotném formátu datových paketů, používaných na úrovni síťové vrstvy, tzv. IP datagramů (IP datagrams), a v poskytování jednotné přenosové služby - nespolehlivé nespojované (datagramové) služby.

 

IP adresy

Adresy, které protokol IP zavádí (a které jsou proto označovány jako tzv. IP adresy), jsou 32-bitové. 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í (tato interpretace pak odpovídá představě vzájemně propojených dílčích sítí. Přesnému formátu a významu IP adres se budeme ještě věnovat v samostatném dílu našeho seriálu.

Je dobré si znovu zdůraznit, že IP adresy jsou pouze abstraktními adresami, které musí být posléze převedeny na skutečné fyzické adresy. Kdykoli totiž ovladač na úrovni vrstvy síťového rozhraní 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í dostat 48-bitovou Ethernetovou adresu. K mechanismu, kterým se v TCP/IP sítích zjišťuje korespondence mezi IP adresami a konkrétními specifickými adresami, se samozřejmě vrátíme ještě podrobněji.

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ž výše zmíněné IP datagramy. Jde o datové pakety, označované jako datagramy proto, že jsou přenášeny pomocí nespojované (též: 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 v obecném případě síť od sítě liší!

Význam přenášených dat na úrovni jednotlivých vrstev ilustruje obrázek 34.3.: zatímco aplikační a transportní vrstvy vůbec "neví" o existenci jednotlivých dílčích sítí (a jako koncoví účastníci přenosu si tak předávají vždy přesně stejný tvar paketů, resp. zpráv), na úrovni vrstvy síťového rozhraní se přenáší identické rámce jen v jednotlivých dílčích sítí. V každé z nich je pak přenášen IP datagram vždy stejného formátu, který se ovšem přeci jen v něčem liší - například v hodnotě čítače, který vyjadřuje životnost paketu (což je součást mechanismu, který má zabránit případnému zacyklení).

 

Adresování v TCP/IP sítích - I.

V minulém dílu našeho seriálu jsme si naznačili, že síťový model TCP/IP zavádí na úrovni síťové vrstvy jednotnou abstrakci všech dílčích sítí, které tvoří výslednou soustavu vzájemně propojených sítí - tzv. internet. Podstata této abstrakce spočívá mj. i v použití jednotných 32-bitových adres, a to bez ohledu na skutečné (fyzické) adresy, používané v jednotlivých dílčích sítích. Podívejme se nyní na otázku IP adres poněkud podrobněji.

Jak jsme si již také uvedli minule, 32-bitové adresy, používané na úrovní síťové vrstvy (tzv. IP adresy), mohou být chápány jako jednosložkové (lineární) adresy, vyjadřující právě a pouze adresu jednoho hostitelského počítače. Pro síťovou vrstvu je ale 32-bitová IP adresa vždy dvousložková, tvořená číslem resp. adresou (dílčí) sítě a číslem resp. adresou hostitelského počítače, který se v této síti nachází. Tato představa pak odpovídá členění výsledné soustavy sítí (internet-u) na jednotlivé dílčí sítě, kterými mohou být například jednotlivé lokální sítě typu Ethernet, Token Ring apod., až po velké rozlehlé sítě s velkým počtem hostitelských počítačů.

Podstata směrování v TCP/IP sítích

Důvod, proč síťová vrstva pracuje právě s takovouto představou, a nikoli s představou jednolité, dále nestrukturované výsledné sítě, je veskrze praktický: v zájmu minimalizace objemu směrovacích tabulek je směrování v TCP/IP sítích založeno jen na adresách (dílčích) sítí, a nikoli na adresách jednotlivých hostitelských počítačů v rámci těchto sítí.

Právě vyslovené tvrzení si zaslouží poněkud upřesnit: Každý hostitelský počítač, který chce odeslat nějaký IP datagram jinému hostitelskému počítači, dokáže z IP adresy příjemce snadno rozpoznat, zda tento leží ve stejné dílčí síti či nikoli. Pokud ano (nachází-li se například v téže síti typu Ethernet), pošle mu odesilatel svůj datagram přímo. Pokud se ale příjemce nachází v jiné síti, pošle odesilatel svůj datagram nejbližší bráně (resp. IP směrovači, viz minule) ve "své" síti. Na ní je pak rozhodnout, kudy datagram poslat dále. Podstatné přitom je, že při svém rozhodování vychází brána pouze z té části IP adresy konečného příjemce, která vyjadřuje příslušnou cílovou síť. V prvním přiblížení si lze představit, že každá brána má své směrovací tabulky ve formě seznamu dvojic <<I>síť,brána>, a podle cílové sítě příjemce si v nich najde, které bráně má příslušný datagram poslat dále. Zbývající část IP adresy příjemce, která vyjadřuje adresu hostitelského počítače v rámci cílové sítě, pak využije až ta brána (poslední v řetězci), která již leží v příslušné cílové síti, a která pak datagram pošle přímo jeho konečnému adresátovi.

Třídy IP adres

32 bitů, vyhrazených pro IP adresy, je tedy nutné vhodným způsobem rozdělit na dvě části, tak aby tyto mohly vyjadřovat adresu sítě a adresu hostitelského počítače v rámci této sítě. Otázkou ovšem je, jak toto rozdělení provést. Filosofie síťového modelu TCP/IP totiž předpokládá, že jednotlivými dílčími sítěmi mohou být jak "malé" sítě s několika málo uzly (hostitelskými počítači), tak i "velké" sítě s tisíci i desítkami tisíc uzlů. Třicet dva bitů, které jsou k dispozici, pak nelze rozdělit jediným způsobem, který by pamatoval na sítě s velkým počtem uzlů, a současně měl i dostatečně velkou rezervu pro rychle rostoucí počet jednotlivých dílčích sítí.

Řešení, uplatněné u IP adres, pak spočívá v zavedení tří různých způsobů rozdělení 32 bitů na dvě části, resp. v zavedení tří různých formátů IP adres: jednoho pro dílčí sítě s velkým počtem uzlů resp. hostitelských počítačů, jednoho pro "středně velké" sítě, a jednoho pro "malé" sítě, s relativně malým počtem uzlů.

Adresy třídy A mají pro adresu sítě vyhrazeno 7 bitů, a pro adresu hostitelského počítače 24 bitů. Adres této třídy je tedy relativně velmi málo, počítají však s velmi velkým počet uzlových počítačů. Jsou určeny pro velké rozlehlé sítě, jako např. síť ARPAnet (viz 38. díl seriálu), která se stala zárodkem sítě Internet, pro velké veřejné sítě, případně i velké podnikové sítě. Adresy třídy B, které připouští až 65534 uzlů (hostitelských počítačů), jsou určeny pro středně velké sítě, např. pro univerzitní sítě, podnikové sítě apod., a používají se též v souvislosti s tzv. subnetting-em (podsítěmi, viz dále). Adresy třídy C, které počítají jen se 254 uzly, jsou pak určeny pro všechny ostatní sítě.

Symbolický zápis IP adres

32-bitové IP adresy je samozřejmě možné 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 vhodná 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á z těchto čá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í). Například nepříliš mnemonický tvar 10000000 00000001 00000010 00000011 tak dostává přehlednější podobu: 128.1.2.3.

první oktet adresysíťová část adresyčást adresy, představující relativní adresu uzlu v rámci sítěmaximální počet hostitelských počítačůtřída A1-126p q.r.s16777214třída B128-191p.qr.s65534třída C192-223p.q.rs254Tabulka 44.3.: Desítková tečkovaná notace a IP adresy (je-li p.q.r.s obecný tvar IP adresy)

Jak volit IP adresy?

V principu je možné volit IP adresy dle vlastního uvážení. Je ovšem nutné dbát na dodržení jedné zásadní podmínky, a tou je jednoznačnost. Nesmí se totiž stát, aby se v jakémkoli konglomerátu vzájemně propojených sítí adresy dvou různých sítí shodovaly (přesněji ty části IP adres, které vyjadřují adresu sítě) - jinak totiž bude mít mechanismus směrování velké problémy.

U každé počítačové sítě či soustavy sítí, budované pomocí protokolů TCP/IP, je však prakticky jen otázkou času, kdy je jejich provozovatelé budou chtít připojit do dnes již celosvětové sítě Internet (viz např. CW 7/92). Také zde samozřejmě platí zásada jednoznačnosti adres, takže všechny nově připojované sítě musí mít dosud nepoužité adresy. V Internetu proto existuje centrální autorita (konkrétně: DDN Network Information Center, SRI International, 333 Rawenswood Avenue, Menlo Park, California 94025), která se stará o hospodaření s IP adresami, a přiděluje je všem potenciálním zájemcům (přesněji: přiděluje tu část IP adres, která představuje adresu sítě, zatímco zbývající část IP adres si volí žadatel. Ve skutečnosti tak přiděluje vlastně celé skupiny IP adres se shodnou první částí). Skutečné připojení k síti Internet přitom vůbec není podmínkou pro přidělení adresy, takže je naopak dobré si přidělení adresy vyžádat co nejdříve, pokud možno ještě před zprovozněním jakékoli sítě na bázi TCP/IP (a tím se vyhnout pozdější změně IP adres, která je samozřejmě možná, ale obvykle značně pracná).

V našich zeměpisných šířkách však není nutné se pro přidělení IP adresy obracet až do USA. DDN NIC, která adresy spravuje, totiž delegovala svou pravomoc v přidělování IP adres pro oblast ČSFR výpočetnímu centru pražské VŠCHT (Technická 5, 166 28 Praha 6).

Subnetting

Jak jsme si již naznačili výše, při směrování v TCP/IP sítích se vychází pouze z té části IP adresy, která představuje adresu (dílčí) sítě. Výhodou jsou neskonale menší směrovací tabulky, než jaké by musely být v případě směrování podle celých IP adres.

Přesto se ale v síti Internet záhy ukázalo, že i tak vychází směrovací tabulky větší, než by bylo vhodné. Proto se zpětně do TCP/IP prosadil mechanismus, označovaný v angličtině jako subnetting, který se snaží další nárůst směrovacích tabulek omezit.

Myšlenku tohoto mechanismu si můžeme ukázat na příkladu organizace, připojené k síti Internet, která provozuje více dílčích sítí, a pro každou z nich má přidělenu samostatnou adresu (nejspíše třídy C). Každá z těchto dílčích sítí je pak ovšem "samostatně viditelná" i z vně příslušné organizace, a jako se samostatnou je s ní také nakládáno - ve směrovacích tabulkách každá zabírá samostatnou položku. Kdyby se ovšem příslušná organizace sama postarala o potřebné směrování mezi svými sítěmi, a navenek vystupovala jako jediný celek, mohla by mít přidělenu jen jednu síťovou adresu (například třídy B místo více síťových adres třídy C), a ve směrovacích tabulkách by tak zabírala jen jednu položku. Všechny dílčí sítě, patřící příslušné organizaci, by tak navenek vystupovaly jako síť jediná, s jedinou společnou adresou (přesněji: s IP adresami, které se shodují v části, vyjadřující adresu sítě). Skutečné vnitřní členění této navenek jednotné sítě by pak bylo plně v kompetenci příslušné organizace. Ta by také musela změnit přesný způsob, jakým sama interpretuje IP adresy svých hostitelských počítačů, a to podle obrázku 44.1. b/ - tu část, která z vnějšího pohledu představuje číslo resp. adresu hostitelského počítače, by pro sebe musela rozdělit na dvě části - číslo resp. adresu své dílčí sítě (podsítě, neboli subnet, odsud subnetting), a na číslo resp. adresu hostitelského počítače v rámci této podsítě. V nejjednodušším případě adresy třídy B tak, že třetí oktet bude považovat za číslo podsítě, a čtvrtý za číslo uzlu (hostitelského počítače). V obecném případě pak podle tzv. masky podsítě (subnet mask), která obě části IP adresy nově definuje.

 

Adresování v TCP/IP sítích - II.

V minulém dílu našeho seriálu jsme se podrobněji zabývali IP adresami. Víme již, že představují jednotné adresy, které používá libovolný konglomerát vzájemně propojených sítí na bázi soustavy protokolů TCP/IP. Jsou však stále jen abstrakcí na úrovni síťové vrstvy, která odpovídá představě jednotné virtuální sítě. Ta je ale ve skutečnosti realizována dílčími sítěmi více či méně odlišného typu, které používají své vlastní mechanismy adresování a formáty adres. Proto také IP adresy musí být převáděny na takové konkrétní (fyzické) adresy, jaké příslušná dílčí síť skutečně používá (na úrovni vrstvy síťového rozhraní). Otázkou ovšem je, jak takovýto převod vůbec realizovat.

Představme si dva hostitelské počítače A a B, které mají po řadě IP adresy IA a IB. Předpokládejme dále, že jde o uzly téže (dílčí) sítě, které díky tomu mohou komunikovat mezi sebou přímo (resp. nejsou odkázány na bránu, resp. IP směrovač, propojující různé dílčí sítě). V rámci "své" dílčí sítě přitom mají oba uzly fyzické adresy FA a FB. Jestliže nyní síťová vrstva (IP vrstva) počítače A dostane od své transportní vrstvy za úkol přenést určitá data počítači s IP adresou IB(tj. počítači B), musí být schopna zajistit převod IP adresy IB na fyzickou adresu FB. Tu totiž potřebuje příslušný ovladač v bezprostředně nižší vrstvě (vrstvě síťového rozhraní), aby mohl přenášená data skutečně doručit. Podobně počítač B: jakmile bude chtít počítači A odpovědět, musí vědět, jaká fyzická adresa (FA) odpovídá IP adrese počítače A (IA).

Problém transformace adres a jeho řešení

Problém transformace adres vyšší úrovně na adresy nižší úrovně, konkrétně nalezení odpovídající fyzické adresy k IP adrese, se označuje jako address resolution problem. Je možné jej řešit například formou tabulky, obsahující seznam vzájemně si odpovídajících adres. Je to ovšem spojeno s četnými problémy - kdo a jak zajistí počáteční naplnění tabulky, kdo ji bude udržovat a přizpůsobovat momentálnímu stavu sítě, kdo zajistí, aby její velikost nepřesáhla únosnou mez atd.

Tam, kde je to jen trochu možné, se proto používají spíše jiná řešení, která jsou ovšem závislá na konkrétní povaze (dílčí) sítě a jím používaném mechanismu adresování.

Řešení pomocí přímého převodu

Velmi jednoduchá myšlenka, které se v této souvislosti sama nabízí, je neřešit převod výčtem (tj. pomocí tabulky), ale pomocí vhodné tranformační funkce (vzorečku pro převod). To je ale možné jen tam, kde si uživatel resp. zřizovatel sítě může fyzické adresy jednotlivých uzlových počítačů volit sám, podle vlastních potřeb. Tak je tomu například v sítích ARCnet či proNET-10, kde si uživatel při instalaci síťové karty do svého počítače sám volí její fyzickou adresu (a tím i fyzickou adresu počítače, připojeného prostřednictvím této síťové karty). Má-li například volitelná fyzická adresa rozsah 8 bitů (jako je tomu právě u sítí ARCnet i proNET-10), je nejjednodušší volit ji shodně s posledním oktetem (posledními osmi bity) IP adresy. Transformace IP adresy na fyzickou se pak stává zcela triviální.

Řešení pomocí dynamické vazby

Možnost volit fyzickou adresu přímo na síťovém adaptéru při jeho instalaci je v praxi únosná jen pro adresy malého rozsahu. Především je ale spojena s potenciálním nebezpečím lidských chyb, které mohou vyústit v existenci dvou adaptérů resp. uzlů se stejnou fyzickou adresou v jedné síti. Jiné síťové technologie se proto k celému problému staví opačně - uživateli nedávají žádnou možnost ovlivnit fyzickou adresu síťového adaptéru. Ten ji má v sobě jednou provždy pevně zabudovánu.

Takto je tomu například u lokálních sítí typu Ethernet. Ty používají fyzické adresy v rozsahu 48 bitů, které v příslušných síťových adaptérech nastavuje přímo jejich výrobce. Aby se zajistila jednoznačnost adres i mezi síťovými adaptéry různých výrobců, musí si každý z nich nechat přidělit určitý rozsah adres od centrální autority, která Ethernetovské adresy spravuje (a kterou je v tomto konkrétním případě americké sdružení IEEE).

Jakmile je ale potřeba transformovat 32-bitové IP adresy na 48-bitové Ethernetovské (či jiné "velké" adresy, které není možné podle potřeby volit), nezbývá než vrátit se zpět k převodním tabulkám, definujícím vzájemnou vazbu mezi jednotlivými adresami. Pokud možno ale nikoli ke statickým tabulkám, ale naopak k tabulkám dynamickým, které se vytváří a modifikují průběžně, podle okamžitého stavu sítě.

 

Protokol ARP

V soustavě protokolů TCP/IP je zahrnut velmi elegantní mechanismus dynamického budování a udržování převodních tabulek mezi IP adresami a fyzickými adresami, založený na protokolu ARP (Address Resolution Protocol). Ten využívá schopnosti všesměrového vysílání (tzv. broadcastingu) v některých sítích, které umožňují adresovat datový rámec všem uzlům dané lokální (resp. dílčí) sítě současně - bez nutnosti znát jejich konkrétní adresy. Například v sítích typu Ethernet lze vyslat datový rámec na jednu, předem známou speciální adresu, na kterou "slyší" všechny síťové adaptéry bez ohledu na svou konkrétní fyzickou adresu. Protokol ARP této možnosti využívá tak, že si jejím prostřednictvím nechá najít majitele příslušné IP adresy:

Představme si situaci, kdy jeden uzlový počítač chce zaslat nějaká data jinému počítači v téže dílčí síti. Zná však pouze jeho IP adresu, nikoli jeho fyzickou adresu. Protokol ARP prvního počítače proto využije možnosti všesměrového vysílání, a všem uzlům dané dílčí sítě pošle zvláštní rámec resp. paket s dotazem: "Kdo má IP adresuţ....?". Tento rámec přijmou všechny uzly, a všechny také vyhodnotí paket, který je v něm obsažen. Pouze uzel B však rozpozná, že obsahuje jemu určený dotaz, a tak na něj odpoví zasláním své fyzické adresy (opět prostřednictvím speciálního paketu, jehož formát definuje protokol ARP). Ostatní uzly přitom na původní dotaz neodpovídají.

Nebylo by ale únosné se takovýmto způsobem ptát při každém jednotlivém přenosu vždy znovu. Každý uzlový počítač si proto sám průběžně vytváří potřebnou převodní tabulku mezi IP adresami a fyzickými adresami (ve vhodné vyrovnávací paměti), a právě naznačený mechanismus využívá až v případě, kdy ji potřebuje doplnit či aktualizovat.

 

Protokol RARP

Protokol ARP umožňuje, aby každý hostitelský počítač (uzel) po svém spuštění vystačil jen se znalostí své vlastní fyzické adresy a své vlastní IP adresy (kterou si obvykle přečte z konfiguračního souboru na svém pevném disku). Na fyzické adresy všech ostatních uzlů ve své dílčí sítí se pak vhodně "doptá". Otázkou ovšem je, jak tomu bude v případě bezdiskových stanic, které si svou IP adresu z vlastního pevného disku přečíst nemohou.

Po svém spuštění si každá bezdisková stanice musí svou vlastní IP adresu nejprve vyžádat na jiném uzlovém počítači, který vůči ní vystupuje v roli serveru IP adres. Způsob, jakým se na něj bezdisková stanice obrací, je analogický výše naznačenému mechanismu protokolu ARP - prostřednictvím všesměrového vysílání bezdisková stanice rozešle všem ostatním uzlům dotaz typu: "Jaká je moje IP adresa?". Sebe sama přitom stanice identifikuje prostřednictvím fyzické adresy, kterou má zabudovánu ve svém síťovém adaptéru.

Konkrétní protokol, prostřednictvím kterého si bezdisková stanice může svou IP adresu vyžádat, vychází z protokolu ARP, a je označován jako RARP (Reverse Address Resolution Protocol).

 

Směrování v TCP/IP sítích - I.

 Další z aspektů, důležitých pro pochopení celkové filosofie soustavy protokolů TCP/IP, je otázka směrování ve vzájemně propojených sítích. Z ní jsme si něco naznačili již ve 43. dílu našeho seriálu, nyní se však touto problematikou budeme zabývat podrobněji.

Nejprve si ale připomeňme, jakým způsobem se protokoly TCP/IP dívají na vzájemně propojené sítě (tzv. internet): předpokládají, že jednotlivé (dílčí) sítě jsou propojeny prostřednictvím bran (gateways), označovaných také jako IP směrovače (IP routers). Vzájemné propojení je přitom takové, že mezi libovolnými dvěma dílčími sítěmi vždy existuje alespoň jedna cesta, která ovšem může vést i přes více jiných dílčích sítí, resp. procházet posloupností bran, propojujících mezilehlé sítě.

Každá brána je vždy připojena nejméně do dvou dílčích sítí, a slouží pouze potřebám směrování (a nikoli k provozování uživatelských aplikací). Tím se brány odlišují od druhého typu uzlů, které naopak slouží především k provozování aplikačních programů, a které se v terminologii TCP/IP označují jako hostitelské počítače (hosts, host computers). Také hostitelské počítače však mohou být připojeny do dvou či více dílčích sítí současně (pak jde o tzv. multi-homed hosts), a mohou tedy fungovat i jako brány. Přestože se toto řešení v praxi občas používá (hlavně v akademickém prostředí), není vždy bezproblémové. Filosofie TCP/IP však velmi ostře rozlišuje mezi hostitelským počítačem a bránou, a proto i my se přidržíme představy dvou fyzicky různých zařízení.

Přímé a nepřímé směrování

Obecně lze říci, že na směrování jakožto rozhodování o tom, kudy dále poslat datový paket, se podílí oba druhy uzlů TCP/IP sítí, tedy jak brány, tak i hostitelské počítače. Záměr je ovšem takový, aby se hostitelské počítače zabývaly směrováním jen v minimální možné míře, a maximum práce na tomto poli přenechaly bránám.

Představme si situaci kdy hostitelský počítač A chce odeslat IP datagram hostitelskému počítači B. Z IP adresy počítače B jednoduchým způsobem rozpozná, že leží v téže dílčí sítí (viz 43. díl našeho seriálu), a tak mu IP datagram pošle přímo. Tento případ je v terminologii TCP/IP označován jako tzv. přímé směrování (direct routing). Jeho režie je minimální: vzhledem k formátu IP adres je triviální rozpoznat, zda příjemce leží v téže dílčí síti, a pokud ano, dílčí síť umožňuje odeslat příslušný datagram jeho koncovému adresátovi přímo.

Nyní si ale představme situaci, kdy hostitelský počítač A chce odeslat IP datagram hostitelskému počítači C. Jelikož z jeho IP adresy rozpozná, že leží v jiné dílčí síti, pošle datagram bráně G (ve "své" dílčí síti). Tím úloha hostitelského počítače A jako odesilatele končí, a další je již na bráně G resp. na celé struktuře bran, které musí být schopné si datagram postupně předávat tak dlouho, dokud se nedostane do cílové dílčí sítě, kde pak může být prostřednictvím přímého směrování odeslán hostitelskému počítači, který je jeho konečným adresátem. Právě naznačený případ odpovídá tzv. nepřímému směrování (indirect routing), ke kterému na rozdíl od směrování přímého dochází tehdy, jestliže adresát není v téže dílčí síti jako odesilatel, a ten proto posílá datagram bráně.

Volba mezi více bránami

Vzhledem k tomu, že vzájemně propojené sítě tvoří souvislý celek, musí být v každé dílčí síti vždy alespoň jedna brána. Nemusí ovšem být zdaleka jen jedna. Představme si jednoduchý příklad kde má hostitelský počítač A na výběr dvě brány, G1 a G2. Každá z nich by sice měla být schopna doručit IP datagram kamkoli je třeba, ale žádná z nich nebude zřejmě optimální pro všechny možné cíle - k některým vede kratší cesta přes bránu G1, k jiným zase přes bránu G2. Znalost toho, kdy je výhodnější poslat datagram bráně G1 a kdy bráně G2, by ale měl mít již hostitelský počítač A. Je samozřejmě možné, aby tento hostitelský počítač měl potřebné informace "pevně zabudovány" ve svých konfiguračních souborech, podle nichž si pak vytváří své směrovací tabulky. Ve vzájemně propojených sítích malého rozsahu a s minimem dynamických změn to je rozumné řešení, v případě větších a častěji se měnících konglomerátů sítí již nikoli. Zde již je nutný jiný mechanismus, umožňující provádět dynamickou aktualizaci směrovacích tabulek hostitelských počítačů podle okamžité situace.

Filosofie směrování v TCP/IP ale vychází z toho, že znát nejvhodnější cesty a průběžně reagovat na skutečnou situaci je úkolem bran, a nikoli hostitelských počítačů. V soustavě protokolů TCP/IP je proto zabudován mechanismus, pomocí kterého je celý problém velmi elegantně řešen: kdykoli nějaká brána zjistí, že některý hostitelský počítač používá neoptimální cestu, upozorní jej na tuto skutečnost. Ukažme si to na příkladu: nechť hostitelský počítač A v dílčí síti X pošle bráně G1 IP datagram, určený počítači C v dílčí síti Y. Brána G1 zná optimální cestu a ví, že ze sítě X do sítě Y je výhodnější použít bránu G2. O doručení přijatého datagramu se brána G1 ještě postará, ale současně s tím upozorní hostitelský počítač A, že další datagramy, směřující do sítě Y, již má posílat přes bránu G2. Hostitelský počítač A si tuto informaci zanese do svých směrovacích tabulek, a nadále se podle ní řídí.

Právě naznačený mechanismus má jeden velmi příjemný efekt - jednotlivé hostitelské počítače vystačí na počátku (tj. při svém spuštění) se znalostí jedné jediné brány ve "své" dílčí síti. Další brány se pak "naučí" používat díky právě popsanému mechanismu. Ten je v praxi zajišťován prostřednictvím protokolu ICMP (Internet Control Message Protocol), který je povinnou součástí protokolu IP, a slouží obecně pro předávání řídících informací a zpráv o chybách a nestandardních situacích.

Připomeňme si však ještě jednu významnou skutečnost, kterou jsme si uvedli již ve 43. dílu našeho seriálu - kvůli minimalizaci rozsahu směrovacích tabulek je veškeré směrování v TCP/IP sítích založeno jen na dílčích sítích jako takových, a nikoli na jednotlivých hostitelských počítačích (přesněji: na té části IP adres, které představují adresy dílčích sítí). V našem konkrétním případě to znamená, že hostitelský počítač A si ve svých směrovacích tabulkách bude pamatovat pouze to, že nejvýhodnější cesta do sítě Y vede přes bránu G2, a nikoli že k hostitelskému počítači C se dostane nejlépe přes bránu G2.

 

Směrování v TCP/IP sítích - II.

V minulém díle jsme se začali podrobněji zabývat problematikou směrování v TCP/IP sítích. Řekli jsme si, že na směrování se podílí jak brány, tak i hostitelské počítače, a blíže jsme se zabývali právě rolí hostitelských počítačů. Dnes se podrobněji zastavíme u toho, jakým způsobem se na směrování podílí brány (IP směrovače).

Vraťme se však ještě jednou k hostitelským počítačům: jejich úloha při směrování končí tím, že datagram buď pošlou přímo jeho koncovému adresátovi (v případě tzv. přímého směrování, viz minule, kdy se příjemce nachází v téže dílčí síti), nebo tím, že datagram předají některé z bran (v opačném případě). O postupu hostitelského počítače v prvním případě jsme si již povídali v souvislosti s problematikou adresování a transformování IP adres. Pro druhý případ musí mít hostitelský počítač právě tolik informací, aby dokázal zvolit jednu z bran ve své dílčí síti, a té datagram poslat. Tyto informace si hostitelský počítač uchovává ve svých směrovacích tabulkách.

Brána v roli učitele

V minulém dílu jsme si naznačili, že znát nejvhodnější cesty a tyto znalosti si průběžně aktualizovat je úkolem bran (IP směrovačů), a nikoli hostitelských počítačů. Ty mohou zpočátku posílat veškeré datagramy jedné jediné bráně ve své dílčí síti, a ta je vždy upozorní v případě, že by prostřednictvím jiné brány byla cesta datagramu výhodnější.

Ukažme si nyní, jaký efekt má tento mechanismus na směrovací tabulky hostitelských počítačů : po spuštění hostitelského počítače musí jeho směrovací tabulka obsahovat informace alespoň o jedné bráně. Tato brána (resp. jedna z bran, je-li ve směrovací tabulce uvedeno) je přitom prohlášena za implicitní (default), a hostitelský počítač jí z počátku posílá všechny datagramy, které směřují do jiné dílčí sítě. Jakmile tato implicitní brána zjistí, že by hostitelský počítač měl použít jinou výhodnější cestu (vedoucí přes jinou bránu), upozorní jej na to. Hostitelský počítač si na základě této explicitní informace upraví svou směrovací tabulku - zavede si v ní novou položku, a v ní si poznačí, že datagramy, směřující do příslušné dílčí sítě, má posílat přes tu a tu bránu. Kdykoli ale má odeslat datagram do dílčí sítě, pro kterou ještě nemá ve své směrovací tabulce uvedenu konkrétní cestu, pošle datagram té bráně, která je v jeho směrovací tabulce uvedena jako implicitní. Takováto organizace směrovacích tabulek velmi dobře odpovídá "stromovitým" konfiguracím , které jsou u lokálních sítí dosti časté, a při kterých samostatné cesty (vyjádřené ve směrovací tabulce explicitně) vedou jen k několika málo dalším dílčím sítím, zatímco ke "zbytku světa" vede cesta jediná (zpřístupněná implicitní bránou).

Činnost bran

Ponechme ještě stranou otázku, jakým způsobem získávají jednotlivé brány potřebné informace o cestách (k tomu se dostaneme příště), a podívejme se, jak brány postupují při vlastním směrování.

Pravidla pro směrování datagramů se u bran principiálně neliší od hostitelských počítačů. Zjistí-li brána, že přijatý datagram je určen adresátovi v dílčí síti, do které je brána připojena (a takové musí být alespoň dvě, má-li jít vůbec o bránu), pošle mu datagram přímo - v rámci přímého směrování . Je-li datagram určen adresátovi v jiné dílčí síti, do které není brána přímo připojena, musí zvolit jinou vhodnou bránu, a té datagram předat. Postupuje přitom obdobně jako hostitelský počítač: pokud ve své směrovací tabulce najde explicitní údaj o tom, že pro danou cílovou síť má datagram předat té a té bráně, učiní tak. Pokud o dané cílové síti nemá ve své směrovací tabulce žádné údaje, použije tu bránu, kterou považuje za implicitní - pokud ovšem má ve své směrovací tabulce implicitní bránu vůbec definovánu. Pokud ne, není daná brána schopna směrování datagramu zajistit, a musí to oznámit jako chybu.

Obsah směrovacích tabulek

Vraťme se ještě jednou k obsahu směrovacích tabulek. Jak jsme si již několikrát naznačili, je z důvodu minimalizace jejich rozsahu veškeré směrování založeno jen na adrese cílové sítě, resp. na té části IP adresy, která tuto cílovou síť vyjadřuje. Směrovací tabulky jsou pak ve své podstatě vlastně seznamem dvojic , kde "síť" představuje cílovou dílčí síť, a "brána" je ta z bran, přes kterou do cílové sítě vede (nejvhodnější) cesta. Jde přitom o bránu, která ještě není konečným příjemcem datagramu, ale jen jeho další přestupní stanicí na cestě k cíli. V angličtině se označuje jako next hop, doslova: další skok.

Bránou pro "další skok" však musí vždy být brána, která je z daného místa dosažitelná přímo - tedy taková brána , která se nalézá ve stejné dílčí síti, jako daný hostitelský počítač, resp. v některé z dílčích sítí, do kterých je přímo připojena daná brána.

Adresy bran, které jsou obsaženy ve směrovacích tabulkách, jsou zásadně IP adresy, ačkoli by se na první pohled mohlo zdát výhodnější používat zde přímo fyzické adresy - čímž by se ušetřila opakované transformace IP adresy na fyzickou adresu brány (viz 44. díl seriálu). Důvodem pro použití IP adres je možnost využívat ve všech uzlech stejnou programovou realizaci směrovacího mechanismu, nezávisle na konkrétních fyzických adresách. Dalším, velmi důležitým důvodem, je možnost průběžné aktualizace směrovacích tabulek a také možnost případného ladění, dojde-li k chybě či jiným nestandardním situacím při směrování. V neposlední řadě použití IP adres ve směrovacích tabulkách vychází i z celkové koncepce síťové (IP) vrstvy a protokolu IP - usilucí o vytvoření jednotné abstrakce všech dílčích sítí.

Výjimka z pravidla

Nebylo by to snad ani žádné pravidlo, kdyby nemělo také své výjimky. V případě pravidla o směrování jen na základě adres dílčích sítí je touto výjimkou možnost zavést do směrovacích tabulek explicitně také údaje o cestách ke konkrétním hostitelským počítačům, nikoli jen do celých dílčích sítí. Ačkoli za běžného provozu by tato možnost měla být využívána spíše vyjímečně, je velmi užitečná pro správce sítí při ladění a správě sítě obecně. Zde může být k nezaplacení možnost přesměrovat tok služebních dat, směřujících k pracovní stanici správce tak, aby se vyhnul přetíženému či zcela neprůchodnému místu, které je zdrojem problémů.

 

Směrování v TCP/IP sítích - III.

V minulých dvou dílech jsme se zabývali konkrétním postupem hostitelských počítačů a bran (IP směrovačů) při směrování IP datagramů. Ukázali jsme si, jakým způsobem k tomu oba druhy uzlů TCP/IP sítí využívají své směrovací tabulky, a naznačili jsme si také, že udržování správného obsahu směrovacích tabulek hostitelských počítačů mají vlastně na starosti brány. Dnes se již dostaneme k tomu, jak si své směrovací tabulky vytváří a udržují samotné brány.

Přístup hostitelských počítačů je založen na myšlence, že dokáží úspěšně směrovat datagramy i v případě, kdy mají k dispozici jen částečnou znalost nejvhodnějších cest v celém konglomerátu vzájemně propojených sítí (internetu). Ty dílčí sítě, do kterých jsou ve směrovací tabulce explicitně definovány cesty, odpovídají té části internetu, kterou vlastník směrovací tabulky "zná". Zbývající část internet-u je pak pro majitele směrovací tabulky reprezentována implicitní (default) bránou, resp. implicitní cestou, která přes tuto bránu vede.

Hlavní výhodou směrování s využitím implicitních cest je značná redukce rozsahu směrovacích tabulek, a s tím související menší režie na jejich aktualizaci a udržování konzistentního stavu. Nevýhodou je pak potenciální neefektivita směrování - cesta, vedoucí přes implicitní bránu, samozřejmě nemusí být nejkratší.

Ani brány nemusí znát všechno

Podobně jako v případě hostitelských počítačů, nebylo by ani v případě bran únosné, aby každá z nich "znala" vždy celý internet - tedy aby její směrovací tabulka obsahovala explicitní údaj o optimální cestě do každé jednotlivé dílčí sítě. Také zde se totiž brzy ukázalo, že již pro nepříliš velké soustavy vzájemně propojených sítí vychází "úplné" směrovací tabulky značně rozsáhlé. Jejich rozsah by však ještě nebyl tak velkým problémem, jakým se náhle stává udržování vzájemné konzistence a průběžná aktualizace směrovacích tabulek jednotlivých bran. K tomu je totiž nutný pravidelný přenos velmi velkého objemu dat, který může brzy zcela zahltit dostupné přenosové cesty.

Proto se i v případě bran aplikovala stejná myšlenka, jako u hostitelských počítačů: vybavit většinu z nich jen částečnou znalostí nejkratších cest do všech možných cílových sítí, a využívat implicitní směrování. Konkrétní realizace se pak vyvíjela na základě toho, jak se TCP/IP protokoly prosazovaly do nově vznikajícího Internetu. Podívejme se proto, jak se situace vyvíjela zde.

Na počátku byl ARPANET

V době, kdy v USA započaly první experimenty se sítí Internet, její zárodečná síť (ARPANET) již existovala a byla v provozu. Vůči právě vznikajícímu Internetu se pak tato rozlehlá síť chovala jako páteřní síť (backbone), ke které byly postupně připojovány jednotlivé lokální sítě či celé skupiny lokálních sítí.

Pokud se jednalo jen o jednu lokální síť, byla tato napojena na páteřní síť prostřednictvím jediné brány. Pokud šlo o více lokálních sítí (například o skupinu lokálních sítí v rámci areálu univerzity apod.), byly tyto navzájem propojeny dalšími bránami, ale na páteřní síť byly jako celek připojeny opět jen v jednom bodě, resp. prostřednictvím jediné brány. Tato brána pak vůči ostatním vystupovala jako implicitní brána, přes kterou byl směrován veškerý provoz, určený "mimo" nově připojenou skupinu dílčích sítí.

Hlavní (core) a vedlejší (noncore) brány

Připojování celých soustav dílčích sítí na páteřní síť vždy jen přes jednu bránu dávalo vzniknout struktuře, ve které se s výhodou uplatnilo implicitní směrování, tedy směrování s využitím implicitní cesty. Všem bránám v určité skupině dílčích sítí stačilo k efektivnímu směrování znát optimální cesty jen v rámci dané skupiny sítí, a veškerý ostatní provoz směrovat přes implicitní bránu do páteřní sítě. Tyto brány tedy mohly pracovat jen s částečnou znalostí celého Internet-u, což značně redukovalo rozsah jejich směrovacích tabulek, a umožňovalo také určitou autonomii při zajišťování změn v "místním" směrování. Neefektivita, vznikající v důsledku implicitního směrování, se zde vzhledem ke skutečné topologii nemohla uplatnit.

Pro ty brány, které byly přímo připojeny na páteřní síť, však již stejná úvaha neplatila. V rámci páteřní sítě (která měla ve skutečnosti dosti složitou vnitřní strukturu) by při implicitním směrování již docházelo k výrazným neefektivitám. Tvůrci Internetu se proto rozhodli poskytnout všem bránám, připojeným přímo na páteřní síť, "úplnou" znalost celého Internetu, a umožnit jim tak využívat skutečně optimálních cest v rámci páteřní sítě. Každá z těchto tzv. hlavních bran (core gateways) tedy znala optimální cestu do všech dostupných cílových sítí v celém Internetu. Všechny hlavní brány si pak navzájem pravidelně předávaly nezbytné směrovací informace, pomocí kterých si aktualizovaly a vzájemně koordinovaly své směrovací tabulky. Tvořily tak ucelený systém, který mohl fungovat dostatečně spolehlivě díky tomu, že všechny hlavní brány spravovala jediná centrální instituce (Internet Network Operations Center).

Všechny ostatní brány, které nebyly přímo napojeny na páteřní síť (tzv. vedlejší brány, noncore gateways), pak již spadaly plně do kompetence provozovatelů jednotlivých dílčích sítí či skupin dílčích sítí. Tito provozovatelé však měli ještě jednu důležitou povinnost - systému hlavních bran museli vhodně zveřejnit IP adresy všech svých dílčích sítí. Díky vzájemnému předávání směrovacích informací se pak již hlavní brány dokázaly samy podělit o znalost těchto dílčích sítí, které se tak záhy staly dostupné z celého rozsáhlého Internetu.

Nic nevydrží věčně

Právě naznačené schéma se však záhy ukázalo být nepraktické, a to hned z několika důvodů. Jedním z nich byl neočekávaně velký růst Internetu. Jeho původní struktura, soustředěná kolem jediné páteřní sítě, se záhy stala značně složitou, a stejně tak se značně netriviálními staly i mechanismy udržování směrovacích tabulek hlavních bran ve vzájemně konzistentním stavu. Také režie těchto mechanismů se při stále rostoucím počtu hlavních bran neúměrně zvyšovala. Kromě toho vznikly problémy i se samotnými hlavními bránami - zdaleka ne všechny lokality měly možnost zřídit pro své potřeby hlavní bránu, a připojit ji přímo na páteřní síť.

Situace si poměrně brzy vynutila řadu změn, ale o nich si povíme až příště.

 

Směrování v TCP/IP sítích - IV.

V minulém dílu jsme dospěli k představě toho, že Internet vznikal a postupně se rozšiřoval připojováním jednotlivých dílčích sítí či celých skupin dílčích sítí přímo na zárodečnou páteřní síť. V rámci těchto skupin byly jednotlivé dílčí sítě propojeny tzv. vedlejšími bránami (noncore gateways), zatímco na páteřní síť byla celá skupina připojena jedinou, tzv. hlavní bránou (core gateway). Tato hlavní brána přitom pravidelně komunikovala se všemi ostatními hlavními bránami Internetu, a vyměňovala si s nimi potřebné směrovací informace. Díky tomu mohly všechny hlavní brány pracovat s úplnou znalostí celého Internetu, tj. znát nejkratší cestu do kterékoli dílčí sítě. Naproti tomu vedlejší (noncore) brány vystačily jen se znalostí svého bezprostředního okolí (resp. příslušné skupiny sítí, sdílejících stejnou hlavní bránu), a pro všechny ostatní cíle používaly implicitní směrování přes hlavní bránu.

Již minule jsme si ale také řekli, že vedlejší brány spadaly plně do kompetence provozovatelů příslušných skupin sítí, které tyto brány propojovaly (zatímco všechny hlavní brány spravovala jediná centrální autorita). Tito provozovatelé pak měli za úkol vhodně zveřejnit informace o dostupnosti svých dílčích sítí systému hlavních bran, který se o ně již dokázal sám podělit. Otázkou ovšem bylo, jak toto zveřejnění zajistit.

Pokud byla přes hlavní bránu připojena k páteřní síti jen jediná dílčí síť, byla situace triviální. Častěji ale byly k páteřní síti připojovány větší celky - celé skupiny dílčích sítí, vzájemně propojených vedlejšími bránami. Zde již byl zapotřebí vhodný mechanismus, který by kromě vlastního jednorázového zveřejnění umožnil také nezbytnou průběžnou aktualizaci směrovacích informací ve vztahu k hlavním bránám.

Problémem však nebyla ani tak technická stránka věci, jako spíše stránka organizační: která z vedlejších bran má předávat potřebné směrovací informace soustavě hlavních bran?

Kromě toho zde byl ještě jeden důležitý aspekt. Nově připojované skupiny vzájemně propojených sítí byly často samy o sobě rozsáhlé konglomeráty, které dříve fungovaly jako samostatné internet-y (s malým "i"), a měly tedy již vybudovány a implementovány vlastní mechanismy a prostředky řízení a správy. Jejich provozovatelé si samozřejmě chtěli i nadále udržet kontrolu nad svými sítěmi, ale současně s tím získat také všechny výhody, plynoucí z přímého napojení na Internet.

Řešením pak bylo přijetí koncepce tzv. autonomních systémů (autonomous systems). Jejich myšlenka je velmi jednouchá: vzájemně propojené sítě, které spadají pod společnou správu, budou tvořit jediný autonomní systém, za který bude plně odpovídat jeho provozovatel. Současně s tím však bude existovat jednotný způsob vzájemného předávání směrovacích informací mezi jednotlivými autonomními systémy, který budou všichni povinni dodržovat. Jinými slovy: v rámci svého vlastního systému má každý možnost zajistit si přenos a aktualizaci směrovacích údajů podle svého, ale navenek musí všichni postupovat jednotně.

Aby toto řešení bylo důsledné, stala se autonomním systémem také původní páteřní síť, resp. celá soustava hlavních bran. Tím se celá struktura Internetu logicky zjednodušila na jediný strom, jehož kořenem je právě autonomní systém, tvořený soustavou hlavních bran

Pro vzájemnou komunikaci mezi autonomními systémy pak byl navržen potřebný protokol EGP (Exterior Gateway Protocol). Ten vychází z představy, že v rámci každého autonomního systému je 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 (exterior gateway). 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í údajů a informací o průběžných změnách.

Protokol EGP je tedy prostředkem, pomocí kterého může autonomní systém informovat jiné autonomní systémy o dostupnosti dílčích sítí v rámci vlastního autonomního systému, a naopak získávat informace o cestách do dílčích sítí v jiných autonomních systémech. V Internetu ale vzhledem k jeho konkrétní stromovité topologii stačí, když jednotlivé autonomní systémy předávají potřebné směrovací informace soustavě hlavních bran (která je sama o sobě autonomním systémem).

Každý autonomní systém však smí zveřejňovat údaje o dostupnosti pouze pro ty dílčí sítě, které spadají pod jeho správu, tedy jen pro dílčí sítě v rámci vlastního autonomního systému. Nesmí fungovat jako prostředník, který by sám zveřejňoval údaje, získané od jiného autonomního systému.

Jednou ze zajímavých vlastností protokolu EGP je skutečnost, že sice přenáší údaje o "délkách" cest do jednotlivých dílčích sítí, ale pak je již nepoužívá. V důsledku toho vlastně pracuje jen informaci o tom, zda cesta do příslušné dílčí sítě existuje či nikoli. To má zajímavý důsledek: kdyby do některé dílčí sítě existovalo více možných cest, příslušné brány by neměly podle čeho mezi nimi vybírat. Proto jsou při vzájemném propojování autonomních systémů zakázány takové topologie, které by připouštěly více možných cest do stejných cílových sítí. Protokol EGP tedy počítá pouze se stromovitou strukturu, což ale v případě Internetu plně postačuje.

Pokud jde o přenos směrovacích informací v rámci jednotlivých autonomních systémů, zde mají jejich provozovatelé možnost vlastního výběru. Mezi možnosti, které se jim nabízí, patří také samotný protokol EGP, který lze používat i "uvnitř" autonomních systémů (povinný je pouze "vně", mezi autonomními systémy). Další, dosti rozšířenou možností je protokol RIP (Routing Information Protocol), prostřednictvím kterého si jednotlivé vnitřní brány autonomního systému předávají údaje o tom, do kterých cílových sítí vede z které brány cesta a jak je dlouhá (měřeno v počtu mezilehlých sítí). Každá z bran si pak na základě těchto údajů sama dopočítá nejkratší cesty do všech dostupných dílčích sítí způsobem, který jsme si naznačili již v 33. dílu našeho seriálu. Na podobném principu je založen alternativní protokol Hello, který však měří délky jednotlivých cest nikoli v počtu mezilehlých sítí, ale v délce zpoždění při přenosu po této cestě. Společnou nevýhodou těchto algoritmů, které pracují s délkou cest (a jsou proto označovány jako vector-distance algorithms) je jejich velká režie, která navíc při zvětšování počtu bran velmi rychle roste. Z tohoto pohledu jsou pak výhodnější algoritmy, označované společně jako link-state či SPF (Shortest Path First) algoritmy. Ty předpokládají, že každá brána zná topologii celého konglomerátu vzájemně propojených sítí, a pravidelně testuje průchodnost přenosových cest ke svým bezprostředním sousedům. Dvouhodnotové informace o této dostupnosti pak rozesílá všem ostatním bránám, které si na jejich základě, podle tzv. Dijkstrova algoritmu, samy vyhodnocují nejkratší cesty do všech dílčích sítí. Ve srovnání s předchozí skupinou vykazují tyto algoritmy výrazně nižší režii, která při zvětšování počtu bran navíc neroste tak rychle.

Zajímavý je z tohoto pohledu také způsob, jakým si potřebné směrovací informace vyměňovala soustava hlavních bran, nyní tvořící jeden autonomní systém. Původně tyto hlavní brány používaly protokol GGP (Gateway-to-Gateway Protocol), který patří do stejné skupiny, jako protokoly RIP a Hello, tedy mezi protokoly, přenášející údaje o délce jednotlivých cest (v případě protokolu GGP měřené v počtu "přestupních" bran). Vzhledem k velké režii (viz závěr minulého dílu) však byl tento protokol nahrazen protokolem SPREAD (patřící mezi protokoly SPF), na který soustava hlavních bran přešla v roce 1988. Všechny protokoly, používané pro přenos směrovacích informací mezi jednotlivými bránami "uvnitř" autonomních systémů, se souhrnně označují jako protokoly IGP (Interior Gateway Protocol).

 

Směrování v TCP/IP sítích - V.

V minulých dílech našeho seriálu jsme se podrobněji zabývali otázkou směrování v TCP/IP sítích. Konkrétní mechanismy, které jsme si v této souvislosti popisovali, však vycházely z určité strategie pro přidělování IP adres, kterou jsme si ukázali již ve 43. dílu. Tato strategie se ale s vývojem Internetu také postupně vyvíjela, a tak muselo nutně dojít k určitým modifikacím i ve způsobu směrování.

O změně strategie při přidělování IP adres jsme se již zmínili ve 43. dílu, kde jsme si o IP adresách povídali podrobněji. Připomeňme si proto, v čem tyto změny spočívají, a hlavně čím jsou motivovány.

Původní záměr byl takový, aby každá dílčí síť měla vlastní samostatnou síťovou adresu. Aby to bylo možné v prostředí, kde se dílčí sítě mohou velmi výrazně lišit co do počtu svých koncových uzlů (hostitelských počítačů, hosts), zavedly se tři různé formáty IP adres - adresy třídy A, B a C (viz 44. díl). Adresy třídy A byly určeny pro sítě s velmi velkým počtem hostitelských počítačů, adresy třídy B pro "středně" velké sítě, a adresy třídy C pro sítě s maximálně 254 hostitelskými počítači. Dlužno ovšem podotknout, že tato strategie vznikla ještě v době, kdy světu vládly velké střediskové počítače a minipočítače, zatímco éra osobních počítačů a malých lokálních sítí měla nastat přibližně o deset let později.

Takový růst nečekali

Tvůrci síťového modelu TCP/IP jistě předpokládali nárůst v nasazení výpočetní techniky, ale s čím již počítali méně je skutečnost, že tento nárůst bude tak prudký, a že se bude ubírat cestou "malých" počítačů a velkého množství relativně malých lokálních sítí. Zatímco zásoba IP adres třídy C ještě zdaleka vyčerpána není, úzkým místem se ukázala být jednak agenda, spojená s přidělováním IP adres, a především rozsah směrovacích tabulek, s nímž pak souvisí i vysoká režie na udržování jejich průběžné konzistence.

Jak jsme si již několikrát ukázali, snaží se TCP/IP protokoly minimalizovat rozsah směrovacích tabulek a režii na jejich aktualizaci dvěma způsoby: směrováním jen na základě adresy dílčí sítě, a používáním implicitního směrování (resp. implicitních cest) v tzv. vedlejších bránách (noncore gateways). Ani to však nestačí, a tak se ukázalo jako nezbytné usilovat o redukci počtu různých IP adres celých sítí. Jinými slovy: usilovat o tom, aby více dílčích sítí mělo přidělenu a sdílelo stejnou síťovou adresu (přesněji: tu část IP adresy, která představuje adresu sítě), a ve směrovacích tabulkách tak zabíralo jen jednu položku. Přišlo se samozřejmě na více možností, jak toho dosáhnout - tou nejefektivnější se ukázala být technika tzv. podsítí (subnets), kterou jsme si naznačili již ve 44. dílu našeho seriálu, a která je dnes již povinnou součástí TCP/IP protokolů. Zopakujme si proto její základní myšlenku.

Podsítě a jejich adresy

Určitá skupina dílčích sítí, které by bez použití techniky podsítí měly samostatné adresy, má naopak jednu společnou adresu, a vůči svému okolí vystupuje jako jediný celek, tj. jako jediná dílčí síť.

V rámci příslušné skupiny sítí je ale jejich společná IP adresa dále členěna - přesněji ta její část, která navenek představuje číslo (adresu) hostitelského počítače, se nyní rozpadá na dvě části - číslo (adresu) dílčí sítě, resp. tzv. podsítě (subnet) v rámci skupiny, a na číslo (adresu) hostitelského počítače v rámci této podsítě. O tom, jak konkrétně má být IP adresa takto členěna, rozhoduje tzv. maska podsítě (subnet mask).

Podstatná je přitom skutečnost, že tato maska nemá žádný povinný tvar. Volí se samostatně pro každou jednotlivou podsíť, což pak ale znamená, že i v rámci jedné skupiny podsítí mohou být používány různé masky. Příslušný standard to sice umožňuje, ale nedoporučuje, neboť tak mohou snadno vznikat nejednoznačnosti v IP adresách. Obvykle se tedy setkáme spíše s tím, že v rámci jedné skupiny podsítí je používána stejná maska.

Směrování v případě podsítí

Jakmile je ale používána technika podsítí, je nutné poněkud upravit konkrétní algoritmus směrování, který jsme si popsali v 46. dílu našeho seriálu. Doposud jsme totiž předpokládali, že ve směrovacích tabulkách jsou dvojice "cílová síť, brána", popisující jednotlivé dílčí sítě, a že algoritmus směrování v nich hledá na základě adresy cílové sítě v příslušném datagramu. Nyní je ale zapotřebí, aby ve směrovacích tabulkách byly trojice: "maska podsítě, cílová síť, brána", popisující i jednotlivé podsítě, a modifikovaný algoritmus směrování musí v takovýchto tabulkách hledat opět podle adresy cílové sítě, s tentokrát navíc s uvážením konkrétní masky podsítě pro každou jednotlivou položku zvlášť.

Tento modifikovaný algoritmus má jednu výhodu - dokáže zobecnit i obě singularity, které se vyskytují u původního algoritmu (viz opět 46. díl), a to směrování na základě adres jednotlivých hostitelských počítačů, a použití implicitních cest. V prvním případě stačí volit takovou masku, díky které bude jako adresa sítě interpretována celá IP adresa příslušného hostitelského počítače (zatímco část, představující číslo hostitelského počítače, bude prázdná). V případě implicitních cest pak stačí použít opačný extrém - masku, která zcela "zamaskuje" adresu sítě.

Otázkou ovšem je, kdo má takto modifikovaný algoritmus směrování používat. Kdyby jej totiž musely používat všechny brány, zcela by se tím negoval výsledný efekt použití techniky podsítí, spočívající v další redukci směrovacích tabulek. Modifikovaný algoritmus směrování musí v každém případě používat všechny brány a hostitelské počítače v jednotlivých podsítích. Pokud jde o ostatní brány a hostitelské počítače, zde platí jednoduché teoretické pravidlo: modifikovaný algoritmus směrování je třeba použít tam, odkud mohou vést různé optimální cesty do různých podsítí se stejnou síťovou adresou.

Toto pravidlo lze jednoduše aplikovat v případě, že do celé skupiny podsítí se stejnou adresou vede jen jediný vstupní bod. V ostatních případech je situace mnohem komplikovanější.

Proxy ARP

Jak jsme si již naznačili výše, technika podsítí (subnetting) není jediným způsobem, jak může více dílčích sítí sdílet tutéž adresu. Další možností je mechanismus, označovaný jako proxy ARP či promiscuous ARP, nebo také ARP hack. Ten je ovšem použitelný jen tam, kde je využíván protokol ARP pro transformaci IP adres na adresy fyzické (tj. například v lokálních sítích typu Ethernet, viz 44. díl seriálu). Myšlenka proxy ARP je založená na jednoduchém triku: brána G se snaží předstírat síti A, že je tím hostitelským počítačem (v síti B), se kterým chce právě komunikovat některý z uzlů sítě A. Dělá to tak, že kdykoli je pomocí protokolu ARP vyslán v síti A dotaz na fyzickou adresu některého hostitelského počítače v síti B, brána G na tento dotaz odpoví, a vrátí svou fyzickou adresu. Všechny datagramy, určené příslušnému počítači, jsou pak posílány na tuto fyzickou adresu, tedy ve skutečnosti bráně G, které je pak prostřednictvím sítě B dále předává jejich konečnému adresátovi. Výsledný efekt je tedy takový, jako kdyby síť B splývala se sítí A, a měla s ní tudíž stejnou síťovou adresu.

Problém je ovšem v omezené použitelnosti (jen tam, kde je používán protokol ARP), a dále také v tom, že některé implementace protokolu ARP se snaží detekovat a hlásit správci sítě tzv. spoofing, jak se označuje situace, kdy jedno zařízení předstírá, že je jiným zařízením (například proto, aby mohlo neoprávněně "odposlouchávat" přenášená data).

 

Jména v TCP/IP sítích - I.

V minulých dílech našeho seriálu jsme si ukázali, že v sítích na bázi protokolů TCP/IP (a samozřejmě také v Internetu) se používají jednotné IP adresy číselného charakteru, a že také veškeré směrování je založeno právě na těchto adresách. Jakkoli jsou ale tyto číselné adresy vhodné pro příslušný síťový software, pro uživatele příliš výstižné nejsou. Lidé raději pracují se snáze zapamatovatelnými symbolickými jmény, například "aviion.mff.cuni.cs", než s málo mnemonickými číselnými adresami typu 129.1.2.3. Jak je to ale s možností používat takováto symbolická jména v TCP/IP sítích?

Zamysleme se nejprve znovu nad tím, co je vlastně IP adresa. Ve 44. dílu jsme dospěli k tomu, že IP adresa je dvousložková, a že její dvě složky reprezentují jednak adresu dílčí sítě, jednak adresu hostitelského počítače (resp. brány) v této dílčí síti. Hostitelské počítače však mohou být přímo připojeny i do dvou či více dílčích sítí (pak jsou v angličtině označovány jako multihomed hosts), a brány dokonce musí být takto připojeny nejméně do dvou sítí, mají-li vůbec fungovat jako brány. Pak ovšem mají také dvě či více různých IP adres. Domyslíme-li tuto skutečnost do důsledku, je přesnější chápat IP adresu nikoli jako adresu počítače resp. brány jako takové, ale jako rozhraní mezi sítí a hostitelským počítačem resp. bránou. Navíc, dojde-li k přemístění počítače či brány, jejich IP adresy se změní.

Jména vs. IP adresy

Symbolická jména bran a hostitelských počítačů, která skutečně lze v TCP/IP sítích používat, však nejsou přesným symbolickým ekvivalentem číselných IP adres. Jména se vztahují k počítačům resp. bránám jako takovým, a nikoli k jejich rozhraním. Jeden hostitelský počítač tedy může mít jediné jméno, ale současně více IP adres (je ovšem také možné, aby měl jmen několik). Dojde-li k přitom k přemístění počítače, jeho jméno (či jména) se měnit nemusí (zatímco jeho IP adresa resp. adresy ano).

Otázkou ovšem je, jaký tvar by měla symbolická jména mít, kdo je oprávněn je přidělovat, a jak z těchto jmen získávat jim odpovídající IP adresy, které jsou potřeba pro vlastní komunikaci.

Flat namespace

Je-li třeba přidělit symbolická jména relativně malému počtu hostitelských počítačů a bran, je vše jednoduché - stačí vymyslet dostatečný počet navzájem různých jmen, a ty jednotlivým počítačům a bránám přidělit. Na syntaktický tvar těchto jmen přitom není třeba klást nějaké zvláštní požadavky - samozřejmě kromě jejich jednoznačnosti - a není ani nutné tato jména jakkoli strukturovat či členit na části. Všechna takováto symbolická jména jsou pak považována za dále nedělitelná (v angličtině se říká, že tvoří "flat namespace", doslova: plochý prostor jmen). Udržet takovýto systém dále nedělitelných jmen v konzistentním stavu však vyžaduje existenci centrální autority, která bude dbát na přípustnost nově přidělovaných jmen - hlavně podle toho, jestli nekolidují s některým již přiděleným jménem. Se zvyšováním počtu přidělovaných symbolických jmen však začne narůstat administrativní i technická zátěž této centrální instituce, a problematické se stává i hledání nových, dosud nepoužitých symbolických jmen. V takových kolosech, jako je Internet, se právě naznačené řešení stalo velmi brzy neúnosné.

Hierarchická jména

Je ale vůbec možné obejít se bez centrální instituce, která by dbala na konzistentnost celého systému symbolických jmen? Odpověď je kladná, a spočívá v tom, že právo přidělovat nová jména bude decentralizováno, a s ním i související odpovědnost za jejich jednoznačnost.

Způsob této decentralizace byl inspirován velkými organizacemi, které jsou hierarchicky členěny na různé organizační složky, a ve kterých vyšší složky delegují některé pravomoci složkám nižším. Podobně jsou na více složek členěna i symbolická jména, a tyto jejich složky jsou hierarchicky uspořádány - od nejvyšší až po nejnižší. Za nejvyšší složku stále zodpovídá jediná centrální autorita, ale za složky nižší úrovně již mohou odpovídat jiné subjekty, kterým centrální autorita deleguje příslušnou pravomoc.

Ukažme si to na hypotetickém příkladu sítě, propojující vysoké školy v Praze, a na příkladu jmen o třech složkách, které vyjadřují vysokou školu jako takovou, fakultu v rámci této vysoké školy, a jméno příslušného počítače na této fakultě. Adresy tohoto typu by mohly vypadat například takto:

aviion.mff.cuni

(počítač se jménem aviion na Matematicko-fyzikální fakultě (mff) Univerzity Karlovy (cuni)), nebo:

vax.fel.cvut

(tj. počítač se jménem vax na Elektrotechnické fakultě pražského ČVUT).

Jednotlivé složky těchto hierarchických jmen jsou přitom zapisovány tak, že složka nejvyšší úrovně je nejvíce vpravo, a jednotlivé složky jsou oddělovány tečkami.

Pro tento námi zvolený příklad by stále ještě musela existovat centrální autorita, která by však odpovídala jen za jména, resp. složky nejvyšší úrovně, vyjadřující jména jednotlivých vysokých škol (tj. cvut, cuni atd.). Každá nová vysoká škola, která by se chtěla zapojit do tohoto systému jmen, by se musela obrátit na tuto centrální autoritu pro přidělení nového jména (resp. jeho nejvyšší složky). Centrální autorita pak přidělením každého nového jména nejvyšší úrovně vlastně vytváří samostatný prostor symbolických jmen, kterému se obvykle říká doména (v našem případě jde např. o domény cvut, cuni). Tím však odpovědnost centrální autority končí, neboť správu každé domény - tj. odpovědnost za přidělování dalších složek jmen - deleguje jednotlivým vysokým školám, které se stávají správci příslušných domén. Ti si pak sami volí jména (složky) druhé úrovně, v našem případě odpovídající jednotlivým fakultám (tj. například mff, fel). Tím vznikají další domény nižší úrovně (subdomény), které opět mají své správce - v našem případě jednotlivé fakulty - které si zase samy volí jména třetí úrovně. A jelikož jsme se v našem hypotetickém příkladu omezili jen na tři úrovně, jde již o jména konkrétních počítačů na příslušných fakultách. V praxi ovšem není počet úrovní (resp. složek) omezen.

Systém doménových jmen

Mechanismus, který v TCP/IP sítích implementuje právě naznačený systém hierarchických jmen, se jmenuje DNS (Domain Name System). Ten má dvě části - první z nich předepisuje syntaxi hierarchických jmen (označovaných nyní jako doménová jména), a pravidla pro delegování pravomocí a odpovědnosti za jejich přidělování. Druhá část pak určuje způsob implementace distribuovaného systému, který umožňuje efektivně převádět doménová jména na jim odpovídající IP adresy (o tom si budeme povídat příště).

Všechno podle Internetu

Standard DNS nepředepisuje žádný povinný tvar jednotlivých složek doménových jmen. Nepředepisuje ani, že členění na domény různých úrovní musí odpovídat organizačnímu členění - stejně tak dobře může toto členění vycházet například z územního členění.

 

Každý konglomerát vzájemně propojených sítí (internet) na bázi TCP/IP si tedy může volit způsob členění na jednotlivé domény i jejich jména zcela podle svého (viz náš hypotetický příklad). V praxi se ale téměř všechny takovéto konglomeráty přizpůsobují tomu, jak jsou doménová jména organizována v Internetu - mj. i z toho prostého důvodu, aby na něj mohly být co nejsnáze připojeny (pokud ještě nejsou).

Systém doménových jmen, používaný v "síti" Internet, má jeden pikantní rys - vznikl totiž v době, kdy jeho autoři vůbec neuvažovali o tom, že by se vůbec někdy rozšířil mimo území USA. Proto zavedli domény nejvyšší úrovně (tzv. top-level domains), které vyjadřují charakter příslušných organizací, ale jsou použitelné jen pro takové organizace, které sídlí v USA (a v části Kanady). Jakmile se ale Internet dostal i mimo Spojených států, musely se zavést ještě další domény nejvyšší úrovně, odpovídající jednotlivým státům. Jména těchto domén nejvyšší úrovně tvoří dvoupísmenové národní kódy (Country Code), které definuje standard ISO 3166, pro Československo pak: cs. Takže například

xinu.cs.purdue.edu

je počítač (xinu) na katedře computer science (cs) na Purdue University (purdue), která je vzdělávací institucí (edu), v USA. Naopak

aviion.mff.cuni.cs

je počítač (aviion) na Matematicko-fyzikální fakultě (mff) Univerzity Karlovy (cuni) v Československu (cs).

Náš hypotetický příklad tedy nebyl tak daleko od skutečnosti. Pouze jsme v něm neuvažovali, že celé Československo tvoří v rámci Internetu jednu doménu nejvyšší úrovně (doménu cs), jejímž správcem je pražská VŠCHT. U ní pak musí být registrovány všechny domény druhé úrovně.

 

Jména v TCP/IP sítích - II.

V minulém dílu jsme se zabývali otázkou symbolických jmen počítačů a bran v TCP/IP sítích a dospěli jsme k tomu, jakým způsobem se přidělují doménová jména v Internetu. Nyní se budeme věnovat otázce, jak na základě symbolických jmen získávat odpovídající IP adresy.

Připomeňme si ještě jednou, že otázku doménových jmen v TCP/IP sítích řeší standard DNS (Domain Name System), který má dvě základní části: první z nich určuje syntaxi doménových jmen a pravidla pro delegování pravomoci a odpovědnosti za jejich přidělování, zatímco druhá část se týká implementace mechanismu pro převod doménových jmen na jim odpovídající IP adresy.

Jestliže pravomoc a odpovědnost za přidělování doménových jmen je distribuována na jednotlivé domény a subdomény, je vcelku přirozené očekávat, že také mechanismus pro převod těchto doménových jmen na IP adresy bude obdobně distribuován - že bude tvořen soustavou vzájemně spolupracujících částí, nazývaných servery jmen (name servers), jejichž uspořádání bude odrážet hierarchickou strukturu domén a subdomén. Základní myšlenka takovéhoto řešení je založena na tom, že s každou doménou a subdoménou bude spojen prostředek (zmíněný server jmen), který všechna jména z příslušné domény či subdomény buď umí převést sám, nebo alespoň zná jiný server jmen, který to dokáže.

Představme si příklad, který ukazuje malou část adresového prostoru doménových jmen Internetu se třemi doménami nejvyšší úrovně - edu (pro vzdělávací instituce v USA), com (pro komerční instituce v USA), a cs (pro celé Československo), s některými jejich subdoménami. Dále si představme stejně strukturovaný systém serverů jmen pro jednotlivé domény a subdomény a předpokládejme, že některý hostitelský počítač potřebuje odeslat zprávu počítači s adresou aviion.mff.cuni.cs. Obrátí se proto nejprve na server jmen domény cs, který jej odkáže na server jmen domény cuni.cs, a ten pak zase na server jmen domény mff.cuni.cs. Ten již je schopen odpovědět na dotaz, jaká je IP adresa počítače aviion.mff.cuni.cs.

Jak je tomu ve skutečnosti

Právě naznačený příklad je samozřejmě dosti zjednodušený, ale jinak dobře vystihuje celkovou filosofii převodu symbolických doménových jmen na IP adresy.

Prvním praktický problém vyvstává hned v okamžiku, kdy je třeba se obrátit na server jmen domény nejvyšší úrovně - každý potenciální tazatel by totiž musel znát adresy serverů jmen všech domén nejvyšší úrovně. Proto se všem těmto serverům nejvyšší úrovně nadřazuje ještě jeden, tzv. kořenový server (root server), a pouze tento kořenový server musí být znám všem potenciálním žadatelům o převod doménových adres. V praxi je tento kořenový server několikanásobně zálohován.

Další odlišností skutečné realizace od naší ideální představy je hloubka výsledného stromu serverů jmen, v jehož kořeni je právě zmíněný kořenový server. Jednotlivé servery jmen totiž mohou obsahovat potřebné informace o doménových jménech pro více různých domén a subdomén - velice často totiž různé organizace soustřeďují informace o jménech ze všech svých subdomén v jediném serveru jmen. Kořenový server naopak obsahuje informace i o všech doménách nejvyšších úrovních, takže výsledný strom serverů jmen bývá v praxi mnohem "mělčí" .

Rekurzivní a iterativní převod

Iniciátorem převodu doménového jména na IP adresu (anglicky: name resolution) je vždy programová entita hostitelského počítače (tzv. name resolver), která vůči celé soustavě serverů jmen vystupuje jako klient. Se svým požadavkem na převod doménového jména se tato entita obrací na některý ze serverů, který může postupovat dvojím způsobem: pokud není schopen převod zajistit, sám se obrátí na jiný server jmen, který převod zajistí, výsledek vrátí prvním serveru, a ten jej pak vrátí původnímu žadateli. Pak jde o tzv. rekurzivní převod (recursive resolution). Alternativou je tzv. iterativní převod (iterative resolution), při kterém dotázaný server jmen buď provede převod sám, nebo pouze vrátí adresu jiného serveru jmen, na který se pak musí žadatel o převod znovu obrátit sám.

Zajímavou otázkou je to, kam se má žadatel o převod obrátit nejprve - zda má začít shora, a obrátit se na kořenový server, nebo má naopak postupovat naopak odspodu, a obrátit se nejprve na "místní" server jmen? Ve prospěch druhé možnosti hovoří hned několik skutečností: kdyby se všichni obraceli přímo na kořenový server, tento by byl brzy zahlcen. Navíc požadavky na převod doménových jmen se nejčastěji týkají právě "místních" jmen, které dokáže převést místní server. Ten je kromě toho schopen fungovat i v případě eventuálního výpadku vyšších vrstev celého stromu name serverů (i když to je vzhledem k jejich zálohování nepříliš pravděpodobné).

Použití vyrovnávacích pamětí (caching)

Kdyby se každý hostitelský počítač musel obracet na soustavu serverů jmen pokaždé, kdy potřebuje převést některé doménové jméno na jemu odpovídající IP adresu, byla by to pro celou síť neúnosně velká zátěž. Pro zefektivnění celého mechanismu převodu se proto počítá s tím, že hostitelské počítače si po určitou dobu pamatují výsledky dříve uskutečněných převodů. Každý hostitelský počítač si proto bude udržovat ve vhodné vyrovnávací paměti (paměti cache) databázi symbolických jmen a jim odpovídajících IP adres. Aby tuto svou databázi udržel v konzistentním stavu, odpovídajícím skutečnosti, bude každá položka této databáze "zastarávat" - po určité době ztratí svou platnost, a příslušný převod bude muset být v okamžiku potřeby vyvolán znovu.

Podobně postupují i servery jmen. Kromě doménových jmen, které jsou schopny (přesněji: oprávněny) převádět samy, se při rekurzivních převodech dozvídají i odpovídající IP adresy k jiným doménovým jménům. Také ty si udržují ve své vyrovnávací paměti, a v případě žádosti o převod je mohou poskytnout - ovšem s poznámkou, že nejsou k jejich převodu kompetentní (tj. že jde o tzv. neautoritativní (nonauthoritative) převod). Současně s tím poskytnou žadateli o převod i odkaz na ten server jmen, který je k převodu kompetentní. Iniciátor převodu pak naloží s touto informací podle vlastního uvážení. Jde-li mu o rychlost, použije tento neautoritativní převod, jde-li mu naopak o spolehlivost, obrátí se na příslušný server jmen, který je pro daný převod kompetentní.

Ještě většího zefektivnění celého mechanismu převodu doménových jmen na IP adresy lze pak dosáhnout tím, že jednotlivé hostitelské počítače si v okamžiku svého spuštění vyžádají od místního serveru jmen celou jeho databázi doménových jmen a jim odpovídajících IP adres. Z té pak vychází, a na server jmen se obrací jen při její aktualizaci (po "zastarání" některé položky) či pro její doplnění o nové doménové jméno, jehož odpovídající IP adresa ještě v databázi není.