Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

2. Fejezet Alkalmazási réteg

Hasonló előadás


Az előadások a következő témára: "2. Fejezet Alkalmazási réteg"— Előadás másolata:

1 2. Fejezet Alkalmazási réteg
A note on the use of these ppt slides: We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following: If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we’d like people to use our book!) If you post any slides in substantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material. Thanks and enjoy! JFK/KWR All material copyright J.F Kurose and K.W. Ross, All Rights Reserved Computer Networking: A Top Down Approach, 4th edition. Jim Kurose, Keith Ross Addison-Wesley, July 2007. 2: Alkalmazási réteg

2 2. Fejezet: Alkalmazási réteg
2.1 Hálózati alkalmazások alapelvei alkalmazás-architektúrák alkalmazások igényei 2.2 Web és HTTP 2.3 FTP 2.4 SMTP, POP3, IMAP 2.5 DNS 2.6 P2P alkalmazások 2.7 Socket programozás TCP-vel 2.8 Socket programozás UDP-vel 2: Alkalmazási réteg

3 2. Fejezet: Alkalmazási réteg
Célunk: alapfogalmak, alkalmazási-réteg protokollok implementációs szempontjai szállítási-réteg szolgáltatási modellek kliens-szerver paradigma peer-to-peer (társ-társ) paradigma alkalmazási-réteg protokollok ismertetése HTTP FTP SMTP / POP3 / IMAP DNS hálózati alkalmazások programozása socket API 2: Alkalmazási réteg

4 Néhány hálózati alkalmazás
web instant messaging távoli bejelentkezés P2P file-megosztás multi-user hálózati játékok tárolt video streaming hang IP-n keresztül valósidejű video-konferencia grid számítások 2: Alkalmazási réteg

5 Hálózati alkalmazások írása
application transport network data link physical programok írása, amelyek (különböző) végerndszereken futnak hálózaton keresztül kommunikálnak pl. web szerver szoftver kommunikál a böngésző szoftverrel kevés szoftver a hálózat magja részére a hálózat magjának eszközei nem futtatnak felhasználói alkalmazásokat application transport network data link physical application transport network data link physical 2: Alkalmazási réteg

6 2. Fejezet: Alkalmazási réteg
2.1 Hálózati alkalmazások alapelvei alkalmazás-architektúrák alkalmazások igényei 2.2 Web és HTTP 2.3 FTP 2.4 SMTP, POP3, IMAP 2.5 DNS 2.6 P2P alkalmazások 2.7 Socket programozás TCP-vel 2.8 Socket programozás UDP-vel 2: Alkalmazási réteg

7 Alkalmazás architektúrák
Kliens-szerver Társ-társ (P2P) Hibrid: kliens-szerver és P2P 2: Alkalmazási réteg

8 Kliens-szerver architektúra
folyamatosan működő host valós rögzített IP cím szerver farmok bővítéshez (skálázás) kliens: a szerverrel kommunikál nem kell folyamatosan működjön dinamikus IP címe is lehet nem kommunikálnak közvetlenül egymással kliens/szerver 2: Alkalmazási réteg

9 Tiszta P2P architektúra
nincs folyamatosan működő szerver tetszőleges perem-rendszerek szabadon kommmunikálnak a párok alkalmanként kapcsolódnak, IP címet váltanak példa: Gnutella Könnyen bővíthető, de nehezen kezelhető társ-társ 2: Alkalmazási réteg

10 Hibrid kliens-szerver és P2P
Skype „voice-over-IP” P2P alkalmazás központi szerver: távoli partner címének megkeresése kliens-kliens kapcsolat: közvetlen (nem a szerveren keresztül) Instant messaging két felhsználó közti chat P2P központosított szolgáltatás: felhasználó jelenlétének detektálása/lokalizálás a felhasználó regisztrálja az IP címét a központi szerveren amikor bejelentkezik a felhasználó a központi szerverhez fordul hogy megtudja egy partner IP címét 2: Alkalmazási réteg

11 Kommunikáló folyamatok
Kliens folyamat: kezdeményezi a kapcsolatot Szerver folyamat: várja, hogy kapcsolatba lépjenek vele Folyamat: egy hoston futó program ugyanazon a hoston futó két folyamat folyamatok közti (interprocess) kommunikációval kommunikál (op. rendsz.) különböző hostokon futó folyamatok, alkamazási-réteg protokollok segítségével kommunikálnak Megjegyzés: a P2P alkalmazásoknak kliens folyamataik és szerver folyamataik is vannak 2: Alkalmazási réteg

12 Socketek a folyamat üzeneteket küld/fogad a socket-nek/től
pufferes TCP, változók socket hoszt vagy szerver Pufferes Internet a folyamat üzeneteket küld/fogad a socket-nek/től A socket hasonlít egy ajtóra a küldő folyamat átküldi az üzenetet az ajtón az ajtó másik oldalán levő infrastruktúrára alapoz, amely eljuttatja az üzenetet a fogadó folyamat socket-jéhez az alkalmazás- fejlesztő irányítja Az OR irányítja API: (1) szállítási protokoll választása; (2) néhány paraméter beállítása (bővebben később) 2: Alkalmazási réteg

13 Folyamatok címzése Ahhoz, hogy egy folyamat fogadóképes legyen, kell legyen egy azonosítója Minden hostnak van egy 32-bites IP címe K: Elegendő a host IP címe, amelyen a folyamat fut a folyamat felismerésére? 2: Alkalmazási réteg

14 Folyamatok címzése Ahhoz, hogy egy folyamat fogadóképes legyen, kell legyen egy azonosítója Minden hostnak van egy 32-bites IP címe K: Elegendő a host IP címe, amelyen a folyamat fut a folyamat felismerésére? V: Nem, több folyamat futhat ugyanazon a hoston Az azonosító magában foglalja a folyamathoz társított IP címet és a port számát. Példa port számokra: HTTP szerver: 80 Mail szerver: 25 HTTP üzenet küldése a gaia.cs.umass.edu web szervernek: IP cím: Port szám: 80 Bővebben később … 2: Alkalmazási réteg

15 Az alkalmazási-réteg protokoll meghatározza:
A kicserélt üzenetek típusát, pl. kérés, válasz Az üzenetek szintaxisát: milyen mezőket tartalmaz az üzenet, mi válassza el a mezőket Az üzenetek szemantikáját: a mezőkben lévő információ jelentését Az üzenetek küldésére illetve fogadására vonatkozó szabályokat Nyilvános protokollok : RFC-kben meghatározott lehetővé teszik az együttműködést pl. HTTP, SMTP Védett protokollok (Proprietary protocols): pl. Skype 2: Alkalmazási réteg

