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 2.6 P2P
of 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

Application Layer 2-2

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-  SMTP / POP3 /
layer service IMAP
models  DNS
 client-server  creating network
paradigm applications
 peer-to-peer  socket API
paradigm

Application Layer 2-3

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

Application Layer 2-4

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 application

browser software transport

network
application
data link
physical transport
network
no need to write data link
physical
software for
network-core devices
 network-core devices
do not run user
applications
 applications on end Application Layer 2-5
Application
architectures
possible structure of applications:
 client-server
 peer-to-peer (P2P)

Application Layer 2-6

 Client-server
architecture
server:
 always-on host
 permanent IP
address
 data centers for
scaling

client/server
clients:
 communicate with
server
 may be
intermittently
connected
 may have dynamic IP
addresses Application Layer 2-7
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 Application Layer 2-8
Processes
communicating
process: programclients, servers
running within a client process:
host process that
 within same host, initiates
two processes communication
communicate using server process:
inter-process process that
communication waits to be
(defined by OS)  aside:
contacted
 processes in applications with
different hosts P2P architectures
communicate by have client
exchanging
messages processes & server
processes
Application Layer 2-9
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

Application Layer 2-10

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:
 Q: does IP address  HTTP server: 80
of host
 A: no,onmany
which  mail server: 25
process runs can be
processes  to send HTTP
suffice foron same
running message to
identifying
host the gaia.cs.umass.edu
process? web server:
 IP address:
128.119.245.12
 port number: 80
Application Layer 2-11
 more shortly…
App-layer protocol
defines
 types of messages open protocols:
exchanged,  defined in RFCs
 e.g., request,  allows for
response interoperability
 message syntax:  e.g., HTTP, SMTP
 what fields in proprietary
messages & how protocols:
fields are  e.g., Skype
delineated
 message semantics
 meaning of
information in
fields
 rules for when and
how processes send
& respond to Application Layer 2-12
What transport service does
an app need?
data integrity throughput
 some apps (e.g.,  some apps (e.g.,
file transfer, web multimedia)
transactions) require minimum
require 100% amount of
reliable data throughput to be
transfer “ effective”
 other apps (e.g.,  other apps
timing
(“ elastic apps” )
 audio) can (e.g.,
some apps tolerate
some loss make use of
Internet whatever
security
telephony,
interactive  throughput
encryption,they
data
get
games) require integrity, …
low delay to be
“ effective”
Application Layer 2-13
 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

Application Layer 2-14

Internet transport
protocols services
TCP service: UDP service:
 reliable transport  unreliable data
between sending and transfer between
receiving process sending and
 flow control: receiving process
sender won’ t
overwhelm receiver
 does not provide:
 congestion control: reliability, flow
throttle sender control,
when network congestion
overloaded control, timing,
 does not provide: throughput
timing, minimum guarantee,
throughput security,
guarantee, security orconnection
 connection- setup,
oriented: setup Application Layer 2-15
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

Application Layer 2-16

Securing TCP

TCP & UDP SSL is at app

 no encryption layer
 cleartext  Apps use SSL

passwds sent libraries,

into socket which “ talk”
traverse to TCP
Internet in SSL socket API
cleartext  cleartext
SSL passwds sent
 provides into socket
encrypted TCP traverse
connection Internet
 data integrity
encrypted Application Layer 2-17
Chapter 2: outline
2.1 principles 2.6 P2P
of network applications
applications 2.7 socket
 app programming
architectures with UDP and
 app TCP
requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic
mail
 SMTP, POP3,
IMAP
Application Layer 2-18
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

Application Layer 2-19

HTTP overview
HTTP: hypertext
transfer HT
protocol TP
req
ues
t
 Web’ s application PC running
Firefox browser HTT
layer protocol Pr
esp
 client/server ons
e
model t
ues
 client: browser Pr
e q
T e server
that requests, HT
s po
ns running
receives, TPr
e Apache Web
(using HTTP HT server
protocol) and
“ displays” Web iphone running
objects Safari browser
 server: Web
