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

AplikaΦnφ vrstva TCP/IP

Kdy₧ jsme si ve 38. dφlu popisovali aplikaΦnφ vrstvu v rßmci referenΦnφho modelu ISO/OSI, dosp∞li jsme k zajφmavΘmu zßv∞ru: aplikaΦnφ vrstva tohoto modelu nenφ urΦena k tomu, aby se v nφ provozovaly jednotlivΘ aplikace. Na poΦßtku, kdy₧ se celkovß koncepce referenΦnφho modelu teprve utvß°ela, se jeÜt∞ p°edpoklßdalo, ₧e jednotlivΘ aplikace budou provozovßny p°φmo v aplikaΦnφ vrstv∞. Jakmile se ale zaΦaly podrobn∞ji rozpracovßvat jednotlivΘ druhy aplikacφ a jejich konkrΘtnφ protokoly, zjistilo se, ₧e na aplikaΦnφ vrstvu zb²vß jeÜt∞ velmi mnoho ·kol∙. Kdyby si je ovÜem zajiÜ¥ovala ka₧dß aplikace sama, bylo by to zbyteΦn²m pl²tvßnφm, proto₧e by stejnΘ funkce byly implementovßny vφcekrßt. Proto se v rßmci referenΦnφho modelu dosp∞lo k zßv∞ru, ₧e je v²hodn∞jÜφ tyto funkce implementovat tak, aby mohly b²t spoleΦnΘ pro vφce aplikacφ. Z tohoto d∙vodu pak byly zb²vajφcφ Φßsti vlastnφch aplikacφ (p°edevÜφm jejich u₧ivatelskß rozhranφ) "vysunuty" nad aplikaΦnφ vrstvu, ve kterΘ naopak z∙staly jen jejich "podp∙rnΘ" prost°edky (viz 38. dφl).

ReferenΦnφ model ISO/OSI tedy stavφ na p°edpokladu, ₧e jednotlivΘ aplikace budou mφt mnoho spoleΦnΘho, a ₧e se tedy vyplatφ realizovat jejich spoleΦnΘ Φßsti samostatn∞, a implementovat je jen jednou. Souvisφ to ostatn∞ i se zp∙sobem, jak²m aplikaΦnφ protokoly v rßmci referenΦnφho modelu vznikaly - p°φstupem, kter² by bylo mo₧nΘ oznaΦit jako maximalistick². ╚asto se toti₧ do aplikaΦnφch protokol∙ zahrnulo "vÜechno, co by mohlo b²t n∞kdy n∞komu u₧iteΦnΘ". Snad nejmarkantn∞ji se tento p°φstup projevil na koncepci protokolu pro p°enos soubor∙ v rßmci ISO/OSI (modelu FTAM - File Access, Transfer and Management), kter² je tak obsßhl² a komplikovan², ₧e snad nikdy nebude moci b²t implementovßn v celΘm svΘm rozsahu.

Naproti tomu sφ¥ov² model TCP/IP vznikal mΘn∞ "od zelenΘho stolu", ne₧ referenΦnφ model ISO/OSI, a vφce vychßzel z praktick²ch zkuÜenostφ a pot°eb. Jeho aplikace zaΦφnaly jako relativn∞ jednoduchΘ, a teprve postupem Φasu se jejich funkce a schopnosti zv∞tÜovaly, a zaΦaly se zavßd∞t novΘ, nßroΦn∞jÜφ druhy aplikacφ. Sφ¥ov² model TCP/IP proto vychßzφ spφÜe z p°edpokladu, ₧e jednotlivΘ aplikace nebudou mφt tolik spoleΦnΘho, aby se tyto jejich spoleΦnΘ Φßsti vyplatilo osamostatnit. Na rozdφl od referenΦnφho modelu ISO/OSI proto oΦekßvß, ₧e ka₧dß aplikace si sama zajistφ to, co pot°ebuje a co ji ni₧Üφ vrstvy neposkytujφ. Teprve v poslednφ dob∞ se pak i v rßmci sφ¥ovΘho modelu TCP/IP zaΦφnajφ n∞kterΘ podp∙rnΘ mechanismy v rßmci aplikaΦnφ vrstvy osamostat≥ovat (nap°. mechanismus volßnφ vzdßlen²ch procedur - viz dßle).

Obr. 64.1.: Aplikace a aplikaΦnφ vrstva v RM ISO/OSI a v sφ¥ovΘm modelu TCP/IP

