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

chapt er 2 applicat ion layer
SMART_READER_LITE
LIVE PREVIEW

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:


slide-1
SLIDE 1

1

2: Applicat ion Layer 1

Chapt er 2: Applicat ion Layer

Chapt er goals:

❒ concept ual +

implement at ion aspect s

  • f net work applicat ion

prot ocols

❍ client server

paradigm

❍ service models

❒ learn about prot ocols by

examining popular applicat ion-level prot ocols

More chapt er goals

❒ specif ic pr ot ocols:

❍ ht t p ❍ f t p ❍ smt p ❍ pop ❍ dns

❒ pr ogr amming net wor k

applicat ions

❍ socket programming 2: Applicat ion Layer 2

Applicat ions and applicat ion-layer prot ocols

Applicat ion: communicat ing, dist ribut ed processes

❍ running in net work host s in

“user space”

❍ exchange messages t o

implement app

❍ e.g., email, f ile t r ansf er,

t he Web Applicat ion-layer prot ocols

❍ one “piece” of an app ❍ def ine messages

exchanged by apps and act ions t aken

❍ user services provided by

lower layer prot ocols

applicat ion t r anspor t net work dat a link physical applicat ion t r anspor t net work dat a link physical applicat ion t r anspor t net work dat a link physical

2: Applicat ion Layer 3

Net work applicat ions: some j argon

❒ A process is a progr am

t hat is running wit hin a host .

❒ Wit hin t he same host , t wo

processes communicat e wit h int er process communicat ion def ined by t he OS.

❒ Processes running in

dif f erent host s communicat e wit h an applicat ion-layer prot ocol ❒ A user agent is an

int er f ace bet ween t he user and t he net wor k applicat ion.

❍ Web:browser ❍ E-mail: mail reader ❍ st reaming audio/ video:

media player

2: Applicat ion Layer 4

Client -server paradigm

Typical net work app has t wo pieces: client and ser ver

applicat ion t r anspor t net work dat a link physical applicat ion t r anspor t net work dat a link physical

Client :

❒ init iat es cont act wit h server

(“speaks f irst ”)

❒ t ypically request s service f rom

server,

❒ f or Web, client is implement ed

in browser ; f or e-mail, in mail reader Server:

❒ provides r equest ed service t o

client

❒ e.g., Web server sends

request ed Web page, mail server delivers e-mail request reply

2: Applicat ion Layer 5

Applicat ion-layer prot ocols (cont ).

API : applicat ion pr ogr amming int er f ace

❒ def ines int er f ace

bet ween applicat ion and t ranspor t layer

❒ socket : I nt ernet AP

I

❍ t wo processes

communicat e by sending dat a int o socket , reading dat a out of socket

Q: how does a pr ocess “ident if y” t he ot her pr ocess wit h which it want s t o communicat e?

❍ I P addr ess of host

running ot her process

❍ “port number” - allows

receiving host t o det ermine t o which local process t he message should be delivered

… lot s mor e on t his lat er .

2: Applicat ion Layer 6

What t ransport service does an app need?

Dat a loss

❒ some apps (e.g., audio) can

t oler at e some loss

❒ ot her apps (e.g., f ile

t ransf er, t elnet ) requir e 100% r eliable dat a t ransf er

Timing

❒ some apps (e.g., I nt ernet

t elephony, int eract ive games) require low delay t o be “ef f ect ive”

Bandwidt h

❒ some apps (e.g., mult imedia)

requir e minimum amount of bandwidt h t o be “ef f ect ive”

❒ ot her apps (“elast ic apps”)

make use of what ever bandwidt h t hey get

slide-2
SLIDE 2

2

2: Applicat ion Layer 7

Transport service requirement s of common apps

Application file transfer e-mail Web documents real-time audio/video stored audio/video interactive games financial apps Data loss no loss no loss loss-tolerant loss-tolerant loss-tolerant loss-tolerant no loss Bandwidth elastic elastic elastic audio: 5Kb-1Mb video:10Kb-5Mb same as above few Kbps up elastic Time Sensitive no no no yes, 100’s msec yes, few secs yes, 100’s msec yes and no

2: Applicat ion Layer 8

Services provided by I nt ernet t ransport prot ocols

TCP ser vice:

❒ connect ion-orient ed: set up

requir ed bet ween client , server

❒ reliable t ransport bet ween

sending and r eceiving process

❒ f low cont rol: sender won’t

  • verwhelm receiver

