Báječný svět počítačových sítí

Část XIV: Služby a aplikace (nejen) v Internetu

Většina aplikací v rámci TCP/IP a Internetu vychází z výpočetního modelu klient/server. Na počátku sloužily tyto aplikace třem základním službám - elektronické poště, přenosu souborů a vzdálenému přihlašování - ale s postupem času se jejich repertoár rozšiřoval. Vznikaly nové a specializované služby, s vlastními aplikacemi a aplikačními protokoly (např. NFS, Archie, WAIS, Gopher apod.). Později se ale trend obrátil a počet služeb, resp. aplikací se začal naopak snižovat. Některé úplně zanikly, zatímco jiné se udržely. Z "nových" uspěl hlavně World Wide Web.

Minulý díl tohoto seriálu jsme zakončili konstatováním, že aplikační vrstva není tím místem, kde jsou provozovány celé aplikace. Ve skutečnosti je tomu tak, že v aplikační vrstvě "běhá" jen část aplikací, zatímco zbývající části aplikací byly "vysunuty nad" aplikační vrstvu. Důvod je velmi prozaický: pokud by v aplikační vrstvě byly provozovány celé aplikace, musely by se také celé podřídit jednotným standardům. Tudíž by mohly nabízet jen standardizované (rozuměj: stejné) uživatelské rozhraní, standardizované (tj. stejné) repertoáry funkcí a schopností, standardizované (stejné) ovládání atd. Pak by ale nemělo smysl vytvářet různé verze aplikací (například různé emailové klienty), od různých výrobců a producentů, protože všechny by vypadaly stejně, chovaly by se stejně, stejně by se ovládaly atd. Vlastně by byly úplně stejné.

Rozumným řešením je rozdělit aplikace tak, aby v aplikační vrstvě zůstalo právě a pouze to, co musí být standardizováno a sjednoceno. Tedy například ta část poštovního programu, která zajišťuje vlastní přenos zpráv, a dbá na to, aby jí ostatní části poštovního systému rozuměly, aby používala jednotný formát emailových zpráv atd. Naopak uživatelské rozhraní a nejrůznější uživatelsky orientované funkce (například pro čtení a psaní samotných zpráv) se již mohou pro různé aplikace lišit.

Obr. 1: Představa vztahu aplikací a aplikační vrstvy

Aplikace a aplikační protokoly

Rozdělení aplikací na dvě části a standardizace těch částí, které zůstaly v aplikační vrstvě, ještě nestačí k tomu, aby aplikace fungovaly skutečně tak jak mají. Například půjde-li o již zmiňovanou elektronickou poštu, musí být nějak vyřešeno předávání zpráv mezi jednotlivými uzly, které se na fungování celého "elektronického poštovního systému" podílejí. Takové předávání zpráv bude řízeno vhodným protokolem, který bude na přenos zpráv specializován.

Obr. 2: Představa aplikačních protokolů

Obecně se takovéto protokoly označují přívlastkem "aplikační", protože fungují v rámci aplikační vrstvy a slouží potřebám aplikací. Konkrétně se pak hovoří například o aplikačním protokolu pro přenos elektronické pošty (kterým je v TCP/IP protokol SMTP, Simple Mail Transfer Protocol), o aplikačním protokolu pro přenos WWW stránek (kterým je v TCP/IP protokol HTTP) atd.

Architektura aplikací a výpočetní model

S aplikačními protokoly úzce souvisí také architektura samotných aplikací. To je opět na delší povídání, které nás čeká v příštím dílu tohoto seriálu, kdy se budeme bavit o tzv. výpočetním modelu. Zde si pouze naznačme, že v prostředí počítačových sítí (a také celosvětového Internetu) je dnes nejčastějším výpočetním modelem model klient/server. Jeho podstatou není nic jiného, než že úkoly, které mají být splněny v rámci nějaké služby, například v rámci elektronické pošty či World-Wide Webu, se rozdělí mezi dvě aplikace - jednu, která plní roli serveru, a druhou, která plní roli klienta. Proto také označení celého tohoto řešení (tzv. výpočetního modelu) termínem "klient/server".

Obr. 3: Představa výpočetního modelu klient/server

