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: Alkalmazási réteg1 2. Fejezet Alkalmazási réteg Computer Networking: A Top Down Approach, 4 th edition. Jim Kurose, Keith Ross Addison-Wesley, July.

Hasonló előadás


Az előadások a következő témára: "2: Alkalmazási réteg1 2. Fejezet Alkalmazási réteg Computer Networking: A Top Down Approach, 4 th edition. Jim Kurose, Keith Ross Addison-Wesley, July."— Előadás másolata:

1 2: Alkalmazási réteg1 2. Fejezet Alkalmazási réteg Computer Networking: A Top Down Approach, 4 th edition. Jim Kurose, Keith Ross Addison-Wesley, July 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

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

3 2: Alkalmazási réteg3 2. Fejezet: Alkalmazási réteg Célunk: r 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 r alkalmazási-réteg protokollok ismertetése  HTTP  FTP  SMTP / POP3 / IMAP  DNS r hálózati alkalmazások programozása  socket API

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

5 2: Alkalmazási réteg5 Hálózati alkalmazások írása 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 application transport network data link physical

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

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

8 2: Alkalmazási réteg8 Kliens-szerver architektúra szerver:  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

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

10 2: Alkalmazási réteg10 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

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

12 2: Alkalmazási réteg12 Socketek r a folyamat üzeneteket küld/fogad a socket- nek/től r 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 r 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) folyamat pufferes TCP, változók socket hoszt vagy szerver folyamat Pufferes TCP, változók socket hoszt vagy szerver Internet Az OR irányítja

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

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

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

16 2: Alkalmazási réteg16 Milyen szállítási szolgáltatásokra van szüksége egy alkalmazásnak? Adatvesztés r vannak alkalmazások, amelyek megengednek bizonyos mértékű adatvesztést (pl. audio) r 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 Időzítés r vannak alkalmazások (pl. Internetes telefon, interaktív játékok), melyek nem tűrik a késéseket Sávszélesség r vannak alkalmazások (pl. multimédia), melyeknek szükségük van egy bizonyos sávszélességre r más alkalmazások („rugalmas alkalmazások”) felhasználnak bármilyen sávszélességet

17 2: Alkalmazási réteg17 Alkalmazások szállítási szolgáltatásainak követelményei Alkalmazás á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 rugalmas Időzítés nem igen, 100 ms igen, néhány s igen, 100 ms igen és nem

18 2: Alkalmazási réteg18 Internet szállítási protokollok szolgáltatásai TCP szolgáltatásai: r összeköttetés alapú: a kliens és a szerver közti kapcsolatteremtés szükséges r megbízható szállítás a küldő és fogadó folyamatok között r folyamellenőrzés: a küldő nem terheli túl a fogadót r zsúfoltság ellenőrzés: lassítja a küldőt, ha a hálózat foglalt r nem biztosít: időzítést, garantált minimális sávszélességet UDP szolgáltatásai: r nem megbízható adatszállítás r 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

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

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

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

22 2: Alkalmazási réteg22 HTTP áttekintés HTTP: hypertext szállítási protokoll r Web alkalmazási réteg protokoll r 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 r HTTP 1.0: RFC 1945 r HTTP 1.1: RFC 2068 PC–n Explorer fut Szerveren Apache Web server fut Mac-on Navigator fut HTTP kérés HTTP válasz

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

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

25 2: Alkalmazási réteg25 Nemperszisztens HTTP 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 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 1b. A HTTP szerver a hoszton TCP kapcsolatra vár a 80-as porton, „fogadja” a kapcsolatot, visszajelez a kliensnek 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ő (tartalmaz szöveget, és hivatkozást 10 jpeg képre)

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

27 2: Alkalmazási réteg27 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ő: r egy RTT a TCP kapcsolat inicializálására r egy RTT a HTTP kérés elküldésétől a válasz első byte-jai megárkezéséig r állomány lekérése össz = 2RTT+elküldési idő állomány küldési ideje TCP kapcsolat inicializálása RTT állomány kérése RTT állomány fogadva idő

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

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

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

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

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

33 2: Alkalmazási réteg33 HTTP válaszüzenet 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... állapot sor (protokoll állapot kód állapot mondat) fejléc sorok adat, pl. a kért HTML file

34 2: Alkalmazási réteg34 HTTP válasz állapotkódok 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 A szerver->kliens válaszüzenet első sorában. Néhány példa :

35 2: Alkalmazási réteg35 Próbáljuk ki a HTTP-t (kliens-oldal) 1. Telnet a kedvenc webszerverünkre: 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 telnet cis.poly.edu Írjuk be a GET HTTP kérést: GET /~ross/ HTTP/1.1 Host: cis.poly.edu Ezt beírva (két ENTER utána), minimális (de teljes) GET kérést küldtünk a HTTP szervernek 3. Nézzük meg a HTTP szerver által küldött választ!

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

37 2: Alkalmazási réteg37 Felhasználó-szerver állapot: cookie-k (sütik) 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) Példa : r Susan mindig ugyanazzal a PC-vel internetezik r először nyit meg egy kereskedelmi oldalt r 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

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

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

