Chapter 2

Application Layer

A note on the use of these ppt slides:

We’re making these slides freely available to all (faculty, students, readers). Computer
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
Networking: A Top
represent a lot of work on our part. In return for use, we only ask the Down Approach,
following:
 If you use these slides (e.g., in a class) in substantially unaltered form, 4th edition.
that you mention their source (after all, we’d like people to use our book!) Jim Kurose, Keith
 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 Ross
note our copyright of this material. Addison-Wesley, July
Thanks and enjoy! JFK/KWR 2007.
All material copyright 1996-2007
J.F Kurose and K.W. Ross, All Rights Reserved
2: Application Layer 1
Chapter 2: Application layer
 2.1 Principles of  2.6 P2P applications
network applications  2.7 Socket
 2.2 Web and HTTP programming with TCP
 2.3 FTP  2.8 Socket
 2.4 Electronic Mail programming with
 SMTP, POP3, IMAP UDP
 2.5 DNS

2: Application Layer 2
Chapter 2: Application Layer
Our goals:  learn about protocols
 conceptual, by examining
implementation popular application-
aspects of network level protocols
application  HTTP
protocols  FTP
 transport-layer
 SMTP / POP3 / IMAP
 DNS
service models
 programming
 client-server
network applications
paradigm  socket API
 peer-to-peer
paradigm
2: Application Layer 3
Some network apps
 e-mail  voice over IP
 web  real-time video
 instant messaging conferencing
 remote login  grid computing
 P2P file sharing 

 multi-user network 
games 
 streaming stored
video clips

2: Application Layer 4
Creating a network app applicatio
n
transport
network

write programs that data link

physical

 run on (different) end

systems
 communicate over
network
 e.g., web server software
communicates with
applicatio
browser software n
transport
No need to write software network
data link
applicatio
n
for network-core devices physical
transport
network
 Network-core devices do data link
physical
not run user applications
 applications on end
systems allows for rapid
app development,
propagation 2: Application Layer 5
Chapter 2: Application layer
 2.1 Principles of  2.6 P2P applications
network applications  2.7 Socket
 2.2 Web and HTTP programming with TCP
 2.3 FTP  2.8 Socket
 2.4 Electronic Mail programming with
 SMTP, POP3, IMAP UDP
 2.5 DNS  2.9 Building a Web
server

2: Application Layer 6
Application architectures
 Client-server
 Peer-to-peer (P2P)
 Hybrid of client-server and P2P

2: Application Layer 7
Client-server architecture
server:
 always-on host
 permanent IP address
 server farms for
scaling
clients:
 communicate with server
client/server  may be intermittently
connected
 may have dynamic IP
addresses
 do not communicate
directly with each other

2: Application Layer 8
Pure P2P architecture
 no always-on server
 arbitrary end systems
directly communicatepeer-peer
 peers are
intermittently
connected and change
IP addresses

Highly scalable but

difficult to manage

2: Application Layer 9
Hybrid of client-server and
P2P
Skype
 voice-over-IP P2P application
 centralized server: finding address of
remote party:
 client-client connection: direct (not through
server)
Instant messaging
 chatting between two users is P2P
 centralized service: client presence
detection/location
• user registers its IP address with central
server when it comes online
• user contacts central server to find IP
addresses of buddies
2: Application Layer 10
Processes communicating
Process: program Client process: process
running within a host. that initiates
 within same host, two communication
processes Server process:
communicate using process that waits to
inter-process be contacted
communication
(defined by OS).  Note: applications
 processes in different with P2P architectures
hosts communicate by have client processes
exchanging messages & server processes

2: Application Layer 11
App-layer protocol defines
 Types of messages Public-domain
exchanged, protocols:
 e.g., request, response  defined in RFCs
 Message syntax:  allows for
 what fields in messages
interoperability
& how fields are
delineated  e.g., HTTP, SMTP
 Message semantics Proprietary protocols:
 meaning of information  e.g., Skype
in fields
 Rules for when and
how processes send &
respond to messages
2: Application Layer 12
 What transport service does an app
need?
Data loss Throughput
 some apps (e.g., audio)  some apps (e.g., multimedia)

can tolerate some loss require minimum amount of

throughput to be “effective”
 other apps (e.g., file
 other apps (“elastic apps”)
transfer, telnet) require make use of whatever
100% reliable data throughput they get
transfer Security
Timing  Encryption, data integrity, …
 some apps (e.g.,
Internet telephony,
interactive games)
require low delay to
be “effective”

2: Application Layer 13
 Transport service requirements of common
apps

Application Data loss Throughput Time Sensitive

file transfer no loss elastic no