❒ congest ion cont rol: t hrot t le

sender when net work

  • verloaded

❒ does not providing: t iming,

minimum bandwidt h guarant ees

UDP service:

❒ unreliable dat a t ransf er

bet ween sending and receiving process

❒ does not provide:

connect ion set up, reliabilit y, f low cont rol, congest ion cont rol, t iming,

  • r bandwidt h guarant ee

Q: why bot her? Why is t here a UDP?

2: Applicat ion Layer 9

I nt ernet apps: t heir prot ocols and t ransport prot ocols

Application e-mail remote terminal access Web file transfer streaming multimedia remote file server Internet telephony Application layer protocol smtp [RFC 821] telnet [RFC 854] http [RFC 2068] ftp [RFC 959] proprietary (e.g. RealNetworks) NSF proprietary (e.g., Vocaltec) Underlying transport protocol TCP TCP TCP TCP TCP or UDP TCP or UDP typically UDP

2: Applicat ion Layer 10

The Web: some j ar gon

❒ Web page:

❍ consist s of “obj ect s” ❍ addr essed by a URL

❒ Most Web pages

consist of :

❍ base HTML page, and ❍ sever al ref er enced

  • bj ect s.

❒ URL has t wo

component s: host name and pat h name:

❒ User agent f or Web is

called a browser:

❍ MS I nt ernet Explorer ❍ Net scape Communicat or

❒ Server f or Web is

called Web server:

❍ Apache (public domain) ❍ MS I nt ernet

I nf ormat ion Server www.someSchool.edu/someDept/pic.gif

2: Applicat ion Layer 11

The Web: t he ht t p pr ot ocol

ht t p: hyper t ext t ransf er pr ot ocol

❒ Web’s applicat ion layer

prot ocol

❒ client / server model

❍ client : browser t hat

request s, receives, “displays” Web obj ect s

❍ server : Web ser ver

sends obj ect s in response t o request s

❒ ht t p1.0: RFC 1945 ❒ ht t p1.1: RFC 2068 P C r unning Explor er Ser ver r unning NCSA Web ser ver Mac r unning Navigat or ht t p request ht t p request h t t p r e s p

  • n

s e ht t p r esponse

2: Applicat ion Layer 12

The ht t p prot ocol: more

ht t p: TCP t r anspor t ser vice:

❒ client init iat es TCP

connect ion (creat es socket ) t o server, por t 80

❒ server accept s TCP

connect ion f rom client

❒ ht t p messages (applicat ion-

layer prot ocol messages) exchanged bet ween browser (ht t p client ) and Web server (ht t p server)

❒ TCP connect ion closed

ht t p is “st at eless”

❒ server maint ains no

inf ormat ion about past client request s Prot ocols t hat maint ain “st at e” are complex!

❒ past hist ory (st at e) must

be maint ained

❒ if server/ client crashes,

t heir views of “st at e” may be inconsist ent , must be reconciled

aside

slide-3
SLIDE 3

3

2: Applicat ion Layer 13

ht t p example

Suppose user ent ers URL

www.someSchool.edu/someDepartment/home.index

  • 1a. ht t p client init iat es TCP

connect ion t o ht t p ser ver (pr ocess) at www.someSchool.edu. Por t 80 is def ault f or ht t p ser ver .

  • 2. ht t p client sends ht t p r equest

message (cont aining URL) int o TCP connect ion socket

  • 1b. ht t p ser ver at host

www.someSchool.edu wait ing f or TCP connect ion at por t 80. “accept s” connect ion, not if ying client

  • 3. ht t p ser ver r eceives r equest

message, f or ms r esponse message cont aining r equest ed

  • bj ect

(someDepartment/home.index), sends message int o socket

t ime

(contains text, references to 10 jpeg images)

2: Applicat ion Layer 14

ht t p example (cont .)

  • 5. ht t p client r eceives r esponse

message cont aining ht ml f ile, displays ht ml. Par sing ht ml f ile, f inds 10 r ef er enced j peg

  • bj ect s
  • 6. St eps 1-5 r epeat ed f or each
  • f 10 j peg obj ect s
  • 4. ht t p ser ver closes TCP

connect ion.

t ime

2: Applicat ion Layer 15

Non-persist ent and persist ent connect ions

Non-per sist ent

❒ HTTP/ 1.0 ❒ ser ver par ses r equest ,

r esponds, and closes TCP connect ion

❒ 2 RTTs t o f et ch each

  • bj ect

❒ Each obj ect t ransf er

