E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
1
EE 586 Communication andSwitching Networks
Lecture 6
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-2
Chapter 2: outline
Syllabus for this chapter
2.1 Principles
2.2 Web and HTTP
2.5 DNS
2.6 P2P applications
Socket Programming
underline_base
(modified by Cheung for EE586; based on K&R original)
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-3
access_point_stylized_small
antenna_radiation_stylized
cell_tower_radiation_gray
access_point_stylized_gray_small
access_point_stylized_gray_small
desktop_computer_stylized_medium
desktop_computer_stylized_medium
desktop_computer_stylized_medium
desktop_computer_stylized_medium
car_icon_small
iphone_stylized_small
antenna_radiation_stylized
antenna_stylized
laptop_keyboard
screen
antenna_stylized
laptop_keyboard
screen
antenna_stylized
laptop_keyboard
screen
desktop_computer_stylized_medium
antenna_stylized
laptop_keyboard
screen
underline_base
Creating a network app
write programs that:
run on (different) end systems
communicate over network
e.g., web server softwarecommunicates with browsersoftware
no need to write software fornetwork-core devices
network-core devices do notrun user applications
applications on end systemsallows for rapid appdevelopment, propagation
application
transport
network
data link
physical
application
transport
network
data link
physical
application
transport
network
data link
physical
(modified by Cheung for EE586; based on K&R original)
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Application architectures
1.Client-server
2.Peer-to-peer (P2P)
3.Hybrid of client-server and P2P
The application architecture is designed by theapplication developer and dictates how theapplication is structured over the various endsystems.
underline_base
(modified by Cheung for EE586; based on K&R original)
2-4
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-5
access_point_stylized_small
antenna_radiation_stylized
cell_tower_radiation_gray
access_point_stylized_gray_small
access_point_stylized_gray_small
desktop_computer_stylized_medium
desktop_computer_stylized_medium
desktop_computer_stylized_medium
desktop_computer_stylized_medium
car_icon_small
iphone_stylized_small
antenna_radiation_stylized
antenna_stylized
laptop_keyboard
screen
antenna_stylized
laptop_keyboard
screen
antenna_stylized
laptop_keyboard
screen
desktop_computer_stylized_medium
antenna_stylized
laptop_keyboard
screen
Client-server architecture
server:
always-on host
permanent IP address
data centers for scaling
clients:
communicate with server
may be intermittentlyconnected
may have dynamic IPaddresses
do not communicate directlywith each other
underline_base
client/server
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-6
access_point_stylized_small
antenna_radiation_stylized
cell_tower_radiation_gray
access_point_stylized_gray_small
access_point_stylized_gray_small
desktop_computer_stylized_medium
desktop_computer_stylized_medium
desktop_computer_stylized_medium
desktop_computer_stylized_medium
car_icon_small
iphone_stylized_small
antenna_radiation_stylized
antenna_stylized
laptop_keyboard
screen
antenna_stylized
laptop_keyboard
screen
antenna_stylized
laptop_keyboard
screen
desktop_computer_stylized_medium
antenna_stylized
laptop_keyboard
screen
P2P architecture
no always-on server
arbitrary end systemsdirectly communicate
peers request service fromother peers, provide servicein return to other peers
self scalability – newpeers bring new servicecapacity, as well as newservice demands
peers are intermittentlyconnected and change IPaddresses
complex management
underline_base
peer-peer
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-7
Processes communicating
process: program runningwithin a host
within same host,  processescommunicate using  inter-process communication(defined by OS)
processes in different hostscommunicate by exchangingmessages
client process: process thatinitiates communication
server process: process thatwaits to be contacted
aside: applications with P2Parchitectures have clientprocesses & serverprocesses
underline_base
clients, servers
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-8
underline_base
Addressing processes
to receive messages,process must have identifier
host device has unique 32-bit IPv4 or 128-bit IPv6address
Q: does  IP address of hoston which process runssuffice for identifying theprocess?
identifier includes both IPaddress and port numbersassociated with process onhost.
example port numbers:
HTTP server: 80
mail server: 25
to send HTTP message togaia.cs.umass.edu webserver:
IP address: 128.119.245.12
port number: 80
more shortly…
A: no, many processescan be running on samehost
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
underline_base
Applications rely on transport services
application: supporting networkapplications (message)
FTP, SMTP, HTTP, Your own
transport: process-process datatransfer (segment)
TCP, UDP
network: routing of (datagrams)from source to destination
IP, routing protocols
link: (frame) data transfer betweenneighboring  network elements
Ethernet, 802.11 (WiFi)
physical: (bits) on the wire
application
transport
network
link
physical
2-9
(modified by Cheung for EE586; based on K&R original)
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-10
What transport service does a process need?
data integrity
some apps (e.g., file transfer,web transactions) require100% reliable data transfer
other apps (e.g., audio) cantolerate some loss
timing
some apps (e.g., Internettelephony, interactivegames) require low delayto be effective
throughput
some apps (e.g.,multimedia) requireminimum amount ofthroughput to beeffective
other apps (elastic apps)make use of whateverthroughput they get
underline_base
security
encryption, data integrity,
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-11
Internet transport protocols services
TCP service (stream):
reliable transport betweensending and receivingprocess
flow control: sender wontoverwhelm receiver
congestion control: throttlesender when networkoverloaded
does not provide: timing,minimum throughputguarantee, security
connection-oriented: setuprequired between client andserver processes
UDP service (datagram):
unreliable best-effort datatransfer between sendingand receiving process
Q: why bother?  Why isthere a UDP?
underline_base
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-12
underline_base
Internet apps:  application, transport protocols
application
e-mail
remote terminal access
Web
file transfer
streaming multimedia
Internet telephony
application
layer protocol
SMTP [RFC 2821]
Telnet [RFC 854]
HTTP [RFC 2616]
FTP [RFC 959]
HTTP (e.g., YouTube),RTP [RFC 1889]
SIP, RTP, proprietary
(e.g., Skype)
underlying
transport protocol
TCP
TCP
TCP
TCP
TCP or UDP
TCP or UDP
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-13
Sockets
process sends/receives messages to/from its socket
socket is a data structure analogous to door
sending process shoves message out door
sending process relies on transport infrastructure onother side of door to deliver message to socket atreceiving process
underline_base
Internet
controlled
by OS
controlled by
app developer
transport
application
physical
link
network
process
transport
application
physical
link
network
process
socket
desktop_computer_stylized_medium
desktop_computer_stylized_medium
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-14
Web and HTTP
First, a review as if you do not already know …
web page consists of objects
object can be HTML file, JPEG image, Java applet,audio file,…
web page consists of base HTML-file whichincludes several referenced objects
each object is addressable by a URL, e.g.,
www.someschool.edu/someDept/pic.gif
host name
path name
underline_base
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-15
HTTP overview
HTTP: hypertexttransfer protocol
Webs application layerprotocol
client/server model
client: browser thatrequests, receives,(using HTTP protocol)and displays Webobjects
server: Web serversends (using HTTPprotocol) objects inresponse to requests
PC running
Firefox browser
server
running
Apache Web
server
iphone running
Safari browser
HTTP request
HTTP response
underline_base
HTTP request
HTTP response
iphone_stylized_small
desktop_computer_stylized_medium
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-16
HTTP overview (continued)
uses TCP:
client initiates TCPconnection (createssocket) to server,  port 80
server accepts TCPconnection from client
HTTP messages(application-layer protocolmessages) exchangedbetween browser (HTTPclient) and Web server(HTTP server)
TCP connection closed
HTTP is stateless
server maintains noinformation aboutpast client requests
protocols that maintainstate are complex!
past history (state) mustbe maintained
if server/client crashes,their views of statemay be inconsistent, mustbe reconciled
aside
underline_base
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-17
HTTP connections
non-persistent HTTP
at most one objectsent over TCPconnection
connection thenclosed
downloading multipleobjects requiredmultiple connections
persistent HTTP
multiple objects canbe sent over singleTCP connectionbetween client, server
underline_base
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-18
underline_base
Non-persistent HTTP: response time
RTT (Round-Trip Time): timefor a small packet to travelfrom client to server and back
HTTP response time:
one RTT to initiate TCPconnection
one RTT for HTTP requestand first few bytes of HTTPresponse to return
file transmission time
non-persistent HTTPresponse time =
   2RTT+ file transmissiontime
