Slidy z prednášky (1,1 MB)
YouTube

1.  Architektúry sieťových aplikácií

Je bežné, že dve rôzne sieťové aplikácie od rôznych výrobcov, a pokojne aj na rôznych operačných systémoch, spolu na internete normálne komunikujú. Komunikácia medzi ľubovoľnými dvoma spustenými programami je realizovaná správami, ktoré si navzájom vymieňajú. To, že si tieto programy rozumejú, umožňujú aplikačné protokoly, ktoré určujú, aké správy si majú tieto aplikácie posielať. Stačí, že týmto správam rozumejú iba tieto dva programy. Ostatné sieťové zariadenia na ceste nijako tieto správy nespracúvajú ani neanalyzujú (za normálnych okolností). Vývoj nových aplikačných protokolov je teda úplne nezávislý od fungovania siete a prenosu správ v nej.

Každý aplikačný sieťový protokol definuje:

  • typy správ, ktoré si programy posielajú (požiadavky, odpovede, informácie, rôzne typy dát)
  • syntax správ určujúcu, ako budú jednotlivé správy vyzerať, z čoho budú zložené a aké hodnoty môžu jednotlivé časti správy obsahovať
  • sémantiku správ predstavujúcu význam jednotlivých správ a informácií v nich
  • okolnosti, za ktorých sa jednotlivé správy posielajú

Definícia verejných aplikačných protokolov je daná v ich voľne prístupných RFC špecifikáciách. Súkromné aplikačné protokoly neumožňujú vývoj nových koncových programov a ako serverovú, tak aj klientsku časť musí zabezpečiť jeden programátor (alebo skupina programátorov, ktorá sa na danom protokole dohodla).

Pred samotným písaním nového protokolu je potrebné si uvedomiť, akú rolu budú hrať jednotlivé časti sieťovej aplikácie. Sieťové aplikácie sa z tohto pohľadu dajú rozdeliť na tri skupiny:

  • klient/server architektúra
    • Predpokladá, že na internete je jeden alebo viac stále zapnutých počítačov s pevnou IP adresou nazývaných servery. Na týchto počítačoch beží serverová časť sieťovej aplikácie. Klienti spúšťajú a vypínajú klientsku časť sieťovej aplikácie podľa potreby. Môžu mať dynamickú IP adresu, môžu sa tiež nachádzať v privátnej sieti za NAT routrom. Klienti komunikujú vždy iba so serverom, nikdy nie s ostatnými klientmi. Server musí byť často výkonný počítač alebo dokonca klaster niekoľkých serverov, aby zvládol nápor množstva klientov.
    • napríklad web servery, ftp servery, DNS servery, AiS2
  • peer-to-peer architektúra
    • Žiaden z počítačov nemusí byť stále zapnutý. Peer-ovia sú niekedy klientmi, niekedy servermi a často oboma naraz. Môžu sa odpájať a pripájať podľa ľubovôle. Záťaž je rozložená oveľa rovnomernejšie ako v prípade klient/server architektúry. Manažovanie siete je dosť ťažké.
    • napríklad Gnutella, Freenet
  • Hybrid klient/server a peer-to-peer architektúry
    • Stále zapnutý server sa používa iba na registráciu a vyhľadávanie napojených peerov, prípadne indexovanie ich dát. Samotné nosné dátové prenosy sa dejú už medzi jednotlivými peermi.
    • napríklad Jabber, Skype, BitTorrent, DCC

2.  Komunikácia s transportnou vrstvou

Každý sieťový program sa spustí ako proces, prípadne množina procesov (záleží na programátorovi). Pokiaľ chcú dva procesy komunikovať v rámci jedného počítača, môžu využiť medziprocesovú komunikáciu, ktorú poskytuje operačný systém. Procesy na rôznych počítačoch komunikujú prostredníctvom správ niektorým z aplikačných protokolov.

Bez ohľadu na typ architektúry aplikácie je pri sieťovej komunikácii medzi dvoma procesmi vždy jeden z procesov klientsky a jeden serverový. Klientsky proces je ten, ktorý inicializuje komunikáciu a serverový proces je ten, ktorý čaká, že sa naň niekto napojí.

