Professional Documents
Culture Documents
Chapter 2: outline
2.1 principles of network
applications
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
2.5 DNS
HTTP
FTP
SMTP / POP3 / IMAP
DNS
creating network
applications
socket API
e-mail
web
text messaging
remote login
P2P file sharing
multi-user network games
streaming stored video
(YouTube, Hulu, Netflix)
application
transport
network
data link
physical
application
transport
network
data link
physical
application
transport
network
data link
physical
Application architectures
possible structure of applications:
client-server
peer-to-peer (P2P)
Client-server architecture
server:
always-on host
permanent IP address
data centers for scaling
clients:
client/server
P2P architecture
no always-on server
arbitrary end systems
directly communicate
peers request service from
other peers, provide service
in return to other peers
self scalability new
peers bring new service
capacity, as well as new
service demands
peers are intermittently
connected and change IP
addresses
complex management
peer-peer
Processes communicating
process: program running
within a host
clients, servers
client process: process that
initiates communication
server process: process that
waits to be contacted
Sockets
process
socket
application
process
transport
transport
network
network
link
physical
Internet
link
controlled by
app developer
controlled
by OS
physical
Addressing processes
to receive messages,
process must have identifier
host device has unique 32bit IP address
Q: does IP address of host
on which process runs
suffice for identifying the
process?
A: no, many processes
can be running on same
host
more shortly
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
rules for when and how
processes send & respond
to messages
open protocols:
defined in RFCs
allows for interoperability
e.g., HTTP, SMTP
proprietary protocols:
e.g., Skype
throughput
some apps (e.g.,
multimedia) require
minimum amount of
throughput to be
effective
other apps (elastic apps)
make use of whatever
throughput they get
security
encryption, data integrity,
data loss
throughput
file transfer
e-mail
Web documents
real-time audio/video
no loss
no loss
no loss
loss-tolerant
stored audio/video
interactive games
text messaging
loss-tolerant
loss-tolerant
no loss
elastic
no
elastic
no
elastic
no
audio: 5kbps-1Mbps yes, 100s
video:10kbps-5Mbps msec
same as above
few kbps up
yes, few secs
elastic
yes, 100s
msec
yes and no
time sensitive
UDP service:
application
layer protocol
underlying
transport protocol
TCP
TCP
TCP
TCP
TCP or UDP
TCP or UDP
Securing TCP
TCP & UDP
no encryption
cleartext passwds sent
into socket traverse
Internet in cleartext
SSL
provides encrypted
TCP connection
data integrity
end-point
authentication
Chapter 2: outline
2.1 principles of network
applications
app architectures
app requirements
2.5 DNS
path name
HTTP overview
HTTP: hypertext
transfer protocol
PC running
Firefox browser
server
running
Apache Web
server
iphone running
Safari browser
HTTP is stateless
server maintains no
information about
past client requests
aside
protocols that maintain
state are complex!
HTTP connections
non-persistent HTTP
at most one object
sent over TCP
connection
connection then
closed
downloading multiple
objects required
multiple connections
persistent HTTP
multiple objects can
be sent over single
TCP connection
between client, server
Non-persistent HTTP
suppose user enters URL:
www.someSchool.edu/someDepartment/home.index
(contains text,
references to 10
jpeg images)
time
Application Layer 2-23
time
initiate TCP
connection
RTT
request
file
time to
transmit
file
RTT
file
received
time
time
Persistent HTTP
non-persistent HTTP issues:
persistent HTTP:
request line
(GET, POST,
HEAD commands)
header
lines
carriage return,
line feed at start
of line indicates
end of header lines
sp
URL
sp
value
version
cr
cr
value
cr
request
line
header
lines
~
~
header field name
lf
lf
~
~
~
~
cr
lf
lf
entity body
~
~
body
URL method:
Method types
HTTP/1.0:
GET
POST
HEAD
asks server to leave
requested object out
of response
HTTP/1.1:
header
lines
data, e.g.,
requested
HTML file
200 OK
request succeeded, requested object later in this msg
example:
Susan always access Internet
from 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
cookie file
ebay 8734
amazon 1678
server
usual http request msg
usual http response
set-cookie: 1678
usual http request msg
cookie: 1678
usual http response msg
Amazon server
creates ID
1678 for user create backend
entry database
cookiespecific
action
access
access
usual http request msg
cookie: 1678
usual http response msg
cookiespecific
action
Application Layer 2-35
Cookies (continued)
what cookies can be used
for:
authorization
shopping carts
recommendations
user session state (Web
e-mail)
aside
proxy
server
client
client
origin
server
origin
server
typically cache is
installed by ISP
(university, company,
residential ISP)
Caching example:
assumptions:
origin
servers
public
Internet
1.54 Mbps
access link
consequences:
problem!
LAN utilization: 15%
access link utilization = 99%
total delay = Internet delay + access
delay + LAN delay
= 2 sec + minutes + usecs
institutional
network
1 Gbps LAN
origin
servers
public
Internet
1.54 Mbps
access link
consequences:
institutional
network
154 Mbps
1 Gbps LAN
msecs
origin
servers
public
Internet
1.54 Mbps
access link
consequences:
utilization, delay?
institutional
network
1 Gbps LAN
local web
cache
origin
servers
link utilization:
1.54 Mbps
access link
total
delay
institutional
network
1 Gbps LAN
local web
cache
Conditional GET
server
client
HTTP response
HTTP/1.0
304 Not Modified
object
not
modified
before
<date>
HTTP response
HTTP/1.0 200 OK
object
modified
after
<date>
<data>
Application Layer 2-43
Chapter 2: outline
2.1 principles of network
applications
app architectures
app requirements
2.5 DNS
file transfer
FTP
client
user
at host
local file
system
FTP
server
remote file
system
FTP
client
FTP
server
Chapter 2: outline
2.1 principles of network
applications
app architectures
app requirements
2.5 DNS
Electronic mail
outgoing
message queue
user mailbox
user agents
mail servers
simple mail transfer
protocol: SMTP
User Agent
user
agent
mail
server
user
agent
SMTP
mail
server
user
agent
SMTP
SMTP
mail
server
user
agent
user
agent
user
agent
user
agent
mail
server
user
agent
SMTP
mail
server
user
agent
SMTP
SMTP
mail
server
user
agent
user
agent
user
agent
1 user
agent
2
mail
server
3
Alices mail server
user
agent
mail
server
4
6
5
Bobs mail server
Application Layer 2-52
220 hamburger.edu
HELO crepes.fr
250 Hello crepes.fr, pleased to meet you
MAIL FROM: <alice@crepes.fr>
250 alice@crepes.fr... Sender ok
RCPT TO: <bob@hamburger.edu>
250 bob@hamburger.edu ... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Do you like ketchup?
How about pickles?
.
250 Message accepted for delivery
QUIT
221 hamburger.edu closing connection
telnet servername 25
see 220 reply from server
enter HELO, MAIL FROM, RCPT TO, DATA, QUIT
commands
above lets you send email without using email client (reader)
HTTP: pull
SMTP: push
header
blank
line
body
commands!
Body: the message
ASCII characters only
Application Layer 2-56
SMTP
SMTP
mail access
protocol
user
agent
(e.g., POP,
IMAP)
senders mail
server
receivers mail
server
POP3 protocol
authorization phase
client commands:
user: declare username
pass: password
server responses
+OK
-ERR
S:
C:
S:
C:
S:
C:
S:
S:
S:
C:
S:
S:
C:
C:
S:
S:
C:
C:
S:
list
1 498
2 912
.
retr 1
<message 1 contents>
.
dele 1
retr 2
<message 1 contents>
.
dele 2
quit
+OK POP3 server signing off
on
IMAP
Chapter 2: outline
2.1 principles of network
applications
app architectures
app requirements
2.5 DNS
distributed database
implemented in hierarchy of
many name servers
application-layer protocol: hosts,
name servers communicate to
resolve names (address/name
translation)
note: core Internet function,
implemented as applicationlayer protocol
complexity at networks
edge
hostname to IP address
translation
host aliasing
canonical, alias names
A: doesnt scale!
e. NASA Mt View, CA
f. Internet Software C.
Palo Alto, CA (and 48 other
sites)
a. Verisign, Los Angeles CA
(5 other sites)
b. USC-ISI Marina del Rey, CA
l. ICANN Los Angeles, CA
(41 other sites)
g. US DoD Columbus,
OH (5 other sites)
13 root name
servers
worldwide
DNS name
resolution example
host at cis.poly.edu
wants IP address for
gaia.cs.umass.edu
iterated query:
contacted server
replies with name of
server to contact
the remaining queries
are iterative.
I dont know this
name, but ask this
server
requesting host
cis.poly.edu
gaia.cs.umass.edu
Application Layer 2-67
DNS name
resolution example
recursive query:
6
TLD DNS
server
8
authoritative DNS server
dns.cs.umass.edu
requesting host
cis.poly.edu
gaia.cs.umass.edu
Application Layer 2-68
DNS caching
DNS caching in order to improve the delay performance and to reduce
DNS caching
2
3
requesting host
cis.poly.edu
gaia.cs.umass.edu
Application Layer 2-70
DNS records
DNS: distributed db storing resource records (RR)that provide hostnameto-IP address mappings. Each DNS reply message carries one or more
resource records.
RR format: (name,
type=A
name is hostname
value is IP address
type=NS
name is domain (e.g.,
foo.com)
value is hostname of
authoritative name
server for this domain
(foo.com, dns.foo.com,
NS)is a Type NS record.
type=CNAME
name is alias name for some
canonical (the real) name
www.ibm.com is really
servereast.backup2.ibm.com
type=MX
value is name of mailserver
associated with name
Application Layer 2-72
msg header
identification
flags
# questions
# answer RRs
# authority RRs
# additional RRs
2 bytes
identification
flags
# questions
# answer RRs
# authority RRs
# additional RRs
RRs in response
to query
records for
authoritative servers
additional helpful
info that may be used
Attacking DNS
DDoS attacks
Bombard root servers
with traffic
Not successful to date
Traffic Filtering
Local DNS servers
cache IPs of TLD
servers, allowing root
server bypass
Redirect attacks
Man-in-middle
Intercept queries
DNS poisoning
Send bogus relies to
DNS server, which
caches
Chapter 2: outline
2.1 principles of network
applications
app architectures
app requirements
2.5 DNS
no always-on server
arbitrary end systems
directly communicate
peers are intermittently
connected and change IP
addresses
examples:
file distribution
(BitTorrent)
Streaming (KanKan)
VoIP (Skype)
file, size F
server
uN
dN
us
u1
d1
u2
d2
di
ui
ui: peer i upload
capacity
Application Layer 2-79
di
network
us
ui
increases linearly in N
Application Layer 2-81
us
di
network
ui
time to distribute F
to N clients using
P2P approach
increases linearly in N
but so does this, as each peer brings service capacity
Application Layer 2-82
3.5
P2P
Client-Server
3
2.5
2
1.5
1
0.5
0
0
10
15
20
25
30
35
N
Application Layer 2-84
Alice arrives
obtains list
of peers from tracker
and begins exchanging
file chunks with peers in torrent
Application Layer 2-85
Hash table
DHT paradigm
Peer churn
Simple Database
Simple database with(key, value) pairs:
key: human name; value: social security #
Key
Value
John Washington
132-54-3570
761-55-3791
Xiaoming Liu
385-41-0902
Rakesh Gopal
441-89-1956
Linda Cohen
217-66-5609
Lisa Kobayashi
177-23-0199
Hash Table
More convenient to store and search on
Key
Value
John Washington
8962458
132-54-3570
761-55-3791
Xiaoming Liu
1567109
385-41-0902
Rakesh Gopal
2360012
441-89-1956
Linda Cohen
5430938
217-66-5609
.
Lisa Kobayashi
9290124
177-23-0199
Circular DHT
60
13
48
25
40
32
overlay network
Resolving a query
1
value
12
60
13
48
O(N) messages
on avgerage to resolve
query, when there
are N peers
25
40
32
12
60
13
48
25
40
32
Peer churn
peers
15
4
12
5
10
Peer churn
peers
15
4
12
10
Chapter 2: outline
2.1 principles of network
applications
app architectures
app requirements
2.5 DNS
Socket programming
goal: learn how to build client/server applications that
communicate using sockets
socket: door between application process and endend-transport protocol
application
process
socket
application
process
transport
transport
network
network
link
physical
Internet
link
controlled by
app developer
controlled
by OS
physical
Socket programming
Two socket types for two transport services:
UDP: unreliable datagram
TCP: reliable, byte stream-oriented
Application Example:
Client reads a line of characters (data) from its
1.
keyboard and sends the data to the server.
The server receives the data and converts
2.
characters to uppercase.
3.
The server sends the modified data to the client.
The client receives the modified data and displays
4.
the line on its screen.
Application Layer 2-100
client
create socket:
clientSocket =
socket(AF_INET,SOCK_DGRAM)
Create datagram with server IP and
port=x; send datagram via
clientSocket
clientSocket = socket(socket.AF_INET,
socket.SOCK_DGRAM)
clientSocket.sendto(message,(serverName, serverPort))
modifiedMessage, serverAddress =
print modifiedMessage
clientSocket.recvfrom(2048)
clientSocket.close()
Application Layer 2-103
serverSocket.bind(('', serverPort))
print The server is ready to receive
loop forever
Read from UDP socket into
message, getting clients
address (client IP and port)
send upper case string
back to this client
while 1:
message, clientAddress = serverSocket.recvfrom(2048)
modifiedMessage = message.upper()
serverSocket.sendto(modifiedMessage, clientAddress)
application viewpoint:
TCP provides reliable, in-order
byte-stream transfer (pipe)
between client and server
Application Layer 2-105
setup
create socket,
connect to hostid, port=x
clientSocket = socket()
send request using
clientSocket
serverPort = 12000
clientSocket = socket(AF_INET, SOCK_STREAM)
clientSocket.connect((serverName,serverPort))
sentence = raw_input(Input lowercase sentence:)
clientSocket.send(sentence)
modifiedSentence = clientSocket.recv(1024)
print From Server:, modifiedSentence
clientSocket.close()
Chapter 2: summary
our study of network apps now complete!
application architectures
client-server
P2P
application service
requirements:
reliability, bandwidth, delay
Internet transport service
model
connection-oriented,
reliable: TCP
unreliable, datagrams: UDP
specific protocols:
HTTP
FTP
SMTP, POP, IMAP
DNS
P2P: BitTorrent, DHT
socket programming: TCP,
UDP sockets
Chapter 2: summary
most importantly: learned about protocols!
typical request/reply
message exchange:
client requests info or
service
server responds with
data, status code
message formats:
headers: fields giving
info about data
data: info being
communicated
important themes:
Chapter 1
Additional Slides
Introduction 1-111
application
(www browser,
packet
analyzer
email client)
application
packet
capture
(pcap)
OS
Transport (TCP/UDP)
copy of all
Ethernet
frames
sent/receive
d
Network (IP)
Link (Ethernet)
Physical