Ji°φ Peterka

Filosofie TCP/IP

Tento Φlßnek vyÜel v poΦφtaΦov²ch novinßch Computerworld Φ. 11/95, v rßmci tzv. tΘmatu t²dne, jako souΦßst sΘrie Φlßnk∙ v∞novan²ch problematice Internetu.

LidΘ, kte°φ navrhovali protokoly TCP/IP, museli ji₧ na zaΦßtku svΘ prßce uΦinit mnoho koncepΦnφch rozhodnutφ, jejich₧ d∙sledky se v plnΘ mφ°e projevujφ dodnes. Mnohß z t∞chto rozhodnutφ p°itom byla diametrßln∞ odliÜnß od t∞ch, kterß ve stejnΘm kontextu p°ijali tv∙rci referenΦnφho modelu ISO/OSI - co₧ nßsledn∞ v²znamn²m zp∙sobem ovlivnilo i "budoucnost" p°φsluÜn²ch protokol∙. M∙₧eme-li p°ijatß rozhodnutφ hodnotit s dneÜnφm odstupem cca 15 let, pak zkuÜenosti dßvajφ celkem jednoznaΦn∞ za pravdu autor∙m protokol∙ TCP/IP. S jedinou v²hradou - ₧e nedokßzali sprßvn∞ docenit mφru svΘho ·sp∞chu. Tedy ₧e nepoΦφtali s tφm, ₧e protokoly TCP/IP bude chtφt pou₧φvat takovΘ obrovskΘ mno₧stvφ sφtφ, kter²m bude t°eba p°id∞lit jednoznaΦnΘ adresy. Mechanismus adresovßnφ, kter² auto°i protokol∙ TCP/IP vymysleli, toti₧ nenφ dostateΦn∞ "nafukovacφ", a p°i dneÜnφch obrovsk²ch rozm∞rech Internetu zaΦφnß b²t ·zk²m mφstem. Ale k tomu se dostaneme v nßsledujφcφm Φlßnku.

Jednotnß pokliΦka nad p°enosovou Φßstφ sφt∞

┌kolem vrstvy sφ¥ovΘho rozhranφ je zajistit p°enos blok∙ dat (v∞tÜinou oznaΦovan²ch jako rßmce, angl. frames) mezi sousednφmi poΦφtaΦi - tedy mezi dv∞ma poΦφtaΦi, kterΘ spolu majφ p°φmΘ spojenφ. Nikoli ji₧ takov² p°enos, kter² musφ p°echßzet p°es n∞jakou "p°estupnφ stanici", co₧ mß na starosti a₧ bezprost°edn∞ vyÜÜφ vrstva. V prost°edφ lokßlnφch poΦφtaΦov²ch sφtφ (sφtφ LAN) do vrstvy sφ¥ovΘho rozhranφ spadajφ nap°φklad technologie Ethernet, Token Ring nebo ARCnet, FDDI, 100 VG AnyLAN, a do budoucna sem z°ejm∞ bude stßle vφce pronikat i technologie ATM (Asynchronous Transfer Mode). SkuteΦnost, ₧e protokoly TCP/IP vrstvu sφ¥ovΘho rozhranφ nijak nepokr²vajφ znamenß, ₧e se nesna₧φ p°edepisovat pou₧itφ ₧ßdnΘ konkrΘtnφ p°enosovΘ technologie, nato₧ pak n∞jakΘ svΘ vlastnφ. O co se naopak sna₧φ, je efektivn∞ vyu₧φt to, co ji₧ na tΘto ·rovni existuje a osv∞dΦilo se.

Otßzkou ovÜem je, jak²m zp∙sobem majφ protokoly TCP/IP vyu₧φvat p°enosovΘ mechanismy na ·rovni vrstvy sφ¥ovΘho rozhranφ. JednotlivΘ technologie, kterΘ na tΘto ·rovni p°ipadajφ v ·vahu, se toti₧ mohou i dosti v²razn∞ liÜit. Nap°φklad v tom, jak² formßt adres pou₧φvajφ, jak velkΘ bloky (rßmce) dokß₧φ p°enßÜet najednou, zda umo₧≥ujφ p°enos od jednoho zdroje k vφce p°φjemc∙m, zda p°enos funguje na spojovanΘm Φi nespojovanΘm principu, neboli zda p°ed ka₧d²m p°enosem dat p°edpoklßdß nejprve navßzßnφ spojenφ, Φi nikoli. Zdaleka nejv²znamn∞jÜφm rozdφlem je pak relativnφ spolehlivost p°enosov²ch cest, kterß b²vß diametrßln∞ odliÜnß u lokßlnφch sφtφ a u sφtφ rozlehl²ch. Celß zßle₧itost pak nabyla jeÜt∞ vφce na v²znamu v okam₧iku, kdy si auto°i protokol∙ TCP/IP sami p°edsevzali, ₧e budou zcela programov∞ vychßzet vst°φc mo₧nosti vzßjemnΘho propojovßnφ i dosti r∙znorod²ch sφtφ, s odliÜn²mi p°enosov²mi technologiemi.

