DNS - Cedupoint

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.
- komerční organizace
edu.
- vzdělávací organizace
gov.
- vládní instituce v USA
int.
- mezinárodní organizace
mil.
- vojenské instituce v USA
net.
- síťové firmy, ISP apod.
org.
- 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
(http://www.iana.org/assignments/dns-parameters)
typů
záznamů
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 „MIMEVersion“.
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
3.7 Závěrečný test
1. Jednotlivé hierarchické úrovně ve struktuře DNS jména se oddělují
znakem
a) tečky
b) dvojtečky
c) pomlčy
d) podtržítka
správné řešení: a
2. Celé DNS jméno může být, včetně teček, dlouhé max.
a) 255 znaků
b) 64 znaků
c) 512 znaků
d) není omezeno
správné řešení: a
3. Každé návěští musí být dlouhé max.
a) 255 znaků
b) 64 znaků
c) 512 znaků
d) není omezeno
správné řešení: b
4. DNS systém je
a) centralizovaný
b) distribuovaný
c) spravovaný vládou USA
d) spravovaný Spojenými národy
správné řešení: b
43
5. Kmenové DNS servery a servery TLD domén
a) jsou vždy delegačního typu
b) jsou někdy delegačního typu
c) nejsou téměř nikdy delegačního typu
d) jsou jen na území USA
správné řešení: a
6. Komunikace v DNS systému je založena na modelu
a) klient/server
b) peer2peer
c) server/server
d) kleint/klient
správné řešení: a
7. Jak se nazývá softwarová komponenta v klienské stanice zajišťující
překlad DNS
a) překladač (resolver)
b) nemá jméno
c) revolver (DNS rotátor)
d) DNS klient
správné řešení: a
8. DNS totaz, který vede k získání odpovědi s úplnými informacemi o DNS
dotazu ze strany DNS klienta se nazývá
a) rekurzivní
b) interattivní
c) nemá jméno
d) úplný
správné řešení: a
44
9. DNS totaz, který vede k získání odpovědi jen s částečnými informace
o DNS dotazu ze strany DNS klienta se nazývá
a) rekurzivní
b) interattivní
c) nemá jméno
d) úplný
správné řešení: b
10. Typ DNS zdroje (RR resource), který spojuje platnou IP adresu
k danému DNS jménu se označuje v zónovém souboru příznakem
a) A
b) SOA
c) NS
d) MX
správné řešení: a
11. Typ DNS zdroje (RR resource), který spojuje kanonické jméno stroje
nebo služby s platnou přezdívkou se v DNS zónovém souboru označuje
příznakem
a) CNAME
b) SOA
c) NS
d) MX
správné řešení: a
12. Protokol používaný pro přenos elektornickcýh zpráv (Email) mezi MTA
agenty poštovního systému se zkratkou nazývá
a) SMTP
b) SNMP
c) CMIP
d) CIF
správné řešení: a
45
13. Moderní protokol, který umožňuje snadné třídění doručených mailů,
jejich řazení do různých složek, vícenásobné připojení k poštovní
schránce, atd. se ve zkratce nazývá
a) IMAPv4
b) POP1
c) POP3
d) CMIP
správné řešení: a
14. Jednoduchý protokol pro stažení doručených emailů se nazývá
a) IMAPv4
b) POP1
c) POP3
d) CMIP
správné řešení: c
15. Jaká HTTP metoda se dnes používá pro předání dat na WWW server
v případě HTML formluře
a) POST
b) GET
c) PUT
d) CONNECT
správné řešení: a
16. Jaká HTTP metoda se dnes používá pro předání dat na WWW server
v případě HTML odkazu
a) POST
b) GET
c) PUT
d) CONNECT
správné řešení: b
46
17. HTTP protokol používá pro přenso zpráv mezi WWW klientem
a serverem transportní protokol zvaný
a) TCP
b) UDP
c) STCP
d) APCT
správné řešení: a
18. Multimediální zprávy se přenáší SMTP protokolom pomocí rozšíření,
které se označuje zkratkou
a) MIME
b) NIME
c) není žádné takové rozšíření
d) MULMED
správné řešení: a
19. Jaká HTTP metoda je akvivalentní metodě GET s tím, že se vrací jen
HTTP hlavičky a ne obsah dat
a) HEAD
b) POST
c) PUT
d) CONNECT
správné řešení: a
47