16 Milyen szállítási szolgáltatásokra van szüksége egy alkalmazásnak?
Adatvesztés vannak alkalmazások, amelyek megengednek bizonyos mértékű adatvesztést (pl. audio) más alkalmazásnak (pl. file-ok másolása , telnet) 100%-an megbízható adat-szállításra van szükségük Sávszélesség vannak alkalmazások (pl. multimédia), melyeknek szükségük van egy bizonyos sávszélességre más alkalmazások („rugalmas alkalmazások”) felhasználnak bármilyen sávszélességet Időzítés vannak alkalmazások (pl. Internetes telefon, interaktív játékok), melyek nem tűrik a késéseket 2: Alkalmazási réteg

17 Alkalmazások szállítási szolgáltatásainak követelményei
állományátvitel Web dokumentumok „élő” audio/video tárolt audio/video interaktív játékok chat Adatvesztés nem megengedett Sávszélesség rugalmas audio: 5kbps-1Mbps video:10kbps-5Mbps --- néhány kbps Időzítés nem igen, 100 ms igen, néhány s igen és nem 2: Alkalmazási réteg

18 Internet szállítási protokollok szolgáltatásai
TCP szolgáltatásai: összeköttetés alapú: a kliens és a szerver közti kapcsolatteremtés szükséges megbízható szállítás a küldő és fogadó folyamatok között folyamellenőrzés: a küldő nem terheli túl a fogadót zsúfoltság ellenőrzés: lassítja a küldőt, ha a hálózat foglalt nem biztosít: időzítést, garantált minimális sávszélességet UDP szolgáltatásai: nem megbízható adatszállítás nem biztosítja: a kapcsolat beállítását, megbízhatóságot, folyamellenőrzést, zsúfoltság felügyeletet, időzítést, garantált sávszélességet K: Miért létezik akkor UDP 2: Alkalmazási réteg

19 Internetes alk.: alkalmazás, szállítási protkollok
Alkalmazási- réteg protokoll SMTP [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] védett (pl. RealNetworks) (pl. Dialpad) Szállítási protokoll TCP TCP vagy UDP tipikusan UDP Alkalmazás távoli terminál hozzáférés Web file átvitel áramlott multimédia Internetes telefon 2: Alkalmazási réteg

20 2. Fejezet: Alkalmazási réteg
2.1 Hálózati alkalmazások alapelvei alkalmazás-architektúrák alkalmazások igényei 2.2 Web és HTTP 2.3 FTP 2.4 SMTP, POP3, IMAP 2.5 DNS 2.6 P2P alkalmazások 2.7 Socket programozás TCP-vel 2.8 Socket programozás UDP-vel 2: Alkalmazási réteg

21 Web és HTTP Zsargon A weboldal objektumokból áll
Az objektum lehet HTML file, JPEG kép, Java, applet, audio file,… A weboldal alap HTML-file, amely beágyazott (hivatkozott) objektumokat tartalmaz Minden objektum egy URL-vel címezhető Példa URL-re: host név elérési út neve 2: Alkalmazási réteg

22 HTTP áttekintés HTTP: hypertext szállítási protokoll
Web alkalmazási réteg protokoll kliens/szerver modell kliens: böngésző, mely kér, fogad, „megmutat” webes objektumokat szerver: webszerver a kérésekre válaszol, objektumokat küld HTTP 1.0: RFC 1945 HTTP 1.1: RFC 2068 HTTP kérés PC–n Explorer fut HTTP válasz HTTP kérés Szerveren Apache Web server fut HTTP válasz Mac-on Navigator fut 2: Alkalmazási réteg

23 HTTP áttekintés (folytatás)
TCP-t használ: kliens inicializálja a TCP kapcsolatot (létrehoz egy socket-et) a szerverrel, a 80-as porton szerver elfogadja a TCP kapcsolatot HTTP üzenetek (alkalmazási-réteg protokoll üzenetek) a böngésző (HTTP kliens) és webszerver (HTTP szerver) között TCP kapcsolat zárul HTTP „állapot nélküli” A szerver nem tart meg információt a kliens régebbi kéréseiről kiegészítés Az olyan protkoll, mely megtartja az „állapotot”, komplex Megőrzi a régebbi kéréseket Ha a szerver/kliens lefagy, az állapotinformáció inkonszisztens lehet 2: Alkalmazási réteg

24 HTTP kapcsolatok Nemperszisztens HTTP
Legfeljebb egy objektumot küld egy TCP kapcsolaton. HTTP/1.0 nemperszisztens HTTP-t használ Perszisztens HTTP Összetett objektumok küldhetőek egyetlen TCP kapcsolaton keresztül a kliens és szerver között. HTTP/1.1 perszisztens kapcsoaltot használ alapértelmezésben 2: Alkalmazási réteg

25 Nemperszisztens HTTP (tartalmaz szöveget, és hivatkozást 10 jpeg képre) A felhasználó beírja az alábbi URL-t 1a. HTTP kliens inicializál egy TCP kapcsolatot a HTTP szerverhez a címre, a 80-as porton 1b. A HTTP szerver a hoszton TCP kapcsolatra vár a 80-as porton, „fogadja” a kapcsolatot, visszajelez a kliensnek 2. HTTP kliens küld egy HTTP kérést (URL) a TCP kapcsolat socket-én. Az üzenet kéri az alábbi objektumot someDepartment/home.index 3. HTTP szerver fogadja a kérést, létrehozza a választ benne az objektummal, és elküldi az üzenetet a megfelelő socket-re idő 2: Alkalmazási réteg

26 Nemperszisztens HTTP (folyt.)
4. HTTP szerver zárja a TCP kapcsolatot. 5. HTTP kliens megkapja az üzenetet, megjeleníti a html fájlt, elemzi azt és talál 10 referenciát 10 jpeg objektumokra idő lépések ismétlődnek mind a 10 jpeg objektumra 2: Alkalmazási réteg

27 Nemperszisztens HTTP: válaszidő
RTT (Round Trip Time) definícója: az az idő, ami alatt egy kis csomag eljut a klienstől a szerverig és vissza. Válaszidő: egy RTT a TCP kapcsolat inicializálására egy RTT a HTTP kérés elküldésétől a válasz első byte-jai megárkezéséig állomány lekérése össz = 2RTT+elküldési idő állomány küldési ideje TCP kapcsolat inicializálása RTT kérése fogadva idő 2: Alkalmazási réteg

28 Perszisztens HTTP Nemperszisztens HTTP :
2 RTT / obj szükséges OR közreműködése minden TCP kapcsolathoz A böngészők gyakran párhuzamos TCP kapcsolatokat nyitnak a hivatkozott objektumok letöltéséhez Perszisztens HTTP A szerver megnyitva hagyja a kapcsolatot a válasz elküldése után a következő HTTP üzenetek ugyanazon kliens és szerver között ugyanazt a TCP kapcsolatot használják Perszisztens csővezeték nélkül : a kliens csak akkor küld új kérést, ha már kapott választ az előbbire egy RTT hivatkozott objektumonként Perszisztens csővezetékkel : alapértelmezett HTTP/1.1-en a kliens kérést küld amint egy objektum-hivatkozást talál megközelítőleg egy RTT az összes hivatkozott objektumra 2: Alkalmazási réteg