time to
transmit
file
initiate TCP
connection
RTT
request
file
RTT
file
received
time
time
desktop_computer_stylized_medium
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-19
Persistent HTTP
non-persistent HTTP issues:
requires 2 RTTs per object
OS overhead for each TCPconnection
browsers often openparallel TCP connectionsto fetch referenced objects– one client may consumemuch of the server’sresource
persistent  HTTP:
server leaves connectionopen after sendingresponse
subsequent HTTPmessages  between sameclient/server sent overopen connection
client sends requests assoon as it encounters areferenced object
as little as one RTT for allthe referenced objects
underline_base
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-20
underline_base
HTTP request message
two types of HTTP messages: requestresponse
HTTP request message:
ASCII or UNICODE (human-readable format)
request line (GET,POST, HEADcommands)
header
 lines
carriage return, line feed atstart of line indicates
end of header lines
GET /index.html HTTP/1.1\r\n
Host: www-net.cs.umass.edu\r\n
User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
Keep-Alive: 115\r\n
Connection: keep-alive\r\n
\r\n
carriage return character
line-feed character
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-21
underline_base
Method types
HTTP/1.0:
GET
POST
web page oftenincludes form input
input is uploaded toserver in entity body
HEAD
asks server to leaverequested object outof response
HTTP/1.1:
GET, POST, HEAD
PUT
uploads file in entitybody to path specifiedin URL field
DELETE
deletes file specified inthe URL field
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-22
underline_base
HTTP response message
status line
(protocol
status code
status phrase)
header
 lines
