Application Layer: Computer Networking: A Top Down Approach

Chapter 2
Application
Layer
A note on the use of these ppt slides:

Computer
We’re making these slides freely available to all (faculty, students, readers).
They’re in PowerPoint form so you see the animations; and can add, modify,
Networking:
and delete slides (including this one) and slide content to suit your needs.
They obviously represent a lot of work on our part. In return for use, we only
A Top Down
ask the following:
 If you use these slides (e.g., in a class) that you mention their source
Approach
(after all, we’d like people to use our book!) 6th edition
 If you post any slides on a www site, that you note that they are adapted Jim Kurose, Keith
from (or perhaps identical to) our slides, and note our copyright of this
material.
Ross
Addison-Wesley
Thanks and enjoy! JFK/KWR
March 2012
All material copyright 1996-2012
J.F Kurose and K.W. Ross, All Rights Reserved
Application Layer 2-1

Chapter 2: outline
2.1 principles of 2.6 P2P
network applications
applications 2.7 socket
2.2 Web and HTTP programming
2.3 FTP with UDP and
TCP
2.4 electronic
mail
 SMTP, POP3,
IMAP
2.5 DNS

Chapter 2: application
layer
our goals:  learn about
 conceptual, protocols by
implementation examining popular
aspects of application-level
network protocols
application  HTTP
protocols  FTP
 transport-layer  SMTP / POP3 /
service models IMAP
 client-server  DNS
paradigm  creating network
 peer-to-peer applications
paradigm  socket API

Some network apps
 e-mail  voice over IP
 web (e.g., Skype)
 text messaging  real-time video
 remote login conferencing
 P2P file sharing
 social networking
 multi-user
 search
network games  …
 streaming stored  …
video (YouTube,
Hulu, Netflix)

Creating a network app application
transport
network
data link
write programs that: physical
 run on (different) end

systems
 communicate over network
 e.g., web server
software communicates
with browser software
no need to write software

for network-core devices application
transport
 network-core devices do network
data link application
not run user physical transport
network
applications data link
physical
 applications on end
systems allows for
rapid app development,
propagation

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:
 communicate with server
 may be intermittently
client/server connected
 may have dynamic IP
addresses
 do not communicate
directly with each
other

P2P architecture
 no always-on server peer-peer
 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
Processes
communicating
process: program clients, servers
running within a client process:
host process that initiates
communication
 within same host,
server process:
two processes process that waits to
communicate using be contacted
inter-process
communication
(defined by OS)  aside:
 processes in applications with
different hosts P2P architectures
communicate by
exchanging messages have client
processes & server
processes
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 to deliver
message to socket at receiving process
application application
socket controlled by
process process app developer
transport transport
network network controlled
link
by OS
link Internet
physical physical

Addressing processes
 to receive  identifier includes
messages, process both IP address and
must have port numbers
identifier associated with
 host device has process on host.
unique 32-bit IP  example port
address numbers:
 HTTP server: 80
 Q: does IP address
 mail server: 25
of host
 A: no,onmany
which
process runs can be
processes
 to send HTTP message
suffice foron same
running to gaia.cs.umass.edu
identifying
host the web server:
process?  IP address:
128.119.245.12
 port number: 80
 more shortly…
App-layer protocol
defines
 types of messages open protocols:
exchanged,
 defined in RFCs
 e.g., request,
response  allows for
 message syntax: interoperability
 what fields in  e.g., HTTP, SMTP
messages & how
fields are proprietary
delineated protocols:
 message semantics  e.g., Skype
 meaning of
information in
fields
 rules for when and how
processes send &
respond to messages

What transport service does
an app need?
data integrity throughput
 some apps (e.g., file
 some apps (e.g.,
transfer, web multimedia)
transactions) require
100% reliable data require minimum
transfer amount of
 other apps (e.g., audio)
throughput to be
can tolerate some loss “ effective”
 other apps
timing
 some apps (e.g.,
(“ elastic apps” )
Internet telephony, make use of
interactive games) whatever
security
require low delay  throughput
encryption,they
data
to be “ effective” get
integrity, …

Transport service requirements:
common apps
application data loss throughput time sensitive
file transfer no loss elastic no

e-mail no loss elastic no
Web documents no loss elastic no
real-time audio/video loss-tolerant audio: 5kbps-1Mbps yes, 100’s msec
video:10kbps-5Mbps
stored audio/video loss-tolerant same as above yes, few secs
interactive games loss-tolerant few kbps up yes, 100’s msec
text messaging no loss elastic yes and no

Internet transport
protocols services
TCP service: UDP service:
 reliable transport  unreliable data
between sending and transfer between
receiving process sending and
 flow control: sender receiving process
won’ t overwhelm
receiver  does not provide:
 congestion control: reliability, flow
throttle sender when control, congestion
network overloaded control, timing,
 does not provide: throughput
timing, minimum guarantee, security,
throughput guarantee, orconnection setup,
security
 connection-oriented:
setup required between Q: why bother? Why
client and server is there a UDP?
processes

Internet apps: application,
transport protocols
application underlying
application layer protocol transport protocol
e-mail SMTP [RFC 2821] TCP