Na v²b∞r byly dv∞ varianty - bu∩to zakr²t veÜkerΘ odliÜnosti jednotliv²ch dφlΦφch sφtφ, nebo je naopak nezakr²vat. Nakonec se auto°i rozhodli pro prvnφ variantu, neboli pro p°ekrytφ vÜech p°enosov²ch technologiφ a vlastnostφ pou₧it²ch p°enosov²ch cest jednotnou "pokliΦkou", kterß zcela zßm∞rn∞ zahladφ veÜkerß specifika a p°φpadnΘ odliÜnosti jednotliv²ch dφlΦφch sφtφ, a vyÜÜφm vrstvßm bude p°edklßdat jednotnou vizi p°enosovΘ Φßsti sφt∞ jako zcela homogennφ soustavy vzßjemn∞ propojen²ch dφlΦφch sφtφ. To na jednΘ stran∞ v²razn∞ zjednoduÜilo nßvrh konkrΘtnφch protokol∙ pro tyto vyÜÜφ vrstvy, ale na druhΘ stran∞ se jednotnß "pokliΦka" zcela zßkonit∞ stala zdrojem urΦitΘ neefektivnosti.

Jakou pokliΦku zvolit?

Auto°i protokol∙ TCP/IP se nakonec rozhodli pro takov² zp∙sob fungovßnφ jednotnΘ "pokliΦky", kter² bude poskytovat pouze tzv. nespolehliv² p°enos. Tomu je t°eba rozum∞t tak, ₧e p°enosovΘ mechanismy sice budou usilovat o bezchybn² p°enos, ale jakmile v n∞jakΘm konkrΘtnφm p°φpad∞ zjistφ ₧e se to nepoda°ilo, nebudou se samy starat o nßpravu. Mφsto toho budou p°edpoklßdat, ₧e o nßpravu se postarß n∞kdo jin² - konkrΘtn∞ protokoly vyÜÜφch vrstev.

ZajφmavΘ je, ₧e auto°i protokol∙ ISO/OSI p°i obdobnΘm rozhodovßnφ zvolili variantu p°esn∞ opaΦnou: doÜli k zßv∞ru, ₧e bude v²hodn∞jÜφ, kdy₧ se o nßpravu chyb p°i p°enosu postarß ji₧ ta vrstva, na kterΘ k chyb∞ doÜlo, resp. kterß chybu detekovala. ProblΘm je ovÜem v tom, ₧e oÜet°enφ chyb a zajiÜt∞nφ spolehlivosti p°enosu je v₧dy spojeno s urΦitou re₧iφ, p°ipadajφcφ zejmΘna na opakovßnφ p°enosu t∞ch dat, kterΘ se p°edtφm p°enesly chybn∞. Podle p°edstavy autor∙ ISO/OSI si spolehlivost zajiÜ¥uje ka₧dß vrstva znovu, a p°φsluÜnß re₧ie se tudφ₧ nßsobφ n-krßt. Naopak v p°φpad∞ protokol∙ TCP/IP se spolehlivost zajiÜ¥uje jen na ·rovni jednΘ (vyÜÜφ) vrstvy, a odpovφdajφcφ re₧ie se tedy uplat≥uje jen 1-krßt. Navφc pouze v p°φpad∞, kdy je spolehlivost skuteΦn∞ po₧adovßna - co₧ nemusφ b²t v₧dy a za vÜech okolnostφ, jak pozd∞ji uvidφme. Dφky tomu dokß₧e °eÜenφ, zvolenΘ v p°φpad∞ TCP/IP, efektivn∞ji vyu₧φvat p°enosov²ch schopnostφ tΘ p°enosovΘ technologie, kterß je k dispozici.

Pokud jde o rozhodnutφ, zda p°ed ka₧d²m p°enosem mß b²t navazovßno spojenφ mezi p°φjemcem a odesilatelem, i zde se p°edstavy tv∙rc∙ TCP/IP a ISO/OSI rozeÜly opaΦn²m sm∞rem. Lze to vysv∞tlit takΘ tφm, ₧e auto°i protokol∙ ISO/OSI m∞li blφzko ke spoj∙m a telekomunikacφm, kterΘ fungujφ na spojovanΘm principu (tj. na principu navazovßnφ spojenφ p°ed p°φpadn²m p°enosem), a rozhodli se pro stejnΘ °eÜenφ i pro pot°eby datov²ch p°enos∙. Naproti tomu tv∙rci protokol∙ TCP/IP doÜli k zßv∞ru, ₧e alespo≥ na ·rovni jednotnΘ "pokliΦky" je v²hodn∞jÜφ nespojovan² charakter p°enosu, nepoΦφtajφcφ s ₧ßdn²m navazovßnφm spojenφ. Ten se toti₧ dokß₧e mnohem snßze adaptovat na p°φpadnΘ dynamickΘ zm∞ny v topologii sφt∞.

Protokol IP

KonkrΘtnφm ·kolem protokolu IP je p°enos blok∙ dat, na ·rovni sφ¥ovΘ vrstvy oznaΦovan²ch ji₧ jako pakety (packets). Protokol IP to d∞lß tak, ₧e zajiÜ¥uje nespolehliv² p°enos (ve v²Üe uvedenΘm smyslu) a pracuje na nespojovanΘm principu - v tΘto souvislosti se takΘ °φkß, ₧e poskytuje tzv. datagramovou slu₧bu. DalÜφm v²znamn²m ·kolem protokolu IP je zajiÜ¥ovat jednotn² zp∙sob adresovßnφ jednotliv²ch uzl∙ i cel²ch sφtφ, prost°ednictvφm tzv. IP adres (podrobn∞ji viz nßsledujφcφ Φlßnek).

