Transcript ppt - The Fengs

CSE 524: Lecture 14
Application layer
1
Application layer protocols
• Last class
– Finished transport layer
• This class
– Application layer
• Application layer functions
• Specific application protocols
– HTTP
– Programming assignment
2
Network applications and application-layer protocols
Application: communicating
sets of distributed processes
– e.g., e-mail, Web, P2P file
sharing, instant messaging
– running in end systems (hosts)
– exchange messages to
implement application
application
transport
network
data link
physical
Application-layer protocols
– one “piece” of an app
– define messages exchanged by
apps and actions taken
– use communication services
provided by lower layer
protocols (TCP, UDP)
application
transport
network
data link
physical
application
transport
network
data link
physical
3
App-layer protocol defines
• Types of messages
exchanged, eg, request &
response messages
• Syntax of message types:
what fields in messages &
how fields are delineated
• Semantics of the fields, ie,
meaning of information in
fields
• Rules for when and how
processes send & respond to
messages
Public-domain protocols:
• defined in RFCs
• allows for interoperability
• eg, HTTP, SMTP
Proprietary protocols:
• eg, KaZaA
4
Client-server paradigm
Typical network app has two
pieces: client and server
application
transport
network
data link
physical
Client:
• initiates contact with server (“speaks
first”)
• typically requests service from
server,
• Web: client implemented in browser;
e-mail: in mail reader
Server:
• provides requested service to client
• e.g., Web server sends requested Web page,
mail server delivers e-mail
request
reply
application
transport
network
data link
physical
5
Processes communicating across network
• process sends/receives
messages to/from its socket
• socket analogous to door
– sending process shoves
message out door
– sending process asssumes
transport infrastructure on other
side of door which brings
message to socket at receiving
process
host or
server
host or
server
process
controlled by
app developer
process
socket
socket
TCP with
buffers,
variables
Internet
TCP with
buffers,
variables
controlled
by OS
• API: (1) choice of transport protocol; (2) ability to fix a few
parameters (lots more on this later)
6
Addressing processes:
• For a process to receive
messages, it must have an
identifier
• Every host has a unique 32bit IP address
• Q: does the IP address of
the host on which the
process runs suffice for
identifying the process?
• Answer: No, many
processes can be running
on same host
• Identifier includes both the
IP address and port
numbers associated with
the process on the host.
• Example port numbers:
– HTTP server: 80
– Mail server: 25
7
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
• some apps (e.g., Internet
telephony, interactive
games) require low delay
to be “effective”
Bandwidth
• some apps (e.g.,
multimedia) require
minimum amount of
bandwidth to be
“effective”
• other apps (“elastic apps”)
make use of whatever
bandwidth they get
8
Transport service requirements of common apps
Data loss
Bandwidth
Time Sensitive
file transfer
e-mail
Web documents
real-time audio/video
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
Application
yes, few secs
yes, 100’s msec
yes and no
9
Recall Internet transport protocol services
TCP service:
UDP service:
• connection-oriented: setup required • unreliable data transfer
between client and server processes
between sending and receiving
process
• reliable transport between sending
and receiving process
• does not provide: connection
setup, reliability, flow control,
• flow control: sender won’t overwhelm
congestion control, timing, or
receiver
bandwidth guarantee
• congestion control: throttle sender
when network overloaded
• does not providing: timing, minimum
bandwidth guarantees
10
Internet apps: application, transport protocols
Application
e-mail
remote terminal access
Web
file transfer
streaming multimedia
and games
Internet telephony
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
11
Application layer functions
• Applications
– Implement desired functionality within application protocols when no
underlying network service provides support
– Functionality that is common rolled into libraries and “middleware”
• Functions
–
–
–
–
–
–
–
–
Security (S/MIME, PGP, S-HTTP)
Delivery semantics (multicast overlays, anycast)
Reliable data transfer (reliable multicast, reliable UDP)
Quality of service (QoS overlays, scheduling)
Congestion control (Non-TCP applications)
Flow control (Non-TCP applications)
Naming (DNS, URLs)
Routing (overlays)
12
AL: Specific applications/protocols
•
•
•
•
HTTP
DNS
FTP
SMTP
13
AL: WWW basics
• Web page:
– consists of “objects”
– addressed by a URL
• Most Web pages consist of:
– base HTML page, and
– several referenced objects.
• URL has two components:
host name and path name:
• Client called a browser:
– MS Internet Explorer
– Netscape Communicator
• Server called a web server:
– Apache (public domain)
– MS Internet Information
Server
http://www.someSchool.edu/someDept/pic.gif
14
AL: HTTP basics
http: hypertext transfer protocol
• Web’s application layer protocol
• 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
PC running
Explorer
Server
running
NCSA Web
server
– http://www.rfc-editor.org/rfc/rfc1945.txt
• HTTP/1.1: RFC 2068
– http://www.rfc-editor.org/rfc/rfc2068.txt
• HTTP state management (cookies):
RFC 2109
– http://www.rfc-editor.org/rfc/rfc2109.txt
Mac running
Navigator
15
AL: http
http: TCP transport service:
http is “stateless”
• client initiates bi-directional TCP
connection (via socket) to server,
port 80
• server accepts TCP connection
• http protocol messages exchanged
between client and server
• server maintains no
information about past client
requests
– Requests/responses encoded in text
– Client sends request to server,
followed by response from server to
client
– How to mark end of message?
– Size of message  Content-Length
• Must know size of transfer in
advance
– Server closes connection
• TCP connection closed (only server
can do this)
aside
Protocols that maintain “state” are
complex!
• past history (state) must be
maintained
• if server/client crashes, their
views of “state” may be
inconsistent, must be
reconciled
16
AL: http example
Suppose user enters URL
www.someSchool.edu/someDepartment/home.index
1a. http client initiates TCP connection to
http server (process) at
www.someSchool.edu. Port 80 is
default for http server.
2. http client sends http request
message (containing URL) into
TCP connection socket
(contains text,
references to 10
jpeg images)
1b. http server at host
www.someSchool.edu waiting
for TCP connection at port 80.
“accepts” connection, notifying
client
3. http server receives request
message, forms response message
containing requested object
(someDepartment/home.index),
sends message into socket
time
17
AL: http example (cont.)
5. http client receives response
4. http server closes TCP connection.
message containing html file,
displays html. Parsing html file,
finds 10 referenced jpeg objects
6. Steps 1-5 repeated for each of 10
time
jpeg objects
18
AL: http message format: request
• two types of http messages: request, response
• http request message:
– ASCII (human-readable format)
request line
(GET, POST,
HEAD commands)
GET /somedir/page.html HTTP/1.0
User-agent: Mozilla/4.0
Accept: text/html, image/gif,image/jpeg
header Accept-language:fr
lines
Carriage return,
line feed
indicates end
of message
(extra carriage return, line feed)
19
AL: http request message: general format
20
AL: http response message: general format
21
AL: http request
• Request line
– Method
• HTTP 1.0
– GET – return object sepecified by URI
– HEAD – return headers only of GET response
– POST – send data to the server (forms, etc.)
• HTTP 1.1
– PUT – upload file to URI specified
– DELETE – remove file specified by URI
– OPTIONS, TRACE, CONNECT
– URI
• E.g. http://www.cse.ogi.edu/index.html with a proxy
• E.g. /index.html if no proxy
– HTTP version
22
AL: http request
• Header lines (HTTP request headers)
– Authorization
• Authentication info
– Accept
• Acceptable document types, encodings, languages, character sets
– From
• User email (when privacy is disabled)
– If-Modified-Since
• For use with caching
– Referer
• URL which caused this page to be requested
– User-Agent
• Client software
– Host
• For multiple web sites hosted on same server
– Connection
• Keep connection alive for subsequent request or close connection
23
AL: http request
• Blank-line
– Separate request headers from POST information
– End of request
• Body
– If POST, send POST information
24
AL: http request example
GET / HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT
5.0)
Host: www.cse.ogi.edu
Connection: Keep-Alive
25
AL: http message format: response
status line
(protocol
status code
status phrase)
header
lines
data, e.g.,
requested
html file
HTTP/1.0 200 OK
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 ...
26
AL: http response
• Status-line
– HTTP version
– 3 digit response code
•
•
•
•
•
1XX – informational
2XX – success
3XX – redirection
4XX – client error
5XX – server error
– Reason phrase
27
AL: http response 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
28
AL: http response
• Header lines
– Location
• redirection
– Server
• server software
– WWW-Authenticate
• request for authentication
– Allow
• list of methods supported (GET, HEAD, etc)
– Content-Encoding
• x-gzip
–
–
–
–
–
Content-Length
Content-Type
Expires
Last-Modified
ETag
29
AL: http response
• Blank-line
– Separate headers from data
• Body
– Data being returned to client
30
AL: http response example
HTTP/1.1 200 OK
Date: Tue, 27 Mar 2001 03:49:38 GMT
Server: Apache/1.3.14 (Unix) (Red-Hat/Linux) mod_ssl/2.7.1
OpenSSL/0.9.5a DAV/1.0.2 PHP/4.0.1pl2 mod_perl/1.24
Last-Modified: Mon, 29 Jan 2001 17:54:18 GMT
ETag: "7a11f-10ed-3a75ae4a"
Accept-Ranges: bytes
Content-Length: 4333
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html
…..
31
AL: Handling user input (forms)
GET method:
• Input is uploaded in URL
field of request line
POST method:
• Input is uploaded to server in
entity body
GET search?name=george&animal=monkey HTTP/1.1
Host: www.somesite.com
POST search HTTP/1.1
Host: www.somesite.com
Content-type: application/x-www-form-urlencoded
name=george&animal=monkey
32
AL: More HTTP examples
• http://www.cse.ogi.edu/class/cse524/http.txt
• http://www.cse.ogi.edu/class/cse524/http_post.txt
33
AL: Trying out HTTP (client side) for yourself
1. Telnet to your favorite Web server:
telnet www.eurecom.fr 80 Opens 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
4. Example using If-Modified-Since:
34
AL: Non-persistent and persistent connections
Non-persistent
• HTTP 0.9/1.0
• One request/response per
connection
– simple to implement
– server parses request,
responds, and closes TCP
connection
• Each object transfer
– Goes through slow start
– Incurs a connection setup
 three-way handshake