29 HTTP kérés üzenet kétféle HTTP üzenet: kérés (request), válasz (response) HTTP kérés üzenet: ASCII (olvasható formátum) kérés sor (GET, POST, HEAD parancsok) GET /somedir/page.html HTTP/1.1 Host: User-agent: Mozilla/4.0 Connection: close Accept-language:fr (extra carriage return, line feed) fejléc sorok Carriage return, line feed jelzi az üzenet végét 2: Alkalmazási réteg

30 HTTP kérés üzenet: általános alak
2: Alkalmazási réteg

31 Form bemenet feltöltése
Post metódus: A weboldal gyakran tartalmaz form bemenetet A bemenet az üzenet testében (entity body) jut el a szerverhez URL módszer: GET metódust használ A bemenet a kérés sor URL mezőjébe kerül : 2: Alkalmazási réteg

32 Metódusok HTTP/1.0 GET POST HEAD HTTP/1.1 GET, POST, HEAD PUT DELETE
kéri a szervert, hogy hagyja ki az objektumot a válaszból HTTP/1.1 GET, POST, HEAD PUT feltölti az üzenet testében szereplő file-t az URL-ben megadott címre DELETE törli az URL mezőben megadott file-t 2: Alkalmazási réteg

33 HTTP válaszüzenet állapot sor (protokoll állapot kód állapot mondat)
HTTP/ OK Connection close Date: Thu, 06 Aug :00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html data data data data data ... fejléc sorok adat, pl. a kért HTML file 2: Alkalmazási réteg

34 HTTP válasz állapotkódok
A szerver->kliens válaszüzenet első sorában. Néhány példa : 200 OK kérés sikeres, a keresett objektum az üzentben 301 Moved Permanently a keresett objektum áthelyezve, az új helye később az üzenetben (Location:) 400 Bad Request a szerver nem érti a kérést 404 Not Found a keresett dokumentum nincs a szerveren 505 HTTP Version Not Supported 2: Alkalmazási réteg

35 Próbáljuk ki a HTTP-t (kliens-oldal)
1. Telnet a kedvenc webszerverünkre: telnet cis.poly.edu 80 TCP kapcsolatot nyit a 80-as portra (alapértelmezett HTTP szerverport) a cis.poly.edu-ra. Mindent, amit beírunk elküldi a cis.poly.edu 80-as portjára 2. Írjuk be a GET HTTP kérést: Ezt beírva (két ENTER utána), minimális (de teljes) GET kérést küldtünk a HTTP szervernek GET /~ross/ HTTP/1.1 Host: cis.poly.edu 3. Nézzük meg a HTTP szerver által küldött választ! 2: Alkalmazási réteg

36 Kövessük a HTTP-t munka közben
telnet példa Ethereal példa 2: Alkalmazási réteg

37 Felhasználó-szerver állapot: cookie-k (sütik)
Példa : Susan mindig ugyanazzal a PC-vel internetezik először nyit meg egy kereskedelmi oldalt az első HTTP kérés vételekor a site létrehoz: egyedi azonosítót (ID) egy új bemenetet az adatbázisban az azonosító számára Számos weboldal használ cookie-kat Négy komponens: 1) cookie fejlécsor a HTTP válaszüzenetben 2) cookie fejlécsor a HTTP kérésüzenetben 3) cookie állomány a felhasználó hostján, amelyet a böngésző kezel 4) adatabázis a web-oldalon (szerver) 2: Alkalmazási réteg

38 Cookie-k: állapotmegjegyzés (folytatás)
kliens szerver ebay 8734 usual http request msg Amazon szerver létrehozza az 1678-as ID-t a felhasználónak bemenet létrehozás cookie file usual http response Set-cookie: 1678 ebay 8734 amazon 1678 usual http request msg cookie: 1678 cookie-ra jellemző művelet hozzáférés usual http request msg cookie: 1678 cookie-ra jellemző művelet hozzáférés usual http response msg adatbázis egy héttel később: ebay 8734 amazon 1678 usual http response msg 2: Alkalmazási réteg

39 Cookie-k (folytatás) Cooki-k és „magánélet” (privacy):
kiegészítés Cooki-k és „magánélet” (privacy): cookie-k révén a site-ok információt kaphatnak a felhasználóról megadhatunk nevet, -címet, stb Mire használható a cookie: engedélyezés bevásárlókocsi ajánlatok, reklám felhasználói „ülés” (session) állapota (pl. webmail) Hogyan jegyezhető meg az állapot: protokoll végpontoknál: a küldő/ fogadó megtartja az állapotot több tranzakción keresztül cookie-k: a http üzenet tartalmazza az állapotot is 2: Alkalmazási réteg

40 Web cache-ek (proxy szerver)
Cél: a kliens kérésének kielégítése a célzott szerver beavatkozása nélkül böngésző beállítása: Web hozzáférés cache-en keresztül a böngésző minden HTTP kérést a cache-hez küld objektum a cache-ben: a cache visszatéríti az objektumot ha nincs, akkor a cache az eredeti szervertől kéri az objektumot s elküldi a kliensnek szerver HTTP válasz HTTP vélasz Proxy szerver HTTP kérés HTTP kérést kliens HTTP kérés HTTP response kliens szerver 2: Alkalmazási réteg

41 Bővebben a Web cache-ről
a cache kliensként és szerverként egyaránt működik általában a cache-t az ISP telepíti (egyetem, cég) Miért jó a Web cache? csökkenti a válaszidőt a kliens kérésére csökkenti a forgalmat egy intézmény kimenő vonalán. cache-ekben „bővelkedő” Internet: lehetővé teszi, hogy „gyenge” adatforgal-mazók is kézbesítsék adataikat (ezt eléri a P2P állománymegosztás is) 2: Alkalmazási réteg

42 Cache példa Feltételezzük, hogy Következmények adatszolgáltató
szerverek Feltételezzük, hogy átlagos objektum méret = bit egy intézmény böngészőitől másodpercenként átalagosan 15 kérés megy a szerverekhez késés az intézmény routerétől valamely szerverig és vissza = 2 sec Következmények LAN kihasználtsága = 15% kimenő kapcsolat kihasználtsága = 100% teljes késés = Internet késés + hozzáférési késés + LAN késés = 2 s + percek + ms-ok nyilvános Internet 1.5 Mbps-os kimenő kapcsolat intézményi hálózat 10 Mbps-os LAN 2: Alkalmazási réteg

