Protokoly aplikační vrstvy - DNS, SMTP, HTTP. Leoš Boháč

Protokoly aplikační vrstvy - DNS, SMTP, HTTP Leoš Boháč

Autor: Leoš Boháč Název díla: Protokoly aplikační vrstvy - DNS, SMTP, HTTP Zpracoval(a): České vysoké učení technické v Praze Fakulta elektrotechnická Kontaktní adresa: Technická 2, Praha 6 Inovace předmětů a studijních materiálů pro e-learningovou výuku v prezenční a kombinované formě studia Evropský sociální fond Praha & EU: Investujeme do vaší budoucnosti

VYSVĚTLIVKY Definice Zajímavost Poznámka Příklad Shrnutí Výhody Nevýhody

ANOTACE Informační a komunikační technologie bezesporu musí sloužit nějakému účelu. Proto existují na nejvyšší vrstvě RM-OSI modelu protokoly, které plní svou konkrétní úlohu. Aplikační protokoly lze rozdělit podle celé řady hledisek, kde jedním z nich může být, zda daný aplikační protokol, či skupina přímo zprostředkování přístup k dané službě člověku nebo jestli se používá jen jako pomocná síťová aplikace, plnící v síti sice důležitou a nezastupitelnou, nicméně ne přímo pro koncového člověka viditelnou funkci. CÍLE Cílem modulu je poskytnout studentům základní znalosti týkající se tří aplikačních protokolů DNS, SMTP a HTTP LITERATURA [1] REXFORD, Balachander Krishnamurthy; Jennifer. Web protocols and practice: HTTP/1.1, networking protocols, caching,and traffic measurement. Boston, Mass. [u.a.]: Addison-Wesley, 2001. ISBN 02-017-1088-9. [2] GOURLEY, David a Brian TOTTY. HTTP: the definitive guide. 1st ed. Sebastopol, CA: O'Reilly, 2002, xviii, 635 p. ISBN 15-659-2509-2. [3] RHOTON, John. Programmer's guide to Internet mail: SMTP, POP, IMAP, and LDAP. Boston: Digital Press, c2000, xix, 291 p. ISBN 15-555-8212-5. [4] COSTALES, Bryan a Bryan COSTALES. Sendmail. 4th ed., rev. Sebastopol: O'Reilly, c2008, xxiv, 1282 p. ISBN 05-965-1029-2. [5] DOSTÁLEK, Libor a Alena KABELOVÁ. DNS in action: a detailed and practical guide to DNS implementation, configuration, and administration. Birmingham, U.K.: Packt Pub., 2006, v, 183 p. From technologies to solutions. ISBN 1904811787. [6] LIU, Cricket a Paul ALBITZ. DNS and BIND. 5th ed. Beijing: O Reilly, 2006, 616 s. ISBN 05-961-0057-4.

Obsah 1 Systém doménových jmen v Internetu DNS... 6 1.1 Hierarchická struktura jmenného prostoru DNS... 8 1.2 DNS domény nejvyšší úrovně... 10 1.3 Distribuované záznamy DNS systému... 11 1.4 Koncepce DNS domén a zón... 13 1.5 Způsoby dotazování na DNS servery... 14 1.6 DNS servery... 17 1.7 Typy DNS záznamů a zónový soubor... 18 2 Systém přenosu elektronické pošty a protokol SMTP... 21 2.1 Architektura elektronické pošty... 22 2.2 Adresa u elektronické pošty... 24 2.3 Protokol pro přenos zpráv elektronické pošty... 25 2.4 Struktura a formát elektronické pošty... 26 2.5 Přenos elektronické zprávy, SMTP protokol... 28 2.6 Protokoly pro čtení a zpracování emailových zpráv... 30 2.7 Funkce protokolu POP3... 31 2.8 Protokol IMAPv4... 32 3 Systém přenosu dat u WWW služeb a protokol HTTP... 33 3.1 Model HTTP komunikace... 34 3.2 Reference na informační zdroje WWW... 36 3.3 HTTP protokol... 37 3.4 Metody HTTP protokolu... 39 3.5 Základní model funkce serveru WWW... 41 3.6 Základní model funkce klienta WWW... 42 3.7 Závěrečný test... 43

1 Systém doménových jmen v Internetu DNS Důležitou funkci v každé datové sítí hraje identifikace příslušného datového zdroje, ať už je přístupný lokálně v rámci jednoho fyzického zařízení nebo po síti. Koneckonců i svět lidí má svůj systém pro identifikace osob, věcí, objektů atd. Bez systému pojmenování bychom se jen těžko mohli i dorozumět. Vždyť i každý jazyk umožňuje sám o sobě věci pojmenovávat. Vidíme tedy, že pojmenování hraje v životě, ale tak i v informačních sítích velmi důležitou roli. Pojmenovávat však lze různými způsoby a metodami. Např. každý jazyk má jiná slova pro po-jmenování stejného objektu, či věci. Těmto různým metodám pojmenování budeme říkat různé adresní prostory (namespace). Abychom byli konkrétní, každé koncové zařízení, které má pracovat v prostředí sítí TCP/IP musí mít (kromě jiného) přiřazené jméno ve formě IP adresy. Pokud budeme chápat IP adresu jako jméno, tak všechny různé IP adresy, včetně formy zápisu, tvoří jeden jmenný IP adresní prostor. Jiným jmenným prostorem může být např. pojmenování popsané textovým řetězcem konkrétní maximální délky s kódováním znaků v ASCII znakové sadě. Všechny možné řetězce, včetně definice významu a tvorby zápisu potom mohou tvořit jiný adresový prostor. Je zjevné, že takto lze vytvořit vcelku libovolný jmenný systém, každý s jinými vlastnostmi. Identifikace koncových zařízení v Internetu pomocí jmenného systému IP adresy je sice pro strojové zpracování velice výhodné, nicméně pro člověka to již tak přehledné a snadno zapamatovatelné rozhodně není. Posuďte sami, jestli je snazší si zapamatovat jméno např. server.prace.cz nebo jeho IP adresu, která může být třeba 134.23.12.1. Jak je vidět, různé jmenné prostory a systémy jsou vhodnější pro určitý účel, ale pro účel jiný, jsou krajně nevhodné. Proto byla velice brzo v Internetu snaha o použití jmen na místo IP adres. Vzhledem k tomu, že pro zpracování paketů ve směrovačích a dalších zařízeních je lepší používat IP adresový prostor, ale pro člověka spíše textově založený prostor (který je zase nevhodný pro zpracování paketů v síti), bylo nutné zajistit převod, či mapování mezi oběma jmennými prostory. Toto mapování se v prvopočátku Internetu (1970) dělalo velice jednoduše ve formě tabulky v souboru HOSTS, který byl upravován manuálně, centrálně a následně se rozesílal ostatním koncovým zařízením v síti, které jej pro převod potřebovaly. S postupným růstem počtu stanic v síti a Internetu bylo zřejmé, že tato metoda není vyhovující. V dnešní době by to se stovkami milionů zařízení v síti nebylo už zcela možné. Hledali se tedy způsoby, jak vymyslet jmenný prostor, který by byl zároveň pro člověka snadno přehledný a zapamatovatelný, ale také, aby potřebné spravování mapovacích záznamu neleželo na jednom subjektu, ale bylo rozložení, tedy distribuované. Vznikl tak doménový jmenný systém známý dnes často jen pod zkratkou jako DNS (Domain Name System).