Praktickou nßplnφ prßce protokolu IP je doruΦovßnφ p°enßÜen²ch dat (paket∙) od jejich odesilatele a₧ k jejich koncovΘmu adresßtovi - i kdyby to m∞lo znamenat jejich postupn² "p°estup" p°es p°φpadnΘ mezilehlΘ uzly. Jak tomuto sprßvn∞ rozum∞t?

V p°edchßzejφcφm odstavci jsme si °ekli, ₧e p°enosovß technologie na bezprost°edn∞ ni₧Üφ vrstv∞ (vrstv∞ sφ¥ovΘho rozhranφ) dokß₧e p°enßÜet data jen mezi dv∞ma poΦφtaΦi, kterΘ spolu majφ p°φmΘ spojenφ. Je to dßno mj. i tφm, ₧e tato vrstva (vrstva sφ¥ovΘho rozhranφ) nemß ₧ßdnΘ informace o skuteΦnΘ topologii danΘ sφt∞ a celΘ soustavy dalÜφch sφtφ, se kter²mi m∙₧e b²t danß sφ¥ propojena. Ostatn∞, ani by nebylo rozumnΘ jφ takovou informaci vnucovat, proto₧e p°i vzßjemnΘm propojenφ dφlΦφch sφtφ s r∙zn²mi p°enosov²mi technologiemi (nap°. p°i vzßjemnΘm propojenφ Ethernetovsk²ch sφtφ se sφt∞mi Token Ring, s rozlehl²mi sφt∞mi atd.) by dochßzelo k mφchßnφ r∙zn²ch zp∙sob∙ adresovßnφ, r∙zn²ch princip∙ a mechanism∙ p°enosu, r∙zn²ch pohled∙ na topologii sφt∞ atd. Proto je vhodnΘ poskytnout informaci o skuteΦnΘ topologii celΘ soustavy vzßjemn∞ propojen²ch sφtφ a₧ zmφn∞nΘ "pokliΦce", kterß vytvß°φ jednotn² pohled na vÜechny dφlΦφ sφt∞. Teprve od tΘto pokliΦky (p°esn∞ji od protokolu IP) pak mß smysl po₧adovat, aby dokßzala najφt cestu mezi kter²mikoli dv∞ma uzly, i kdy₧ spolu nemajφ p°φmΘ spojenφ.

Protokol IP tedy musφ mφt k dispozici dostateΦnou informaci o skuteΦnΘ topologii danΘ sφt∞ i vÜech ostatnφch sφtφ, se kter²mi je danß sφ¥ spojena. Kdy₧ pak mß zajistit p°enos n∞jakΘho konkrΘtnφho paketu k urΦitΘmu adresßtovi, musφ uΦinit d∙le₧itΘ rozhodnutφ - nenφ-li koncov² adresßt v p°φmΘm dosahu (v dosahu p°φmΘho spojenφ z odesφlajφcφm uzlem), pak ze vÜech p°φmo dosa₧iteln²ch uzl∙ musφ protokol IP zvolit takov², kter² by mohl nejlΘpe poslou₧it jako p°estupnφ uzel, p°es kter² by bylo mo₧nΘ p°φsluÜn² paket doruΦit. Takov²to p°estupnφ uzel samoz°ejm∞ nemusφ b²t jen jeden, proto₧e cesta ke koncovΘmu adresßtovi m∙₧e vΘst postupn∞ p°es n∞kolik p°estupnφch uzl∙.

Rozhodovßnφ o cestßch, po kter²ch majφ b²t pakety p°enßÜeny, se oznaΦuje jako tzv. sm∞rovßnφ (anglicky: routing). Vzhledem k tomu, ₧e protokol IP zajiÜ¥uje p°enos paket∙ na nespojovanΘm (connectionless) principu, sm∞ruje ka₧d² paket v ka₧dΘm p°estupnφm uzly v₧dy znovu a samostatn∞ - tj. v ka₧dΘm uzlu se pro ka₧d² paket v₧dy znovu rozhoduje, kter²m sm∞rem jej mß odeslat dßl. Dφky tomu se pak protokol IP dokß₧e snadno vyrovnat s dynamick²mi zm∞nami topologie sφtφ - nap°φklad s tφm, ₧e urΦit² spoj vypadne Φi stane se z jinΘho d∙vodu nepr∙chodn²m. Protokol IP pak jednoduÜe posφlß dalÜφ pakety jinou cestou.

DalÜφ protokoly sφ¥ovΘ vrstvy

Bylo by takΘ chybou p°edstavovat si, ₧e protokol IP n∞jakß data skuteΦn∞ (tj. "fyzicky") p°enßÜφ. SkuteΦnost je takovß, ₧e jakmile v rßmci urΦitΘho (odesφlajφcφho) uzlu uΦinφ protokol IP pot°ebnΘ rozhodnutφ o sm∞ru, kter²m mß b²t paket vyslßn, p°edß jej bezprost°edn∞ ni₧Üφ vrstv∞ (vrstv∞ sφ¥ovΘho rozhranφ) k vlastnφmu odeslßnφ. Teprve tato vrstva pak zabezpeΦφ p°enos paketu ("zabalenΘho" do p°enosovΘho rßmce) takov²m zp∙sobem, pro jak² je uzp∙sobena. KoneΦn² cφl p°enßÜenΘho paketu tuto vrstvu v∙bec nezajφmß - na druhΘ stran∞ p°φmΘho spoje je rßmec p°ijat, je vybalen v n∞m obsa₧en² paket, a ten je p°edßn zdejÜφmu protokolu IP. Teprve ten pak znovu rozhoduje o tom, kudy dßl mß b²t paket odeslßn, aby se nakonec dostal ke svΘmu skuteΦnΘmu adresßtovi.

