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).
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
Computer Networking:
represent a lot of work on our part. In return for use, we only ask the A Top Down Approach,
following:
‰ If you use these slides (e.g., in a class) in substantially unaltered form,
5th edition.
diti
that you mention their source (after all, we’d like people to use our book!) Jim Kurose, Keith Ross
‰ 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
Addison-Wesley, April
note our copyright of this material. 2009.
Thanks and enjoy! JFK/KWR

All material copyright 1996-2009

J.F Kurose and K.W. Ross, All Rights Reserved
2: Application Layer 1

2: Application Layer 2

1
Chapter 2: Application layer
ˆ 2.1 Principles of ˆ 2.6 P2P applications
network applications ˆ 2.7
2 7 Socket programming
ˆ 2.2 Web and HTTP with UDP
ˆ 2.3 FTP ˆ 2.8 Socket programming
ˆ 2.4 Electronic Mail with TCP
™ SMTP, POP3, IMAP
ˆ 2.5 DNS

2: Application Layer 3

Chapter 2: Application Layer

Our goals: ˆ learn about protocols
ˆ conceptual, by examining popular
implementation
l application-level
li i l l
aspects of network protocols
application protocols ™ HTTP
™ transport-layer ™ FTP
service models ™ SMTP / POP3 / IMAP
DNS
™ client-server
™

paradigm ˆ programming
i network
t k
™ peer-to-peer
applications
paradigm ™ socket API

2: Application Layer 4

2
 Some network apps
ˆ e-mail ˆ social networks
ˆ web ˆ voice over IP
ˆ instant messaging ˆ real-time video
ˆ remote login conferencing
ˆ P2P file sharing ˆ grid computing
ˆ multi-user network
g
games
ˆ streaming stored video
clips

2: Application Layer 5

Creating a network app application

transport
network
data link

write programs that physical

™ run on (different) end

s st ms
systems
™ communicate over network
™ e.g., web server software
communicates with browser
software application

No need to write software

transport
network
data link
for network-core devices
f
application
physical
transport
p
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 6

3
Chapter 2: Application layer
ˆ 2.1 Principles of ˆ 2.6 P2P applications
network applications ˆ 2.7
2 7 Socket programming
ˆ 2.2 Web and HTTP with UDP
ˆ 2.3 FTP ˆ 2.8 Socket programming
ˆ 2.4 Electronic Mail with TCP
™ SMTP, POP3, IMAP
ˆ 2.5 DNS

2: Application Layer 7

Application architectures
ˆ Client-server
™ Including data centers / cloud computing

ˆ Peer-to-peer (P2P)
ˆ Hybrid of client-server and P2P

2: Application Layer 8

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

Google Data Centers

ˆ Estimated cost of data center: $600M
ˆ Google
G l spentt $2.4B
$2 4B in
i 2007 on new data
d t
centers
ˆ Each data center uses 50-100 megawatts
of power

5
Pure P2P architecture
ˆ no always-on server
ˆ arbitrary end systems
directly communicate peer-peer
ˆ peers are intermittently
connected and change IP
addresses

Highly scalable but

difficult to manage

2: Application Layer 11

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 12

6
 Processes communicating
Process: program running Client process: process
within a host. that initiates
ˆ within same host, two
communication
processes communicate Server process: process
using inter-process that waits to be
communication (defined contacted
by OS).
ˆ processes in different ˆ Note
Note: applications with
hosts communicate by P2P architectures have
exchanging messages client processes &
server processes

2: Application Layer 13

Sockets

ˆ process sends/receives
host or host or
server server
messages
g to/from
f its
socket controlled by
app developer
ˆ socket analogous to door process process

™ sending process shoves socket socket

message out door TCP with TCP with
Internet buffers,
™ sending process relies on buffers,
variables variables
transport infrastructure
on other
th sideid of
fddoor which
hi h
brings message to socket controlled
by OS
at receiving process

ˆ API: (1) choice of transport protocol; (2) ability to fix

a few parameters (lots more on this later)
2: Application Layer 14

