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.
Warning: include(../includes/potenza/stridavytext_inner.php3): failed to open stream: No such file or directory in /www/doc/www.earchiv.cz/www/a92/a239c110.php3 on line 27
Warning: include(../includes/potenza/stridavytext_inner.php3): failed to open stream: No such file or directory in /www/doc/www.earchiv.cz/www/a92/a239c110.php3 on line 27
Warning: include(): Failed opening '../includes/potenza/stridavytext_inner.php3' for inclusion (include_path='.:/usr/share/php') in /www/doc/www.earchiv.cz/www/a92/a239c110.php3 on line 27
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
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 (viz obrázek 48.2). 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.
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ě.