remote terminal access Telnet [RFC 854] TCP
Web HTTP [RFC 2616] TCP
file transfer FTP [RFC 959] TCP
streaming multimedia HTTP (e.g., YouTube), TCP or UDP
RTP [RFC 1889]
Internet telephony SIP, RTP, proprietary
(e.g., Skype) TCP or UDP

Securing TCP
TCP & UDP SSL is at app

 no encryption layer
 cleartext passwds  Apps use SSL
sent into socket libraries, which
traverse Internet “ talk” to TCP
in cleartext SSL socket API
SSL  cleartext passwds
 provides encrypted
sent into socket
TCP connection traverse Internet
 data integrity encrypted
 end-point  See Chapter 7
authentication

Chapter 2: outline
 app programming
architectures
 app requirements
with UDP and
TCP
2.2 Web and HTTP
2.3 FTP
2.4 electronic
mail
 SMTP, POP3, IMAP
2.5 DNS
Web and HTTP
First, a review…
 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
www.someschool.edu/someDept/pic.gif
URL, e.g.,
host name path name

HTTP overview
HTTP: hypertext
transfer protocol
 Web’ s application HT
TP
req
layer protocol PC running ues
HT t
 client/server model Firefox browser TP
res
 client: browser pon
se
that requests,
receives, (using t
HTTP protocol) u es
req server
and “ displays” T P n se
HT s po running
Web objects r e Apache Web
 server: Web T TP
H server
server sends
(using HTTP
protocol) objects iphone running
in response to Safari browser
requests

HTTP overview
(continued)
uses TCP: HTTP is “ stateless
 client initiates TCP ”
connection (creates
 server maintains no
information about
socket) to server, past client requests
port 80
 server accepts TCP
connection from client aside
 HTTP messages
protocols that
(application-layer maintain “ state”
protocol messages) are complex!
exchanged between  past history (state)
browser (HTTP client) must be maintained
and Web server (HTTP  if server/client
server) crashes, their views
 TCP connection closed of “ state” may be
inconsistent, must be
reconciled
HTTP connections
non-persistent persistent HTTP
HTTP  multiple
 at most one
objects can be
object sent over sent over
TCP connection single TCP
 connection connection
then closed between client,
 downloading server
multiple objects
required
multiple
connections
Non-persistent HTTP
suppose user enters URL: (contains text,
www.someSchool.edu/someDepartment/home.index references to 10
jpeg images)
1a. HTTP client
initiates TCP
connection to HTTP 1b. HTTP server at host
server (process) at www.someSchool.edu
www.someSchool.edu on waiting for TCP
port 80 connection at port
2. HTTP client sends 80. “ accepts”
HTTP request message connection, notifying
(containing URL) into 3. client
HTTP server receives
TCP connection request message,
socket. Message forms response
indicates that client message containing
wants object requested object, and
time someDepartment/home.i sends message into
ndex its socket
Non-persistent HTTP
(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
time
6. Steps 1-5 repeated
for each of 10 jpeg
objects

Non-persistent HTTP: response
time
RTT (definition): time
for a small packet to
travel from client to
server and back
HTTP response time: initiate TCP
 one RTT to initiate TCP connection
connection RTT
 one RTT for HTTP request
request and first few file
bytes of HTTP response time to
RTT transmit
to return file
 file transmission time
file
 non-persistent HTTP received
response time =
2RTT+ file time time
transmission time

Persistent HTTP
non-persistent persistent HTTP:

HTTP issues:  server leaves
connection open after
 requires 2 RTTs sending response
per object  subsequent HTTP
 OS overhead for messages between
each TCP same client/server
sent over open
connection connection
 browsers often  client sends requests
open parallel TCP as soon as it
connections to encounters a
fetch referenced referenced object
objects  as little as one RTT
for all the
referenced objects

HTTP request message
 two types of HTTP messages: request,
response
 HTTP request message:
 ASCII (human-readable format) carriage return character
line-feed character
request line
(GET, POST, GET /index.html HTTP/1.1\r\n
HEAD commands) Host: www-net.cs.umass.edu\r\n
User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
headerAccept-Language: en-us,en;q=0.5\r\n
linesAccept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
carriage return, Keep-Alive: 115\r\n
line feed at start Connection: keep-alive\r\n
\r\n
of line indicates
end of header lines
HTTP request message:
general format
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

Uploading form input
POST method:
 web page often
includes form
input
 input is uploaded
to server in
URL method:
entity body
 uses GET method
 input is uploaded
in URL field of
request line:
www.somesite.com/animalsearch?monkeys&banana

Method
types
HTTP/1.0: HTTP/1.1:
 GET  GET, POST, HEAD
 POST  PUT
 HEAD  uploads file in
 asks server to entity body to
leave requested path specified
object out of in URL field
response  DELETE
 deletes file
specified in
the URL field

HTTP response message
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
Accept-Ranges: bytes\r\n
lines 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
HTTP response status
codes
 status code appears in 1st line in server-to-
client response message.
 some sample 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
Trying out HTTP (client side)
for yourself
1. Telnet to your favorite Web server:
telnet cis.poly.edu 80 opens TCP connection to port 80

(default HTTP server port) at cis.poly.edu.
anything typed in sent
to port 80 at cis.poly.edu
2. type in a GET HTTP request:

GET /~ross/ HTTP/1.1 by typing this in (hit carriage
Host: cis.poly.edu return twice), you send
this minimal (but complete)
GET request to HTTP server
3. look at response message sent by HTTP server!

Wireshark to look at captured HTTP request/respons
User-server state:
cookies
example:
many Web sites use
 Susan always access
cookies
four components:
Internet from PC
 visits specific e-
1) cookie header
line of HTTP commerce site for
response message first time
2) cookie header  when initial HTTP
line in next HTTP requests arrives at
request message site, site creates:
3) cookie file kept  unique ID
on user’ s host,
managed by user’ s
 entry in backend