Celß v∞c mß ale jeden mal² technick² hßΦek: protokol IP se p°i svΘm rozhodovßnφ o volb∞ dalÜφho sm∞ru p°enosu (p°i tzv. sm∞rovßnφ) rozhoduje podle jednotn²ch adres, tzv. IP adres. Dojde-li vÜak k zßv∞ru, ₧e urΦit² paket mß b²t odeslßn nap°. uzlu s IP adresou X.Y.Z.W, nem∙₧e se jednoduÜe obrßtit na vrstvu sφ¥ovΘho rozhranφ s po₧adavkem "odeÜli tento paket uzlu X.Y.Z.W.". ProblΘm je v tom, ₧e vrstva sφ¥ovΘho rozhranφ jednotn²m IP adresßm nerozumφ. Rozumφ pouze takov²m adresßm, s jak²mi pracuje konkrΘtnφ p°enosov² mechanismus, pou₧it² na ·rovni tΘto vrstvy - v p°φpad∞ Ethernetov²ch sφtφ jde o 48-bitovΘ EthernetovΘ adresy, v p°φpad∞ ARCnetu o 8-bitovΘ ARCnetovΘ adresy apod.

Protokol IP tedy musφ b²t schopen p°evßd∞t tzv. IP adresy (kterΘ jsou ve svΘ podstat∞ pouhou abstrakcφ) na r∙znΘ druhy konkrΘtnφch fyzick²ch adres. Op∞t je v principu mo₧nΘ poskytnout mu p°edem vypln∞nou "p°evodnφ tabulku", kterou pak bude pou₧φvat. V praxi se ale Φast∞ji pou₧φvß jinΘ °eÜenφ, kterΘ umo₧≥uje p°evßd∞t jednotlivΘ druhy adres mezi sebou dynamick²m zp∙sobem.

SouΦßstφ rodiny protokol∙ TCP/IP je takΘ protokol ARP (Address Resolution Protocol), kter² umo₧≥uje p°evßd∞t IP adresy na adresy fyzickΘ. P°i jistΘm zjednoduÜenφ si m∙₧eme p°edstavit, ₧e se v₧dy obrßtφ na vÜechny uzly ve svΘm dosahu s dotazem: "kdo z vßs mß IP adresu X.Y.Z.W?". Uzel, kterΘho se to t²kß, by na takovouto v²zvu m∞l reagovat, a v rßmci odpov∞di sd∞lit tazateli svou fyzickou adresu. VÜe je p°itom zalo₧eno na mo₧nosti oslovit vÜechny uzly souΦasn∞ (v rßmci tzv. vÜesm∞rovΘho vysφlßnφ, angl. broadcasting), prost°ednictvφm jednΘ specißlnφ fyzickΘ adresy (kterß je p°edem znßma).

NßÜ v²Φet protokol∙, kterΘ jsou souΦßstφ rodiny protokol∙ TCP/IP a pat°φ do sφ¥ovΘ vrstvy, vÜak u protokol∙ IP a ARP jeÜt∞ zdaleka nekonΦφ. Do sφ¥ovΘ vrstvy bychom m∞li za°adit nap°. protokol RARP (Reverse ARP), kter² si m∙₧eme p°edstavit jako p°esn² protip≤l protokolu ARP: konkrΘtnφmu uzlu, kter² neznß svou IP adresu, umo₧≥uje zjisti si ji (tak, ₧e op∞t "do Θteru" vznese dotaz, ze kterΘho je patrnß jeho fyzickß adresa). Ke stejnΘmu ·Φelu, tedy k zφskßnφ odpovφdajφcφ IP adresy na zßklad∞ adresy fyzickΘ, pak slou₧φ dalÜφ protokol sφ¥ovΘ vrstvy, protokol BOOTP.

Zajφmav²m protokolem je protokol ICMP (Internet Control Message Protocol). Ten je mo₧nΘ pova₧ovat za mechanismus, vytvß°ejφcφ jak²si "slu₧ebnφ kanßl". Tφm mohou protΘkat nejr∙zn∞jÜφ zprßvy a hlßÜenφ o nestandardnφch a chybov²ch situacφch, na kterΘ je t°eba reagovat.

Pro pot°eby p°ipojovßnφ u₧ivatel∙ k Internetu pak majφ doslova klφΦov² v²znam dva novΘ protokoly, SLIP a PPP, kterΘ umo₧≥ujφ p°enßÜet IP pakety i po sΘriov²ch linkßch, vΦetn∞ komutovan²ch linek ve°ejnΘ telefonnφ sφt∞. T∞mto dv∞ma protokol∙m je v∞novßn samostatn² Φlßnek.

Transportnφ vrstva

