ECE/CS 372 – introduction to computer networks
Lecture 5
Announcements:
 Lab1 is due today
 Lab2 is posted and is due next Tuesday
Acknowledgement: slides drawn heavily from Kurose & Ross
Chapter 2, slide: 1
Chapter 1: recap
By now, you should know:
 the Internet and its components
 circuit-switching networks vs. packet-switching networks
 different network access technologies
 the three Tiers 1, 2, and 3
 layered architecture of networks
 types of delays and throughput analysis
Chapter 2, slide: 2
Chapter 2: Application Layer
Our goals:
 aspects of network
application protocols
 transport-layer
service models
 client-server paradigm
 peer-to-peer paradigm
 learn about protocols
by examining popular
application-level
protocol: HTTP
Chapter 2, slide: 3
Some network apps
 e-mail
 voice over IP
 web
 real-time video
 instant messaging
 remote login
conferencing
 grid computing
 P2P file sharing
 multi-user network
games
 streaming stored video
clips
Chapter 2, slide: 4
Creating a network app
write programs that



run on (different) end
systems
communicate over network
e.g., web server software
communicates with browser
software
little software written for
devices in network core

application
transport
network
data link
physical
network core devices do
not run user applications
application
transport
network
data link
physical
application
transport
network
data link
physical
Chapter 2, slide: 5
Chapter 2: Application layer
 Principles of network applications
 app architectures
 app requirements
 Web and HTTP
 P2P file sharing
Chapter 2, slide: 6
Application architectures
There are 3 types of architectures:
 Client-server
 Peer-to-peer (P2P)
 Hybrid of client-server and P2P
Chapter 2, slide: 7
Client-server architecture
server:



always-on
fixed/known IP address
serves many clients at same time
clients:


client/server


communicate with server only
may be intermittently connected
may have dynamic IP addresses
do not communicate directly with
each other
E.g., of client-server archit.:

Google, Amazon, MySpace,
YouTube,
Chapter 2, slide: 8
Pure P2P architecture
 no always-on server
 arbitrary end systems
directly communicate
 peers are intermittently
connected and change IP
addresses
 example: BitTorrent
peer-peer
Pros and cons:
 scalable and distributive
 difficult to manage
 not secure
Chapter 2, slide: 9
Hybrid of client-server and P2P
Skype
 voice-over-IP P2P application
 centralized server: finding address of remote party
 client-client connection: direct (not through server)
Instant messaging
 chatting between two users is P2P
 centralized service: client presence location
• user registers its IP address with central server
when it comes online
• user contacts central server to find IP addresses
of buddies
Chapter 2, slide: 10
Processes communicating
Process: is program
running within a host.
 processes in same host
communicate using
inter-process
communication
(managed by OS).
 processes in different
hosts communicate by
exchanging messages
Client process: process
that initiates
communication
Server process: process
that waits to be
contacted
 Note: applications with
P2P architectures have
client processes &
server processes
Chapter 2, slide: 11
Sockets
 process sends/receives
messages to/from its
socket
 socket analogous to door


sending process shoves
message out door
sending process relies on
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
 App Program Interface (API): (1) choice of transport
protocol; (2) ability to fix a few parameters
Chapter 2, slide: 12
Addressing processes
 to receive messages,
process must have
identifier
 host device has unique
32-bit IP address
 Q: does IP address of
host on which process
runs suffice to identify
the process?
 A: No, many processes
can be running on same
host
 identifier consists of:
 IP address (host)
 port numbers (process)
 Example port numbers:
 HTTP server: 80
 Mail server: 25
 to send HTTP message
to gaia.cs.umass.edu web
server:


IP address: 128.119.245.12
Port number: 80
 more shortly…
Chapter 2, slide: 13
App-layer protocol defines
Question: why do we need an “App-layer protocol” ?
 Types of messages
exchanged,

e.g., request, response
 Message syntax:
 what fields in messages &
how fields are delineated
 Message semantics
 meaning of information in
fields
Public-domain protocols:
 defined in RFCs
 allows for
interoperability
 e.g., HTTP, SMTP
Proprietary protocols:
 e.g., Skype
 Rules for when and how
processes send &
respond to messages
Chapter 2, slide: 14
What transport service does an app need?
Data loss/reliability
 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
Security
 what about it !!!
Chapter 2, slide: 15
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
Chapter 2, slide: 16
What services do Internet transport
protocols provide?
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
Q: why bother? Why is
there a UDP?
Chapter 2, slide: 17
Internet apps: application, transport protocols
Application
e-mail
remote terminal access
Web
file transfer
streaming multimedia
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., Vonage, Skype)
TCP
TCP
TCP
TCP
TCP or UDP
typically UDP
Chapter 2, slide: 18
Chapter 2: Application layer
 Principles of network applications
 app architectures
 app requirements
 Web and HTTP
 P2P file sharing