browser database for ID
4) back-end database
at Web site
Cookies: keeping “ state”
(cont.)
client server
ebay 8734
usual http request msg Amazon server
cookie file creates ID
usual http response
1678 for user create backend
ebay 8734
set-cookie: 1678 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
Cookies (continued)
aside
what cookies can cookies and
be used for: privacy:
 authorization
 cookies permit
 shopping carts
 recommendations
sites to learn a
 user session state
lot about you
(Web e-mail)  you may supply
name and e-mail
how to keep “ state” : to sites
 protocol endpoints: maintain
state at sender/receiver
over multiple transactions
 cookies: http messages carry
state
Web caches (proxy
server)
goal: satisfy client request without
involving
 user origin
sets browser: Web server
accesses via cache
 browser sends all HTTP
requests to cache HT proxy
 object in cache: TP ue st
req server req
HT ues P se
cache returns client TP t H TT p on
res res origin
object pon TP server
se HT
 else cache requests est
u
object from origin req e
T P o ns
server, then HT
es
p
r
returns object to TTP
client H
client origin
server

More about Web caching
 cache acts as why Web caching?
both client and  reduce response time
server for client request
 server for original  reduce traffic on an
requesting client institution’ s
 client to origin access link
server
 Internet dense with
 typically cache caches: enables
is installed by “ poor” content
ISP (university, providers to
company, effectively deliver
residential ISP) content (so too does
P2P file sharing)

Caching example:
assumptions:
 avg object size: 100K
origin
bits servers
 avg request rate from public
browsers to origin Internet
servers:15/sec
 avg data rate to
browsers: 1.50 Mbps
 1.54 Mbps
RTT from institutional
access link
router to any origin
server: 2 sec problem! institutional
 access link rate: 1.54 network
1 Gbps LAN
Mbps
consequences:
 LAN utilization: 15%
 access link utilization =
99%
 total delay = Internet
Caching example: fatter
access link
assumptions:
origin
bits servers
servers:15/sec
browsers: 1.50 Mbps
 154 1.54 Mbps
RTT from institutional 154 Mbps
access link
router to any origin Mbps
server: 2 sec institutional
9.9% 1 Gbps LAN
Mbps
consequences:
 LAN utilization:
msecs 15%
Cost:
99%increased access link speed (not cheap!)
 total delay = Internet Application Layer 2-40
Caching example: install
local cache
assumptions:
origin
bits servers
servers:15/sec
browsers: 1.50 Mbps
 1.54 Mbps
RTT from institutional
access link
router to any origin
server: 2 sec institutional
? 1 Gbps LAN
Mbps ?
local web
How to compute link
consequences: cache
 utilization,
LAN utilization: delay?
15%
Cost: web cache (cheap!)
100%
 total delay = Internet Application Layer 2-41
Caching example: install
local cache
Calculating access link
utilization, delay with
cache: origin
 suppose cache hit rate is 0.4 servers
 40% requests satisfied at cache, public
60% requests satisfied at origin Internet
access link
utilization:
 60% of requests use access 1.54 Mbps
link access link
 data rate to browsers over institutional
access
total link = 0.6*1.50
delay network
1 Gbps LAN
Mbps = .9 Mbps
 = 0.6 * (delay from origin
 utilization = 0.9/1.54 = .
servers) +0.4 * (delay when
58 local web
satisfied at cache) cache
 = 0.6 (2.01) + 0.4 (~msecs)
 = ~ 1.2 secs
 less than with 154 Mbps
link (and cheaper too!) Application Layer 2-42
Conditional GET
client server
 Goal: don’ t send
object if cache has
up-to-date cached HTTP request msg
version If-modified-since: <date> object
 no object transmission not
delay modified
HTTP response
 lower link utilization before
HTTP/1.0
 cache: specify date 304 Not Modified <date>
of cached copy in
HTTP request
If-modified-since:
<date>
 server: response HTTP request msg
If-modified-since: <date> object
contains no object
modified
if cached copy is
up-to-date: HTTP response after
HTTP/1.0 200 OK <date>
HTTP/1.0 304 Not
Modified <data>
Chapter 2: outline
 app programming
architectures
with UDP and
TCP
2.2 Web and HTTP
2.3 FTP
2.4 electronic
mail
2.5 DNS
FTP: the file transfer
protocol
file transfer
FTP FTP FTP
user client server
interface
user
at host remote file
local file system
system
 transfer file to/from remote host

 client/server model
 client: side that initiates transfer