Sφ¥ovß vrstva a protokol IP mohly jeÜt∞ vychßzet z p°edstavy, ₧e p°ijemci i odesilateli veÜker²ch dat jsou uzly poΦφtaΦov²ch sφtφ jako takovΘ, a ₧e tyto uzly nejsou nijak dßle d∞litelnΘ. Tomu ostatn∞ odpovφdala i logika adres, pou₧φvan²ch na ·rovni sφ¥ovΘ vrstvy, neboli IP adres: ka₧dß jednotlivß IP adresa identifikovala uzel jako celek. Ve skuteΦnosti ale na ka₧dΘm uzlu b²vß vφce potencißlnφch p°φjemc∙ a odesilatel∙ dat - vφce systΘmov²ch program∙, vφce aplikacφ - a to dokonce i v p°φpad∞, kdy nejde ani o vφceu₧ivatelsk² poΦφtaΦ, a dokonce ani o poΦφtaΦ s vφce·lohov²m operaΦnφm systΘmem. ┌kol rozliÜovat tyto samostatnΘ p°φjemce a odesilatele pat°φ a₧ transportnφ vrstv∞.

Transportnφ vrstva samoz°ejm∞ pot°ebuje vhodn² mechanismus, prost°ednictvφm kterΘho by dokßzala identifikovat r∙znΘ odesilatele a p°φjemce dat v rßmci danΘho uzlu. PodstatnΘ je p°itom uv∞domit si, ₧e t∞mito p°φjemci a odesilateli jsou objekty programovΘho charakteru (procesy, ·lohy, programy), nachßzejφcφ se jeÜt∞ "o patro v²Üe" ne₧ vrstva transportnφ, tedy v aplikaΦnφ vrstv∞. KonkrΘtnφ mechanismus, kter² se pro identifikaci t∞chto proces∙ pou₧φvß v rodin∞ protokol∙ TCP/IP, je nejlΘpe si p°edstavit jako soustavu p°echodov²ch bod∙ (bran) na rozhranφ mezi transportnφ vrstvou a bezporst°edn∞ vyÜÜφ aplikaΦnφ vrstvou. Tyto p°echodovΘ body jsou oznaΦovßny Φφsly (Φφseln²mi identifikßtory), a °φkß se jim porty.

Kdy₧ pak n∞jakß aplikace pot°ebuje odeslat urΦitß data jinΘ aplikaci na n∞kterΘm jinΘm uzlu sφt∞, p°edß je k odeslßnφ transportnφ vrstv∞. P°itom k nim musφ p°idat takΘ informaci o tom, kdo si je mß na druhΘ stran∞ p°evzφt, p°esn∞ji p°es kter² port majφ b²t p°edßny. Transportnφ vrstva odesφlajφcφho uzlu pak p°φsluÜnß data rozd∞lφ do tak velk²ch Φßstφ, jakΘ je mo₧nΘ p°enßÜet najednou (jakΘ je na ·rovni sφ¥ovΘ vrstvy mo₧nΘ vlo₧it do paket∙ protokolu IP), a p°idß k nim ·daje o Φφsle portu odesilatele i p°φjemce, a vÜe odeÜle (ve skuteΦnosti: p°edß k odeslßnφ svΘ bezprost°edn∞ ni₧Üφ vrstv∞, tj. vrstv∞ sφ¥ovΘ). Na stran∞ koncovΘho p°φjemce se pak p°φsluÜnß data dostanou analogick²m postupem a₧ k tamnφ transportnφ vrstv∞. Ta si z nich "vybalφ" ·daj o Φφsle portu na stran∞ p°φjemce, a podle n∞j pak vlastnφ data p°edß p°φsluÜnΘmu p°φjemci v rßmci svΘ aplikaΦnφ vrstvy.

Zde je dobrΘ si jeÜt∞ uv∞domit, ₧e Φφsla port∙ nejsou jednoznaΦnou identifikacφ proces∙, ·loh Φi program∙, b∞₧φcφch na ·provni aplikaΦnφ vrstvy. To by ostatn∞ bylo i dosti obtφ₧n∞ realizovatelnΘ, nebo¥ tyto programovΘ objekty mohou dynamicky vznikat a zase zanikat. JednotlivΘ porty je skuteΦn∞ t°eba chßpat jen jako p°echodovΘ body, nezßvislΘ na konkrΘtnφch procesech. Ty se mohou dynamicky "p°ipojovat" k jednotliv²m port∙m a p°ijφmat vÜe, co je t∞mto port∙m adresovßno. Je-li to za°φzeno prßv∞ takto, pak je nap°φklad mo₧nΘ, aby existovalo n∞kolik tzv. dob°e znßm²ch port∙ (well-known ports), s p°edem pevn∞ dan²mi Φφsly, kter²m mohou b²t z jin²ch uzl∙ adresovßny po₧adavky na poskytnutφ urΦit²ch konkrΘtnφch slu₧eb. Kter² konkrΘtnφ systΘmov² proces, ·loha Φi program je ve skuteΦnosti p°ijφmß skrz p°φsluÜn² port, je zßvislΘ na momentßlnφ situaci, ale pro ₧adatele (odesilatele) to ji₧ nenφ relevantnφ.

Protokoly TCP a UDP