43 Cache példa (folytatás)
adatszolgáltató szerverek lehetséges megoldás növeljük a kimenő kapcsolat sávszélességét pl. 10 Mbps-ra következmény LAN kihasználtsága = 15% kimenő kapcsolat kihasználtsága = 15% teljes késés = Internet késés + hozzáférési késés + LAN késés = 2 s + ms-ok + ms-ok gyakran költséges felújítás nyilvános Internet 10 Mbps-os kimenő kapcsolat intézményi hálózat 10 Mbps-os LAN 2: Alkalmazási réteg

44 Cache példa (folytatás)
adatszolgáltató szerverek lehetséges megoldás: cache telepítése feltételezzük, hogy a találati arány 0.4 következmény 40%-át a kéréseknek szinte azonnal teljesíti 60%-át a kéréseknek az adatszolgáltató szerverek teljesítik a kimenő kapcsolat kihasznált-sága 60%-ra csökken minimális késésnövekedéssel (pl. 10 ms) teljes átlagos késés = Internet késés + hozzáférési késés + LAN késés = 0,6*(2,01) s + 0,4*ms-ok < 1,4 s nyilvános Internet 1.5 Mbps-os kimenő kapcsolat intézményi hálózat 10 Mbps-os LAN intézményi cache 2: Alkalmazási réteg

45 If-modified-since: <date> If-modified-since: <date>
Feltételes GET cache szerver Cél: ne küldjük el az objektumot, ha a cache-ben megvan a naprakész verzió cache: megadja a cache-elt másolat dátumát a HTTP kérésben If-modified-since: <date> szerver: a válasz nem tartalmazza az objektumot, ha az időközben nem változott: HTTP/ Not Modified HTTP request msg If-modified-since: <date> az objektum nem változott HTTP response HTTP/1.0 304 Not Modified HTTP request msg If-modified-since: <date> az objektum változott HTTP response HTTP/ OK <data> 2: Alkalmazási réteg

46 2. Fejezet: Alkalmazási réteg
2.1 Hálózati alkalmazások alapelvei alkalmazás-architektúrák alkalmazások igényei 2.2 Web és HTTP 2.3 FTP 2.4 SMTP, POP3, IMAP 2.5 DNS 2.6 P2P alkalmazások 2.7 Socket programozás TCP-vel 2.8 Socket programozás UDP-vel 2: Alkalmazási réteg

47 FTP: az állományátviteli protokoll
felhasz. interfész kliens file átvitel FTP szerver felhaszn. a hoszton lokális állomány rendszer távoli állomány rendszer Állomány letöltése / feltöltése távoli hosztról kliens/szerver modell kliens: inicializálja az átvitelt (fogadja/küldi a file-t) szerver: távoli hoszt ftp: RFC 959 ftp szerver: port 21 2: Alkalmazási réteg

48 FTP: külön vezérlő, illetve adatkapcsolat
kliens szerver TCP vezérlő-kapcsolat 21-es port TCP adatkacsolat 20-as port FTP kliens kapcsolatba lép az FTP szerverrel a 21-es porton, TCP szállítási protokollal a kliens engedélyezése a vezérlő kapcsolaton a kliens kereshet a távoli katalógusokban a vezérlő-kapcsolaton küldött parancsokkal. állomány-átviteli parancs érkezésekor a szerver nyit egy második TCP kapcsolatot a klienshez az állomány átvitele után a szerver zárja az adatkapcsolatot. a szerver új TCP kapcsolatot nyit egy második file átvitelére vezérlő kapcsolat: „sávon kívül” az FTP szerver megtartja az „állapotot”: jelenlegi katalógus, előbbi engedélyezés 2: Alkalmazási réteg

49 FTP parancsok, válaszok
példák parancsokra: ASCII szövegként küldi el a vezérlőkapcsolaton USER username PASS password LIST az aktuális katalógus tartalmának lekérdezése RETR filename állomány letöltése STOR filename feltöltése a távoli hosztra visszatérésikód példák ugyanúgy, mint a HTTP-ben) 331 Username OK, password required 125 data connection already open; transfer starting (adatkapcsolat már nyítva, átvitel indul) 425 Can’t open data connection (Nem nyitható meg az adatkapcsolat) 452 Error writing file 2: Alkalmazási réteg

50 2. Fejezet: Alkalmazási réteg
2.1 Hálózati alkalmazások alapelvei alkalmazás-architektúrák alkalmazások igényei 2.2 Web és HTTP 2.3 FTP 2.4 SMTP, POP3, IMAP 2.5 DNS 2.6 P2P alkalmazások 2.7 Socket programozás TCP-vel 2.8 Socket programozás UDP-vel 2: Alkalmazási réteg

51 Elektronikus posta Három fő komponens: SMTP SMTP SMTP
Felh. postaláda Kimenő üzenetsor felh. Három fő komponens: felhasználói alkalmazás mailszerverek levélszállítási protokoll: SMTP (Simple Mail transfer protocol) Felhasználó „levélolvasó” levél- írás, olvasás, küldés pl., Eudora, Outlook, elm, Mizilla Thunderbird ki-/bemenő leveleket a szerver tárolja mail szerver felh. SMTP mail server felh. SMTP mail szerver SMTP felh. felh. felh. 2: Alkalmazási réteg

52 Elektronikus posta: mailszerverek
felh. Mailszerverek a postaláda tartalmazza a felhasználó beérkezett üzeneteit üzenetsor: kimenő üzenetek sora SMTP protokoll mailszerverek közti üzenetek küldését biztosítja kliens: küldő mailszerver „szerver”: fogadó mailszerver mail szerver felh. SMTP mail szerver felh. SMTP mail szerver SMTP felh. felh. felh. 2: Alkalmazási réteg

53 Elektronikus posta: SMTP [RFC 2821]
TCP-t használ a megbízható adatkapcsolat érdekében, a 25-ös porton kommunikál közvetlen átvitel: küldő szerver  fogadó szerver három lépés kézfogás üzenetek elküldése zárás parancsok/válaszok parancsok: ASCII szöveg válasz: állapotkód és magyarázat az üzenet 7-bites ASCII formátumban kell legyen 2: Alkalmazási réteg

54 Forgatókönyv: Alice üzenetet küld Bobnak
1) Alice levelezőprogramját használja, hogy levelet írjon és elküldje a címre 2) Az üzenet elmegy az Alice mailszerveréhez; bekerül a várakozási sorba 3) az SMTP kliens nyit egy TCP kapcsolatot Bob mailszerveréhez 4) Az SMTP kliens elküldi Alice üzenetét a TCP kapcsolaton 5) Bob mailszervere beteszi az üzenetet a Bob postaládájába 6) Bob elolvassa az üzenetet a levelezőprogramja segítségével mail szerver mail szerver 1 felh. közv. felh. közv. 2 3 6 4 5 2: Alkalmazási réteg

55 SMTP kommunikáció példa
S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: S: 250 Sender ok C: RCPT TO: S: Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Do you like ketchup? C: How about pickles? C: . S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection 2: Alkalmazási réteg

