Ji°φ Peterka

Nejprve si ale p°ipome≥me hlavnφ myÜlenky a nejd∙le₧it∞jÜφ v²chozφ p°edpoklady, kterΘ se uplatnily ji₧ p°i nßvrhu ni₧Üφch vrstev TCP/IP. èlo zejmΘna o zßkladnφ princip, kter² by se dal charakterizovat sloganem äspφÜe skromnost, ne₧ bohatost", a kter² dßval p°ednost jednoduÜÜφm, snßze implementovateln²m a mnohdy i efektivn∞jÜφm °eÜenφm. V duchu tohoto principu pak auto°i TCP/IP uΦinili nßsledujφcφ rozhodnutφ:

• na ·rovni sφ¥ovΘ vrstvy dali p°ednost rychlΘmu a robustnφmu p°enosu dat, p°ed p°enosem spolehliv²m. V d∙sledku toho zvolili pro sφ¥ovou vrstvu p°enos nespolehliv² (kter² je rychlejÜφ, proto₧e se nemusφ zdr₧ovat napravovßnφm p°φpadn²ch chyb p°i p°enosech), a souΦasn∞ p°enos nespojovanΘho charakteru (kter² je robustn∞jÜφ ne₧ p°enos spojovan², nebo¥ snßze p°e₧ije p°φpadn² v²padek p°enosov²ch cest).
• na jeÜt∞ ni₧Üφ ·rovni akceptovali fakt, ₧e ₧ivotaschopnΘ p°enosovΘ technologie mohou vznikat i mimo rßmec TCP/IP, a ₧e je ₧ßdoucφ je p°evzφt a vyu₧φt (a nikoli je apriorn∞ odmφtat Φi alespo≥ formßln∞ zaΦle≥ovat do rßmce TCP/IP jako vlastnφ standardy). Z tohoto d∙vodu TCP/IP nijak nep°edepisuje, co mß b²t äpod" sφ¥ovou vrstvou - sice zde zavßdφ samostatnou vrstvu, tzv. vrstvu sφ¥ovΘho rozhranφ, ale tu nijak nenapl≥uje.

Transportnφ vrstva: a¥ si ka₧d² vybere

Auto°i TCP/IP dosp∞li k zßv∞ru, ₧e by to nebylo zcela optimßlnφ, a to z nßsledujφcφho d∙vodu: i aplikace jsou dosti r∙znorodΘ, a mohou mφt r∙znorodΘ po₧adavky na p°enosovΘ slu₧by. N∞kterΘ budou spolehlivost skuteΦn∞ po₧adovat, zatφmco jinΘ aplikace dajφ p°ednost rychlejÜφmu a pravideln∞jÜφmu p°enosu dat p°ed spolehlivostφ p°enosu (proto₧e fungovßnφ mechanism∙ pro zajiÜt∞nφ spolehlivosti zp∙sobuje celkovΘ zpomalenφ a zavßdφ nerovnom∞rnosti v doruΦovßnφ dat). Pro p°φklady takov²chto aplikacφ nenφ nutnΘ chodit daleko - nap°φklad p°i p°enosu zvuku Φi obrazu nejsou p°φpadnΘ chyby v p°enesen²ch datech tak bolestivΘ, jako p°φpadnß nerovnom∞rnost v jejich doruΦovßnφ. Nap°φklad lidskΘ oko v∞tÜinou ani nepost°ehne drobn² äkaz" v n∞kterΘm ze snφmk∙ b∞₧φcφho filmu, ale okam₧it∞ by post°ehlo kolφsßnφ rychlosti filmu (tj. nepravidelnosti ve st°φdßnφ jednotliv²ch snφmk∙).