Takov²to zp∙sob p°enosu, jak² nabφzφ sφ¥ovß vrstva a protokol IP, vÜak nemusφ v₧dy vyhovovat. M∙₧e, ale nemusφ. N∞kterΘ aplikaci p°φliÜ nezßle₧φ na rychlosti, ale naopak by jφ siln∞ vadilo, kdyby dostßvala jakkoli poÜkozenß Φi pozm∞n∞nß data. P°φkladem m∙₧e b²t elektronickß poÜta, p°enos soubor∙, vzdßlenΘ p°ihlaÜovßnφ apod. JinΘ aplikace naopak preferujφ maximßlnφ mo₧nou rychlost, a kv∙li nφ se dokß₧φ smφ°it i s tφm, ₧e obΦas dostanou pon∞kud poÜkozenß data. JakΘ aplikace to mohou b²t? Nejsna₧Üφ je z°ejm∞ p°edstavit si n∞kterou dneÜnφ multimedißlnφ aplikaci, nap°φklad videokonference, resp. p°enos obrazu. Zde je jist∞ p°ijateln∞jÜφ, kdy₧ Φas od Φasu bude n∞kter² snφmek mφt urΦit² "kaz", zp∙soben² chybou v p°enßÜen²ch datech, ale jednotlivΘ snφmky na sebe budou navazovat konstantnφ rychlostφ. Kdyby ale takovßto aplikace trvala na tom, ₧e chce dostßvat jen nepoÜkozenß data, a vy₧adovala tedy spolehliv² zp∙sob p°enosu dat, dostßvala by jednotlivΘ snφmky s r∙zn²mi Φasov²mi odstupy - proto₧e opravn² mechanismus by musel zajiÜ¥ovat opakovan² p°enos n∞kter²ch Φßstφ dat. Pro divßka by to pak bylo stejnΘ, jako kdyby mu n∞kdo promφtal film, a neustßle m∞nil rychlost posunu filmovΘho pßsu.

Auto°i protokol∙ TCP/IP vÜak naÜli jeÜt∞ jeden velmi pßdn² argument pro svΘ uva₧ovßnφ. Uv∞domili si toti₧, ₧e n∞kterΘ aplikace si stejn∞ budou chtφt zajistit spolehlivost p°enosu samy (tj. na ·rovni aplikaΦnφ vrstvy), a ₧e by tedy bylo zbyteΦnΘ jim zajiÜt∞nφ spolehlivosti vnucovat znovu i na ·rovni transportnφ vrstvy. Zde je dobrΘ si uv∞domit, ₧e p°φvlastek "spolehliv²" je v₧dy relativnφ, a nikoli absolutnφ. Neexistuje toti₧ ₧ßdn² mechanismus, kter² by dokßzal s absolutnφ spolehlivostφ rozpoznat, zda v p°enesen²ch datech doÜlo k chyb∞ Φi nikoli. Existuje sice celß °ada takov²chto detekΦnφch mechanism∙, ale ka₧d² z nich funguje jen s urΦitou mφrou p°esnosti a spolehlivosti. Sice hodn∞ vysokou, ale nikdy ne stoprocentnφ. Je pak na koncovΘ aplikaci, resp. na koncovΘm p°φjemci, aby si rozhodl, zda mu mφra poskytovanΘ spolehlivosti postaΦuje, Φi nikoli. Zcela jinak asi bude vypadat p°φsluÜnΘ rozhodnutφ nap°φklad u bankovnφch aplikacφ, kterΘ zajiÜ¥ujφ p°evody z ·Φt∙ a ·Φet, a zcela jinak u aplikacφ, kterΘ sbφrajφ ·daje o poΦasφ.

Tv∙rci protokol∙ TCP/IP proto dosp∞li k velmi rozumnΘmu zßv∞ru: umo₧nit ka₧dΘ aplikaci, a¥ si vybere sama. Tedy ponechat jφ volbu mezi tφm, zda chce vyu₧φvat rychlejÜφ, ale zato nespolehlivΘ p°enosovΘ slu₧by (a p°φpadnou spolehlivost si zajiÜ¥ovat sama), nebo zda rad∞ji vyu₧ije pomalejÜφ, ale zato spolehliv² relativn∞ spolehliv² zp∙sb p°enosu (a akceptuje mφru jeho spolehlivosti). V praxi toto znamenalo, ₧e tv∙rci protokol∙ museli "zabydlet" transportnφ vrstvu dv∞ma transportnφmi protokoly: jednφm, kter² bude spφÜe jednoduchou obßlkou nad protokolem IP sφ¥ovΘ vrstvy, a k jeho funkΦnosti bude p°idßvat prakticky jen schopnost rozd∞lovat data podle Φφsel port∙ mezi jednotlivΘ adresßty, a koneΦn∞ druh²m, kter² ji₧ bude v²razn∞ji m∞nit vlastnosti protokolu IP, a bude zajiÜ¥ovat spolehliv² p°enos. Prvnφm z t∞chto dvou protokol∙ je protokol UDP (User Daragram Protocol), a druh²m protokol TCP (Transport Control Protocol).

Na protokolu TCP, kter² spolu s protokolem IP dal celΘ rodin∞ porotokol∙ i jmΘno, je podstanΘ takΘ to, ₧e krom∞ zavßd∞nφ spolehlivosti m∞nφ i nespojovan² zp∙sob p°enosu (kter² pou₧φvß protokol IP) na spojovan². Neboli ₧e p°ed zahßjenφm ka₧dΘho p°enosu navazuje spojenφ mezi odesilatelem a p°φjemcem, a pak veÜkerß data p°enßÜφ v rßmci takto navßzanΘho spojenφ.