Procesy posielajú a prijímajú správy od procesu na druhej strane komunikácie prostredníctvom soketov. Soket je rozhranie (API), ktoré poskytuje komunikáciu sieťovej aplikácie s niektorým protokolom transportnej vrstvy. Samotná transportná vrstva je obyčajne už riadená operačným systémom. Soket poskytuje posielanie a prijímanie správ systémom producent-konzument. Okrem toho umožňuje nastavenie niektorých parametrov protokolov nižších vrstiev.

Na to, aby dva procesy na rôznych staniciach mohli komunikovať, musí klientsky proces vedieť identifikátor presne určujúci, kde sa nachádza serverový proces, aby s ním mohol inicializovať komunikáciu. Identifikátor sa skladá z IP adresy stanice, na ktorej beží serverový proces a čísla portu, ktorý jednoznačne identifikuje proces v rámci tejto stanice. Netreba zabúdať, že na jednom počítači môže byť spustených niekoľko serverových procesov a musia sa preto ich identifikátory od seba líšiť.

Číslo portu si môže serverový proces (lepšie povedané jeho programátor) vybrať, aké chce. Dobre známe služby už majú všeobecne uznané čísla portov (well known ports). Napríklad HTTP server obvykle počúva na porte 80, FTP server na porte 21 a podobne.

Jednotlivé webové aplikácie majú rôzne nároky na transportnú vrstvu a sieťové pripojenie. Niektoré nie sú citlivé na stratu niektorých dát (napr. VoIP, streamované rádio a televízia), iné vyžadujú stopercentne spoľahlivé dátové prenosy. Na druhej strane, rôzne multimediálne prenosy obrazu a zvuku vyžadujú nejakú minimálnu šírku pásma, aby ich kvalita bola dostatočná. Iné aplikácie nie sú až také citlivé na šírku pásma a dokážu sa prispôsobiť aktuálnym možnostiam. Real-time aplikácie určené na komunikáciu tiež vyžadujú malé zdržanie paketov.

Charakter internetu (prepínanie riadené paketmi) neumožňuje žiadnemu transportnému protokolu zabezpečiť minimálnu šírku pásma ani malé zdržanie paketov, takže multimediálne real-time prenosy by sme mali uskutočňovať na „nevyťažených spojeniach s dostatočnou šírkou pásma“, kde je zdržanie malé.

Všetky aplikačné protokoly, ktoré očakávajú spoľahlivý prenos všetkých správ v správnom poradí, využívajú transportný protokol TCP. Protokol UDP je odľahčený protokol nepodporujúci spoľahlivý prenos dát (navyše ani v správnom poradí). Ak sa odosielajúca stanica nemusí starať o to, či všetky dáta spoľahlivo došli ku klientom, je vhodnejšie použiť UDP protokol, ktorý odľahčí odosielajúcu stanicu aj sieťovú komunikáciu. Typicky sú to práve spomínané streamované rádia a televízia či telefonovanie cez internet. Niektoré multimediálne programy však preferujú TCP protokoly hlavne pre ich schopnosť kontroly zahltenia siete. Využívajú ho hlavne archívy multimédií (napr. YouTube). UDP protokol je tiež vhodný, ak je potrebné odosielať totožné správy viacerým staniciam súčasne.

3.  Aplikačný protokol HTTP

HTTP: hypertext transfer protocol, verzia HTTP 1.0: RFC 1945, verzia HTTP 1.1: RFC 2068, verzia HTTP 2: RFC 7540

Protokol HTTP používa klient/server architektúru. Klientsky proces (HTTP klient) predstavuje webový prehliadač (Firefox, Internet Explorer, Chrome, Opera a iné), ktorý kontaktuje webový server (Apache Web server, Microsoft IIS). HTTP klient na základe URL adresy zistí adresu webového servera a cestu na webovom serveri k objektu, o ktorý má používateľ záujem. Objektom posielaným cez HTTP protokol môže byť čokoľvek. Najčastejšie ide o základný HTML súbor obsahujúci URL adresy ďalších objektov (obrázkov, videí, hudby, CSS štýlov, …) výslednej webovej stránky, ktoré si HTTP klient následne po jednom opýta, aby zobrazil používateľovi výslednú webovú stránku.