server sends
(using HTTP Application Layer 2-20
HTTP overview
(continued)
uses TCP: HTTP is
 client initiates “ stateless”
TCP connection  server
(creates socket) maintains no
to server, port information
80 about past aside
client that
protocols
 server accepts TCP requests “ state”
connection from maintain
client are complex!
 past history (state)
 HTTP messages must be maintained
(application-layer  if server/client
protocol messages) crashes, their views
exchanged between of “ state” may be
browser (HTTP inconsistent, must be
client) and Web reconciled
server (HTTP Application Layer 2-21
HTTP connections
non-persistent persistent HTTP
HTTP  multiple
 at most one objects can be
object sent sent over
over TCP single TCP
connection connection
 connection between client,
then closed server
 downloading
multiple
objects
required
multiple Application Layer 2-22
 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
Application Layer 2-23
 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
time objects
6. Steps 1-5 repeated
for each of 10 jpeg
objects

Application Layer 2-24

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

non-persistent persistent
HTTP issues: HTTP:
 requires 2 RTTs  server leaves
per object connection open
 OS overhead for after sending
each TCP response
connection  subsequent HTTP
 browsers often messages between
open parallel TCP same
connections to client/server
fetch referenced sent over open
objects connection
 client sends
requests as soon
as it encounters
a referencedApplication Layer 2-26
 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
Application Layer 2-27
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

Application Layer 2-28

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

Application Layer 2-29

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

Application Layer 2-30

 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
Application Layer 2-31
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
Application Layer 2-32
 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
Application Layer 2-33
User-server state:
cookies
example:
many Web sites use  Susan always access
cookies Internet from PC
four components:  visits specific e-
1) cookie header commerce site for
line of HTTP first time
response  when initial HTTP
message requests arrives at
2) cookie header site, site creates:
line in next  unique ID
HTTP request  entry in backend
message database for ID
3) cookie file
kept on user’ s
host, managed
Application Layer 2-34
by user’ s
 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
Application Layer 2-35
Cookies (continued)
aside
what cookies can cookies and
be used for: privacy:
 authorization
 cookies permit
 shopping carts
sites to learn a
 recommendations
lot about you
 user session
 you may supply
state (Web e-
mail) 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
Application Layer 2-36
Web caches (proxy
server)
goal: satisfy client request without
involving origin server
 user sets
browser: Web
accesses via HT
TP proxy e st
cache req
uesserver TP re
q u
 browser sends all HT t HT
client TP o n se
res p origin
HTTP requests to pon P res
e sst e HTT server
cache req
u
TP
 object in HT
n se
po
cache: cache res
TP
returns object H T

 else cache client origin

requests object server
from origin
server, then Application Layer 2-37
returns object
More about Web caching
 cache acts as why Web caching?
both client and  reduce response
server time for client
 server for request
original
requesting client  reduce traffic on
 client to origin
server
an institution’ s
access link
 typically cache  Internet dense
is installed by
ISP with caches:
(university, enables “ poor”
company, content providers
residential to effectively
ISP) deliver content
Application Layer 2-38
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%
Application Layer 2-39
 total delay = Internet
 Caching example: fatter
access link
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
154 1.54 Mbps
 RTT from institutional 154 Mbps
access link
router to any origin Mbps
server: 2 sec institutional
 access link rate: 1.54 network
9.9% 1 Gbps LAN
Mbps
consequences:
 LAN utilization:
msecs 15%
 access link utilization =
Cost:
99%increased access link speed (not cheap!)
 total delay = Internet Application Layer 2-40
Caching example: install
local cache
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 institutional
 access link rate: 1.54 network
? 1 Gbps LAN
Mbps ?
local web
How to compute link
consequences: cache
 utilization,
LAN utilization: delay?
15%
 access link utilization =
Cost: web cache (cheap!)
100%
 total delay = Internet Application Layer 2-41
Caching example: install
local cache
Calculating access
link utilization, origin
delay with cache: servers
 suppose public
cache hit rate Internet
is 0.4
access link satisfied
 40% requests