Jednou pro vÜechny, nebo pro ka₧dΘho v₧dy znovu?

Samoz°ejm∞ existujφ takovΘ techniky a metody, kterΘ prßv∞ popsan² problΘm dokß₧φ °eÜit. Nap°φklad tak, ₧e jeÜt∞ p°ed odeslßnφm zajistφ konverzi dat do takovΘho formßtu, jakΘmu "rozumφ" p°φjemce. Nebo jinak - p°enßÜenß data se p°ed p°enosem p°evedou do jednotnΘho univerzßlnφho "mezitvaru", ke kterΘmu se jeÜt∞ p°ipojφ podrobn∞jÜφ popis v²znamu dat. D∙le₧itß je ovÜem jinß otßzka: mß si tyto mechanismy implementovat a₧ ten, kdo je skuteΦn∞ pot°ebuje? S potencißlnφm nebezpeΦφm, ₧e kdy₧ je bude pot°ebovat vφce r∙zn²ch protokol∙ vyÜÜφch vrstev (p°esn∞ji: aplikaΦnφ vrstvy), budou muset b²t implementovßny vφcekrßt! Nebo je rozumn∞jÜφ je implementovat jen jednou takov²m zp∙sobem, aby mohly slou₧it spoleΦn∞ vÜem potencißlnφm zßjemc∙m - s nebezpeΦφm toho, ₧e je nebude chtφt vyu₧φvat nikdo?

V odpov∞di na tuto zajφmavou otßzku se auto°i protokol∙ TCP/IP op∞t zßsadn∞ rozeÜli s autory referenΦnφho modelu ISO/OSI. Auto°i TCP/IP se p°iklonili k zßsad∞ "kdo to chce, a¥ si to implementuje sßm". V d∙sledku toho pak ji₧ nad transportnφ vrstvou nepot°ebovali ₧ßdnou dalÜφ vrstvu, ne₧ vrstvu aplikaΦnφ, ve kterΘ jsou soust°ed∞ny zßkladnφ Φßsti aplikaΦnφch protokol∙. Naproti tomu tv∙rci referenΦnφho modelu se rozhodli implementovat zmφn∞nΘ mechanismy bez ohledu na to, zda jsou skuteΦn∞ pot°eba. Pak jim ale vyÜlo, ₧e nad transportnφ vrstvou (koncipovanou obdobn∞ jako u protokolu TCP/IP) pot°ebujφ hned dv∞ dalÜφ vrstvy - vrstvu relaΦnφ (session layer) a vrstvu prezentaΦnφ (presentation layer). A to je dalÜφ v²razn² rozdφl mezi ob∞ma sφ¥ov²mi koncepcemi.

Kam pat°φ aplikace?

Jist∞ nenφ t°eba zd∙raz≥ovat, ₧e u₧ivatele zajφmajφ p°edevÜφm aplikace, a mΘn∞ ji₧ "to, co je vespod". Bylo by ovÜem chybou domnφvat se, ₧e aplikace je to, co je provozovßno na ·rovni aplikaΦnφ vrstvy, nebo obrßcen∞ ₧e "aplikaΦnφ vrstvu je to, kde jsou provozovßny aplikace". ProblΘm je toti₧ v tom, ₧e kdy₧ n∞co spadß do urΦitΘ vrstvy sφ¥ovΘho modelu, m∞lo by to b²t standardizovßno - neboli pokryto standardy, kterΘ p°esn∞ °φkajφ, jak mß co pracovat, fungovat atd. A sem by m∞la pat°it nap°φklad grafickß u₧ivatelskß rozhranφ Φi konkrΘtnφ "obrazovky" jednotliv²ch aplikacφ? Pokud ano, musely by se vÜechny aplikace na svΘ u₧ivatele "tvß°it" stejn∞, mφt naprosto stejnΘ vlastnosti, funkce, i sv∙j celkov² "image".

Standardizovat tφmto zp∙sobem vÜechny aplikace nenφ ·nosnΘ (ji₧ jen kv∙li objemu prßce, kter² by to vy₧adovala), a dokonce ani ₧ßdoucφ. Na druhΘ stran∞ je ale urΦitß mφra standardizace nezbytnß - majφ-li si vzßjemn∞ rozum∞t nap°φklad dv∞ aplikace pro elektronickou poÜtu, musφ se shodnout na p°esnΘm formßtu zprßv, kterΘ si budou p°edßvat, na konkrΘtnφm mechanismu p°enosu t∞chto zprßv atd. Na Φem se naopak shodnout nemusφ, je u₧ivatelskΘ rozhranφ, kterΘ budou sv²m u₧ivatel∙m vytvß°et - jedna aplikace m∙₧e nabφzet jen velmi strohΘ, znakov∞ orientovanΘ u₧ivatelskΘ rozhranφ v prost°edφ MS DOSu, zatφmco druhß m∙₧e poskytovat pln∞ komfortnφ grafickΘ rozhranφ v prost°edφ MS Windows, se vÜemi obvykl²mi "okennφmi vymo₧enostmi".