7
Addressing processes
ˆ Q: does IP address of
ˆ to receive messages, host on which process
process must have runs suffice for
identifier
f identifying the process?
ˆ host device has unique ™ A: No, many processes
32-bit IP address can be running on
ˆ Exercise: use ipconfig same
from command prompt to ˆ Identifier includes both
get your IP address IP address and port
(Windows) numbers
mb s associated
ss i t d with
ith
process on host.
ˆ Example port numbers:
™ HTTP server: 80
™ Mail server: 25
2: Application Layer 15

App-layer protocol defines

ˆ Types of messages Public-domain protocols:
exchanged, ˆ defined in RFCs
™ e.g., request, response ˆ allows for
ˆ Message syntax: interoperability
™ what fields in messages &
ˆ e.g., HTTP, SMTP,
how fields are delineated
BitTorrent
ˆ Message semantics
Proprietary protocols:
™ meaning of information in
fields ˆ e.g., Skype, ppstream
ˆ Rules for when and how
processes send &
respond to messages
2: Application Layer 16

8
 What transport service does an app need?
Data loss Throughput
ˆ some apps (e.g., audio) can ˆ some apps (e.g.,
tolerate some loss multimedia)) require
q
ˆ other apps (e.g., file minimum amount of
transfer, telnet) require throughput to be
100% reliable data “effective”
transfer
ˆ other apps (“elastic apps”)
Timing make use of whatever
ˆ some apps (e.g., g p they
throughput y get
g
I t
Internett ttelephony,
l h
interactive games) Security
require low delay to be ˆ Encryption, data
“effective” integrity, …

2: Application Layer 17

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 andd no

2: Application Layer 18

9
 Internet transport protocols services

TCP service: UDP service:

ˆ connection-oriented:
connection oriented: setup ˆ unreliable data transfer
f
required between client and between sending and
server processes receiving process
ˆ reliable transport between ˆ does not provide:
sending and receiving process connection setup,
ˆ flow control: sender won’t reliability, flow control,
overwhelm receiver congestion control, timing,
throughput guarantee, or
ˆ congestion control: throttle
security
sender when network
overloaded
ˆ does not provide: timing, Q: why bother? Why is
minimum throughput there a UDP?
guarantees, security
2: Application Layer 19

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 20

10
Chapter 2: Application layer
ˆ 2.1 Principles of ˆ 2.6 P2P applications
network applications ˆ 2.7
2 7 Socket programming
ˆ 2.2 Web and HTTP with UDP
ˆ 2.3 FTP ˆ 2.8 Socket programming
ˆ 2.4 Electronic Mail with TCP
™ SMTP, POP3, IMAP
ˆ 2.5 DNS

2: Application Layer 21

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 22

11
HTTP overview

HTTP: hypertext
transfer protocol
ˆ Web’s application layer PC running
protocol Explorer

ˆ client/server model
™ client: browser that
requests, receives, Server
“displays” Web objects running
Apache
p Web
W
™ server: Web server
server
sends objects in
response to requests
Mac running
Navigator

2: Application Layer 23

HTTP overview (continued)

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

2: Application Layer 24

12
 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 25

Nonpersistent HTTP
(contains text,
Suppose user enters URL references to 10
www.someSchool.edu/someDepartment/home.index 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 3 HTTP server receives request
3.
socket. Message indicates message, forms response
that client wants object message containing requested
someDepartment/home.index object, and sends message
into its socket

time
2: Application Layer 26

13
 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 27

Non-Persistent HTTP: Response time

Definition of RTT: time for
a small packet to travel
from client to server
and back. initiate TCP
connection
Response time: RTT
ˆ one RTT to initiate TCP request
file
connection time to
RTT
transmit
ˆ one RTT for HTTP file
requestst and
d fi
first
st few
f fil
file
received
bytes of HTTP response
to return time time
ˆ file transmission time
total = 2RTT+transmit time
2: Application Layer 28

14
 Persistent HTTP

Nonpersistent HTTP issues: Persistent HTTP

ˆ requires 2 RTTs per object ˆ server leaves connection
ˆ OS overhead
h df for each
h TCP open after sending
connection response
ˆ browsers often open parallel ˆ subsequent HTTP messages
TCP connections to fetch between same
referenced objects client/server sent 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 29

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 30

15
HTTP request message: general format

2: Application Layer 31

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 32

16
Method types
HTTP/1.0 HTTP/1.1
ˆ GET ˆ GET,
GET POST,
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 33

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
Server: Apache/1.3.0 (Unix)
header
Last-Modified: Mon, 22 Jun 1998 …...
lines
Content-Length: 6821
Content-Type: text/html

data, e
data e.g.,
g d t d
data data
t ddata
t ddata
t ddata
t ...
requested
HTML file

2: Application Layer 34

17
 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
q
™ request message not understood by server
404 Not Found
™ requested document not found on this server
505 HTTP Version Not Supported
2: Application Layer 35

Trying out HTTP (client side) for yourself

1. Telnet to your favorite Web server:

telnet cis.poly.edu 80 Opens TCP connection
O ti tot portt 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
H t cis.poly.edu
Host: i l d return twice),
twice) you send
this minimal (but complete)
GET request to HTTP server