HTTP protokol využíva TCP protokol transportnej vrstvy. Webový server obvykle obsadzuje port 80. Prehliadač to predpokladá, a preto ak do URL adresy nedodáme číslo portu, je automaticky použitý port 80.

HTTP protokol používa dva typy správ, požiadavky (HTTP request) od klienta a odpovede (HTTP response) od servera.

3.1  HTTP požiadavka

HTTP požiadavka sa skladá z príkazového riadka, hlavičky a tela. Klient v príkazovom riadku HTTP požiadavky uvádza metódu (GET, POST, HEAD, PUT alebo DELETE), časť URL adresy predstavujúcu cestu v adresároch webového sídla a verziu protokolu, ktorým chceme komunikovať.

Príklad príkazového riadka HTTP požiadavky a jedného riadka hlavičky, v ktorej žiadame protokolom HTTP verzie 1.1 súbor index.html v adresári webového servera /oddelenie na počítači www.inštitúcia.sk:

GET /oddelenie/index.html HTTP/1.1
Host: www.inštitúcia.sk

Úplná URL adresa tohto súboru je www.inštitúcia.sk/oddelenie/index.html. V prípade, že potrebujeme žiadanej webovej stránke odovzdať aj nejaké dáta, získané obvykle z webového formulára, boli by otáznikom oddelené od požadovaného súboru. Napríklad, ak posielame meno a priezvisko, tak URL adresa by vyzerala nasledovne www.inštitúcia.sk/oddelenie/index.html?meno=Peter&priezvisko=Gursk%C3%BD, a teda HTTP požiadavka by vyzerala nasledovne:

GET /oddelenie/index.html?meno=Peter&priezvisko=Gursk%C3%BD@@ HTTP/1.1
Host: www.inštitúcia.sk

Poznámka: Trochu rušivo pôsobí %C3%BD, čo predstavuje binárny kód znaku „ý“ v UTF-8 kódovaní „preložený“ do 7 bitového ASCII kódovania metódou URL encoding. Navyše tento riadok môže byť iný, ak je prednastavené kódovanie v prehliadači iné. To, aké kódovanie bolo použité pôvodne, sa uvádza ako ďalší z riadkov hlavičky (Accept-Charset: UTF-8,*)

Dáta sa môžu tiež odosielať metódou POST. V tom prípade to, čo sa písalo pri metóde GET v URL adrese za otáznik, sa uvádza v tele požiadavky. Táto metóda je obľúbenejšia a používateľsky príjemnejšia, keďže nezobrazuje odoslané dáta z formulára v URL adrese (napríklad heslo).

V skratke ešte povedzme, na čo sa používajú zvyšné 3 príkazy. HEAD má rovnakú funkciu ako GET alebo POST s tým rozdielom, že od servera nechceme výslednú stránku, ale len HTTP hlavičku odpovede. Príkaz PUT sa používa na odosielanie súboru a príkaz DELETE na mazanie súboru na serveri.

3.2  HTTP odpoveď

HTTP odpoveď sa skladá z riadka odpovede, hlavičky a tela. Riadok odpovede sa skladá z verzie protokolu, kódu stavu a komentára stavu vyriešenia požiadavky.

Základným kódom stavu odpovede je 200 s komentárom OK, označujúci, že požiadavka na objekt bola úspešná a v tele tejto odpovede je pribalený požadovaný objekt. Kódy začínajúce číslom 3 obvykle znamenajú, že stránka bola presunutá a v hlavičke, v časti Location, je uvedené kam. Kódy začínajúce číslom 4 znamenajú, že požadovaný objekt sa z nejakého dôvodu nedá poslať. Kódy začínajúce číslom 5 sú chybové stavy, s ktorými sa HTTP server nevedel vysporiadať. Pre úplný prehľad kódov odpovedí si pozrite RFC 2068.

3.3  Niektoré ďalšie vlastnosti HTTP protokolu