56 Próbáljuk ki az SMTP kapcsolatot:
telnet szervernév 25 figyeljük meg a 220-as választ a szervertől próbáljuk ki a következő parancsokat: HELO, MAIL FROM, RCPT TO, DATA, QUIT ezen parancsok segítségével t lehet küldeni levelezőprogram használata nélkül 2: Alkalmazási réteg

57 SMTP: következtetés Összehasonlítás HTTP-vel:
SMTP perszisztens kapcsolatot használ az SMTP csak 7-bites ASCII üzenetekkel dolgozik SMTP szerver CRLF.CRLF használ az üzenet végének detektálására Összehasonlítás HTTP-vel: HTTP: pull SMTP: push ASCII parancs/válasz kölcsönhatás, státus kódok mindkettőnél HTTP: mindegyik objektumot külön üzenetben küldi el SMTP: többszörös objektumokat többrészes üzenetben küldi el 2: Alkalmazási réteg

58 A levél formátuma fejléc test SMTP: protokoll
RFC 822: standard szöveges üzenetekre: fejléc, pl. To: From: Subject: különbözik az SMTP parancsoktól ! test maga az „üzenet”, ASCII karakterek fejléc üres sor test 2: Alkalmazási réteg

59 Levél formátum: multimédia kiterjesztések
MIME: multimedia mail extension, RFC 2045, 2056 további sorok a fejlécben jelzik a MIME tartalom típusát From: To: Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......base64 encoded data MIME verzió kódolási módszer multimédia adat típus, altípus, paraméterek kódolt adat 2: Alkalmazási réteg

60 MIME típusok típus/altípus; paraméterek
Text (szöveg) pl. altípusok: plain, html Image (kép) pl. altípusok: jpeg, gif Audio (hang) pl. altípusok: basic (8-biten kódolt), 32kadpcm (32 kbps kódolt) Video pl. altípusok: mpeg, quicktime Alkalmazás Olyan adatok, amelyeket át kell dolgozni, mielőtt olvasható lesz pl. altípus: msword, octet-stream 2: Alkalmazási réteg

61 Multipart (Többrészes) típus
From: To: Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=StartOfNextPart --StartOfNextPart Dear Bob, Please find a picture of a crepe. Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......base64 encoded data Do you want the reciple? 2: Alkalmazási réteg

62 Mail elérési protokollok
SMTP SMTP elérési protokoll felh. közv. felh. közv. A küldő mailszervere A fogadó mailszervere SMTP: küldés/tárolás a fogadó szerverére Mail elérési protokollok: adat fogadása a szervertől POP: Post Office Protocol [RFC 1939] engedélyezés (levelezőprogram <-->szerver) és letöltés IMAP: Internet Mail Access Protocol [RFC 1730] komplexebb dolgozni lehet a szerveren tárolt üzenetekkel HTTP: gmail, Hotmail , Yahoo! Mail, etc. 2: Alkalmazási réteg

63 POP3 protokoll engedélyezési fázis C: list tranzakció fázis, kliens:
S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on engedélyezési fázis kliens parancsok: user: felh. név megadása pass: jelszó szerver válaszok +OK -ERR tranzakció fázis, kliens: list: üzenetek számai retr: üzenet lekérése számuk szerint dele: törlés quit: kilépés C: list S: 1 498 S: 2 912 S: . C: retr 1 S: <message 1 contents> C: dele 1 C: retr 2 S: <message 2 contents> C: dele 2 C: quit S: +OK POP3 server signing off 2: Alkalmazási réteg

64 POP3 (folytatás) és IMAP
Az előbbi példa „download és delete”-et használ. Bob nem olvashatja újra az üzenetet, ha klienst cserél “Download-and-keep”: másolja az üzenetet különböző kliensekre a POP3 állapotmentes az ülések között IMAP Minden üzenetet egy helyen, a szerveren tárol A felhasználó az üzeneteket könyvtárakban tárolhatja IMAP elmenti az állapotot: könyvtárak nevei, megfeleltetés az üzenet azonosítója és a könyvtár neve között, stb. 2: Alkalmazási réteg

65 2. Fejezet: Alkalmazási réteg
2.1 Hálózati alkalmazások alapelvei alkalmazás-architektúrák alkalmazások igényei 2.2 Web és HTTP 2.3 FTP 2.4 SMTP, POP3, IMAP 2.5 DNS 2.6 P2P alkalmazások 2.7 Socket programozás TCP-vel 2.8 Socket programozás UDP-vel 2: Alkalmazási réteg

66 DNS: Domain Name System (Doméniumnév rendszer)
Emberek: számos azonosító: „CNP”, név, útlevélszám Internet hosztok, ruterek: IP cím (32 bit) a datagrammok címzésére „név” pl., gaia.cs.umass.edu – emberek által használt K: IP cím és név közti kapcsolat? Domain Name System: osztott adatbázis számos névszerver hierarchiájában implementált alalmazási-réteg protokoll hosztok, routerek, névszerverek kommunikálnak a nevek „megfejtése” érdekében (cím/név fordítása) megjegyzés: Internet-mag funkció, amit mégis alkalmazási-réteg protokoll implementál komplexitás a hálózat „peremén” 2: Alkalmazási réteg

67 DNS Miért nem központosítják a DNS-t? DNS szolgáltatások
egyetlen kritikus pont nagy adatforgalom nagy távolság karbantartás nehezen bővíthető! DNS szolgáltatások hosztnév IP címre fordítása hoszt álnév (alternatív név, alias) Kanonikus, alias nevek mail szerver aliasing forgalom megosztása másolt Web szerverek: több IP cím egy kanonikus névhez 2: Alkalmazási réteg

68 Osztott, hierarchikus adatbázis
Root DNS Servers com DNS servers org DNS servers edu DNS servers poly.edu DNS servers umass.edu yahoo.com amazon.com pbs.org a kliens a IP címét keresi; 1. megközelítés: a kliens egy root szerverhez fordul, hogy megkapja a com DNS szervert a kliens megkérdezi a com DNS szervert, hogy megkapja az amazon.com DNS szervert a kliens megkérdezi az amazon.com DNS szervert, hogy megkapja a IP címét 2: Alkalmazási réteg

69 DNS: Root névszerverek
a lokális névszerver lép vele kapcsolatba, ha nem ismeri a nevet root névszerver: kapcsolatba lép a parancsoló (authoritative) névszerverrel, ha a név megfeleltetést nem ismeri elküldi a megfeleltetést a lokális névszerverhez a Verisign, Dulles, VA c Cogent, Herndon, VA (also LA) d U Maryland College Park, MD g US DoD Vienna, VA h ARL Aberdeen, MD j Verisign, ( 21 locations) k RIPE London (also 16 other locations) i Autonomica, Stockholm (plus other locations) e NASA Mt View, CA f Internet Software C. Palo Alto, CA (and 36 other locations) m WIDE Tokyo (also Seoul, Paris, SF) 13 root név- szerver a világon b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA 2: Alkalmazási réteg