(either to/from remote)
 server: remote host
 ftp: RFC 959
 ftp server: port 21
FTP: separate control, data
connections
 FTP client contacts FTP TCP control connection,
server port 21
server at port 21, using
TCP
 client authorized over TCP data connection,
FTP server port 20 FTP
control connection client server
 client browses remote
directory, sends
commands over control  server opens
connection another TCP data
 when server receives connection to
file transfer command, transfer another
server opens 2nd TCP data file
connection (for file) to
client  control connection:
 after transferring one “ out of band”
file, server closes data  FTP server
connection maintains “ state” :
current directory,
FTP commands, responses
sample commands: sample return
 sent as ASCII text codes
over control channel  status code and
 USER username phrase (as in HTTP)
 PASS password  331 Username OK,
 LIST return list of password required
file in current  125 data connection
directory already open;
 RETR filename transfer starting
retrieves (gets)  425 Can’t open data
file connection
 STOR filename  452 Error writing
stores (puts) file file
onto remote host

Chapter 2: outline
 app programming
architectures
with UDP and
TCP
2.2 Web and HTTP
2.3 FTP
2.4 electronic
mail
2.5 DNS
Electronic mail outgoing
message queue
user mailbox
Three major user
components: agent
 user agents
mail user
 mail servers server agent
 simple mail transfer
protocol: SMTP SMTP mail user
server agent
User Agent SMTP
 a.k.a. “ mail reader”
 composing, editing, SMTP user
reading mail messages agent
mail
 e.g., Outlook, server
Thunderbird, iPhone mail user
client agent
 outgoing, incoming user
messages stored on agent
server

Electronic mail: mail
servers
mail servers: user
agent
 mailbox contains
incoming messages for mail user
user server agent
 message queue of
outgoing (to be sent) SMTP mail user
mail messages server agent
 SMTP protocol between SMTP
mail servers to send
SMTP user
email messages agent
 client: sending mail
server
mail server user
 “ server” : agent
receiving mail user
server agent

Electronic Mail: SMTP
[RFC 2821]
 uses TCP to reliably transfer email
message from client to server, port 25
 direct transfer: sending server to
receiving server
 three phases of transfer
 handshaking (greeting)
 transfer of messages
 closure
 command/response interaction (like
HTTP, FTP)
 commands: ASCII text
 response: status code and phrase
 messages must be in 7-bit ASCI

Scenario: Alice sends
message to Bob
1) Alice uses UA to 4) SMTP client sends
compose message “ to” Alice’ s message
bob@someschool.edu over the TCP
2) Alice’ s UA sends connection
message to her mail
server; message placed
5) Bob’ s mail server
in message queue places the message
3) client side of SMTP
in Bob’ s mailbox
opens TCP connection 6) Bob invokes his
with Bob’ s mail user agent to read
server message
1 user mail user

mail agent
agent server server
2 3 6
4
5
Alice’s mail server Bob’s mail server
Sample SMTP interaction
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr... Sender ok
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburger.edu ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection

Try SMTP interaction for
yourself:
 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)

SMTP: final words
 SMTP uses comparison with
persistent HTTP:
connections  HTTP: pull
 SMTP requires  SMTP: push
message (header &
body) to be in 7-
 both have ASCII
command/response
bit ASCII interaction, status
 SMTP server uses codes
CRLF.CRLF to  HTTP: each object
determine end of encapsulated in its
message own response msg
 SMTP: multiple
objects sent in
multipart msg

Mail message format
SMTP: protocol for
exchanging email msgs header
RFC 822: standard for blank
text message format: line
 header lines, e.g.,
 To:
 From: body
 Subject:
different from SMTP
MAIL FROM, RCPT TO:
commands!
 Body: the “ message”
 ASCII characters only

Mail access protocols
user
mail user
SMTP SMTP access
agent agent
protocol
(e.g., POP,
IMAP)
sender’s mail receiver’s mail

server server
 SMTP: delivery/storage to receiver’ s server
 mail access protocol: retrieval from server
 POP: Post Office Protocol [RFC 1939]:
authorization, download
 IMAP: Internet Mail Access Protocol [RFC 1730]:
more features, including manipulation of stored
msgs on server
 HTTP: gmail, Hotmail, Yahoo! Mail, etc.

POP3 protocol
S: +OK POP3 server ready
C: user bob
authorization phase S: +OK
 client commands: C: pass hungry
 user: declare username S: +OK user successfully logged on
 pass: password C: list

 server responses S: 1 498
 +OK S: 2 912
 -ERR S: .
C: retr 1
transaction phase, S: <message 1 contents>
client: S: .
 list: list message C: dele 1
numbers C: retr 2
 retr: retrieve message S: <message 1 contents>
by number S: .
 dele: delete C: dele 2
 quit C: quit
S: +OK POP3 server signing off
POP3 (more) and IMAP
more about POP3 IMAP
 previous example  keeps all messages
uses POP3 in one place: at
“ download and server
delete” mode  allows user to
 Bob cannot re- organize messages