data, e.g.,
requested
HTML file
HTTP/1.1 200 OK\r\n
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:02GMT\r\n
ETag: "17dc6-a5c-bf716880"\r\n
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 data data data data ...
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-23
underline_base
HTTP response status codes
200 OK
request succeeded, requested object later in this msg
301 Moved Permanently
requested object moved, new location specified later in this msg(Location:)
400 Bad Request
request msg not understood by server
404 Not Found
requested document not found on this server
505 HTTP Version Not Supported
status code appears in 1st line in server-to-client response message.
some sample codes:
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-24
User-server state: cookies
Many Web sites use cookies
four components:
1) cookie header line ofHTTP response message
2) cookie header line in nextHTTP request message
3) cookie file kept on usershost, managed by usersbrowser
4) back-end database at Website
example:
Susan always access Internetfrom PC
visits specific e-commercesite for first time
when initial HTTP requestsarrives at site, site creates:
unique ID
entry in backenddatabase for ID
underline_base
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
underline_base
Cookies: keeping state (cont.)
client
server
usual http response msg
usual http response msg
cookie file
one week later:
usual http request msg
cookie: 1678
cookie-
specific
action
access
ebay 8734
usual http request msg
Amazon server
creates ID
1678 for user
create
    entry
usual http response
set-cookie: 1678
ebay 8734
amazon 1678
usual http request msg
cookie: 1678
cookie-
specific
action
access
ebay 8734
amazon 1678
backend
database
desktop_computer_stylized_medium
2-25
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-26
underline_base
Cookies (continued)
how cookies are used:
authorization
shopping carts
recommendations
user session state (Webe-mail)
cookies and privacy:
cookies permit sites tolearn a lot about you
you may supply name ande-mail to sites
aside
how to keep state:
protocol endpoints: maintain state atsender/receiver over multipletransactions
cookies: http messages carry state
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
Web caches (proxy server)
2-27
desktop_computer_stylized_medium
desktop_computer_stylized_medium
underline_base
user sets browser: Webaccesses via  cache
browser sends all HTTPrequests to cache
object in cache: cachereturns object
else cache requestsobject from originserver, then returnsobject to client
goal: satisfy client request without involving origin server
client
proxy
server
client
HTTP request
HTTP response
HTTP request
HTTP request
origin
server
origin
server
HTTP response
HTTP response
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-28
underline_base
More about Web caching
cache acts as bothclient and server
server for originalrequesting client
client to origin server
typically cache isinstalled by ISP(university, company,residential ISP)
why Web caching?
reduce response timefor client request
reduce traffic on aninstitutions access link
Internet dense withcaches: enables poorcontent providers toeffectively delivercontent (so too doesP2P file sharing)
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-29
underline_base
Caching example:
origin
servers
public
 Internet