70 TLD és parancsoló szerverek
Top-level domain (TLD) szerverek: hatáskörükben a com, org, net, edu, stb., illetve a legfelsőbb szintű országdoméniumok, pl. uk, fr, ca, jp. Network Solutions tartja fenn a com TLD szervereit Educause az edu TLD-t Parancsoló (authoritative) DNS szerverek: szervezetek DNS szerverei, az adott szervezet szervereinek hosztnév – IP cím megfeleltetéseit szolgáltatja (pl.,Web, mail). az adott szervezet vagy az internet szolgáltató működtetheti 2: Alkalmazási réteg

71 Lokális névszerverek nem tartozik szigorúan a hierarchiához
minden ISP (lakótelepi ISP, cég, egyetem) rendelkezik eggyel. alapértelmezett (default) névszervernek is hívják egy hoszt a DNS kérését a lokális névszerverhez küldi proxy-ként működik, továbbítja a kérést a hierarchiába 2: Alkalmazási réteg

72 parancsoló DNS szerver
DNS név megoldás példa root DNS szerver 2 A cis.poly.edu keresi a gaia.cs.umass.edu IP címét 3 TLD DNS szerver 4 5 iterált lekérés: a megkeresett szerver a hierarchiában következő szerver nevével válaszol „Nem ismerem ezt a nevet, de kérdezd meg ettől a szervertől” lokális DNS szerver dns.poly.edu 7 6 1 8 parancsoló DNS szerver dns.cs.umass.edu kérdező hoszt cis.poly.edu gaia.cs.umass.edu 2: Alkalmazási réteg

73 parancsoló DNS szerver
DNS név megoldás példa kérdező hoszt cis.poly.edu gaia.cs.umass.edu root DNS server lokális DNS szerver dns.poly.edu 1 2 4 5 6 parancsoló DNS szerver dns.cs.umass.edu 7 8 TLD DNS server 3 recurzív lekérés: átadja a név megoldásának feladatát a következő névszervernek nagy terhelés? 2: Alkalmazási réteg

74 DNS: cache és bejegyzések frissítése
ha egy névszerver megtanul egy megfeleltetést, akkor megjegyzi azt (cache) a cache bemenetek egy idő után eltűnnek (timeout) a lokális névszerverek általában megjegyzik a TLD szervereket így csak ritkán kell a root névszerverekhez fordulni frissítés/értesítés mechanizmusát még tervezik az IETF-nél RFC 2136 2: Alkalmazási réteg

75 RR formátum: (név, érték, típus,ttl)
DNS rekordok DNS: az osztott adatbázis erőforrás rekordokat tárol (RR - Resource Record) RR formátum: (név, érték, típus,ttl) Típus=A név a hosztnév érték az IP cím Típus=CNAME név egy kanonikus (valódi) név álneve (alias) valójában servereast.backup2.ibm.com érték a kanonikus név Típus=NS név a doménium (pl. foo.com) érték ezen doménium parancsoló névszerverének a neve Típus=MX érték a névhez tartozó mailszerver neve 2: Alkalmazási réteg

76 DNS protokoll, üzenetek
DNS protokoll : kérdés- és válasz- üzenetek, az üzenetformátum egyforma üzenet fejléc azonosító: 16 bites szám a kérésben, a válasz ugyanazt a számot használja flag-ek: kérés vagy válasz rekurzió kivánatos rekurzió lehetséges a válasz parancsolt 2: Alkalmazási réteg

77 DNS protokoll, üzenetek
Név, típus mezők a kérés számára RR-ek kérésre válaszként rekordok parancsoló szerverek számára más „hasznos” információk 2: Alkalmazási réteg

78 Bejegyzés beszúrása a DNS-be
pálda: új hálózat „Network Utopia” networkuptopia.com név bejegyzése egy DNS iktatóba (pl. Network Solutions) megadjuk a nevet, a parancsoló névszerver IP címeit (elsődleges és másodlagos) az iktató két RR bejegyzést készít a com TLD szerveren: (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, , A) parancsoló névszerver bejegyzések létrehozása: A típusú bejegyzés MX típusú bejegyzés networkutopia.com-nak Hogy kapható meg a honlapunk IP címe? 2: Alkalmazási réteg

79 2. Fejezet: Alkalmazási réteg
2.1 Hálózati alkalmazások alapelvei alkalmazás-architektúrák alkalmazások igényei 2.2 Web és HTTP 2.3 FTP 2.4 SMTP, POP3, IMAP 2.5 DNS 2.6 P2P alkalmazások 2.7 Socket programozás TCP-vel 2.8 Socket programozás UDP-vel 2: Alkalmazási réteg

80 P2P állománymegosztás Alice kiválaszt egyet a társak (peer) közül, pl. Bob-ot HTTP-n keresztül lemásolja az állományt Bob géperől az Alice gépére miközben Alice másol, más felhasználok tőle másolnak Alice gépe egyben webkliens és egy alkalmi webszerver is. Minden társ (peer) egy szerver  bővíthetőség Példa Alice–nak a számítógépén fut egy P2P alkalmazás alkalmanként kacspolódik az Internetre; mindig új IP címmel keresi a „Hey Jude” számot az alkalmazás kiírja, melyik gépeken találta meg a számot 2: Alkalmazási réteg

81 Centralizált katalógus
katalógus szerver társak Alice Bob 1 2 3 eredeti „Napster” vázlat 1) ha egy peer kapcsolódik, szól a központi szervernek: IP cím tartalom 2) Alice érdeklődik a „Hey Jude” számoról 3) Alice kéri az állományt Bobtól 2: Alkalmazási réteg

82 Problémák a centralizált katalógussal
egyetlen meghibásodási pont teljesítmény „szűkkeresztmetszet” Copyright problémája az állományátvitel nem centralizált, de a keresett anyag lokalizálása nagyon is centralizált 2: Alkalmazási réteg

83 Lekérdezés „elárasztással”: Gnutella
teljesen osztott nincs központi szerver nyilvános protokoll különböző Gnutella kliensek valósítják meg a protokollt átfedő hálózat (overlay network): gráf él X és Y társ között, ha TCP kapcsolat van köztük az összes aktív társ és a köztük meglevő élek alkotják az átfedő hálózatot él: virtuális kapcsolat (nem közvetlen fizikai kapcsolat) egy társnak jellemzően < 10 overlay szomszédja 2: Alkalmazási réteg

84 Gnutella: protokoll Állományátvitel: HTTP lekérdezés (kérés üzenet) meglevő TCP kapcsolatokon a társak továbbít- ják a kérést találat visszaküldése fordított útvonalon Kérés Találat Lekérdezés Bővíthetőség: korlátozott távolságú elárasztás 2: Alkalmazási réteg