Chapter 2, slide: 19
Web and HTTP
First some terminologies:
 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 (Uniform Resource Locator):
www.someschool.edu/someDept/pic.gif
host name
path name
Chapter 2, slide: 20
HTTP overview: app architecture
HTTP: hypertext
transfer protocol
 Web’s appl-layer protocol
 client/server model


PC running
Explorer
client: browser that
requests, receives,
“displays” Web objects
server: Web server
sends objects in
response to requests
 HTTP 1.0: RFC 1945
Server
running
Apache Web
server
Mac running
Navigator
 HTTP 1.1: RFC 2068
Chapter 2, slide: 21
HTTP overview (continued)
Uses TCP:
 client initiates TCP
connection (creates socket)
to server, port 80
 server accepts TCP
connection from client
 HTTP messages exchanged
between browser (HTTP
client) and Web server
(HTTP server)
 TCP connection closed
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
Chapter 2, slide: 22
HTTP connections
Nonpersistent HTTP
 At most one object is
sent over a TCP
connection.
 HTTP/1.0 uses
nonpersistent HTTP
Persistent HTTP
 Multiple objects can
be sent over single
TCP connection
between client and
server.
 HTTP/1.1 uses
persistent connections
in default mode
Chapter 2, slide: 23
Nonpersistent HTTP
(contains text,
Suppose user enters URL
references to 10
www.someSchool.edu/someDepartment/home.index
jpeg images)
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
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
time
Chapter 2, slide: 24
Nonpersistent HTTP (cont.)
4. HTTP server closes TCP
5. HTTP client receives response
connection.
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
Chapter 2, slide: 25
Non-Persistent HTTP: Response time
Definition of RTT (round
trip time): time to send
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 + transmit time
initiate TCP
connection
RTT
request
file
RTT
file
received
time
time to
transmit
file
time
Chapter 2, slide: 26
Non-Persistent HTTP: issues
Nonpersistent HTTP:
 Name some issues??
 requires 2 RTTs per
object
 E.g., a 10-object page
needs ~ 20 RTTs
 Open/close TCP
connection for each
object => OS overhead
initiate TCP
connection
RTT
request
file
RTT
file
received
time
time to
transmit
file
time
 Any ideas for
improvement?
Chapter 2, slide: 27
Persistent HTTP
Persistent HTTP
 server leaves
connection open after
sending response
 subsequent HTTP
messages between
same client/server sent
over open connection
 reduces response time
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
Chapter 2, slide: 28
Web and HTTP: Review Question
 A HTTP request consists of:



1 basic html object
2 referenced JPEG objects
Each object is of size = 106bits
 RTT = 1 second
 Transmission rate = 1Mbps
 Consider transmission delay of
objects only
 Question: how long it takes
to receive the entire page:
a)
b)
c)
Non-persistent connection
Persistent without pipelining
Persistent with pipelining
initiate TCP
connection
RTT
request
file
RTT
file
received
time
time to
transmit
file
time
Chapter 2, slide: 29
Web and HTTP: Review Question
 A HTTP request consists of:



1 basic html object
2 referenced JPEG objects
Each object is of size = 106bits
 RTT = 1 second
 Transmission rate = 1Mbps
 Consider transmission delay of
objects only
initiate TCP
connection
RTT
request
file
time to
transmit
file
RTT
 Answer: (transmit time = 1 sec)
file
a) 3+3+3=9 sec
received
(initiate + request + transmit) for each of all 3
b) 1+2+2+2=7 sec
time
time
initiate + (request + transmit) for each of all 3
c) 1+2+3=6 sec
initiate + (request + transmit for basic) + (one
request for 2 + two transmits, one for each of the 2 objects)
Chapter 2, slide: 30
ECE/CS 372 – introduction to computer networks
Lecture 6
Announcements:
 Lab2 is due next Tuesday
Acknowledgement: slides drawn heavily from Kurose & Ross
Chapter 2, slide: 31
Web caches (or proxy server)
Goal: satisfy client request without involving origin server
 If page is needed,
origin
server
browser requests it
from the Web cache
 Q: what if object not in
client
Proxy
server
cache??
cache requests object
from origin server, then
returns object to client
client
origin
server
Chapter 2, slide: 32
More about Web caching
 cache acts as both
client and server
Why Web caching?
 reduce response time
for client request
 typically cache is
installed by ISP
(university, company,
residential ISP)
 reduce traffic on an
institution’s access link.
Chapter 2, slide: 33
Caching example
origin
servers
Assumptions
 avg. object size = 0.1x106bits
 avg. request rate from
institution to origin servers =
10/sec
 Internet delay = 2 sec
Consequences
 utilization on LAN = 10%
(LAN: local area network)
 utilization on access link = 100%
 total delay = Internet delay +
