Ji°φ Peterka: Co je Φφm ... v poΦφtaΦov²ch sφtφch (55):

Transportnφ protokoly TCP/IP - II.

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∙?

Adresovat data konkrΘtnφm proces∙m tedy nenφ p°φliÜ rozumnΘ. JakΘ jsou ale alternativy?

Porty a jejich vlastnosti

Obr. 55.1.: P°edstava port∙

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ß - viz obr. 55.1. 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∙

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∙

Obr. 55.2.: 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∙ (viz obrßzek 55.2).

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².