Lekce 11: Aplikaní vrstva

Transkript

1 Poítaové sít, v. 3.1 Katedra softwarového inženýrství, Matematicko-fyzikální fakulta, Univerzita Karlova, Praha Lekce 11: Aplikaní vrstva Jií Peterka, 200

2 Koncepce aplikaní vrstvy pedstava, že "v aplikaní vrstv jsou provozovány (celé) aplikace" není správná dvod: bylo by nutné standardizovat celé aplikace vetn uživatelského rozhraní atd. místo toho: v aplikaní vrstv je pouze ást aplikací "základ aplikace", který spolupracuje s aplikacemi na jiných uzlech tento základ musí být standardizován aby si rozuml s ostatními "základy" zbytek aplikace je "nad" aplikaní vrstvou zejména uživatelské rozhraní nkdy se tato ást oznauje (ne moc správn) jako "User Agent" není to dlení "klient/server" již nemusí být (není vhodné aby bylo) standardizováno platí jak pro RM ISO/OSI, tak i pro TCP/IP aplikaní vrstva aplikace uživatelské rozhraní základ aplikace aplikaní vrstva

3 koncepce aplikaní vrstvy "základ" aplikace (v rámci aplikaní vrstvy) realizuje njaká entita nejastji: proces aplikaní entita (proces) komunikuje s jinými entitami v rámci téhož uzlu prostedky "meziprocesové komunikace" s aplikaními entitami (procesy) na jiných uzlech komunikuje prostednictvím aplikaních protokol protokol aplikaní vrstvy jsou šité na míru konkrétním druhm aplikací (nap. el. pošt, WWW, penosu soubor atd.) uživatelské rozhraní nkteré aplikace (nap. v roli server) nemusí vbec mít uživatelské rozhraní uživatelské rozhraní základ aplikace aplikaní protokol základ aplikace aplikaní protokol "user agent" základ aplikace sí sí

4 vývoj aplikaní vrstvy RM ISO/OSI: snaha vytváet"bohaté" a "dokonalé" aplikaní protokoly nap. MOTIS/X.400 elektronická pošta Message Oriented Text Interchange System X.00 adresáové služby FTAM práce se soubory File Transfer, Access and Management VT vzdálené pihlašování Virtual Terminal CMIP správa, management Common Management Information Protocol.. vtšina z nich se neujala a nepoužívá se nkteré ISO/OSI protokoly však peci jen došly uritého využití nap. X.400 MS Exchange byl až do verze 2000 primárn založen na X.400 nap. X.00 "odlehením" vznikl reáln % používaný protokol LDAP rodina protokol TCP/IP postupný vývoj, od jednoduššího ke složitjšímu aplikace vznikaly jako jednoduché, a teprve postupn se obohacovaly rozšiovalo se také spektrum aplikací "poátení množina" aplikací: vzdálené pihlašování (Telnet, rlogin) penos soubor (FTP) elektronická pošta (SMTP, RFC 822) postupn se pidávaly další aplikace sdílení soubor (NFS) sdílení informací (NNTP) zpístupnní informací Gopher WWW (World Wide Web) vyhledávání informací Archie, WAIS, Veronica. dochází ke vzniku "aplikaních platforem" el. pošta a WWW nejsou již jen službami/aplikacemi, ale stávají se platformami, na kterých lze vytváet nové služby nkteré pvodní aplikace asem zanikají nap. vyhledávání se stává nadstavbou WWW

5 architektura aplikací souvisí s tzv. výpoetním modelem ucelenou pedstavou o tom, jak "vypadají" a jak fungují aplikace kolik majíásti, kde tyto ásti bží, kde jsou umístna data, kde jsou zpracovávána.. výpoetní model se postupn vyvíjí aplikace pvodn: dávkový model dávkové zpracování pak: model host/terminál vzdálené pihlašování aplikace dnes: monolitické aplikace aplikace si dlá vše sama veškeré zpracování dat vytváí uživatelské rozhraní, komunikuje s uživatelem není rozdlena na více ástí (vtšinou) nespolupracuje s jinými aplikacemi pokud je provozována v prostedí sít hodí se pro izolované poítae nehodí se (tolik) pro distribuované prostedí pro sí pokud nap. zpracovává vtší objemy dat, musí je mít "u sebe" je nutné penášet velké objemy dat a zpracovávat je jinde, než kde vnikají a jsou standardn uloženy &