V²sledn²m efektem je pak skuteΦnost, ₧e do aplikaΦnφ vrstvy se za°azujφ pouze Φßsti aplikacφ - ty, kterΘ je ₧ßdoucφ standardizovat - zatφmco zb²vajφcφ Φßsti aplikacφ (kterΘ naopak nemß smysl svazovat p°φpadnou standardizacφ) se vysouvajφ nad aplikaΦnφ vrstvu. I dφky tomu je pak mo₧nΘ, aby si v prost°edφ poΦφtaΦovΘ sφt∞ navzßjem rozum∞ly a dokßzaly spolupracovat aplikace, pochßzejφcφ od r∙zn²ch v²robc∙, provozovanΘ na r∙zn²ch typech poΦφtaΦ∙, v prost°edφ r∙zn²ch operaΦnφch systΘm∙ apod. Snad nejmarkantn∞jÜφ je to prßv∞ v citovanΘm p°φpad∞ elektronickΘ poÜty, ale totΘ₧ platφ v zßsad∞ pro jak²koli druh aplikace.

Inventura aplikacφ

Existuje samoz°ejm∞ urΦitß mno₧ina aplikacφ, kterΘ ji₧ majφ svou standardizaci ·sp∞Ün∞ za sebou. N∞kter²mi z nich se budeme zab²vat podrobn∞ji v dalÜφch tΘmatech t²dne o Internetu, zatφmco pro jinΘ nßm v∙bec nezbyde prostor. Na tomto mφst∞ si proto ud∞lejme jen malou inventuru zßkladnφch aplikacφ, kterΘ jsou nejΦast∞ji provozovßny v prost°edφ TCP/IP sφtφ obecn∞ a v Internetu konkrΘtn∞, a vyjmenujme si protokoly a standardy, kterΘ byly pro tyto aplikace vyvinuty:

• elektronickß poÜta (electronic mail): pro elektronickou poÜtu existujφ dva relevantnφ standardy: prvnφ z nich se obvykle oznaΦuje jako RFC822 (podle dokumentu Request For Comment s po°adov²m Φφslem 822), a definuje zßkladnφ formßt zprßv, p°enßÜen²ch elektronickou poÜtou, vΦetn∞ formßtu pou₧φvan²ch elektronick²ch adres. Druh² standard definuje protokol, pou₧φvan² pro vlastnφ p°enos jednotliv²ch zprßv. Tφmto protokolem je protokol SMTP (Simple Mail Transfer Protocol), podle kterΘho je takΘ el. poÜta v rßmci TCP/IP sφtφ neformßln∞ oznaΦovßna - jako SMTP poÜta, SMTP-kompatibilnφ poÜta apod. UrΦitou nev²hodou t∞chto dvou standard∙ je skuteΦnost, ₧e jsou Üity na mφru pot°eb∞ p°enßÜet textovΘ zprßvy, nejspφÜe jen v angliΦtin∞ - nepamatujφ ani na mo₧nost p°enosu znak∙ v nßropdnφch abecedßch, ani mo₧nost p°enosu binßrnφch soubor∙ elektronickou poÜtou (nap°φkladve form∞ p°φlohy). Pro tento ·Φel byl v nedßvnΘ dob∞ vyvinut standard MIME (Multipurpose Internet Mail Extension), kter² ji₧ umo₧≥uje p°enßÜet elektrnickou poÜtou jak texty v nejr∙zn∞jÜφch nßrodnφch abecedßch, tak i vÜelijakΘ druhy p°φloh - nap°φklad zvukovΘ Φi obrazovΘ zßznamy, binßrnφ datovΘ soubory apod. Pro pot°eby p°enosu elektronickΘ poÜty mezi poÜtovnφmi servery a samostatn²mi uzlov²mi poΦφtaΦi byly vytvo°eny dalÜφ protokoly, mj. POP2 a POP3, IMAP2 a IMAP3 a DSMP.
• sφ¥ovΘ news (network news): pro p°enos a distribuci jednotliv²ch p°φsp∞vk∙ sφ¥ov²ch news je mo₧nΘ pou₧φt mnoho r∙zn²ch p°enosov²ch mechanism∙,. V prost°edφ Internetu je doporuΦen²m mechanismem protokol NNTP (Network News Transfer Protocol).
• p°enos soubor∙ (file transfer): pro p°enos soubor∙ se v prost°edφ TCP/IP sφtφ pou₧φvß protokol FTP (File Transfer Protocol). Jde p°itom o tzv. netransparentnφ p°enos, p°i kterΘm musφ u₧ivatel znßt umφst∞nφ a jmΘno souboru, se kter²m chce pracovat.
• sdφlenφ soubor∙ (file sharing): pro pln∞ transparentnφ sdφlenφ soubor∙ se v prost°edφ TCP/IP sφtφ pou₧φvß protokol NFS, p∙vodn∞ vyvinut² firmou Sun Microsystems jako jejφ proprietßrnφ °eÜenφ. PoslΘze vÜak byl tento protokol standardizovßn (formou dokumentu RFC).
• vzdßlenΘ p°ihlaÜovßnφ (remote login): pro pot°eby vzdßlenΘho p°ihlaÜovßnφ v prost°edφ TCP/IP sφtφ je nejΦast∞ji vyu₧φvßn protokol Telnet.
• sprßva sφt∞ (network management): pro tento ·Φel je vyu₧φvßn protokol SNMP (Simple Networek Management Protocol,), kter² v souΦasnΘ dob∞ existuje ji₧ i ve verzi SNMP-2.