Výhodou DNS je jeho distribuovanost. Jmenný prostor DNS je uspořádán tak, že se skládá z hierarchicky vzájemně propojených domén. Každá doména je menším jmenným podprostorem v celkovém jmenném prostoru s tím, že jednu doménu a její další případně podprostory spravuje daný subjekt, např. konkrétní organizace. Tím se z pohledu správy celý DNS prostor rozpadne na menší domény a vznikne tak distribuovaný model správy celého jmenného prostoru DNS. Aby celek mohl správně fungovat, jsou jednotlivé níže hierarchicky položené domény flexibilně svázány s mateřskými doménami vyšší úrovně. Domény jsou nejenom techniky svázány s mateřskými doménami, ale také i se zápisem doménového jména. 7

1.1 Hierarchická struktura jmenného prostoru DNS DNS systém a domény v něm tvoří stromovou hierarchii, která má svůj počátek v tzv. DNS kořeni (Root). Struktura se dále větví pomocí subdomén nižší úrovně a de facto končí u listů stromu, což jsou konečné názvy koncových zařízení v rámci celé dané domény. Hierarchické uspořádání DNS domén si lze asi nejlépe představit jako strom, viz obrázek. Hierarchická struktura DNS domén Podtržené názvy jmen představují název dané domény, nepodtržené názvy jsou kanonická jména zařízení (konečné listy stromu), např. serverů, s nimiž úzce souvisí konkrétní IP adresa. Jednotlivé hierarchické úrovni ve struktuře DNS jména se oddělují znakem tečky.. Celý jmenný prostor je zakotven v kořenu, který je u DNS jména představován formálně přítomností tečky, nejvíce napravo v DNS jménu. Větvení stromu DNS jména se v zápise projeví postupným zvětšením délky DNS jména od pravé tečky směrem doleva. Textovému řetězci mezi dvěma tečkami se říká návěští a de facto se jedná o nekanonické (nejednoznačné) jméno subdomény, pokud toto návěští není zcela nalevo v zápise. Návěští zcela nalevo vyjadřuje nekanonický název zařízení nebo služby. Nekanonická návěští nemusí být jednoznačná, např. návěští www se může vyskytnout ve mnoha jiných DNS jménech. Na formát a strukturu DNS jména jsou kladena jistá omezení, viz obrázek. Celé DNS jméno může být, včetně teček, dlouhé max. 255 znaků. Každé návěští musí být dlouhé max. 63 alfanumerických znaků (+ znak - ). Z hlediska přehlednosti není vhodné tvořit více DNS úrovní než 3 4. 8

Formát zápisu doménového jména systému DNS 9

1.2 DNS domény nejvyšší úrovně Hierarchicky nejvýše položené jsou jména domén, které následují po jednotném identifikátoru DNS kořene, tedy tečkou. Jako příklad uveďme třeba doménu cz. nebo doménu org., net. apod. Těmto doménám se říká domény nejvyšší úrovně TLD (Top Level Domains) a je možné je rozdělit celkem do několika tříd, podle významu jaký mají: obecné domény nejvyšší úrovně, gtld (generic Top Level Domains) s těmito do-ménami se v podstatě v době vzniku Internetu začínalo. Jejich význam spočívá v tom, že jejich jmenný podprostor (všechny subdomény a jména) mají souvislost s účelem vy-tvoření dané gtld com. edu. gov. int. mil. net. org. - komerční organizace - vzdělávací organizace - vládní instituce v USA - mezinárodní organizace - vojenské instituce v USA - síťové firmy, ISP apod. - neziskové organizace Tyto domény se ještě dále dělí na sponzorované a nesponzorované, podle toho, zdali se registrace subdomén řeší klasickou metodou předepsanou ICANN (Internet Corporation for Assigned Names and Numbers) nebo zdali jsou pravidla větvení stromu dané domény striktně dána jinou organizací (sponzorované), stld (sponsored TLD). Ke sponzorovaným TLD patří např. aero., asia., cat., coop., edu., gov., int. atd. domény zkratek zemí cctld (country code TLD) tyto domény představují zkratky zemí na světě jako je cz., be., us., fi. atd. internacionalizovaní domény IDN cctld to jsou domény zatím ve zkušebním provozu, kde se testuje možnost použití ve jménu jiné znakové sady než jen US-ASCII. infrastrukturní domény tyto domény obecně slouží pro provoz sítě, příkladem je třeba TLD doména arpa.. Jedna se subdomén ARPA domény, konkrétně in-addr.arpa., se používá pro reverzní překlad IPv4 adresy na DNS jméno apod. 10

1.3 Distribuované záznamy DNS systému Hlavní výhodou DNS systému je jeho distribuovaný charakter záznamů a taktéž i to, že správa a administrace domén je řešena bez nutnosti centrální autority. Jednotlivé záznamy DNS se ukládají na velkém počtu DNS serverů, přičemž na každém takovém serveru je uložena jen část celého jmenného prostoru. Správu každé části DNS jmenného prostoru má na starosti konkrétní autorita. Ta je většinou zodpovědná za jednu nebo i více DNS domén. V rámci domény dané úrovně lze vytvořit dalších několik subdomén nižší úrovně. Takto to může dále pokračovat. I když teoreticky na DNS serveru dané domény mohou být obsažené záznamy o všech jejích subdoménách, nerealizuje se to takto, hlavně pokud se jedná o domény vyšších úrovní, které by musely potom obsahovat velké množství záznamů, což by popíralo původní logiku a záměr vzniku DNS. V tomto případě se realizuje proces, kterému se říká delegování zodpovědnosti. Jinými slovy, vyšší doména např. CZ., deleguje zodpovědnost za spravování záznamů své níže položené domény, např. CVUT.CZ., na jinou organizaci, v tomto případě na správu sítě ČVUT. Záznamy, které patří do domény CVUT.CZ. jsou velice často fyzicky uložené na jiných DNS serverech. Vztah mezi DNS servery je naznačen na obrázku Vzájemný vztah DNS serverů Všimněme si, že celý systém DNS je zakotven v tečce napravo. Tento kmen je stmelovacím prvkem DNS, který spojuje celý strom do jednoho celku. Nejvýše položené DNS servery jsou kmenové DNS servery (DNS Root servers), které 11

udržují delegační záznamy na servery zcela všech na světě existujících nejvýše položených domén TLD. Při hledání záznamů se prvotně vychází právě z těchto serverů a postupuje se směrem dolů ve stromu DNS jmenné struktury. Kmenové DNS servery a servery TLD domén jsou téměř vždy delegačního typy, tj. udržují jen a pouze delegační údaje svých subdomén na několik serverů nižší úrovně. Na světě existuje celkem 13 kmenových DNS serverů, které jsou rozmístěné po celém světě. Přesněji řečeno se jedná o 13 IP adres, protože ve skutečnosti těchto DNS serverů je mnohem více než jen 13. Rozmístění DNS kmenových serverů lze nalézt na WEB stránce http://www.root-servers.org/. Pro Evropu je rozmístění serverů naznačeno na obrázku. Jména kmenových serverů začínají písmenem A a končí písmenem M. Umístění kmenových serverů v Evropě (zdroj:http//www.root-servers.org/) 12

