Principy přenosu v síti Internet

SDĚLOVACÍ KANÁL-PŘENOSOVÝ KANÁL

Přenosový kanál

V síti Internet se pro realizaci přenosu mezi počítači vytvářejí přenosové kanály někdy také charakterizované jako virtuální přenosové kanály. Virtuální - což znamená pomyslné - protože o jejich existenci vědí pouze počítače, mezi nimiž je přenosový kanál vytvořen. Vytvoření přenosového kanálu nedefinuje jeho kapacitu, neurčuje konkrétní přenosové linky, kudy bude komunikace probíhat, není ani zabezpečeno, aby v případě výpadku linky byla tato informace předána na dotyčné počítače. Původní koncepce přenosu na lince spojující dva počítače vychází z toho, že pokud to její kapacita dovolí, jsou zde přenášeny IP-datagramy, aniž se přitom zkoumá, k jaké funkci patří. Takže potom není ani dost dobře možné kontrolovat všechny virtuální kanály, které by přes tuto linku mohly vést.

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 .

TCP / IP

Většina internetových aplikací pracuje tak, že data přenášená virtuálním kanálem jsou segmentována do částí, o kterých se hovoří jako o tzv. datagramech. Způsob segmentování popisuje protokol TCP - Transmission Control Protocol . Většina aplikací se přitom obrací na komponentu systému nazývanou TCP-část, jež takovouto činnost na počítači zajišťuje. ( RFC793 [3] )
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] .

Problémy spojené s fragmentováním by snad blíže mohla ilustrovat následující situace. Řekněme, že v našem předchozím příkladě by TCP-část zasílala 1000 znaků. Obrazovka se tak pošle ve dvou částech, 1000 a 600 znaků. A nyní si představme, že zaslané IP-datagramy narazí někde na linku, kde MTU bude třeba jen 784. Každý zaslaný IP-datagram obsahuje IP-hlavičku o 20 bytech (oktetech) a ještě TCP-záhlaví standardně také 20 oktetů, tedy jejich celková velikost je 1040 resp. 640 oktetů. První IP-datagram proto bude muset být rozdělen na fragmenty, které mimo IP-hlavičku budou oktetů obsahovat nanejvýše 764. Oktety ve fragmenu (nezapočítává se IP-hlavička) musí být dělitelné 8 , tedy do prvního fragmentu se může zahrnout maximálně 760 oktetů, ( Za TCP-záhlavím je v něm tedy dále přenášeno jen 740 znaků z obrazovky.) Zbývající fragment bude obsahovat zbylých 260 znaků obrazovky. ( Datová velikost posledního fragmentu pochopitelně již nemusí být dělitelená 8 .) U tohoto IP-datagramu je jen IP-hlavička, tedy jeho celková velikost je 280 oktetů.
Pokud by na svě cestě k cíli narazily IP-datagramy na linku, kde MTU je 576, opět by se fragmentovaly, a to i datagramy již jednou fragmentované. Tedy konkrétně první fragment celkové velikosti 780 oktetů, se může rozdělit na IP-datagram velikosti 572 nesoucí fragment 552 oktetů ( 552 = 8 * 69 ) a IP-datagram velikosti 228 oktetů s fragmentem, který bude také násobkem 8 , konkrétně tedy 208. Při následně fragmentaci pak je nutné zachovat položku "Identification". Tím, že návaznost fragmentů je dána polem "Fragment Offset" ( do něhož se nezpočítávají oktety IP-hlavičky ), je pro opětovné skládání jednotlivých fragmentů ( na cílovém počítači ) jedno, jak a kde k jejich fragmentaci došlo.

Zároveň je snad vidět, že prvotní volba maximální velikosti jednotlivých přenášených částí, pokud je při konfiguraci volitelná, musí nějak zohledňovat i hledisko nejčastějšího použití třeba zde zmiňovaného TELENETu. Pokud jej uživatelé používají většinou tam, kde je všude MTU alespoň 1040, bude práce podle této druhé varianty efektivnější, pokud se však při jeho použití dostávají velmi často do míst sítě s nizkou velikostí MTU, je efektivnější využívat prvně popisovanou situaci, kdy se vždy zasílá jen oněch 500 znaků obrazovky.

IP-konektivita Internetu

O odesílání a přijímání IP-datagramů se na počítači většinou stará IP-část programového vybavení počítače, velmi úzce spolupracující s TCP-částí. Často se jedná o jednotný programový produkt, schematicky značený v obrázku v předchozí kapitole jako TCP_/_IP . IP-část musí umět zpracovat i IP-datagramy, jež nemusí obsahovat TCP-záhlaví. Jde většinou o IP-datagramy, které zabezpečují servisní (systémové) funkce v Internetu, kde by bylo zbytečné a komplikované, aby procházely částí TCP, neboť se jedná zpravidla o krátké informace. To se týká příkladně IP-datagramů, které jsou popsány protokolem ICMP ( Internet Control Message Protocol ) nebo UDP ( User Datagram Protocol ).

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 Amsterdamu. 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čtupočí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ápadod 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".

Internet a vícevrstvá architektura

V podstatě souběžně s koncepcí Internetu se koncem 70.let začíná do povědomí dostávat sedmivrstvý model architektury počítačových sítí. Velmi často se o něm hovoří jako o 7 vrstvách architektury ISO OSI . ISO je zkratkou International Organization for Standardization, jejíž jedna komise vytvářela standardy pro komunikační sítě známé jako OSI - Open Systems Interconnection. Standardy byly rozděleny do 7 úrovní, podle toho jaké části hardwaru a softwaru se týkají. Označovány jsou, počínajíc nejnižší vrstvou, jako vrstva: fyzická, linková, síťová, transportní, relační, presentační, aplikační. Tímto rozdělením se důsledně řídí sítě, které jsou plně budovány na rozhraní X.25 .

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

Část TCP je transportní vrstva, IP-část odpovídá vrstvě síťové. Vrstvy relační a presentační se dají v Internetu těžko nalézt. Nad částí TCP jsou již jednotlivé (uživatelské) funkce Internetu, jejichž chování v síti popisují RFC-dokumenty. Z těchto funkcí jsou nejrozšířenější FTP, TELNET, SMTP, Gopher, WWW , jak již bylo zmiňováno na začátku této kapitoly.
Pod IP-částí je úroveň obhospodařovaná instalovaným komunikačním systémem. RFC-dokumenty v řadě případů popisují také způsob realizace přenosu IP-datagramů v komunikačním prostředí. Faktem ale je, že kdyby bylo vkládání IP-datagramů do komunikačních paketů realizováno způsobem jiným, nic by to v zásadě nezměnilo na práci v prostředí Internetu. Samozřejmě by se například nemohl převzít modul (driver) TCP/IP , ale musel by být speciálně naprogramován. Obdobně může být někde Internet provozován na komunikačním rozhraní, o němž se v dokumentech Internetu ani nehovoří. Proto je zde tato v pořadí čtvrtá popisovaná úroveň brána z hlediska nezbytnosti v Internetu jako tři a půltá.
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.

	Tento článok bol vytlačený zo stránky https://referaty.centrum.sk

Sdělovací kanál