Transportnφ protokoly TCP/IP - I.
P°i srovnßvßnφ celkovΘ filosofie sφ¥ovΘho modelu TCP/IP a referenΦnφho modelu ISO/OSI jsme si ji₧ d°φve uvedli, ₧e jednou z jejich odliÜnostφ je po₧adavek na spolehlivost p°enosov²ch slu₧eb na jednotliv²ch ·rovnφch. ReferenΦnφ model ISO/OSI (alespo≥ ve svΘ p∙vodnφ koncepci) je orientovßn p°edevÜφm na spojovanΘ slu₧by spolehlivΘho charakteru, a p°edpoklßdß tudφ₧ za°azenφ pot°ebn²ch mechanism∙ pro zajiÜt∞nφ spolehlivosti ji₧ do vrstvy sφ¥ovΘ. Naproti tomu TCP/IP model pova₧uje zajiÜt∞nφ spolehlivosti za ·kol koncov²ch ·Φastnφk∙, a za°azuje proto p°φsluÜnΘ mechanismy a₧ do vrstvy transportnφ.
Pro sprßvnΘ pochopenφ podstaty celΘho problΘmu je t°eba si uv∞domit, ₧e realizace spolehliv²ch slu₧eb je spojena s v∞tÜφ re₧iφ, ne₧ jakou jsou zatφ₧eny nespolehlivΘ p°enosovΘ slu₧by. Nejde p°itom jen o v∞tÜφ v²poΦetnφ nßroΦnost, ale takΘ o v∞tÜφ nßroky na p°enosovou kapacitu. Spolehlivost p°enos∙ po ne zcela spolehliv²ch p°enosov²ch cestßch se toti₧ musφ zajiÜ¥ovat vhodnou formou potvrzovßnφ, co₧ je ale v₧dy spojeno s p°enosem urΦitΘho objemu slu₧ebnφch dat, ke kterΘmu samoz°ejm∞ dochßzφ na ·kor "u₧iteΦn²ch dat".
Jestli₧e tedy TCP/IP model po₧aduje na sφ¥ovΘ vrstv∞ pouze nespolehlivou p°enosovou slu₧bu (realizovanou protokolem IP, viz minul² dφl), umo₧≥uje tφm souΦasn∞, aby sφ¥ovß vrstva pracovala s menÜφ re₧iφ, a tudφ₧ rychleji.
Spolehlivost vs. rychlost
Pova₧uje-li sφ¥ov² model TCP/IP otßzku zajiÜt∞nφ spolehlivosti za ·kol koncov²ch ·Φastnφk∙ komunikace, znamenß to, ₧e p°φsluÜnΘ mechanismy pro jejφ zajiÜt∞nφ musφ b²t implementovßny ve vyÜÜφ vrstv∞, ne₧ je vrstva sφ¥ovß. Otßzkou ovÜem je, zda to skuteΦn∞ musφ b²t ji₧ vrstva bezprost°edn∞ vyÜÜφ, tedy vrstva transportnφ - jak jsme dosud p°edpoklßdali.
Za°adit pot°ebnΘ mechanismy pro zajiÜt∞nφ spolehlivosti do transportnφ vrstvy mß ΦetnΘ v²hody. P°edevÜφm pak tu, ₧e tyto prost°edky mohou b²t v transportnφ vrstv∞ realizovßny prßv∞ jednou, a sdφleny vÜemi entitami aplikaΦnφ vrstvy. Pokud bychom naopak tyto prost°edky umφstili a₧ do vrstvy aplikaΦnφ, vlastn∞ by to znamenalo, ₧e by si je musela ka₧dß entita aplikaΦnφ vrstvy zajiÜ¥ovat v₧dy znovu a sama.
Mohlo by se tedy zdßt, ₧e vÜe hovo°φ ve prosp∞ch prvnφ mo₧nosti. Ale i ta druhß m∙₧e mφt svΘ opodstatn∞nφ - existujφ toti₧ i takovΘ druhy aplikacφ, kterΘ bu∩ v∙bec nepot°ebujφ spolehlivΘ p°enosovΘ slu₧by, nebo naopak nepova₧ujφ "spolehlivost" na ·rovni transportnφ vrstvy za dostateΦnou, a tak si ji musφ zajiÜ¥ovat samy a znovu. Jinou motivacφ mohou b²t otßzky efektivnosti - n∞kterΘ aplikace si dokß₧φ zajistit samy takovou mφru spolehlivosti, jakou skuteΦn∞ pot°ebujφ, a vykazujφ p°itom menÜφ re₧ii, ne₧ jakou na zajiÜt∞nφ "·plnΘ" spolehlivosti vy₧aduje vrstva transportnφ. P°φkladem takovΘhoto druhu aplikacφ m∙₧e b²t distribuovan² systΘm soubor∙ NFS (Network File System) firmy Sun, velmi oblφben² a znaΦn∞ rozÜφ°en² v prost°edφ operaΦnφho systΘmu Unix. Umo₧≥uje, aby jeden uzlov² poΦφtaΦ zcela transparentn∞ sdφlel soubory jinΘho uzlovΘho poΦφtaΦe, tedy aby k nim p°istupoval naprosto stejn∞, jako ke sv²m vlastnφm soubor∙m. Nemß-li ale dochßzet k v²razn∞jÜφm Φasov²m rozdφl∙m p°i p°φstupu k lokßlnφm a vzdßlen²m soubor∙m, musφ systΘm NFS pracovat maximßln∞ rychle. Nem∙₧e si proto dovolit pou₧φvat spolehlivΘ, zato ale "pomalΘ" p°enosovΘ slu₧by na ·rovni transportnφ vrstvy.
Ka₧d² si m∙₧e vybrat sßm
TCP/IP Sφ¥ov² model TCP/IP vychßzφ vst°φc ob∞ma skupinßm aplikacφ - jak t∞m, kterΘ na transportnφ vrstv∞ po₧adujφ spolehliv² p°enos, tak i t∞m, kterΘ jej cht∞jφ mφt co mo₧nß nejrychlejÜφ. SouΦßstφ rodiny protokol∙ TCP/IP jsou toti₧ dva alternativnφ protokoly pro transportnφ vrstvu: protokol TCP (Transmission Control Protocol), kter² zajiÜ¥uje spolehlivou p°enosovou slu₧bu, a protokol UDP (User Datagram Protocol), kter² naopak nabφzφ slu₧bu nespolehlivou, s v²razn∞ ni₧Üφ re₧iφ, a tudφ₧ rychlejÜφ. JednotlivΘ protokoly aplikaΦnφ vrstvy si pak mezi ob∞ma protokoly transportnφ vrstvy mohou vybrat ten, kter² jim lΘpe vyhovuje, p°φpadn∞ vyu₧φvat oba.
Spojovan² vs. nespojovan² charakter transportnφch slu₧eb
Spolehlivost a nespolehlivost nenφ jedin²m rozdφlem mezi ob∞ma protokoly transportnφ vrstvy. Protokol TCP mß spojovan² (connection-oriented) charakter, kter² pracuje s virtußlnφmi okruhy (virtual circuits), a p°ed vlastnφm p°enosem p°edpoklßdß navßzßnφ spojenφ mezi odesilatelem a p°φjemcem. Naproti tomu protokol UDP mß nespojovan² (connectionless) charakter, a ka₧d² jednotliv² blok dat, oznaΦovan² v tomto p°φpad jako u₧ivatelsk² datagram (user datagram) p°enßÜφ samostatn∞ a nezßvisle na ostatnφch datagramech.
Protokol UDP tak vlastn∞ poskytuje na ·rovni transportnφ vrstvy slu₧by stejnΘho charakteru, jakΘ na ·rovni vrstvy sφ¥ovΘ poskytuje protokol IP (viz minule), tedy nespolehlivΘ a nespojovanΘ slu₧by. Naproti tomu protokol TCP implementuje pomocφ nespolehliv²ch a nespojovan²ch slu₧eb na ·rovni sφ¥ovΘ vrstvy spolehlivΘ a spojovanΘ transportnφ slu₧by. Jak jsme si ji₧ naznaΦili v²Üe, Φinφ tak s pomocφ mechanismu potvrzovßnφ (acknowledgement), a tudφ₧ i s nezanedbatelnou re₧iφ.
Proud vs. blokov∞ orientovan² p°enos
DalÜφ odliÜnostφ mezi ob∞ma protokoly je pak takΘ forma, jakou svΘ p°enosovΘ slu₧by nabφzφ. Protokol UDP koncipuje svou p°enosovou slu₧bu jako p°enos cel²ch blok∙ dat. OΦekßvß tedy, ₧e entita aplikaΦnφ vrstvy, kterß chce odeslat n∞jakß data, je sama sestavφ do bloku, a ten pak protokolu UDP p°edß jako jeden celek. Protokol UDP tento blok vezme, umφstφ jej do svΘho u₧ivatelskΘho datagramu (viz v²Üe), a p°enese op∞t jako jeden celek. Naproti tomu protokol TCP koncipuje svou p°enosovou slu₧bu jako tzv. proud (stream) jednotliv²ch byt∙ (p°esn∞ji: osmic byt∙, tzv. oktet∙). Odesilatel na jednom uzlovΘm poΦφtaΦi postupn∞ p°edßvß protokolu TCP jednotlivΘ byty (oktety), a obdobn∞ postupuje i p°φjemce, kter² si je na druhΘ stran∞ zase postupn∞ odebφrß. VeÜkerΘ Φlen∞nφ p°enßÜen²ch dat na bloky a p°enos cel²ch t∞chto blok∙ zajiÜ¥uje protokol TCP pln∞ transparentn∞. U₧ivatelΘ p°enosov²ch slu₧eb protokolu TCP tak zφskßvajφ iluzi, ₧e pracujφ se slu₧bou, kterß p°enßÜφ individußln∞ jednotlivΘ byty (oktety).
Stavov² vs. bezestavov² zp∙sob komunikace
Se spojovan²m, resp. nespojovan²m charakterem protokol∙ TCP a UDP ·zce souvisφ jeÜt∞ i dalÜφ aspekt, kter² je velmi podstatn² pro protokoly aplikaΦnφ vrstvy a pro jejich volbu mezi ob∞ma nabφzen²mi transportnφmi protokoly.
Ka₧d² u₧ivatelsk² datagram (user datagram) - jak je oznaΦovßn blok dat, p°enßÜen² na ·rovni transportnφ vrstvy protokolem UDP - je pova₧ovßn za samostatn² celek, a vzhledem k nespojovanΘmu charakteru protokolu UDP je takΘ tak p°enßÜen - samostatn∞, nezßvisle na jin²ch u₧ivatelsk²ch datagramech, a bez p°edchozφho navßzßnφ spojenφ mezi p°φjemcem a odesilatelem. Stejn∞ tak i p°φjemce chßpe u₧ivatelsk² datagram jako jedin² celek, a ne jako souΦßst v∞tÜφho celku. Tomu pak odpovφdß i skuteΦnost, ₧e p°φjemce nem∞nφ sv∙j stav v zßvislosti na pr∙b∞hu komunikace - po p°ijetφ datagramu se nachßzφ ve stejnΘm stavu, v jakΘm byl p°ed jeho p°ijetφm. Jde tedy o zp∙sob p°enosu, kter² je mo₧nΘ charakterizovat jako bezestavov² (stateless). Naproti tomu ka₧dß spojovanß slu₧ba mß v₧dy nutn∞ stavov² charakter, nebo¥ ji₧ pouh²m navßzßnφm spojenφ se p°φjemce dostßvß do jinΘho stavu, ne₧ v jakΘm byl p°edtφm.
Bezestavov² zp∙sob komunikace je vzhledem ke svΘ podstat∞ dob°e odoln² v∙Φi r∙zn²m nestandardnφm situacφm, p°edevÜφm pak v²padk∙m a ztrßtßm dat. Dojde-li nap°φklad k v²padku p°enosov²ch cest Φi k v²padku p°φjemce (a je nutnΘ jej znovu spustit, provΘst tzv. reboot), nejsou nutnß ₧ßdnß specifickß opat°enφ pro obnovu p∙vodnφho stavu - v p°enosu dat se jednoduÜe pokraΦuje dßl. Naproti tomu v p°φpad∞ stavovΘho zp∙sobu komunikace mohou b²t urΦitΘ nßpravnΘ akce zapot°ebφ, mß-li b²t zachovßna konzistence prßv∞ probφhajφcφch Φinnostφ, a znovu navßzßno p°eruÜenΘ spojenφ.
S tφm pak takΘ souvisφ i otßzka spolehlivosti - zatφmco bezestavovΘ protokoly si mohou dovolit b²t nespolehlivΘ (jako UDP), pro jejich stavovΘ prot∞jÜky je v²hodn∞jÜφ pracovat s dostateΦnou mφrou spolehlivosti, a tedy nabφzet spolehlivΘ p°enosovΘ slu₧by (jako protokol TCP).
Transportnφ protokoly TCP/IP - II.
V minulΘm dφlu naÜeho serißlu jsme se zaΦali zab²vat transportnφ vrstvou sφ¥ovΘho modelu TCP/IP. Seznßmili jsme se se dv∞ma alternativnφmi protokoly - TCP a UDP - kterΘ jsou na tΘto ·rovni k dispozici, a zab²vali jsme se p°edevÜφm jejich odliÜnostmi. Dnes se podrobn∞ji zastavφme u toho, co majφ oba transportnφ protokoly spoleΦnΘho.
A₧ doposud jsme v naÜich ·vahßch p°edpoklßdali, ₧e prvotnφmi odesilateli a koneΦn²mi p°φjemci nejr∙zn∞jÜφch dat v poΦφtaΦov²ch sφtφch jsou jednotlivΘ uzlovΘ poΦφtaΦe jako takovΘ. Nynφ si vÜak musφme tuto p°edstavu up°esnit: skuteΦn²mi odesilateli a p°φjemci jsou entity aplikaΦnφ vrstvy. Tyto mohou b²t oznaΦovßny r∙zn∞: jako procesy (processes), ·lohy (tasks), aplikaΦnφ programy (application programs) Φi jeÜt∞ jinak. PodstatnΘ ovÜem je, ₧e v prost°edφ vφce·lohov²ch operaΦnφch systΘm∙ takov²chto entit m∙₧e b²t (a takΘ b²vß) vφce. Oba protokoly transportnφ vrstvy pak pot°ebujφ podle n∞Φeho rozhodnout, kterΘ entit∞ aplikaΦnφ vrstvy majφ p°ijatß data p°edat.
Adresy proces∙?
NejjednoduÜÜφ by bylo adresovat jednotlivß data p°φmo konkrΘtnφm proces∙m. Tedy p°id∞lit proces∙m jednoznaΦnΘ identifikßtory, a ty pak pou₧φvat pro urΦenφ koncov²ch p°φjemc∙ v rßmci p°φsluÜnΘho hostitelskΘho poΦφtaΦe. ProblΘm je ovÜem v tom, ₧e procesy vznikajφ a zanikajφ dynamicky, a odesilatel obvykle nemß dostatek informacφ o tom, kterΘ konkrΘtnφ procesy prßv∞ b∞₧φ na cφlovΘm poΦφtaΦi. Kdyby tomu tak m∞lo b²t, p°i vzniku Φi zßniku ka₧dΘho procesu by museli b²t pr∙b∞₧n∞ informovßni vÜichni potencißlnφ odesilatelΘ, co₧ nenφ prakticky mo₧nΘ. Pro odesilatele navφc nemusφ b²t v∙bec podstatnΘ, kter² konkrΘtnφ proces bude p°φjemcem jeho dat. Data, kterß proces na jednom poΦφtaΦi posφlß na jin² poΦφtaΦ, toti₧ mohou p°edstavovat po₧adavek na urΦitou slu₧bu. Pak ale nenφ relevantnφ to, kter² proces prßv∞ zajiÜ¥uje danou slu₧bu, jako spφÜe to, o jakou slu₧bu jde. Navφc je docela dob°e mo₧nΘ, ₧e jeden a tent²₧ proces zajiÜ¥uje vφce jak jednu slu₧bu souΦasn∞.
Adresovat data konkrΘtnφm proces∙m tedy nenφ p°φliÜ rozumnΘ. JakΘ jsou ale alternativy?
Porty a jejich vlastnosti
DalÜφ mo₧nostφ je vytvo°it na rozhranφ mezi transportnφ vrstvou a bezprost°edn∞ vyÜÜφ vrstvou "p°echodovΘ body", a ty opat°it jednoznaΦn²mi identifikßtory, resp. adresami. P°enßÜenß data pak jsou adresovßna t∞mto "p°echodov²m bod∙m", a skuteΦn²m p°φjemcem dat je pak ten proces, kter² je v danΘm okam₧iku k tomuto "p°echodovΘmu bodu" logicky p°ipojen.
Sφ¥ov² model TCP/IP pou₧φvß prßv∞ tento mechanismus, a p°φsluÜnΘ "p°echodovΘ body" oznaΦuje jako porty (ports).
Z pohledu procesu, kter² je prßv∞ p°ipojen k urΦitΘmu portu, se tento jevφ jako vyrovnßvacφ pam∞¥ s re₧imem fronty - entita transportnφ vrstvy uklßdß data do portu z jednΘ strany, a entita aplikaΦnφ vrstvy (tj. proces) si je ve stejnΘm po°adφ zase odebφrß. Analogicky i pro opaΦn² sm∞r p°enosu. Samotn² port s prßv∞ naznaΦen²mi vlastnostmi je sßm o sob∞ datovou strukturou, a jako takov² m∙₧e dynamicky vznikat i zanikat, obdobn∞ jako vlastnφ procesy.
Adresy port∙
Vztah mezi portem a procesem (entitou aplikaΦnφ vrstvy) je vztahem dynamick²m - procesy se dynamicky p°ipojujφ a odpojujφ od jednotliv²ch port∙. Pro odesilatele je tedy podstatnΘ znßt Φφsla (adresy) jednotliv²ch port∙, a nemusφ pro n∞ b²t relevantnφ, kter² konkrΘtnφ proces je k p°φsluÜnΘmu portu prßv∞ p°ipojen. Chce-li nap°φklad urΦit² proces na hostitelskΘm poΦφtaΦi A zφskat soubor, kter² se nalΘzß na poΦφtaΦi B, musφ sv∙j po₧adavek na tento soubor adresovat poΦφtaΦi B (kter² urΦφ jeho IP adresou), a doplnit jej adresou portu, na kterΘm je zajiÜ¥ovßna slu₧ba pro p°enos soubor∙. Adresy port∙ jsou p°itom cel²mi Φφsly bez znamΘnka, v rozsahu 16 bit∙. Otßzkou ovÜem je, jak m∙₧e aplikaΦnφ proces na jednom hostitelskΘm poΦφtaΦi zjistit pot°ebnß Φφsla port∙ na jinΘm poΦφtaΦi, a¥ ji₧ chce vyu₧φt n∞kterou z jφm poskytovan²ch slu₧eb, nebo jinak komunikovat s n∞kter²m z aplikaΦnφch proces∙ na tomto jinΘm poΦφtaΦi.
K °eÜenφ tΘto otßzky jsou v zßsad∞ dva mo₧nΘ p°φstupy. Prvnφ z nich spoΦφvß v tom, ₧e Φφsla port∙ se na vÜech hostitelsk²ch poΦφtaΦφch p°id∞lφ jednou prov₧dy a stejn∞, a toto p°id∞lenφ se zve°ejnφ. Ka₧d² aplikaΦnφ proces pak mß k dispozici informaci o Φφslech p°φsluÜn²ch port∙ na vÜech uzlov²ch poΦφtaΦφch - t∞mto port∙m se pak takΘ °φkß dob°e znßmΘ porty (well-known ports). ProblΘm je ovÜem v tom, ₧e tato varianta statickΘho charakteru se dß pou₧φt jen pro zve°ejn∞nφ takov²ch slu₧eb, kterΘ jsou p°edem znßmy, a s jejich₧ existencφ lze p°edem poΦφtat.
Alternativou je umo₧nit proces∙m na jin²ch uzlov²ch poΦφtaΦφch zjistit si Φφslo portu na danΘm poΦφtaΦi - dotazem stylu: "na jakΘm portu je poskytovßna slu₧ba p°enosu soubor∙?" Tato varianta stßle vy₧aduje alespo≥ jeden "dob°e znßm² port" (p°es kter² by bylo mo₧nΘ vznΘst p°φsluÜn² dotaz), a je takΘ spojena s urΦitou re₧iφ. Na druhΘ stran∞ je ale mnohem pru₧n∞jÜφ, nebo¥ umo₧≥uje vytvß°et porty a p°id∞lovat jim Φφsla (adresy) podle okam₧itΘ pot°eby dynamicky vznikajφcφch a zanikajφcφch aplikaΦnφch proces∙, a nenφ vßzßna tφm, jak jsou obdobnß p°id∞lenφ realizovßna na jin²ch uzlov²ch poΦφtaΦφch.
Tv∙rci TCP/IP protokol∙ se rozhodli pro kombinaci obou variant - pro nejΦast∞ji pou₧φvanΘ slu₧by pou₧ili prvnφ mo₧nost, tedy pevnΘ p°id∞lenφ Φφsel "dob°e znßm²m port∙m", a zbylΘ adresy ponechali volnΘ pro dynamickΘ p°id∞lovßnφ podle okam₧it²ch pot°eb.
Multiplex a demultiplex datagram∙
Vra¥me se nynφ zp∞t k ob∞ma protokol∙m transportnφ vrstvy soustavy TCP/IP, tedy k protokol∙m UDP a TCP. Z existence vφce port∙ mezi transportnφ a aplikaΦnφ vrstvou vypl²vß, ₧e protokol transportnφ vrstvy na stran∞ odesilatele musφ b²t schopen p°ijφmat data od r∙zn²ch aplikaΦnφch entit, a p°edßvat je sφ¥ovΘ vrstv∞ (realizovanΘ pomocφ protokolu IP) k p°enosu - tedy zajiÜ¥ovat jejich multiplexovßnφ, a na stran∞ p°φjemce pak provßd∞t jejich demultiplexovßnφ, tedy rozd∞lovßnφ dat, p°evzat²ch od sφ¥ovΘ vrstvy, mezi r∙znΘ entity aplikaΦnφ vrstvy, prost°ednictvφm p°φsluÜn²ch port∙.
Tato p°edstava velmi dob°e odpovφdß koncepci nespojovanΘ p°enosovΘ slu₧by, kterou poskytuje protokol UDP. Tento protokol se na ka₧d² port dφvß skuteΦn∞ jako na jeden logick² objekt - frontu, do kterΘ jsou postupn∞ uklßdßny vÜechny datagramy, adresovanΘ tomuto portu na danΘm poΦφtaΦi.
Protokol TCP vÜak vychßzφ z pon∞kud odliÜnΘ abstrakce. Vzhledem ke svΘmu spojovanΘmu charakteru pracuje se spojenφmi, kterß jsou definovßna dv∞ma koncov²mi body - ka₧d² koncov² bod je p°itom urΦen dvojicφ . Vφce r∙zn²ch spojenφ p°itom m∙₧e sdφlet tent²₧ koncov² bod, tj. "konΦit" ve stejnΘm portu. Zßkladnφm typem objektu, se kter²m protokol TCP pracuje, je tedy spojenφ, a nikoli port jako takov².
Protokol UDP
V p°edchozφch dφlech naÜeho serißlu jsme se zaΦali zab²vat transportnφ vrstvou sφ¥ovΘho modelu TCP/IP. P°itom jsme si naznaΦili, ₧e pro tuto vrstvu p°ipadajφ v ·vahu dva alternativnφ protokoly - TCP a UDP. Dnes se podrobn∞ji zastavφme u jednoho z nich: protokolu UDP.
Nejprve si ale znovu p°ipome≥me n∞kterΘ obecn∞jÜφ souvislosti, o kter²ch jsme se ji₧ zmφnili. Zde jsme si °ekli, ₧e na rozdφl od referenΦnφho modelu ISO/OSI pova₧uje sφ¥ov² model TCP/IP otßzku zabezpeΦenφ spolehlivosti p°enos∙ za v∞c koncov²ch ·Φastnφk∙ komunikace, a z tohoto d∙vodu za°azuje p°φsluÜnΘ mechanismy pro zajiÜt∞nφ spolehlivosti a₧ do transportnφ vrstvy, zatφmco na ·rovni sφ¥ovΘ vrstvy p°edpoklßdß pouze nespolehlivou slu₧bu nespojovanΘho charakteru (realizovanou protokolem IP). ╪ekli jsme si vÜak takΘ, ₧e sφ¥ov² model TCP/IP pamatuje i na to, ₧e pro n∞kterΘ druhy aplikacφ nemusφ b²t spolehlivΘ transportnφ slu₧by v²hodnΘ. Proto jim nabφzφ jako alternativnφ mo₧nost vyu₧φvat i na ·rovni transportnφ vrstvy slu₧by stejnΘ povahy a kvality, jakou majφ p°enosovΘ slu₧by na ·rovni sφ¥ovΘ vrstvy, zajiÜ¥ovanΘ protokolem IP - tedy nespolehlivΘ p°enosovΘ slu₧by nespojovanΘho charakteru.
UDP jako jednoduchß "obßlka" protokolu IP
Mechanismem, kter² entitßm (proces∙m, ·lohßm, program∙m) aplikaΦnφ vrstvy zp°φstup≥uje nespolehlivΘ a nespojovanΘ, zato ale rychlΘ a efektivnφ p°enosovΘ slu₧by sφ¥ovΘ vrstvy (protokolu IP), je prßv∞ protokol UDP (User Datagram Protocol). M∙₧eme si jej p°edstavit jako jednoduchou "obßlku" nad protokolem IP, kterß nijak nem∞nφ povahu ani kvalitu jeho p°enosov²ch slu₧eb, ale pouze je zprost°edkovßvß svΘ bezprost°edn∞ vyÜÜφ vrstv∞. V podstat∞ jedinΘ, co UDP zajiÜ¥uje navφc, je multiplexovßnφ a demultiplexovßnφ datagram∙ (viz minul² dφl serißlu), tedy rozliÜovßnφ r∙zn²ch p°φjemc∙, resp. odesilatel∙ v rßmci tΘho₧ hostitelskΘho poΦφtaΦe - podle Φφsla portu.
Odpov∞dnost p°ebφrß aplikace
Ka₧d² aplikaΦnφ program, kter² se rozhodne pou₧φvat transportnφ slu₧by protokolu UDP, tak na sebe p°ebφrß odpov∞dnost za zajiÜt∞nφ takovΘ ·rovn∞ spolehlivosti p°enos∙, jakou sßm pot°ebuje. Sßm se takΘ musφ vyrovnßvat i s dalÜφmi d∙sledky, kterΘ vypl²vajφ z nespolehlivΘho a nespojovanΘho charakteru p°enosov²ch slu₧eb protokolu UDP - jako je nap°. zajiÜ¥ovßnφ sprßvnΘho po°adφ doruΦovan²ch datagram∙, eliminace duplicitnφch datagram∙ apod.
Jak jsme si ji₧ uvedli v p°edchozφch dφlech, je volba nespolehliv²ch transportnφch slu₧eb protokolu UDP determinovßna p°edevÜφm charakterem aplikace a jeho po₧adavky na efektivitu p°enosov²ch slu₧eb. Svou roli p°i rozhodovßnφ mezi nespolehliv²mi ale rychlejÜφmi slu₧bami protokolu UDP a spolehliv²mi, zato ale pomalejÜφmi transportnφmi slu₧bami protokolu TCP vÜak sehrßvß i prost°edφ, ve kterΘm jsou tyto transportnφ slu₧by zajiÜ¥ovßny. Nap°φklad v lokßlnφch sφtφch, kterΘ jsou velmi rychlΘ a p°edevÜφm relativn∞ spolehlivΘ, m∙₧e b²t protokol UDP pro mnohΘ aplikace velmi v²hodn². P°i p°echodu do prost°edφ rozlehl²ch sφtφ, kterΘ jsou ve svΘ podstat∞ mnohem mΘn∞ spolehlivΘ, vÜak m∙₧e natolik nar∙st re₧ie konkrΘtnφho aplikaΦnφho programu na zajiÜt∞nφ pot°ebnΘ spolehlivosti, ₧e se pro ni stane protokol UDP mΘn∞ v²hodn², ne₧ "spolehliv²" protokol TCP, nebo se pou₧itφ protokolu UDP stane dokonce zcela ne·nosnΘ.
Formßt UDP datagramu
Protokol UDP dostßvß od svΘ bezprost°edn∞ vyÜÜφ vrstvy bloky dat, kterΘ se sna₧φ vklßdat celΘ do jednotliv²ch datagram∙ sφ¥ovΘ vrstvy (IP datagram∙). Proto se takΘ t∞mto blok∙m na ·rovni transportnφ vrstvy °φkß u₧ivatelskΘ datagramy (user datagrams), nebo tΘ₧ UDP datagramy (UDP datagrams).
HlaviΦku (anglicky: header) UDP datagramu tvo°φ 4 polo₧ky v rozsahu 16 bit∙, kterΘ po °ad∞ vyjad°ujφ Φφslo portu odesilatele a p°φjemce, dΘlku UDP datagramu, a kontrolnφ souΦet.
╚φslo portu p°φjemce (polo₧ka UDP DESTINATION PORT) je zßkladnφ informacφ, podle kterΘ se protokol UDP na stran∞ p°φjemce rozhoduje, komu mß p°ijat² datagram doruΦit - p°esn∞ji: p°es kter² port mß p°ijat² datagram p°edat entit∞ aplikaΦnφ vrstvy. ╚φslo portu odesilatele (v polo₧ce UDP SOURCE PORT) je nepovinnΘ; vypl≥uje se v p°φpad∞, kdy je po₧adovßna odpov∞∩ (v opaΦnΘm p°φpad∞ se tato polo₧ka zapl≥uje nulami). Polo₧ka LENGTH vyjad°uje dΘlku UDP datagramu, m∞°enou v oktetech (tj. osmicφch bit∙) - vΦetn∞ vlastnφ hlaviΦky. Minimßlnφ dΘlka UDP datagramu je proto 8, co₧ je prßv∞ velikost hlaviΦky, s prßzdnou datovou Φßstφ.
Kontrolnφ souΦet (polo₧ka CHECKSUM) je poΦφtßn v rozsahu 16 bit∙ v aritmetice, kterß pro vyjßd°enß Φφsel se znamΘnkem vyu₧φvß tzv. jedniΦkov² dopln∞k (one's complement). Jednou ze zajφmav²ch vlastnostφ tΘto nep°φliÜ pou₧φvanΘ aritmetiky je skuteΦnost, ₧e mß dva mo₧nΘ zp∙soby znßzorn∞nφ nuly: tzv. kladnou nulu, tvo°enou dvojkov∞ sam²mi nulami, a tzv. zßpornou nulu, kterß mß naopak vÜechny bity nastaveny na jedniΦku. V p°φpad∞, ₧e kontrolnφ souΦet vychßzφ nulov², je pou₧ita prßv∞ tato druhß mo₧nost, tedy tzv. zßpornß nula. Pou₧itφ kontrolnφho souΦtu vÜak nenφ povinnΘ. Jestli₧e se kontrolnφ souΦet nepou₧ije, je polo₧ka CHECKSUM vynulovßna - ovÜem tzv. kladnou nulou, co₧ je dφky vlastnostem jedniΦkovΘho dopl≥ku mo₧nΘ odliÜit od nulovΘ hodnoty kontrolnφho souΦtu.
ZvlßÜtnostφ protokolu UDP je skuteΦnost, ₧e zmφn∞n² kontrolnφ souΦet - je-li pou₧it - nenφ poΦφtßn z UDP datagramu), ale z v∞tÜφ datovΘ struktury, kterß vznikne pomysln²m p°ipojenφm dalÜφ hlaviΦky - tzv. pseudohlaviΦky (pseudo header) k vlastnφmu datagramu. Pomysln²m p°ipojenφm v tom smyslu, ₧e tato pseudohlaviΦka nenφ ve skuteΦnosti p°enßÜena od odesilatele k p°φjemci, ale je brßna v ·vahu pouze pro v²poΦet kontrolnφho souΦtu.
V pseudohlaviΦce obsa₧ena mj. IP adresa p°φjemce a odesilatele (kterß naopak ve vlastnφm UDP datagramu, resp. jeho hlaviΦce obsa₧ena nenφ). Protokol UDP na stran∞ p°φjemce kontroluje bezchybovost vÜech p°ijat²ch datagram∙ nov²m v²poΦtem kontrolnφho souΦtu a jeho porovnßnφm s obsahem polo₧ky CHECKSUM. U₧ivatelsk² datagram sice p°ijme bez jeho pseudohlaviΦky, ale pro pot°eby kontrolnφho souΦtu si ji protokol UDP znovu vytvo°φ a zahrne ji do novΘho v²poΦtu kontrolnφho souΦtu. Vzhledem k tomu, ₧e pseudohlaviΦka UDP datagramu obsahuje mj. i IP adresu p°φjemce, jde o mechanismus, kter² krom∞ poÜkozen²ch datagram∙ umo₧≥uje rozpoznat takΘ datagramy, doruΦenΘ na chybnou IP adresu (co₧ z pouhΘho Φφsla portu, kterΘ je ve vlastnφm datagramu, nelze poznat), a nßsledn∞ je eliminovat.
Zastavme se vÜak jeÜt∞ u prßv∞ naznaΦenΘho v²poΦtu kontrolnφho souΦtu. Podle n∞j musφ protokol UDP u odesilatele ji₧ p°i sestavovßnφ UDP datagramu znßt nejen IP adresu p°φjemce, ale i IP adresu odesilatele, nebo¥ ob∞ tyto adresy musφ zahrnout do kontrolnφho souΦtu. IP adresu p°φjemce se protokol UDP dozvφ od aplikace, nebo¥ prßv∞ ona urΦuje, komu jsou p°φsluÜnß data urΦena. Pokud vÜak jde o IP adresu odesilatele, nemusφ b²t v silßch protokolu UDP ji stanovit. Jde-li toti₧ o hostitelsk² poΦφtaΦ, kter² mß vφce ne₧ jedno sφ¥ovΘ rozhranφ (tj. jde-li o tzv. multi-homed host, kter² je souΦasn∞ zapojen do vφce dφlΦφch sφtφ, viz 46. dφl serißlu), mß odesilatel vφce r∙zn²ch IP adres (po jednΘ na ka₧dΘ sφ¥ovΘ rozhranφ, resp. pro ka₧dou dφlΦφ sφ¥). Rozhodnout, kudy bude p°φsluÜn² datagram skuteΦn∞ odeslßn (tj. kter²m sφ¥ov²m rozhranφm, resp. s jakou IP adresou odesilatele), je pak a₧ v silßch sφ¥ovΘ vrstvy, resp. protokolu IP, kter² zajiÜ¥uje sm∞rovßnφ. Protokol UDP si proto musφ p°i sestavovßnφ u₧ivatelskΘho datagramu vy₧ßdat pomoc protokolu IP, co₧ ale pon∞kud naruÜuje standardnφ zp∙sob interakce jednotliv²ch vrstev ve vrstevnatΘm modelu.