Úkolem klienta přitom je zajišťovat styk s uživatelem. Tedy zejména zobrazovat mu požadované výstupy, a přijímat od něj jeho požadavky (vstupy, obvykle zadávané z klávesnice, myši atd.). Úkolem serveru pak je zajišťovat vlastní zpracování, které je v rámci služby zapotřebí, a to až na výzvy klienta (resp. jeho uživatele). Asi nejnázornější je to na příkladu služby WWW: její server je tím, kdo u sebe uchovává jednotlivé WWW stránky. Sám je ale nikomu nevnucuje. Pouze pasivně čeká, až si některý WWW klient (označovaný také jako browser, či prohlížeč) o nějakou WWW stránku řekne. Pak mu ji server poskytne - a je už na klientovi, aby tuto stránku korektně zobrazil svému uživateli. Když ten si pak vyžádá nějakou jinou WWW stránku (ať již explicitním zadáním její adresy či kliknutím na hypertextový odkaz v právě zobrazované stránce), WWW klient pošle WWW serveru nový požadavek - a vše se opakuje.

Obr. 4: Představa modelu klient/server v rámci služby WWW

Ovšem aby si server a klient správně rozuměli a dokázali spolu spolupracovat tak jak je třeba, musí mezi nimi existovat dvě konvence:

• konvence o tom, jak budou vzájemně komunikovat. Tuto konvenci naplňuje aplikační protokol, v konkrétním případě služby WWW jde o protokol HTTP (Hypertext Transfer Protocol)
• konvence o tom, jak budou formátovány a jaký význam budou mít data, která si klient a server vzájemně předávají. V případě WWW jde hlavně o formát WWW stránek, které server zasílá klientovi - ty jsou kódovány v jazyku HTML (HyperText Markup Language). Klient mu musí rozumět natolik, aby podle něj dokázal vytvořit grafickou podobu příslušné WWW stránku (provést tzv. rendering, neboli jakousi "vizualizaci" WWW stránky).

Elektronická pošta jako aplikace

Ukažme si vše ještě na jednom příkladu, a to pro elektronickou poštu (v Internetu). Ta je službou, na jejíž realizaci se podílí poštovní servery (mail servery), zajišťující přenos jednotlivých zpráv, a dále poštovní klienti, kteří uživatelům zprostředkovávají čtení i psaní zpráv. Pro svou vzájemnou komunikaci přitom poštovní servery a poštovní klienti mají k dispozici více aplikačních protokolů. Nejčastější je dnes asi stále řešení, kdy se pro odesílání zpráv (od poštovního klienta k poštovnímu serveru) a pro přenos zpráv (mezi poštovními servery) používá protokol SMTP (Simple Mail Transfer Protocol), a pro stahování zpráv (z poštovních schránek, umístěných na poštovním serveru, do poštovního klienta) se používá protokol POP3. Proč tomu tak je, a proč zde nestačí jen jediný protokol (SMTP), či kde a jak se používají další "poštovní" aplikační protokoly jako je IMAP, si povíme později, v dalších pokračováních tohoto seriálu, až se dostaneme konkrétněji k fungování elektronické pošty jako takové.

Obr. 5: Představa modelu klient/server v rámci elektronické pošty

Teď jen sumarizující obrázek (č. 5), naznačující představu serverů a klientů v rámci celého systému elektronické pošty, a také jedno malé upřesnění: World Wide Web i elektronická pošta jsou službami, a jako takové jsou realizovány (implementovány) konkrétními aplikacemi, s využitím konkrétních aplikačních protokolů atd. V případě WWW existuje jen jeden způsob implementace této služby (ten, který jistě dobře znáte z Internetu, s protokolem HTTP, jazykem HTML atd.).

Ovšem u elektronické pošty je to jinak. Ta je službou, která může být (a je) implementována více různými způsoby, s využitím různých aplikačních protokolů a dalších standardů, na různých platformách atd. Vlastně je možné hovořit o celých ucelených "systémech elektronické pošty", které se shodují v základním účelu (možnosti elektronické poštovní korespondence), ale už se mohou i významně lišit v tom, jak konkrétně to dělají. Ten systém elektronické pošty, který jsme si až dosud popisovali a který se používá v Internetu, je dnes sice dominující, ale není zdaleka jediný. Pokud je třeba jej odlišit od ostatních systémů elektronické pošty, označuje se neformálně jako "SMTP pošta" (kvůli aplikačnímu protokolu SMTP pro přenos zpráv).

Alternativou k SMTP poště, pocházející ze světa ISO/OSI, měl být systém X.400. Moc se ale neujal, i když byl doveden až do stádia veřejně nabízené služby, fungující na komerčním základě. Připomeňme si, že v roce 1995 začal takovouto službu na bázi X.400 nabízet i v ČR Český Telecom, pod názvem CZ.MAIL. Inzeroval ji například pomocí celostránkových inzerátů v celostátních denících, ale i přesto s ní vůbec neuspěl. Nejspíše i proto, že v jeho podání šlo o službu zpoplatněnou: například první 2 KB zprávy, přenášené po Evropě, měly stát 8,40 Kč, a každé další dva kilobity již "jen" 4,80 Kč.