access delay + LAN delay
= 2 sec + sec + milliseconds
unacceptable delay!
public
Internet
1 Mbps
access link
institutional
network
10 Mbps LAN
institutional
cache
Chapter 2, slide: 34
Caching example (cont)
origin
servers
possible solution
 increase bandwidth of access
link to, say, 10 Mbps
public
Internet
consequence
 utilization on LAN = 10%
10 Mbps
access link
 utilization on access link = 10%
 Total delay
= Internet delay +
access delay + LAN delay
= 2 sec + msecs + msecs
 often a costly upgrade
 total delay still dominated by
Internet delay
institutional
network
10 Mbps LAN
institutional
cache
Chapter 2, slide: 35
Caching example (cont)
origin
servers
2nd possible sol: web cache
 suppose hit rate is 0.4
(typically, between 0.3 & 0.7)
consequence
public
Internet
 40% requests will be satisfied
almost immediately and 60%
requests satisfied by origin server
 utilization of access link reduced by
40%, giving an access delay in the
order of milliseconds; say 10 millisec
 Total delay = 0.4x(0.1) (LAN) +
1 Mbps
access link
institutional
network
10 Mbps LAN
institutional
cache
0.6x(0.1+0.1+2) (LAN + access + Internet) = (about) 1.3 second
 total avg delay reduced by about 40%
Chapter 2, slide: 36
Web cache (cont)
Advantages are obvious:
 Reduce response time
 Reduce internet traffic
Any problems with caches??
 Local cache copies of web pages
may not be up-to-date??
 What do we do then?
Solution
 Upon receiving a web
request, a cache must
consult origin server to
check whether the
requested page is up-todate
 Conditional GET method


What:
Sent by cache to origin
server: check page status
When:
For each new request:
client checks with cache
Chapter 2, slide: 37
Conditional GET
 Goal: don’t send object if cache
has up-to-date version
 How: cache specifies date of
cached copy in HTTP request
If-modified-since: <date>
cache
server
HTTP request msg
If-modifiedsince: <date>
HTTP response
object
not
modified
HTTP/1.0
304 Not Modified
 Server: response contains no
object if cached copy is up-todate:
HTTP/1.0 304 Not Modified
HTTP request msg
If-modifiedsince: <date>
HTTP response
object
modified
HTTP/1.0 200 OK
<data>
Chapter 2, slide: 38
Chapter 2: Application layer
 Principles of network applications
 app architectures
 app requirements
 Web and HTTP
 P2P file sharing
Chapter 2, slide: 39
File sharing approaches
There are 2 approaches
Bob
server
peers
 Centralized:
Client-server architecture
Alice
 Distributed:
P2P architecture
(e.g., BitTorrent)
server
obtain list
of peers
trading
chunks
peer
Chapter 2, slide: 40
File sharing: P2P vs. client-server architectures
Client-Server
P2P
Single point of failure
Fault-tolerant
Scalability
Not scalable
Scalable
Security
More secure
Less secure
Bottleneck
Better
Robustness to failure
Performance
Chapter 2, slide: 41
Comparing Client-Server, P2P architectures
Question : What is the file distribution time:
from one server to N hosts?
us: server upload
bandwidth
Server
us
File, size F
dN
uN
u1
d1
u2
ui: client/peer i
upload bandwidth
d2
di: client/peer i
download bandwidth
Network (with
abundant bandwidth)
Chapter 2, slide: 42
Client-server: file distribution time
 server sequentially
sends N copies:

NF/us time
 client i takes F/di
time to download
Time to distribute F
to N clients using = dcs
client/server approach
Server
F
us
dN
u1 d1 u2
d2
Network (with
abundant bandwidth)
uN
> max { NF/us, F/min(d
i) }
i
increases linearly in N
(for large N)
Chapter 2, slide: 43
Client-server: file distribution time
dcs
= max { NF/us, F/min(d
i) }
i
 We now show that the distribution time is
actually equal to max{NF/us, F/min(di) }
 See board notes
Chapter 2, slide: 44
P2P: file distribution time
 server must send one
copy: F/us time
 client i takes F/di time
to download
Server
F
us
dN
 NF bits must be downloaded
u1 d1 u2
d2
Network (with
abundant bandwidth)
uN
- NF bits must be uploaded
- Fastest possible upload rate
(assuming all nodes sending file chunks to
same peer) is:
us + Sui
i=1,N
dP2P > max { F/us, F/min(di) , NF/(us + Sui) }
i=1,N
Chapter 2, slide: 45
Comparing Client-server, P2P architectures
Minimum Distribution Time
3.5
P2P
Client-Server
3
2.5
2
1.5
1
0.5
0
0
5
10
15
20
25
30
35
N
Chapter 2, slide: 46
Chapter 2: Summary
We covered general concepts, like:
 application architectures
 client-server, P2P
 application service requirements:
 reliability, bandwidth, delay
 Web and HTTP
 Non-Persistent, persistent, web cache
 Distribution time

Client-server, P2P
Chapter 2, slide: 47