each time
Persistent
• default for HTTP/1.1
• Several requests/responses
per connection
– On same TCP connection:
server, parses request,
responds, parses new
request,..
• Client sends requests for
all referenced objects as
soon as it receives base
HTML.
• Several extra round trips
added to transfer (if done
serially)
But most 1.0 browsers use
parallel TCP connections.
35
AL: Non-persistent connections
• Short transfers are hard on TCP
– Stuck in slow start
– Loss recovery is poor when windows are small
• Lots of extra connections
– Increases server state/processing
• Server also forced to keep TIME_WAIT connection
state
– Why must server keep these?
– Tends to be an order of magnitude greater than #of active
connections, why?
36
AL: Single non-persistent example
Client
SYN
0 RTT
Client opens TCP connection
1 RTT
Client sends HTTP request for HTML
Server
SYN
DAT
ACK
2 RTT
ACK
DAT
FIN
Server reads from disk
ACK
Client parses HTML
Client opens TCP connection
FIN
ACK
3 RTT
Client sends HTTP request for image
SYN
SYN
ACK
DAT
Server reads from disk
ACK
4 RTT
Image begins to arrive
DAT
37
AL: Parallel non-persistent connections
(Netscape)
• Improve non-persistent latency by using multiple
concurrent connections
– Different parts of Web page arrive independently on separate
connections (object demux via connections)
– Can grab more of the network bandwidth than other users
• Doesn’t necessarily improve response time
– TCP loss recovery ends up being timeout dominated because
windows are small
38
AL: Persistent Connection Solution
• Multiplex multiple transfers onto one TCP connection
– Serialize transfers  client makes next request only after previous
response
• Benefits greatest for small objects
– Up to 2x improvement in response time
• Server resource utilization reduced due to fewer connection
establishments and fewer active connections
• TCP behavior improved
– Longer connections help adaptation to available bandwidth
– Larger congestion window improves loss recovery
• HTTP/1.1 vs. HTTP/1.0 example
– Multiple requests to www.cse.ogi.edu
• Problem: serial delivery of objects (head-of-line object blocking)
39
AL: Persistent Connection Example
Client
0 RTT
Client sends HTTP request for HTML
Server
DAT
ACK
Server reads from disk
DAT
1 RTT
ACK
Client parses HTML
Client sends HTTP request for image
DAT
ACK
Server reads from disk
DAT
2 RTT
Image begins to arrive
40
AL: Persistent Connection Solution
• Pipelining requests
– Getall – request HTML document and all embeds
• Requires server to parse HTML files
• Embeds returned serially
• Doesn’t consider client cached documents
– Getlist – request a set of documents
• Implemented as a simple set of GETs
• Problems with pipelined serialized requests
– Stall in one object prevents delivery of others
– Much of the useful information in first few bytes (layout info)
– Multiple connections allow incremental rendering of images as they
come in
– Need application-level demux to emulate multiple connections
• HTTP-NG, HTTP/2.0, HTTP range requests
– Application specific solution to transport protocol problems
– SCTP
41
AL: Persistent vs. non-persistent summary
Nonpersistent HTTP issues:
• requires 2 RTTs per object
• OS must work and allocate host
resources for each TCP
connection
• solves demux issue on multiple
objects
Persistent HTTP
• server leaves connection open
after sending response
• subsequent HTTP messages
between same client/server are
sent over connection
Persistent without pipelining:
• client issues new request 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
• objects returned one at a time
(HOL blocking vs. parallel nonpersistent connections)
42
AL: Some HTTP headers by function
• Authentication
– Client
• Authorization, Proxy-Authorization
– Server
• WWW-authenticate, Proxy-Authenticate
• User, server tracking
– Client
• Cookie, Referer, From, User-agent
– Server
• Set-cookie, Server
43
AL: Some HTTP headers by function
• Caching
– General
• Cache-control, Pragma
– Client
• If-Modified-Since, If-Unmodified-Since, If-Match
– Server
• Last-Modified, Expires, ETag, Age
44
AL: Authentication
Authentication goal: control access to
server
server documents
client
• stateless: client must present
usual http request msg
authorization in each request
401: authorization req.
• authorization: typically name,
WWW authenticate:
password
– authorization: header line in
request
usual http request msg
+Authorization:cred
– if no authorization presented,
server refuses access, sends
WWW authenticate:
usual http response msg
header line in response
• http://www.sandbox.com/clipboard/p
ub-doc/home.jsp
usual http request msg
+ Authorization:cred
usual http response msg
Browser caches name & password so
that user does not have to repeatedly enter it.
time
45
AL: Authentication example
• http://www.cse.ogi.edu/class/cse524/http_ba.txt
46
AL: Cookies (keeping “state”)
Many major Web sites use
cookies
Four components:
1) cookie header line in the
HTTP response message
Set-cookie:
2) cookie header line in HTTP
request message
Cookie:
3) cookie file kept on user’s host
and managed by user’s
browser
4) back-end database at Web site
Example:
– Susan access Internet always
from same PC
– She visits a specific ecommerce site for first time
– When initial HTTP requests
arrives at site, site creates a
unique ID and creates an entry
in backend database for ID
47
AL: Cookies: keeping “state” (cont.)
client
Cookie file
server
usual http request msg
usual http response +
ebay: 8734
Cookie file
amazon: 1678
ebay: 8734
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
server
creates ID
1678 for user
cookiespecific
action
cookiespectific
action
48
AL: Cookies and usage
aside
What cookies can bring:
• authorization
• shopping carts
• site preferences
• site personalization
• user session state (Web email)
Cookies and privacy:
• cookies permit sites to
learn a lot about you
• you may supply name and
e-mail to sites
• search engines use
redirection & cookies to
learn yet more
• advertising companies
obtain info across sites
49
AL: Caching
• Do not send content if it has not changed
– Can be done directly between client and server (browser)
– Can be done along path between client and server (web/proxy caches)
Why Web caching?
• Reduce response time for client request.
• Reduce network traffic
• Reduce load on servers
50
AL: Client caching
client
• “Conditional GET”
• client: specify date of
http request msg
If-modified-since:
cached copy in http request
If-modified-since:
<date>
• server: response contains
no object if cached copy
up-to-date:
HTTP/1.0 304 Not
Modified
<date>
http response
HTTP/1.0
304 Not Modified
server
object
not
modified
http request msg
If-modified-since:
<date>
http response
object
modified
HTTP/1.1 200 OK
…
<data>
51
AL: HTTP caching
• Additional caching methods
– ETag and If-Match
• HTTP 1.1 has file signature as well
• When/how often should the original be checked for
changes?
– Check every time?
– Check each session? Day? Etc?
– Use Expires header
• If no Expires, often use Last-Modified as estimate
52
AL: Example Cache Check Request
GET / HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
If-Modified-Since: Mon, 29 Jan 2001 17:54:18 GMT
If-None-Match: "7a11f-10ed-3a75ae4a"
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5;
Windows NT 5.0)
Host: www.cse.ogi.edu
Connection: Keep-Alive
53
AL: Example Cache Check Response
HTTP/1.1 304 Not Modified
Date: Tue, 27 Mar 2001 03:50:51 GMT
Server: Apache/1.3.14 (Unix) (Red-Hat/Linux)
mod_ssl/2.7.1 OpenSSL/0.9.5a DAV/1.0.2
PHP/4.0.1pl2 mod_perl/1.24
Connection: Keep-Alive
Keep-Alive: timeout=15, max=100
ETag: "7a11f-10ed-3a75ae4a"
54
AL: Web Caches (proxy server)
Goal: satisfy client request without involving origin server
• user sets browser: Web
accesses via web cache
• client sends all http requests
to web cache
•
– if object at web cache, web
cache immediately returns
object in http response
– else requests object from
origin server, then returns
http response to client
Internet dense with caches
enables “poor” content
providers to effectively deliver
content
origin
server
client
client
Proxy
server
origin
server
55
AL: More about Web caching
• Cache acts as both client to content servers
• Cache acts as server to its users
• Typically installed by ISP (university, company,
residential ISP)
• Cache can do up-to-date check using Ifmodified-since HTTP header
– Issue: should cache take risk and deliver cached object
without checking?
– Heuristics are used.
56
AL: Benefits of web caches
Assume: cache is “close” to client (e.g.,
in same network)
• smaller response time: cache
“closer” to client
• decrease traffic to distant servers
origin
servers
public
Internet
– link out of institutional/local ISP
network often bottleneck
• Further info on web caching
– http://www.ircache.net/
– http://www.squid.org
– ICP
• http://www.rfc-editor.org/rfc/rfc2186.txt
• http://www.rfc-editor.org/rfc/rfc2187.txt
1.5 Mbps
access link
institutional
network
10 Mbps LAN
institutional
cache
57
AL: Caching example (1)
Assumptions
• average object size = 100,000 bits
• avg. request rate from institution’s
browser to origin serves = 15/sec
• delay from institutional router to
any origin server and back to router
= 2 sec
Consequences
•
•
•
utilization on LAN = 15%
utilization on access link = 100%
total delay = Internet delay + access
delay + LAN delay
= 2 sec + minutes + milliseconds
origin
servers
public
Internet
1.5 Mbps
access link
institutional
network
10 Mbps LAN
institutional
cache
58
AL: Caching example (2)
Possible solution
• increase bandwidth of access link
to, say, 10 Mbps
Consequences
origin
servers
public
Internet
•
•
•
utilization on LAN = 15%
utilization on access link = 15%
Total delay = Internet delay + access
delay + LAN delay
= 2 sec + msecs + msecs
• often a costly upgrade
10 Mbps
access link
institutional
network
10 Mbps LAN
institutional
cache
59
AL: Caching example (3)
origin
servers
Install cache
• suppose hit rate is .4
Consequence
• 40% requests will be satisfied
almost immediately
• 60% requests satisfied by origin
server
• utilization of access link reduced to
60%, resulting in negligible delays
(say 10 msec)
• total delay = Internet delay +
access delay + LAN delay
= .6*2 sec + .6*.01 secs +
milliseconds < 1.3 secs
public
Internet
1.5 Mbps
access link
institutional
network
10 Mbps LAN
institutional
cache
60
AL: Content distribution networks (CDNs)
• The content providers are the CDN
customers.
Content replication
• CDN company installs hundreds of
CDN servers throughout Internet
– in lower-tier ISPs, close to users
• CDN replicates its customers’ content
in CDN servers. When provider
updates content, CDN updates servers
origin server
in North America
CDN distribution node
CDN server
in S. America CDN server
in Europe
CDN server
in Asia
61
CDN example
HTTP request for
www.foo.com/sports/sports.html
1
Origin server
2
3
DNS query for www.cdn.com
CDNs authoritative
DNS server
HTTP request for
www.cdn.com/www.foo.com/sports/ruth.gif
Nearby
CDN server
origin server
• www.foo.com
• distributes HTML
• Replaces:
http://www.foo.com/sports.ruth.gif
with
http://www.cdn.com/www.foo.com/sports/ruth.gif
CDN company
• cdn.com
• distributes gif files
• uses its authoritative DNS
server to route redirect
requests
62
More about CDNs
routing requests
• CDN creates a “map”,
indicating distances from
leaf ISPs and CDN nodes
• when query arrives at
authoritative DNS server:
– server determines ISP from
which query originates
– uses “map” to determine
best CDN server
not just Web pages
• streaming stored
audio/video
• streaming real-time
audio/video
– CDN nodes create
application-layer overlay
network
63