1.4 Koncepce DNS domén a zón DNS záznamy se pro části jmenného prostoru ukládají v DNS serverech. Každý DNS server udržuje ve svých záznamech jistou část všech záznamů celé domény. Této části záznamů uložené většinou v jednom souvislém souboru se říká zóna a souboru, v němž jsou tyto záznamy uložené, se říká zónový soubor. Koncepčně si lze rozdíl mezi pojmem doména a zóna představit názorněji pomocí obrázku. Každá zóna je ukotvená ke konkrétní doméně, nicméně zóna není to samé jako doména. DNS doména je celou větví jmenného prostoru. DNS zóna je obecně jen část DNS prostoru s danou administrativní správou. Administrátor DNS serveru zodpovědný za danou doménu (např. cvut.cz.) ji může rozdělit do částí, subdomén (např. feld.cvut.cz., fsi.cvut.cz. ) a jejich správu delegovat na jiné DNS servery V tomto případě má typicky každá nově delegovaná subdoména své vlastní DNS servery, které obsahují záznamy (všechny nebo jen některé) těchto subdomén. Tyto servery mohou provádět delegování na další subdomény atd. Koncepce DNS domén a zón 13

1.5 Způsoby dotazování na DNS servery Služeb DNS používají nejčastěji koncová zařízení s cílem získat překlad jména jednoho jmenného prostoru na jiný. Vhodné je upozornit, že i když tato služba je asi nejpodstatnější a nejčastěji využívaná, není jedinou, kterou DNS systém poskytuje. Druhou významnou funkcí DNS je poskytnout poštovním serverům jména MTA (Message Transfer Agent) serverů, které jsou domácím poštovním serverem pro danou poštovní doménu, v níž mají uživatelé zřízen svůj poštovní účet. Se systémem DNS velice úzce souvisí i protokol DNS, pomocí něhož se uskutečňuje interakce mezi klientem a DNS serverem. Ten je v detailech specifikován v dokumentu RFC 1035. Komunikace v DNS systému je založena opět na modelu klient/server. Protokolový model DNS používá na straně koncového zařízení funkci překladač (Resolver), což je proces nebo část operačního systému zodpovědná na jedné straně za přijímání požadavků na překlad od programů či procesů na koncové stanice a na druhé straně komunikaci s DNS serverem. Překladač je také zodpovědný za dočasné ukládání již zodpovězených dotazů, aby se nemusely provádět znovu, když už byly dříve provedeny. Obecně se procesu dočasného uchovávání již zodpovězených DNS dotazů říká slangově DNS caching. V DNS systému existují dva základní typy dotazů, podle nichž se výrazně liší celý proces, jak klient získá požadované DNS informace (záznamy): rekurzivní DNS dotaz (viz obrázek) u tohoto typu dotazu se DNS překladač (resolver), běžící na klientské stanice, dotáže daného DNS serveru s požadavkem na překlad jména (např. www.fel.cvut.cz ) na IP adresu a požádá ho o doručení jen konečného výsledku, tj. požadované IP adresy. V tomto případě musí kontaktovaný DNS server provést sám několik dotazů (uvažujeme případ, kdy žádný výsledek dílčích dotazů není obsažen už v lokální DNS cache ) na jiné DNS servery, než získá požadovaný výsledek překladu, který následně pošle klientovi. Tento typ dotazu byl historicky určen pro zařízení, která neměla dostatečné prostředky (paměť, procesní výkon apod.) pro realizaci složitějšího iterativního dotazu, viz dále. Provedení rekurzivního dotazu je ale jeho dobrou vůlí, protože podle standardu není povinností DNS serveru tuto vlastnost podporovat. Ve vnitřních sítích se velice často toto používá, protože většina OS dnes má implementovanou podporu tohoto typu dotazu 14

Příklad rekurzivního dotazu na DNS server iterativní DNS dotaz (viz obrázek) v tomto případě žádá překladač (resolver) DNS server jen o zaslání odkazů (referrals) na další DNS servery, o nichž ví, že obsahují další potřebné informace, které překladači pomohou v dalším procesu prohledávání DNS distribuovaného stromu. Všimněme si, že se u tohoto typu dotazu jen přesune systém prohledávání DNS stromu z DNS serveru na překladač. 15

Příklad iterativního dotazu na DNS server 16

1.6 DNS servery Pro každou DNS zónu musí existovat jeden primární (MASTER) a minimálně jeden sekundární (SLAVE) DNS server, viz obrázek. Primární DNS server udržuje soubor zóny, který obsahuje data o dané zóně. Veškeré změny dat zóny se standardně provádějí na primárním serveru. Sekundární DNS server si pravidelně kopíruje data zóny ze serveru primárního, pokud zde dojde k jejich změně. Sekundární servery se v pravidelných intervalech (dáno v SOA záznamu pro danou zónu na primárním serveru) připojují k primárnímu serveru a zjišťují stav sériového číslo (serial number) dané zóny, pokud je toto číslo větší než dřívější, znamená to, že se data na primárním serveru změnila a je nutné provést přenos zóny. Přenos zóny se uskuteční, jen pokud je sériové číslo větší, než předchozí. Další parametry potřebné pro sekundární server(y) jsou součástí SOA DNS záznamu pro danou zónu na primárním serveru. Primární server může být nakonfigurován tak, že při změně dat zóny informuje sekundární servery automaticky o této skutečnost. Kopírování dat ale i tak aktivují sekundární servery. DNS servery 17

