Application Layer Overview and

Web/HTTP

2: Application Layer 1
Some network apps
 E-mail  Internet telephone
 Web  Real-time video
 Instant messaging conference
 Remote login  Massive parallel

 P2P file sharing computing

 Multi-user network
games
 Streaming stored
video clips

2: Application Layer 2
Creating a network app
Write programs that application
transport
network
 run on different end data link
physical
systems and
 communicate over a
network.
 e.g., Web: Web server
software communicates
with browser software
No software written for application
application

devices in network core

transport
transport network
network data link
data link
 Network core devices do physical
physical

not function at app layer

 This design allows for rapid
app development
2: Application Layer 3
Application architectures
 Client-server
 Peer-to-peer (P2P)
 Hybrid of client-server and P2P

2: Application Layer 4
Client-server archicture
server:
 always-on host
 permanent IP address
 server farms for scaling
clients:
 communicate with server
 may be intermittently
connected
 may have dynamic IP
addresses
 do not communicate
directly with each other
Examples?

2: Application Layer 5
Pure P2P architecture
 no always on server
 arbitrary end systems
directly communicate
 peers are intermittently
connected and change IP
addresses
 example: Gnutella

Highly scalable

But difficult to manage

2: Application Layer 6
Hybrid of client-server and P2P
Napster
 File transfer P2P
 File search centralized:
• Peers register content at central server
• Peers query same central server to locate content
Instant messaging
 Chattingbetween two users is P2P
 Presence detection/location centralized:
• 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 7
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: applications with
hosts communicate by P2P architectures have
exchanging messages client processes &
server processes

2: Application Layer 8
 Sockets
host or host or
 process sends/receives server server
messages to/from its
socket controlled by
app developer
 socket analogous to door process process

socket
 sending process shoves socket
message out door TCP with TCP with
buffers, Internet buffers,
 sending process relies on variables variables
transport infrastructure
on other side of door which
controlled
brings message to socket 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 9
Port Numbers

Web Server Mail Server

Port = 80 Port = 25

TCP

IP = 138.110.1.1

2: Application Layer 10
App-layer protocol defines
 Types of messages Public-domain protocols:
exchanged, eg, request &  defined in RFCs
response messages
 allows for
 Syntax of message
types: what fields in interoperability
messages & how fields  eg, HTTP, SMTP
are delineated Proprietary protocols:
 Semantics of the fields,
 eg, KaZaA
ie, meaning of
information in fields
 Rules for when and how
processes send &
respond to messages
2: Application Layer 11
Applications and App-Layer Protocols

UI

HTTP
Web Server

Web Browser

File
HTTP … Access

2: Application Layer 12
What transport service does an app need?
Data loss Bandwidth
 some apps (e.g., audio) can  some apps (e.g.,
tolerate some loss multimedia) require
 other apps (e.g., file minimum amount of
transfer, telnet) require bandwidth to be
100% reliable data “effective”
transfer  other apps (“elastic
Timing apps”) make use of
 some apps (e.g., whatever bandwidth they
Internet telephony, get
interactive games)
require low delay to be
“effective”
2: Application Layer 13
 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 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 process connection setup,
 flow control: sender won’t reliability, flow control,
overwhelm receiver congestion control, timing,
 congestion control: throttle or bandwidth guarantee
sender when network
overloaded Q: why bother? Why is
 does not provide: timing, there a UDP?
minimum bandwidth
guarantees
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 proprietary TCP or UDP
(e.g. RealNetworks)
Internet telephony proprietary
(e.g., Dialpad) typically UDP

2: Application Layer 16
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 17
HTTP overview

HTTP: hypertext
transfer protocol HT
TP
r
equ
 Web’s application layer PC running HT est
TP
protocol Explorer res
pon
se
 client/server model
 client: browser that
e st
u
requests, receives, P r eq se Server
T o n
“displays” Web objects HT r es
p running
T P Apache Web
 server: Web server HT
server
sends objects in
response to requests
Mac running
 HTTP 1.0: RFC 1945 Navigator
 HTTP 1.1: RFC 2068

