PART - I

Principles of Network Applications, The Web and HTTP

 E-mail
 Web
 Instant messaging
 Remote login
 P2P file sharing
 Multi-user network games
 Streaming stored audio and video clips
 Voice over IP
 Real-time video conferencing
 Internet Radio
 IP TV
 Write programs that
 Run on different end systems
and
 Communicate over a network
 E.g, web server software
communicates with browser
software
 Little software written for
devices in network core
 Network core devices do not
run user application code
 Application on end systems
allows for rapid app
development, propagation
 Client-server
 Peer-to-Peer (P2P)
 Hybrid
 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
 E.g. search engines, e-
commerce, web-based email,
social networking
Infrastructure Intensive
 No always-on server
 Arbitrary end systems
directly communicate
 Peers are
intermittently
connected and change
IP addresses
 E.g. BitTorrent,
Highly scalable but
difficult to manage
 Skype
 Internet Telephony app
 Finding address of remote party: centralized server(s)
 Client-client connection is direct
 Instant messaging
 Chatting between two users is P2P
 Presence detection/location centralized:
▪ Users registers its IP address with central server when it
comes online
▪ User contacts central server to fine IP addresses of buddies
Process: Program running  Client process: process
within a host that initiates
 Within same host, two communication
processes  Server process:
communicate using process that waits to
inter-process be contacted
communication
 Processes in different
hosts communicate by
exchanging messages.
 Process sends/receives
messages to/from its host or host or
server server
socket
 Socket analogous to controlled by
door process
app developer
process
 Sending process shoves socket socket
message out door TCP with TCP with
Internet
 Sending process relies on buffers, buffers,
variables variables
transport infrastructure on
other side of door which
Controlled by OS
brings message to socket
at receiving process
 To receive messages,  Identifier includes both
process must have IP address and port
identifiers numbers associated with
 Host device has unique process on host
32-bit IP address.  E.g.
 Many processes can be  HTTP server – 80
running on same host  Mail server – 25
 Port number to identify  To send HTTP message
the process to gaia.cs.umass.edu
web server
 IP address: 128.119.245.12
 Port Number : 80
 Defines  Public domain protocols
 Types of messages  defined in RFCs
exchanged  Allows for interoperability
▪ E.g. request, response  e.g. HTTP, SMTP
 Message syntax  Proprietary protocols
▪ What fields in messages and
how fields are delineated  e.g. Skype
 Message semantics
▪ Meaning of information in
fields
 Rules for when and how
processes send & respond
to messages
 Data loss
 Some apps can tolerate
some loss (e.g. audio)
 Other apps require 100%
reliable data transfer (e.g.
file transfer, telnet)
 Timing
 Some apps require low
delay to be effective (e.g.
internet telephony,
interactive games)
 Throughput
 Some apps require
minimum amount of
throughput to be effective
(e.g., multimedia)
 Other apps (“elastic apps”)
make use whatever
throughput they get
 Security
 Encryption, data integrity
 Application Data Loss Bandwidth Time-sensitive
File transfer No loss Elastic No
E-mail No loss Elastic No
Web documents No loss Elastic No
Internet Loss-tolerant Audio: few kbps – Yes, 100s of msec
telephony/video 1Mbps
conferencing Video: 10kbps – 5
Mbps
Stored audio/ video Loss-tolerant Same as above Yes, few secs
Interactive games Loss-tolerant Few kbps – 10 kbps Yes, 100s of msec
Instant messaging No loss Elastic Yes and No
 TCP SERVICE
 connection-oriented: setup
required between client and
server processes
 reliable transport between
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
UDP SERVICE
 unreliable data transfer
between sending and
receiving process
 does not provide:
connection setup,
reliability, flow control,
congestion control, timing,
or bandwidth guarantee
 Application Application Layer Underlying transport
Protocol protocol
E-mail SMTP [RFC 5321] 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
Internet Telephony Proprietary Typically UDP
 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
www.siescoms.edu/programmes/index.html

Host Name Path Name

 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
 Uses TCP  HTTP is “stateless”
 Client initiates TCP  Server maintains no
connection (creates information about past
socket) to server, port 80 client requests
 Server accepts TCP
connection from client
 HTTP messages
exchanged between
browser and web server
 TCP connection closed
 Nonpersistent HTTP  Persistent HTTP
 At most one object is  Multiple objects can be
sent over a TCP sent over single TCP
connection connection between
client and server
 suppose user enters URL:
