CSE 524: Lecture 14

1
CSE 524 Lecture 14

• Application layer

2
Application layer protocols

• Last class
• Finished transport layer
• This class
• Application layer
• Application layer functions
• Specific application protocols
• HTTP
• Programming assignment

3
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-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)

4
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

5
Client-server paradigm

• Typical network app has two pieces client and
  server

• 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

6
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

controlled by app developer
Internet
controlled by OS

• API (1) choice of transport protocol (2)
  ability to fix a few parameters (lots more on
  this later)

7
Addressing processes

• For a process to receive messages, it must have
  an identifier
• Every host has a unique 32-bit 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

8
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

• 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

• Timing
• some apps (e.g., Internet telephony, interactive
  games) require low delay to be effective

9
Transport service requirements of common apps
Time Sensitive no no no yes, 100s msec yes,
few secs yes, 100s msec yes and no
Application file transfer e-mail Web
documents real-time audio/video stored
audio/video interactive games instant messaging
Bandwidth elastic elastic elastic audio
5kbps-1Mbps video10kbps-5Mbps same as above few
kbps up elastic
Data loss no loss no loss no loss loss-tolerant
loss-tolerant loss-tolerant no loss
10
Recall Internet transport protocol services

• TCP service
• connection-oriented setup required between
  client and server processes
• reliable transport between sending and receiving
  process
• flow control sender wont overwhelm receiver
• congestion control throttle sender when network
  overloaded
• does not providing timing, minimum bandwidth
  guarantees

• UDP service
• unreliable data transfer between sending and
  receiving process
• does not provide connection setup, reliability,
  flow control, congestion control, timing, or
  bandwidth guarantee

11
Internet apps application, transport protocols
Application layer protocol SMTP RFC
2821 Telnet RFC 854 HTTP RFC 2616 FTP RFC
959 proprietary (e.g. RealNetworks) proprietary (
e.g., Dialpad)
Underlying transport protocol TCP TCP TCP TCP TCP
or UDP typically UDP
Application e-mail remote terminal access Web
file transfer streaming multimedia and
games Internet telephony
12
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)

13
AL Specific applications/protocols

• HTTP
• DNS
• FTP
• SMTP

14
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
15
AL HTTP basics

• http hypertext transfer protocol
• Webs 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
• 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

http request
PC running Explorer
http response
http request
Server running NCSA Web server
http response
Mac running Navigator
16
AL http

• http TCP transport service
• client initiates bi-directional TCP connection
  (via socket) to server, port 80
• server accepts TCP connection
• http protocol messages exchanged between client
  and server
• 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)

• http is stateless
• server maintains no information about past client
  requests

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

17
AL http example

• Suppose user enters URL www.someSchool.edu/someDep
  artment/home.index

(contains text, references to 10 jpeg images)

• 1a. http client initiates TCP connection to http
  server (process) at www.someSchool.edu. Port 80
  is default for http server.

1b. http server at host www.someSchool.edu
waiting for TCP connection at port 80. accepts
connection, notifying client
2. http client sends http request message
(containing URL) into TCP connection socket
3. http server receives request message, forms
response message containing requested object
(someDepartment/home.index), sends message into
socket
time
18
AL http example (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

6. Steps 1-5 repeated for each of 10 jpeg objects
time
19
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 Accept-languagefr (extra
carriage return, line feed)
header lines
Carriage return, line feed indicates end of
message
20
AL http request message general format
21
AL http response message general format
22
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

23
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

24
AL http request

• Blank-line
• Separate request headers from POST information
• End of request
• Body
• If POST, send POST information

25
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

26
AL http message format response
status line (protocol status code status phrase)
HTTP/1.0 200 OK Date Thu, 06 Aug 1998 120015
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 ...
header lines
data, e.g., requested html file
27
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

28
AL http response codes
In first line in server-gtclient 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

29
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

30
AL http response

• Blank-line
• Separate headers from data
• Body
• Data being returned to client

31
AL http response example

• HTTP/1.1 200 OK
• Date Tue, 27 Mar 2001 034938 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 175418 GMT
• ETag "7a11f-10ed-3a75ae4a"
• Accept-Ranges bytes
• Content-Length 4333
• Keep-Alive timeout15, max100
• Connection Keep-Alive
• Content-Type text/html
• ..

32
AL Handling user input (forms)

• POST method
• Input is uploaded to server in entity body

• GET method
• Input is uploaded in URL field of request line

GET search?namegeorgeanimalmonkey
HTTP/1.1 Host www.somesite.com
POST search HTTP/1.1 Host www.somesite.com Conten
t-type application/x-www-form-urlencoded namege
orgeanimalmonkey
33
AL More HTTP examples

• http//www.cse.ogi.edu/class/cse524/http.txt
• http//www.cse.ogi.edu/class/cse524/http_post.txt

34
AL Trying out HTTP (client side) for yourself

• 1. Telnet to your favorite Web server

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
telnet www.eurecom.fr 80
2. Type in a GET HTTP request
By typing this in (hit carriage return twice),
you send this minimal (but complete) GET request
to HTTP server
GET /ross/index.html HTTP/1.0
3. Look at response message sent by HTTP
server 4. Example using If-Modified-Since
35
AL Non-persistent and persistent connections

• 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.

• 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
• Several extra round trips added to transfer (if
  done serially)

But most 1.0 browsers use parallel TCP
connections.
36
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?

37
AL Single non-persistent example

• Client

Server
SYN
0 RTT
SYN
Client opens TCP connection
1 RTT
ACK
DAT
Client sends HTTP request for HTML
ACK
Server reads from disk
DAT
FIN
2 RTT
ACK
Client parses HTML Client opens TCP connection
FIN
ACK
SYN
SYN
3 RTT
ACK
DAT
Client sends HTTP request for image
Server reads from disk
ACK
4 RTT
DAT
Image begins to arrive
38
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
• Doesnt necessarily improve response time
• TCP loss recovery ends up being timeout dominated
  because windows are small

39
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)

