Čá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é (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í e-mailoví klienti) 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 e-mailový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.
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.
Obecně se takové 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 (tí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 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".
Úkolem klienta přitom je zajišťovat styk s uživatelem. Tedy zejména zobrazovat 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ěji je to vidět na příkladu služby WWW: 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ž si ten 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.
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ána 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ánky (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ílejí 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 mají přitom poštovní servery a poštovní klienti 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), 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 pak 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é.
Sumarizující obrázek naznačuje představu serverů a klientů v rámci celého systému elektronické pošty. Jedno malé upřesnění: World Wide Web i elektronická pošta jsou služby, 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, dnes sice dominuje, 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. Příliš 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 takovou službu na bázi X.400 nabízet i v Česku Č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č, každé další dva kilobyty již "jen" 4,80 Kč.
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 podobných 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 mezi jednotlivými uzly v rámci sítě celé soubory. 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 němž běží. FTP klient pak běží na uzlu, na kterém pracuje uživatel, a přes 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", přes které jsou "vidět" soubory, umístěné na vzdáleném počítači, a ty jsou dostupné pro čtení a zápis. Naznačuje to i další obrázek.
Vzdálené přihlašování
Pokud jde o vzdálené přihlašování, je to 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 vzdáleném počítači na dálku nějaké úkony (například nějaké změny nastavení), 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 přes 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, že 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ýstupy 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). Teprve zde se tyto výstupy zobrazují. Obdobně se vstupy, které generuje uživatel mačkáním kláves na své klávesnici tam, kde se nachází, jsou po síti zasílány až ke vzdálenému uzlu, kde běží příslušná aplikace, a jsou jí předávány.
Způsob, jak je služba vzdáleného přihlašování realizována v prostředí TCP/IP, ukazuje následující obrázek. 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ěrovat výstupy zdejších aplikací na jiné uzly (kde běží Telnet klient). Úkolem Telnet klienta je naopak takové 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 (tedy softwarovou emulaci terminálu) plní i 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 ty zase zasílat opačným směrem, k Telnet serveru. Úkolem Telnet serveru je pak "podstrčit" tyto vstupy místní aplikaci, aby si myslela, že pochází od nějakého místního uživatele, vzala je na vědomí a vykonala to, co požadují.
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, 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, nikoli cestou vývoje zcela nového řešení, které by nahradilo to dosavadní.
Asi nejlepší 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 tedy 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 ve stále 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. A tak odborníci zasedli a vymysleli způsob, jak původní SMTP poštu obohatit, aby požadované věci zvládala. Navíc tak, aby to skutečně byl "přírůstek", resp. rozšíření ve smyslu, že nebude třeba měnit základní způsob fungování celé SMTP pošty, jen se "něco přidá". Důležitý byl také způsob takového rozšíření, založený na principu: "když něčemu nerozumíš, tak se tím nezatěžuj a pokračuj dál". 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é funkce 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 svému uživateli zpřístupnil. V daném případě by ji tedy měl zobrazit 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 těchto trendů se týká způsobu, jak 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í). S rozvojem internetu a s růstem jeho popularity ale tyto firmy seznaly, že se jim vyplatí spíše něco jiného nikoliv držet si tato řešení jako svá vlastní (proprietární) a tím i uzavřená, ale naopak je otevřít 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, tedy v komerční sféře, vznikají prakticky všechny nové věci v rámci TCP/IP a internetu.
Nejprve diverzifikace, pak unifikace
Dalším zajímavým trendem, který se týká vývoje aplikací a služeb, je trend k diverzifikaci, neboli ke vzniku 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ě.
Zpočátku, v "době diverzifikace", 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, 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.
Některé z těchto služeb uspěly, 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 dnes 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 ale neujal se, prohrál v souboji s WWW 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í. 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.
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ří museli pro tyto služby instalovat na své počítače specializované klienty (klientské aplikace), 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ší), 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é 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.
PŘEDPLATNÉ
ČLÁNKY DO MAILU