Aplikační vrstva TCP/IP

Ve třech minulých dílech jsme se zabývali rozhraním mezi transportní a aplikační vrstvou v rámci síťového modelu TCP/IP, neboli tím, jak mohou být služby transportní vrstvy zpřístupněny jednotlivým aplikacím. Ukázali jsme si, že zde velmi záleží na konkrétním operačním systému, a pak jsme se podrobněji věnovali dvěma možnostem, se kterými se můžeme setkat v prostředí operačního systému Unix. Dnes již dojde řada na vlastní aplikační vrstvou.

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

Většina aplikací a aplikačních protokolů v rámci síťového modelu TCP/IP vychází z modelu klient/server. Předpokládá tedy existenci dvou složek, které nemají rovnocenné postavení - klient žádá o konkrétní služby a je iniciátorem veškeré komunikace, zatímco server své služby neposkytuje z vlastní iniciativy, ale pouze na žádost klienta.

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

Pro lepší představu o celkové filosofii aplikačních protokolů síťového modelu TCP/IP je vhodné si alespoň naznačit jejich implementaci v prostředí operačního systému Unix.

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

---