6 ešení: model klient/server myšlenka: data se budou zpracovávat tam, kde se nachází výstupy pro uživatele se budou generovat tam, kde se nachází uživatel musí dojít k rozdlení pvodn monolitické aplikace na dvásti serverovou ást zajišuje zpracování dat klientskou ást zajišuje uživatelské rozhraní db 10 MB + db klient a server si posílají data pedstavující dotazy a odpovdi pokud se klient a server dobe dohodnou, mohou úinn minimalizovat objem penášených dat mají výrazn menší penosové nároky mohou pracovat i v prostedí rozlehlých sítích navíc: klient a server mohou stát na rzných platformách 10 MB zpracování 1 bit prezentace monolitická aplikace serverová ást klientská ást '

7 pedstava modelu klient/server server serverová ást aplikace klientskáást aplikace klient požadavek na zpracování výsledek zpracování komunikace mezi klientem a serverem se odehrává stylem: požadavek/odpov ( server pasivneká, až dostane njaký požadavek sám se klientm nevnucuje komunikaci iniciuje klient, zasláním požadavku musí být definována vzájemná komunikace mezi klientem a serverem komunikaní protokol (nap. HTTP) musí být definován formát dat (zpráv, ), které si server a klient vymují nap. jazyk HTML,. vtšina aplikací dnes funguje na bázi modelu klient/server píklad: WWW WWW server, WWW klient (browser) protokol HTTP,. jazyk HTML píklad: poštovní server, poštovní klient protokoly SMTP, POP3, IMAP formát RFC-822, MIME..

8 penos a sdílení soubor penos soubor (file transfer) je to služba (realizovaná aplikací) je netransparentní ( = rozlišují se místní a vzdálené soubory) je teba znát umístní vzdálených soubor se vzdálenými soubory se pracuje jinak než s místními pro pesun soubor (z místního umístní na vzdálené) je teba podnikat explicitní akce píkazy typu "GET", "PUT" atd. TCP/IP: nejpoužívanjším protokolem pro penos soubor je protokol FTP File Transfer Protocol dalším protokolem pro penos soubor je TFTP Trivial FTP RM ISO/OSI: protokol FTAM File Transfer Access and Management realizuje jak penos soubor, tak i jejich ) sdílení sdílení soubor (file sharing) je transparentní ( = nerozlišují se vzdálené a místní soubory) není nutné znát umístní vzdálených soubor se vzdálenými i místními soubory se pracuje stejn (jako s místními) pro pesun soubor (z místního umístní na vzdálené a naopak) není teba podnikat žádné explicitní akce zajišuje to služba (aplikace) sama TCP/IP: nejpoužívanjším protokolem pro sdílení soubor je NFS Network File System dalším je nap. AFS Athena File System nov: CIFS Common Internet File System RM ISO/OSI: protokol FTAM Microsoft, MS Windows: protokol SMB (Server Message Blocks)

9 FTP pedstava a penos soubor FTP implicitn chápe soubor jako dále nestrukturovaný (bez vnitní struktury) - oznaováno jako file structure proto nepotebuje "doprovodnou" konvenci o formátu penášených dat implicitn je obsah souboru penášen jako spojitý proud dat (tzv. stream mode) protokol FTP využívá (spolehlivých, spojovaných) transportních služeb protokolu TCP implementace vychází z modelu klient/server klient je typicky aplikaním programem server obvykle systémovým procesem (démonem, rezidentním programem apod.) návrh protokolu TCP je uzpsoben možnosti úsporné implementace snaží se nárokovat si systémové zdroje až v okamžiku jejich skutené poteby zajištní potebných funkcí v rámci FTP je rozdleno mezi dv entity: interpret protokolu (PI, Protocol Interpreter) penosový proces (DTP, Data Transfer Process) interpret protokolu (PI) existuje trvale, penosový proces (DTP) vzniká až na základ konkrétního požadavku používají se dv rzná spojení: ídící (pro penos píkaz) datové (pro penos soubor) *