www.someSchool.edu/someDepartment/home.index
1a. HTTP client initiates TCP
connection to HTTP server
(process) at
www.someSchool.edu on port
80
2. HTTP client sends HTTP request
message (containing URL) into TCP
connection socket. Message
indicates that client wants object
someDepartment/home.index
time
(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, and
sends message into its socket
 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
 Round Trip Time (RTT):
time for a small packet
to travel from client to
server and back
 Response time
 One RTT to initiate TCP
connection
 One RTT for HTTP request
and first few bytes of HTTP
response to return
 File transmission time
▪ 2RTT+transmt time
 Nonpersistent HTTP
issues
 Requires 2 RTTs per object
 OS overhead for each TCP
connection
 Browsers of ten open
parallel TCP connections to
fetch referenced objects
 Persistent HTTP
 Server leaves connection
open after sending
response
 Subsequent HTTP
messages between same
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
▪ With pipelining
▪ Without pipelining
 Two types of HTTP messages: request, response
 HTTP request message
 ASCII
carriage return character
request line
(GET, POST, GET /index.html HTTP/1.1\r\n line-feed character
HEAD commands) Host: www-net.cs.umass.edu\r\n
User-Agent: Firefox/3.6.10\r\n
header Accept: text/html,application/xhtml+xml\r\n
lines Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
carriage return, Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
line feed at start Keep-Alive: 115\r\n
of line indicates Connection: keep-alive\r\n
\r\n
end of header lines
 method sp URL sp version cr lf request
line
header field name value cr lf

header
~
~ ~
~ lines

header field name value cr lf

cr lf

~
~ entity body ~
~ body
 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
HTTP/1.0 HTTP/1.1
 GET  GET, POST, HEAD
 Request an object from  PUT
server  Uploads file in entity
 POST body to path specified in
 Upload information URL field
using forms  DELETE
 HEAD  Deletes file specified in
 Asks server to leave the URL field
requested object out of
response
status line
(protocol
status code HTTP/1.1 200 OK\r\n
status phrase) Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n
Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 17:00:02
GMT\r\n
header ETag: "17dc6-a5c-bf716880"\r\n
lines Accept-Ranges: bytes\r\n
Content-Length: 2652\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html; charset=ISO-8859-
1\r\n
\r\n
data, e.g., data data data data data ...
requested
HTML file
 version sp Status code sp phrase cr lf status
line
header field name: value cr lf

header
~
~ ~
~ lines

header field name value cr lf

cr lf

~
~ entity body ~
~ body
 200 OK
 Request succeeded, requested object later in this
message
 301 Moved Permanently
 Requested object moved, new location specified later
in this message
 400 Bad Request
 Request message not understood by server
 404 Not Found
 Requested document not found on this server
 505 HTTP version Not Supported
 Requested protocol is not supported by the server
Many web sites use cookies  Example
Four Components:
1. Cookie header line of
HTTP response
message
2. Cookie header line in
next HTTP request
message
3. Cookie file kept on
user’s host, managed
by user’s browser
4. Back-end database at
web site
 Susan always access
Internet from the same PC
 Visits specific e-commerce
site for first time
 When initial HTTP requests
arrives at site, site creates:
▪ Unique ID
▪ Entry in backend database
for ID
 client server

ebay 8734
usual http request msg Amazon server
cookie file creates ID
usual http response 1678 for user create backend
set-cookie: 1678
ebay 8734 entry database
amazon 1678
usual http request msg
cookie: 1678 cookie- access
specific
usual http response msg action

one week later:

access
ebay 8734 usual http request msg
amazon 1678 cookie: 1678 cookie-
specific
usual http response msg action
 What cookies can be
used for
 Authorization
 Shopping carts
 Recommendations  Cookies and privacy
 User session state (web e-  Cookies permit sites to learn
mail) a lot about you
 How to keep “state”  You may supply name and
e-mail to sites
 Protocol endpoints:
maintain state at
sender/receiver over
multiple transactions
 Cookies: http messages
carry state
 Goal: satisfy client
requests without
involving origin server
proxy
 User sets browser: web server
accesses via cache client
origin
 Browser sends all HTTP server
requests to cache
 Object in cache: cache
returns object
 Else cache requests
object from origin server, client origin
then returns object to server
client
 Cache acts as both  Why web caching?
client and server
 Server for original
requesting client
 Client to origin server
 Typically cache is
installed by ISP
 Reduce response time
for client request
 Reduce traffic on an
institution’s access link
 Internet dense with
caches: enables “poor”
content providers to
effectively deliver
content
 Assumptions origin
 Avg. object size: 100K bits servers
public
 Avg. request rate from
Internet
browsers to origin servers:
15/sec
 Avg. data rate to browsers:
1.50Mbps
1.54 Mbps
 RTT from institutional router access link
to any origin server: 2 sec
 Access link rate: 1.54Mbps institutional
network
 Consequences 1 Gbps LAN
 LAN utilization: 15%
 Access link utilization = 99%
 Total delay= Internet delay+
access delay + LAN delay
 Assumptions origin
 Avg. object size: 100K bits servers
 Avg. request rate from public
browsers to origin servers: Internet
15/sec
 Avg. data rate to browsers:
1.50Mbps
 RTT from institutional router to 1.54 Mbps
154 Mbps
any origin server: 2 sec access link
 Access link rate: 154Mbps institutional
 Consequences network
1 Gbps LAN
 LAN utilization: 15%
 Access link utilization = 9.9%
 Total delay= Internet delay+
access delay + LAN delay
Cost: Increased Access Link Speed (Not Cheap!)
 Assumptions origin
 Avg. object size: 100K bits servers
 Avg. request rate from public
browsers to origin servers: Internet
15/sec
 Avg. data rate to browsers:
1.50Mbps
 RTT from institutional router to 1.54 Mbps
any origin server: 2 sec access link
 Access link rate: 1.54Mbps institutional
 Consequences network
1 Gbps LAN
 LAN Utilization: 15%
 Access link utilization, total local web
delay = ? cache

Cost: Web Cache(Cheap!)

 Suppose cache hit rate is
0.4
 40% requests satisfied at
cache, 60% requests
satisfied at origin
 Access link utilization
 60% of requests use access
link
 Data rate to browsers
over access link =
0.6*1.50Mbps=0.9Mbps
 Utilization=0.9/1.54=0.58
 Total delay
 0.6*(delay from origin
servers)+0.4*(delay when
satisfied at cache)
 0.6*(2.01)+0.4*(msec)
 ~1.2msec
 Less than with 1.54Mbps
link
 client server
 Goal: don’t send object if HTTP request msg
cache has up-to-date If-modified-since: <date> object
cached version not
modified
 No object transmission delay HTTP response
before
 Lower link utilization HTTP/1.0
304 Not Modified
<date>
 Cache: specify date of
cached copy in HTTP
request
 If-modified-since:<date> HTTP request msg
 Server: response contains If-modified-since: <date> object
no object if cached copy is modified
HTTP response after
up-to-date: HTTP/1.0 304 <date>
HTTP/1.0 200 OK
Not Modified <data>