Ji°φ Peterka

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.