Chapt er 2: Applicat ion Layer Applicat ions and applicat ion-layer - PDF document

Chapt er 2: Applicat ion Layer Applicat ions and applicat ion-layer prot ocols Chapt er goals: More chapt er goals Applicat ion: communicat ing, applicat ion t r anspor t dist ribut ed processes ❒ concept ual + ❒ specif ic pr ot ocols: net work dat a link implement at ion aspect s ❍ running in net work host s in physical ❍ ht t p “user space” of net work applicat ion ❍ f t p prot ocols ❍ exchange messages t o ❍ smt p implement app ❍ client server ❍ pop paradigm ❍ e.g., email, f ile t r ansf er, ❍ dns t he Web ❍ service models ❒ pr ogr amming net wor k Applicat ion-layer prot ocols ❒ learn about prot ocols by applicat ion examining popular applicat ions ❍ one “piece” of an app applicat ion t r anspor t t r anspor t net work applicat ion-level net work ❍ def ine messages dat a link ❍ socket programming dat a link physical prot ocols physical exchanged by apps and act ions t aken ❍ user services provided by lower layer prot ocols 2: Applicat ion Layer 1 2: Applicat ion Layer 2 Net work applicat ions: some j argon Client -server paradigm Typical net work app has t wo applicat ion ❒ A process is a progr am ❒ A user agent is an pieces: client and ser ver t r anspor t net work t hat is running wit hin a dat a link int er f ace bet ween t he Client : physical host . user and t he net wor k request ❒ init iat es cont act wit h server ❒ Wit hin t he same host , t wo applicat ion. (“speaks f irst ”) processes communicat e ❍ Web:browser ❒ t ypically request s service f rom wit h int er process server, communicat ion def ined by ❍ E-mail: mail reader t he OS. ❒ f or Web, client is implement ed reply ❍ st reaming audio/ video: in browser ; f or e-mail, in mail ❒ Processes running in media player applicat ion reader dif f erent host s t r anspor t net work communicat e wit h an Server: dat a link physical applicat ion-layer prot ocol ❒ provides r equest ed service t o client ❒ e.g., Web server sends request ed Web page, mail 2: Applicat ion Layer 3 2: Applicat ion Layer 4 server delivers e-mail Applicat ion-layer prot ocols (cont ). What t ransport service does an app need? Dat a loss API : applicat ion Q: how does a pr ocess ❒ some apps (e.g., audio) can pr ogr amming int er f ace “ident if y” t he ot her t oler at e some loss pr ocess wit h which it ❒ def ines int er f ace ❒ ot her apps (e.g., f ile want s t o communicat e? bet ween applicat ion t ransf er, t elnet ) requir e Timing and t ranspor t layer ❍ I P addr ess of host 100% r eliable dat a t ransf er ❒ some apps (e.g., I nt ernet running ot her process ❒ socket : I nt ernet AP I t elephony, int eract ive Bandwidt h ❍ “port number” - allows games) require low delay t o ❍ t wo processes receiving host t o ❒ some apps (e.g., mult imedia) be “ef f ect ive” communicat e by sending det ermine t o which requir e minimum amount of dat a int o socket , local process t he bandwidt h t o be “ef f ect ive” reading dat a out of message should be ❒ ot her apps (“elast ic apps”) socket delivered make use of what ever bandwidt h t hey get … lot s mor e on t his lat er . 2: Applicat ion Layer 5 2: Applicat ion Layer 6 1