suf f er s f r om slow st ar t Per sist ent

❒ def ault f or HTTP/ 1.1 ❒ on same TCP

connect ion: server , parses request , r esponds, par ses new r equest ,..

❒ Client sends r equest s

f or all r ef erenced

  • bj ect s as soon as it

r eceives base HTML.

❒ Fewer RTTs and less

slow st art . But most 1.0 browser s use par allel TCP connect ions.

2: Applicat ion Layer 16

ht t p message f or mat : request

❒ t wo t ypes of ht t p messages: r equest , r esponse ❒ ht t p r equest message:

❍ ASCI I (human-readable f ormat )

GET /somedir/page.html HTTP/1.0 User-agent: Mozilla/4.0 Accept: text/html, image/gif,image/jpeg Accept-language:fr (extra carriage return, line feed) request line (GET, POST, HEAD commands) header lines Car riage ret urn, line f eed indicat es end

  • f message

2: Applicat ion Layer 17

ht t p request message: general f ormat

2: Applicat ion Layer 18

ht t p message f or mat : respone

HTTP/1.0 200 OK Date: Thu, 06 Aug 1998 12: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 ... st at us line (prot ocol st at us code st at us phrase) header lines dat a, e.g., request ed ht ml f ile

slide-4
SLIDE 4

4

2: Applicat ion Layer 19

ht t p r esponse st at us codes

200 OK

❍ request succeeded, request ed obj ect lat er in t his message

301 Moved Permanently

❍ request ed obj ect moved, new locat ion specif ied lat er in

t his message (Locat ion:)

400 Bad Request

❍ request message not underst ood by server

404 Not Found

❍ request ed document not f ound on t his ser ver

505 HTTP Version Not Supported I n f ir st line in ser ver -> client r esponse message. A f ew sample codes:

2: Applicat ion Layer 20

Trying out ht t p (client side) f or yourself

  • 1. Telnet t o your f avor it e Web ser ver :

Opens TCP connect ion t o por t 80 (def ault ht t p ser ver por t ) at www.eur ecom.f r. Anyt hing t yped in sent t o por t 80 at www.eur ecom.f r telnet www.eurecom.fr 80

  • 2. Type in a GET ht t p r equest :

GET /~ross/index.html HTTP/1.0

By t yping t his in (hit carr iage r et ur n t wice), you send t his minimal (but complet e) GET r equest t o ht t p ser ver

  • 3. Look at r esponse message sent by ht t p ser ver!

2: Applicat ion Layer 21

User-server int eract ion: aut hent icat ion

Aut hent icat ion goal: cont rol access t o server document s

❒ st at eless: client must present

aut hor izat ion in each request

❒ aut hor izat ion: t ypically name,

password

❍ authorization: header

line in request

❍ if no aut horizat ion

pr esent ed, server r ef uses access, sends

WWW authenticate:

header line in response

client ser ver

usual ht t p r equest msg 401: aut hor izat ion r eq. WWW authenticate: usual ht t p r equest msg + Authorization:line usual ht t p r esponse msg usual ht t p r equest msg + Authorization:line usual ht t p r esponse msg

t ime Browser caches name & password so t hat user does not have t o repeat edly ent er it .

2: Applicat ion Layer 22

User -server int eract ion: cookies

❒ server sends “cookie” t o

client in r esponse mst

Set-cookie: 1678453 ❒ client present s cookie in

lat er request s

cookie: 1678453 ❒ server mat ches

pr esent ed-cookie wit h server-st or ed inf o

❍ aut hent icat ion ❍ remember ing user

pr ef erences, pr evious choices

client ser ver

usual ht t p r equest msg usual ht t p r esponse +

Set-cookie: #

usual ht t p r equest msg

cookie: #

usual ht t p r esponse msg usual ht t p r equest msg

cookie: #

usual ht t p r esponse msg

cookie- spect if ic act ion cookie- spect if ic act ion

2: Applicat ion Layer 23

User -server int eract ion: condit ional GET

❒ Goal: don’t send obj ect if

client has up-t o-dat e st ored (cached) version

❒ client : specif y dat e of

cached copy in ht t p request

If-modified-since: <date> ❒ server : response cont ains

no obj ect if cached copy up- t o-dat e:

HTTP/1.0 304 Not Modified

client ser ver

ht t p r equest msg

If-modified-since: <date>

ht t p r esponse

HTTP/1.0 304 Not Modified

  • bj ect

not modif ied

