Současné trendy ve světě protokolů TCP/IP (I.)
Již minule jsme i naznačili, že koncepce protokolů TCP/IP se ukázala být velmi životaschopná, a to i v dlouhodobém výhledu. To, co její autoři vymysleli před více dvaceti lety, v zásadě vydrželo až dodnes, a nemuselo být zásadním způsobem měněno. To samozřejmě neznamená, že ve světě TCP/IP nedocházelo k žádným změnám - ty však měly spíše charakter zdokonalování a doplňování nových a nových funkcí, schopností a vlastností. V současné době, a zejména pak v souvislosti s obrovským rozvojem Internetu, však přeci jen dochází k nemalým tlakům na poněkud podstatnější změny v základech, na kterých stojí svět TCP/IP. Pojďme si stručně naznačit, jaké tlaky to jsou, a jaké změny zřejmě vyvolají.
Místem, kde současná koncepce protokolů TCP/IP snad nejvíce „praská ve švech", je rozsah číselných adres, používaných na úrovni síťové vrstvy, tedy tzv. IP adres. Autoři TCP/IP zvolili pevný rozsah těchto adres (kvůli jednodušší manipulaci s nimi), a to 32 bitů. Ve své době to jistě bylo více než dostatečné, a skýtalo to bohatou rezervu - zvláště když autoři TCP/IP mohli uvažovat nejvýše v měřítku desítek či maximálně stovek sítí, které budou mít zájem propojit se prostřednictvím protokolů TCP/IP. Kdepak by je tehdy napadlo, že díky obrovskému rozmachu Internetu z těchto desítek až stovek relativně velkých sítí budou rázem miliony mnohdy miniaturních sítí a jednotlivých počítačů? Autoři TCP/IP sice počítali s určitou různorodostí připojovaných sítí co do jejich velikosti, a připravili pro ně tři různé formáty IP adres - adresy třídy A pro velmi velké sítě, adresy třídy B pro středně velké sítě, a adresy třídy C pro malé sítě (do 254 počítačů). Konkrétní způsob přidělování IP adres, který z této koncepce vycházel, však nebyl příliš úsporný, a vedl naopak k jistému plýtvání dostupným adresovým prostorem, jednou provždy vymezeným 32-bitovým rozsahem IP adres.
IP adres je málo!
Již na počátku osmdesátých let, v souvislosti s nárůstem zájmu o Internet, se pak začalo rýsovat určité nebezpečí vyčerpání adresového prostoru všech IP adres. S postupem času, rostoucím zájmem o Internet a akcelerujícím čerpáním IP adres pak toto nebezpečí začínalo nabývat na intenzitě. Nikdo však nedokázal exaktně vypočítat, kdy by k úplnému vyčerpání mohlo dojít - pesimistické odhady hrozily apokalypsou málem druhý den, zatímco optimistické odhady sahaly za rok 2000. Přesto se ale všichni shodovali v tom, že jde o nebezpečí se kterým je třeba něco dělat.
Akce, které komunita lidí kolem neustále rostoucího Internetu nakonec podnikla, lze rozdělit do dvou skupin: na opatření směřující k efektivnějšímu hospodaření s IP adresami a ke zpomalení jejich úbytku, a na opatření která by dokázala problém vyřešit skutečně zásadním způsobem. Podívejme se nejprve na první skupinu.
Dočasná řešení: privátní Internety a CIDR
Jedna z možných strategií úspory IP adres vychází z toho, že se dovolí aby různé sítě a uzly měly stejné IP adresy. To je sice za normálních okolností nepřípustné (neboť by to zmátlo mechanismus směrování, který se stará o volbu cest v soustavě vzájemně propojených sítí), ale zde je nežádoucím následkům zabráněno tím, že informace o existenci takovýchto sítí (s ne-unikátními adresami) nejsou šířeny do celého velkého Internetu. Zmíněné sítě, které používají „již použité" IP adresy, jsou ve skutečnosti efektivně schovány před zbytkem světa (za bránami, které obvykle slouží i potřebám zabezpečení, a označují se jako tzv. firewally). Proto se také takto „schovaným" sítím říká privátní Internety.
Dalším významným opatřením na cestě ke zpomalení úbytku IP adres bylo odbourání dosavadního členění IP adres na třídy A, B a C, a jejich přidělování i po jiných jednotkách. Tím se jednak odstranila určitá neefektivnost při přidělování IP adres - například síť s pouhými čtyřmi uzly musela dříve dostat jednu skupinu adres třídy C, neboli 265 jednotlivých IP - a současně s tím se dosáhlo i významného zjednodušení při vlastním směrování (zmenšil se objem informací, které si jednotlivé směrovače musí ke svému fungování pamatovat). Celá strategie dostala jméno CIDR (od: Classless Inter-Domain Routing).
Definitivní řešení: IP verze 6
Cesta k definitivnímu řešení nebyla jednoduchá. Stávající IP adresy jsou totiž tak hluboce „zakořeněny" v dosavadním protokolu IP, že jakákoli změna ve své podstatě znamená vyvinutí zcela nového přenosového protokolu síťové vrstvy. Do jeho hledání se zapojilo mnoho lidí, skupin i celých institucí, a předloženo bylo mnoho variant řešení, často i dosti protichůdných. Po jisté době váhání, úvah a zvažování se nakonec podařilo dospět ke shodě nad jedním konkrétním protokolem, který byl posléze nazván IPv6 (od. Internet Protocol verze 6). Někdy se lze setkat i s označením IPnG (IP next generation), které je však používáno jako generické označení všech uvažovaných variant, ze kterých nakonec vzešla vítězně jen jedna jediná. Důležité přitom je, že tato nová verze protokolu IP místo dosavadních 32 bitů pro jednotlivé adresy již používá 128 bitů, a to by snad mohlo na určitou dobu vystačit. Zajímavé bude spíše sledovat, jak se nový protokol prosadí do praxe - podle prognóz se první implementace měly objevit v polovině letošního roku. Moc o nich slyšet není, ale první vlaštovky se přeci jen objevují. Například firma FTP Software právě uvedla na trh novou verzi programového balíku OnNet, který již nový protokol IPv6 podporuje.
Multimédia a IP nejdou moc dohromady
Další oblastí, ve které dosavadní koncepce protokolů TCP/IP začíná být úzkým místem, je přenos multimédií a provozování aplikací, které mají blízko k fungování v reálném čase. Takovéto aplikace totiž velmi špatně snáší případy, kdy jim jejich data dochází se zpožděním a nepravidelně (jak jsme se o tom již zmiňovali ve třetím dílu tohoto modulu). Nicméně přenosové protokoly TCP/IP, ať již protokol IP na úrovni síťové vrstvy, tak i protokoly TCP a UDP na úrovni transportní vrstvy, nejsou stavěné tak aby vycházely vstříc požadavkům aplikací fungujících v reálném čase. Autoři TCP/IP naopak koncipovali přenosové protokoly s uvážením toho, že budou sloužit potřebám „čistě datových" přenosů, například přenosu souborů, vzdáleného přihlašování, pošty atd., které nemají žádné specifické nároky na pravidelnost přísunu dat a jejich zpoždění, a spíše než rovnoměrnou zátěž způsobují nárazové zatížení sítě.
V současné době ale rychle roste zájem o to, aby se i v TCP/IP sítích (a zejména v Internetu) provozovaly nejrůznější multimediální aplikace a další aplikace fungující v reálném čase. Důvod je zřejmý - když už je k dispozici jedna značně univerzální a dobře fungující infrastruktura (Internet), tak proč ji nevyužít pro všechny druhy přenosů, které uživatele potřebují? Proč by měla být budována a provozována nějaká paralelní infrastruktura pouze pro tyto „nové" aplikace? Řešení se opět hledá ve dvou základních směrech: první je možné přirovnat k „přístupu hrubou silou", a druhé ke koncepčnímu řešení.
„Řešení hrubou silou" spočívá jednak ve zvyšování přenosové kapacity, jednak ve zdokonalování technik komprese dat. Princip fungování přenosové části sítě přitom sice zůstává nezměněn, ale jeho negativní vliv na přenos dat v reálném čase se zmenšuje. Díky tomu se pak na scéně mohly objevit takové aplikace, jako je například dnes tolik oblíbené telefonování po Internetu.
Koncepčním řešením jsou pak nové přenosové protokoly, šité na míru potřebám přenosů v reálném čase. Zde se jedná především o transportní protokol RTP (Real-Time Transport Protocol), který si lze představit jako třetí alternativu ke stávajícím dvěma protokolům transportní vrstvy TCP/IP, tj. k protokolům TCP a UDP (ačkoli sám využívá služeb protokolu UDP, a patřil by tedy spíše až do aplikační vrstvy). K jeho korektnímu fungování je ale nutná i určitá spolupráce přenosové infrastruktury, konkrétně spolupráce jednotlivých směrovačů. Ty totiž už nemohou dávat veškerou dostupnou přenosovou kapacitu „na jednu hromadu" a využívat ji podle momentálních potřeb dle vlastního uvážení. Místo toho musí být schopné rezervovat určitou přenosovou kapacitu pro potřeby přenosů v reálném čase. K tomu účelu musel být vyvinut další nový protokol, jménem RSVP (Resource Reservation Protocol). Oba protokoly (RTP i RSVP) jsou ale velmi čerstvého data (zatím se nachází ve stádiu návrhů standardů), a na jejich skutečné rozšíření do praxe si zřejmě ještě trochu počkáme.