10 implementace protokolu FTP pedstava požadavek na penos penos souboru PI server interpret protokolu ídící spojení klient uživatelské rozhraní interpret protokolu UI PI systém soubor penosový proces DTP datové spojení DTP penosový proces systém soubor využívají se transportní služby protokolu TCP

11 datové a ídící spojení ídící spojení iniciuje (navazuje) klient ze svého (dynamicky pidleného) portu na port 21 ruší se až explicitním píkazem datové spojení iniciuje (navazuje) server ze svého portu 20 na port klienta, ze kterého bylo navázáno ídící spojení passive-mode: datové spojení nenavazuje server, ale klient kvli firewallm, které neakceptují žádosti o otevení spojení vedoucí dovnit na "náhodný" port FTP definuje vlastníídící jazyk píkazy ídícího jazyka jsou penášeny ídícím spojením ídící píkazy mají textovou povahu píkazy ídícího jazyka lze rozdlit na: ízení pístupu (access control commands) - nap. pro zadání uživatelského jména a hesla nastavení parametr pístupu (transfer parameter commands) - nap. pro zmnu implicitních ísel port, pro nastavení režimu penosu apod. výkonné píkazy (FTP service commands) - pro vlastní penos soubor, rušení, pejmenovávání atd., pro pechody mezi adresái apod. napíklad: RETR penos souboru ze vzdáleného umístní do místního STORE penos z "místního" do "vzdáleného" LIST výpis obsahu adresáe CWD pechod mezi adresái

12 odpovdi na píkazy FTP každý píkaz vyvolá alespo jednu odpov odpovdi majííselný charakter (s textovým komentáem) odpovdi tvoí trojmístnéíslo: prvnííslice vyjaduje celkový charakter odpovdi druháíslice upesuje odpov tetí ješt blíže specifikuje hierarchický charakter odpovdí vychází vstíc rzné inteligenci proces, které je vyhodnocují hloupý klient i server se mže spokojit jen s prvnííslicí chytrý klient (server) využije všechny íslice 1xx 2xx 3xx 4xx xx pedbžná kladná odpov (akce byla zahájena, budou ješt další odpovdi) kladná odpov (definitivní) prozatímní odpov (jsou nutné další píkazy) doasná záporná odpov (nepodailo se, ale je vhodné opakovat) trvalá záporná odpov (nepodailo se a nemá smysl opakovat) stejná konvence (3-místnéíselné odpovdi) se používá i u dalších aplikaních protokol nap. u SMTP (elektronická pošta), pro vzájemný dialog server u HTTP pro odpovdi serveru na požadavky klienta nap. "chyba 404" (stránka nenalezena) jde o chybu na stran klienta

13 píklad navázání (transportního) spojení na uzel charon.isdn.cz, na port 21 USER earchiv PASS (hidden) CWD /earchiv/ definitivní kladná odpov 220 charon.isdn.cz FTP server ready prozatím kladná odpov, nutná ješt další akce 331 Password required for earchiv definitivní kladná odpov 230 User earchiv logged in definitivní kladná odpov 20 CWD command successful RETR users.dat Received bytes in 0.8 secs, (.1 Mbps), transfer succeeded pedbžná kladná odpov, nutná ješt další akce 10 Opening BINARY mode data connection for users.dat ( bytes) definitivní kladná odpov 226 Transfer complete.