ht t p r equest msg

If-modified-since: <date>

ht t p r esponse

HTTP/1.1 200 OK …

<data>

  • bj ect

modif ied

2: Applicat ion Layer 24

Web Caches (pr oxy ser ver )

❒ user set s browser :

Web accesses via web cache

❒ client sends all ht t p

request s t o web cache

❍ if obj ect at web

cache, web cache immediat ely r et ur ns

  • bj ect in ht t p

r esponse

❍ else r equest s obj ect

f r om or igin ser ver , t hen r et ur ns ht t p r esponse t o client

Goal: sat isf y client request wit hout involving origin server

client

Proxy server

client h t t p r e q u e s t ht t p request h t t p r e s p

  • n

s e ht t p r esponse ht t p request ht t p r esponse h t t p r e q u e s t h t t p r e s p

  • n

s e

  • r igin

ser ver

  • r igin

ser ver

slide-5
SLIDE 5

5

2: Applicat ion Layer 25

Why Web Caching?

Assume: cache is “close” t o client (e.g., in same net wor k)

❒ smaller r esponse t ime:

cache “closer” t o client

❒ decrease t raf f ic t o

dist ant ser ver s

❍ link out of

inst it ut ional/ local I SP net work of t en bot t leneck

  • rigin

servers

public I nt er net inst it ut ional net wor k 10 Mbps LAN 1.5 Mbps access link

inst it ut ional cache

2: Applicat ion Layer 26

f t p: t he f ile t r ansf er pr ot ocol

❒ t ransf er f ile t o/ f rom remot e host ❒ client / server model

❍ client : side t hat init iat es t r ansf er (eit her t o/ f rom

remot e)

❍ server : remot e host

❒ f t p: RFC 959 ❒ f t p server : port 21 f ile t r ansf er FTP ser ver FTP user int er f ace FTP client local f ile syst em r emot e f ile syst em user at host

2: Applicat ion Layer 27

f t p: separat e cont rol, dat a connect ions

❒ f t p client cont act s f t p server

at port 21, specif ying TCP as t ransport prot ocol

❒ t wo par allel TCP connect ions

  • pened:

❍ cont rol: exchange

commands, responses bet ween client , server. “out of band cont rol”

❍ dat a: f ile dat a t o/ f rom

server

❒ f t p server maint ains “st at e”:

curr ent direct ory, earlier aut hent icat ion FTP client FTP server

TCP cont r ol connect ion por t 21 TCP dat a connect ion por t 20

2: Applicat ion Layer 28

f t p commands, r esponses

Sample commands:

❒ sent as ASCI I t ext over

cont rol channel

❒ USER username ❒ PASS password ❒ LIST ret urn list of f ile in

curr ent direct ory

❒ RETR filename ret rieves

(get s) f ile

❒ STOR filename st ores

(put s) f ile ont o remot e host

Sample ret urn codes

❒ st at us code and phrase (as

in ht t p)

❒ 331 Username OK,

password required

❒ 125 data connection

already open; transfer starting

❒ 425 Can’t open data

connection

❒ 452 Error writing

file

2: Applicat ion Layer 29

Elect r onic Mail

Thr ee maj or component s:

❒ user agent s ❒ mail servers ❒ simple mail t ransf er

prot ocol: smt p User Agent

❒ a.k.a. “mail r eader” ❒ composing, edit ing, reading

mail messages

❒ e.g., Eudor a, Out look, elm,

Net scape Messenger

❒ out going, incoming messages

st ored on server

user mailbox

  • ut going

message queue mail ser ver user agent user agent user agent mail ser ver user agent user agent mail ser ver user agent

SMTP SMTP SMTP

2: Applicat ion Layer 30

Elect r onic Mail: mail ser ver s

Mail Servers

❒ mailbox cont ains incoming

messages (yet t o be r ead) f or user

❒ message queue of out going

(t o be sent ) mail messages

❒ smt p prot ocol bet ween mail

servers t o send email messages

❍ client : sending mail

server

❍ “server ”: receiving mail

server

mail ser ver user agent user agent user agent mail ser ver user agent user agent mail ser ver user agent

SMTP SMTP SMTP

slide-6
SLIDE 6

6

2: Applicat ion Layer 31

Elect r onic Mail: smt p [RFC 821]

❒ uses t cp t o reliably t ransf er email msg f rom client t o

server, port 25

❒ dir ect t r ansf er: sending server t o receiving server ❒ t hr ee phases of t ransf er