40 2: Alkalmazási réteg40 Web cache-ek (proxy szerver) r böngésző beállítása: Web hozzáférés cache-en keresztül r 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 Cél: a kliens kérésének kielégítése a célzott szerver beavatkozása nélkül kliens Proxy szerver kliens HTTP kérés HTTP response HTTP kérés HTTP kérést szerver HTTP válasz HTTP vélasz

41 2: Alkalmazási réteg41 Bővebben a Web cache-ről r a cache kliensként és szerverként egyaránt működik r általában a cache-t az ISP telepíti (egyetem, cég) Miért jó a Web cache ? r csökkenti a válaszidőt a kliens kérésére r csökkenti a forgalmat egy intézmény kimenő vonalán. r 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)

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

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

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

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

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

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

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

49 2: Alkalmazási réteg49 FTP parancsok, válaszok példák parancsokra: r 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 r ugyanúgy, mint a HTTP- ben) r 331 Username OK, password required r 125 data connection already open; transfer starting (adatkapcsolat már nyítva, átvitel indul) r 425 Can’t open data connection (Nem nyitható meg az adatkapcsolat) r 452 Error writing file

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

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

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

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

54 2: Alkalmazási réteg54 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 felh. közv. mail szerver mail szerver felh. közv

55 2: Alkalmazási réteg55 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: 250 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

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

57 2: Alkalmazási réteg57 SMTP: következtetés r SMTP perszisztens kapcsolatot használ r 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: r HTTP: pull r SMTP: push r ASCII parancs/válasz kölcsönhatás, státus kódok mindkettőnél r HTTP: mindegyik objektumot külön üzenetben küldi el r SMTP: többszörös objektumokat többrészes üzenetben küldi el

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

59 2: Alkalmazási réteg59 Levél formátum: multimédia kiterjesztések r MIME: multimedia mail extension, RFC 2045, 2056 r 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 multimédia adat típus, altípus, paraméterek kódolási módszer MIME verzió kódolt adat

60 2: Alkalmazási réteg60 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 r pl. altípusok: mpeg, quicktime Alkalmazás r Olyan adatok, amelyeket át kell dolgozni, mielőtt olvasható lesz r pl. altípus: msword, octet-stream

61 2: Alkalmazási réteg61 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. --StartOfNextPart Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data base64 encoded data --StartOfNextPart Do you want the reciple?

62 2: Alkalmazási réteg62 Mail elérési protokollok r SMTP: küldés/tárolás a fogadó szerverére r 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. felh. közv. A küldő mailszervere felh. közv. SMTP elérési protokoll A fogadó mailszervere

63 2: Alkalmazási réteg63 POP3 protokoll engedélyezési fázis r kliens parancsok:  user: felh. név megadása  pass: jelszó r 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 r quit: kilépés C: list S: S: S:. C: retr 1 S: S:. C: dele 1 C: retr 2 S: S:. C: dele 2 C: quit S: +OK POP3 server signing off S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on

64 2: Alkalmazási réteg64 POP3 (folytatás) és IMAP POP3 folytatás r Az előbbi példa „download és delete”- et használ. r Bob nem olvashatja újra az üzenetet, ha klienst cserél r “Download-and-keep”: másolja az üzenetet különböző kliensekre r a POP3 állapotmentes az ülések között IMAP r Minden üzenetet egy helyen, a szerveren tárol r A felhasználó az üzeneteket könyvtárakban tárolhatja r 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.

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

66 2: Alkalmazási réteg66 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: r osztott adatbázis számos névszerver hierarchiájában implementált r 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”

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

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

69 2: Alkalmazási réteg69 DNS: Root névszerverek r a lokális névszerver lép vele kapcsolatba, ha nem ismeri a nevet r 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 13 root név- szerver a világon b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA e NASA Mt View, CA f Internet Software C. Palo Alto, CA (and 36 other locations) i Autonomica, Stockholm (plus 28 other locations) k RIPE London (also 16 other locations) m WIDE Tokyo (also Seoul, Paris, SF) 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)

70 2: Alkalmazási réteg70 TLD és parancsoló szerverek r 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 r 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

71 2: Alkalmazási réteg71 Lokális névszerverek r nem tartozik szigorúan a hierarchiához r minden ISP (lakótelepi ISP, cég, egyetem) rendelkezik eggyel.  alapértelmezett (default) névszervernek is hívják r 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

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

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

74 2: Alkalmazási réteg74 DNS: cache és bejegyzések frissítése r 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 r frissítés/értesítés mechanizmusát még tervezik az IETF-nél  RFC 2136 

75 2: Alkalmazási réteg75 DNS rekordok DNS: az osztott adatbázis erőforrás rekordokat tárol (RR - Resource Record) r Típus=NS  név a doménium (pl. foo.com)  érték ezen doménium parancsoló névszerverének a neve RR formátum: (név, érték, típus,ttl) r Típus=A  név a hosztnév  érték az IP cím r 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 r Típus=MX  érték a névhez tartozó mailszerver neve

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

77 2: Alkalmazási réteg77 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