40
AL Persistent Connection Example

• Client

Server
0 RTT
DAT
Client sends HTTP request for HTML
ACK
Server reads from disk
DAT
1 RTT
ACK
Client parses HTML Client sends HTTP request for
image
DAT
Server reads from disk
ACK
DAT
2 RTT
Image begins to arrive
41
AL Persistent Connection Solution

• Pipelining requests
• Getall request HTML document and all embeds
• Requires server to parse HTML files
• Embeds returned serially
• Doesnt 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

42
AL Persistent vs. non-persistent summary

• 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 non-persistent connections)

• 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

43
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

44
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

45
AL Authentication

• Authentication goal control access to server
  documents
• stateless client must present authorization in
  each request
• authorization typically name, password
• authorization header line in request
• if no authorization presented, server refuses
  access, sends
• WWW authenticate
• header line in response
• http//www.sandbox.com/clipboard/pub-doc/home.jsp

server
client
usual http request msg
401 authorization req. WWW authenticate
Browser caches name password so that user does
not have to repeatedly enter it.
46
AL Authentication example

• http//www.cse.ogi.edu/class/cse524/http_ba.txt

47
AL Cookies (keeping state)

• Many major Web sites use cookies
• Four components
• cookie header line in the HTTP response message
• Set-cookie
• 2) cookie header line in HTTP request message
• Cookie
• 3) cookie file kept on users host and managed by
  users browser
• 4) back-end database at Web site

• Example
• Susan access Internet always from same PC
• She visits a specific e-commerce 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

48
AL Cookies keeping state (cont.)
server creates ID 1678 for user
entry in backend database
access
access
one week later
49
AL Cookies and usage
aside

• 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

• What cookies can bring
• authorization
• shopping carts
• site preferences
• site personalization
• user session state (Web e-mail)

50
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

51
AL Client caching
server
client

• Conditional GET
• client specify date of cached copy in http
  request
• If-modified-since ltdategt
• server response contains no object if cached
  copy up-to-date
• HTTP/1.0 304 Not Modified

http request msg If-modified-since ltdategt
object not modified
http request msg If-modified-since ltdategt
object modified
http response HTTP/1.1 200 OK ltdatagt
52
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

53
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 175418 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

54
AL Example Cache Check Response

• HTTP/1.1 304 Not Modified
• Date Tue, 27 Mar 2001 035051 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 timeout15, max100
• ETag "7a11f-10ed-3a75ae4a"

55
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
Proxy server
http request
http request
client
http response
http response
http request
http request
http response
http response
client
origin server
56
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
  If-modified-since HTTP header
• Issue should cache take risk and deliver cached
  object without checking?
• Heuristics are used.

57
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
• 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

origin servers
public Internet
1.5 Mbps access link
institutional network
10 Mbps LAN
institutional cache
58
AL Caching example (1)
origin servers

• Assumptions
• average object size 100,000 bits
• avg. request rate from institutions 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

public Internet
1.5 Mbps access link
institutional network
10 Mbps LAN
institutional cache
59
AL Caching example (2)
origin servers

• Possible solution
• increase bandwidth of access link to, say, 10
  Mbps
• Consequences
• 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

public Internet
10 Mbps access link
institutional network
10 Mbps LAN
institutional cache
60
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
• .62 sec .6.01 secs milliseconds lt 1.3
  secs

public Internet
1.5 Mbps access link
institutional network
10 Mbps LAN
institutional cache
61
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 Asia
CDN server in Europe
62
CDN example

• 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

63
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