Obr. 6: Veřejná elektronická pošta CZ.MAIL, na bázi X.400 (ze světa ISO/OSI)

Prvotní aplikace pro Internet

Od alternativ k SMTP poště jsme se dostali k tomu, že "není aplikace jako aplikace", a že jedna a ta samá služba (jako například právě elektronická pošta) může být v různém prostředí implementována různě, pomocí různých aplikací, s různými aplikačními protokoly atd. Vraťme se ale k Internetu, který nás ze všech takovýchto prostředí zajímá určitě nejvíce, a řekněme si, jak to bylo s "jeho" aplikacemi, resp. službami.

Když se dnešní Internet teprve rodil (přesněji když vznikaly protokoly TCP/IP), počítali jeho autoři se třemi "základními" službami:

• elektronickou poštou
• přenosem souborů
• vzdáleným přihlašováním

Pro zajištění těchto služeb vymysleli tři odpovídající aplikační protokoly, a do protokolů TCP/IP zabudovali vše potřebné, co s tím souvisí. Například pro elektronickou poštu vytvořili celý koncept "SMTP pošty", jehož součástí není jen aplikační protokol SMTP pro přenos zpráv, zmiňovaný výše, ale také další součásti - zejména standard (RFC 822), definující formát poštovních zpráv, formát a význam poštovních adres a další věci.

Přenos souborů

Pro přenos souborů vznikl ve stejné době protokol FTP (což je zkratka od: File Transfer Protocol), umožňující přenášet celé soubory mezi jednotlivými uzly v rámci sítě. Opět ale jde o službu, zajišťovanou pomocí aplikací fungujících v modelu klient/server. Aplikace v roli FTP serveru je "tím, kdo má soubory", zatímco klient je "tím, kdo chce soubory". FTP server běží na nějakém uzlu (z pohledu uživatele celé služby jde o vzdálený uzel), a nabízí ke stažení všechny nebo některé soubory, nacházející se na tomto (vzdáleném) počítači. Stejně tak může nabízet nahrání (uchování, uložení) dalších souborů na uzel, na kterém běží. FTP klient pak běží na uzlu, na kterém pracuje uživatel, a skrze tohoto klienta si stahuje soubory ze (vzdáleného) FTP serveru, nebo naopak nahrává (tzv. uploaduje) své soubory na (vzdálený) FTP server. Lze si to představit také tak, že FTP server vytváří jakési "okno", skrze které jsou "vidět" soubory, umístěné na vzdáleném počítači, a tyto jsou dostupné pro čtení a zápis. Naznačuje to i obrázek č. 7

Obr. 7: Představa přenosu souborů prostřednictvím FTP

Vzdálené přihlašování

Pokud jde o vzdálené přihlašování, to je služba motivovaná zejména potřebou využívat na dálku výpočetní kapacitu a další zdroje vzdálených uzlů. Třeba k tomu, aby správce sítě mohl provést na dálku nějaké úkony (například nějaké změny nastavení) na vzdáleném počítači, a to přímo ze svého počítače, aniž by se musel fyzicky přemisťovat ke vzdálenému počítači. Také běžný uživatel si může skrze vzdálené přihlašování spustit aplikace na vzdáleném počítači, a používat je "na dálku". Je to možné díky tomu, mezi jeho počítačem a vzdáleným počítačem vzniká tzv. vzdálená terminálová relace (jako alternativa k "lokální" terminálové relaci). Její podstatou je přesměrování výstupů (a také vstupů) příslušné aplikace, běžící na vzdáleném uzlu. Místo toho, aby tato aplikace zobrazovala své výstupu na "místním" monitoru (resp. terminálu), jako u lokální terminálové relace, posílá je po síti na jiný uzel (kde se nachází uživatel), a teprve zde se tyto výstupy zobrazují. Obdobně se vstupy, které generuje uživatel - generuje je (mačkáním kláves na své klávesnici) tam, kde se nachází, a tyto vstupy jsou po síti zasílání až ke vzdálenému uzlu, kde běží příslušná aplikace, a jsou jí předávány.

Obr. 8: Představa lokální a vzdálené terminálové relace

Způsob, jakým je služba vzdáleného přihlašování realizována v prostředí TCP/IP, ukazuje následující obrázek č. 9. Opět jde o řešení na bázi modelu klient/server, s tím že komunikaci mezi klientem a serverem zajišťuje protokol Telnet. Podle něj se také hovoří o Telnet serveru a Telnet klientovi.