at cache, 60% requests
utilization:
satisfied
 60% at origin
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)
.58 +0.4 * (delay when 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 HTTP request msg
object
If-modified-since: <date>
cached version not
 no object modified
transmission delay HTTP response
before
HTTP/1.0
 lower link 304 Not Modified <date>
utilization
 cache: specify
date of cached
copy in HTTP HTTP request msg
request If-modified-since: <date> object
If-modified-since: modified
<date> HTTP response after
HTTP/1.0 200 OK <date>
 server: response <data>
contains no
object if cached Application Layer 2-43
Chapter 2: outline
2.1 principles 2.6 P2P
of network applications
applications 2.7 socket
 app programming
architectures with UDP and
 app TCP
requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic
mail
 SMTP, POP3,
IMAP
Application Layer 2-44
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
Application Layer 2-45
FTP: separate control, data
connections
TCP control connection,
 FTP client contacts server port 21
FTP server at port
21, using TCP
TCP data connection,
 client authorized FTP server port 20 FTP
over control client server
connection
 client browses  server opens
remote directory, another TCP data
sends commands over connection to
control connection transfer another
file
 when server receives
file transfer  control connection:
command, server “ out of band”
opens 2nd TCP data  FTP server
connection (for maintains “ state” :
file) to client current directory, Application Layer 2-46
FTP commands, responses
sample commands: sample return
 sent as ASCII codes
text over control  status code and
channel phrase (as in
 USER username HTTP)
 PASS password  331 Username OK,
 LIST return list password required
of file in  125 data
current directory connection
already open;
 RETR filename transfer starting
retrieves (gets)
file
 425 Can’t open
data connection
 STOR filename  452 Error writing
stores (puts) file
file onto remote Application Layer 2-47
Chapter 2: outline
2.1 principles 2.6 P2P
of network applications
applications 2.7 socket
 app programming
architectures with UDP and
 app TCP
requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic
mail
 SMTP, POP3,
IMAP
Application Layer 2-48
Electronic mail outgoing
message queue
user mailbox
Three major user
agent
components:
 user agents mail user
server agent
 mail servers
 simple mail SMTP mail user
transfer protocol: server agent
SMTP SMTP
SMTP user
User Agent mail
agent
server
 a.k.a. “ mail user
reader” agent
 composing, user
editing, reading agent
mail messages
 e.g., Outlook, Application Layer 2-49
Electronic mail: mail
servers
mail servers: user
agent
 mailbox contains
incoming messages mail user
server
for user agent
 message queue of SMTP mail user
outgoing (to be server agent
sent) mail SMTP
messages
 SMTP protocol SMTP user
agent
mail
between mail server
servers to send user
email messages agent

 client: sending user

agent
mail server
 “ server” :
receiving mail Application Layer 2-50
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
Application Layer 2-51
Scenario: Alice sends
message to Bob
1) Alice uses UA to 4) SMTP client sends
compose message Alice’ s message
“ to” over the TCP
bob@someschool.edu connection
2) Alice’ s UA sends 5) Bob’ s mail server
message to her mail places the message
server; message in Bob’ s mailbox
placed in message 6) Bob invokes his
queue user agent to read
3) client side of message
SMTP opens TCP
connection with Bob
user
’ 1susermail server
mail mail
agent
agent server server
2 3 6
4
5
Alice’s mail server Bob’s mail server
Application Layer 2-52
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

Application Layer 2-53

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)

Application Layer 2-54

SMTP: final words
 SMTP uses comparison with
persistent HTTP:
connections
 SMTP requires
 HTTP: pull
message (header &  SMTP: push
body) to be in 7-
bit ASCII
 both have ASCII
command/response
 SMTP server uses interaction,
CRLF.CRLF to status codes
determine end of
message  HTTP: each object
encapsulated in
its own response
msg
 SMTP: multiple
Application Layer 2-55
objects sent in
Mail message format
SMTP: protocol for
exchanging email header
msgs blank
line
RFC 822: standard
for text message
format:
body
 header lines,
e.g.,
 To:
 From:
 Subject:
different from
SMTP MAIL FROM,
RCPT TO:
commands!
Application Layer 2-56

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. Application Layer 2-57
POP3 protocol
S: +OK POP3 server ready
C: user bob
authorization S: +OK
C: pass hungry
phase S: +OK user successfully logged on
 client commands:
C: list
 user: declare
username S: 1 498
S: 2 912
 pass: password
S: .
 server responses C: retr 1
 +OK S: <message 1 contents>
 -ERR S: .
C: dele 1
transaction C: retr 2
phase, client: S: <message 1 contents>
 list: list message S: .
numbers C: dele 2
 retr: retrieve message C: quit
