Vyšlo v týdeníku CHIPweek č. 34/96, 20. srpna 1996
Vytištěno z adresy: http://www.earchiv.cz/a96/a634k150.php3

Protokoly TCP/IP (III.)

Jestliže protokoly nižších vrstev TCP/IP jsou v dnešní době relativně stabilizovány, a jejich další vývoj má spíše charakter technického zdokonalování, pak v aplikační vrstvě je tomu poněkud jinak. Zde se doslova o překot objevují nová a nová řešení, která se velmi vehementně snaží ukázat svou životaschopnost a prosadit se, někdy i na úkor jiných alternativních řešení. Podívejme se na některá z nich, a naznačme si i způsob, jakým tato řešení vznikají a jakým se dostávají do světa TCP/IP.

Minule jsme si popisovali „klasické" aplikace jako elektronickou poštu, přenos souborů a vzdálené přihlašování. Jsou to všechno aplikace (a s nimi související protokoly), které vznikly přímo v samotném světě TCP/IP. V současné době se ale začíná čím dál tím více prosazovat poněkud odlišný model - nové aplikace vznikají mnohdy mimo „svět TCP/IP", tedy jako vlastní (obvykle proprietární) řešení jiných subjektů, a teprve následně, když prokáží svou životaschopnost a účelnost, jsou začleňovány do „světa TCP/IP" a stávají se jeho standardy. První vlaštovkou tohoto trendu byl protokol NFS pro sdílení souborů v lokálních sítích, pocházející od firmy Sun Microsystems. Dalšími příklady pak mohou být protokoly zajišťující fungování dnes tolik oblíbených internetových služeb jako WWW, Gopher, IRC apod.

Sdílení souborů (NFS)

Potřeba sdílení souborů se začala objevovat s nástupem lokálních sítí, od kterých se očekávalo že svým uživatelům nabídnou možnost sdílení souborů - navíc takového sdílení, při kterém by skutečné fyzické umístění jednotlivých souborů přestalo hrát roli (přestalo by být „viditelné", odsud také" transparentní sdílení). S postupem času se objevila různá řešení, která takovouto potřebu sdílení souborů dokázala naplnit. Jedním z nich bylo i řešení, které si pro sebe vyvinula firma Sun Microsystems, a nazvala jej NFS (Network File System).

Vůdčími myšlenkami sdílení souboru á la NFS jsou snaha o maximální robustnost a snaha o nezávislost na konkrétní platformě. A pak samozřejmě také architektura klient/server, která je potřebě sdílení souborů doslova šita na míru - serverem (konkrétně tzv., file serverem) je zde počítač, na kterém jsou sdílené soubory skutečně umístěny, zatímco v roli jeho klienta vystupuje počítač, který k těmto souborům chce mít přístup. Snaha o maximální robustnost se pak projevuje v tom, že komunikace mezi klientem a serverem je tzv. bezestavová - což znamená, že každý jednotlivý požadavek klienta začíná vždy „na zelené louce", a je zcela nezávislý na tom, jaký byl případný předchozí požadavek. Server si pak nemusí pamatovat vůbec nic o případné předchozí komunikaci se svými klienty - což je doslova k nezaplacení pro případné výpadky a poruchy, po kterých není potřeba vůbec nic obnovovat. Přispívá k tomu i skutečnost, že klient smí klást pouze tzv. idempotentní požadavky, neboli takové které lze libovolněkrát opakovat, ale jejich výsledek bude vždy stejný - pak to totiž má velmi jednoduché i klient. Pokud se nedočká odezvy na některý svůj požadavek, jednoduše jej vznese znovu.

Snaha o nezávislost na konkrétní platformě, kterou má systém NFS také doslova vrozenou, pak přináší významné praktické důsledky. Zejména v tom, že file server i jeho klient mohou stát na různých platformách. Například file server může být Unixovým počítačem, a jeho klient například počítačem PC s DOS-em, MS Windows atd.

Výše uvedené vlastnosti systému NFS se pak postaraly o to, že původně proprietární řešení firmy Sun Microsystems se prosadilo do praxe, a na celé čáře porazilo své konkurenty - například systém RFS (Remote File System, vyvinutý firmou AT&T). Ten totiž fungoval na stavovém principu (tj. jeho server si pamatoval určité informace o svých klientech mezi jejich jednotlivými požadavky), a tak byl méně robustní. Než se ale systém NFS mohl stát standardem „světa TCP/IP", musely být jeho specifikace plně zveřejněny, a musely se stát „veřejným vlastnictvím" (v tom smyslu, že využití těchto specifikací nesmělo být vázáno na žádné licenční poplatky). Vlastně tedy celé řešení, které původně patřilo firmě Sun Microsystems (a která jej vyvinula na své náklady) muselo být předáno do „světa TCP/IP". Navíc muselo projít celou standardizační mašinerií TCP/IP, která specifikace NFS přejala a vydala jako svůj standard.