2: Application Layer 18
HTTP overview (continued)
Uses TCP: HTTP is “stateless”
 client initiates TCP  server 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 19
HTTP
PC running
Explorer

TCP O
pe n?

OK
HTTP
GE T…

Data

TCP Close

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
 HTTP/1.0 uses between client and
nonpersistent HTTP server.
 HTTP/1.1 uses
persistent connections
in default mode

2: Application Layer 21
Nonpersistent HTTP
TCP O
pe n?

OK
HTTP
GE T ind
ex.ht
m

Data
TCP Close

TCP O
pe n?

OK
HTTP
GE T sam
i.jpg

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

2: Application Layer 23
Persistent HTTP

Nonpersistent HTTP issues: Persistent without pipelining:

 requires 2 RTTs per object  client issues new request
 OS must work and allocate only when previous
host resources for each TCP response has been received
connection  one RTT for each
 but browsers often open referenced object
parallel TCP connections to Persistent with pipelining:
fetch referenced objects  default in HTTP/1.1
Persistent HTTP  client sends requests as
 server leaves connection soon as it encounters a
open after sending response referenced object
 subsequent HTTP messages  as little as one RTT for all
between same client/server the referenced objects
are sent over connection

2: Application Layer 24
Persistent HTTP
TCP O
pe n?

OK
HTTP
GE T ind
ex.ht
m

Data
HTTP
GE T sam
i.jpg

Data
TCP Close

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
Many major Web sites Example:
use cookies  Susan access Internet
Four components: always from same PC
 She visits a specific e-
1) cookie header line in
commerce site for first
the HTTP response
time
message
 When initial HTTP
2) cookie header line in
requests arrives at site,
HTTP request message
site creates a unique ID
3) cookie file kept on and creates an entry in
user’s host and managed backend database for
by user’s browser ID
4) back-end database at
Web site

2: Application Layer 33
 Cookies: keeping “state” (cont.)

client server
Cookie file usual http request msg server n e
da try i
tab n b
usual http response + creates ID as ac
e ke
ebay: 8734 Set-cookie: 1678 1678 for user nd

Cookie file
usual http request msg
amazon: 1678 cookie: 1678 cookie- ss
ebay: 8734 specific acce
usual http response msg action

ss
one week later:

ce
ac
usual http request msg
Cookie file cookie-
cookie: 1678
amazon: 1678 spectific
ebay: 8734 usual http response msg action

2: Application Layer 34
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
 search engines use
(Web e-mail)
redirection & cookies
to learn yet more
 advertising companies
obtain info across
sites

2: Application Layer 35
Web caches (proxy server)
Goal: satisfy client request without involving origin server

 user sets browser: Web origin

accesses via cache server
 browser sends all HTTP Proxy
HT
requests to cache TP
req server q uest
H u P re
T
client TP e st T T o n se
object in cache: cache H p
res r es

pon P
returns object se H TT
else cache requests e st
 u
P r eq nse
object from origin T p o
HT r es
server, then returns TP
HT
object to client
client
origin
server

2: Application Layer 36
More about Web caching
 Cache acts as both client Why Web caching?
and server  Reduce response time for
 Typically cache is installed
client request.
by ISP (university,  Reduce traffic on an
company, residential ISP) institution’s access link.
 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
 avg. request rate from Internet

institution’s browsers to origin

servers = 15/sec
 delay from institutional router to
1.5 Mbps
any origin server and back to access link
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 access
public
link to, say, 10 Mbps
Internet
Consequences
 utilization on LAN = 15%
 utilization on access link = 15%
10 Mbps
 Total delay = Internet delay +
access link
access delay + LAN delay
institutional
= 2 sec + msecs + msecs network
 often a costly upgrade 10 Mbps LAN

institutional
cache

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

2: Application Layer 40
 Conditional GET

 Goal: don’t send object if cache server

cache has up-to-date cached HTTP request msg
version If-modified-since:
object
 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
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 41