Protokol HTTP verzie 1.0 funguje len v neperzistentnom režime. To znamená, že server po každej odpovedi klientovi uzavrie TCP spojenie. Ak má webová stránka povedzme 10 obrázkov, potrebujeme pre každý z nich iniciovať TCP spojenie so serverom. Protokol HTTP verzie 1.1 už umožňuje prácu v perzistentnom režime, v ktorom klient môže v hlavičke špecifikovať, aby server po odpovedi ešte neuzavrel spojenie (Connection: keep-alive) a až v poslednej požiadavke pre danú stránku môže (ale aj nemusí) oznámiť serveru, že po odpovedi na ňu už môže spojenie uzavrieť (Connection: close).

Protokol HTTP je bezstavový. Umožňuje však webovým portálom, aby si v prípade potreby manažovali stav sami. Pre každé novovytvorené spojenie vytvorí jedinečný identifikátor, ktorý pošle klientovi v časti hlavičky zvanej Cookie. Keď klient posiela požiadavku a v hlavičke tiež uvedie Cookie identifikátor, ktorý pred tým dostal od tohto webového servera, webový server ho skontroluje so svojou databázou vygenerovaných identifikátorov a v prípade nájdenia zhody poskytne tento identifikátor webovému portálu, ktorý takto môže udržiavať stav komunikácie s daným klientom.

3.4  HTTP 2.0

Protokol HTTP 2 výrazne zrýchľuje celú komunikáciu efektívnejším perzistentným režimom. Efektívnejšie spracovanie je umožnené hlavne používaním binárnych rámcov namiesto pôvodných textových HTTP požiadaviek a odpovedí ako základných častí dát zasielaných v správach.

Definuje 10 typov rámcov. HEADERS rámec požiadavky, ako náprotivok hlavičky HTTP/1.x požiadavky, definuje nový prúd dát v rámci spojenia, ktorý má zabezpečiť stiahnutie jedného objektu. Jeden objekt je potom zo servera vysielaný v niekoľkých rámcoch – najprv HEADERS rámec odpovede nasledovaný rámcami typu DATA, prípadne aj typu CONTINUATION (pokračovanie HEADERS alebo DATA rámca, ak hlavička alebo dáta sú väčšie ako maximálna veľkosť rámca). Každý prúd dát môže mať rôznu prioritu, ktorá umožní zasielanie rámcov jedného objektu častejšie ako iného. Ďalšími vychytávkami sú:

  • možnosť pre server zasielať objekty bez vyžiadania, ak server predpokladá, že prehliadač bude daný objekt potrebovať,
  • nastavovanie vzájomných závislostí prúdov (ak mi nepošleš tento objekt, tak objekty na ňom závislé tiež neposielaj),
  • zaslanie nastavení servera/prehliadača v rámci typu SETTINGS iba raz pre celé spojenie, namiesto uvádzania v každej hlavičke
  • kompresia hlavičiek, kde ďalšie hlavičky obsahujú iba rozdiely oproti predchádzajúcim hlavičkám
  • možnosť použitia spojenia so serverom pre viaceré domény, ak sú hostované na serveri s rovnakou IP adresou
  • obmedzenie menej spoľahlivých foriem šifrovania komunikácie

Viac o protokole HTTP 2 sa môžete dočítať aj v tomto peknom článku na serveri oreilly.com, alebo kratšie, ale česky v článku Pavla Satrapy.

3.5  Proxy server

Proxy server je špeciálny program, ktorý funguje ako sprostredkovateľ webových stránok pre klienta. Ak chceme využiť služby proxy servera, môžeme v prehliadači nastaviť na akom počítači a porte proxy server počúva. Potom už všetka komunikácia z prehliadača ide cez proxy server. Pre úplnosť dodajme, že časté sú aj transparentné proxy servery, ktoré fungujú „neviditeľne“ tak, že cez nich je administrátorom routra presmerovaná komunikácia smerujúca mimo lokálnu sieť na porty 80.

