Technologie internetu (6.): Směrování datagramů

Co se děje v pozadí pohodlné internetové komunikace? Jaké neviditelné procesy stojí za síťovým přenosem dat ?V minulém dílu seriálu jsme se věnovali čtyřvrstvé architektuře TCP/IP. Jejím příjemným důsledkem je abstrakce, která pro koncového uživatele vytváří iluzi přímé komunikace se vzdáleným partnerem či serverem.



Co se děje v pozadí pohodlné internetové komunikace? Jaké neviditelné procesy stojí za síťovým přenosem dat ?V minulém dílu seriálu jsme se věnovali čtyřvrstvé architektuře TCP/IP. Jejím příjemným důsledkem je abstrakce, která pro koncového uživatele vytváří iluzi přímé komunikace se vzdáleným partnerem či serverem.

Uživatel prostě zadá do svého prohlížeče odkaz na stránku, kterou si chce přečíst, a příslušný webový server mu ji bez řečí pošle. Práce spodních vrstev, tedy třeba to, že stránka přišla v několika paketech, jimiž se po cestě zabývalo dvacet směrovačů, nemusí uživatele vůbec zajímat. My se teď ale podíváme právě na to, co probíhá za scénou.

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

Základní úloha, s níž si musí poradit všechny systémy, které se na komunikaci podílejí, se nazývá směrování (routing). Kostra směrovacího algoritmu, jaká se aplikuje na každý odesílaný datagram, je následující:
1. Pokud je cílový hostitel, který je konečným příjemcem datagramu, připojen na lokálním síťovém segmentu, použije se přímé směrování – datagram se předá vrstvě síťového rozhraní, která zajistí jeho doručení.
2. Jinak se použije nepřímé směrování: vybere se vhodný směrovač připojený k lokálnímu segmentu a datagram se mu pošle prostřednictvím vrstvy síťového rozhraní. Spolu s datagramem se tomuto směrovači předá i problém, jak s ním dále naložit.

Výstupem směrovacího algoritmu je tedy takzvaný následník (next hop), který bude další zastávkou na cestě datagramu internetem. Zapamatujme si, že následník musí být vždy ve stejném síťovém segmentu jako systém, který realizuje směrovací algoritmus, aby mu bylo možné datagram fyzicky předat (například prostřednictvím Ethernetu).

Maska podsítě

Pozornému čtenáři jistě neuniklo, že v předchozím popisu jsme odbyli některé podstatné detaily. Především: jak směrující systém pozná, že je na stejném segmentu s cílovým hostitelem? K tomuto účelu se používá maska podsítě, která musí být spolu s IP adresou konfigurována na každém síťovém rozhraní. Maska udává počet bitů z levého konce IP adresy, které jsou stejné pro všechna rozhraní, připojená k danému síťovému segmentu. Pokud se tedy tato část vlastní adresy shoduje se stejnou částí adresy cílového hostitele, je možné použít přímé směrování. Maska podsítě se tradičně (a celkem zbytečně) zapisuje poněkud komplikovaným a uživatelsky málo přívětivým způsobem jako speciální IP adresa, jejíž levou část odpovídající délce masky tvoří samé jedničky a zbytek samé nuly. Například maska se šestnácti bity se zapisuje jako 255.255.0.0. V IPv6 byla tato praxe zcela opuštěna a pracuje se výhradně s celočíselnou délkou masky.

Spolupráce s vrstvou síťového rozhraní

Problém číslo dvě: máme-li prostřednictvím vrstvy síťového rozhraní předat datagram následníkovi – ať je jím směrovač nebo cílový hostitel – musíme jej umět na společném segmentu lokalizovat a data mu fyzicky doručit. Je-li následník připojen dvoubodovým spojem, nalezneme jej prostě na opačném konci kabelu. Jiné je to ale v případě linkových technologií s vícenásobným přístupem. Kupříkladu Ethernet používá šestibajtovou adresu rozhraní (takzvanou MAC adresu), která nijak nesouvisí s IP adresou. Pro převod IP adres na MAC adresy proto každý systém používá tabulku sousedů (neighbour cache). Tu je možné sestavit ručně, daleko častěji se ale vyplňuje dynamicky s využitím protokolů, které jsou pro tento účel k dispozici.

Směrovací tabulka

