Internet, intranet a elektronickß poÜta u₧ dnes neodmysliteln∞ pat°φ k naÜφ ka₧dodennφ prßci s poΦφtaΦi. Podφvejme se na n∞kterΘ z prvk∙, kterΘ jsou jejich zßkladem.
Jednoduch² protokol pro p°enos poÜty (Simple Mail Transfer Protocol, SMTP) slou₧φ k p°enosu elektronickΘ poÜty mezi stanicemi sφtφ TCP/IP. P°enos elektronickΘ poÜty je spolu s prohlφ₧enφm WWW strßnek patrn∞ nejrozÜφ°en∞jÜφ aplikacφ v sφtφch TCP/IP. SMTP pou₧φvß ke svΘ Φinnosti port s Φφslem 25. Architektura protokolu je uvedena na obr. 1. SMTP definuje pouze zp∙sob komunikace mezi koncov²mi uzly (User Agent, UA) a poÜtovnφmi servery (Message Agent Server), avÜak nezab²vß se jejich formßtem Φi implementacφ. Mezi dv∞ma koncov²mi uzly m∙₧e le₧et v∞tÜφ mno₧stvφ poÜtovnφch server∙.
Protokol SMTP definuje pouze p°enos zprßv elektronickΘ poÜty prost°ednictvφm transportnφho spojenφ TCP s pou₧itφm sedmibitov²ch ASCII znak∙ formßtovan²ch do °ßdk∙ s odd∞lovaΦi CR a LF (nßvrat vozφku a konec °ßdku).
Formßt zprßv odpovφdß samostatnΘmu doporuΦenφ RFC822, kterΘ popisuje formßt zßhlavφ zprßvy a jejφho t∞la. Pro p°φpadn² p°enos binßrnφch soubor∙ se pou₧φvß formßtovßnφ podle doporuΦenφ RFC1341 MIME (Multipurpose Internet Mail Extension), kterΘ specifikuje p°evod binßrnφch dat na posloupnost ASCII znak∙. Pro v²b∞r zprßv z poÜtovnφho serveru koncov²m uzlem se pou₧φvß protokolu POP3 (Post Office Protocol 3).
P°i p°enosu zprßv odeÜle koncov² uzel zprßvu nejbli₧Üφmu (svΘmu) poÜtovnφmu serveru. Ten ji prost°ednictvφm p°φmΘho TCP spojenφ p°edß poÜtovnφmu serveru p°φjemce nebo nejbli₧Üφmu mezilehlΘmu poÜtovnφmu serveru, kter² zprßvu p°edßvß dßle, dokud nedorazφ k cφlovΘmu poÜtovnφmu serveru. Koncov² uzel si pak z poÜtovnφho serveru zprßvu vyzvedne pomocφ protokolu POP3.
Logika spojenß se jmΘny
Je z°ejmΘ, ₧e v prost°edφ sφtφ TCP/IP by bylo pou₧itφ IP adres ve tvaru dvaat°icetibitov²ch slov z u₧ivatelskΘho hlediska velmi t∞₧kopßdnΘ. P°irozen∞jÜφ komunikace m∙₧e probφhat nap°. prost°ednictvφm logick²ch nßzv∙ (jmen) tvo°en²ch srozumiteln²mi posloupnostmi pφsmen a Φφslic. V prost°edφ TPC/IP byla proto vypracovßna hierarchickß struktura jmen oznaΦovanß jako domΘnov² jmenn² systΘm (Domain Name System, DNS). LogickΘ jmΘno uzlu je tvo°eno posloupnostφ podjmen odd∞len²ch vzßjemn∞ teΦkami. Jednotlivß podjmΘna, kterß oznaΦujφ tzv. domΘny, mohou odpovφdat nap°. samostatnΘmu uzlu, skupinßm uzl∙, oblastem Φi organizacφm. Po°adφ domΘn je strukturovßno tak, aby podjmΘno domΘny nejv∞tÜφho rozsahu le₧elo nejvφce vpravo. Obecnß struktura domΘnov²ch jmen mß tvar:
JednoznaΦnΘ p°i°azenφ logick²ch jmen a IP adres je udr₧ovßno na tzv. jmenn²ch domΘnov²ch serverech (Domain Names Servers, DNS servery). Servery jednotliv²ch oblastφ jsou vßzßny hierarchicky, viz obr. 2. P°i zφskßvßnφ IP adres na zßklad∞ znalosti domΘnovΘho jmΘna (Domain Name Resolving) se klient dotß₧e nejprve svΘho domΘnovΘho serveru. Nenalezne-li tento DNS server zßznam ve svΘ tabulce, postoupφ dotaz nad°φzenΘmu DNS serveru ve svΘ hierarchii. Takto se postupuje a₧ k tomu DNS serveru, jen₧ mß p°φsluÜn² zßznam ve svΘ tabulce a odpovφ na dotaz po₧adovanou IP adresou. V²hodou je, ₧e ka₧d² uzel sφt∞ k tomu, aby zjistil libovolnou IP adresu na zßklad∞ domΘnovΘho jmΘna, pot°ebuje znßt pouze adresu jedinΘho DNS serveru. Ten pak na pozadφ zabezpeΦφ nezbytnou komunikaci s ostatnφmi DNS servery.
Pro ·sp∞Ün² start
Startovacφ protokol (Bootstrap Protocol, BootP) slou₧φ k zφskßvßnφ zßkladnφch informacφ o konfiguraci systΘmu nevybavenΘho prost°edky pro zahßjenφ Φinnosti, nap°. pevn²mi disky, p°i jeho startu. ProgramovΘ vybavenφ realizujφcφ protokol BootP je obvykle ulo₧eno v pam∞ti ROM. Po zapnutφ systΘmu se prost°ednictvφm UDP vyÜle tzv. univerzßlnφ zprßva, tj. zprßva, kterß je p°ijata vÜemi stanicemi sφt∞, s dotazem, zda v sφti existuje BootP server. Pokud ano, BootP server, na n∞m₧ je sprßvcem sφt∞ udr₧ovßna tabulka p°i°azenφ stanic a jim odpovφdajφcφch IP adres, na zßklad∞ p°edanΘ MAC adresy zaÜle odpov∞∩ obsahujφcφ IP adresu a masku podsφt∞ stanici, kterß vyslala dotaz. Nßsledn∞ pak lze prost°ednictvφm protokolu TFTP (viz v²Üe) zavΘst do stanice pot°ebnΘ programovΘ vybavenφ, nap°. operaΦnφ systΘm. BootP server pou₧φvß ve°ejn² port s Φφslem 67, klient port s Φφslem 68.
Protokol BootP je v modernφch sφtφch stßle Φast∞ji nahrazovßn protokolem pro dynamickou konfiguraci hostitelskΘho systΘmu (Dynamic Host Configuration Protocol, DHCP). DHCP rozÜi°uje mo₧nosti protokolu BootP zejmΘna o automatizovanΘ p°id∞lovßnφ IP adres. DHCP server disponuje urΦitou mno₧inou IP adres, kterΘ m∙₧e po₧adujφcφm stanicφm p°id∞lovat podle urΦit²ch pravidel. Z toho plynou dv∞ zßkladnφ v²hody protokolu DHCP oproti protokolu BootP. P°edevÜφm odpadß slo₧itß ruΦnφ konfigurace BootP serveru, zalo₧enß na pevnΘm p°id∞lenφ jednotliv²ch IP adres p°φsluÜn²m stanicφm, kterß mnohdy vedla k chybßm, znemo₧≥ujφcφm komunikaci. Druhou nespornou v²hodou je skuteΦnost, ₧e mno₧ina IP adres m∙₧e b²t menÜφ, ne₧ je skuteΦn² poΦet stanic v sφti, samoz°ejm∞ za p°edpokladu, ₧e ne vÜechny stanice jsou do nφ p°ipojeny souΦasn∞. To platφ obzvlßÜt∞ dob°e v p°φpad∞ poskytovatel∙ internetov²ch slu₧eb, kdy u₧ivatelΘ p°istupujφ k sφti obvykle jen na omezenou kratÜφ dobu a prakticky nikdy ne vÜichni souΦasn∞.
Protokol DHCP umo₧≥uje p°id∞lovat IP adresy t°emi r∙zn²mi zp∙soby:
* automatickΘ - pro p°id∞lovßnφ stßl²ch IP adres;
* dynamickΘ - pro p°id∞lovßnφ IP adres doΦasn∞ na urΦitou dobu;
* ruΦnφ - kdy sprßvce sφt∞ p°id∞lφ IP adresu staticky a protokol DHCP pouze zajistφ transfer adresy p°φsluÜnΘ stanici.
Krom∞ toho umo₧≥uje protokol DHCP takΘ klient∙m ₧ßdat o specifickΘ hodnoty konfiguraΦnφch parametr∙. K nim zejmΘna pat°φ:
* maska podsφt∞;
* sm∞rovaΦ;
* domΘna;
* DNS server.
Internet a jeho protokol
Protokol pro p°enos hypertextov²ch informacφ (Hypertext Transfer Protocol, HTTP) je protokol urΦen² pro v²m∞nu informacφ v rozsßhl²ch distribuovan²ch hypermedißlnφch prost°edφch. Byl vyvinut v roce 1990 v rßmci globßlnφ iniciativy WWW (World Wide Web), kde byl pou₧it pro p°enos informacφ ve tvaru tzv. WWW strßnek ve formßtu HTML (Hypertext Markup Language), tj. v jazyku umo₧≥ujφcφm souΦasn² p°enos textov²ch a multimedißlnφch informacφ v jedinΘm dokumentu. Dnes je protokol HTML zßkladnφm protokolem celosv∞tovΘ sφt∞ internet i vnitropodnikov²ch sφtφ intranet.
Protokol HTTP je koncipovßn jako bezestavov² protokol pracujφcφ v re₧imu dotaz/odpov∞∩. Pro p°enos pou₧φvß spolehlivΘ spojenφ na bßzi TCP s vyhrazen²m aplikaΦnφm portem Φφslo 80 na stran∞ serveru. Protokol HTTP umo₧≥uje p°enßÜet informace v r∙znorod²ch formßtech, nebo¥ klient p°i zasφlßnφ dotazu p°edßvß seznam formßt∙, kterΘ je schopen zpracovat. Server pak odeÜle data v jednom z po₧adovan²ch formßt∙. Toho lze s v²hodou vyu₧φt i pro p°enos nestandardnφch formßt∙, pokud tyto formßty jak server, tak i klient podporujφ.
K adresovßnφ informaΦnφch zdroj∙ v internetu pou₧φvß HTTP adresovΘ schΘma oznaΦovanΘ jako URL (Uniform Resource Locator), kterΘ adresuje nejenom p°φsluÜn² server, ale takΘ po₧adovan² dokument, obsahuje specifikaci p°φstupovΘho protokolu a p°φpadn∞ dalÜφ data pro autorizaci p°φstupu. Obecn² formßt URL (hranatΘ zßvorky oznaΦujφ, ₧e parametr je nepovinn² a m∙₧e chyb∞t) je:
Protokol SMNP je spolu s aplikaΦnφm protokolem CMOT (v prost°edφ RM OSI) jednφm z nepou₧φvan∞jÜφch protokol∙ pro sprßvu sφtφ. Slou₧φ k monitorovßnφ aktivnφch prvk∙ sφtφ, jejich vzdßlenΘmu °φzenφ a konfiguraci. Architektura protokolu je op∞t zalo₧ena na koncepci klient/server a tvo°φ ji t°i zßkladnφ prvky:
* SNMP agent;
* MIB databßze;
* SNMP mana₧er.
SNMP agentem se rozumφ programovΘ vybavenφ provozovanΘ na spravovan²ch aktivnφch prvcφch sφt∞, jimi₧ mohou b²t rozboΦovaΦe, sm∞rovaΦe, p°epφnaΦe, ale takΘ zßlo₧nφ zdroje, sφ¥ovΘ tiskßrny a mnohß dalÜφ za°φzenφ. SNMP agent sleduje Φinnost prvku, na n∞m₧ je provozovßn, a informace uklßdß do p°edem definovanΘ informaΦnφ databßze. Ta je obvykle oznaΦovßna jako MIB (Management Information Database, informaΦnφ databßze pro sprßvu). MIB je objektov∞ orientovanß databßze s p°i°azen²mi nßzvy parametr∙ a definovanou syntaxφ, tj. typem a strukturou t∞chto parametr∙. Prost°ednictvφm Φtenφ a zßpisu ·daj∙ do MIB sledovan²ch za°φzenφ pak SNMP mana₧er, programovΘ vybavenφ pro monitorovßnφ a sprßvu sφt∞ jako celku provozovanΘ obvykle na jednΘ ze stanic sφt∞, komunikuje s jednotliv²mi SNMP agenty umφst∞n²mi v t∞chto za°φzenφch. Tφm je umo₧n∞no nejenom sledovßnφ stavu a Φinnosti jednotliv²ch za°φzenφ Φtenφm a vyhodnocenφm ·daj∙, kterΘ do MIB ulo₧il p°φsluÜn² SNMP agent, ale takΘ konfiguraci a °φzenφ Φinnosti t∞chto za°φzenφ zßpisem SNMP mana₧erem do MIB vhodn²ch parametr∙, na jejich₧ zßklad∞ SNMP agent upravφ vlastnosti za°φzenφ.
Velkou v²hodou pou₧itφ MIB je relativnφ nezßvislost mezi za°φzenφm a v n∞m pou₧it²m SNMP agentem a SNMP mana₧erem, nebo¥ struktura a nßzvy zßkladnφch objekt∙ pou₧φvan²ch v r∙zn²ch MIB a prezentaΦnφ prost°edφ ASN.1 jsou standardizovßny. Je vÜak ponechßna volnost v²robc∙m za°φzenφ v tom sm∞ru, ₧e mohou MIB dopl≥ovat i dalÜφmi vlastnφmi parametry, co₧ vÜak ji₧ vy₧aduje pou₧itφ SNMP agent∙ i SNMP mana₧eru od jednoho v²robce.
DalÜφ aplikaΦnφ protokoly
DalÜφch pou₧φvan²ch protokol∙ aplikaΦnφ vrstvy TCP/IP je celß °ada. V zßv∞ru serißlu se jich dotkneme pouze velmi struΦn∞.
Sφ¥ov² protokol Φasovßnφ (Network Time Protocol, NTP) slou₧φ k synchronizaci hodin jednotliv²ch uzl∙ v rßmci celΘ sφt∞.
RezervaΦnφ protokol (Resource Reservation Protocol, RSVP) je signalizaΦnφ protokol umo₧≥ujφcφ p°ijφmajφcφ stanici rezervovat si pot°ebnou Üφ°ku pßsma v sφti pro p°enos dat citliv²ch na zpo₧d∞nφ, tj. zejmΘna hlasu Φi obrazov²ch informacφ).
P°enosov² protokol v reßlnΘm Φase (Real-time Transport Protocol, RTP) slou₧φ ke spolehlivΘmu p°enosu interaktivnφch multimedißlnφch dat, p°edevÜφm interaktivnφho videa. DoruΦovßnφ paket∙ je monitorovßno °φdicφm protokolem RTCP (Real-time Control Protocol, °φdicφ protokol pro p°enos v reßlnΘm Φase).
Poodhrnutß rouÜka
Serißl, kter² prßv∞ skonΦil, rozhodn∞ nemohl b²t a ani nebyl vyΦerpßvajφcφ uΦebnicφ poΦφtaΦov²ch sφtφ. Ani si to nekladl za cφl. Problematika poΦφtaΦov²ch sφtφ nenφ jenom ohromn∞ Üirokß, ale takΘ velmi hlubokß. Pod obecn²mi postupy, kterΘ jsou mnohdy velmi jednoduchΘ a pochopitelnΘ, se skr²vajφ ohromn∞ slo₧itΘ implementace vyvolßvajφcφ v sφti a k nφ p°ipojen²ch za°φzenφch mnohdy miliony Φi miliardy drobn²ch, neviditeln²ch operacφ.
M²m cφlem bylo vysv∞tlit zßkladnφ principy Φinnosti poΦφtaΦov²ch sφtφ, osv∞tlit a dßt nßpl≥ termφn∙m a pojm∙m, s nimi₧ se v∞tÜina z nßs dnes dostßvß denn∞ do styku, a alespo≥ trochu p°iblφ₧it a zpopularizovat sv∞t, kter² nßm pomßhß komunikovat mezi sebou.