Obrázek 1.
Zajímavá je i implementační stránka sdílení souborů á la NFS. I zde totiž firma Sun Microsystem přišla se zajímavými a podnětnými myšlenkami, které se záhy prosadily do světa TCP/IP. Šlo především o to, že samotný protokol NFS, realizující vlastní sdílení souborů, doslova „podložili" dvěma samostatnými službami - službou pro tzv. vzdálené volání procedur (RPC, Remote Procedure Call], a XDR (eXternal Data Representation]. Smyslem mechanismu RPC (implementovaného stejnojmenným protokolem] je skrýt před programátory existenci sítě a vytvořit jim iluzi toho, že vše se odehrává na jednom jediném počítači - programátoři zde volají procedury a funkce, o kterým si myslí že jsou lokální (a používají mj. i lokální konvence pro své volání, předávání parametrů apod.), ale ve skutečnosti jsou tyto procedury a funkce vykonávány (prováděny) na vzdálených počítačích (odsud také: vzdálené volání procedur). Výhodou je pak skutečnost, že aplikační programátor nemusí znát specifika sítě a práce v síti. Mechanismus XDR pak zajišťuje případné konverze datových formátů, pokud jsou zapotřebí. Firma Sun Microsystems přitom vymyslela oba mechanismy takovým způsobem, aby netvořily integrální součást systému NFS, a byly naopak relativně nezávislé a využitelné i jinými aplikačními službami a jejich protokoly.

Nepřipomíná vám to ale samostatnou relační a prezentační vrstvu v referenčním modelu ISO/OSI, kterou autoři TCP/IP odmítli jako nepotřebnou? Pokud ano, máte pravdu - zde se ve formě mechanismů RPC a XDR skutečně objevuje něco, co lze připodobnit k samostatným vrstvám, zaměřeným obdobně jako relační a prezentační vrstva ISO/OSI. Svědčí to o staré dobré pravdě, že nakonec se přeci jen prosadí zlatá střední cesta - a pak to také svědčí o tom, že model TCP/IP je dostatečně pružný, když dokázal takovýto přístup elegantně „vstřebat".

World Wide Web

Služba World Wide Web, která dnes doslova hýbe celým Internetem, má po technické stránce mnoho společného se sdílením souborů a systémem NFS. Původně totiž vznikla v komunitě fyziků zabývajících se vysokými energiemi, jako řešení jejich potřeby sdílení informací, především textového charakteru (konkrétně ve švýcarském středisku CERN). Časem se ale prosadila i do světa TCP/IP, a postarala se o nebývalý boom Internetu. Po stránce implementační jde opět o řešení, tvoření několika složkami - zejména protokolem HTTP (HyperText Transfer Protocol), který definuje způsob přenosu WWW stránek po síti, mezi WWW serverem a jeho klientem, a pak jazykem HTML (HyperText Markup Language), který definuje formát jednotlivých stránek. V poslední době pak k těmto dvěma „základním" složkám přibývají další, které mají za úkol dále zvyšovat schopnosti a funkční možnosti služby WWW. Jde například o jazyk Java, mechanismy ActiveX, nebo různé zabezpečovací mechanismy a protokoly (jako SSL, S/HTTP, SET apod.), které umožňují provádět prostřednictvím služby WWW bezpečné transakce. Formální standardizace těchto složek, v rámci obvyklé standardizační mašinérie světa TCP/IP, však zatím poněkud pokulhává - není ostatně ani moc divu, vzhledem k neuvěřitelně rychlému vývoji v této oblasti.

Také po stránce svého fungování má služba WWW hodně společného se sdílením souborů á la NFS. Komunikace WWW serveru a jeho klientů je totiž také bezestavová, a WWW server si tedy obecně nepamatuje nic o tom, co po něm chtěl určitý klient někdy dříve. Důsledkem je větší robustnost než jaké by bylo možné dosáhnout při stavovém způsobu komunikace. Výhody přitom pociťujeme skoro všichni: pokud jste k Internetu připojeni po modemu, tj. přes komutované linky veřejné telefonní sítě, pak váš browser dokáže bez problémů přežít i výpadek spojení, a po opětovném „dovolání se" můžete ve svém brouzdání pokračovat, jako kdyby se nic nestalo.