Telnet server "sedí" na vzdáleném uzlu, a má za úkol přesměrovávat výstupy zdejších aplikací na jiné uzly (kde běží Telnet klient). Úkolem Telnet klienta je naopak takovéto výstupy zobrazovat uživateli na jeho displeji. Ten dříve patřil skutečnému terminálu, a proto se také hovořilo o "terminálových relacích". Dnes již uživatelé pracují téměř výlučně s běžnými univerzálními počítači, které funkce a chování jednoúčelového terminálu pouze předstírají (tzv. emulují), pomocí softwarových prostředků. Tuto roli, resp. úkol (tj. softwarovou emulaci terminálu) také plní Telnet klient. Kromě toho samozřejmě musí "sbírat" vstupy od svého uživatele (z klávesnice, případně i od myši), a tyto zase zasílat opačným směrem, k Telnet serveru. Úkolem Telnet serveru je pak "podstrčit" tyto vstupy místní aplikaci, tak aby si myslela, že pochází od nějakého místního uživatele, a vzala je na vědomí a vykonala to, co požadují.

Obr. 9: Představa realizace vzdálených terminálových relací v TCP/IP (protokol Telnet)

Další vývoj v TCP/IP

Další vývoj aplikací a služeb v rámci TCP/IP (a Internetu), po vzniku "prvotní trojice", se ubíral dvěma hlavními směry:

• obohacováním již existujících aplikací o další možnosti a schopnosti
• vznikem nových aplikací, realizujících nové služby

Pro první variantu (obohacování již existujících aplikací) je podstatné, že se tak dělo inkrementálním způsobem, a nikoli formou "zahoď stávající a přejdi na nové". Jinými slovy: nové možnosti a schopnosti se postupně přidávaly jako přírůstky k již existujícímu řešení, resp. jako vylepšení toho, co již existuje a používá se, a nikoli cestou vývoje zcela nového řešení, které by nahradilo to dosavadní.

Asi nejlépe bude si vše přiblížit na konkrétním příkladu. Zde se přímo nabízí již zmiňovaná elektronická pošta (SMTP pošta), která původně vznikla jako jednoduchá služba pro přenos krátkých textových zpráv (nezaměňovat s SMS). Nebyla stavěna na přenos rozsáhlých textů, ani na texty v národních abecedách neanglických mluvících uživatelů (u nás: na přenos textů s háčky a čárkami). Počítala pouze s přenosem čistých ASCII znaků, a nedovolovala ani žádné "přikrášlování" textu zpráv, pomocí různých druhů písma, barviček či jiného formátování. Stejně tak neumožňovala ani přikládání příloh (ve formě souborů) ke zprávám.

I tak si ale lidé elektronickou poštu velmi oblíbili, používali ji v čím dál tím větším měřítku - a požadovali její další obohacení, zejména o již zmiňované možnosti formátování textů a přílohy. No a tak odborníci zasedli a vymysleli způsob, jak původní SMTP poštu obohatit tak, aby požadované věci zvládala. Navíc tak, aby to skutečně byl "přírůstek", resp. rozšíření, v tom smyslu že nebude třeba měnit základní způsob fungování celé SMTP pošty, a jen se "něco přidá". Důležitý byl také způsob takovéhoto přidání, založený na principu "když něčemu nerozumíš, tak se tím nezatěžuj a pokračuj dál". Takže když se například rozšířily možnosti formátování zprávy o různé druhy písma, barvy atd., ale "obohacená" zpráva přišla uživateli s poštovním klientem který takovéto rozšíření dosud nepodporuje, neměl by "starý" klient apriorně odmítat s takovou "novou" zprávou pracovat. Místo toho by měl udělat vše proto, aby ji alespoň nějak zpřístupnil svému uživateli. V daném případě tedy zobrazil bez barviček a nestandardních druhů pásma - ale stále v čitelné podobě.

Konkrétní rozšíření systému SMTP pošty, které v tomto duchu vzniklo, se jmenuje MIME (což je zkratka od: Multimedia Internet Mail Extensions).

Nové aplikace

Druhý směr dalšího vývoje, tedy vznik zcela nových služeb a aplikací, pochopitelně již nemůže být inkrementální. I zde ale existuje několik zajímavých momentů, na které je vhodné poukázat. Jde vlastně o určité trendy, které se postupně prosadily.