❍ handshaking (greet ing) ❍ t ransf er of messages ❍ closure

❒ command/ response int eract ion

❍ commands: ASCI I t ext ❍ response: st at us code and phr ase

❒ messages must be in 7-bit ASCI I

2: Applicat ion Layer 32

Sample smt p int er act ion

S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <alice@crepes.fr> S: 250 alice@crepes.fr... Sender ok C: RCPT TO: <bob@hamburger.edu> S: 250 bob@hamburger.edu ... 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: Applicat ion Layer 33

t ry smt p int eract ion f or yourself :

❒ telnet servername 25 ❒ see 220 reply f r om server ❒ ent er HELO, MAI L FROM, RCPT TO, DATA, QUI T

commands above let s you send email wit hout using email client (r eader)

2: Applicat ion Layer 34

smt p: f inal words

❒ smt p uses persist ent

connect ions

❒ smt p requir es t hat

message (header & body) be in 7-bit ascii

❒ cert ain charact er st rings

are not permit t ed in message (e.g., CRLF.CRLF). Thus message has t o be encoded (usually int o eit her base-64 or quot ed pr int able)

❒ smt p server uses

CRLF.CRLF t o det ermine end of message

Compar ison wit h ht t p

❒ ht t p: pull ❒ email: push ❒ bot h have ASCI I

command/ response int eract ion, st at us codes

❒ ht t p: each obj ect is

encapsulat ed in it s own response message

❒ smt p: mult iple obj ect s

message sent in a mult ipart message

2: Applicat ion Layer 35

Mail message f or mat

smt p: prot ocol f or exchanging email msgs RFC 822: st andard f or t ext message f ormat :

❒ header lines, e.g.,

❍ To: ❍ Fr om: ❍ Subj ect :

dif f er ent f r om smt p commands! ❒ body

❍ t he “message”, ASCI I

char act er s only

header body

blank line

2: Applicat ion Layer 36

Message f ormat : mult imedia ext ensions

❒ MI ME: mult imedia mail ext ension, RFC 2045, 2056 ❒ addit ional lines in msg header declare MI ME cont ent

t ype

From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......................... ......base64 encoded data

mult imedia dat a t ype, subt ype, paramet er declarat ion met hod used t o encode dat a MI ME version encoded dat a

slide-7
SLIDE 7

7

2: Applicat ion Layer 37

MI ME t ypes

Content-Type: type/subtype; parameters Text

❒ example subt ypes: plain,

html

I mage

❒ example subt ypes: jpeg,

gif

Audio

❒ exampe subt ypes: basic

(8-bit mu-law encoded), 32kadpcm (32 kbps

coding)

Video

❒ example subt ypes: mpeg,

quicktime

Applicat ion

❒ ot her dat a t hat must be

processed by reader bef ore “viewable”

❒ example subt ypes:

msword, octet-stream

2: Applicat ion Layer 38

Mult ipart Type

From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=98766789

  • -98766789

Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Dear Bob, Please find a picture of a crepe.

  • -98766789

Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......................... ......base64 encoded data

  • -98766789--

2: Applicat ion Layer 39

Mail access prot ocols

❒ SMTP: delivery/ st or age t o receiver ’s server ❒ Mail access prot ocol: ret rieval f rom server

❍ POP: Post Of f ice Prot ocol [RFC 1939]

  • aut hor izat ion (agent <
  • ->

server) and download

❍ I MAP: I nt ernet Mail Access Prot ocol [RFC 1730]

  • more f eat ur es (more complex)
  • manipulat ion of st ored msgs on ser ver

❍ HTTP: Hot mail , Yahoo! Mail, et c. user agent sender ’s mail ser ver user agent

SMTP SMTP P OP 3 or I MAP

r eceiver ’s mail ser ver

2: Applicat ion Layer 40

POP3 pr ot ocol

aut hor izat ion phase

❒ client commands:

❍ user: declare username ❍ pass: password

❒ server r esponses

❍ +OK ❍ -ERR

t r ansact ion phase, client :

❒ list: list message numbers ❒ retr: ret r ieve message by

number

❒ dele: delet e ❒ quit C: list S: 1 498 S: 2 912 S: . C: retr 1 S: <message 1 contents> S: . C: dele 1 C: retr 2 S: <message 1 contents> S: . C: dele 2 C: quit S: +OK POP3 server signing off S: +OK POP3 server ready C: user alice S: +OK C: pass hungry S: +OK user successfully logged on