Proxy server je vytvorený na to, aby odľahčil pomalé internetové pripojenia tak, že objekty, ktoré už raz boli z internetu stiahnuté, boli prehliadaču poskytované z cache tohto proxy servera. Je však prirodzené, že webové stránky menia v čase svoj obsah a používatelia by radi videli aktuálne stránky. Toto je vyriešené cez podmienenú HTTP požiadavku na webový server. Proxy server v prípade, že prehliadač od neho žiada stránku, ktorú má v cache, pridá do hlavičky požiadavky časovú pečiatku poslednej modifikácie daného objektu (If-modified-since:<dátum a čas>). Ak server zistí, že nemá novšiu verziu daného objektu, posiela iba hlavičku s kódom 304 Not Modified. Ak však má novšiu verziu, pošle celý objekt aj s novou časovou pečiatkou poslednej zmeny.

V súčasnosti sa proxy server často používa na logovanie webovej komunikácie a aj na obmedzenie prístupu na určité webové stránky, čo sa využíva hlavne na ochranu malých detí, na školách, ale často aj vo firmách.

4.  Aplikačný protokol FTP

FTP: file transfer protocol, RFC 959

Protokol FTP je určený na prenos súborov zo servera na klienta a naopak. FTP protokol oddeľuje riadenie komunikácie od prenosu dát do samostatných TCP spojení. Riadiaca časť FTP servera čaká na spojenia od klientov na porte 21. Po napojení FTP klienta na riadiacu časť servera sa musí používateľ autorizovať svojím prihlasovacím menom a heslom. V prípade, že ide o verejný FTP server s povolenou anonymnou autorizáciou, používa sa ako prihlasovacie meno anonymous a ako heslo sa uvádza e-mailová adresa (tá môže byť často prázdna alebo stačí uviesť @).

FTP spojenie si uchováva pozíciu v rámci adresárovej štruktúry webového servera. Niektoré príkazy, ktoré nepotrebujú prenášať dáta, si vystačia aj s riadiacim spojením (napr. CWD na zmenu adresára a DELE na zmazanie súboru). Iné príkazy, ktoré už vyžadujú prenos dát (RETR na stiahnutie súboru, STOR na zaslanie súboru, LIST na získanie obsahu aktuálneho adresára), už potrebujú na svoje úspešné vykonanie vopred otvorené dátové spojenie.

Dátové spojenie sa môže otvoriť jedným z dvoch spôsobov – módov:

  • aktívny mód, v ktorom klient riadiaceho spojenia spustí na svojom počítači serverový dátový proces a oznámi serveru riadiaceho spojenia IP adresu a číslo portu, na ktorý sa má napojiť klientskou časťou dátového spojenia. Zasielaná správa o otvorenom porte má tvar PORT a1,a2,a3,a4,p1,p2 v ktorom a1.a2.a3.a4 je IP adresa a výsledok výrazu p1*256+p2 je číslo portu(na obrázku č.1). Server riadiaceho spojenia poďakuje (číslo 2). FTP klient môže predpokladať, že FTP server sa napojí na tento dátový server z portu 20 (číslo 3). Keď sa TCP spojenie podarí (číslo 4), dátový kanál je pripravený na odoslanie jedného súboru dát (súbor alebo výpis adresára). Tento spôsob spojenia sa veľmi nevyužíva, nakoľko klienti dosť často nemajú verejnú IP adresu a FTP server sa na nich nevie napojiť.
  • pasívny mód, v ktorom klient najprv požiada FTP server v riadiacom spojení o otvorenie serverovej časti dátového spojenia príkazom PASV (na obrázku číslo 1). Server otvorí niektorý port a pošle v riadiacom spojení klientovi správu v tvare 227 Entering Passive Mode (a1,a2,a3,a4,p1,p2). v ktorom opäť a1.a2.a3.a4 je IP adresa a výsledok výrazu p1*256+p2 je číslo portu, na ktorom čaká (číslo 2). FTP klient inicializuje dátové spojenie na tento port (číslo 3). Keď sa TCP spojenie podarí (číslo 4), dátový kanál je pripravený na odoslanie jedného súboru dát (súbor alebo výpis adresára). V tomto prípade sa port 20 nevyužíva.

Po otvorení spojenia môže FTP klient požiadať o dátový prenos v riadiacom spojení (RETR, STOR alebo LIST).