85 Gnutella: társ (peer) csatlakozása
Alice, a csatlakozó társ kell találjon egy másik társat a Gnutella hálózatban: jelöltlisták használata Alice sorban próbálkozik TCP kapcsolatok létesítésével a jelölt társakkal, amíg talál egy aktívat, pl. Bobot Elárasztás: Alice Ping üzenetet küld Bobnak; Bob továbbítja a Ping üzenetet a szomszédjainak (akik a maguk során továbbítják a saját szomszédjaiknak….) a társak, akik megkapják a Ping üzenetet egy Pong üzenettel válaszolnak Alicenak Alice számos Pong üzenetet kap, ezek alapján újabb TCP kapcsolatokat létesíthet 2: Alkalmazási réteg

86 Hierarchikus lefedés a központosított katalógus és az elárasztás kombinációja minden társ vagy csoport-vezető, vagy egy csoport-vezetőhöz tartozik. TCP kapcsolat egy társ és a csoportvezetője között. TCP kapcsolat egyes csoportvezetők között. a csoportvezető számontartja a csoportjabeli társak katalógusait 2: Alkalmazási réteg

87 Kliens-szerver és P2P architektúrák összehasonlítása
Kérdés : Mennyi időbe telik az eredetileg egy szerveren meglevő állomány eljuttatása N másik gépre? us: szerver upload sávszélesség Szerver ui: i. kliens/társ upload sávszélessége u1 d1 u2 d2 us di: i. kliens/társ download sávszélessége File, mérete F dN Hálózat (nagy sávszélesség) uN 2: Alkalmazási réteg

88 Kliens-szerver: állomány szétküldési idő
a szerver sorban elküld N másolatot: NF/us i. kliensnek F/di időbe telik a letöltés F u2 u1 d1 d2 us Hálózat (nagy sávszélesség) dN uN = dcs = max { NF/us, F/min(di) } i F szétküldési ideje N kliensnek – kliens/szerver lineárisan nő N szerint (nagy N-re) 2: Alkalmazási réteg

89 P2P: állomány szétküldési idő
Szerver a szerver el kell küldjön egy másolatot: F/us time i. kliensnek F/di időbe telik a letöltés NF bitet kell letölteni (összesen) F u2 u1 d1 d2 us Hálózat (nagy sávszélesség) dN uN lehető legnagyobb feltöltési sebesség (feltételezve, hogy minden csomópont ugyanannak a társnak küld darabokat): us + Sui i=1,N dP2P = max { F/us, F/min(di) , NF/(us + Sui) } i i=1,N 2: Alkalmazási réteg

90 Összehasonlítás: kliens-szerver  P2P
2: Alkalmazási réteg

91 P2P esettanulmány: BitTorrent
P2P állomány szétosztás (darab = chunk) nyomkövető (tracker): figyeli a torrentben résztvevő társakat torrent: társak csoportja, akik egy állomány darabjait cserélik társak lisájának lekérése darbok cseréje társ 2: Alkalmazási réteg

92 BitTorrent (1) az állományt 256KB-os darabokra (chunks) osztja.
társ belépése a torrentbe: nincsenek darabjai, de idővel megszerzi őket regisztrál a nyomkövetőnél, hogy megkapja a társak listáját, kapcsolódik néhány társhoz („szomszédok”) mialatt letölt, a társ darabokat tölt fel más társaknak. társak beléphetnek és kiléphetnek mikor egy társ megkapta az egész állományt (önzően) kiléphet, or (altruistically) remain 2: Alkalmazási réteg

93 BitTorrent (2) Pulling Chunks Sending Chunks: tit-for-tat
at any given time, different peers have different subsets of file chunks periodically, a peer (Alice) asks each neighbor for list of chunks that they have. Alice issues requests for her missing chunks rarest first Sending Chunks: tit-for-tat Alice sends chunks to four neighbors currently sending her chunks at the highest rate re-evaluate top 4 every 10 secs every 30 secs: randomly select another peer, starts sending chunks newly chosen peer may join top 4 2: Alkalmazási réteg

94 P2P Case study: Skype Skype clients (SC) P2P (pc-to-pc, pc-to-phone, phone-to-pc) Voice-Over-IP (VoIP) application also IM proprietary application-layer protocol (inferred via reverse engineering) hierarchical overlay Skype login server Supernode (SN) 2: Alkalmazási réteg

95 Skype: making a call User starts Skype SC registers with SN
list of bootstrap SNs Skype login server SC logs in (authenticate) Call: SC contacts SN will callee ID SN contacts other SNs (unknown protocol, maybe flooding) to find addr of callee; returns addr to SC SC directly contacts callee, overTCP 2: Alkalmazási réteg

96 Chapter 2: Application layer
2.1 Principles of network applications 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P file sharing 2.7 Socket programming with TCP 2.8 Socket programming with UDP 2: Alkalmazási réteg

97 2. Fejezet: Alkalmazási réteg
2.1 Hálózati alkalmazások alapelvei alkalmazás-architektúrák alkalmazások igényei 2.2 Web és HTTP 2.3 FTP 2.4 SMTP, POP3, IMAP 2.5 DNS 2.6 P2P alkalmazások 2.7 Socket programozás TCP-vel 2.8 Socket programozás UDP-vel 2: Alkalmazási réteg

98 Socket programming Goal: learn how to build client/server application that communicate using sockets Socket API introduced in BSD4.1 UNIX, 1981 explicitly created, used, released by apps client/server paradigm two types of transport service via socket API: unreliable datagram reliable, byte stream-oriented a host-local, application-created, OS-controlled interface (a “door”) into which application process can both send and receive messages to/from another application process socket 2: Alkalmazási réteg

99 Socket-programming using TCP
Socket: a door between application process and end-end-transport protocol (UCP or TCP) TCP service: reliable transfer of bytes from one process to another controlled by application developer controlled by application developer process TCP with buffers, variables socket process TCP with buffers, variables socket controlled by operating system controlled by operating system internet host or server host or server 2: Alkalmazási réteg

100 Socket programming with TCP
Client must contact server server process must first be running server must have created socket (door) that welcomes client’s contact Client contacts server by: creating client-local TCP socket specifying IP address, port number of server process When client creates socket: client TCP establishes connection to server TCP When contacted by client, server TCP creates new socket for server process to communicate with client allows server to talk with multiple clients source port numbers used to distinguish clients (more in Chap 3) TCP provides reliable, in-order transfer of bytes (“pipe”) between client and server application viewpoint 2: Alkalmazási réteg

101 Client/server socket interaction: TCP
Server (running on hostid) Client create socket, port=x, for incoming request: welcomeSocket = ServerSocket() TCP connection setup close connectionSocket read reply from clientSocket create socket, connect to hostid, port=x clientSocket = Socket() wait for incoming connection request connectionSocket = welcomeSocket.accept() send request using clientSocket read request from connectionSocket write reply to 2: Alkalmazási réteg