e-mail no loss elastic no
Web documents no loss elastic no
real-time audio/video loss-tolerant audio: 5kbps-1Mbps yes, 100’s msec
video:10kbps-5Mbps
stored audio/video loss-tolerant same as above yes, few secs
interactive games loss-tolerant few kbps up yes, 100’s msec
instant messaging no loss elastic yes and no

2: Application Layer 14
Internet transport protocols services

TCP service: UDP service:

 connection-oriented: setup  unreliable data transfer
required between client and between sending and
server processes 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, throughput
 congestion control: throttle guarantee, or security
sender when network
overloaded
Q: why bother? Why is
 does not provide: timing, there a UDP?
minimum throughput
guarantees, security
2: Application Layer 15
Internet apps: application, transport protocols

Application Underlying
Application layer protocol transport protocol

e-mail SMTP [RFC 2821] TCP

remote terminal access Telnet [RFC 854] TCP
Web HTTP [RFC 2616] TCP
file transfer FTP [RFC 959] TCP
streaming multimedia HTTP (eg Youtube), TCP or UDP
RTP [RFC 1889]
Internet telephony SIP, RTP, proprietary
(e.g., Skype) typically UDP

2: Application Layer 16
Chapter 2: Application layer
 2.1 Principles of  2.6 P2P applications
network applications  2.7 Socket
 app architectures programming with TCP
 app requirements  2.8 Socket
 2.2 Web and HTTP
programming with
 2.4 Electronic Mail UDP
 SMTP, POP3, IMAP
 2.5 DNS

2: Application Layer 17
Web and HTTP
First some jargon
 Web page consists of objects
 Object can be HTML file, JPEG image, Java
applet, audio file,…
 Web page consists of base HTML-file which
includes several referenced objects
 Each object is addressable by a URL
 Example URL:

www.someschool.edu/someDept/pic.gif

host name path name

2: Application Layer 18
HTTP overview

HTTP: hypertext
transfer protocol HT
TP
requ
 Web’s application layer H
PC running TT est
Pr
protocol Explorer esp
ons
 client/server model e

 client: browser that

e st
u
requests, receives, req se Server
T P n
“displays” Web HT spo running
r e
objects T TP Apache Web
H server
 server: Web server
sends objects in
Mac running
response to requests Navigator

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

2: Application Layer 20
HTTP connections
Nonpersistent HTTP Persistent HTTP
 At most one object is  Multiple objects can
sent over a TCP be sent over single
connection. TCP connection
between client and
server.

2: Application Layer 21
 Nonpersistent HTTP
(contains text,
Suppose user enters URL www.someSchool.edu/someDepartment/home.index
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 on port 80
for TCP connection at port
80. “accepts” connection,
notifying client
2. HTTP client sends HTTP request
message (containing URL) into TCP
connection socket. Message indicates
that client wants object 3. HTTP server receives
someDepartment/home.index
request message, forms
response message
containing requested object,
and sends message into its
socket
time
2: Application Layer 22
 Nonpersistent HTTP (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
time 6. Steps 1-5 repeated for each
of 10 jpeg objects

2: Application Layer 23
Non-Persistent HTTP: Response
time
Definition of RTT: time for a
small packet to travel
from client to server and
back. initiate TCP
Response time: connection
RTT
 one RTT to initiate TCP
request
connection file
 one RTT for HTTP request time to
RTT
transmit
and first few bytes of file
file
HTTP response to return received
 file transmission time
total = 2RTT+transmit time time time

2: Application Layer 24
Persistent HTTP

Nonpersistent HTTP issues: Persistent HTTP

 requires 2 RTTs per object  server leaves connection
 OS overhead for each TCP open after sending
connection response
 browsers often open  subsequent HTTP
parallel TCP connections messages between
to fetch referenced same client/server sent
objects over open connection
 client sends requests as
soon as it encounters a
referenced object
 as little as one RTT for all
the referenced objects

2: Application Layer 25
 HTTP request message
 two types of HTTP messages: request,
response
 HTTP request message:
 ASCII (human-readable format)
request line
(GET, POST, GET /somedir/page.html HTTP/1.1
HEAD commands) Host: www.someschool.edu
User-agent: Mozilla/4.0
header Connection: close
lines Accept-language:fr

Carriage return,
line feed (extra carriage return, line feed)
indicates end
of message
2: Application Layer 26
HTTP request message: general
format

2: Application Layer 27
Uploading form input
Post method:
 Web page often
includes form input URL method:
 Input is uploaded to  Uses GET method
server in entity body  Input is uploaded in
URL field of request
line:

www.somesite.com/animalsearch?monkeys&banana

2: Application Layer 28
Method types
HTTP/1.0 HTTP/1.1
 GET  GET, POST, HEAD
 POST  PUT
 HEAD  uploads file in entity
body to path specified
 asks server to leave
in URL field
requested object out
of response  DELETE
 deletes file specified
in the URL field

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

data, e.g., data data data data data ...

requested
HTML file

2: Application Layer 30
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 31
 Trying out HTTP (client side) for yourself

1. Telnet to your favorite Web server:

telnet cis.poly.edu 80 Opens TCP connection to port 80
(default HTTP server port) at cis.poly.edu.
Anything typed in sent
to port 80 at cis.poly.edu

2. Type in a GET HTTP request:

GET /~ross/ HTTP/1.1 By typing this in (hit carriage
Host: cis.poly.edu 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 32
User-server state: cookies
Example:
Many major Web sites
 Susan always access
use cookies
Four components: Internet always from PC
 visits specific e-
1) cookie header line of
HTTP response commerce site for first
message time
2) cookie header line in  when initial HTTP
HTTP request
message requests arrives at site,
3) cookie file kept on site creates:
user’s host, managed  unique ID
by user’s browser
 entry in backend