Zde je dobrΘ si uv∞domit dalÜφ rozdφl mezi referenΦnφm modelem ISO/OSI a sφ¥ov²m modelem TCP/IP, kter² spoΦφvß v poΦtu jejich vrstev. ReferenΦnφ model ISO/OSI toti₧ za°azuje mezi transportnφ vrstvu a vrstvu aplikaΦnφ jeÜt∞ dv∞ dalÜφ vrstvy (relaΦnφ a prezentaΦnφ), kterΘ takΘ poskytujφ podp∙rnΘ slu₧by vlastnφm aplikacφm (krom∞ samotnΘ aplikaΦnφ vrstvy). Sφ¥ov² model TCP/IP vÜak nemß ₧ßdnou analogii relaΦnφ a prezentaΦnφ vrstvy ISO/OSI. TakΘ jejich funkce si proto v prost°edφ TCP/IP musφ zajistit jednotlivΘ aplikace vlastnφmi silami - viz obr. 64.1.

Stejn∞ tak jako referenΦnφ model ISO/OSI, byl i sφ¥ov² model TCP/IP navr₧en pro heterogennφ prost°edφ, tedy pro prost°edφ poΦφtaΦov²ch sφtφ, jejich₧ uzlovΘ poΦφtaΦe se mohou i dosti v²razn∞ liÜit - nejen pou₧it²m hardwarem, ale takΘ nap°φklad konvencemi pro znßzor≥ovßnφ Φφsel, k≤dovßnφm jednotliv²ch znak∙, konvencemi operaΦnφch systΘm∙ o vlastnictvφ a p°φstupov²ch prßvech k soubor∙m apod. V referenΦnφm modelu se o odstran∞nφ n∞kter²ch odliÜnostφ (hlavn∞ ve vnit°nφch formßtech) starß prezentaΦnφ vrstva. V modelu TCP/IP je vÜe na samotn²ch aplikacφch.

Klient vs. server

Obr. 64.2.: P°edstava slo₧ek v roli klienta a serveru

Rozeberme si tuto p°edstavu pon∞kud podrobn∞ji. P°edstavme si (viz tΘ₧ obr. 64.2.) slo₧ku v roli klienta na poΦφtaΦi A. Tato klientskß slo₧ka formuluje svΘ po₧adavky na konkrΘtnφ slu₧by, a zasφlß je svΘ partnerskΘ slo₧ce v roli serveru na poΦφtaΦi B. Slo₧ka v roli serveru je p°ijφmß, zpracovßvß a reaguje na n∞ (nap°. vracφ zp∞t po₧adovanß data). P°esn² zp∙sob komunikace p°itom zßvisφ na konkrΘtnφ aplikaci - n∞kterΘ vyu₧φvajφ pro vzßjemnou komunikaci klienta se serverem spolehlivΘ a spojovanΘ transportnφ slu₧by protokolu TCP, zatφmco jinΘ dßvajφ p°ednost nespolehliv²m a nespojovan²m transportnφm slu₧bßm protokolu UDP. V₧dy vÜak musφ platit to, co jsme si ji₧ naznaΦovali v 55. dφlu: ₧e klient musφ b²t schopen "najφt" p°φsluÜn² server. Slo₧ka v roli serveru proto musφ p°ijφmat po₧adavky sv²ch klient∙ na takovΘm portu (p°echodovΘm bodu mezi transportnφ a aplikaΦnφ vrstvou), kter² je klientovi znßm (tedy na tzv. dob°e znßmΘm portu, viz 55. dφl),

Implementace klienta a serveru v prost°edφ Unixu

Ve vφce·lohovΘm prost°edφ Unixu je vcelku p°irozenΘ koncipovat ob∞ slo₧ky jako samostatnΘ procesy - ka₧d² ovÜem s jin²m postavenφm v rßmci operaΦnφho systΘmu. Proces, realizujφcφ slo₧ku v roli serveru, je obvykle systΘmov²m procesem. Tedy takov²m procesem, kter² nenφ spouÜt∞n na popud u₧ivatele, ale na popud operaΦnφho systΘmu (obvykle ji₧ p°i jeho poΦßteΦnφm zavßd∞nφ). U₧ivatel o jeho existenci vlastn∞ ani nemusφ v∞d∞t, proto₧e takov²to proces s u₧ivatelem p°φmo nekomunikuje. V prost°edφ Unixu se procesy tohoto typu oznaΦujφ jako dΘmoni (daemons).