78 2: Alkalmazási réteg78 Bejegyzés beszúrása a DNS-be r pálda: új hálózat „Network Utopia” r 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) r parancsoló névszerver bejegyzések létrehozása: A típusú bejegyzés MX típusú bejegyzés networkutopia.com-nak r Hogy kapható meg a honlapunk IP címe?

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

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

81 2: Alkalmazási réteg81 Centralizált katalógus 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 centralizált katalógus szerver társak Alice Bob

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

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

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

85 2: Alkalmazási réteg85 Gnutella: társ (peer) csatlakozása 1. Alice, a csatlakozó társ kell találjon egy másik társat a Gnutella hálózatban: jelöltlisták használata 2. 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 3. 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….) r a társak, akik megkapják a Ping üzenetet egy Pong üzenettel válaszolnak Alicenak 4. Alice számos Pong üzenetet kap, ezek alapján újabb TCP kapcsolatokat létesíthet

86 2: Alkalmazási réteg86 Hierarchikus lefedés r a központosított katalógus és az elárasztás kombinációja r 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. r a csoportvezető számontartja a csoportjabeli társak katalógusait

87 2: Alkalmazási réteg87 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? usus u2u2 d1d1 d2d2 u1u1 uNuN dNdN Szerver Hálózat (nagy sávszélesség) File, mérete F u s : szerver upload sávszélesség u i : i. kliens/társ upload sávszélessége d i : i. kliens/társ download sávszélessége

88 2: Alkalmazási réteg88 Kliens-szerver: állomány szétküldési idő usus u2u2 d1d1 d2d2 u1u1 uNuN dNdN Szerver Hálózat (nagy sávszélesség) F r a szerver sorban elküld N másolatot:  NF/u s r i. kliensnek F/d i időbe telik a letöltés lineárisan nő N szerint (nagy N-re) = d cs = max { NF/u s, F/min(d i ) } i F szétküldési ideje N kliensnek – kliens/szerver

89 2: Alkalmazási réteg89 P2P: állomány szétküldési idő usus u2u2 d1d1 d2d2 u1u1 uNuN dNdN Szerver Hálózat (nagy sávszélesség) F r a szerver el kell küldjön egy másolatot: F/u s time r i. kliensnek F/d i időbe telik a letöltés r NF bitet kell letölteni (összesen)  lehető legnagyobb feltöltési sebesség (feltételezve, hogy minden csomópont ugyanannak a társnak küld darabokat): u s +  u i i=1,N d P2P = max { F/u s, F/min(d i ), NF/(u s +  u i) } i i=1,N

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

91 2: Alkalmazási réteg91 P2P esettanulmány: BitTorrent 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 r P2P állomány szétosztás (darab = chunk)

92 2: Alkalmazási réteg92 BitTorrent (1) r az állományt 256KB-os darabokra (chunks) osztja. r 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”) r mialatt letölt, a társ darabokat tölt fel más társaknak. r társak beléphetnek és kiléphetnek r mikor egy társ megkapta az egész állományt (önzően) kiléphet, or (altruistically) remain

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

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

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

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

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

98 2: Alkalmazási réteg98 Socket programming Socket API r introduced in BSD4.1 UNIX, 1981 r explicitly created, used, released by apps r client/server paradigm r 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 Goal: learn how to build client/server application that communicate using sockets

99 2: Alkalmazási réteg99 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 process TCP with buffers, variables socket controlled by application developer controlled by operating system host or server process TCP with buffers, variables socket controlled by application developer controlled by operating system host or server internet

100 2: Alkalmazási réteg100 Socket programming with TCP Client must contact server r server process must first be running r server must have created socket (door) that welcomes client’s contact Client contacts server by: r creating client-local TCP socket r specifying IP address, port number of server process r When client creates socket: client TCP establishes connection to server TCP r 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

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

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

103 2: Alkalmazási réteg103 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)

104 2: Alkalmazási réteg104 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

105 2: Alkalmazási réteg105 Example: Java client (TCP), cont. 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(); } Create input stream attached to socket Send line to server Read line from server

106 2: Alkalmazási réteg106 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

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

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

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

110 2: Alkalmazási réteg110 Socket programming with UDP UDP: no “connection” between client and server r no handshaking r sender explicitly attaches IP address and port of destination to each packet r 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

111 2: Alkalmazási réteg111 Client/server socket interaction: UDP close clientSocket Server (running on hostid ) read reply from clientSocket 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 write reply to serverSocket specifying client host address, port number

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

113 2: Alkalmazási réteg113 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

114 2: Alkalmazási réteg114 Example: Java client (UDP), cont. 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(); } Create datagram with data-to-send, length, IP addr, port Send datagram to server Read datagram from server

115 2: Alkalmazási réteg115 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

116 2: Alkalmazási réteg116 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 Write out datagram to socket End of while loop, loop back and wait for another datagram Create datagram to send to client

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

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


Letölteni ppt "2: Alkalmazási réteg1 2. Fejezet Alkalmazási réteg Computer Networking: A Top Down Approach, 4 th edition. Jim Kurose, Keith Ross Addison-Wesley, July."

Hasonló előadás


Google Hirdetések