102 Stream jargon A stream is a sequence of characters that flow into or out of a process. An input stream is attached to some input source for the process, e.g., keyboard or socket. An output stream is attached to an output source, e.g., monitor or socket. Client process client TCP socket 2: Alkalmazási réteg

103 Socket programming with TCP
Example client-server app: 1) client reads line from standard input (inFromUser stream) , sends to server via socket (outToServer stream) 2) server reads line from socket 3) server converts line to uppercase, sends back to client 4) client reads, prints modified line from socket (inFromServer stream) 2: Alkalmazási réteg

104 Example: Java client (TCP)
import java.io.*; import java.net.*; class TCPClient { public static void main(String argv[]) throws Exception { String sentence; String modifiedSentence; BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); Socket clientSocket = new Socket("hostname", 6789); DataOutputStream outToServer = new DataOutputStream(clientSocket.getOutputStream()); Create input stream Create client socket, connect to server Create output stream attached to socket 2: Alkalmazási réteg

105 Example: Java client (TCP), cont.
Create input stream attached to socket BufferedReader inFromServer = new BufferedReader(new InputStreamReader(clientSocket.getInputStream())); sentence = inFromUser.readLine(); outToServer.writeBytes(sentence + '\n'); modifiedSentence = inFromServer.readLine(); System.out.println("FROM SERVER: " + modifiedSentence); clientSocket.close(); } Send line to server Read line from server 2: Alkalmazási réteg

106 Example: Java server (TCP)
import java.io.*; import java.net.*; class TCPServer { public static void main(String argv[]) throws Exception { String clientSentence; String capitalizedSentence; ServerSocket welcomeSocket = new ServerSocket(6789); while(true) { Socket connectionSocket = welcomeSocket.accept(); BufferedReader inFromClient = new BufferedReader(new InputStreamReader(connectionSocket.getInputStream())); Create welcoming socket at port 6789 Wait, on welcoming socket for contact by client Create input stream, attached to socket 2: Alkalmazási réteg

107 Example: Java server (TCP), cont
DataOutputStream outToClient = new DataOutputStream(connectionSocket.getOutputStream()); clientSentence = inFromClient.readLine(); capitalizedSentence = clientSentence.toUpperCase() + '\n'; outToClient.writeBytes(capitalizedSentence); } Create output stream, attached to socket Read in line from socket Write out line to socket End of while loop, loop back and wait for another client connection 2: Alkalmazási réteg

108 Chapter 2: Application layer
2.1 Principles of network applications 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P file sharing 2.7 Socket programming with TCP 2.8 Socket programming with UDP 2.9 Building a Web server 2: Alkalmazási réteg

109 2. Fejezet: Alkalmazási réteg
2.1 Hálózati alkalmazások alapelvei alkalmazás-architektúrák alkalmazások igényei 2.2 Web és HTTP 2.3 FTP 2.4 SMTP, POP3, IMAP 2.5 DNS 2.6 P2P alkalmazások 2.7 Socket programozás TCP-vel 2.8 Socket programozás UDP-vel 2: Alkalmazási réteg

110 Socket programming with UDP
UDP: no “connection” between client and server no handshaking sender explicitly attaches IP address and port of destination to each packet server must extract IP address, port of sender from received packet UDP: transmitted data may be received out of order, or lost application viewpoint UDP provides unreliable transfer of groups of bytes (“datagrams”) between client and server 2: Alkalmazási réteg

111 Client/server socket interaction: UDP
Server (running on hostid) create socket, clientSocket = DatagramSocket() Client Create, address (hostid, port=x, send datagram request using clientSocket create socket, port=x, for incoming request: serverSocket = DatagramSocket() read request from serverSocket close clientSocket read reply from clientSocket write reply to serverSocket specifying client host address, port number 2: Alkalmazási réteg

112 Example: Java client (UDP)
process Input: receives packet (recall thatTCP received “byte stream”) Output: sends packet (recall that TCP sent “byte stream”) client UDP socket 2: Alkalmazási réteg

113 Example: Java client (UDP)
import java.io.*; import java.net.*; class UDPClient { public static void main(String args[]) throws Exception { BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); DatagramSocket clientSocket = new DatagramSocket(); InetAddress IPAddress = InetAddress.getByName("hostname"); byte[] sendData = new byte[1024]; byte[] receiveData = new byte[1024]; String sentence = inFromUser.readLine(); sendData = sentence.getBytes(); Create input stream Create client socket Translate hostname to IP address using DNS 2: Alkalmazási réteg

114 Example: Java client (UDP), cont.
Create datagram with data-to-send, length, IP addr, port DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 9876); clientSocket.send(sendPacket); DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); clientSocket.receive(receivePacket); String modifiedSentence = new String(receivePacket.getData()); System.out.println("FROM SERVER:" + modifiedSentence); clientSocket.close(); } Send datagram to server Read datagram from server 2: Alkalmazási réteg

115 Example: Java server (UDP)
import java.io.*; import java.net.*; class UDPServer { public static void main(String args[]) throws Exception { DatagramSocket serverSocket = new DatagramSocket(9876); byte[] receiveData = new byte[1024]; byte[] sendData = new byte[1024]; while(true) DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); serverSocket.receive(receivePacket); Create datagram socket at port 9876 Create space for received datagram Receive datagram 2: Alkalmazási réteg

116 Example: Java server (UDP), cont
String sentence = new String(receivePacket.getData()); InetAddress IPAddress = receivePacket.getAddress(); int port = receivePacket.getPort(); String capitalizedSentence = sentence.toUpperCase(); sendData = capitalizedSentence.getBytes(); DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, port); serverSocket.send(sendPacket); } Get IP addr port #, of sender Create datagram to send to client Write out datagram to socket End of while loop, loop back and wait for another datagram 2: Alkalmazási réteg

117 Chapter 2: Summary our study of network apps now complete!
specific protocols: HTTP FTP SMTP, POP, IMAP DNS P2P: BitTorrent, Skype socket programming application architectures client-server P2P hybrid application service requirements: reliability, bandwidth, delay Internet transport service model connection-oriented, reliable: TCP unreliable, datagrams: UDP 2: Alkalmazási réteg

118 Chapter 2: Summary Most importantly: learned about protocols
typical request/reply message exchange: client requests info or service server responds with data, status code message formats: headers: fields giving info about data data: info being communicated Important themes: control vs. data msgs in-band, out-of-band centralized vs. decentralized stateless vs. stateful reliable vs. unreliable msg transfer “complexity at network edge” 2: Alkalmazási réteg


Letölteni ppt "2. Fejezet Alkalmazási réteg"

Hasonló előadás


Google Hirdetések