3. Look at response message sent by HTTP server!

2: Application Layer 36

18
 User-server state: cookies
Example:
Many major Web sites
use cookies ˆ Susan always access
Four components: Internet always from PC
1) cookie header line of ˆ visits specific e-
HTTP response message commerce site for first
2) cookie header line in time
HTTP request message
3) cookie file kept on ˆ when initial HTTP
user’s host, managed by requests
q arrives at site,
user’s
’ bbrowser
site creates:
4) back-end database at
Web site ™ unique ID
™ entry in backend
database for ID
2: Application Layer 37

Cookies: keeping “state” (cont.)

client server
ebay 8734
usual http request msg
Amazon server
cookie file usual http response creates ID
Set-cookie: 1678 1678 for user create
ebay 8734 entry
amazon 1678
usual http request msg
cookie: 1678 cookie- access
specific
one week
on w later:
at r usual http
p response
p msg
g action backend
database
access
ebay 8734 usual http request msg
amazon 1678 cookie: 1678 cookie-
spectific
usual http response msg action

2: Application Layer 38

19
 Cookies (continued)
aside
What cookies can bring: Cookies and privacy:
ˆ authorization ˆ cookies permit sites to
ˆ shopping carts
learn a lot about you
ˆ 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 39

Web caches (proxy server)

Goal: satisfy client request without involving origin server

ˆ user sets browser

browser: origin
g
server
Web accesses via
cache Proxy
ˆ browser sends all server
client
HTTP requests to
cache
™ object in cache
cache: cache
returns object
™ else cache requests
object from origin client
origin
server, then returns server
object to client
2: Application Layer 40

20
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, company, institution’s access
residential ISP) link.
ˆ Internet dense with
caches: enables “poor”
poor
content providers to
effectively deliver
content (but so does
P2P file sharing)
2: Application Layer 41

Caching example
origin
Assumptions servers
ˆ average object size =
public
p
11,000,000
000 000 bits Internet
ˆ avg. request rate from
institution’s browsers to origin
servers = 15/sec
15 Mbps
ˆ delay from institutional router access link
to any origin server and back
institutional
to router = 2 sec network
p LAN
100 Mbps
C
Consequences
ˆ utilization on LAN = 15%
ˆ utilization on access link = 100%
institutional
ˆ total delay = Internet delay +
cache
access delay + LAN delay
= 2 sec + minutes + milliseconds
2: Application Layer 42

21
Caching example (cont)
origin
possible solution servers
ˆ increase bandwidth of access
public
p
link to
to, say
say, 100 Mbps Internet
consequence
ˆ utilization on LAN = 15%
ˆ utilization on access link = 15% 100 Mbps
ˆ Total delay = Internet delay + access link
access delay + LAN delay institutional
= 2 sec + msecs + msecs network
p LAN
100 Mbps
ˆ often a costly upgrade

institutional
cache

2: Application Layer 43

Caching example (cont)

origin
possible solution: install servers
cache public
p
ˆ suppose hit
h rate is 0.4
04 Internet
consequence
ˆ 40% requests will be
satisfied almost immediately
15 Mbps
ˆ 60% requests satisfied by
access link
origin server
ˆ utilization of access link institutional
reduced to 60%, resulting in network
p LAN
100 Mbps
negligible
li ibl ddelays
l ((say 10
msec)
ˆ total avg delay = Internet
delay + access delay + LAN institutional
delay = .6*(2.01) secs +
.4*milliseconds < 1.4 secs cache

2: Application Layer 44

22
 Conditional GET

ˆ Goal: don’t send object if cache server

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

23