4) back-end database at
Web site database for ID

2: Application Layer 33
 Cookies: keeping “state” (cont.)
client server
ebay 8734
usual http request
Amazon server
msg
cookie file usual http responsecreates ID
Set-cookie: 1678 1678 for user create
ebay 8734 entry
amazon 1678
usual http request
msg cookie- access
cookie: 1678 specific
one week later: usual http response action backend
msg database
access
ebay 8734 usual http request
amazon 1678 msg cookie-
cookie: 1678 spectific
usual http response action
msg
2: Application Layer 34
Cookies (continued)
aside
What cookies can bring: Cookies and privacy:
 cookies permit sites to
 authorization
learn a lot about you
 shopping carts
 you may supply name
 recommendations and e-mail to sites
 user session state
(Web e-mail)
How to keep “state”:
 protocol endpoints: maintain
state at sender/receiver over
multiple transactions
 cookies: http messages carry
state
2: Application Layer 35
 Web caches (proxy server)
Goal: satisfy client request without involving origin server

 user sets browser: origin

server
Web accesses via
cache Proxy
HT st
 browser sends all HTTP TP
req server reque
H ues se
requests to cache client TTP t T TP on
H
re s
pon r esp
 object in cache: cache se H TTP
e st
returns object u
req se
P n
 else cache requests HT
T
spo
e
object from origin T Pr
server, then returns HT
object to client client
origin
server

2: Application Layer 36
More about Web caching
 cache acts as both Why Web caching?
client and server  reduce response time
 typically cache is for client request
installed by ISP  reduce traffic on an
(university, institution’s access
company, residential link.
ISP)  Internet dense with
caches: enables
“poor” content
providers to
effectively deliver
content (but so does
P2P file sharing)
2: Application Layer 37
Caching example
origin
Assumptions servers
 average object size = 100,000
bits public
Internet
 avg. request rate from
institution’s browsers to origin
servers = 15/sec
 delay from institutional router 1.5 Mbps
to any origin server and back access link
to router = 2 sec institutional
Consequences network
10 Mbps LAN
 utilization on LAN = 15%
 utilization on access link = 100%
 total delay = Internet delay +
access delay + LAN delay institutional
= 2 sec + minutes + milliseconds cache

2: Application Layer 38
Caching example (cont)
origin
possible solution servers
 increase bandwidth of
public
access link to, say, 10 Mbps Internet
consequence
 utilization on LAN = 15%
 utilization on access link = 10 Mbps
15% access link
 Total delay = Internet delay +
institutional
access delay + LAN delay network
10 Mbps LAN
= 2 sec + msecs + msecs
 often a costly upgrade

institutional
cache

2: Application Layer 39
Caching example (cont)
origin
possible solution: install servers
cache public
 suppose hit rate is 0.4 Internet
consequence
 40% requests will be
satisfied almost
immediately 1.5 Mbps
 60% requests satisfied by access link
origin server institutional
 utilization of access link
network
reduced to 60%, resulting in 10 Mbps LAN
negligible delays (say 10
msec)
 total avg delay = Internet
delay + access delay + LAN institutional
delay = .6*(2.01) secs cache
+ .4*milliseconds < 1.4
secs
2: Application Layer 40
 Conditional GET

 Goal: don’t send object if cache server

cache has up-to-date HTTP request msg
cached version If-modified-since:
<date>
object
 cache: specify date of
not
cached copy in HTTP modified
request HTTP response
HTTP/1.0
If-modified-since: 304 Not Modified
<date>
 server: response contains
HTTP request msg
no object if cached copy is If-modified-since:
up-to-date: <date> object
HTTP/1.0 304 Not modified
Modified HTTP response
HTTP/1.0 200 OK
<data>
2: Application Layer 41