Services provided by I nt ernet Transport service requirement s of common apps t ransport prot ocols UDP service: TCP ser vice: Application Data loss Bandwidth Time Sensitive ❒ connect ion-orient ed: set up ❒ unreliable dat a t ransf er bet ween sending and requir ed bet ween client , file transfer no loss elastic no receiving process server e-mail no loss elastic no no ❒ does not provide: Web documents loss-tolerant elastic ❒ reliable t ransport bet ween connect ion set up, real-time audio/video loss-tolerant audio: 5Kb-1Mb yes, 100’s msec sending and r eceiving process reliabilit y, f low cont rol, video:10Kb-5Mb ❒ f low cont rol: sender won’t yes, few secs congest ion cont rol, t iming, stored audio/video loss-tolerant same as above overwhelm receiver interactive games loss-tolerant few Kbps up yes, 100’s msec or bandwidt h guarant ee ❒ congest ion cont rol: t hrot t le yes and no financial apps no loss elastic sender when net work Q: why bot her? Why is overloaded t here a UDP? ❒ does not providing: t iming, minimum bandwidt h guarant ees 2: Applicat ion Layer 7 2: Applicat ion Layer 8 I nt ernet apps: t heir prot ocols and t ransport The Web: some j ar gon prot ocols ❒ User agent f or Web is Application Underlying ❒ Web page: Application layer protocol transport protocol called a browser: ❍ consist s of “obj ect s” ❍ MS I nt ernet Explorer e-mail smtp [RFC 821] TCP ❍ addr essed by a URL ❍ Net scape Communicat or remote terminal access telnet [RFC 854] TCP ❒ Most Web pages ❒ Server f or Web is Web http [RFC 2068] TCP consist of : file transfer ftp [RFC 959] TCP called Web server: ❍ base HTML page, and proprietary streaming multimedia TCP or UDP ❍ Apache (public domain) (e.g. RealNetworks) ❍ sever al ref er enced ❍ MS I nt ernet remote file server NSF TCP or UDP obj ect s. I nf ormat ion Server Internet telephony proprietary typically UDP ❒ URL has t wo (e.g., Vocaltec) component s: host name and pat h name: www.someSchool.edu/someDept/pic.gif 2: Applicat ion Layer 9 2: Applicat ion Layer 10 The ht t p prot ocol: more The Web: t he ht t p pr ot ocol ht t p is “st at eless” ht t p: hyper t ext t ransf er ht t p: TCP t r anspor t pr ot ocol ser vice: ❒ server maint ains no ht t p request inf ormat ion about ❒ Web’s applicat ion layer ❒ client init iat es TCP P C r unning h t t p past client request s prot ocol Explor er r connect ion (creat es socket ) e s p o n s e t o server, por t 80 ❒ client / server model aside ❒ server accept s TCP ❍ client : browser t hat Prot ocols t hat maint ain ht t p request connect ion f rom client “st at e” are complex! request s, receives, ht t p r esponse Ser ver “displays” Web obj ect s ❒ ht t p messages (applicat ion- r unning ❒ past hist ory (st at e) must NCSA Web layer prot ocol messages) ❍ server : Web ser ver be maint ained ser ver exchanged bet ween browser sends obj ect s in ❒ if server/ client crashes, (ht t p client ) and Web server response t o request s t heir views of “st at e” may Mac r unning (ht t p server) ❒ ht t p1.0: RFC 1945 be inconsist ent , must be Navigat or ❒ TCP connect ion closed reconciled ❒ ht t p1.1: RFC 2068 2: Applicat ion Layer 11 2: Applicat ion Layer 12 2

ht t p example ht t p example (cont .) Suppose user ent ers URL 4. ht t p ser ver closes TCP (contains text, connect ion. www.someSchool.edu/someDepartment/home.index references to 10 5 . ht t p client r eceives r esponse jpeg images) message cont aining ht ml f ile, 1a . ht t p client init iat es TCP displays ht ml. Par sing ht ml connect ion t o ht t p ser ver f ile, f inds 10 r ef er enced j peg 1b. ht t p ser ver at host (pr ocess) at obj ect s www.someSchool.edu wait ing www.someSchool.edu. Por t 80 f or TCP connect ion at por t 80. 6. St eps 1-5 r epeat ed f or each is def ault f or ht t p ser ver . “accept s” connect ion, not if ying of 10 j peg obj ect s t ime client 2. ht t p client sends ht t p r equest message (cont aining URL) int o 3. ht t p ser ver r eceives r equest TCP connect ion socket message, f or ms r esponse message cont aining r equest ed obj ect (someDepartment/home.index), sends message int o socket t ime 2: Applicat ion Layer 13 2: Applicat ion Layer 14 Non-persist ent and persist ent connect ions ht t p message f or mat : request Non-per sist ent Per sist ent ❒ HTTP/ 1.0 ❒ def ault f or HTTP/ 1.1 ❒ t wo t ypes of ht t p messages: r equest , r esponse ❒ on same TCP ❒ ser ver par ses r equest , ❒ ht t p r equest message: r esponds, and closes connect ion: server , ❍ ASCI I (human-readable f ormat ) TCP connect ion parses request , r esponds, par ses new ❒ 2 RTTs t o f et ch each request line r equest ,.. obj ect (GET, POST, GET /somedir/page.html HTTP/1.0 HEAD commands) ❒ Client sends r equest s User-agent: Mozilla/4.0 ❒ Each obj ect t ransf er Accept: text/html, image/gif,image/jpeg f or all r ef erenced suf f er s f r om slow header Accept-language:fr obj ect s as soon as it st ar t lines r eceives base HTML. (extra carriage return, line feed) Car riage ret urn, ❒ Fewer RTTs and less But most 1.0 browser s use line f eed slow st art . par allel TCP connect ions. indicat es end of message 2: Applicat ion Layer 15 2: Applicat ion Layer 16 ht t p request message: general f ormat ht t p message f or mat : respone st at us line (prot ocol HTTP/1.0 200 OK st at us code st at us phrase) Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... header Content-Length: 6821 lines Content-Type: text/html data data data data data ... dat a, e.g., request ed ht ml f ile 2: Applicat ion Layer 17 2: Applicat ion Layer 18 3