Keď používateľ vypne FTP klienta, ten ešte odosiela príkaz QUIT pre FTP server na korektné ukončenie riadiaceho spojenia.

Komunikácia v riadiacom spojení je podobná s prvým riadkom HTTP požiadaviek a odpovedí. FTP odpovede servera sa tiež skladajú z kódu a komentára stavu. Všetky typy požiadaviek a odpovedí si môžete pozrieť v RFC 959.

5.  Aplikačný protokol SMTP

SMTP: simple mail transfer protocol, RFC 2821

SMTP protokol je určený na odosielanie mailu od používateľa k svojmu mailovému serveru a na odosielanie mailov od odosielateľovho mailového servera k mailovému serveru príjemcu. SMTP servery počúvajú na porte 25.

SMTP protokol je veľmi starý. Jeho jadro bolo vytvorené už v roku 1982. Z toho plynú niektoré nepríjemné dôsledky, na ktoré sa vtedy nemyslelo.

  • Všetko, čo sa odosiela SMTP protokolom (vrátane príloh), musí byť kódované v 7-bitovom ASCII kódovaní. Z toho vyplýva, že aj text, aj binárne súbory v prílohách musia byť prekódované do tohto kódovania, čo „zbytočne“ zaťažuje procesor a zväčšuje objem prenesených dát. Rozšírenie o prekódované binárne dáta a dáta v inom kódovaní znakov umožňujú multimediálne rozšírenia. Takzvané MIME (multimedia mail extension) typy v hlavičke mailu definujú, akým kódovaním boli tieto dáta prekódované a akého boli pôvodne typu.
  • SMTP protokol nemá žiadnu autorizáciu. To znamená, že môžeme posielať maily z ľubovoľnej e-mailovej adresy. Dôsledok je dobre známy. Až 97 % všetkých e-mailov tvorí spam. Provideri často robia (pseudo)opatrenie, že blokujú odchádzajúcu komunikáciu na port 25 a nedovolia tak svojim zákazníkom prevádzku SMTP serverov.

SMTP správy od servera sú jednoriadkové odpovede v tvare kód a komentár stavu. Klient zasiela buď príkazy alebo obsah mailu podľa toho, v ktorej časti komunikácie sa nachádza. V prípade, že je v stave, že práve posiela mail, môže zasielať toľko riadkov, koľko potrebuje. Koniec odosielania mailovej časti správy oznamuje bodkou na samostatnom riadku. K jednotlivým príkazom sa nie je potrebné vyjadrovať. Tie jednoduché sú samo vysvetľujúce a zložité si môžete pozrieť v RFC 2821. Odporúčam si preštudovať zdrojové súbory vašich vlastných mailov. Uvediem iba jednoduchú komunikáciu na odoslanie krátkeho mailu. „C:“ označuje riadok správy klienta a „S:“ riadok správy servera.

S: 220 mail.ics.upjs.sk
C: HELO doma.sk
S: 250 Hello doma.sk, pleased to meet you
C: MAIL FROM: <alica@doma.sk>
S: 250 alica@doma.sk... Sender ok
C: RCPT TO: <bob@upjs.sk>
S: 250 bob@upjs.sk ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Prepacte, ze som pred tyzdnom neposlala projekt
C: lebo som velmi chora
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 mail.ics.upjs.sk closing connection

Je nutné poznamenať, že mailový server nášho ústavu, teda mail.ics.upjs.sk, je nastavený tak, že nedovolí odosielanie mailov z iných mailových adries ako registrovaných. Nie všetky mailové servery toto dodržiavajú.

Keď mailový server prijme od používateľa mail, vloží mail do radu mailov na odoslanie a následne odosiela tento mail na cieľový server, daný emailovou adresou prijímateľa, opäť protokolom SMTP. Pokiaľ je cieľový server dočasne nedostupný, pokúša sa o spojenie ešte niekoľkokrát v priebehu najbližších hodín a dní. Zároveň upozorňuje odosielateľa o neschopnosti mail doručiť. Po doručení mailu na mailový server prijímateľa, je tento mail uložený v jeho mailovej schránke a čaká, kedy si ho používateľ vyzdvihne.