14 World Wide Web - architektura vychází z modelu klient/server pedpokládá následující dlbu práce: server (WWW server): uchovává jednotlivé WWW stránky, na (explicitní) žádost je poskytuje svým klientm klient (WWW prohlíže, browser) si vyzvedává stránky od server, zobrazuje je uživateli, zprostedkovává brouzdání pro korektní fungování WWW musí existovat všeobecn dodržované konvence o: formátu WWW stránek (zápisu jejich obsahu) toto pokrývá jazyk HTML (HyperText Markup Language) zpsobu penosu stránek (mezi serverem a klientem) toto pokrývá protokol HTTP (HyperText Transfer Protocol) % browser interpretuje HTML kód a sestavuje grafickou podobu stránky (rendering) WWW stránka WWW server HTTP požadavek HTTP odpov + HTML kód HTML rendering browser

15 je to jednoduchý penosový protokol penáší data v textovém tvaru používá transportní služby protokolu TCP není to nutné, lze použít i jiné protokoly server pijímá požadavky na dobe známém portu 80 funguje bezestavov dialog s klientem nemní stav serveru navazuje samostatné spojení pro každý objekt v rámci WWW stránky obrázek, ikonu atd. komunikace má charakter "žádost-odpov" klient iniciuje navázání spojení klient pošle svou žádost server pošle odpov spojení je ukoneno odpovdi majííselný charakter stejn jako u FTP a SMTP souástí odpovdi je i samotný obsah WWW stránky & protokol HTTP (HyperText Transfer Protocol) každá WWW stránka mže obsahovat adu samostatných objekt 1 x samotný HTML kód stránky n x obrázek další (flashe, audiosoubory, každý objekt mže být umístn na jiném WWW serveru ale nebývá, spíše na stejném HTTP verze 1.0: každý objekt na stránce je "získáván" samostatn je pro nj zizováno samostatné transportní spojení s WWW serverem (na port 80), objekt je vyžádán, penesen, spojení ukoneno HTTP verze 1.1: jsou-li objekty na stejném serveru, jsou "získávány" spolen je zízeno jedno spolené transportní spojení s WWW serverem, objekty jsou postupn stahovány, teprve pak je transportní HTML kód atd.

16 metody HTTP žádosti WWW klient (browser) mají formu jednoduchých píkaz oznaovaných jako metody píklady metod: metoda GET požadavek klienta na poskytnutí WWW stránky obecn: GET <URL> HTTP/1.0 nebo GET <URL>, pak server nevrací své (HTTP) hlaviky (ale rovnou HTML kód požadované stránky) metoda HEAD požadavek na zaslání hlaviky WWW stránky metoda POST pošle data na server používá se pi práci s formulái pro zasílání odpovdí, které mají být dále zpracovány, nap. CGI skriptem» jinak se používá i GET PUT, DELETE, LINK, UNLINK ' nepoužívají se žádosti klient mohou být doplnny dalšími parametry oznaovanými jako hlaviky píklady hlaviek If-Modified-Since <datum> uvádí se nap. s metodou GET, a stránka je požadována jen je-li novjší Authorization pro zasílání identifikaních údaj (jméno, heslo, ) všechny žádosti klient zaínají "na zelené louce" server si nepamatuje historii komunikace s daným klientem dsledek: komunikace klienta se serverem je bezestavová výhoda: požadavky rzných klient mohou být libovoln promíchány, a serveru to nevadí

17 odpovdi HTTP odpovdi WWW serveru mají nkolik ástí: "status odpovdi" používá se stejný systém 3.místných íselných odpovdí jako u FTP a SMT protokol 1xx: informaní, záleží na aplikaci 2xx: kladná odpov nap. 200 OK, 201 Created, 202 Accepted 3xx: oekává se další aktivita od klienta 4xx: problém (chyba) na stran klienta 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found. xx: problém (chyba) na stran serveru 00 Internal Server Error 01 Not Implemented 03 Service Unavailable upesující hlaviky, napíklad Content-Type specifikuje MIME typ toho, co je v "datovéásti" odpovdi» nap. Content-Type: text/html; charset=windows-120 Expires <datum> íká kdy mají být data považována za neplatná (a nemají se dávat do cache). Expires: 0 znamená, že se nemají cacheovat vbec Pragma obecná hlavika, význam závisí na konkrétní implementaci» nap.: Pragma: no-cache.. "datovou ást" nap. HTML kód požadované stránky, obrázek, obecn klientem vyžádaný objekt jeho typ je upesnn v hlavice Content-type (

18 GET /index.html HTTP/1.0 píklad HTTP dialogu požadavek klienta HTTP/ OK Date: Mon, 22 May :09:17 GMT Server: Czech-Net Apache Content-Length: 46 Last-Modified: Thu, 08 Apr :39:0 GMT Connection: close Content-Type: text/html; charset=windows-120 Expires: Thu, 01 Jan :00:01 GMT odpov serveru (2xx) hlaviky HTTP protokolu (upesují odpov) ) <html> <head> <title>.. "datováást" (poskytnutá WWW stránka)

19 co je elektronická pošta? je to služba mže být realizována rznými zpsoby, v rzném prostedí existují rzné "koncepce" elektronické pošty nap. Mail602, ccmail, MS Mail, X.400, SMTP,.. liší se formátem zpráv, adresami, penosovými mechanismy,... obecn jsou vzájemn nekompatibilní pro možnost vzájemné spolupráce vyžadují existenci poštovních bran v Internetu se používá tzv. SMTP-pošta založená na jedné konkrétní koncepci (na bázi protokolu SMTP a RFC 822) stejná koncepce elektronické pošty mže být použita i jinde mimo Internet není proprietární není "vlastnná" žádnou firmou, vychází z pln otevených standard * napíklad SPT Telecom (dnes: eský Telecom) zprovoznil koncem roku 199 veejnou elektronickou poštu CZ MAIL, na bázi X.400 penos jednotlivých zpráv byl zpoplatnn první 2 KB zprávy po Evrop stály 8,40 K každé další 2 KB stály 4,80 K do ostatního svta 1,80 K / 8,40 K

20 filosofie a architektura SMTP pošty zaíná skromn, postupn se obohacuje pvodn vznikla jako velmi jednoduchá služba jako elektronická obdoba "office memo" pvodn penášela jen krátké texty v istém ASCII tvaru další vlastnosti a schopnosti se pidávaly teprve postupn, pokud se ukázala jejich poteba, nap. možnost formátování textu, vkládání obrázk atd. možnost penosu netextových píloh podpora národních abeced (háky&árky).. a to až po ovení jejich úelnosti a funknosti vychází z modelu klient/server poštovní server (mail server): v terminologii ISO/OSI: MTA, Message Transfer Agent zajišuje transport zpráv shromažuje zprávy pro ty úastníky, kteí nejsou momentáln dostupní poštovní klient v terminologii ISO/OSI: UA, User Agent umožuje íst, psát a jinak zpracovávat jednotlivé zprávy vytváí uživatelské rozhraní standardy el. pošty musí pokrývat penos zpráv (mezi servery): definuje protokol SMTP (Simple Mail Transfer Protocol) formát zpráv a adres definuje doporuení RFC822 download stahování zpráv ze schránky na poštovním serveru definuje protokol POP3, IMAP. rozšíení (národní abecedy, pílohy, formátování, ) definuje standard MIME

21 "anatomie" poštovní zprávy Každá zpráva má tyto ásti: hlaviku (header) tlo (body) voliteln: pílohu (attachment) Hlavika obsahuje: adresu píjemce (píjemc) adresu odesilatele datum vzniku/odeslání pedmt zprávy (subject) jednoádkový, výstižný popis toho, o co jde další atributy zprávy nap. naléhavost, požadavek na potvrzení píjmu,. Tlo obsahuje vlastní text zprávy Píloha: v zásad cokoli, co lze "zabalit" do podoby souboru nap. datový soubor, zvukový klip apod. hlavika (header) prázdná ádka tlo (body) To: To: Josef.Novak@matfyz.cz Josef.Novak@matfyz.cz From: From: jiri@peterka.cz jiri@peterka.cz Date: Date: Fri, Fri, 7 7 Jan Jan :7:10 12:7: Subject: Subject: Prihlaseni Prihlaseni ke ke zkousce zkousce Dobry Dobry den, den, Vase Vaseprihlaseni prihlasenike ke zkousce zkousce z z predmetu predmetu "Pocitacove "Pocitacovesite", site", v v terminu: terminu: steda steda od od 9:00 9:00 bylo bylo uspesne uspesne S pozdravem pozdravem J. J. Peterka Peterka ATT00023.txt píloha (attachment)

22 RFC822 vs. SMTP Pedstava: zpráva je list papíru, který se vloží do obálky a teprve ta se penáší RFC 822 definuje, co a jak má být napsáno na listu papíru SMTP definuje obálku a zpsob jejího penosu (i co má být napsáno na této obálce) nkteré z položek hlaviky listu jsou kopírovány na obálku, mj. adresa píjemce a odesilatele SMTP je penosovým mechanismem pro penos zpráv ( obálek ) využívá spolehlivých penosových služeb protokolu TCP (ale mže být implementován i nad jinými spolehlivými penosovými protokoly) chápe penášená data jako text lenný na ádky pomocí CR+LF tvoený 7-bitovými ASCII znaky To: To: Josef.Novak@matfyz.cz Josef.Novak@matfyz.cz From: From: jiri@peterka.cz jiri@peterka.cz Date: Date: Fri, Fri, 7 7 Jan Jan :7:10 12:7: Subject: Subject: Prihlaseni Prihlaseni ke ke zkousce zkousce Dobry Dobry den, den, Vase Vaseprihlaseni prihlasenike ke zkousce zkousce z z predmetu predmetu "Pocitacove "Pocitacovesite", site", v v terminu: terminu: steda steda od od 9:00 9:00 bylo bylo uspesne uspesne S pozdravem pozdravem J. J. Peterka Peterka ATT00023.txt from: jiri@peterka.cz to: to: josef.novak@matfyz.cz

23 pedstava penosu zpráv Internet poštovní klient poštovní klient 1. sestavení zprávy, píkaz k odeslání 2. upload (odeslání) zprávy na poštovní server pomocí SMTP 3. penos zprávy mezi poštovními servery pomocí protokolu SMTP zpráva koní v poštovní schránce (mailboxu) píjemce 4. stažení zprávy z poštovní schránky do poštovního klienta pomocí protokolu POP3.tení pijaté zprávy, v rámci poštovního klienta píjemce

24 doruování podle MX záznam ové adresy dnes mají nejastji tvar nap. jak píjemce pozná, na který SMTP server má zprávu doruit k dispozici má pouze jméno domény ešení: pro každou doménu je definován tzv. MX (mail exchanger) záznam definuje jeden (nebo více) SMTP server, které pijímají poštu pro danou doménu cz cz to: to: jiri@peterka.cz peterka odpov dotaz do DNS MX: MX: 10, 10, scretchy.czech.net scretchy.czech.net MX: MX: 100, 100, mspool.czech.net mspool.czech.net doruení % poštovní schránka na stroji scretchy.czech.net

25 doruování zpráv SMTP pošta odesilatel (poštovní klient odesilatele) sám typicky nedoruuje zprávy zná "nejbližší" poštovní server, a tomu pedá zprávu k odeslání/doruení "nejbližší" = ten, který má poštovní klient uvedený ve vlastní konfiguraci zpráva se pedává pomocí protokolu SMTP teprve "nejbližší" poštovní server se stará o doruení pevzaté zprávy hledá SMTP server, kterému by ml zprávu pedat nejdíve hledá podle MX záznam v DNS pokud se nedaí urit pijímající server z DNS, snaží se odesilatel interpretovat ást adresy za zavináem jako jméno konkrétního poítae odesílající SMTP server naváže spojení s pijímajícím serverem transportní spojení smuje na port 2 (kde eká SMTP server) spojení využívá transportní protokol TCP & následuje "SMTP dialog" ob strany si pedávají dležité "identifikaní" údaje mj. údaje, pedstavující nápisy na obálce teprve pak je penesena vlastní zpráva ( list ) píkazy protokolu SMTP mají textový charakter nap. HELO, EHLO, RCPT,... odpovdi v SMTP jsou zásadníselné trojmístné používá se stejná konvence jako u FTP a HTTP 1xx pedbžná odpov 2xx definitivní odpov 3xx prozatímní odpov, nutné další akce 4xx doasná chyba, lze zkoušet znovu xx trvalá chyba, nemá smysl zkoušet znovu vlastní dialog má i protokol POP3 pro stahování pošty z poštovních schránek POP3 server poskytuje své služby na portu. 110

26 SMTP dialog - prbh navázání transportního spojení na port 2 (uzlu scretchy.czech.net) 220 scretchy.czech.net SMTP service ready HELO smtp.post.cz 20 scretchy.czech.net hello smtp.post.cz MAIL FROM: <nekdo@post.cz> 20 sender ok From: nekdo@post.cz RCPT TO: <jiri@peterka.cz> 20 recipient ok RCPT TO: <jirka@peterka.cz> 20 recipient ok DATA 34 Enter mail, end with "." on a line by itself { hlavika zprávy dle RFC 822} {tlo zprávy dle RFC822}. {teka jako zakonující znak} 20 mail accepted {ukonení penosu dat} QUIT 221 scretchy.czech.net {ukonení transportního spojení} ' To: To: jiri@peterka.cz Cc: Cc: jirka@peterka.cz

27 netextové penosy v SMTP pošt Pvodn: SMTP pošta byla urena jen pro penos krátkých textových zpráv v "istém ASCII" bez hák&árek, bez formátování, rzných druh písma penosové mechanismy (protokol SMTP) jsou koncipovány tak, aby garantovaly penos textových zpráv složených ze 7-bitových znak není stanoveno co se má stát, když znaky budou 8-bitové Problém: pokud se nkdo pokusí penést nco jiného než 7-bitové znaky, není garantováno jak to dopadne mže to dopadnou dobe ale: "nejvyšší bity" mohou být oezány (nastaveny na 0) apod. ( 8 bit SMTP problém je s pílohami pokud by k textové zpráv byl piložen datový soubor, nemusel by "projít" datový soubor je obecn tvoený 8-bitovými byty problém je i s národními abecedami nelze používat znaky národních abeced, protože ty je nutné kódovat do 8 bit problém je i s formátováním formátovací znaky jsou také 8-bitové princip ešení: všechno co je 8-bitové se pevede na 7- bitové, penese a pak zase vrátí do pvodní podoby ALE: toto lze uinit mnoha rznými zpsoby nejvtší problém je v tom, aby se lidé dohodli na spoleném postupu tak aby píjemce vždy vdl, co a jak má provést s obdrženou zprávou 7 bit

28 ) ešení "netextových" penos v rámci SMTP pošty "nesystematická" ešení: týkají se pouze "pibalování" píloh UUENCODE varianta "pibalování" píloh, pocházející ze svta Unixu BinHex varianta pocházející ze svta poíta Macintosh.. systematickéešení: standard MIME Multipurpose Internet Multimedia Extensions je podporován vtšinou novjších poštovních klient umožuje bezproblémovou práci s pílohami jedna zpráva mže mít i více píloh, pílohou mže být cokoli, co lze "zabalit" do podoby souboru umožuje psát esky v tle zprávy, pedmtu zprávy i v komentáových ástech adres umožuje provázání poštovního klienta s aplikacemi tak aby uživateli stailo kliknout na ikonku s pílohou, a klient vdl co má s pílohou udlat (jak ji "vybalit" a kterému programu ji pedat) co všechno definuje standard MIME? kódování 2 zpsoby pevedení 8-bitových dat do 7-bitové podoby: Quoted Printable a Base64 typování dat zavádí tzv. MIME type (je dvousložkový), aby bylo možné definovat co jsou data za a bylo možné odvodit, jak mají být zpracována nap. text/html, image/gif rozšíení formátu zprávy zavádí rozšíení formátu dle RFC822, tak aby mohly být ve zpráv vyjádeny informace související s pílohami, kódováním atd. zavádí nové položky do hlaviky umožuje aby tlo zprávy mlo více složek standard MIME je typickým píkladem vývoje aplikací v rámci TCP/IP nejprve jsou vyvinuty jednoduché aplikace když se aplikace uchytí a uživatelé si vznikne poteba jejich zdokonalení, toto se pipraví

29 další aplikaní protokoly TCP/IP IMAP Internet Message Access Protocol umožuje pracovat se zprávami pímo ve vzdálené poštovní schránce není nutné je stahovat, jako u POP3 S/MIME (secure MIME) rozšíení MIME o bezpenostní prvky NNTP Network News Transfer Protocol "síové noviny", služba USENET Telnet vzdálené pihlašování LDAP Lightweight Directory Access Protocol NTP Network Time Protocol. * (píklad využití protokolu LDAP pro vyhledání adresy ve veejném adresái)

30 historické služby/aplikace TCP/IP: Gopher gopher = zool.:pytlonoš kanadský americký sysel Minnesoan (pezdívka) nebo je to odvozeno od "to GO FOR information"? Gopher prohrál v souboji s WWW nebyl tolik "sexy". Gopher byl vyvinut na University of Minnesota, USA je to služba pro zpístupnní informací uživateli poskytuje nabídku ve form menu jednotlivé položky menu jsou uspoádány lineárn položky jsou textové (i celé menu) položka mže pedstavovat: soubor (text, obrázek,...) odkaz na jiné menu pechod (bránu) do jiné služby i aplikace

31 Gopher dnes již v Internetu funguje jen velmi málo server Gopher nap. gopher://gopher.quux.org/ menu "obsahová" stránka

32 nkteré služby Internetu pvodn vznikly jako samostatné byly pro n vytvoeny samostatné (aplikaní) protokoly a aplikace napíklad: klientské aplikace i servery vyhledávání soubor v FTP archivech služba Archie plnotextové vyhledávání v dokumentech služba WAIS (Wide Area Information System).. specializované vs. nadstavbové služby v Internetu dotaz dotaz databáze databáze nalezené dokumenty nalezené dokumenty

33 WWW a el. pošta jako aplikaní platformy pvodn samostatné služby (Archie, WAIS, ) vyžadovaly, aby uživatelé: používali specifické klientské aplikace museli si je instalovat, konfigurovat atd. používali specifický styl práce uili se znát ovládání aplikací, píkazy atd. celkový trend vedl k: minimalizaci klient kvli správ klientského SW kvli nárokm na uživatele.. dsledek: pvodn široký repertoár služeb a aplikací v Internetu a TCP/IP se postupn zužoval až zstaly dv "základní aplikace", resp. služby, resp. klienti: WWW (browser) a pošta (poštovní klient) elektronická pošta a WWW se staly platformami, na kterých jsou "stavny" další aplikace takové, které pvodn byly samostatné elektronická pošta: zprostedkovává též: diskuse (News, NetNews, Usenet), elektronické konference, nástnky (bulletin-board) apod. WWW: nejrznjší formy vyhledávání obecné i specializované transakce objednávání, nakupování, prodej, hry, e-learning,.. vzdálené pihlašování. pesto stále vznikají samostatní klienti nap. pro instant messaging apod.