Naproti tomu proces, realizujφcφ klientskou slo₧ku, je Φasto b∞₧n²m typem aplikaΦnφho procesu, kter² si u₧ivatel sßm explicitn∞ spouÜtφ a₧ na zßklad∞ skuteΦnΘ pot°eby. Krom∞ toho, ₧e implementuje p°φsluÜnΘ aplikaΦnφ protokoly, b²vß tento aplikaΦnφ proces vybaven i vlastnφm u₧ivatelsk²m rozhranφm - nejΦast∞ji jednoduch²m a °ßdkov∞ orientovan²m. Typick²m p°φkladem m∙₧e b²t protokol FTP (File Transfer Protocol), jeho₧ klientskß slo₧ka b²vß v Unixu implementovßna jako samostatnß utilita, s vlastnφm °ßdkov∞ orientovan²m u₧ivatelsk²m rozhranφm. Prost°ednictvφm tohoto jednoduchΘho rozhranφ pak u₧ivatel mj. zadßvß, kterΘ soubory si p°eje p°enΘst.

V poslednφ dob∞ se vÜak toto schΘma zaΦφnß pon∞kud m∞nit, v souvislosti s tφm, jak i Unix postupn∞ zφskßvß grafickß u₧ivatelskß rozhranφ, a opouÜtφ u₧ivateli tolik kritizovanß, strohß °ßdkovß rozhranφ. Zde ji₧ jsou i klientskΘ slo₧ky realizovßny bez vlastnφho u₧ivatelskΘho rozhranφ, a toto jim vytvß°φ a₧ p°φsluÜnß grafickß nadstavba (nap°. systΘm X-Window). S klientskou slo₧kou, implementujφcφ vlastnφ aplikaΦnφ protokoly, pracuje prost°ednictvφm p°esn∞ definovan²ch konvencφ, kterΘ tvo°φ tzv. aplikaΦnφ programovΘ rozhranφ (API, Application Programming Interface).

Obr. 64.3.: P°edstava implementace klientskΘ slo₧ky protokolu NFS

UvedenΘ koncepci se vÜak pon∞kud vymykajφ n∞kterΘ specißlnφ aplikace v rßmci sφ¥ovΘho modelu TCP/IP. Z°ejm∞ nejmarkantn∞jÜφm p°φkladem je aplikaΦnφ protokol NFS (Network File System, vyvinut² firmou Sun MicroSystems), p°φpadn∞ jeho alternativnφ protokol RFS (Remote File Sharing, vyvinut² firmou AT&T). Ten mß toti₧ za ·kol zajiÜ¥ovat pln∞ transparentnφ sdφlenφ soubor∙ mezi uzlov²mi poΦφtaΦi, o kterΘm by u₧ivatel vlastn∞ ani nem∞l v∞d∞t. Na rozdφl od protokolu FTP, kter² je urΦen pro interaktivnφ p°enos cel²ch soubor∙, NFS svΘ u₧ivatelskΘ rozhranφ ani dost dob°e mφt nem∙₧e. Mφsto toho musφ b²t implementovßn tak (viz obr. 64.3.), aby mohl b²t operaΦnφm systΘmem "p°ekryt", a dostßval od n∞j k vy°φzenφ ty po₧adavky na p°φstup k soubor∙m, kterΘ nejsou lokßlnφ - tedy kterΘ se fyzicky nenachßzφ na lokßlnφm disku.

Protokol NFS je navφc relativn∞ mlad²m protokolem v rßmci TCP/IP, a p°i jeho₧ vzniku se ji₧ uplatnila obdobnß tendence, jako u referenΦnφm modelu ISO/OSI: nenechat aplikace, aby si vÜe pot°ebnΘ zajiÜ¥ovaly samy, ale poskytnout jim pot°ebnΘ podp∙rnΘ prost°edky, realizovanΘ jako samostatnΘ (na ·rovni aplikaΦnφ vrstvy), a tudφ₧ vyu₧itelnΘ i jin²mi aplikacemi. Protokol NFS proto poΦφtß s tφm, ₧e bude vyu₧φvat dva samostatn∞ implementovanΘ mechanismy: mechanismus vzdßlenΘho volßnφ procedur (RPC, Remote Procedure Call), kter² mu zprost°edkovßvß vhodn² zp∙sob komunikace s jeho partnerskou slo₧kou v roli klienta, a dßle mechanismus, zajiÜ¥ujφcφ nezbytnou konverzi p°enßÜen²ch dat (XDR, eXternal Data Representation).