6.  Aplikačné protokoly POP3 a IMAP

POP3: Post Office Protocol – Version 3, RFC 1939
IMAP: Internet Mail Access Protocol, RFC 1730

Oba protokoly slúžia na to, aby si používateľ kontroloval a sťahoval došlú poštu zo svojej mailovej schránky na svojom mailovom serveri. Pri komunikácii cez niektorý z týchto protokolov mailový klient (Outlook, Elm, Pine, Mozilla Thunderbird, Evolution a pod.) periodicky kontaktuje mailový server, autorizuje sa používateľským menom a heslom a zisťuje aktuálny obsah mailovej schránky používateľa.

Protokol POP3 umožňuje pozretie zoznamu mailov v schránke, stiahnutie mailov a zmazanie stiahnutých mailov v schránke na serveri.

Protokol IMAP je zložitejší. Poskytuje viac príkazov ako POP3. Je určený na to, aby uchovával maily v schránke servera. Umožňuje okrem iného aj organizáciu mailov do priečinkov a presúvanie mailov medzi nimi. Výhoda tohto prístupu je tá, že používateľ má všetky maily k dispozícii aj na iných počítačoch v rámci Internetu.

Popri protokoloch POP3 a IMAP používatelia radi využívajú na čítanie a organizáciu mailov webové rozhranie priamo na mailovom serveri (Gmail, Yahoo, Hotmail, Post.sk, Zoznam.sk, Azet.sk a pod.).

7.  Úlohy a diskusia

  • Uveďte päť otvorených internetových aplikácií a protokoly, ktoré používajú.
  • Počas komunikácie medzi dvoma stanicami, ktorá z nich je klient a ktorá server?
  • Čo sa myslí pod pojmom „hand-shaking“ protokol?
  • Prečo služby HTTP, FTP, SMTP používajú práve protokol TCP a nie UDP?
  • Predstavte si webový e-shop, ktorý by si rád zaznamenával údaje o nákupoch každého z nakupujúcich. Uveďte, ako je to možné docieliť pomocou HTTP autentizácie a ako pomocou cookies (koláčikov).
  • Predpokladajte, že Alica posiela svoje emaily cez niektorú webovú službu (Gmail, Yahoo) a pošle email Bobovi, ktorý k svojej pošte pristupuje cez POP3. Uveďte, ako email putuje z Alicinej klávesnice až do Bobovho emailového klienta, uveďte príklady programov a protokolov, ktoré sú cestou využité.
  • Pozrite si hlavičku emailu, ktorý ste nedávno dostali. Koľko Received: riadkov v nej je? Analyzujte ich.
  • Z používateľského hľadiska, aký je rozdiel medzi stiahnutím a zmazaním a stiahnutím a uchovaním v POP3? Popíšte, ako si predstavujete ich fungovanie.
  • V HTTP existujú požiadavky GET a POST. Sú v HTTP/1.0 definované ešte iné požiadavky? Ak áno, na čo sú používané? Ako to je v HTTP/1.1?
  • Viete nakonfigurovať webový prehliadač tak, aby otvoril viac simultánnych spojení na webovú stránku? Aké sú výhody a nevýhody viacerých simultánnych spojení?
  • Sú SMTP, POP3 a IMAP stavové alebo nestavové protokoly? Prečo?
  • Odpovedajte Pravda alebo Nepravda:
    • Predpokladajte, že používateľ pošle požiadavku na web stránku, ktorá obsahuje len text a dva obrázky. Prebieha to teda tak, že prehliadač pošle jednu požiadavku a odpovede budú tri?
    • Môžu byť dve rozdielne webové stránky (ics.upjs.sk/~gursky/siete a ics.upjs.sk/~rkb/) poslané cez to isté TCP spojenie?
    • Záznam Date: v HTTP odpovedi označuje, kedy bola stránka naposledy zmenená?

zdroje:

  • James F. Kurose, Keith W. Ross: Computer Networking: A Top-Down Approach, 4th edition. Pearson Education, Inc., ISBN: 0-321-51325-8, 878 pages, 2008
  • http://slacksite.com/other/ftp.html