institutional
network
1 Gbps LAN
1.54 Mbps
access link
assumptions:
LAN: 1 Gbps
access link rate: 1.54 Mbps
RTT from institutional routerto any origin server: 2 sec
avg object size: 100K bits
avg request rate :15/sec
avg data rate : 1.50 Mbps
consequences:
LAN utilization: 0.15%
access link utilization = 97%
total delay   = Internet delay +access delay + LAN delay
     =  2 sec + minutes + usecs
desktop_computer_stylized_medium
desktop_computer_stylized_medium
desktop_computer_stylized_medium
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
assumptions:
LAN: 1 Gbps
access link rate: 1.54 Mbps
RTT from institutional routerto any origin server: 2 sec
avg object size: 100K bits
avg request rate :15/sec
avg data rate : 1.50 Mbps
consequences:
LAN utilization: 0.15%
access link utilization = 97%
total delay   = Internet delay +access delay + LAN delay
     =  2 sec + minutes + usecs
2-30
underline_base
Caching example: fatter access link
origin
servers
1.54 Mbps
access link
154 Mbps
154 Mbps
msecs
Cost: increased access linkspeed (not cheap!)
public
 Internet
institutional
network
1 Gbps LAN
desktop_computer_stylized_medium
desktop_computer_stylized_medium
desktop_computer_stylized_medium
<1%
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
institutional
network
1 Gbps LAN
desktop_computer_stylized_medium
desktop_computer_stylized_medium
desktop_computer_stylized_medium
2-31
underline_base
Caching example: install local cache
origin
servers
1.54 Mbps
access link
local web
cache
?
?
How to compute link
utilization, delay?
Cost: web cache (cheap!)
public
 Internet
assumptions:
LAN: 1 Gbps
access link rate: 1.54 Mbps
RTT from institutional routerto any origin server: 2 sec
avg object size: 100K bits
avg request rate :15/sec
avg data rate : 1.50 Mbps
consequences:
LAN utilization =
access link utilization =
E l e c t r i c a l    &   C o m p u t e r
Department of
Electrical & Computer Engineering
2-32
underline_base
Caching example: install local cache
Calculating access linkutilization, delay with cache:
suppose cache hit rate is 0.4
40% requests satisfied at cache,60% requests satisfied at origin
 
origin
servers
1.54 Mbps
access link
access link utilization:
60% of requests use access link
data rate to browsers over accesslink = 0.6*1.50 Mbps = .9 Mbps
utilization = 0.9/1.54 = .58
total delay
= 0.6 * (delay from origin servers) +0.4* (delay when satisfied at cache)
= 0.6 (2.01) + 0.4 (~msecs)
= ~ 1.2 secs
less than with 154 Mbps link (andcheaper too!)
 
public
 Internet
institutional
network
1 Gbps LAN
desktop_computer_stylized_medium
desktop_computer_stylized_medium
desktop_computer_stylized_medium
local web
cache