Chapter 2: Application Layer

Chapter goals: More chapter goals

 conceptual +  specific protocols:
implementation  http
aspects of network
application protocols
 ftp
 client server
 smtp
paradigm  pop
 service models  dns
 learn about protocols  programming
by examining popular network
application-level
applications
protocols
 socket programming

2: Application Layer 1
Applications and application-layer protocols

Application: communicating, applicatio

n
distributed processes transport
network
 running in network hosts data link
physical
in “user space”
 exchange messages to
implement app
 e.g., email, file transfer,
the Web
Application-layer protocols
applicatio
 one “piece” of an app applicatio
n
n
transport
transport network
 define messages network data link
data link physical
exchanged by apps and physical

actions taken
 user services provided
by lower layer protocols
2: Application Layer 2
Network applications: some jargon

 A process is a program  A user agent is an

that is running within a interface between
host.
 Within the same host,
the user and the
two processes
network application.
communicate with  Web:browser
interprocess  E-mail: mail reader
communication defined  streaming
by the OS. audio/video: media
 Processes running in player
different hosts
communicate with an
application-layer protocol

2: Application Layer 3
Client-server paradigm
Typical network app has two applicatio
pieces: client and server n
transport
network

Client: data link

physical

 initiates contact with server request

(“speaks first”)
 typically requests service
from server,
 for Web, client is reply
implemented in browser; for
applicatio
e-mail, in mail reader n
transport
Server: network
data link
physical
 provides requested service
to client
 e.g., Web server sends
requested Web page, mail
2: Application Layer 4
server delivers e-mail
Application-layer protocols (cont).

API: application Q: how does a process

programming “identify” the other
interface process with which it
 defines interface wants to
between application communicate?
and transport layer  IP address of host
running other process
 socket: Internet API
 “port number” -
 two processes allows receiving host
communicate by to determine to which
sending data into local process the
socket, reading data message should be
out of socket delivered
… lots more on this later.
2: Application Layer 5
What transport service does an app
need?
Data loss
 some apps (e.g., audio) can
tolerate some loss
 other apps (e.g., file
transfer, telnet) require
Timing
100% reliable data transfer
 some apps (e.g., Internet
telephony, interactive
Bandwidth games) require low delay
 some apps (e.g., to be “effective”
multimedia) require
minimum amount of
bandwidth to be
“effective”
 other apps (“elastic
apps”) make use of
whatever bandwidth they 2: Application Layer 6
 Transport service requirements of common
apps

Application Data loss Bandwidth Time Sensitive

file transfer no loss elastic no

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

2: Application Layer 7
 Services provided by Internet
transport protocols
TCP service: UDP service:
 connection-oriented: setup  unreliable data transfer
required between client, between sending and
server receiving process
 reliable transport between  does not provide:
sending and receiving connection setup,
process reliability, flow control,
 flow control: sender won’t congestion control,
overwhelm receiver timing, or bandwidth
 congestion control: throttle guarantee
sender when network
overloaded
Q: why bother? Why is
 does not providing: timing, there a UDP?
minimum bandwidth
guarantees
2: Application Layer 8
 Internet apps: their protocols and transport
protocols
Application Underlying
Application layer protocol transport protocol

e-mail smtp [RFC 821] TCP

remote terminal access telnet [RFC 854] TCP
Web http [RFC 2068] TCP
file transfer ftp [RFC 959] TCP
streaming multimedia proprietary TCP or UDP
(e.g. RealNetworks)
remote file server NSF TCP or UDP
Internet telephony proprietary typically UDP
(e.g., Vocaltec)

2: Application Layer 9
 The Web: some jargon
 User agent for Web
 Web page:
 consists of “objects”
is called a browser:
 addressed by a URL
 MS Internet Explorer
 Netscape
 Most Web pages
Communicator
consist of:  Server for Web is
 base HTML page, and
called Web server:
 several referenced
objects.
 Apache (public
 URL has two domain)
 MS Internet
components: host
Information Server
name and path name:

www.someSchool.edu/someDept/pic.gif
2: Application Layer 10
The Web: the http protocol

http: hypertext transfer

protocol htt
pr
eq
 Web’s application layer PC running htt ues
pr t
protocol Explorer esp
ons
 client/server model e

 client: browser that

t
ues
requests, receives, r eq e Server
“displays” Web objects ttp o ns
h p running
r es
p NCSA Web
htt
 server: Web server
server
sends objects in
response to requests
 http1.0: RFC 1945 Mac running
Navigator
 http1.1: RFC 2068

2: Application Layer 11
The http protocol: more
http: TCP transport http is “stateless”
service:  server maintains no
 client initiates TCP information about
connection (creates past client requests
socket) to server, port 80
 server accepts TCP
aside
Protocols that maintain
connection from client “state” are complex!
 http messages  past history (state) must
(application-layer protocol be maintained
messages) exchanged  if server/client crashes,
between browser (http their views of “state”
client) and Web server may be inconsistent,
(http server) must be reconciled
 TCP connection closed

2: Application Layer 12
 http example
Suppose user enters URL www.someSchool.edu/someDepartment/home.index
(contains text,
references to 10
jpeg images)
1a. http client initiates TCP
connection to http server
(process) at
1b. http server at host
www.someSchool.edu waiting
www.someSchool.edu. Port 80
for TCP connection at port
is default for http server.
80. “accepts” connection,
notifying client
2. http client sends http
request message
(containing URL) into TCP 3. http server receives request
connection socket message, forms response
message containing
requested object
(someDepartment/home.index),
sends message into socket
time
2: Application Layer 13
 http example (cont.)
4. http server closes TCP
connection.
5. http client receives response
message containing html
file, displays html. Parsing
html file, finds 10
referenced jpeg objects
6. Steps 1-5 repeated for each
of 10 jpeg objects
time

2: Application Layer 14
 Non-persistent and persistent connections

Non-persistent Persistent
 HTTP/1.0  default for HTTP/1.1

 server parses  on same TCP

connection: server,
request, responds,
parses request,
and closes TCP
responds, parses new
connection request,..
 2 RTTs to fetch each  Client sends requests
object for all referenced
 Each object transfer objects as soon as it
suffers from slow receives base HTML.
start  Fewer RTTs and less
slow start.
But most 1.0 browsers use
parallel TCP connections.
2: Application Layer 15
 http message format: request
 two types of http messages: request, response
 http request message:
 ASCII (human-readable format)

request line
(GET, POST, GET /somedir/page.html HTTP/1.0
HEAD commands) User-agent: Mozilla/4.0
Accept: text/html, image/gif,image/jpeg
header Accept-language:fr
lines

(extra carriage return, line feed)

Carriage return,
line feed
indicates end
of message
2: Application Layer 16
http request message: general
format

2: Application Layer 17
http message format: respone
status line
(protocol
status code HTTP/1.0 200 OK
status phrase) Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
header Last-Modified: Mon, 22 Jun 1998 …...
lines Content-Length: 6821
Content-Type: text/html

data data data data data ...

data, e.g.,
requested
html file

2: Application Layer 18
http response status codes
In first line in server->client response message.
A few sample codes:
200 OK
 request succeeded, requested object later in this
message
301 Moved Permanently
 requested object moved, new location specified later
in this message (Location:)
400 Bad Request
 request message not understood by server
404 Not Found
 requested document not found on this server
505 HTTP Version Not Supported 2: Application Layer 19
 Trying out http (client side) for
yourself
1. Telnet to your favorite Web server:
telnet www.eurecom.fr 80Opens TCP connection to port 80
(default http server port) at www.eurecom.fr.
Anything typed in sent
to port 80 at www.eurecom.fr

2. Type in a GET http request:

GET /~ross/index.html HTTP/1.0 By typing this in (hit carriage
return twice), you send
this minimal (but complete)
GET request to http server

3. Look at response message sent by http server!

2: Application Layer 20
 User-server interaction:
authentication
Authentication goal: control client server
access to server documents usual http request
 stateless: client must present msg
401: authorization
authorization in each request
req.
 authorization: typically name,
WWW authenticate:
password
 authorization: header usual http request
msg
line in request
+ Authorization:line
 if no authorization usual http response
presented, server refuses msg
access, sends
usual http request
WWW authenticate:
msg
header line in response + Authorization:line
usual http response time
msg
Browser caches name & password so
that user does not have to repeatedly enter it. 2: Application Layer 21
 User-server interaction: cookies

 server sends “cookie” to client server

client in response mst usual http request
Set-cookie: 1678453 msg
usual http response
 client presents cookie in +
later requests Set-cookie: #
cookie: 1678453
usual http request
 server matches msg cookie-
presented-cookie with cookie: # spectific
server-stored info usual http response action
msg
 authentication
 remembering user usual http request
msg
cookie-
preferences, spectific
previous choices cookie: #
usual http response action
msg

2: Application Layer 22
 User-server interaction: conditional
GET

 Goal: don’t send object if client server

client has up-to-date
http request msg
stored (cached) version If-modified-since: object
 client: specify date of <date> not
cached copy in http http response modified
request HTTP/1.0
If-modified-since: 304 Not Modified
<date>
 server: response contains
no object if cached copy http request msg
up-to-date: If-modified-since:
<date>
object
HTTP/1.0 304 Not modified
Modified http response
HTTP/1.1 200 OK
…
<data>
2: Application Layer 23
Web Caches (proxy server)
Goal: satisfy client request without involving origin
server
 user sets browser: Web
origin
accesses via web cache server
 client sends all http
requests to web cache htt
Proxy t
pr server ues
 if object at web cache, eq req
clienthttp r
ues p nse
web cache t ht t po
esp es
ons p r
immediately returns
t
e htt
object in http response s
q ue htt
pr
 else requests object p re nse eq
t o htt ues
from origin server, ht es
p pr t
p r esp
then returns http htt ons
e
response to client
client
origin
server

2: Application Layer 24
Why Web Caching?
origin
servers
Assume: cache is
“close” to client public
Internet
(e.g., in same
network)
 smaller response
1.5 Mbps
time: cache “closer” access link

to client institutional
network
 decrease traffic to 10 Mbps LAN

distant servers
 link out of
institutional/local ISP institutional
network often cache
bottleneck
2: Application Layer 25
ftp: the file transfer protocol

FTP file transfer

FTP FTP
user client server
interface
user
at host local file remote file
system system

 transfer file to/from remote host

 client/server model
 client: side that initiates transfer (either to/from
remote)
 server: remote host
 ftp: RFC 959
 ftp server: port 21

2: Application Layer 26
ftp: separate control, data
connections
 ftp client contacts ftp server
at port 21, specifying TCP
as transport protocol
TCP control
 two parallel TCP connection
connections opened: port 21
 control: exchange
TCP data connection
commands, responses FTP port 20 FTP
between client, server. client server
“out of band control”
 data: file data to/from
server
 ftp server maintains
“state”: current directory,
earlier authentication

2: Application Layer 27
ftp commands, responses

Sample commands: Sample return codes

 sent as ASCII text over  status code and phrase
control channel (as in http)
 USER username  331 Username OK,
 PASS password password required
 LIST return list of file in  125 data connection
current directory already open;
transfer starting
 RETR filename retrieves
 425 Can’t open data
(gets) file connection
 STOR filename stores  452 Error writing
(puts) file onto remote file
host

2: Application Layer 28
Electronic Mail outgoing
message queue
user mailbox
user
Three major components: agent
 user agents mail
user
 mail servers server
agent
 simple mail transfer
SMTP mail
protocol: smtp
server user

User Agent SMTP agent

 a.k.a. “mail reader”

SMTP
 composing, editing, reading mail user
agent
mail messages server
 e.g., Eudora, Outlook, elm,
user
Netscape Messenger agent
 outgoing, incoming user
messages stored on server agent