Pohybnosti v∙Φi zavedenφ spolehlivosti do transportnφ vrstvy vÜak mohou mφt i diametrßln∞ odliÜnou motivaci - pro n∞kterΘ aplikace nemusφ b²t spolehlivost, realizovanß na ·rovni transportnφ vrstvy, dostateΦnß a adekvßtnφ jejich pot°ebßm. Zde je t°eba si uv∞domit, ₧e mechanismy zajiÜ¥ujφcφ spolehlivost nemohou mφt nikdy absolutnφ ·Φinnost a efektivnost, proto₧e absolutn∞ ·ΦinnΘ a efektivnφ nejsou ani mechanismy detekce chyb (umo₧≥ujφcφ v∙bec rozpoznat, ₧e k n∞jakΘ chyb∞ doÜlo). Proto ka₧dß spolehlivost je v₧dy relativnφ. M∙₧e se sice dosti t∞sn∞ blφ₧it absolutnφ hranici 100%, ale nikdy se k nφ fakticky nedostane. V praxi by se pak mohlo stßt, ₧e transportnφ vrstva by sice zajiÜ¥ovala spolehlivost p°enosu, ale pro urΦitou aplikaci ne dostateΦnou, a tato aplikace by si proto musela zajiÜ¥ovat pot°ebnou mφru spolehlivosti sama a znovu. Pak by ale bylo zbyteΦnΘ a neefektivnφ, aby spolehlivost zajiÜ¥ovala souΦasn∞ i vrstva transportnφ.l

Jak² je ale celkov² zßv∞r? Mß transportnφ vrstva zajiÜ¥ovat spolehlivost, nebo naopak nemß? Auto°i TCP/IP vy°eÜili toto dilema skuteΦn∞ Üalamounsky: odpov∞d∞li souΦasn∞ äano" i äne". Ud∞lali to tak, ₧e pro svou transportnφ vrstvu navrhli dv∞ alternativy, resp. dva hlavnφ transportnφ protokoly - z nich₧ jeden (protokol TCP, Transport Control Protocol) zajiÜ¥uje urΦitou mφru spolehlivosti a druh² (protokol UDP, User Datagram Protocol) nikoli. VyÜÜφ vrstvy si pak mohou samy vybrat, kter² z t∞chto transportnφch protokol∙ budou vyu₧φvat.

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

Srovnßnφ vrstev TCP/IP a ISO/OSI

Jakmile se auto°i TCP/IP zdßrn∞ vyrovnali s dilematem transportnφ vrstvy, Φekalo na n∞ dalÜφ zßva₧nΘ rozhodnutφ. Tentokrßte se t²kalo slu₧eb, kterΘ jsme si p°i popisu referenΦnφho modelu ISO/OSI charakterizovali jako äpodp∙rnΘ" pro jednotlivΘ aplikace - tedy nap°φklad slu₧eb zajiÜ¥ujφcφch konverze p°enßÜen²ch dat, korektnφ pr∙b∞h relacφ apod. Otßzka p°itom nezn∞la tak, zda tyto slu₧by majφ Φi nemajφ smysl. èlo spφÜe o Φetnost po₧adavk∙ na jejich vyu₧itφ, a v nßvaznosti na tom o nejvhodn∞jÜφ zp∙sob jejich implementace.

Auto°i referenΦnφho modelu ve stejnΘ situaci dosp∞li k zßv∞ru, ₧e slu₧by tohoto typu budou pot°ebovat vÜechny aplikace, a tak se rozhodli implementovat je takov²m zp∙sobem, aby je m∞ly vÜechny aplikace k dispozici - a vyhradili pro n∞ samostatnΘ vrstvy. To pak ale mj. znamenalo, ₧e i re₧ii spojenou s implementacφ t∞chto slu₧eb musely nΘst op∞t vÜechny aplikace, vΦetn∞ t∞ch kterΘ podp∙rnΘ slu₧by nepo₧adujφ a nevyu₧φvajφ.

Auto°i TCP/IP dosp∞li p°i stejnΘm rozhodovßnφ k opaΦnΘmu zßv∞ru - k p°esv∞dΦenφ, ₧e po₧adavky na podp∙rnΘ slu₧by budou spφÜe mΘn∞ ΦastΘ, a ₧e naopak budou p°eva₧ovat aplikace kterΘ tyto slu₧by vyu₧φvat nebudou. Pak jim ale takΘ vyÜlo, ₧e nenφ moc rozumnΘ implementovat zmφn∞nΘ podp∙rnΘ funkce v samostatn²ch vrstvßch, spoleΦn∞ pro vÜechny aplikace - nech¥ si je implementuje a₧ ta aplikace, kterß je skuteΦn∞ pot°ebuje, a to vlastnφmi silami. No a to je takΘ d∙vod, proΦ TCP/IP na rozdφl od ISO/OSI nemß ani relaΦnφ, ani prezentaΦnφ vrstvu.