read e-mail if he in folders
changes client  keeps user state
 POP3 “ download- across sessions:
and-keep” : copies  names of folders
of messages on
and mappings
different clients
between message
 POP3 is stateless IDs and folder
across sessions name

Chapter 2: outline
 app programming
architectures
with UDP and
TCP
2.2 Web and HTTP
2.3 FTP
2.4 electronic
mail
2.5 DNS
DNS: domain name system
people: many Domain Name System:
identifiers:  distributed database
 SSN, name, passport implemented in
# hierarchy of many name
Internet hosts, servers
routers:  application-layer
 IP address (32 bit) protocol: hosts, name
- used for servers communicate to
addressing resolve names
datagrams (address/name
 “ name” , e.g., translation)
www.yahoo.com -  note: core Internet
used by humans function, implemented
Q: how to map between as application-layer
IP address and name, protocol
and vice versa ?  complexity at
network’ s “ edge”
DNS: services, structure
DNS services why not centralize
 hostname to IP DNS?
address translation  single point of failure
 traffic volume
 host aliasing
 canonical, alias
 distant centralized
names database
 maintenance
 mail server
aliasing A: doesn’t scale!
 load distribution
 replicated Web
servers: many IP
addresses
correspond to
one name

DNS: a distributed,
hierarchical database
Root DNS Servers
… …
com DNS servers org DNS servers edu DNS servers
pbs.org poly.edu umass.edu

yahoo.com amazon.com
DNS servers DNS serversDNS servers
DNS servers DNS servers
client wants IP for www.amazon.com; 1 st approx:

 client queries root server to find com DNS server
 client queries .com DNS server to get amazon.com
DNS server
 client queries amazon.com DNS server to get IP
address for www.amazon.com

DNS: root name servers
 contacted by local name server that can not
resolve name
 root name server:
 contacts authoritative name server if name
mapping not known
 gets mapping
 returns mapping
c. Cogent, Herndon, VA (5 other sites) to local name server
d. U Maryland College Park, MD k. RIPE London (17 other sites)
h. ARL Aberdeen, MD
j. Verisign, Dulles VA (69 other sites ) i. Netnod, Stockholm (37 other sites)
e. NASA Mt View, CA m. WIDE Tokyo

f. Internet Software C. (5 other sites)
Palo Alto, CA (and 48 other
sites)
a. Verisign, Los Angeles CA 13 root name

(5 other sites)
b. USC-ISI Marina del Rey, CA
“servers”
l. ICANN Los Angeles, CA worldwide
(41 other sites)
g. US DoD Columbus,
OH (5 other sites)

TLD, authoritative
servers
top-level domain (TLD) servers:
 responsible for com, org, net, edu, aero,
jobs, museums, and all top-level country
domains, e.g.: uk, fr, ca, jp
 Network Solutions maintains servers
for .com TLD
 Educause for .edu TLD
authoritative DNS servers:
 organization’ s own DNS server(s),
providing authoritative hostname to IP
mappings for organization’ s named hosts
 can be maintained by organization or
service provider
Local DNS name server
 does not strictly belong to
hierarchy
 each ISP (residential ISP,
company, university) has one
 also called “ default name server”
 when host makes DNS query, query
is sent to its local DNS server
 has local cache of recent name-to-
address translation pairs (but may be
out of date!)
 acts as proxy, forwards query into
hierarchy

DNS name
resolution root DNS server
example 2
host at 3
TLD DNS server
cis.poly.edu 4
wants IP address
for 5
gaia.cs.umass.ed local DNS server
iterated
u query: dns.poly.edu
 contacted server 7 6
1 8
replies with
name of server
authoritative DNS server
to contact dns.cs.umass.edu
 “ I don’ t know requesting host
cis.poly.edu
this name, but
ask this server
gaia.cs.umass.edu
”
DNS name
resolution root DNS server
example 2 3
recursive query: 7
6
 puts burden of TLD DNS
server
name
resolution on local DNS server
contacted name dns.poly.edu 5 4
server 1 8
 heavy load at
authoritative DNS server
upper levels dns.cs.umass.edu
of hierarchy? requesting host
cis.poly.edu
gaia.cs.umass.edu

DNS: caching, updating
records
 once (any) name server learns mapping,
it caches mapping
 cache entries timeout (disappear) after
some time (TTL)
 TLD servers typically cached in local name
servers
• thus root name servers not often visited
 cached entries may be out-of-date (best
effort name-to-address translation!)
 if name host changes IP address, may not be
known Internet-wide until all TTLs expire
 update/notify mechanisms proposed IETF
standard
 RFC 2136

DNS records
DNS: distributed db storing resource records (RR)
RR format: (name, value, type, ttl)
type=A type=CNAME
 name is hostname  name is alias name for
 value is IP address some “ canonical” (the
type=NS real) name
 name is domain  www.ibm.com is really
(e.g., foo.com) servereast.backup2.ibm.com
 value is hostname
of authoritative  value is canonical name
name server for type=MX
this domain  value is name of
mailserver associated
with name
DNS protocol, messages
 query and reply messages, both with same message format
