Přenosový kanál je definován čtveřicí číselných hodnot. IP-adresou
počátečního počítače a IP-adresou cílového počítače a dále porty
cílového a počátečního počítače. Port je číslo, které
má rozlišit různé funkce, ke kterým byl přenosový kanál vytvářen.
Obrazně řečeno má vyjádřit způsob, jímž je přenosový kanál "ukotven"
k počátečnímu i cílovému počítači.
Na Obr. 1 ( v předchozí kapitole [1])
byl vytvořen virtuální přenosový kanál z prvního počítače na druhý
pro uživatele User1, který pracuje s TELNETem, a současně s tím může
začít program SMTP přenášet stejným směrem i E-mail (dopis). Další
uživatel User3 by mohl právě otevírat FTP. Přitom již úvodní reakce
druhého počítače je na každou ze zmíněných činností odlišná. ( Například
pro SMTP nevyžaduje zadání hesla.) Vlastně se dá říci, že příkazy pro aktivaci
nějaké (interaktivní) funkce v Internetu by měly obecně vypadat
funkce počítač [port]
A skutečně se tato syntaxe dá v mnoha případech nějakým způsobem nalézt, nejuniverzálněji pro funkci TELNET . Explicitní zadávání portu ovšem není příliš časté, neboť pro běžné funkce se v Internetu standardně používají pro port tyto implicitní hodnoty:
| funkce | port | |
| FTP | 21 | |
| TELNET | 23 | |
| SMTP | 25 | ( E-mail ) |
| - - - - - - | ||
| Gopher | 70 | |
| WWW | 80 | |
Již hodnoty implicitně stanovených portů v Internetu dávají tušit, proč právě tyto funkce byly v předchozím ( na rozdíl od funkcí jiných ) uvedeny jako charakteristické pro funkční pohled na počítač připojený do Internetu. Jen dodejme, že podle SMTP - zkratka Simple Mail Transfer Protocol - pracují v pozadí programy přenášející dopisy.
Přitom první tři (historické) funkce představují tzv. spojovanou
spolupráci programového vybavení na dvou počítačích. To znamená, že virtuální
kanál je otevřen po celou dobu seance ( zakončované explicitně příkazy jako
quit , bye , logout a podobně ).
Gopher a WWW naopak představují typickou nespojovanou spolupráci
klient-programu se server-programem. Přenosový kanál se vždy znovu vytváří
pro každý požadavek zadávaný serveru. Po odpovědi serveru je kanál zrušen.
( To zároveň vysvětluje, proč se v těchto případech někdy hovoří o síti
Gopher serverů nebo WWW serverů .)
Je potřeba zdůraznit, že pro určení přenosového kanálu je možné implicitní
hodnotu portu používat pouze pro cílový počítač! Oprosťme se od pohledu
uživatele osobního počítače. Představme si, že by ve výše zmiňovaném
příkladu současně s uživatelem User1 otvíral funkci TELNET ve stejném
směru i třeba uživatel User4. Pokud bychom i pro port na počátečním
počítači použili standardní hodnotu 23 , nemohli bychom tyto dva virtuální
kanály rozlišit. Proto je port počátečního počítače generován (jeho) systémem,
aby bylo zaručeno, že v každé čtveřici definující virtuální kanál je alespoň
jedno číslo odlišné. Jakým způsobem je zajišťováno generování odlišné hodnoty
počátečního portu závisí na způsobu implementace v operačním systému.
V našem příkladu to zajišťuje část TCP a IP , která obhospodařuje veškerou
komunikaci do sítě.
Snad ještě poznámka k tomu, že i na PC je situace obdobná. Proto můžeme
například v TELNETu i z PC současně otvírat třeba dvě seance na tentýž
(cílový) počítač.
Je-li přenosový kanál otevřen, nemusí být určující čtveřice čísel - dvakrát 32-bitová hodnota adres počítačů a dvakrát 16-bitová hodnota portů - po celou dobu konstantní. V Internetu existují prostředky, aby bylo možno ( v průběhu seance ) změnit port, lze vzájemně zaměnit roli cílového a počátečního počítače, otevírat další virtuální kanály a podobně.
Například FTP vytváří pro vlastní přenos souboru ještě druhý virtuální kanál, a to opačným směrem. Přitom tento druhý, tzv. datový kanál, může být otevřen buď po celou dobu seance anebo jen po dobu přenosu některého souboru. Alespoň nahlédnout lze na koncepční schéma - Figure 1 ( část 2.3 ) - v RFC959 [2], které popisuje File Transfer Protocol .
Představme si, že například jsme někam propojeni TELNETem a po přenosovém
kanálu je právě potřeba přenést celou popsanou obrazovku, což představuje
( s nějakými mezerami na konci řádků ) tak 1600 znaků. Program
TELNET, s nímž pracujeme, předá všechny znaky TCP-části, která je rozdělí
na 500, 500, 500 a 100 znaků. Ke každé této části doplní hlavičku, možná výstižněji
záhlaví TCP-protokolu a předá ji komponentě, která pak zajistí jejich odeslání.
Každá z těchto čtyř částí potom putuje samostatně sítí Internet až k cílovému
počítači. A zde opět pracuje TCP-část, která ony čtyři části správným
způsobem složí a předá je programovému vybavení, které zde podporuje naši
práci v TELNETu. Pochopitelně mohou jednotlivé části na cílový počítač
dorazit v pozměněném pořadí, třeba poslední část, ve které je jen 100 znaků,
může dorazit již jako druhá. V doplňovaném TCP-záhlaví tedy musí
být informace, podle níž je možno jednotlivé části opět správně složit.
Například v oné poslední části je konkrétně uvedeno číslo 1500, které znamená,
že tato část navazuje na předchozí 1500. znak, tedy je potřeba nejprve složit
(a získat) ony tři 500 znakové části.
Ba co více. Pokud některá část vůbec nedorazí nebo je při přenosu
poškozena, TCP-část na cílovém počítači si je schopna si ji znovu
vyžádat z počátečního počítače. A teprve po správném sestavení přenášené
množiny znaků potvrdí TCP-části na počátečním počítači úspěšné přenesení
dat po virtuálním přenosovém kanálu. Proto se také při využívání protokolu
TCP hovoří v Internetu o potvrzovaných službách.
Popis struktury TCP-hlaviček tj. TCP-záhlaví doplňovaných k vytvářeným částem (datagramům) je převzat z části 2. Introduction to the Internet Protocols [4] zmiňovaném již v předchozí kapitole. Snad lze ještě doplnit, že každý řádek obsahuje 4 byty (oktety), tedy 32 bitů. ( Každý z nich je ve schématu reprezentován jednou pomlčkou - .)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port (počáteční port) | Destination Port (cílový port)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | your data ... next 500 octets | | ...... |
Takto ale přenášené datagramy ještě nevypadají ! Pokud někdo nemůže najít
ve schématu TCP-protokolu nějaké informace o adresách, nechť se podívá
na další schéma.
Každá část ( včetně TCP-záhlaví ) je vložena do IP-datagramu.
Anebo řečeno jinak, je doplněna IP-hlavičkou a takto vzniklý
IP-datagram je pak přenášen po Internetu.
IP je zkratkou
z Internet Protocol ,
podle něhož mají hlavičky přenášených IP-datagramů takovýto tvar:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address ( počáteční IP-adresa ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address ( cílová IP-adresa ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TCP header , then your data ...... | | |
Schéma je převzato jako předchozí ze stejného zdroje a rovněž se z něj dá
( podle počtu pomlček ) vyčíst počet bitů vyhrazených jednotlivým údajům.
Nejdůležitějšími informacemi v IP-hlavičce jsou samozřejmě ( 32-bitové )
číselné IP-adresy. Na cílovou IP-adresu pak datagram v Internetu
dopravují IP-routery.
Ještě je potřeba se asi krátce zmínit o velikosti přenášených IP-datagramů. Velikost může být (teoreticky) až 65535 bytů, lépe řečeno oktetů, jak se má používat v souvislosti s Internetem. Oktet je tvořen 8 bity , což je na všech běžně používaných počítačích u nás jeden byte. Ale mohou být v Internetu i počítače, na nichž má "byte" (jakožto základní adresovatelná jednotka paměti) odlišnou velikost. Omezení na méně než 65536 = 2 ** 16 oktetů je dáno vyhrazením 16 bitů v hlavičce IP-datagramu pro hodnotu "Total Length", což jest celková délka IP-datagramu ( včetně IP-hlavičky ).
Každá realizace přenosu IP-datagramů využívá nějakého systému komunikace. IP-datagramy se obvykle vkládají do jednotlivých paketů tohoto komunikačního systému. ( Analogickým způsobem jako jsou ze segmentů TCP vytvořeny jednotlivé IP-datagramy. ) Stále je asi nejčastějším konkrétním příkladem princip vkládání IP-datagramů do paketů Ethernetu. A na to pak navazují i způsoby transformace 32-bitových IP-adres počítačů na 48-bitové adresy používané v kartách Ethernetu. Způsoby implementace nejen do Ethernetu, ale i do jiných komunikačních prostředí jsou náplní řady RFC-dokumentů [5], z nichž ovšem některé jsou pro obyčejného uživatele Internetu už těžko čitelné.
Zpravidla ovšem nemohou mít pakety komunikačního prostředí až takovou velikost jako IP-datagramy. Potom je nejsnazším řešením připustit přenos pouze IP-datagramů menší velikosti, které lze ještě jednoduše vkládat do komunikačních paketů. Tato omezující hodnota může být pro různé přenosové cesty odlišná a pro určitý úsek je dána hodnotou MTU , tj. Maximum Transmission Unit. Minimální možná velikost MTU pro každé místo v Internetu musí být alespoň 576 oktetů. ( Tedy vidíme, že ony čtyři IP-datagramy z příkladu přenosu naší zaplněné obrazovky by měly být schopny bez problémů dorazit kamkoliv v síti Internet.) Pokud do paketů komunikačního prostředí se nedá vložit 576 oktetů, je pak implementace IP-přenosu složitější. Každý IP-datagram musí být rozdělen a následně zase složen z několika komunikačních paketů. To je konkrétně případ rozhraní (komunikačního prostředí) X.25 , kde velikost používaných komunikačních paketů je 128 bytů.
V tom, že lidé, kteří stáli u zrodu Internetu, velmi prakticky z důvodů
snadného propojení různých sítí principiálně připustili libovolnou velikost
IP-datagramů, je například jeden z důvodů velkého rozšíření Internetu.
S rozvojem nových přenosových technologií vzrůstají nejen přenosové rychlosti,
ale je možné používat i větší komunikační pakety. To je samozřejmě výhodné,
neboť pro větší soubory dat nemusí výrazněji stoupat režie přenosu daná
rozkladem na (malé) IP-datagramy.
Pochopitelně ovšem může dojít k situaci, že velikost přenášeného datagramu
je větší než MTU v některém místě sítě Internet ( a jiná cesta není
možná ). Takováto situace se pak řeší fragmentováním
IP-datagramu, tedy rozdělením na IP-datagramy menší velikosti.
Fragmentované datagramy se pak znova nespojují, putují už takto na cílové
místo. Jejich vzájemná návaznost je pak uvedena v IP-hlavičce v poli
"Fragment Offset".
Offset obvykle znamená počet znaků od začátku, v tomto případě tedy původního IP-datagramu, a tím lze v něm fragment lokalizovat. Nelogické pak ovšem je, že pro tento údaj je v hlavičce vyhrazeno pouze 13 bitů, původní datagram přitom mohl teoreticky mít velikost, k jejímuž zapsání 13 bitů nepostačuje. Při fragmentaci se však nové (menší) datagramy vytvářejí tak, aby vždy obsahovaly počet oktetů dělitelný osmi. "Fragment Offset" zde tedy neznamená počet oktetů od počátku původního datagramu, ale takovýto údaj vydělený číslem 8 ( anebo tedy offset vyjádřený počtem 64-bitových řetězců ). Neboť 8 = 2 ** 3 , lze pro údaj "Fragment Offset" vystačit s 16 - 3 , tj. 13 bity. Snad ještě doplňme, že (číselný) údaj "Identification" je při fragmentaci naplněn stejnou hodnotou jen pro fragmenty z téhož IP-datagramu. Tak je na cílovém počítači známo, které fragmenty mají patřit k sobě - viz RFC791 [6] .
ICMP-protokolem jsou například zasílány zprávy, že některý
router není
kapacitně schopen zajistit transfer datagramů dál. ( Počáteční počítač -
pokud se ovšem nejedná o systém NT - se snaží alespoň prodloužit interval
odesílání jednotlivých datagramů, aby nedocházelo ke zbytečnému zahlcování
přenosové cesty.) Protokolem ICMP se také zjišťuje dostupnost počítače
v síti. Ten by měl IP-datagram vrátit nezměněný odesílajícímu
(počátečnímu) počítači, což je využíváno například programem ping.
Protokoly ICMP ( a obdobně UDP ) mají shora uváděnou IP-hlavičku
a pak obsahují další pole počínaje 21. oktetem, tedy místem, kde v předchozím
schématu začíná TCP header . ( Při jejich popisu se ale často mluvívá
už jen o těchto dalších polích.) Strukturou definovaných polí by tedy
ICMP-protokoly mohly patřit - analogicky TCP - do vy
musejí být zpracovávány na stejné úrovni jako IP-datagramy, tedy
IP-částmi programových systémů, neboť právě jejich funkce je jimi
řízena. ( Typy ICMP-protokolů a jimi přenášených chybových zpráv lze nalézt
v RFC792 [7] .)
UDP-protokol je určen pro informativní uživatelské aplikace,
jako třeba nslookup . Obdobně protokolu TCP obsahuje tento protokol pole
počáteční a cílový port a samozřejmě také datovou oblast.
IP-část by měla aplikačnímu programu předávat i informace
z IP-hlavičky, jako je počáteční a cílová IP-adresa.
A protože ty nejsou součástí UDP-protokolu, hovoří se někdy o předávání
informací z pseudozáhlaví.
Podstatný rozdíl je oproti spolupráci aplikačního programu s TCP-částí
( a s využitím TCP-protokolu ) v nezabezpečeném přenosu protokolů UDP.
Aplikační program musí být napsán tak, aby pro jeho práci anebo pro uživatele
se nestala zásadním problémem skutečnost, že některý datagram nedorazil
úspěšně k cíli ( nebo situace, že to ani není známo ). Při využívání UDP
( případně protokolu ICMP ) se proto hovoří o tzv. nepotvrzovaných
službách.
Z hlediska přenosu v Internetu je důležité, aby IP-datagramy ( ať již jejich datový obsah odpovídá kterémukoliv protokolu ) byly schopny dorazit až na cílový počítač. Dosažitelnost počítače pro IP-datagramy je nazývána IP-konektivitou. Podle tohoto hlediska je možná nejlepší rozhodovat, zda je počítač zapojen do sítě Internet. Ale z druhé strany bychom také mohli takto definovat síť Internet. Jako síť počítačů s IP-konektivitou, tj. počítačů dosažitelných pro IP-datagramy. Problém takovéto charakterizace je v tom, že se obvykle výslovně neuvádí, aby počítač byl vždy dosažitelný, nebo s ohledem na případné poruchy, aby byl teoreticky vždy dosažitelný. Což by asi nejlépe odpovídalo původnímu pojetí Internetu. Po pravdě je těžko říci, zda dnes IP-konektivitu chápeme jako trvalou anebo jen po dobu činnosti nějaké internetové funkce. Čehož důsledkem jsou ony rozdílné hodnoty v odhadech počítačů připojených do Internetu, jak je zmiňováno na začátku předchozí kapitoly.
IP-datagramy v Internetu dopravují IP-routery, tak hovoříme o počítačích, které zprostředkují převod datagramů z jedné linky na druhou. V současnosti se především pro připojení kapacitních linek využívají jako routery účelově konstruované počítače, aby byly schopny nejen zajistit transfer velkého množství IP-datagramů mezi řadou připojitelných linek, ale aby i algoritmus převodu datagramů mezi nimi byl programovatelný. Pokud se na Internet díváme jako na množinu nejrůznějších podsítí, potom routery zajišťují přechod IP-datagramů z jedné podsítě do jiné. Z úrovně komunikačního prostředí se proto někdy místo internetového pojmu router používá slovo "gateway". To je rozšířeno spíše ve starší literatuře, pokud ještě nerespektuje terminologii podle současných RFC-dokumentů. ( Často užívané označení RFC je ze slov Request for Comments a v Internetu, jak je všeobecně známo, lze v těchto volně získatelných dokumentech nalézt závazné standardy i mnohá dalších doporučení, aby nejrůznější typy počítačů byly v síti Internet schopny navzájem spolupracovat. Řada dokumentů je ale jen vysvětlujících a informativních, jako například RFC1983 [8] týkající se právě terminologie. )
Z internetového pohledu tedy routery IP-datagramy tak, jak je z jednoho směru (z jedné linky) dostanou, předávají dál (na jinou linku). Výrazným zásahem může být jedině fragmentování datagramu, pokud v následujícím směru je MTU nedostatečně veliké. Pro přesnost bychom měli ještě dodat, že router ale sníží hodnotu pole "Time to Live" v IP-hlavičce datagramu. Hlavním důvodem je omezit případné bloudění IP-datagramů po síti Internet pouze na dobu, než je toto pole vynulováno. ( Poté se datagram ztratí, neboť již nemá být routery předáván dál. )
Hlavní informací, jíž se routery řídí, je IP-adresa cílového počítače.
Router datagram předá na linku, kudy vede cesta k cílovému počítači.
Uvědomíme-li si, že 32-bitové adresy představují přes 4 miliardy možností,
je téměř neřešitelné, aby každý router přesně znal směrování pro všechny
možné IP-datagramy. Pro nalezení vhodné cesty routery využívají
různé algoritmy, které zpravidla kombinují použití tabulky pro nejběžnější
adresy, defaultní (nebo též implicitně určené) směrování pro neznámé adresy
a dočasně používané informace o špatném směrování, které získaly
z ICMP-zpráv. Přesto nemusí být nalezení správné cesty v některých uzlech
algoritmicky jednoduše řešitelnou záležitostí. Na začátku 90.let dokonce
někteří odpovědní pracovníci Internetu upozorňovali, že poroste-li počet
počítačů v Internetu dosavadním tempem a přitom nebudou přijata přísnější
pravidla pro přidělování IP-adres, může se časem stát, že (libovolné)
dva počítače nemusejí být v Internetu vzájemně dosažitelné.
Způsob směrování IP-datagramů se v Internetu nazývá
IP-routing. Nejsnáze lze možná s tím spojené
problémy ilustrovat na historickém vývoji připojení vysokých škol u nás
do sítě Internet. V době, kdy u nás existovalo jediné spojení do Internetu
po telefonní lince do Lince, bylo routování IP-datagramů u nás
velice jednoduché. Všechny IP-adresy našich počítačů tehdy začínaly
147... anebo ještě 146.102.. , to byla (a je) Vysoká škola
ekonomická. Cesty k nim byly dány jednoznačně, neboť všechny tuzemské
linky vedly do OVC ČVUT v Dejvicích. Pokud cílová IP-adresa začínala
jinak, poslal se datagram (z Dejvic) do Lince - a tam si s ním už nějak
poradili.
První vážnější problém se u nás objevil v okamžiku, kdy kromě první linky
do Rakouska, jejíž zakončení bylo mezi tím přeneseno do Vídně, byla otevřena
druhá mezinárodní linka do Amsterodamu. Router, který od nás směroval
IP-datagramy do zahraničí, vybíral směr buď do Rakouska nebo do
Holandska podle toho, kudy mu cesta k cílovému počítači vycházela kratší -
podle počtu počítačů (routerů), kterými datagram procházel. ( Router si
informacemi o délce cest postupně rozšiřoval svoje tabulky, asi jako kdyby
si uživatel tyto informace postupně zapisoval z každého použití příkazu
traceroute .) Záhy se ukázalo, že většina cest vychází kratší
přes Vídeň a že tak linka do Rakouska je stále přetěžována oproti
nepříliš kapacitně využívané lince do Holandska. Proto byl dočasně využit
zcela jiný (triviální) algoritmus směrování, který vycházel
z IP-adresy počátečního počítače. Datagramy z Dejvic (z ČVUT a VŠCHT)
byly směrovány do Holandska, datagramy ze zbytku republiky pak do Rakouska.
Tato situace trvala pochopitelně jen asi 2 nebo 3 týdny, než se podařilo
vybrat jiný algoritmus ( a získat pro router příslušný program ). Za
povšimnutí z celé situace snad stojí to, že směrování ( IP-routing ) se
může řídit také adresou odesílatele datagramu ( počáteční IP-adresou ).
T.č. se to například využívá v routerech, které rozhodují, zda datagram
z některých (uzlových) měst bude cestovat po linkách CESNETu anebo po
ATM-spojích v síti TEN155-CZ.
Současné routery jsou schopny pro IP-routing používat nejen informace o zatížení linek, ale dokonce i údaj o cílovém portu, který ovšem není uveden v IP-hlavičce. Musejí se tedy zabývat i datovou částí IP-datagramu a pokud ta začíná TCP-hlavičkou, je v datagramu informace o portu. A tak mohou být směrovány IP-datagramy odpovídající některé funkci Internetu jinudy, než řekněme IP-datagramy přenosu pošty, dokonce lze přenos IP-datagramů některých funkcí na určitém routeru preferovat. Možná pravý opak těchto věcí se lze někdy dočíst ve starší literatuře o Internetu, kde se vychází z koncepčně vlastně správnější představy, že IP-routery se zabývají jen IP-hlavičkami datagramů, protože by routing zdržovalo, kdyby se ještě musela analyzovat datová část IP-datagramu. Změna tohoto pojetí v současnosti je dána výkonností a účelovým zaměřením počítačů používaných pro IP-routing. Takto lze dokonce zakázat směrování některých datagramů podle údajů vztahujících se k portu. Tento problém se už spíše dotýká konstrukce firewallů ( zařízení, jež se snaží kvůli různému účelu zamezit přenosu datagramů té či oné internetovské funkce ).
To vše ale neřeší podstatným způsobem zásadní problém IP-routingu, a to nalezení cesty k určitému počítači. ( Problém, který v předchozím historickém ohlédnutí do našich začátků Internetu se vyřešil někde v Rakousku.) V samých počátcích Internetu byla možná představa, že úvodní čísla IP-adres budou nějakým způsobem korespondovat s linkami k jednotlivým podsítím. ( Analogicky začátku Internetu u nás. ) S postupným rozšiřováním sítě Internet, budováním dalších spojení a změnami v jejich topologii se prakticky nedá takovýchto vazeb již využívat. S prudkým nárůstem počítačů zapojených do Internetu okolo přelomu 80. a 90. let se více méně musela opustit i snaha, aby alespoň významné uzlové routery věděly o všech IP-adresách ( přesněji počátcích IP-adres ) přidělených pro podsítě. Věděly pouze o nejvýznamnějších (největších a nejbližších), které měly s informacemi o směrování uloženy v tabulce. Tabulky si mohou routery vytvářet a pak aktualizovat různým způsobem a podle způsobu použitých metod a algoritmů se pak v Internetu rozlišují a nazývají způsoby routingu.
Pokud k některé (cílové) IP-adrese nenalezne router žádnou informaci
ve svých tabulkách, využije tzv. defaultního směrování -
default route . Datagramy neznámých cílových adres směruje vždy
na jednu určenou linku. ( Jako bylo u nás na onom prvním routeru do Lince.)
Pochopitelně takto může dojít i k situaci, že IP-datagram se znovu
vrátí na router, kde již jednou byl. Pokud to router nerozpozná a pošle
datagram opět stejným směrem, vyprší časem životnost IP-datagramu aniž
byl úspěšně doručen. V tom případě (nejpozději) router, na němž skončila
životnost datagramu, odesílá ICMP-zprávu, že datagram nedorazil k cíli.
Tu ovšem zasílá na IP-adresu počátečního počítače. Pokud zjistí,
který router jej nevhodně směroval, může jemu poslat ICMP-žádost o změnu
směrování.
Možnosti protokolu ICMP ovšem plně nepokrývají případy, které přitom mohou
nastat a nedá se s jejich pomocí zaručit vždy správné nalezení cesty.
V podstatě čím bohatší (hustší) topologie pro možné směrování datagramů, tím
obtížnější může být nalezení správné cesty v Internetu. ( Například i proto,
že ICMP-zpráva o nedoručení IP-datagramu se na počáteční počítač může
vracet přes zcela jiné IP-routery a původní routery tak ani nemusí mít
šanci se dozvědět o slepé cestě.) Na takovéto problémy, které je nutno v síti
Internet řešit, upozorňovali na začátku 90.let někteří odborníci.
Problém se podařilo překonat ( možná ale jen oddálit ) budováním "informačních
dálnic" [9],
tím je myšleno budování a využívání vysokokapacitních přenosových
spojů. Situaci bychom mohli připodobnit k problému, který si každý snadno
asi dokáže představit, volbě trasy, po níž je nejlepší jet u nás automobilem
z Chebu do Olomouce. Po nynějším dobudování dálnice na západ od Plzně vyjde
podle většiny kritérií jako nejlepší řešení najet co možná nejblíže od Chebu
na dálnici a po ní pak pokračovat směrem Praha, Brno a po rychlostní komunikaci
dále do Olomouce. I v mnoha jiných případech většinou vyjde strategie
(algoritmus) nejbližšího napojení na čtyřproudovou komunikaci jako nejlepší,
a nakonec je skoro zbytečné zdlouhavě zvažovat různé jiné trasy a cesty
právě proto, že síť našich čtyřproudových komunikací má (dosud) velmi
jednoduchou topologii. Pro srovnání jen uvažme varianty a rozhodování
v případě, že bychom museli jet pouze po (husté) síti obyčejných silnic.
A stejným způsobem existence (menšího počtu) vysoce kapacitních přenosových
spojů usnadňuje rozhodování o směrování IP-datagramů. ( A rovněž pak
lze s daleko větší pravděpodobností určit, na který router by měl směřovat
ICMP-požadavek pro opravu směrovací tabulky.) Ne nepodobně pozemním trasám
se tak v tomto pojetí snad i výstižně zavedl pojem "informačních dálnic".
V Internetu ale 7 vrstev nenajdeme. Pokud bychom se důsledně dívali na Internet jako jen na to, co je v celé této síti jednotné, dá se asi nejvýstižněji říci, že Internet má vrstev 3,5 . Vztah sedmi vrstev ISO OSI k internetovskému prostředí ilustruje následující obrázek:
vrstvy ISO OSI síť Internet
------------------------
| aplikační | -------------------------
------------------------ | |
| presentační | | internetovské |
------------------------ | funkce |
| relační | | |
------------------------ -------------------------
| transportní | | T C P - část |
------------------------ -------------------------
| síťová | | I P - část |
------------------------ -------------------------
| linková | | komunikační prostředí |
------------------------ _ _ _ _ _ _ _ _ _ _ _ _ _
| fyzická |
------------------------
Obr. 2
Oproti komunikačnímu prostředí, v němž bychom linkovou část a pod ní i fyzickou byli schopni nalézt ( a otázkou pak je její vztah k Internetu ), vrstvy relační a presentační se v internetovských funkcích dají dost těžko nějak charakterizovat. Ovšem z druhé strany je také obtížné zahrnout vše jen do nejvyšší (sedmé) vrstvy aplikační ( například ve WWW odlišné funkce http a HTML - viz další kapitoly ).
Toto nemá popírat význam všech 7 vrstev pro budování některých firemních či účelových sítí. Je však třeba se vážně zabývat otázkou, zda rozšíření Internetu téměř na všechny typy počítačů není dáno právě tím, že se zde specifikovaly pouze tři nebo čtyři nejpodstatnější vrstvy. Nejen že tím byla tvůrcům poskytnuta jistá volnost pro efektivní implementaci na rozdílných platformách, ale hlavní předností je spíše průhlednost několika vrstev Internetu v porovnání s jistě zdlouhavějším studiem sedmi vrstev ( což pochopitelně nebaví ani tvůrce softwarového vybavení počítačů ). A tak je možno jedině konstatovat, že i při tvorbě sjednocujících pravidel a doporučení bývá méně někdy více.