chapter 2: Application Layer › ~jsteach › cosc4377 › 2001fall › notes › Chapter2a.pdf2:...
Transcript of chapter 2: Application Layer › ~jsteach › cosc4377 › 2001fall › notes › Chapter2a.pdf2:...
COSC 4377, Spring 2001 - Chapter 2, Part A 9/18/01
1
2: Application Layer 1
chapter 2: Application LayerChapter goals:r conceptual +
implementation aspectsof network applicationprotocolsm client server
paradigmm service models
r learn about protocols byexamining popularapplication-levelprotocols
More chapter goalsr specific protocols:
m httpm ftpm smtpm popm dns
r programming networkapplicationsm socket programming
2: Application Layer 2
Applications and application-layer protocolsApplication: communicating,
distributed processesm running in network hosts
and in “user space”m exchange messages to
implement appm e.g., email, file transfer,
the WebApplication-layer protocols
m one (big) “piece” of anetwork application
m define messages exchangedby apps and actions taken
m use services provided bylower layer protocols , e.g.,TCP, UDP
applicationtransportnetworkdata linkphysical
applicationtransportnetworkdata linkphysical
applicationtransportnetworkdata linkphysical
COSC 4377, Spring 2001 - Chapter 2, Part A 9/18/01
2
2: Application Layer 3
Network applications: some jargon
r A process is a programthat is running within ahost.
r Within the same host, twoprocesses communicatewith interprocesscommunication defined bythe OS.
r Processes running indifferent hostscommunicate with anapplication-layer protocol
r A user agent is aninterface between theuser and the networkapplication.m Web:browserm E-mail: mail readerm streaming audio/video:
media player
2: Application Layer 4
Client-server paradigmTypical network app has two
pieces: client and server applicationtransportnetworkdata linkphysical
applicationtransportnetworkdata linkphysical
Client:r initiates contact with server
(“speaks first”)r typically requests service
from server,r for Web, client is implemented
in browser; for e-mail, in mailreader
Server:r active in listening moder responds and provides
requested service to clientr e.g., Web server sends
requested Web page
request
reply
COSC 4377, Spring 2001 - Chapter 2, Part A 9/18/01
3
2: Application Layer 5
Application-layer protocols (cont).
API: applicationprogramming interface
r defines interfacebetween applicationand transport layer
r socket: Internet APIm two processes
communicate by sendingdata into socket,reading data out ofsocket
Q: how does a process“identify” the otherprocess with which itwants to communicate?m IP address of host
running other processm “port number” - allows
receiving host todetermine to whichlocal process themessage should bedelivered
… lots more on this later.
2: Application Layer 6
What transport service does an app need?Data lossr some apps (e.g., audio) can
tolerate some lossr other apps (e.g., file
transfer, telnet) require100% reliable data transfer Timing
r some apps (e.g., Internettelephony, interactivegames) require low delay tobe “effective”
Bandwidthr some apps (e.g., multimedia)
require minimum amount ofbandwidth to be “effective”
r other apps (“elastic apps”)make use of whateverbandwidth they get
COSC 4377, Spring 2001 - Chapter 2, Part A 9/18/01
4
2: Application Layer 7
Transport service requirements of common apps
Application
file transfere-mail
Web documentsreal-time audio/video
stored audio/videointeractive games
financial apps
Data loss
no lossno lossloss-tolerantloss-tolerant
loss-tolerantloss-tolerantno loss
Bandwidth
elasticelasticelasticaudio: 5Kb-1Mbvideo:10Kb-5Mbsame as abovefew Kbps upelastic
Time Sensitive
nononoyes, 100’s msec
yes, few secsyes, 100’s msecyes and no
2: Application Layer 8
Services provided by Internettransport protocols
TCP service:r connection-oriented: setup
required between client,server
r reliable transport betweensending and receiving process
r flow control: sender won’toverwhelm receiver
r congestion control: throttlesender when networkoverloaded
r does not provide: timing,minimum bandwidthguarantees
UDP service:r unreliable data transfer
between sending andreceiving process
r does not provide:connection setup,reliability, flow control,congestion control, timing,or bandwidth guarantee
Q: why bother? Why isthere a UDP?
COSC 4377, Spring 2001 - Chapter 2, Part A 9/18/01
5
2: Application Layer 9
Internet apps: their protocols and transportprotocols
Application
e-mailremote terminal access
Web file transfer
streaming multimedia
remote file serverInternet telephony
Applicationlayer protocol
smtp [RFC 821]telnet [RFC 854]http [RFC 2068]ftp [RFC 959]proprietary(e.g. RealNetworks)NFSproprietary(e.g., Vocaltec)
Underlyingtransport protocol
TCPTCPTCPTCPTCP or UDP
TCP or UDPtypically UDP
2: Application Layer 10
The Web: some jargonr Web page:
m consists of “objects”m addressed by a URL
r Most Web pages consistof:m base HTML file, andm several referenced
objects.r URL (Uniform Resource
Locator) has three parts:protocol, host name(w/port), and path name:
r User agent for Web iscalled a browser:m MS Internet Explorerm Netscape Communicator
r Server for Web iscalled Web server:m Apache (public domain)m MS Internet
Information Server
http://www.someSchool.edu:port/someDept/pic.gif
COSC 4377, Spring 2001 - Chapter 2, Part A 9/18/01
6
2: Application Layer 11
The Web: the http protocolhttp: hypertext transfer
protocolr Web’s application layer
protocolr client/server model
m client: browser thatrequests, receives,“displays” Web objects
m server: Web serversends objects inresponse to requests
r http1.0: RFC 1945, May 1996r http1.1: RFC 2068, Jan. 1997
PC runningExplorer
Server running
NCSA Webserver
Mac runningNavigator
http request
http reque
st
http response
http respo
nse
2: Application Layer 12
The http protocol: morehttp: TCP transport
service:r client initiates TCP
connection (creates socket)to server, port 80
r server accepts TCPconnection from client
r http messages (application-layer protocol messages)exchanged between browser(http client) and Web server(http server)
r TCP connection closed
http is “stateless”r server maintains no
information aboutpast client requests
Protocols that maintain“state” are complex!
r past history (state) mustbe maintained
r if server/client crashes,their views of “state” maybe inconsistent, must bereconciled
aside
COSC 4377, Spring 2001 - Chapter 2, Part A 9/18/01
7
2: Application Layer 13
http exampleSuppose user enters URL
http://www.someSchool.edu/someDepartment/home.index
1a. http client initiates TCPconnection to http server(process) atwww.someSchool.edu. Port 80is default for http server.
2. http client sends http requestmessage (containing URL) intoTCP connection socket
1b. http server at hostwww.someSchool.edu waitingfor TCP connection at port 80.“accepts” connection, notifyingclient
3. http server receives requestmessage, forms responsemessage containing requestedobject(someDepartment/home.index),sends message into sockettime
(contains text,references to
10 jpeg images)
2: Application Layer 14
http example (cont.)
5. http client receives responsemessage containing html file,displays html. Parsing htmlfile, finds 10 referenced jpegobjects
6. Steps 1-5 repeated for eachof 10 jpeg objects
4. http server closes TCPconnection.
time
COSC 4377, Spring 2001 - Chapter 2, Part A 9/18/01
8
2: Application Layer 15
Non-persistent and persistent connectionsNon-persistentr HTTP/1.0r server parses request,
responds, and closesTCP connection
r 2 RTTs (round-trip time)to fetch each object
r Each object transfersuffers from slowstart
Persistentr default for HTTP/1.1r on same TCP
connection: server,parses request,responds, parses newrequest,..
r Client sends requestsfor all referencedobjects as soon as itreceives base HTML.(pipelined)
r Fewer RTTs and lessslow start.
But most 1.0 browsers useparallel TCP connections.
2: Application Layer 16
http message format: requestr two types of http messages: request, responser http request message:
m ASCII (human-readable format)
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
Carriage return, line feed
indicates end of message
COSC 4377, Spring 2001 - Chapter 2, Part A 9/18/01
9
2: Application Layer 17
http request message: general format
2: Application Layer 18
http message format: 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 ...
status line(protocol
status codestatus phrase)
header lines
data, e.g., requestedhtml file
COSC 4377, Spring 2001 - Chapter 2, Part A 9/18/01
10
2: Application Layer 19
http response status codes
200 OKm request succeeded, requested object later in this message
301 Moved Permanentlym requested object moved, new location specified later in
this message (Location:)400 Bad Request
m request message not understood by server404 Not Found
m requested document not found on this server505 HTTP Version Not Supported
In first line in server->client response message.A few sample codes:
2: Application Layer 20
Trying out http (client side) for yourself
1. Telnet to your favorite Web server:Opens TCP connection to port 80(default http server port) at www.eurecom.fr.Anything typed in sent to port 80 at www.eurecom.fr
telnet www.eurecom.fr 80
2. Type in a GET http request:GET /~ross/index.html HTTP/1.0 By typing this in (hit carriage
return twice), you sendthis minimal (but complete) GET request to http server
3. Look at response message sent by http server!
COSC 4377, Spring 2001 - Chapter 2, Part A 9/18/01
11
2: Application Layer 21
User-server interaction: authentication
Authentication goal: controlaccess to server documents
r stateless: client must presentauthorization in each request
r authorization: typically name,passwordm authorization: header
line in requestm if no authorization
presented, server refusesaccess, sendsWWW authenticate:
header line in response
client serverusual http request msg401: authorization req.WWW authenticate:
usual http request msg+ Authorization:line
usual http response msg
usual http request msg+ Authorization:line
usual http response msg timeBrowser caches name & password sothat user does not have to repeatedly enter it.
2: Application Layer 22
User-server interaction: cookies
r server sends “cookie” toclient in response mstSet-cookie: 1678453
r client presents cookie inlater requestscookie: 1678453
r server matchespresented-cookie withserver-stored infom authenticationm remembering user
preferences, previouschoices
client serverusual http request msgusual http response +Set-cookie: #
usual http request msgcookie: #
usual http response msg
usual http request msgcookie: #
usual http response msg
cookie-specificaction
cookie-specificaction
COSC 4377, Spring 2001 - Chapter 2, Part A 9/18/01
12
2: Application Layer 23
User-server interaction: conditional GET
r Goal: don’t send object ifclient has up-to-date stored(cached) version
r client: specify date ofcached copy in http requestIf-modified-since:
<date>
r server: response containsno object if cached copy up-to-date:HTTP/1.0 304 Not
Modified
client serverhttp request msg
If-modified-since:<date>
http responseHTTP/1.0
304 Not Modified
object not
modified
http request msgIf-modified-since:
<date>
http responseHTTP/1.1 200 OK
…<data>
object modified
2: Application Layer 24
Web Caches (proxy server)
r user sets browser:Web accesses via webcache
r client sends all httprequests to web cachem if object at web
cache, web cacheimmediately returnsobject in httpresponse
m else requests objectfrom origin server,then returns httpresponse to client
Goal: satisfy client request without involving origin server
client
Proxyserver
client
http request
http reque
st
http response
http respo
nse
http reque
st
http respo
nse
http requesthttp response
origin server
origin server
COSC 4377, Spring 2001 - Chapter 2, Part A 9/18/01
13
2: Application Layer 25
Why Web Caching?Assume: cache is “close”
to client (e.g., in samenetwork)
r smaller response time:cache “closer” toclient
r decrease traffic todistant serversm link out of
institutional/local ISPnetwork oftenbottleneck
originservers
public Internet
institutionalnetwork 10 Mbps LAN
1.5 Mbps access link
institutionalcache
2: Application Layer 26
ftp: the file transfer protocol
r transfer file to/from remote hostr client/server model
m client: side that initiates transfer (either to/fromremote)
m server: remote hostr ftp: RFC 959r ftp server: port 21
file transfer FTPserver
FTPuser
interfaceFTP
client
local filesystem
remote filesystem
userat host
COSC 4377, Spring 2001 - Chapter 2, Part A 9/18/01
14
2: Application Layer 27
ftp: separate control, data connections
r ftp client contacts ftp serverat port 21, specifying TCP astransport protocol
r two parallel TCP connectionsopened:m control: exchange
commands, responsesbetween client, server.
“out of band control”m data: file data to/from
serverr ftp server maintains “state”:
current directory, earlierauthentication
FTPclient
FTPserver
TCP control connectionport 21
TCP data connectionport 20
2: Application Layer 28
ftp commands, responsesSample commands:r sent as ASCII text over
control channelr USER usernamer PASS password
r LIST return list of file incurrent directory
r RETR filename retrieves(gets) file
r STOR filename stores(puts) file onto remotehost
Sample return codesr status code and phrase (as
in http)r 331 Username OK,
password requiredr 125 data connection
already open;transfer starting
r 425 Can’t open dataconnection
r 452 Error writingfile
COSC 4377, Spring 2001 - Chapter 2, Part A 9/18/01
15
2: Application Layer 29
Electronic MailMajor Components:r mail user agents (MUA) and
mailer process (e.g. sendmail)r mail serversr simple mail transfer protocol:
SMTP / ESMTPr mail access protocols (e.g.
POP, IMAP)User Agentr a.k.a. “mail reader”r composing, editing, reading
mail messagesr e.g., Eudora, Outlook, elm,
pine, Netscape Messenger
sendingMUA
types calls sendingmail
server
receivingmail
server
Internet
on the sending network
on the receiving network
Bob’smailbox
Alice
delivers to
Bob’sMUA
Bob’snotifier Bob
2: Application Layer 30
Electronic Mail: mail serversMail Serversr mailbox contains incoming
messages (yet to be read)for user
r message queue of outgoing(to be sent) mail messages
r smtp protocol used betweenmail servers to send emailmessages (routing messages)m client: sending mail serverm “server”: receiving mail
server
user mailbox
outgoing message queue
mailserver
useragent
useragent
useragentmail
server
useragent
useragent
mailserver
useragent
SMTP
SMTP
SMTP
COSC 4377, Spring 2001 - Chapter 2, Part A 9/18/01
16
2: Application Layer 31
Electronic Mail: smtp [RFC 821]r uses tcp to reliably transfer email msg from client to server,
port 25r direct transfer: sending server to receiving serverr three phases of transfer
m handshaking (greeting)m transfer of messagesm closure
r command/response interactionm commands: ASCII textm response: status code and phrase
r messages must be in 7-bit ASCIIr ESMTP [RFC 1869] - SMTP Service Extension: 8-bit data
transfer
2: Application Layer 32
Sample smtp interaction S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <[email protected]> S: 250 [email protected]... Sender ok C: RCPT TO: <[email protected]> S: 250 [email protected] ... 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
COSC 4377, Spring 2001 - Chapter 2, Part A 9/18/01
17
2: Application Layer 33
try smtp interaction for yourself:
r telnet servername 25r see 220 reply from serverr enter HELO, MAIL FROM, RCPT TO, DATA, QUIT
commandsabove lets you send email without using email client
(reader)
2: Application Layer 34
smtp: final wordsr smtp uses persistent
connectionsr smtp requires that message
(header & body) be in 7-bitascii
r certain character strings arenot permitted in message (e.g.,CRLF.CRLF). Thus message hasto be encoded (usually intoeither base-64 or quotedprintable)
r smtp server uses CRLF.CRLFto determine end of message
r esmtp can take 8-bit data
Comparison with httpr http: pullr email: pushr both have ASCII
command/responseinteraction, status codes
r http: each object isencapsulated in its ownresponse message
r smtp: multiple objectsmessage sent in a multipartmessage
COSC 4377, Spring 2001 - Chapter 2, Part A 9/18/01
18
2: Application Layer 35
Mail message formatsmtp: protocol for exchanging
email msgsRFC 822: standard for text
message format:r header lines
(keyword: values), e.g.,m To:m From:m Subject:different from smtp
commands!r body
m the “message”, ASCIIcharacters only
header
body
blankline
2: Application Layer 36
Message format: multimedia extensionsr MIME: Multipurpose Internet Mail Extension, RFCs 2045-2049,
especially RFC 2045 and 2046r additional lines in msg header declare MIME content type
From: [email protected]: [email protected]: Picture of yummy crepe.MIME-Version: 1.0Content-Transfer-Encoding: base64Content-Type: image/jpeg
base64 encoded data ....................................base64 encoded data
multimedia datatype, subtype,
parameter declaration
method usedto encode data
MIME version
encoded data
COSC 4377, Spring 2001 - Chapter 2, Part A 9/18/01
19
2: Application Layer 37
MIME typesContent-Type: type/subtype; parameters
Textr example subtypes: plain,
html
Imager example subtypes: jpeg,
gif
Audior example subtypes: basic
(8-bit mu-law encoded),32kadpcm (32 kbpscoding)
Videor example subtypes: mpeg,
quicktime
Applicationr other data that must be
processed by readerbefore “viewable”
r example subtypes:msword, octet-stream
2: Application Layer 38
Multipart TypeFrom: [email protected]: [email protected]: Picture of yummy crepe.MIME-Version: 1.0Content-Type: multipart/mixed; boundary=98766789
--98766789Content-Transfer-Encoding: quoted-printableContent-Type: text/plain
Dear Bob,Please find a picture of a crepe.--98766789Content-Transfer-Encoding: base64Content-Type: image/jpeg
base64 encoded data ....................................base64 encoded data--98766789--
COSC 4377, Spring 2001 - Chapter 2, Part A 9/18/01
20
2: Application Layer 39
Mail access protocols
r SMTP: delivery/storage to receiver’s serverr Mail access protocol: retrieval from server
m POP: Post Office Protocol [RFC 1939]• authorization (agent <-->server)• download mail
m IMAP: Internet Mail Access Protocol [RFC 1730]m HTTP or Webmail
useragent
sender’s mail server
useragent
SMTP SMTP POP3 orIMAP
receiver’s mail server
2: Application Layer 40
POP3 protocolauthorization phaser client commands:
m user: declare usernamem pass: password
r server responsesm +OKm -ERR
transaction phase, client:r list: list message numbersr retr: retrieve message by
numberr dele: deleter 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
COSC 4377, Spring 2001 - Chapter 2, Part A 9/18/01
21
2: Application Layer 41
Mail access protocolsr Problems with POP
m viewed mail resides on a specific user machine and cannotbe accessed from other machines.
r IMAP• maintains folder hierarchy on the server• can receive/download only components of a message,
e.g., header or certain attachmentsr HTTP
m Hotmail , Yahoo! Mail, Novell MyRealBox.com, etc.m Similar in concept to IMAP but with a web interface