PDF

Some network apps
Application Layer Overview and
Web/HTTP
❒
E-mail
❒
❒
Web
❒
❒
Instant messaging
❒
Remote login
❒
P2P file sharing
❒
❒
2: Application Layer
❍
❍
❍
run on different end systems
and
❍
Massive parallel
computing
Multi-user network
games
Streaming stored
video clips
2: Application Layer
2
Application architectures
application
transport
network
data link
physical
❒ Client-server
❒ Peer-to-peer (P2P)
communicate over a network.
❒ Hybrid of client-server and P2P
e.g., Web: Web server
software communicates with
browser software
No software written for
devices in network core
❍
Real-time video
conference
1
Creating a network app
Write programs that
❒
Internet telephone
applicatin
transport
network
data link
physical
transport
network
data link
physical
Network core devices do not
function at app layer
This design allows for rapid
app development
2: Application Layer
3
Client-server archicture
❍
always-on host
❍
permanent IP address
❍
server farms for scaling
❍
❍
2: Application Layer
6
❒ no always on server
❒ arbitrary end systems
directly communicate
❒ peers are intermittently
clients:
❍
4
Pure P2P architecture
server:
❍
2: Application Layer
connected and change IP
addresses
communicate with server
may be intermittently
connected
❒ example: Gnutella
may have dynamic IP
addresses
Highly scalable
do not communicate
directly with each other
But difficult to manage
Examples?
2: Application Layer
5
1
Hybrid of client-server and P2P
Processes communicating
Napster
Process: program running
within a host.
❍
File transfer P2P
❍
File search centralized:
❒
• Peers register content at central server
• Peers query same central server to locate content
Instant messaging
❍
❍
Chatting between 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
❒ socket analogous to door
sending process shoves
message out door
process
2: Application Layer
Web Server
controlled by
app developer
socket
TCP with
buffers,
variables
Internet
2: Application Layer
IP = 138.110.1.1
what fields in messages &
how fields are delineated
❒ Semantics of the fields,
ie, meaning of information
in fields
❒
UI
defined in RFCs
allows for
interoperability
HTTP
Web Server
eg, HTTP, SMTP
Proprietary protocols:
❒
10
Applications and App-Layer Protocols
Public-domain protocols:
❒
2: Application Layer
9
App-layer protocol defines
❒ Syntax of message types:
Port = 25
TCP
controlled
by OS
❒
Mail Server
Port = 80
TCP with
buffers,
variables
API: (1) choice of transport protocol; (2) ability to
fix a few parameters (lots more on this later)
exchanged, eg, request &
response messages
8
process
socket
sending process relies on
transport infrastructure on
other side of door which
brings message to socket at
receiving process
❒ Types of messages
Note: applications with
P2P architectures have
client processes &
server processes
host or
server
host or
server
messages to/from its socket
❒
❒
processes in different
hosts communicate by
exchanging messages
Port Numbers
❒ process sends/receives
❍
Server process: process
that waits to be
contacted
7
Sockets
❍
within same host, two
processes communicate
using inter-process
communication (defined
by OS).
Client process: process that
initiates communication
Web Browser
eg, KaZaA
HTTP
❒ Rules for when and how
…
File
Access
processes send & respond
to messages
2: Application Layer
11
2: Application Layer
12
2
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
100% reliable data
transfer
Timing
Bandwidth
❒
❒
❒
some apps (e.g.,
Internet telephony,
interactive games)
require low delay to
be “effective”
❒
other apps (“elastic
apps”) make use of
whatever bandwidth
they get
2: Application Layer
TCP service:
UDP service:
❒ connection-oriented: setup
❒ unreliable data transfer
❒ reliable transport between
❒ does not provide:
sending and receiving process
❒ flow control: sender won’t
overwhelm receiver
❒ congestion control: throttle
sender when network
overloaded
❒ does not provide: timing,
minimum bandwidth
guarantees
❒
❒
no loss
no loss
no loss
loss-tolerant
no
no
no
yes, 100’s msec
stored audio/video
interactive games
instant messaging
loss-tolerant
loss-tolerant
no loss
elastic
elastic
elastic
audio: 5kbps-1Mbps
video:10kbps-5Mbps
same as above
few kbps up
elastic
yes, few secs
yes, 100’s msec
yes and no
2: Application Layer
e-mail
remote terminal access
Web
file transfer
streaming multimedia
connection setup,
reliability, flow control,
congestion control,
timing, or bandwidth
guarantee
Internet telephony
14
Application
layer protocol
Underlying
transport protocol
SMTP [RFC 2821]
Telnet [RFC 854]
HTTP [RFC 2616]
FTP [RFC 959]
proprietary
(e.g. RealNetworks)
proprietary
(e.g., Dialpad)
TCP
TCP
TCP
TCP
TCP or UDP
typically UDP
Q: why bother? Why is
there a UDP?
2: Application Layer
15
16
HTTP overview
HTTP: hypertext transfer
protocol
Web page consists of objects
❒
Object can be HTML file, JPEG image, Java
applet, audio file,…
client/server model
❍ client: browser that
requests, receives,
“displays” Web objects
❍ server: Web server sends
objects in response to
requests
❒ HTTP 1.0: RFC 1945
Each object is addressable by a URL
Example URL:
www.someschool.edu/someDept/pic.gif
❒
path name
2: Application Layer
Web’s application layer
protocol
❒
Web page consists of base HTML-file which
includes several referenced objects
host name
file transfer
e-mail
Web documents
real-time audio/video
Application
First some jargon
❒
Time Sensitive
Internet apps: application, transport protocols
Web and HTTP
❒
Bandwidth
13
between sending and
receiving process
2: Application Layer
❒
Data loss
Application
some apps (e.g.,
multimedia) require
minimum amount of
bandwidth to be
“effective”
Internet transport protocols services
required between client and
server processes
Transport service requirements of common apps
17
HTTP 1.1: RFC 2068
HT
TP
req
ues
PC running HT
t
TP
res
Explorer
pon
se
t
ues
req
se Server
TP
pon
s
HT
running
e
r
TP
Apache Web
HT
server
Mac running
Navigator
2: Application Layer
18
3
HTTP overview (continued)
HTTP
Uses TCP:
HTTP is “stateless”
❒ client initiates TCP
❒ server maintains no
PC running
Explorer
information about
past client requests
connection (creates socket)
to server, port 80
TCP O
pen ?
OK
aside
❒ server accepts TCP
Protocols that maintain “state”
are complex!
connection from client
❒ HTTP messages (application-
❒
layer protocol messages)
exchanged between browser
(HTTP client) and Web
server (HTTP server)
❒
❒ TCP connection closed
HTT
P GE
T…
past history (state) must be
maintained
Data
TCP Close
if server/client crashes,
their views of “state” may be
inconsistent, must be
reconciled
2: Application Layer
19
HTTP connections
Nonpersistent HTTP
❒
❒
At most one object is
sent over a TCP
connection.
HTTP/1.0 uses
nonpersistent HTTP
❒
Data
TCP Close
TCP O
pen ?
HTTP/1.1 uses
persistent
connections in default
mode
OK
HTT
P GE
T sam
i.jpg
Data
❒ one RTT for HTTP request
and first few bytes of HTTP
response to return
❒ file transmission time
total = 2RTT+transmit time
TCP Close
21
Persistent HTTP
Definition of RRT: time to send
a small packet to travel from
client to server and back.
connection
22
OK
HTT
P GE
T inde
x.htm
Multiple objects can
be sent over single
TCP connection
between client and
server.
Response time modeling
❒ one RTT to initiate TCP
2: Application Layer
TCP O
pen ?
2: Application Layer
Response time:
20
Nonpersistent HTTP
Persistent HTTP
❒
2: Application Layer
Nonpersistent HTTP issues:
Persistent without pipelining:
❒ requires 2 RTTs per object
❒ client issues new request
❒ OS must work and allocate
host resources for each
TCP connection
initiate TCP
connection
RTT
❒ but browsers often open
request
file
RTT
file
received
time
time to
transmit
file
parallel TCP connections to
fetch referenced objects
Persistent HTTP
❒ server leaves connection
open after sending response
❒ subsequent HTTP messages
time
2: Application Layer
between same client/server
are sent over connection
23
only when previous
response has been received
❒ one RTT for each
referenced object
Persistent with pipelining:
❒ default in HTTP/1.1
❒ client sends requests as
soon as it encounters a
referenced object
❒ as little as one RTT for all
the referenced objects
2: Application Layer
24
4
Persistent HTTP
HTTP request message
TCP O
pen ?
OK
HTT
P GE
T ind
ex.htm
❒
two types of HTTP messages: request, response
❒
HTTP request message:
❍
Data
ASCII (human-readable format)
request line
(GET, POST,
HEAD commands)
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
User-agent: Mozilla/4.0
header Connection: close
lines Accept-language:fr
HTT
P GE
T sam
i.jpg
Data
TCP Close
2: Application Layer
25
Carriage return,
line feed
indicates end
of message
(extra carriage return, line feed)
2: Application Layer
26
Uploading form input
HTTP request message: general format
Post method:
❒
❒
Web page often
includes form input
Input is uploaded to
server in entity body
URL method:
❒
❒
Uses GET method
Input is uploaded in
URL field of request
line:
www.somesite.com/animalsearch?monkeys&banana
2: Application Layer
Method types
HTTP/1.0
status line
(protocol
status code
status phrase)
HTTP/1.1
GET
❒
GET, POST, HEAD
❒
POST
❒
PUT
❒
HEAD
asks server to leave
requested object out
of response
28
HTTP response message
❒
❍
2: Application Layer
27
❍
❒
header
lines
uploads file in entity
body to path specified
in URL field
DELETE
❍
data, e.g.,
requested
HTML file
deletes file specified
in the URL field
2: Application Layer
29
HTTP/1.1 200 OK
Connection close
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 ...
2: Application Layer
30
5
HTTP response status codes
Trying out HTTP (client side) for yourself
In first line in server->client response message.
1. Telnet to your favorite Web server:
A few sample codes:
200 OK
❍
telnet cis.poly.edu 80
request succeeded, requested object later in this message
301 Moved Permanently
❍
2. Type in a GET HTTP request:
requested object moved, new location specified later in
this message (Location:)
request message not understood by server
404 Not Found
❍
3. Look at response message sent by HTTP server!
requested document not found on this server
505 HTTP Version Not Supported
2: Application Layer
Many major Web sites use
cookies
Four components:
1) cookie header line in the
HTTP response message
❍
❍
❍
4) back-end database at
Web site
client
Cookie file
Susan access Internet
always from same PC
ebay: 8734
She visits a specific ecommerce site for
first time
Cookie file
amazon: 1678
ebay: 8734
When initial HTTP
requests arrives at
site, site creates a
unique ID and creates
an entry in backend
database for ID
2: Application Layer
❒
authorization
❒
shopping carts
❒
recommendations
user session state
(Web e-mail)
server
usual http request msg
usual http response +
Set-cookie:
1678
usual http request msg
cookie: 1678
usual http response msg
one week later:
Cookie file
amazon: 1678
ebay: 8734
usual http request msg
cookie: 1678
usual http response msg
e
n
server
da try i
tab n b
as ac
creates ID
e
ke
nd
1678 for user
cookiespecific
action
ss
acce
ss
ce
ac
cookiespectific
action
2: Application Layer
33
Cookies (continued)
What cookies can bring:
32
Cookies: keeping “state” (cont.)
Example:
2) cookie header line in
HTTP request message
3) cookie file kept on user’s
host and managed by
user’s browser
2: Application Layer
31
User-server state: cookies
❒
By typing this in (hit carriage
return twice), you send
this minimal (but complete)
GET request to HTTP server
GET /~ross/ HTTP/1.1
Host: cis.poly.edu
400 Bad Request
❍
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
34
Web caches (proxy server)
Cookies and privacy:
aside
Goal: satisfy client request without involving origin server
❒ cookies permit sites to
❒ user sets browser: Web
learn a lot about you
❒ you may supply name and e-
mail to sites
❒ browser sends all HTTP
requests to cache
❒ search engines use
❍
redirection & cookies to
learn yet more
❍
❒ advertising companies
obtain info across sites
2: Application Layer
accesses via cache
35
object in cache: cache
returns object
else cache requests
object from origin
server, then returns
object to client
origin
server
Proxy
HT
st
TP
que
req
ues server TP re
clientHTTP
nse
t
HT
spo
res
e
r
pon
TP
se
HT
t
s
ue
req
se
TP
pon
HT
res
P
T
HT
client
origin
server
2: Application Layer
36
6
More about Web caching
❒ Cache acts as both client
Caching example
Assumptions
and server
❒ Typically cache is installed
by ISP (university,
company, residential ISP)
origin
servers
❒ average object size = 100,000
Why Web caching?
bits
❒ Reduce response time for
public
Internet
❒ avg. request rate from
client request.
institution’s browsers to
origin servers = 15/sec
❒ Reduce traffic on an
❒ delay from institutional
institution’s access link.
router to any origin server
and back to router = 2 sec
❒ Internet dense with
caches enables “poor”
content providers to
effectively deliver content
(but so does P2P file
sharing)
Consequences
❒
utilization on LAN = 15%
❒
utilization on access link = 100%
❒
1.5 Mbps
access link
institutional
network
10 Mbps LAN
total delay = Internet delay +
access delay + LAN delay
institutional
cache
= 2 sec + minutes + milliseconds
2: Application Layer
Caching example (cont)
link to, say, 10 Mbps
origin
servers
❒
❒
Consequence
public
Internet
❒ 40% requests will be
utilization on LAN = 15%
Total delay = Internet delay +
access delay + LAN delay
satisfied almost immediately
10 Mbps
access link
utilization on access link = 15%
= 2 sec + msecs + msecs
❒
origin
servers
Install cache
❒ suppose hit rate is .4
public
Internet
Consequences
❒
38
Caching example (cont)
Possible solution
❒ increase bandwidth of access
2: Application Layer
37
institutional
network
1.5 Mbps
access link
❒ 60% requests satisfied by
origin server
❒ utilization of access link
reduced to 60%, resulting
in negligible delays (say 10
msec)
❒ total avg delay = Internet
delay + access delay + LAN
delay = .6*(2.01) secs +
milliseconds < 1.4 secs
10 Mbps LAN
often a costly upgrade
institutional
cache
2: Application Layer
39
institutional
network
10 Mbps LAN
institutional
cache
2: Application Layer
40
Conditional GET
❒ Goal: don’t send object if
cache has up-to-date cached
version
❒ cache: specify date of
cached copy in HTTP request
If-modified-since:
<date>
❒ server: response contains no
object if cached copy is upto-date:
HTTP/1.0 304 Not
Modified
server
cache
HTTP request msg
If-modified-since:
<date>
HTTP response
object
not
modified
HTTP/1.0
304 Not Modified
HTTP request msg
If-modified-since:
<date>
HTTP response
object
modified
HTTP/1.0 200 OK
<data>
2: Application Layer
41
7