1.7 Typy DNS záznamů a zónový soubor V DNS serverech se uchovávají různé typy zdrojových záznamů zvaných RR (Resource Records). Mezi nejčastější používané záznamy patří: SOA (Start Of Authority) detailní informace o dané zóně A (Address) přiřazení IPv4 adresy k známému doménovému jménu zařízení (PC) nebo služby (WEB) NS (Name Server) definuje doménové jméno DNS serveru(ů), který je zodpovědný (autoritativní) za překlad jmen v dané subdoméně (delegace) CNAME (Canonical Name) definuje alias k existujícímu plně kvalifikovanému FQDN (Fully Qualified Domain Name) jménu (kanonické jméno). K jednomu FQDN může být přiřazeno i více přezdívek MX (Mail Exchanger) definuje cílový SMTP server pro danou doménu (nesmí být alias), musí být DNS jméno, nikoliv IP adresa PTR (Pointer) k IP adrese přiřazuje DNS jméno registrováno je na 60 RR typů záznamů (http://www.iana.org/assignments/dns-parameters) Jednotlivé DNS záznamy se ukládají do zónových souborů. Příklad obsahu jednoho zónového souboru jen na obrázku. Zónový soubor Zápis údajů do zónových souborů má svá přesná specifika, sémantiku a syntaxi. Vysvětleme si alespoň ty některá zásadní. Na detaily je možné se podívat do specializované literatury nebo dokumentů. Každý zónový soubor 18

obsahuje část nebo všechny informace o dané DNS doméně, např. v našem případě se jedná o doménu pokus.cz. Každá doména je v zónovém souboru blíže popsaná svým SOA (Start Of Authority) záznamem, který je asi ze všech DNS záznamů nejkomplexnější. Každá doména je v zónovém souboru blíže popsaná svým SOA (Start Of Authority) záznamem, který je asi ze všech DNS záznamů nejkomplexnější. SOA záznam určuje jméno autoritativního DNS serveru domény (ns.pokus.cz), emailovou adresu správce domény zapsanou ve speciálním formátu (hostmaster.pokus.cz=hostmaster@pokus.cz) a tyto další údaje: sériové číslo poslední změny zónového souboru (serial number) toto číslo může nabývat libovolné hodnoty v rozsahu od 0 do 4294967295 a při každé změně provedené v zónovém soboru se musí zvětšit. Dle konvence se ale toto číslo zapisuje jako YYYYMMDDSS, kde YYYY představuje rok, MM měsíc a DD den. Pokud by se zónový soubor měnil častěji než jednou denně, je zde ještě číslo SS, které potom představuje sériové číslo změny v daném dni obnovení (refresh) tento údaj definuje interval, po jehož uplynutí se sekundární server dané zóny připojí k primárnímu serveru a stáhne si z něj SOA záznam dané zóny a podívá se, zdali se změnilo její sériové číslo, tj. zjistí, zda došlo či nedošlo k modifikaci zónového souboru na primárním serveru. Pokud se zjistí, že došlo ke změně záznamu, iniciuje sekundární server aktualizace záznamů z master serveru opětovný pokus (retry) definuje, za jakou dobu se má sekundární server znovu pokusit spojit s primárním serverem, pokud předchozí pokus o spojení v rámci obnovení selhal vypršení doby (expire) pokud se nepodaří sekundárními serveru kontaktovat primární server pro danou zónu (neustálým opakováním kontaktu po periodách retry ) po delší dobu, než je uvedené v tomto parametru, přestane brát sekundární server data zóny jako platná a přestane na ně poskytovat dotazy klientům (klientem může být i jiný DNS server) min toto je perioda času, po kterou mohou být negativní záznamy (tj. záznam neexistuje) dočasně uloženy na sekundárních serverech pro danou doménu. Další zajímavostí syntaxe zónového souboru je používání znaku @. Toto je zástupný znak, který značí, že se jeho výskyt má zaměnit za argument v klíčovém slově $ORIGIN. Konkrétně v našem případě to znamená, že se místo znaku @ dosadí textový řetězec pokus.cz.. Důležitou zajímavostí vytváření zónových souborů je automatické doplnění jména DNS o argument klíčového slova $ORIGIN, které nekončí napravo tečkou. Takže, ve výše uvedeném souboru např. doménové jméno ppp bude automaticky rozvinuté do jména ppp.pokus.cz., tj. doplněné o textový argument proměnné $ORIGIN pokus.cz.. I když se v praxi při psaní doménových jmen často vynechává psaní poslední tečky napravo identifikující kmen DNS a v zásadě to ničemu nevadí. Při psaní DNS zónových 19

souboru má uvedení či neuvedení pravé tečky v doménovém jménu velký význam. Význam dalším RR záznamů v uvedeném příkladě je zřejmý. První dva NS záznamy udávají odkazy na doménové servery vlastní zóny. Další NS záznam je delegačním záznamem, který se uvádí jméno DNS serveru na němž jsou další záznamy subdomény ppp domény pokus.cz.. Následující A záznamy udávají překlad DNS jmen na příslušné IPv4 adresy. DNS systém používá pro dotazy a odpovědi UDP protokol s port 53. Pro specializované případy transferu záznamů mezi DNS servery se používá transportní protokol TCP se stejným portem. 20

2 Systém přenosu elektronické pošty a protokol SMTP Systém elektronické pošty, E-mail (Electronic Mail), patří dnes patrně k nepoužívanějším služ-bám v Internetu a spolu se službou WWW (World Wide Web) de facto tvoří komunikační pro-středek pro miliony lidí na celém světě. Jak je známo, E-mail a WWW jsou také nejpoužívanější služby nejen v univerzitním prostředí, z něhož v podstatě kdysi dávno vzešly, ale také v komerčním elektronickém světě. I když podstata výměny zpráv, jakou je i E-mail, je známá a používaná po staletí ve formě klasické pošty, její hojně využívanou elektronickou verzi spatřilo světlo světa až s příchodem Internetu. Je dlužno dodat, že elektronická forma výměny zpráv je dokonce starší než Internet sám, protože byla používána v nezasíťované podobě již v době sálových počítačů. V následujících kapitolách stručně popíše základní architekturu systému elektronické pošty. 21

2.1 Architektura elektronické pošty Základní architektura elektronické pošty je nakreslena na obrázku. Uživatelský program, který je zodpovědný za styk s uživatelem budeme pro účely našeho výkladu považovat za uživatelského agenta. Základní architektura elektronické pošty Dnes existuje celá řada programů, které lze v této úloze použít jako je např. Mozilla Thundebird, Microsoft Office Outlook, Pegasus Mail, KMail, em klient, Elm, GNUMAil, GNus, Mutt, atd. Jak je vidět existuje vcelku velké množství E-mail klientů, které si uživatel může vybrat podle svých potřeb a funkcí, který ten či onen program poskytuje. Klientský program umožňuje uživateli snadné psaní E-mailu a také jejich čtení. Nezbytnou funkcí je i možnost třídění zpráv a snadné hledání podle různých kritérií. E-mail klienty lze rozlišit také podle podpory operačního systému a zda jsou graficky (okna) nebo textově orientované. Dnes jsou pro běžné uživatele velmi rozšíření graficky orientované E-mail klientské programy. Textově orientované verze se stále ještě používají, ale spíše u více odborně orientovaných uživatelů. Pro vysvětlení funkce současných protokolů pro přenos elektronické pošty lze použít analogii s klasickým poštovním systémem. Předpokládejme například, že Tomáš chce poslat doporučený dopis Petrovi. Tomáš napíše zprávu na listy papíru a vloží je do obálky. Dolů vpravo na její přední stranu napíše adresu Petra a do horní levé části adresu Tomáše (zpáteční adresa). Je běžnou praxí psát zpáteční adresu na obálku, protože kdyby poštovní služba zjistila, že Petrova adresa, jak je uvedena na obálce, nebyla správná (nebo byl jiný problém s doručením), bylo by možné vrátit dopis zpět odesílateli. Tomáš následně vhodí dopis do podací poštovní schránky. Poštovní služba si dopis ze schránky vyzvedne a doveze jej, spolu s ostatními od jiných odesílatelů na poštovní úřad. Tam se dle adresy Petra určí místo určení (geografická poloha) jeho poštovní výběrové schránky. Následně pošta rozhodně jakými dalšími poštovními uzly musí dopis projít, aby doručení bylo finančně efektivní. Konečným výsledkem procesu doručení 22

klasické pošty je vhození daného dopisu do poštovní schránky Petra, z níž si jí Petr dříve či později vyzvedne. Současné elektronické protokoly přenosu pošty používají podobnou technologie ukládání a předávání E-mailu. To tedy znamená, že uživatel může napsat zprávu a poslat ji na konkrétní počítač připojený k Internetu. Tato zpráva je následně elektronicky poslána do poštovní schránky příjemce, který si ji může kdykoliv vyzvednout. Základní charakteristikou E-mailové služby je její asynchronnost, které ji dělá do jisté míry přitažlivou. Uživatelé si totiž nemusí číst zprávy okamžitě, ale jejich čtení je dáno možnostmi příjemce, který sám rozhoduje, kdy dané zprávy bude číst a bude na ně odpovídajícím způsobem reagovat. Toto umožňuje flexibilní plánování ze strany příjemce, který nemusí reagovat na zprávy ihned, když dojdou. Díky asynchronní vlastnosti nelze tedy zajistit, aby byl příjemce vždy k dispozici pokaždé, když si zdroj zprávy vzpomene. Dnes je běžné, že počítače jednotlivých uživatelů se často vypínají (např. v nočních hodinách), často se přemisťují (různé sítě) a také, uživatelé nejsou často pevně svázáni s konkrétním počítačem. E-mail tuto záležitosti řeší tak, že přijímací poštovní schránky nejsou realizovány přímo na počítačích uživatelů, ale naopak na specializovaných poštovních serverech, které běží nepřetržitě a lze se k nim kdykoliv připojit. V tomto ohledu je zde zásadní rozdíl mezi klasickou poštou a její elektronickou verzí. Zatímco u klasické pošty je doručovací schránka co nejblíže koncovému uživateli, u elektronického systému je vždy na centrálním serveru, z něhož si poštu každý uživatel vybírá individuálně. Je to tedy spíše obdoba systému P.O. boxů. K poštovním serverům se ještě později vrátíme. Nyní se nepodívejme na podstatu systému adres u elektronické pošty. Tak jako u klasické pošty existuje více či méně ustálený formát jak určit adresáta, je tomu podobně i u elektronické pošty. 23

2.2 Adresa u elektronické pošty U klasické pošty se adresou blíže specifikuje geografická poloha adresáta. To lze a má smysl jen tehdy, pokud se uživatel v dané lokalitě často nachází a má tedy možnost si poštu vyzvedávat. U elektronické verze se toto takto nedělá. Rozumným požadavkem je, aby poštovní server, kde má uživatel svou elektronickou verzi schránky nebyl topologicky (síťově) příliš vzdálen od místa, kde se uživatel k síti připojuje a aby připojení bylo rozumně rychlé. V dnešní době rychlého Internetu, ale ani tento požadavek není často splněn. Je např. možné se připojovat k Internetu v ČR a míst schránku elektronické pošty v USA nebo kdekoliv jinde na světě. Celá adresa u elektronické pošty musí být jednoznačná, protože s každou adresou je pevně spjatá konkrétní elektronická schránka na daném poštovním serveru. Pokud by toto bylo porušeno, byla by pošta doručována jinam, než kam má být. Formát elektronické pošty Jak je patrné z obrázku, skládá se E-mailová adresa ze dvou částí. První část ID_uživatele jednoznačně určuje uživatele v rámci domény. Tento identifikátor nemusí být celosvětově jednoznačný. Druhá část za uvozujícím znakem @ určuje jméno domény, v níž musí být část ID_uživatele jedinečná. Celá adresa musí být celosvětově jednoznačná. Část jméno_domény je dále strukturovaná podle pravidel doménových jmen DNS používaných v Internetu (viz další kapitola). Na E-mailovou adresu jsou kladeny ještě další požadavky, jejichž popis je nad rámec tohoto základního textu. Odkazujeme v tomto případě na příslušné dokumenty jako je RFC 5321 nebo RFC 5322 a další. 24

2.3 Protokol pro přenos zpráv elektronické pošty Elektronickou zprávu (Email) je nutné nejprve vytvořit a poté podat do systému elektronické pošty, který zajistí její správné doručení do schránky příjemce. Zprávu elektronicky přenese (podá) uživatelský program (MUA) na pozadí uživatele prvnímu domovskému MTA agentovi v cestě, viz obrázek. Zde se zpráva dočasně celá uloží a následně se pošle dál k dalšímu MTA agentovi. Ve finále dojde k MTA příjemce, kde se uloží do elektronické schránky (většinou ve formě souboru). Příjemce se asynchronně připojuje, prostřednictvím svého uživatelského programu (MUA) ke svému domovskému MTA a stáhne si poštu na svůj počítač. Základní architektura elektronické pošty V uživatelském programu mailu je proces odesílání a příjmu zpráv zcela oddělen. K odesílání se používá zcela jiný protokol než pro příjem. Části MUA, která se stará o podání pošty se říká agent podání zpráv MSA (Message Submission Agent) a části, která se naopak stará o příjem zpráv se říká agent pro doručování zpráv MDA (Message Delivery Agent). U elektronické pošty hraje velice důležitou roli protokol přenosu zpráv SMTP (Simple Mail Transfer Mail Protocol). Tento protokol byl původně určen hlavně pro přenos zpráv mezi MTA agenty navzájem, nicméně postupem doby se začal používat i pro podávání Email zpráv uživatelem do domovského MTA, který potom posílá zprávy dál do Internetu. I když historicky mohl koncový uživatel doručit Email přímo do domovského MTA příjemce, dnes se toto již nedělá a dokonce je to často i zakázané. Důvodem je problém s nevyžádanou poštou, která je hlavním trnem v oku celého Email systému. Právě systémy nevyžádané pošty hojně využívají této možnosti přímého doručení, aby skryly svou identitu. Proto musí nejprve uživatel předat svou zprávu poštovnímu serveru, který je autoritativní posílat z dané domény odesílatele zprávy do Internetu. Úlohou serveru je také při přenosu zpráv v Internetu použít standardizovaný protokol SMTP. 25

2.4 Struktura a formát elektronické pošty Elektronický zpráva musí mít specifický formát podle RFC 5322. Každá zpráva se skládá (viz obrázek): záhlaví (header) a tělo zprávy (message body) Struktura Email zprávy Záhlaví každé zprávy se skládá z určitého počtu záznamů, které lze rozdělit dle funkce do určitých množin: sledovací záhlaví záhlaví odesílatele záhlaví adresáta záhlaví identifikující zprávu volitelná záhlaví. Význam výše uvedených záznamů záhlaví je uveden na obrázku. Sekce celého záhlaví je oddělená od sekce těla zprávy identifikátorem nové řádky CRLF (Carriage Return/Line Feed). Základní tělo zprávy nese textovou informaci, která musí být kódována ve znakové sadě ASCII (American Standard Code for Information Interchange), což je dáno především historicky. Vzhledem k omezení, které ASCII znaková sada představuje pro mezinárodní prostředí a také pro přenos obsahu jiných datových objektů, bylo specifikováno víceúčelové rozšíření zvané MIME (Multipurpose Internet Mail Extensions), které dovoluje přenášet tělem zprávy různá data s odlišnými znakovými sadami a kódováním. MIME také přináší možnost přenosu více datových objektů jedním mailem. Příklad MIME zakódované části Email zprávy je možné vidět na dalším obrázku. MIME formátované informace se identifikují záhlavím s názvem MIME- Version. 26

Příklad formátu bloku dat podle MIME standardu 27

2.5 Přenos elektronické zprávy, SMTP protokol K přenosu elektronických zpráv (mailů) mezi MTA se používá protokol SMTP (Simple Mail Transfer Protocol). Ten k tomu používá transportní protokol TCP s tím, že přijímací proces naslouchá na portu 25. SMTP je standardizován v dokumentu RFC 5321. SMTP protokol je znakově orientovaný protokol, což je jednou z jeho velkých výhod, protože se dá velice jednoduše ladit a dále zpracovávat. Celý proces přenosu zprávy mezi dvěma MTA se uskutečňuje v několika fázích. Předně, protokol SMTP je založen na modelu klient/sever, což v tomto případě znamená, že MTA, který vysílá zprávu, vystupuje v roli klienta, tj. žádá o službu přenosu zprávy cílový MTA (nebo další v pořadí), který naopak zastává roli serveru. První fází komunikace SMTP protokolu (viz obrázek) je vytvoření TCP spojení mezi klientským MTA a serverovým MTA. Po navázání spojení pošle MTA server uvítací SMTP zprávu MTA klientovi, kterou se mu identifikuje (poetičtěji se mu představí). Odpovědi SMTP serveru jsou strukturované tak, že začínají nejprve číslem a poté textovým řetězcem, který je pro člověka lépe srozumitelný. Úvodní číslo se ale zase lépe zpracovává strojově, než klasický text, který se může někdy implementace od implementace lišit. Jednoduchý příklad SMTP komunikace Následuje představení klientské strany SMTP protokolu pomocí příkazu HELO+textový řetězec. Dále následuje skupina příkazů, které se někdy říká vnější obálka dopisu. Předně je to příkaz MAIL FROM:, kterým identifikuje skutečný odesílatel zprávy svou identitu. Ve většině případů klasických mailů to bude stejný identifikátor, jaký je také uveden v záhlaví zprávy v poli From:, ale také tomu tak být nemusí. Na tyto detaily odkazujeme na příslušný standard. V okamžiku, kdy SMTP server zná emailovou identitu odesílatele a je ochoten od něj zprávu převzít a doručit dál, pošle SMTP klientovy pozitivní potvrzovací zprávu a ten tedy může pokračovat dalším příkazem RCTP TO:, v němž uvede emailovou adresu adresáta. Pokud je třeba doručit identický email více adresátům současně, klient zadá více RCPT TO: příkazů, vždy s příslušnou emailovou adresou. Pokud server 28

akceptuje konkrétního adresáta, vrátí vždy na odpovídající příkaz RCPT TO: pozitivní odpověď. Vlastní datový obsah zprávy se předá příkazem DATA, který informuje SMTP server, že následuje obsah vlastní zprávy. Klient ale může začít posílat svá data zprávy až po příjmu pozitivní odpovědi od serveru (viz řádek s kódem odpovědi 354). Po předání všech bajtů zprávy se její konec indikuje ASCII znakem tečky. začínajícím jako první na samostatném řádku. Pokud je vše v pořádku, server pozitivně odpoví, že zprávu zařadil do fronty, a že ji bezprostředně odešle. SMTP spojení aktivně ukončí klient příkazem QUIT. Na tento příkaz reaguje SMTP server zprávou o aktivním rozpojení TCP spojení, které následně také uzavře. Výše uvedený proces SMTP je jen ukázkou té nejjednodušší formy SMTP komunikace, která tedy nemůže postihnout všechny detaily! Na detaily funkce SMTP je nutné se blíže podívat do samotného standardu. 29

2.6 Protokoly pro čtení a zpracování emailových zpráv Jak již bylo řečeno, elektronicky doručené zprávy se ukládají do elektronických schránek na domovských poštovních serverech. Aby je uživatel mohl přečíst, musí se k těmto zprávám dostat. Toto lze zajistit buď nestandardizovaným způsobem (tzv. proprietární řešení) nebo pomocí nějakého nejlépe veřejně dostupného protokolu. Dnes výhodnějším a také mnohem flexibilním řešení je použití druhé možnosti. Pro manipulaci (čtení, mazání, třídění atd.) s doručenou poštou se dnes setkáme s těmito dvěma protokoly: POP3 (Post Office Protocol version 3), RFC 1939, RFC 2449 a RFC 1734, IMAPv4 (Internet Message Access Protocol version 4), RFC 3501, Historicky prvním protokolem byl první jmenovaný. Novější protokolem je potom IMAP. Podívejme se nyní stručně, jak pracuje protokol POP3. 30

2.7 Funkce protokolu POP3 POP3 protokol je velice jednoduchý protokol pro stažená emailových zpráv ze schránky domovského poštovního serveru. Tak jako většina protokolu, tak i POP pracuje v režimu stavového automatu, který má celkem pět stavů, viz obrázek. POP protokol používá model komunikace klient server, přičemž v tomto případě vystupuje uživatelský program MUA v roli klienta a poštovní server, který má přístup do poštovní schránky, v roli serveru. Přenos příkazů a dat se uskutečňuje opět pomocí transportního protokolu TCP, přičemž POP server naslouchá na příchozí požadavky TCP spojení na portu 110. Komunikaci si řídí POP3 klient zasíláním příkazů POP3 serveru. Soubor příkazů uvádí Konečný automat protokolu POP3 První fází je tedy navázání spojení TCP klientem na port 110. Pokud je spojení úspěšné, bude mezi klientem a serverem funkční obousměrný datový kanál, jímž mohou obě strany mezi sebou komunikovat. Následně po navázání spojení se POP3 server klientovi představí uvítací a identifikační zprávou ve formě jedné řádky. Následuje fáze autentizace, kdy je nutné, aby se POP3 serveru klient autentizoval. Autentizace se provádí příkazy user a pass s odpovídajícími argumenty uživatelského jména a hesla. Pokud autentizace proběhne v pořádku, může klient přejít do fáze transakce. V této fázi si lze, např. použitím příkazů LIST, RETR a DELE, nechat vypsat seznam doručených zpráv, stáhnout zprávy nebo zprávy označit k následnému vymazání. Fázi transakce klient opouští příkazem UPDATE, čímž se definitivně příkazem DELE označené zprávy vymažou. 31

2.8 Protokol IMAPv4 POP3 protokol je sice jednoduchý, ale neposkytuje celou řadu funkcí, kterou dne běžný uživatel vyžaduje, jako: je možnost přístupu k poštovní schránce z více míst najednou, třídění a umisťování zpráv pošty do různých zásuvek, prohledávání zpráv podle různých kritérií, selektivní stahování jen určitých částí mailu (např. jen hlaviček bez příloh, které se musí POP3 protokolem stáhnou také) a jiné. Tyto nevýhody výrazně odstraňuje právě protokol IMAPv4, který je ale mnohem složitější. Pro jeho funkci odkazujeme na výše zmiňované RFC dokumenty. 32

3 Systém přenosu dat u WWW služeb a protokol HTTP WWW (World Wide Web) je uživatelská aplikace určená původně jako náhrada služby GOPHER. Historicky umožňovala a stále umožňuje uživateli získat snadný přístup k hypertextově orientovaným dokumentům. Tyto dokumenty byly dříve v prvopočátcích hlavně textově orientované bez podpory jiného multimediálního obsahu. S postupem doby začaly tyto dokumenty podporovat i jiné jazyky než angličtinu a hlavně nový multimediální obsah (nejprve obrázky, poté zvuk a v neposlední řadě video a animace). Dnešní WWW dokumenty jsou smíšenou kombinací multimediálního obsahu. Pro prohlížení hypertextových dokumentů slouží WWW prohlížeče, slangově nazývané jako browsery. Jako příklad uveďme Internet Explorer, Opera, Mozilla, Safari, Konqueror, Lynx a další. Každý prohlížeč je aplikací, která je typicky naprogramována tak, že běží víceprocesně a multivláknově v daném operačním systému počítače. Struktura hypertextových dokumentů se popisuje pomocí jazyka HTML (HyperText Markup Language). Služba WWW je založena na modelu komunikace klient/server. 33

3.1 Model HTTP komunikace Vlastní komunikace probíhá mezi WWW klientem (prohlížečem) na jedné straně a WWW serverem na straně druhé protokolem zvaným HTTP (HyperText Transfer Protocol). Komunikace protokolem HTTP je založena na jednoduchém principu dotaz/odpověď. Klient HTTP dotazy žádá WWW server o zaslání specifického hypertextového dokumentu nebo přímo konkrétního datového objektu (soubor s daty obrázku, videa, zvuku, tabulky, formuláře atd.). WWW server přijetím dotazu pošle zpět klientovy požadovaný obsah daného zdroje objektu (zdrojového objektu), včetně jeho metainformací (=informace o informaci). Existují dva modely komunikace http protokolem v módu klient/server. První, zobrazený na obrázku, používá přímou datovou komunikace mezi HTTP klientem a HTTP serverem prostřednictvím datové sítě založené na architektuře TCP/IP (reprezentované na zmiňovaném obrázku symbolem mráčku). HTTP protokol vyžaduje spolehlivé datové spojení v obou směrech přenosu. I když tento požadavek lze v praxi splnit různým způsobem, nejčastější je použití transportního protokolu TCP. WWW server v tomto jednoduchém případě se nazývá původním serverem proto, protože datové zdroje objektů předávané protokolem HTTP zpět jednotlivým klientům jsou na tomto serveru uložené. Zde je nutné si uvědomit, že v souvislosti s rozšířením datových center, virtualizace a cloud řešení, je dnes otázka lokálního uložení dat poněkud nepřesná. Ve skutečnosti jsou dnes data ukládána na disková pole, která jsou sice velmi často blízko WWW serveru (v rámci datového centra), avšak v některých případech tomu tak být vůbec nemusí. Jednoduché schéma komunikace HTTP Druhý, komplexnější model komunikace je naznačen na dalším obrázku. V tomto případě se mezi WWW klienta a server vkládá ještě množina HTTP Proxy serverů nebo dokonce v ojedinělýh případech i HTTP tunel. HTTP proxy servery mohou plnit celou řadu rozmanitých funkcí jako např. autentikační služby (tj. poskytnutí přístupu ke zdrojovému serveru po provedení autentizace) 34

filtrace a modifikace obsahu (selektivní zamezení přístupu k určitým zdrojům na WEBu, změna rozměrů obrázku, překódování obsahu, apod.) dočasné uložení informace pro šetření přenosových prostředků (kapacita sítě), tzv. caching Komplexní schéma komunikace HTTP V praxi existuje celá řada Proxy serverů, které se nazývají různými jmény, typicky podle konkrétní funkce, kterou ve WWW službě plní: WWW cache proxy (dočasné uchování obsahu) WWW autentizační proxy (povolení přístupu k volným zdrojům po autentizaci) Filtrační WWW Proxy (selektivní filtrace zakázaného obsahu WEBu) Anonymizační Proxy (anonymizace přístupu k Webu, skrytí za Proxy) reverzní WWW proxy (konsolidace několika Web serverů za jeden Proxy server) 35

3.2 Reference na informační zdroje WWW Služba WWW je ve své obecné rovině založena na dvou základních pilířích. Jedním z nich je popis struktury multimediálního dokumenty a druhým je vlastní datový obsah dokumentu. Tak jako celá řada dalších komponent služby WWW, musí být i popisný jazyk struktury dokumentu standardizovaný, jinak by nebylo možné, aby odlišné prohlížeče a servery si vzájemně rozuměly. Jak již bylo popsáno dříve, WWW používá pro popis struktury dokumentu nejčastěji jazyk HTML. Tento jazyk však není jediným, který lze v této roli použít. Jako příklad lze uvést XHTML, XML, C-HTML, atd. Těchto jazyků je celá řada, jen jsou poněkud v pozadí HTML. Stejně jako každý jiný datový objekt, či datový zdroj, ve službě WWW, tak i objekt popisují strukturu dokumentu lze chápat zcela obecně jako další datový objekt podobný tomu co představuje např. objekt obrázku, videa, apod. Je více než zjevné, že dnešní jedna WWW stránka libovolné multimediální informace v Internetu představuje celou řadu objektů, které je nutné od sebe odlišit, určit místo, kde ten či onen objekt nachází, a definovat formu či protokol, jak se lze k tomuto objektu lze dostat. K tomuto účelu byl vytvořen obecný koncept založený na využití universálního identifikátoru zdroje, URI (Universal Resource Indentifier), viz obrázek, kde je také naznačen význam jednotlivých částí URI. Pro WWW službu se využívá speciální případ URI s metodou přístupu protokolem HTTP nebo HTTPS, který se nazývá univerzální lokátor zdroje, URL (Universal Resource Locator). Reference na informační zdroje 36

3.3 HTTP protokol HTTP je protokol pro přenos obsahu hypertextově orientovaných elektronických dokumentů od WWW serveru ke klientovi. Ten si ale musí nejprve o informace požádat a uvést o jaký zdroj se jedná specifikováním jeho URL. Celý HTTP protokol je textově (ASCII) a řádkově orientovaný, každá řádka je ukončena povinně kombinací znaků <CRLF> (0x0d,0x0a). HTTP protokol je bezestavově orientovaný (není s ním spojen žádný konečný automat, protože nemá žádné interní stavy). To, že HTTP byl navržen prvotně jako bezestavový bylo dáno požadavkem jednoduchosti, nicméně později v době rozmachu WWW služeb a další sofistikací WWW aplikací toto zjednodušení vedlo u k problémům, stavovost se tedy později implementuje metodami jako je např. nastavení cookies (otázka bezpečnosti), skrytými formuláři, nebo SESSION proměnnými. HTTP zprávy se dělí na HTTP_dotazy (requests) a HTTP_odpovědi (responses), viz obrázek. Formát HTTP zpráv Na dalším obrázku je znázorněn formát řádku HTTP požadavku, který vytváří WWW klient. Prvním údajem je typ HTTP metody, která určuje co se má s daným objektem provádět za operaci a jakým způsobem bude tento objekt zpřístupněn. Metody HTTP budou blíže probrány v následující kapitole. Dále následuje znak mezery (<SP>) a za ním bezprostředně identifikátor zdroje URI (v případě WWW služby spíše URL). Po něm následuje klíčové slovo udávající verzi HTTP protokolu. Celý řádek požadavku končí znakem odřádkování. 37

Řádek HTTP požadavku 38

3.4 Metody HTTP protokolu Protokol HTTP používá pro jednotlivé požadavky koncepci metod. Nepřesně řečeno, HTTP metoda určuje, jak se má s daným datovým objektem pracovat. I když HTTP standard definuje osm metod, pravdou je, že se v praxi nejčastěji používají jen dvě, a to GET a POST. Další se využívají je pro speciální účely (HEAD, OPTIONS, TRACE) a zbývajíc téměř vůbec ně, nebo dokonce se jejich použití z bezpečnostním důvodů nedoporučuje. Popišme si nyní stručně význam jednotlivých HTTP metod: GET metoda - umožňuje klientovi požádat Server o zaslání obsahu konkrétního datového objektu (HTML dokument, obrázek, zvuk, obecný soubor, video, ). Tato metoda patří dnes k nejpoužívanějším metodám HTTP protokolu vůbec, umožňuje předávat na WEB server i detailnější specifikaci o zdroji. Tato metoda je u serverově dynamických WEB stránek často skriptována a považuje se za tzv. bezpečnou, tj. její volání může být opakované bez konkrétního vlivu na stav serveru, tedy, tato metoda může být vyvolána prohlížečem i bez explicitní nutnosti informovat o tomto uživatele (měla by být používána Weboty) POST metoda umožňuje, aby klient mohl zaslat na WWW Server další nové informace. Dnes je tato metoda nejčastěji používána ve spojitosti s odesíláním dat WWW formulářů, včetně případných souborů. V metodě POST určuje URI většinou aplikaci (skript), který převezme od WWW serveru data zasílaná v těle metody POST, tato metoda není považována za bezpečnou a jako taková musí být její aktivace potvrzena vždy uživatelem (např. nutností stisknutí tlačítka ODESLAT (SUBMIT), prohlížeč má dle standardů zakázáno bez vědomí uživatele automaticky generovat POST dotazy, protože POST metoda může souviset např. s odesláním závazné objednávky. PUT metoda umožňuje klientovi zaslat na server na konkrétní URI daný obsah přiložený v těle PUT metod. Je to jistý ekvivalent nahrání souboru protokolem FTP do požadovaného adresáře. Tato metoda není u dnešních prohlížečů příliš používána, taktéž u serverů je nutné ji speciálně aktivovat a nastavit. Metoda PUT je ale efektivnější pro upload souborů než dnes často používaná metoda POST, kde je nutné soubor předávat v multiformátovém těle. U PUT metody je obecně problém s přidáním požadovaného souboru do stromu WWW, což není obecně považováno za bezpečné, PUT metody jsou často skriptované, než přímé (tj. kdy by WWW server přímo zapsal soubor do adresářového stromu WWW) DELETE metoda je opakem PUT metody, kde se však jedná o smazání zdroje (tedy URI definovaného souboru), ostatní platí podobně jako u metody PUT HEAD metoda je ekvivalentní metodě GET, jen s tím rozdílem, že WWW Server nevrací vlastní obsah, ale jen hlavičky (důležité pro aplikace, kdy nás 39

nezajímá vlastní obsah, ale jen informace o daném zdroji tzv. metainformace) použití pro proxy servery, vyhledávací roboty, atd. TRACE metoda umožňuje ladit přenosový řetězec HTTP, kdy WWW Server vrací zpět ke klientovi to, co sám přijal. Takto lze zjistit, jaké úpravy v daných HTTP dotazech provedly případné WEB HTTP proxy servery v cestě, je to jakási forma HTTP Echo OPTIONS metoda umožňuje klientovi zjistit, jaké metody jsou platné pro konkrétní zdroj URI, popř. pro celý WWW server CONNECT metoda umožňuje klientovi požádat WWW proxy o vytvoření čistého tunelového spojení mezi klientem a specifikovaným serverem a jeho portem, po úspěšně provedeném spojení nezasahuje proxy do tunelovaných dat, pro vytvoření tunelu je nutné z hlediska bezpečnosti předat ještě v dotazu s touto metodou autentizační údaje, tato metoda může představovat bezpečností riziko 40

3.5 Základní model funkce serveru WWW WWW server původu je typem HTTP serveru (viz model na obrázku), který je držitelem původního obsahu daného zdroje. Server původu je dnes nejčastěji řešen spojením vlastního WWW serveru a skriptovacího překladače. Úkolem skriptovacího překladače je vytváření dynamického obsahu dokumentů na základě od uživatele předaných vstupních dat serveru. Statické WWW informace jsou předány klientovy přímo serverem. Dynamicky generované stránky na straně serveru vyžádané klientem nejprve projdou skriptovacím překladačem a teprve jeho výstup je předán WWW serveru a ten jej dále předá přes síť klientovi. WWW server a skriptovací překladač lze integrovat do jednoho celku aplikace. Model WWW serveru 41

3.6 Základní model funkce klienta WWW Web klient se někdy nazývá odborně jako uživatelský agent UA (User Agent). Ve většině případů je UA reprezentován programem WEB prohlížeče, který tvoří rozhraní mezi člověkem a WWW službou. Existují však i jiní UA, kteří jsou reprezentovány samočinně běžícími programy, jejichž přímá interakce s člověkem není zapotřebí, jedná se o tzv. WWW roboty (WEBoty), které provádějí různé funkce, např. vyhledávání dat na různých WWW serverech a jejich indexování (ty jsou základem vyhledávacích služeb v Internetu jako je Google, Atlas, Seznam, apod.) Dnes existuje velké množství WEB prohlížečů - Firefox, Lynx, Konqeror,Internet Explorer, Opera, atd. Každý prohlížeč v sobě integruje (viz obrázek): grafické okno prohlížeče URI řádek, kam uživatel zadává URI požadovaného dokumentu HTML vykreslovač (renderer) zodpovědný za prezentaci obsahu HTML dokumentu v okně prohlížeče podpora skriptovacích jazyků umožňuje vytváření dynamických DHTML stránek na straně uživatele podpora modulů rozšířené funkce třetích stran (plug-in) umožňuje nezávisle na jazyce HTML vytvářet obsahově bohaté rozhraní uživatele, např. FLASH, koncepce RIA (Rich Internet Applications) WEB aplikací Model WWW klienta 42