2 bytes 2 bytes
msg header identification flags
 identification: 16 # questions # answer RRs

bit # for query,
# authority RRs # additional RRs
reply to query uses
same # questions (variable # of questions)
 flags:
 query or reply answers (variable # of RRs)
 recursion desired
 recursion authority (variable # of RRs)
available
 reply is additional info (variable # of RRs)
authoritative
DNS protocol, messages
2 bytes 2 bytes
identification flags
# questions # answer RRs
# authority RRs # additional RRs
name, type fields

questions (variable # of questions)
for a query
RRs in
response answers (variable # of RRs)
to query
records for authority (variable # of RRs)
authoritative servers
additional “ helpful” additional info (variable # of RRs)
info that may be used
Inserting records into
DNS
 example: new startup “ Network Utopia”
 register name networkuptopia.com at DNS
registrar (e.g., Network Solutions)
 provide names, IP addresses of authoritative
name server (primary and secondary)
 registrar inserts two RRs into .com TLD
server:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
 create authoritative server type A
record for www.networkuptopia.com; type
MX record for networkutopia.com

Attacking DNS
DDoS attacks Redirect attacks
 Bombard root  Man-in-middle
servers with  Intercept queries
traffic  DNS poisoning
 Not successful to  Send bogus relies
date to DNS server,
 Traffic Filtering which caches
 Local DNS servers Exploit DNS for DDoS
cache IPs of TLD
servers, allowing  Send queries with
root server bypass spoofed source
 Bombard TLD address: target IP
servers  Requires
 Potentially more amplification
dangerous

Chapter 2: outline
 app programming
architectures
with UDP and
TCP
2.2 Web and HTTP
2.3 FTP
2.4 electronic
mail
2.5 DNS
Pure P2P architecture
 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 distribution: client-
server vs P2P
Question: how much time to distribute file (size F)
from one server to N peers?
 peer upload/download capacity is limited resource
us: server upload

capacity
u1 di: peer i download

file, size F us d1 u2 capacity
d2
server
di
uN network (with abundant
bandwidth) ui
dN
ui: peer i upload
capacity

File distribution time:
client-server
 server transmission:
must sequentially send F
(upload) N file copies: us
 time to send one copy: di
F/us
network
 time to send N copies: ui
NF/us
 client: each client
must download file
copy
 dmin = min client
download rate
time to download
 min client distribute F
time: F/dto N
min
clients using
Dc-s > max{NF/us,,F/dmin}
client-server approach
increases linearly in N
File distribution time: P2P
 server
transmission: must F
u
upload at least one s
di
 copy
client: each client network
 timedownload
must to send one
file ui
copy: F/us
copy
 min client
 clients: as download
aggregate must
time: F/d
download NF
min bits
 max upload rate (limting max download
timerate) is us F+ ui
to distribute
DP2P > max{F/us,,F/dmin,,NF/(us +
to N clients using ui)}
P2P approach
increases linearly in N …
… but so does this, as each peer brings service capacity
Client-server vs. P2P:
example
client upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us
3.5
P2P
Minimum Distribution Time
3
Client-Server
2.5
1.5
0.5
0
0 5 10 15 20 25 30 35
N
P2P file distribution:
BitTorrent
 file divided into 256Kb chunks
 peers in torrent send/receive file chunks
tracker: tracks peers torrent: group of

participating in torrent peers exchanging
chunks of a file
Alice arrives …
… obtains list
of peers from tracker
… and begins exchanging
file chunks with peers in torrent

P2P file distribution:
BitTorrent
 peer joining torrent:
 has no chunks, but will
accumulate them over
time from other peers
 registers with tracker
to get list of peers,
connects to subset of
peers (“ neighbors” )
 while downloading, peer uploads chunks to

other peers
 peer may change peers with whom it
exchanges chunks
 churn: peers may come and go
 once peer has entire file, it may
(selfishly) leave or (altruistically)
BitTorrent: requesting,
sending file chunks
requesting chunks: sending chunks: tit-
 at any given time, for-tat
different peers have
different subsets of  Alice sends chunks to
file chunks those four peers
 periodically, Alice currently sending her
asks each peer for chunks at highest
list of chunks that rate
they have  other peers are choked
 Alice requests by Alice (do not
missing chunks from receive chunks from
peers, rarest first her)
 re-evaluate top 4
every10 secs
 every 30 secs:
randomly select
another peer, Application
starts Layer 2-83
BitTorrent: tit-for-
tat
1) Alice “ optimistically unchokes” Bob
lice becomes one of Bob’ s top-four providers; Bob reciprocat
) Bob becomes one of Alice’ s top-four providers
higher upload rate:

find better trading
partners, get file
faster ! Application Layer 2-84
Distributed Hash Table
(DHT)
 Hash table
 DHT paradigm
 Circular DHT and overlay networks
 Peer churn
Simple Database
Simple database with(key, value)
pairs:
• key:
Key
human name;
Value
value: social
security #
John Washington 132-54-3570
Diana Louise Jones 761-55-3791
Xiaoming Liu 385-41-0902
Rakesh Gopal 441-89-1956
Linda Cohen 217-66-5609
……. ………
Lisa Kobayashi 177-23-0199
• key: movie title; value: IP

address
Hash Table
• More convenient to store and
search on numerical
representation of key
• key = Keyhash(original
Original Key key)
Value
John Washington 8962458 132-54-3570
Diana Louise Jones 7800356 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
Distributed Hash Table
(DHT)
 Distribute (key, value) pairs over
millions of peers
 pairs are evenly distributed over peers
 Any peer can query database with a key
 database returns value for the key
 To resolve query, small number of messages
exchanged among peers
 Each peer only knows about a small
number of other peers
 Robust to peers coming and going
(churn)
Assign key-value pairs
to peers
 rule: assign key-value pair to
the peer that has the closest ID.
 convention: closest is the
immediate successor of the key.
 e.g., ID space {0,1,2,3,…,63}
 suppose 8 peers:
1,12,13,25,32,40,48,60
 If key = 51, then assigned to peer 60
Circular DHT
• each peer only aware of
immediate successor and
predecessor.
12
60
13
48
25
40
32 “overlay network”
Resolving a query
1 What is the value

associated with key 53 ?
value 12
60
13
48
(N) messages 25
n avgerage to resolve
uery, when there 40
32
re N peers
Circular DHT with
shortcuts 1 What is the value for
value
key 53
12
60
13
48
25
40
32
• each peer keeps track of IP addresses of
predecessor, successor, short cuts.
• reduced from 6 to 3 messages.
• possible to design shortcuts with O(log N)
neighbors, O(log N) messages in query
Peer churn handling peer
1
churn:
peers may come and go
15 3 (churn)
each peer knows
4 address of its two
successors
12
5 each peer
periodically pings its
10 two successors to check
8
aliveness
example: peer 5 abruptly leaves
if immediate
successor leaves,
choose next successor
as new immediate
successor
Peer churn handling peer
1
churn:
peers may come and go
15 3 (churn)
each peer knows
4 address of its two
successors
12
each peer
periodically pings its
10 two successors to check
8
example: peer 5 abruptlyaliveness
leaves
peer 4 detects peer 5’ 
sif immediatemakes 8
departure;
its immediate successor successor leaves,
choosesuccessor
 4 asks 8 who its immediate next successor
is;
as new immediate
makes 8’ s immediate successor its second
successor. successor
Chapter 2: outline
applications
2.7 socket
 app
architectures programming
 app requirements with UDP and
TCP
2.2 Web and HTTP
2.3 FTP
2.4 electronic
mail
2.5 DNS
Socket programming
goal: learn how to build client/server
applications that communicate using sockets
socket: door between application process and
end-end-transport protocol
application application
socket controlled by
process process app developer
transport transport
network network controlled
link
by OS
link Internet
physical physical

Socket programming
Two socket types for two transport
services:
 UDP: unreliable datagram
 TCP: reliable, byte stream-oriented
Application Example:
1. Client reads a line of characters
(data) from its keyboard and sends
the data to the server.
2. The server receives the data and
converts characters to uppercase.
3. The server sends the modified data
to the client.
4. The client receives the modified
Socket programming with
UDP
UDP: no “ connection” between client
& server
 no handshaking before sending data
 sender explicitly attaches IP destination
address and port # to each packet
 rcvr extracts sender IP address and port#
from received packet
UDP: transmitted data may be lost or
received out-of-order
Application viewpoint:
 UDP provides unreliable transfer of
groups of bytes (“ datagrams” ) between
client and server

Client/server socket
interaction: UDP
server (running on serverIP) client
create socket:
create socket, port= x: clientSocket =
serverSocket = socket(AF_INET,SOCK_DGRAM)
socket(AF_INET,SOCK_DGRAM)
Create datagram with server IP and
port=x; send datagram via
read datagram from clientSocket
serverSocket
write reply to
serverSocket read datagram from
specifying clientSocket
client address,
port number close
clientSocket
Application 2-99
Example app: UDP client
Python UDPClient
include Python’s socket
library from socket import *
serverName = ‘hostname’
serverPort = 12000
create UDP socket for
server
clientSocket = socket(socket.AF_INET,
get user keyboard socket.SOCK_DGRAM)
input
message = raw_input(’Input lowercase sentence:’)
Attach server name, port to
message; send into socket clientSocket.sendto(message,(serverName, serverPort))
read reply characters from modifiedMessage, serverAddress =
socket into string
clientSocket.recvfrom(2048)
print out received string print modifiedMessage
and close socket
clientSocket.close()
Example app: UDP server
Python UDPServer
from socket import *
serverPort = 12000
create UDP socket serverSocket = socket(AF_INET, SOCK_DGRAM)
bind socket to local port
number 12000 serverSocket.bind(('', serverPort))
print “The server is ready to receive”
loop forever
while 1:
Read from UDP socket into
message, getting client’s
message, clientAddress = serverSocket.recvfrom(2048)
address (client IP and port) modifiedMessage = message.upper()
send upper case string serverSocket.sendto(modifiedMessage, clientAddress)
back to this client

Socket programming with
TCP
client must contact  when contacted by client,
server server TCP creates new
 server process must first socket for server process
be running to communicate with that
 server must have created particular client
socket (door) that  allows server to talk
welcomes client’ s with multiple clients
contact  source port numbers
client contacts server used to distinguish
by: clients (more in Chap
3)
 Creating TCP socket,
specifying IP address,
port number of server
process application viewpoint:
 when client creates TCP provides reliable, in-ord
socket: client TCP
establishes connection byte-stream
to transfer (“ pipe”
server TCP between client and server

Client/server socket
interaction: TCP
server (running on hostid) client
create socket,
port=x, for incoming
request:
serverSocket = socket()
wait for incoming create socket,

connection request
TCP connect to hostid, port=x
connectionSocket = connection setup clientSocket = socket()
serverSocket.accept()
send request using

read request from clientSocket
connectionSocket
write reply to
connectionSocket read reply from
clientSocket
close
connectionSocket close
clientSocket

Example app: TCP client
Python TCPClient
serverName = ’servername’
create TCP socket for serverPort = 12000
server, remote port 12000
clientSocket = socket(AF_INET, SOCK_STREAM)
clientSocket.connect((serverName,serverPort))
sentence = raw_input(‘Input lowercase sentence:’)
No need to attach server
name, port clientSocket.send(sentence)
modifiedSentence = clientSocket.recv(1024)
print ‘From Server:’, modifiedSentence
clientSocket.close()

Example app: TCP server
Python TCPServer
create TCP welcoming serverPort = 12000
socket serverSocket = socket(AF_INET,SOCK_STREAM)
serverSocket.bind((‘’,serverPort))
server begins listening for
incoming TCP requests serverSocket.listen(1)
print ‘The server is ready to receive’
loop forever
while 1:
server waits on accept()
for incoming requests, new
connectionSocket, addr = serverSocket.accept()
socket created on return
read bytes from socket (but

sentence = connectionSocket.recv(1024)
not address as in UDP) capitalizedSentence = sentence.upper()
close connection to this connectionSocket.send(capitalizedSentence)
client (but not welcoming
socket) connectionSocket.close()
Chapter 2:
summary
our study of network apps now complete!
 application architectures  specific
 client-server
protocols:
 P2P
 application service  HTTP
requirements:
 FTP
 reliability, bandwidth,
delay  SMTP, POP, IMAP
 Internet transport service
model  DNS
 connection-oriented,  P2P: BitTorrent,
reliable: TCP
 unreliable, datagrams: DHT
UDP  socket
programming: TCP,
UDP sockets
Chapter 2:
summary
most importantly: learned about
protocols!
 typical request/reply
message exchange: important themes:
 client requests info  control vs. data
or service
msgs
 server responds with
data, status code  in-band, out-of-
 message formats: band
 headers: fields
giving info about  centralized vs.
data decentralized
 data: info being
 stateless vs.
communicated
stateful
 reliable vs.
unreliable msg
transfer
Chapter 1
Additional
Slides
Introduction 1-108
application
packet (www browser,
analyzer email client)

application
OS
packet Transport (TCP/UDP)
copy of all Network (IP)
capture Ethernet
frames Link (Ethernet)
(pcap) sent/receive
d Physical

Application Layer: Computer Networking: A Top Down Approach

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Application Layer: Computer Networking: A Top Down Approach

Uploaded by

Copyright:

Available Formats

Chapter 2

A note on the use of these ppt slides:

Application Layer 2-1

Application Layer 2-2

Application Layer 2-3

Application Layer 2-4

 run on (different) end

no need to write software

Application Layer 2-5

Application Layer 2-6

Application Layer 2-7

Application Layer 2-10

Application Layer 2-12

Application Layer 2-13

application data loss throughput time sensitive

file transfer no loss elastic no

Application Layer 2-14

Application Layer 2-15

e-mail SMTP [RFC 2821] TCP

Application Layer 2-16

TCP & UDP SSL is at app

Application Layer 2-17

Application Layer 2-19

Application Layer 2-20

Application Layer 2-24

Application Layer 2-25

non-persistent persistent HTTP:

Application Layer 2-26

header field name value cr lf

Application Layer 2-28

Application Layer 2-29

Application Layer 2-30

telnet cis.poly.edu 80 opens TCP connection to port 80

2. type in a GET HTTP request:

3. look at response message sent by HTTP server!

one week later:

Application Layer 2-37

Application Layer 2-38

 transfer file to/from remote host

Application Layer 2-47

Application Layer 2-49

Application Layer 2-50

Application Layer 2-51

1 user mail user

Application Layer 2-53

above lets you send email without using

Application Layer 2-54

Application Layer 2-55

Application Layer 2-56

sender’s mail receiver’s mail

Application Layer 2-57

 pass: password C: list

Application Layer 2-59

Application Layer 2-62

com DNS servers org DNS servers edu DNS servers

pbs.org poly.edu umass.edu

client wants IP for www.amazon.com; 1 st approx:

Application Layer 2-63

e. NASA Mt View, CA m. WIDE Tokyo

a. Verisign, Los Angeles CA 13 root name

Application Layer 2-64

Application Layer 2-66

Application Layer 2-68