2: Application Layer 29
Electronic Mail: mail servers
user
Mail Servers agent
 mailbox contains
mail
user
incoming messages (yet server
agent
to be read) for user
 message queue of
SMTP mail
server user
outgoing (to be sent) mail
messages SMTP agent

 smtp protocol between

SMTP
mail servers to send email mail user
messages server agent
 client: sending mail
user
server agent
 “server”: receiving user
mail server agent

2: Application Layer 30
Electronic Mail: smtp [RFC 821]
 uses tcp to reliably transfer email msg from client to
server, port 25
 direct transfer: sending server to receiving server
 three phases of transfer
 handshaking (greeting)
 transfer of messages
 closure
 command/response interaction
 commands: ASCII text
 response: status code and phrase

 messages must be in 7-bit ASCII

2: Application Layer 31
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

2: Application Layer 32
try smtp interaction for yourself:

 telnet servername 25
 see 220 reply from server
 enter HELO, MAIL FROM, RCPT TO, DATA, QUIT
commands
above lets you send email without using email
client (reader)

2: Application Layer 33
smtp: final words
 smtp uses persistent
Comparison with http
connections
 smtp requires that
 http: pull

message (header & body)  email: push

be in 7-bit ascii
 both have ASCII
 certain character strings
are not permitted in command/response
message (e.g., interaction, status codes
CRLF.CRLF). Thus message  http: each object is
has to be encoded (usually
encapsulated in its own
into either base-64 or
quoted printable)
response message
 smtp server uses
 smtp: multiple objects

CRLF.CRLF to determine message sent in a

end of message multipart message

2: Application Layer 34
Mail message format

smtp: protocol for

exchanging email msgs header
blank
RFC 822: standard for text
line
message format:
 header lines, e.g.,
 To: body
 From:
 Subject:

different from smtp

commands!
 body
 the “message”, ASCII
characters only

2: Application Layer 35
 Message format: multimedia extensions
 MIME: multimedia mail extension, RFC 2045, 2056
 additional lines in msg header declare MIME content
type

From: [email protected]
MIME version To: [email protected]
Subject: Picture of yummy crepe.
method used MIME-Version: 1.0
to encode data Content-Transfer-Encoding: base64
Content-Type: image/jpeg
multimedia data
type, subtype, base64 encoded data .....
parameter declaration .........................
......base64 encoded data
encoded data

2: Application Layer 36
MIME types
Content-Type: type/subtype; parameters

Text Video
 example subtypes:  example subtypes: mpeg,
plain, html quicktime

Image Application
 example subtypes: jpeg,  other data that must be
gif processed by reader
before “viewable”
Audio  example subtypes:
 exampe subtypes: basic msword, octet-stream
(8-bit mu-law encoded),
32kadpcm (32 kbps
coding)
2: Application Layer 37
Multipart Type
From: [email protected]
To: [email protected]
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: Application Layer 38
Mail access protocols
SMTP SMTP POP3 or user
user
agent IMAP agent

sender’s mail receiver’s mail

server server
 SMTP: delivery/storage to receiver’s server
 Mail access protocol: retrieval from server
 POP: Post Office Protocol [RFC 1939]
• authorization (agent <-->server) and download
 IMAP: Internet Mail Access Protocol [RFC 1730]
• more features (more complex)
• manipulation of stored msgs on server
 HTTP: Hotmail , Yahoo! Mail, etc.

2: Application Layer 39
POP3 protocol S: +OK POP3 server ready
C: user alice
authorization phase S: +OK
C: pass hungry
 client commands:
S: +OK user successfully logged on
 user: declare username
C: list
 pass: password
S: 1 498
 server responses S: 2 912
 +OK S: .
 -ERR C: retr 1
S: <message 1 contents>
transaction phase, client: S: .
 list: list message numbers C: dele 1
 retr: retrieve message by C: retr 2
S: <message 1 contents>
number
S: .
 dele: delete
C: dele 2
 quit C: quit
S: +OK POP3 server signing off
2: Application Layer 40