by number S: +OK POP3 server signing off
 dele: delete Application Layer 2-58
POP3 (more) and IMAP
more about POP3 IMAP
 previous example  keeps all
uses POP3 messages in one
“ download and place: at server
delete” mode  allows user to
 Bob cannot re- organize messages
read e-mail if in folders
he changes  keeps user state
client across sessions:
 POP3 “ download-  names of
and-keep” : copies folders and
of messages on mappings
different clients between message
 POP3 is stateless IDs and folder
across sessions name
Application Layer 2-59
Chapter 2: outline
2.1 principles 2.6 P2P
of network applications
applications 2.7 socket
 app programming
architectures with UDP and
 app TCP
requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic
mail
 SMTP, POP3,
IMAP
Application Layer 2-60
DNS: domain name system
people: many Domain Name System:
identifiers:  distributed database
 SSN, name, implemented in
passport # hierarchy of many
Internet hosts, name servers
routers:  application-layer
 IP address (32 protocol: hosts,
bit) - used for name servers
addressing communicate to
datagrams resolve names
 “ name” , e.g., (address/name
www.yahoo.com - translation)
used by humans  note: core Internet
function,
Q: how to map
implemented as
between IP application-layer
Application Layer 2-61
address and name,
DNS: services, structure
DNS services why not centralize
 hostname to IP DNS?
address  single point of
translation failure
 host aliasing  traffic volume
 canonical, alias  distant centralized
names
database
A: doesn’t scale!
 mail server  maintenance
aliasing
 load distribution
 replicated Web
servers: many
IP addresses
correspond to
one name
Application Layer 2-62
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; 1st

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
Application Layer 2-63
 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)

Application Layer 2-64

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 Application Layer 2-65
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

Application Layer 2-66

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
”
Application Layer 2-67
DNS name
resolution root DNS server

example 2 3
7
recursive query: 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

Application Layer 2-68

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
Application Layer 2-69
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
real) name
type=NS
 name is domain
 www.ibm.com is really
(e.g., foo.com) servereast.backup2.ibm.com
 value is  value is canonical name
hostname of type=MX
authoritative  value is name of
name server for
this domain mailserver associated
with name
Application Layer 2-70
DNS protocol, messages
 query and reply messages, both
with same message 2 bytes
format 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
Application Layer 2-71
 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
Application Layer 2-72
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
Application Layer 2-73
Attacking DNS
DDoS attacks Redirect attacks
 Bombard root  Man-in-middle
servers with  Intercept
traffic queries
 Not successful  DNS poisoning
to date  Send bogus
 Traffic relies to DNS
Filtering server, which
 Local DNS caches
servers cache Exploit DNS for
IPs of TLD DDoS
servers,
allowing root  Send queries
server bypass with spoofed
source address:
Application Layer 2-74

Chapter 2: outline
2.1 principles 2.6 P2P
of network applications
applications 2.7 socket
 app programming
architectures with UDP and
 app TCP
requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic
mail
 SMTP, POP3,
IMAP
Application Layer 2-75
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)
Application Layer 2-76
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

Application Layer 2-77

File distribution time:
client-server
 server
transmission: must F
us
sequentially send
(upload) N file di

copies: network
ui
 time to send one
 client: each client
copy: F/us
must download file
 time to send N
copy
 copies: NF/us
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
Application Layer 2-78
File distribution time: P2P
 server
transmission: must F
u
upload at least one s

 copy
di
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
Application Layer 2-79
 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
Application Layer 2-80
 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

Application Layer 2-81

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
 while of peers
downloading, peer uploads chunks to
(“ neighbors”
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)
Application Layer 2-82
BitTorrent: requesting,
sending file chunks
requesting sending chunks: tit-
chunks: for-tat
 at any given time,  Alice sends chunks to
different peers those four peers
have different currently sending her
subsets of file chunks at highest
chunks rate
 periodically,  other peers are choked
Alice asks each by Alice (do not
peer for list of receive chunks from
her)
chunks that they
 re-evaluate top 4
have every10 secs
 Alice requests  every 30 secs:
missing chunks randomly select
from peers, rarest another peer, Application
starts
first 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: human name; value: social
Key Value
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
 If key = 60, then assigned to peer 60
 If key = 61, then assigned to peer 1
 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
