Vrstvy ISO/OSI a teorie síťování

Jak funguje routing v Internetu jsme už vlastně naznačili v předchozí kapitole. Pro jistotu si ale ještě projdeme následující příklad:

Dejme tomu, že uživatel vlevo dole chce poslat HTTP request na adresu 10.1.5.10. Že takovému HTTP requestu předchází zpravidla DNS dotaz a odpověď teď zatím zanedbáme. HTTP je protokol sedmé vrstvy a přenáší se přes TCP. TCP musí sestavit spojení, tedy poslat trojici TCP segmentů (dva z klienta na server a jeden ze serveru na klienta), kterou udělá „handshake“. TCP se přenáší v IP, v našem příkladě v IPv4 (i když v IPv6 by to bylo skoro totožné). Rozebereme si, jak tedy protokol IP doručí první dva TCP segmenty - jeden od klienta na server a druhý v opačném směru. První datagram bude:

1. Klient musí vybrat záznam ve směrovací tabulce, který použije k odeslání IP datagramu. Jediný záznam, který matchuje, je default route (0.0.0.0/0), který vede na next-hop 192.168.1.1 přes interface wlp58s0. Tato informace klientovi stačí, aby zkusil najít v ARP cache záznam pro IP adresu 192.168.1.1 a s jeho pomocí mohl vyplnit cílovou adresu v L2 hlavičce. Mezi klientem a routerem R1 je sice WiFi, ale ta se v této situaci chová obdobně jako Ethernet (a rozebereme si to později detailně). Pokud klient L2 (MAC) adresu v ARP cache nenajde, vyvolá ARP dotaz, aby zjistil, kam datagram poslat. V našem příkladě bude výsledek 88:71:b1:08:5d:d0.

2. Klient musí při navazování spojení rozhodnout nejen, kterým rozhraním odešle první TCP segment, ale i jakou IP adresu použije jako zdrojovou. V našem případě je to však jednoduché - jediné rozhraní, které klient má (krom loopbacku), a přes které tedy bude první datagram odcházet, je WiFi karta wlp58s0. Z tohoto rozhraní tedy klient použije zdrojovou IP adresu 192.168.1.100 a i zdrojovou MAC adresu cc:d9:ac:1c:5e:44 - tohle rozhodnutí udělá jen na začátku, pak už je TCP spojení určeno neměnnou čtveřicí: zdrojová a cílová IP adresa a zdrojový a cílový port.

V našem případě tedy přes WiFi rozhraní wlp58s0 odejde následující rámec. Pro jednoduchost se nebudeme zabývat specialitami WiFi a představíme si, že WiFi emuluje Ethernet, což je do znační míry pravda:

3. Předpokládejme, že datagram úspěšné dorazil na router R1 po L2 mezi klientem a R1. R1 datagram vybalí z MAC hlavičky (při tom se kontroluje, že cílová MAC adresa rámce je adresa rozhraní wlan0 na R1). Kdyby nebyla, rámec by se zahodil.

   Router R1 vyhledá podle pravidla LPM nejlepší cestu pro cílovou adresu z datagramu 10.1.5.10. Ve směrovací tabulce R1 je nejlepší (a jediný) match poslední cesta 10.1.0.0/16 via 10.1.1.1. Tato informace nám však nestačí, protože nevíme, přes které rozhraní máme datagram poslat. Proto je třeba udělat rekurzivní vyhledání next-hopu 10.1.1.1 z výsledku vyhledání cílové adresy z datagramu. Pro adresu 10.1.1.1 matchuje záznam 10.1.1.0/30 dev eth0 . To je connected route a říká nám tedy, že next-hop pro datagram je dostupný přes L2, rozhraní eth0. Udělá se tedy opět ARP vyhledání resp. ARP request + reply transakce, aby se zjistila cílová MAC adresa pro 10.1.1.1 přes eth0 a po Ethernetu mezi R1 a R2 odejde rámec takhto:

IP adresy v hlavičce se ovšem nijak nezměnily - ty zůstávají po celý přenos stejné, v IP hlavičce se jen odečítá pole TTL na každém routeru, ale jinak všechny změny probíhají v MAC hlavičce. Mimochodem, TTL pole (v našem příkladě není explicitně vypsané, ale spadalo by do sekce „další pole“) slouží k prevenci smyček: při každém průchodu routerem se odečte z inicializované hodnoty (zpravidla 64) jednička. Jakmile by se hodnota snížila na nulu (tedy po průchodu 64 routery, což značí, že se pravděpodobně zasmyčkoval), bude datagram zahozen.

4. Na routeru R2 se situace opakuje - IP datagram je vybalen z ethernetové hlavičky, vyhledá se nejlepší záznam podle LPM, což je záznam 10.1.5.0/24 dev eth1, což je connected route a tedy router R2 vyhledá pomocí ARPu MAC adresu pro cílovou adresu 10.1.5.10 z našeho datagramu. MAC adresa bude 4e:4b:0c:66:fb:66 a datagram se tak může doručit přes L2 k cíli v této formě:

5. V cestě nám ještě stojí switch S1, ale ten do IP hlavičky nekouká vůbec a v ethernetové hlavičce nic nemění. Pouze si z procházejícího datagramu zapamatuje do switchovací tabulky, že MAC adresa ba:57:a8:cf:54:58 je dostupná na portu ethernet 1. Pokud bude mít ve switchovací tabulce informaci o tom, na kterém portu je MAC adresa 4e:4b:0c:66:fb:66 (je na portu ethernet 2), odešle náš rámec jen na tento port. Jinak jej rozešle na všechny aktivní porty (v dané VLAN, což už tu pro jednoduchost detailně znovu nerozebíráme).

6. Jakmile rámec dorazí na rozhraní eth0 serveru a následně je předán prokolu IP, zjistí se porovnání cílové adresy s adresou rozhraní, že server je adresátem datagramu a datagram je předán vyšším vrstvám TCP/IP stacku ke zpracování.

Odpověď od serveru ke klientovi bude doručovaná obdobně, jen v opačném směru, neboť odpověď bude mít v prvotním IP datagramu naopak cílovou a zdrojovou adresu, než měl původní dotaz, který jsme v minulém odstavci rozebrali.