Zbývá nám otázka třetí: dojde-li na nepřímé směrování, jak určíme, který směrovač na lokálním segmentu je tím správným následníkem? Pokud segment obsahuje jediný směrovač, což je naštěstí případ většiny koncových sítí, není co řešit. Je-li jich tam však více, musíme internetovou vrstvu instruovat, jakým způsobem má naložit s libovolným paketem. V naprosté většině případů je jediným kritériem pro směrování cílová IP adresa. Jiná doplňující kritéria, jako třeba zdrojová adresa nebo typ služby, se používají jen velmi okrajově.

Směrování na základě cílové adresy se implementuje pomocí směrovací tabulky (routing table). V každém řádku této tabulky je zapsán jeden směrovací prefix spolu s instrukcí, co udělat s datagramem, jehož cílová adresa tomuto prefixu odpovídá, tj. že se shoduje se směrovacím prefixem ve všech bitech zleva až do délky prefixu.
● U prefixů lokálně připojených sítí je zapsáno síťové rozhraní, přes nějž se má datagram přímo doručit cílovému hostiteli.
● U prefixů nelokálních sítí pak najdeme IP adresu následníka, jemuž se má datagram předat.
Pokud cílová IP adresa odpovídá několika směrovacím prefixům v tabulce, použije se ten řádek směrovací tabulky, který má nejdelší prefix a je tudíž nejspecifičtější. Ve směrovací tabulce často najdeme tzv. implicitní směrovací cestu (default route), jejíž prefix je 0.0.0.0/0 pro IPv4, resp. ::/0 pro IPv6. Takovému prefixu ovšem odpovídá libovolná IP adresa, takže implicitní cesta je záchytným bodem pro případ, že se žádný specifičtější řádek ve směrovací tabulce nenajde. Většina hostitelů v internetu vystačí s dvouřádkovou směrovací tabulkou. První řádek popisuje přímé směrování do lokální sítě, druhý pak implicitní cestu, která se použije pro všechny nelokální cíle.

Nejzajímavějším a zároveň také nejsložitějším problémem je, zejména u směrovačů, způsob plnění směrovací tabulky. Tuto otázku si však necháme na příště.

Příklad standardního směrování datagramu v internetu, kdy spolu zdrojový hostitel A a cílový hostitel B s veřejnými IP adresami komunikují přes několik směrovačů:

Předpokládejme, že hostitel A potřebuje odeslat datagram hostiteli B. Ten s ním není na stejném ethernetovém segmentu, takže přichází ke slovu nepřímé směrování, kde je následníkem směrovač R1. Hostitel A opatří datagram ethernetovou hlavičkou, v níž bude jeho vlastní MAC adresa jako zdrojová a MAC adresa směrovače R1 (přesněji MAC adresa jeho rozhraní, které je připojeno do segmentu, v němž je i hostitel A). Směrovač R1 paket přijme, odstraní ethernetovou hlavičku a spustí vlastní – na hostiteli A nezávislý – směrovací algoritmus. Cílový hostitel B stále s R1 nesdílí společný segment, takže se znovu směruje nepřímo. Paket se předá směrovači R2 a stejným způsobem dále až k směrovači Rn. Ten je s cílovým hostitelem připojen ke stejnému ethernetovému segmentu, a proto zde již přijde ke slovu přímé směrování. Paket se zabalí do ethernetového rámce, v němž bude příslušná MAC adresa směrovače Rn zapsána jako zdrojová a MAC adresa hostitele B jako cílová. Tím je paket doručen.

Každý „hop“ kompletně přepisuje hlavičku vrstvy síťového rozhraní, zbytek se však mění jen minimálně. Speciální, zdrojová a cílová IP adresa v hlavičce datagramu zůstávají stále stejné (to by ovšem neplatilo, pokud by směrovač R1 zároveň působil jako brána NAT). Jediný údaj v hlavičce IP, který každý následník modifikuje, je TTL (Time To Live), v IPv6 označovaný jako počet hopů (hop count). Zdrojová stanice – v našem případě A – jej inicializuje určitou nenulovou hodnotou, například 64. Každý následník na trase je pak povinen tuto hodnotu o jedničku snížit. Pokud by klesla až na nulu, je následník povinen paket zahodit. Tento mechanismus je jednou z obran proti směrovacím smyčkám, v nichž by pakety mohly jinak obíhat donekonečna. Hlavičku transportní vrstvy, jakož i aplikační data, směrovače vůbec nečtou ani nemění.










Komentáře