aliveness
example: peer 5 abruptly leaves
if immediate
peer 4 detects peer 5’ s departure;
successor leaves,
makes 8 its immediatechoose
successor
next successor
 4 asks 8 who its immediate successor
as new immediate
is; makes 8’ s immediate successor its
successor
second successor.
Chapter 2: outline
2.1 principles 2.6 P2P
of network applications
applications 2.7 socket
 app programming
architectures with UDP and
 app TCP
requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic
mail
 SMTP, POP3,
IMAP
Application Layer 2-95
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 socket application
controlled by
process process app developer

transport transport
network network controlled
link
by OS
link Internet
physical physical

Application Layer 2-96

 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
Application Layer 2-97
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 Application Layer 2-98
 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
include Python’s socket
library
create UDP socket for
server
get user keyboard
input
Attach server name, port to
message; send into socket
read reply characters from
socket into string
print out received string
and close socket
Python UDPClient
from socket import *
serverName = ‘hostname’
serverPort = 12000
clientSocket = socket(socket.AF_INET,
socket.SOCK_DGRAM)
message = raw_input(’Input lowercase sentence:’)
clientSocket.sendto(message,(serverName, serverPort))
modifiedMessage, serverAddress =
clientSocket.recvfrom(2048)
print modifiedMessage
clientSocket.close()
Application Layer 2-100
 Example app: UDP server
create UDP socket
bind socket to local port
number 12000
loop forever
Read from UDP socket into
message, getting client’s
address (client IP and port)
send upper case string
back to this client
Python UDPServer
from socket import *
serverPort = 12000
serverSocket = socket(AF_INET, SOCK_DGRAM)
serverSocket.bind(('', serverPort))
print “The server is ready to receive”
while 1:
message, clientAddress = serverSocket.recvfrom(2048)
modifiedMessage = message.upper()
serverSocket.sendto(modifiedMessage, clientAddress)
Application Layer 2-101
Socket programming with
TCP
client must contact when contacted by

server client, server TCP
 server process must creates new socket
first be running for server process
 server must have
to communicate with
that particular
created socket client
(door) that
welcomes client’ s  allows server to
contact talk with multiple
clients
client contacts  source port
server by: application viewpoint:
numbers used to
 Creating TCP distinguish
TCP provides reliable, in-ord
clients
socket, specifyingbyte-stream (more in
transfer (“ pipe”
IP address, port between Chap 3) and server
client
number of server
process
 when client creates Application Layer 2-102
 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

Application Layer 2-103

 Example app: TCP client
Python TCPClient
from socket import *
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()

Application Layer 2-104

 Example app: TCP server
create TCP welcoming
socket
server begins listening for
incoming TCP requests
loop forever
server waits on accept()
for incoming requests, new
socket created on return
read bytes from socket (but
not address as in UDP)
close connection to this
client (but not welcoming
socket)
Python TCPServer
from socket import *
serverPort = 12000
serverSocket = socket(AF_INET,SOCK_STREAM)
serverSocket.bind((‘’,serverPort))
serverSocket.listen(1)
print ‘The server is ready to receive’
while 1:
connectionSocket, addr = serverSocket.accept()
sentence = connectionSocket.recv(1024)
capitalizedSentence = sentence.upper()
connectionSocket.send(capitalizedSentence)
connectionSocket.close()
Application Layer 2-105
Chapter 2:
summary
our study of network apps now
complete!
 application  specific
architectures protocols:
 client-server  HTTP
 P2P
 FTP
 application service
requirements:  SMTP, POP, IMAP
 reliability,  DNS
bandwidth, delay  P2P: BitTorrent,
 Internet transport DHT
service model
 socket
 connection-
oriented, programming: TCP,
reliable: TCP UDP sockets
 unreliable, Application Layer 2-106
Chapter 2:
summary
most importantly: learned about
protocols!
 typical
important themes:
request/reply
message exchange:  control vs. data
 client requests msgs
info or service  in-band, out-of-
 server responds band
with data,  centralized vs.
status code
decentralized
 message formats:
 stateless vs.
 headers: fields
giving info stateful
about data  reliable vs.
 data: info unreliable msg
being transfer Application Layer 2-107
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