První z takovýchto trendů se týká způsobu, jakým aplikace vznikají. Původně je vymýšleli lidé z akademické sféry, v rámci orgánu IETF (Internet Engineering Task Force), který také připravuje (po věcné stránce) příslušné standardy. Poměrně brzy se to ale změnilo, a nové protokoly (nejen ty aplikační) začala vymýšlet spíše komerční sféra. Tedy jednotlivé firmy, které investovaly do jejich vývoje, a vytvářely příslušná řešení nejdříve jako svá vlastní (firemní, tzv. proprietární) řešení. S rozvojem Internetu a s růstem jeho popularity ale tyto firmy seznaly, že se jim vyplatí spíše něco jiného - ne držet si tato řešení jako svá vlastní (proprietární) a tím i uzavřená, ale naopak otevřít je a prosadit jako veřejný standard. A tak svá řešení začaly firmy předkládat standardizačním orgánům Internetu (hlavně IETF), a různě lobovat za jejich prosazení.

Prvním aplikačním protokolem, který se takto prosadil, byl protokol NFS (Network File System) pro transparentní sdílení souborů, vyvinutý společností Sun Microsystems (také k němu se v dalších dílech tohoto seriálu dostaneme podrobněji). Dnes takto, tj. v komerční sféře, vznikají prakticky všechny nové věci v rámci TCP/IP a Internetu.

Nejprve diversifikace, pak unifikace

Dalším zajímavým trendem, který se týká vývoje aplikací a služeb, je trend k diversifikaci, neboli ke vniku většího počtu různých a samostatných služeb, resp. aplikací které je implementují. S postupem času se to ale ukázalo jako nepříliš šikovné, a tento trend se obrátil - směrem k unifikaci, přesněji ke snižování počtu samostatných aplikací. Ale nepředbíhejme a vezměme to popořadě.

Služba Gopher

Zpočátku, v "době diversifikace", lidé vymýšleli nové služby pro kdejaký, často i dosti specifický účel. Například pro vyhledávání souborů v FTP archivech. Nebo samostatnou službu pro vyhledávání osob v adresářích. Nebo pro nabídku toho, co je kde dostupné (jaké soubory, například textové, s obrázky apod.). Ke všem těmto nově koncipovaným službám pak lidé vymýšleli příslušné aplikace, standardizovali příslušné aplikační protokoly, definovali formáty dat a další náležitosti. Takto vznikly například služby jako Archie (pro hledání souborů v FTP archivech), WAIS (pro plnotextové vyhledávání v textových dokumentech), Whois (pro hledání osob v adresářích), Gopher (pro sestavování nabídek toho, co se kde nachází), a také World Wide Web.

Služba WAIS

Některé z těchto služeb uspěly, a známe je a běžně používáme ještě dnes. Příkladem může být stále populárnější služba WWW. Jenže kdo si dne vzpomene, že třeba takový Gopher vznikl zhruba ve stejné době jako WWW, možná o něco dříve, měl v zásadě stejný cíl jako WWW - ale neujal se, v souboji s WWW prohrál na celé čáře, a dnes již patří spíše do učebnic internetové historie? Důvod, proč se tak stalo, je docela zajímavý: nebyl zdaleka tak "sexy", jako World Wide Web. Nenabízel tolik uživatelsky atraktivních možností, jako WWW. Byl strohý, málo barevný a málo grafický, byť na druhé straně byl podstatně efektivnější a méně náročný na nejrůznější zdroje. Ale lidé zkrátka dali přednost hezčímu obalu.

Služba WAIS

To důvod, proč zmizely ze scény ostatní služby a aplikace - jako například Archie, WAIS a další - byl úplně jiný. Tyto "hodně specializované" služby byly relativně náročné na znalosti a schopnosti svých uživatelů, kteří si museli instalovat na své počítače specializované klienty (klientské aplikace) pro tyto služby, museli se je učit ovládat, starat se o ně atd.). Časem ale stejnou funkčnost, navíc v podstatně jednodušším a "jednotném" provedení, dokázaly nabídnout jiné služby, zejména World Wide Web.

Dnes již se třeba hledání čehokoli neřeší přes samostatné a specializované služby, s vlastními aplikacemi, klienty a hlavně postupy, ale přes jednotné vyhledávací služby, jaké nabízí například Google (ale i mnohé další), a které fungují jako nadstavba nad službou WWW. Chcete-li je používat, nepotřebujete žádného speciálního klienta, a nemusíte se učit žádné jeho specifické ovládání. Jen ve svém browseru zadáte příslušnou URL adresu, do jednoduchého formuláře napíšete co chcete - a pak už je to jen o vaší vlastní šikovnosti a schopnosti zadat vyhledávací dotaz tak, abyste se dobrali kýženého výsledku.

---