Chapter 2: outline

Chapter 2
Application Layer 2.1 principles of network 2.6 P2P applications
applications 2.7 socket programming
2.2 Web and HTTP with UDP and TCP
2.3 FTP
A note on the use of these ppt slides:
We’re making these slides freely available to all (faculty, students, readers). Computer 2.4 electronic mail
They’re in PowerPoint form so you see the animations; and can add, modify,
and delete slides (including this one) and slide content to suit your needs. Networking: A Top § SMTP, POP3, IMAP
They obviously represent a lot of work on our part. In return for use, we only
ask the following: Down Approach 2.5 DNS
v If you use these slides (e.g., in a class) that you mention their source
(after all, we’d like people to use our book!)
6th edition
v If you post any slides on a www site, that you note that they are adapted Jim Kurose, Keith Ross
from (or perhaps identical to) our slides, and note our copyright of this Addison-Wesley
material.
March 2012
Thanks and enjoy! JFK/KWR

All material copyright 1996-2012

J.F Kurose and K.W. Ross, All Rights Reserved

Application Layer 2-1 Application Layer 2-2

Chapter 2: application layer Some network apps

our goals: v learn about protocols by
v conceptual, examining popular v e-mail v voice over IP (e.g., Skype)
implementation aspects application-level v web v real-time video
of network application protocols v text messaging conferencing
protocols § HTTP v remote login v social networking
§ transport-layer § FTP v P2P file sharing v search
service models § SMTP / POP3 / IMAP
v multi-user network games v …
§ client-server § DNS
v streaming stored video v …
paradigm v creating network
applications (YouTube, Hulu, Netflix)
§ peer-to-peer
paradigm § socket API

Application Layer 2-3 Application Layer 2-4

Creating a network app application
transport
Application architectures
network
data link

write programs that: physical

v run on (different) end systems

possible structure of applications:
v communicate over network
v client-server
v e.g., web server software
communicates with browser v peer-to-peer (P2P)
software
no need to write software for application

network-core devices transport

network
data link application
v network-core devices do not physical transport
network
run user applications data link
physical

v applications on end systems

allows for rapid app
development, propagation

Application Layer 2-5 Application Layer 2-6

Client-server architecture P2P architecture

v no always-on server peer-peer
server:
v arbitrary end systems
v always-on host directly communicate
v permanent IP address v peers request service from
v data centers for scaling other peers, provide service
in return to other peers
clients: § self scalability – new
v communicate with server peers bring new service
client/server v may be intermittently capacity, as well as new
connected service demands
v may have dynamic IP v peers are intermittently
addresses connected and change IP
v do not communicate directly addresses
with each other § complex management

Application Layer 2-7 Application Layer 2-8

Processes communicating Sockets
v process sends/receives messages to/from its socket
process: program running clients, servers v socket analogous to door
within a host client process: process that § sending process shoves message out door
v within same host, two initiates communication § sending process relies on transport infrastructure on
processes communicate server process: process that other side of door to deliver message to socket at
using inter-process waits to be contacted receiving process
communication (defined by
OS) application
application socket controlled by
v processes in different hosts process process app developer
communicate by exchanging v aside: applications with P2P
transport
messages architectures have client transport
network network controlled
processes & server link Internet link
by OS
processes physical physical

Application Layer 2-9 Application Layer 2-10

Addressing processes App-layer protocol defines

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

Application Layer 2-11 Application Layer 2-12

What transport service does an app need? Transport service requirements: common apps
data integrity throughput
v some apps (e.g., file transfer, v some apps (e.g.,
application data loss throughput time sensitive
web transactions) require multimedia) require
100% reliable data transfer minimum amount of file transfer no loss elastic no
v other apps (e.g., audio) can
throughput to be e-mail no loss elastic no
tolerate some loss “effective” Web documents no loss elastic no
v other apps (“elastic apps”) real-time audio/video loss-tolerant audio: 5kbps-1Mbps yes, 100’s
make use of whatever video:10kbps-5Mbps msec
timing stored audio/video loss-tolerant same as above
throughput they get
v some apps (e.g., Internet interactive games loss-tolerant few kbps up yes, few secs
telephony, interactive security text messaging no loss elastic yes, 100’s
games) require low delay msec
to be “effective” v encryption, data integrity, yes and no
…

Application Layer 2-13 Application Layer 2-14

Internet transport protocols services Internet apps: application, transport protocols

TCP service: UDP service: application underlying

application layer protocol transport protocol
v reliable transport between v unreliable data transfer
sending and receiving between sending and
process e-mail SMTP [RFC 2821] TCP
receiving process remote terminal access Telnet [RFC 854]
v flow control: sender won’t TCP
overwhelm receiver v does not provide: Web HTTP [RFC 2616] TCP
reliability, flow control, file transfer FTP [RFC 959] TCP
v congestion control: throttle congestion control,
sender when network streaming multimedia HTTP (e.g., YouTube), TCP or UDP
overloaded timing, throughput RTP [RFC 1889]
v does not provide: timing, guarantee, security, Internet telephony SIP, RTP, proprietary
minimum throughput orconnection setup, (e.g., Skype) TCP or UDP
guarantee, security
v connection-oriented: setup Q: why bother? Why is
required between client and there a UDP?
server processes

Application Layer 2-15 Application Layer 2-16

Securing TCP Chapter 2: outline
TCP & UDP SSL is at app layer 2.1 principles of network 2.6 P2P applications
v no encryption v Apps use SSL libraries, applications 2.7 socket programming
v cleartext passwds sent which “talk” to TCP § app architectures with UDP and TCP
into socket traverse SSL socket API § app requirements
Internet in cleartext v cleartext passwds sent
2.2 Web and HTTP
SSL into socket traverse 2.3 FTP
v provides encrypted Internet encrypted 2.4 electronic mail
TCP connection v See Chapter 7 § SMTP, POP3, IMAP
v data integrity 2.5 DNS
v end-point
authentication
Application Layer 2-17 Application Layer 2-18

Web and HTTP HTTP overview

First, a review… HTTP: hypertext
v web page consists of objects transfer protocol HT
v Web’s application layer TP
req
v object can be HTML file, JPEG image, Java applet, protocol PC running HT
ues
t
audio file,… v client/server model Firefox browser TP
res
pon
se
v web page consists of base HTML-file which § client: browser that
includes several referenced objects requests, receives, st
(using HTTP protocol) ue
eq
v each object is addressable by a URL, e.g., and “displays” Web T Pr ns
e server
HT sp
o running
objects TP
re Apache Web
www.someschool.edu/someDept/pic.gif § server: Web server HT server
sends (using HTTP
host name path name protocol) objects in iphone running
response to requests Safari browser

Application Layer 2-19 Application Layer 2-20

 HTTP overview (continued) HTTP connections
uses TCP: HTTP is “stateless” non-persistent HTTP persistent HTTP
client initiates TCP v server maintains no
v at most one object
v
information about v multiple objects can
connection (creates
socket) to server, port 80 past client requests sent over TCP be sent over single
v server accepts TCP connection TCP connection
connection from client aside § connection then between client, server
protocols that maintain
v HTTP messages “state” are complex! closed
(application-layer protocol v downloading multiple
v past history (state) must be
messages) exchanged
between browser (HTTP
maintained objects required
client) and Web server
v if server/client crashes, their multiple connections
views of “state” may be
(HTTP server) inconsistent, must be
v TCP connection closed reconciled

Application Layer 2-21 Application Layer 2-22

Non-persistent HTTP Non-persistent HTTP (cont.)

suppose user enters URL: (contains text,
www.someSchool.edu/someDepartment/home.index references to 10
4. HTTP server closes TCP
jpeg images)
connection.
1a. HTTP client initiates TCP 5. HTTP client receives response
connection to HTTP server message containing html file,
(process) at 1b. HTTP server at host displays html. Parsing html file,
www.someSchool.edu waiting finds 10 referenced jpeg objects
www.someSchool.edu on port
80 for TCP connection at port 80.
“accepts” connection, notifying time
6. Steps 1-5 repeated for each of
2. HTTP client sends HTTP request client
10 jpeg objects
message (containing URL) into
TCP connection socket. 3. HTTP server receives request
Message indicates that client message, forms response
wants object message containing requested
someDepartment/home.index object, and sends message into
its socket
time
Application Layer 2-23 Application Layer 2-24
Non-persistent HTTP: response time Persistent HTTP
RTT (definition): time for a
small packet to travel from non-persistent HTTP issues: persistent HTTP:
client to server and back v requires 2 RTTs per object v server leaves connection
HTTP response time: initiate TCP v OS overhead for each TCP open after sending
v one RTT to initiate TCP
connection connection response
connection RTT v browsers often open v subsequent HTTP
v one RTT for HTTP request
request parallel TCP connections messages between same
file client/server sent over
and first few bytes of HTTP time to
to fetch referenced objects
response to return
RTT transmit open connection
file v client sends requests as
v file transmission time file
received soon as it encounters a
v non-persistent HTTP referenced object
response time =
time time v as little as one RTT for all
2RTT+ file transmission the referenced objects
time

Application Layer 2-25 Application Layer 2-26

HTTP request message HTTP request message: general format

v two types of HTTP messages: request, response method sp URL sp version cr lf request
v HTTP request message: line
header field name value cr lf
§ ASCII (human-readable format)
carriage return character header
line-feed character ~
~ ~
~ lines
request line
(GET, POST, GET /index.html HTTP/1.1\r\n
HEAD commands) Host: www-net.cs.umass.edu\r\n header field name value cr lf
User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n cr lf
header Accept-Language: en-us,en;q=0.5\r\n
lines Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n ~
~ entity body ~
~ body
carriage return, Keep-Alive: 115\r\n
Connection: keep-alive\r\n
line feed at start
\r\n
of line indicates
end of header lines
Application Layer 2-27 Application Layer 2-28
 Uploading form input Method types
POST method:
v web page often includes HTTP/1.0: HTTP/1.1:
form input v GET v GET, POST, HEAD
v input is uploaded to v POST v PUT
server in entity body v HEAD § uploads file in entity
§ asks server to leave body to path specified
URL method: requested object out in URL field
v uses GET method of response v DELETE
v input is uploaded in URL § deletes file specified in
field of request line: the URL field
www.somesite.com/animalsearch?monkeys&banana

Application Layer 2-29 Application Layer 2-30

HTTP response message HTTP response status codes

status line
v status code appears in 1st line in server-to-
(protocol client response message.
status code HTTP/1.1 200 OK\r\n
Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n v some sample codes:
status phrase)
Server: Apache/2.0.52 (CentOS)\r\n 200 OK
Last-Modified: Tue, 30 Oct 2007 17:00:02
GMT\r\n § request succeeded, requested object later in this msg
header ETag: "17dc6-a5c-bf716880"\r\n 301 Moved Permanently
Accept-Ranges: bytes\r\n
lines Content-Length: 2652\r\n § requested object moved, new location specified later in this msg
Keep-Alive: timeout=10, max=100\r\n (Location:)
Connection: Keep-Alive\r\n
Content-Type: text/html; charset=ISO-8859-
400 Bad Request
1\r\n § request msg not understood by server
\r\n
data data data data data ...
404 Not Found
data, e.g.,
§ requested document not found on this server
requested
HTML file 505 HTTP Version Not Supported
Application Layer 2-31 Application Layer 2-32
 Trying out HTTP (client side) for yourself User-server state: cookies
1. Telnet to your favorite Web server: example:
many Web sites use cookies v Susan always access Internet
telnet cis.poly.edu 80 opens TCP connection to port 80 four components: from PC
(default HTTP server port) at cis.poly.edu. 1) cookie header line of v visits specific e-commerce
anything typed in sent HTTP response site for first time
to port 80 at cis.poly.edu
message v when initial HTTP requests
2) cookie header line in arrives at site, site creates:
2. type in a GET HTTP request:
next HTTP request § unique ID
GET /~ross/ HTTP/1.1 by typing this in (hit carriage message
return twice), you send § entry in backend
Host: cis.poly.edu
this minimal (but complete) 3) cookie file kept on database for ID
GET request to HTTP server user’s host, managed
by user’s browser
3. look at response message sent by HTTP server! 4) back-end database at
(or use Wireshark to look at captured HTTP request/response) Web site
Application Layer 2-33 Application Layer 2-34

Cookies: keeping “state” (cont.) Cookies (continued)

client server aside
what cookies can be used cookies and privacy:
for: v cookies permit sites to
ebay 8734
usual http request msg Amazon server v authorization learn a lot about you
cookie file creates ID v shopping carts
usual http response v you may supply name and
1678 for user create backend recommendations
ebay 8734
set-cookie: 1678 entry database
v
e-mail to sites
amazon 1678 v user session state (Web
usual http request msg
e-mail)
cookie: 1678 cookie- access
specific how to keep “state”:
usual http response msg action
v protocol endpoints: maintain state at
one week later: sender/receiver over multiple
access transactions
ebay 8734 usual http request msg
amazon 1678 cookie: 1678 cookie- v cookies: http messages carry state
specific
usual http response msg action
Application Layer 2-35 Application Layer 2-36
Web caches (proxy server) More about Web caching
goal: satisfy client request without involving origin server
v cache acts as both why Web caching?
v user sets browser: Web client and server v reduce response time
accesses via cache § server for original for client request
v browser sends all HTTP proxy
requesting client
requests to cache HT t § client to origin server v reduce traffic on an
TP
req server ues
eq
H ues Pr e institution’s access link
§ object in cache: cache client TTP
res
t HT
T
r esp
ons origin v typically cache is
returns object pon TP
se HT server installed by ISP v Internet dense with
e st
§ else cache requests
Pr
e qu
e (university, company, caches: enables “poor”
object from origin T ns
HT res
po residential ISP) content providers to
server, then returns HT
TP
effectively deliver
object to client
client
content (so too does
origin
server P2P file sharing)

Application Layer 2-37 Application Layer 2-38

Caching example: Caching example: fatter access link

assumptions: assumptions:
v avg object size: 100K bits origin v avg object size: 100K bits origin
v avg request rate from browsers to servers v avg request rate from browsers to servers
origin servers:15/sec public origin servers:15/sec public
v avg data rate to browsers: 1.50 Mbps Internet v avg data rate to browsers: 1.50 Mbps Internet
v RTT from institutional router to any v RTT from institutional router to any
origin server: 2 sec origin server: 2 sec
v access link rate: 1.54 Mbps 1.54 Mbps v access link rate: 1.54 Mbps 1.54 Mbps
154 Mbps 154 Mbps
access link access link
consequences: consequences:
v LAN utilization: 15% problem! institutional v LAN utilization: 15% institutional
network access link utilization = 99% 9.9% network
v access link utilization = 99% 1 Gbps LAN v 1 Gbps LAN
v total delay = Internet delay + v total delay = Internet delay + access
delay + LAN delay
access delay + LAN delay
= 2 sec + minutes + usecs
= 2 sec + minutes + usecs msecs
Cost: increased access link speed (not cheap!)
Application Layer 2-39 Application Layer 2-40
Caching example: install local cache Caching example: install local cache
assumptions: Calculating access link
v avg object size: 100K bits origin utilization, delay with cache: origin
v avg request rate from browsers to servers v suppose cache hit rate is 0.4 servers
origin servers:15/sec public § 40% requests satisfied at cache, public
avg data rate to browsers: 1.50 Mbps Internet Internet
v 60% requests satisfied at origin
v RTT from institutional router to any v access link utilization:
origin server: 2 sec
§ 60% of requests use access link
v access link rate: 1.54 Mbps 1.54 Mbps 1.54 Mbps
v data rate to browsers over access link
access link = 0.6*1.50 Mbps = .9 Mbps access link
consequences:
v LAN utilization: 15% institutional § utilization = 0.9/1.54 = .58 institutional
network v total delay network
v ?
access link utilization = 100% 1 Gbps LAN 1 Gbps LAN
v ?
total delay = Internet delay + access § = 0.6 * (delay from origin servers) +0.4
delay + LAN delay local web * (delay when satisfied at cache) local web
How to compute link
= 2 sec + minutes + usecs cache § = 0.6 (2.01) + 0.4 (~msecs) cache
utilization, delay? § = ~ 1.2 secs
§ less than with 154 Mbps link (and
Cost: web cache (cheap!) cheaper too!)
Application Layer 2-41 Application Layer 2-42

Conditional GET
Chapter 2: outline
client server
v Goal: don’t send object if
cache has up-to-date 2.1 principles of network 2.6 P2P applications
cached version HTTP request msg
object applications 2.7 socket programming
If-modified-since: <date>
§ no object transmission not § app architectures with UDP and TCP
delay modified
§ lower link utilization HTTP response
before
§ app requirements
HTTP/1.0
v cache: specify date of 304 Not Modified
<date> 2.2 Web and HTTP
cached copy in HTTP 2.3 FTP
request
If-modified-since: 2.4 electronic mail
<date> HTTP request msg § SMTP, POP3, IMAP
server: response contains If-modified-since: <date> object
v
modified 2.5 DNS
no object if cached copy after
HTTP response
is up-to-date: HTTP/1.0 200 OK <date>
HTTP/1.0 304 Not <data>
Modified
Application Layer 2-43 Application Layer 2-44
FTP: the file transfer protocol FTP: separate control, data connections
file transfer
FTP TCP control connection,
user
FTP FTP v FTP client contacts FTP server server port 21
client server at port 21, using TCP
interface
user v client authorized over control
at host remote file TCP data connection,
local file system connection FTP server port 20 FTP
system client server
v client browses remote
directory, sends commands
over control connection v server opens another TCP
v transfer file to/from remote host v when server receives file
data connection to transfer
client/server model another file
v transfer command, server
§ client: side that initiates transfer (either to/from remote) opens 2nd TCP data v control connection: “out of
connection (for file) to client band”
§ server: remote host
v after transferring one file, v FTP server maintains
v ftp: RFC 959 server closes data connection “state”: current directory,
v ftp server: port 21 earlier authentication

Application Layer 2-45 Application Layer 2-46

FTP commands, responses Chapter 2: outline

sample commands: sample return codes
v sent as ASCII text over v status code and phrase (as 2.1 principles of network 2.6 P2P applications
control channel in HTTP) applications 2.7 socket programming
v USER username v 331 Username OK, § app architectures with UDP and TCP
v PASS password password required § app requirements
LIST return list of file in v 125 data 2.2 Web and HTTP
connection
v
current directory already open; 2.3 FTP
v RETR filename transfer starting 2.4 electronic mail
retrieves (gets) file v 425 Can’t open § SMTP, POP3, IMAP
v STOR filename stores data connection
2.5 DNS
(puts) file onto remote v 452 Error writing
host file

Application Layer 2-47 Application Layer 2-48

Electronic mail outgoing
message queue
Electronic mail: mail servers
user mailbox
Three major components: user mail servers: user
agent agent
v user agents v mailbox contains incoming
v mail servers mail user messages for user mail user
server agent server agent
v simple mail transfer v message queue of outgoing
protocol: SMTP SMTP mail user (to be sent) mail messages SMTP mail user
server agent v SMTP protocol between server agent
SMTP mail servers to send email SMTP
User Agent messages
v a.k.a. “mail reader” SMTP user SMTP user
mail
agent § client: sending mail mail
agent
v composing, editing, reading server server server
mail messages user
§ “server”: receiving mail user
agent agent
v e.g., Outlook, Thunderbird, server
iPhone mail client user user
agent agent
v outgoing, incoming
messages stored on server
Application Layer 2-49 Application Layer 2-50

Electronic Mail: SMTP [RFC 2821] Scenario: Alice sends message to Bob
1) Alice uses UA to compose 4) SMTP client sends Alice’s
v uses TCP to reliably transfer email message from message “to” message over the TCP
client to server, port 25 [email protected] connection
v direct transfer: sending server to receiving 2) Alice’s UA sends message 5) Bob’s mail server places the
server to her mail server; message message in Bob’s mailbox
placed in message queue 6) Bob invokes his user agent
v three phases of transfer 3) client side of SMTP opens to read message
§ handshaking (greeting) TCP connection with Bob’s
§ transfer of messages mail server
§ closure
v command/response interaction (like HTTP, FTP) 1 user mail user
mail agent
§ commands: ASCII text agent server server
2
§ response: status code and phrase 3 4 6

v messages must be in 7-bit ASCI Alice’s mail server

5
Bob’s mail server
Application Layer 2-51 Application Layer 2-52
Sample SMTP interaction Try SMTP interaction for yourself:
S: 220 hamburger.edu
C: HELO crepes.fr v telnet servername 25
S: 250 Hello crepes.fr, pleased to meet you v see 220 reply from server
C: MAIL FROM: <[email protected]>
S: 250 [email protected]... Sender ok v enter HELO, MAIL FROM, RCPT TO, DATA, QUIT
C: RCPT TO: <[email protected]> commands
S: 250 [email protected] ... Recipient ok
C: DATA above lets you send email without using email client (reader)
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 Application Layer 2-54

SMTP: final words Mail message format

v SMTP uses persistent comparison with HTTP: SMTP: protocol for
connections exchanging email msgs header
v HTTP: pull blank
v SMTP requires message RFC 822: standard for text
v SMTP: push line
(header & body) to be in message format:
7-bit ASCII v header lines, e.g.,
v both have ASCII
v SMTP server uses command/response § To: body
CRLF.CRLF to interaction, status codes § From:
determine end of message § Subject:
v HTTP: each object different from SMTP MAIL
encapsulated in its own FROM, RCPT TO:
response msg commands!
v SMTP: multiple objects v Body: the “message”
sent in multipart msg § ASCII characters only

Application Layer 2-55 Application Layer 2-56

Mail access protocols POP3 protocol
S: +OK POP3 server ready
C: user bob
mail access S: +OK
user
agent
SMTP SMTP protocol
user
agent
authorization phase C: pass hungry
(e.g., POP, v client commands: S: +OK user successfully logged on
IMAP) § user: declare username
§ pass: password C: list
sender’s mail receiver’s mail
server
S: 1 498
server server responses S: 2 912
v
§ +OK S: .
v SMTP: delivery/storage to receiver’s server
§ -ERR C: retr 1
v mail access protocol: retrieval from server S: <message 1 contents>
§ POP: Post Office Protocol [RFC 1939]: authorization, transaction phase, client: S: .
download v list: list message numbers C: dele 1
§ IMAP: Internet Mail Access Protocol [RFC 1730]: more v retr: retrieve message by C: retr 2
features, including manipulation of stored msgs on number S: <message 1 contents>
server v dele: delete S: .
v quit C: dele 2
§ HTTP: gmail, Hotmail, Yahoo! Mail, etc. C: quit
S: +OK POP3 server signing off
Application Layer 2-57 Application Layer 2-58

POP3 (more) and IMAP Chapter 2: outline

more about POP3 IMAP
v previous example uses v keeps all messages in one
2.1 principles of network 2.6 P2P applications
POP3 “download and place: at server applications 2.7 socket programming
delete” mode v allows user to organize § app architectures with UDP and TCP
§ Bob cannot re-read e- messages in folders § app requirements
mail if he changes v keeps user state across 2.2 Web and HTTP
client sessions:
v POP3 “download-and- 2.3 FTP
§ names of folders and
keep”: copies of messages mappings between 2.4 electronic mail
on different clients message IDs and folder § SMTP, POP3, IMAP
v POP3 is stateless across name
sessions 2.5 DNS

Application Layer 2-59 Application Layer 2-60

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

Application Layer 2-61 Application Layer 2-62

DNS: a distributed, hierarchical database DNS: root name servers

Root DNS Servers
v contacted by local name server that can not resolve name
… … v root name server:
com DNS servers org DNS servers edu DNS servers § contacts authoritative name server if name mapping not known
§ gets mapping
yahoo.com pbs.org poly.edu umass.edu § returns mapping to local name server
amazon.com DNS serversDNS servers
DNS servers DNS servers DNS servers
c. Cogent, Herndon, VA (5 other sites)
d. U Maryland College Park, MD k. RIPE London (17 other sites)
h. ARL Aberdeen, MD

client wants IP for www.amazon.com; 1st approx: j. Verisign, Dulles VA (69 other sites ) i. Netnod, Stockholm (37 other sites)

e. NASA Mt View, CA m. WIDE Tokyo

v client queries root server to find com DNS server f. Internet Software C. (5 other sites)
Palo Alto, CA (and 48 other
v client queries .com DNS server to get amazon.com DNS server sites)

v client queries amazon.com DNS server to get IP address for a. Verisign, Los Angeles CA 13 root name
www.amazon.com (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-63 Application Layer 2-64

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

Application Layer 2-65 Application Layer 2-66

DNS name root DNS server DNS name root DNS server
resolution example resolution example
2 2 3
v host at cis.poly.edu 3
TLD DNS server recursive query: 7
6
wants IP address for 4
gaia.cs.umass.edu v puts burden of name TLD DNS
5 server
resolution on
local DNS server contacted name local DNS server
iterated query: dns.poly.edu server dns.poly.edu 5 4
v contacted server 7 6
replies with name of
1 8 v heavy load at upper 1 8

server to contact levels of hierarchy?

authoritative DNS server authoritative DNS server
v “I don’t know this dns.cs.umass.edu dns.cs.umass.edu
name, but ask this requesting host requesting host
cis.poly.edu cis.poly.edu
server”
gaia.cs.umass.edu gaia.cs.umass.edu

Application Layer 2-67 Application Layer 2-68

DNS: caching, updating records DNS records
v once (any) name server learns mapping, it caches DNS: distributed db storing resource records (RR)
mapping RR format: (name, value, type, ttl)
§ cache entries timeout (disappear) after some time (TTL)
§ TLD servers typically cached in local name servers type=A type=CNAME
• thus root name servers not often visited
§ name is hostname § name is alias name for some
v cached entries may be out-of-date (best effort § value is IP address “canonical” (the real) name
name-to-address translation!) type=NS § www.ibm.com is really
§ if name host changes IP address, may not be known § name is domain (e.g., servereast.backup2.ibm.com
Internet-wide until all TTLs expire foo.com) § value is canonical name
v update/notify mechanisms proposed IETF standard § value is hostname of
authoritative name type=MX
§ RFC 2136 server for this domain
§ value is name of mailserver
associated with name

Application Layer 2-69 Application Layer 2-70

DNS protocol, messages DNS protocol, messages

v query and reply messages, both with same message
format 2 bytes 2 bytes 2 bytes 2 bytes

msg header identification flags identification flags

v identification: 16 bit # for # questions # answer RRs # questions # answer RRs

query, reply to query uses
# authority RRs # additional RRs # authority RRs # additional RRs
same #
flags: name, type fields
v questions (variable # of questions) questions (variable # of questions)
for a query
§ query or reply
§ recursion desired answers (variable # of RRs) RRs in response answers (variable # of RRs)
to query
§ recursion available
records for
§ reply is authoritative authority (variable # of RRs) authority (variable # of RRs)
authoritative servers

additional info (variable # of RRs) additional “helpful” additional info (variable # of RRs)
info that may be used
Application Layer 2-71 Application Layer 2-72
Inserting records into DNS Attacking DNS
v example: new startup “Network Utopia”
DDoS attacks Redirect attacks
v register name networkuptopia.com at DNS registrar
v Bombard root servers v Man-in-middle
(e.g., Network Solutions)
§ provide names, IP addresses of authoritative name server
with traffic § Intercept queries
(primary and secondary) § Not successful to date v DNS poisoning
§ registrar inserts two RRs into .com TLD server: § Traffic Filtering § Send bogus relies to
(networkutopia.com, dns1.networkutopia.com, NS) § Local DNS servers DNS server, which
(dns1.networkutopia.com, 212.212.212.1, A) cache IPs of TLD caches
v create authoritative server type A record for servers, allowing root Exploit DNS for DDoS
www.networkuptopia.com; type MX record for server bypass
v Send queries with
networkutopia.com v Bombard TLD servers
spoofed source
§ Potentially more
dangerous address: target IP
v Requires amplification
Application Layer 2-73 Application Layer 2-74

Chapter 2: outline Pure P2P architecture

v no always-on server
2.1 principles of network 2.6 P2P applications v arbitrary end systems
applications 2.7 socket programming directly communicate
§ app architectures with UDP and TCP v peers are intermittently
§ app requirements connected and change IP
addresses
2.2 Web and HTTP
2.3 FTP examples:
2.4 electronic mail § file distribution
(BitTorrent)
§ SMTP, POP3, IMAP § Streaming (KanKan)
2.5 DNS § VoIP (Skype)

Application Layer 2-75 Application Layer 2-76

File distribution: client-server vs P2P File distribution time: client-server
Question: how much time to distribute file (size F) from v server transmission: must
one server to N peers? sequentially send (upload) N F
us
§ peer upload/download capacity is limited resource file copies:
di
§ time to send one copy: F/us
network
us: server upload § time to send N copies: NF/us ui
capacity
v client: each client must
download file copy
di: peer i download
file, size F u1 d1 capacity § dmin = min client download rate
us u2 d2
server § min client download time: F/dmin
di
uN network (with abundant time to distribute F
bandwidth) ui
dN
to N clients using Dc-s > max{NF/us,,F/dmin}
client-server approach
ui: peer i upload
capacity
increases linearly in N
Application Layer 2-77 Application Layer 2-78

File distribution time: P2P Client-server vs. P2P: example

v server transmission: must client upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us
upload at least one copy F
us
§ time to send one copy: F/us
di
v client: each client must network
download file copy ui
§ min client download time: F/dmin
v clients: as aggregate must download NF bits
§ max upload rate (limting max download rate) is us + Sui

time to distribute F
to N clients using DP2P > max{F/us,,F/dmin,,NF/(us + Sui)}
P2P approach

increases linearly in N …
… but so does this, as each peer brings service capacity
Application Layer 2-79 Application Layer 2-80
 P2P file distribution: BitTorrent P2P file distribution: BitTorrent
v file divided into 256Kb chunks
v peer joining torrent:
v peers in torrent send/receive file chunks
§ has no chunks, but will
tracker: tracks peers torrent: group of peers accumulate them over time
participating in torrent exchanging chunks of a file from other peers
§ registers with tracker to get
list of peers, connects to
subset of peers
(“neighbors”)
v while downloading, peer uploads chunks to other peers
Alice arrives … v peer may change peers with whom it exchanges chunks
… obtains list v churn: peers may come and go
of peers from tracker
… and begins exchanging v once peer has entire file, it may (selfishly) leave or
file chunks with peers in torrent (altruistically) remain in torrent

Application Layer 2-81 Application Layer 2-82

BitTorrent: requesting, sending file chunks BitTorrent: tit-for-tat

(1) Alice “optimistically unchokes” Bob
requesting chunks: sending chunks: tit-for-tat (2) Alice becomes one of Bob’s top-four providers; Bob reciprocates
v at any given time, different v Alice sends chunks to those (3) Bob becomes one of Alice’s top-four providers
peers have different subsets four peers currently sending her
of file chunks chunks at highest rate
v periodically, Alice asks each § other peers are choked by Alice
peer for list of chunks that (do not receive chunks from her)
they have § re-evaluate top 4 every10 secs
v Alice requests missing v every 30 secs: randomly select
chunks from peers, rarest another peer, starts sending
first chunks
§ “optimistically unchoke” this peer
§ newly chosen peer may join top 4
higher upload rate: find better
trading partners, get file faster !

Application Layer 2-83 Application Layer 2-84

Distributed Hash Table (DHT) Simple Database
Simple database with(key, value) pairs:
v Hash table
• key: human name; value: social security #
v DHT paradigm Key Value
John Washington 132-54-3570
v Circular DHT and overlay networks Diana Louise Jones 761-55-3791
Xiaoming Liu 385-41-0902
Rakesh Gopal 441-89-1956
v Peer churn
Linda Cohen 217-66-5609
……. ………
Lisa Kobayashi 177-23-0199

• key: movie title; value: IP address

Hash Table Distributed Hash Table (DHT)

• More convenient to store and search on v Distribute (key, value) pairs over millions of peers
numerical representation of key § pairs are evenly distributed over peers
v Any peer can query database with a key
• key = hash(original key) § database returns value for the key
Original Key Key Value § To resolve query, small number of messages exchanged among
John Washington 8962458 132-54-3570 peers
Diana Louise Jones 7800356 761-55-3791 v Each peer only knows about a small number of other
Xiaoming Liu 1567109 385-41-0902 peers
Rakesh Gopal 2360012 441-89-1956
v Robust to peers coming and going (churn)
Linda Cohen 5430938 217-66-5609
……. ………
Lisa Kobayashi 9290124 177-23-0199
 Assign key-value pairs to peers Circular DHT
v rule: assign key-value pair to the peer that has the • each peer only aware of
closest ID. immediate successor and
v convention: closest is the immediate successor of predecessor.
the key.
v e.g., ID space {0,1,2,3,…,63} 1
v suppose 8 peers: 1,12,13,25,32,40,48,60
§ If key = 51, then assigned to peer 60 12
60
§ If key = 60, then assigned to peer 60
§ If key = 61, then assigned to peer 1 13
48
25
40
32 “overlay network”

Resolving a query Circular DHT with shortcuts

1 What is the value for
value
key 53
1 What is the value 12
associated with key 53 ? 60
value 12
13
60
48
25
13 40
32
48 • each peer keeps track of IP addresses of predecessor,
O(N) messages 25 successor, short cuts.
• reduced from 6 to 3 messages.
on avgerage to resolve • possible to design shortcuts with O(log N) neighbors, O(log N)
query, when there 40 messages in query
32
are N peers
Peer churn handling peer churn:
Peer churn handling peer churn:
1 1
vpeers may come and go (churn) vpeers may come and go (churn)
veach peer knows address of its veach peer knows address of its
3 two successors 3 two successors
15 15
veach peer periodically pings its veach peer periodically pings its
4 two successors to check aliveness 4 two successors to check aliveness
vif immediate successor leaves, vif immediate successor leaves,
12 12
5 choose next successor as new choose next successor as new
immediate successor immediate successor
10 10
8 8
example: peer 5 abruptly leaves example: peer 5 abruptly leaves
vpeer 4 detects peer 5’s departure; makes 8 its immediate
successor
v 4 asks 8 who its immediate successor is; makes 8’s
immediate successor its second successor.

Chapter 2: outline Socket programming

goal: learn how to build client/server applications that
2.1 principles of network 2.6 P2P applications communicate using sockets
applications 2.7 socket programming
§ app architectures
socket: door between application process and end-
with UDP and TCP end-transport protocol
§ app requirements
2.2 Web and HTTP application application
socket controlled by
2.3 FTP process process app developer

2.4 electronic mail transport transport

network controlled
§ SMTP, POP3, IMAP network
by OS
link Internet link
2.5 DNS physical physical

Application Layer 2-95 Application Layer 2-96

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

Client/server socket interaction: UDP Example app: UDP client

Python UDPClient
server (running on serverIP) client include Python’s socket
library from socket import *
create socket:
create socket, port= x: serverName = ‘hostname’
clientSocket =
serverSocket = socket(AF_INET,SOCK_DGRAM) serverPort = 12000
socket(AF_INET,SOCK_DGRAM) create UDP socket for
clientSocket = socket(socket.AF_INET,
Create datagram with server IP and server
port=x; send datagram via get user keyboard
socket.SOCK_DGRAM)
read datagram from clientSocket input
serverSocket message = raw_input(’Input lowercase sentence:’)
Attach server name, port to
message; send into socket clientSocket.sendto(message,(serverName, serverPort))
write reply to
serverSocket read datagram from
read reply characters from modifiedMessage, serverAddress =
socket into string
specifying clientSocket clientSocket.recvfrom(2048)
client address,
port number close
print out received string print modifiedMessage
and close socket
clientSocket clientSocket.close()

Application 2-99 Application Layer 2-100

 Example app: UDP server Socket programming with TCP
Python UDPServer client must contact server v when contacted by client,
from socket import * v server process must first be server TCP creates new socket
running for server process to
serverPort = 12000 communicate with that
v server must have created
create UDP socket serverSocket = socket(AF_INET, SOCK_DGRAM) socket (door) that particular client
bind socket to local port
serverSocket.bind(('', serverPort)) welcomes client’s contact § allows server to talk with
number 12000
multiple clients
print “The server is ready to receive” client contacts server by: § source port numbers used
loop forever while 1: v Creating TCP socket, to distinguish clients
Read from UDP socket into message, clientAddress = serverSocket.recvfrom(2048) specifying IP address, port (more in Chap 3)
message, getting client’s number of server process
address (client IP and port) modifiedMessage = message.upper() application viewpoint:
v when client creates socket:
send upper case string serverSocket.sendto(modifiedMessage, clientAddress) client TCP establishes TCP provides reliable, in-order
back to this client
connection to server TCP byte-stream transfer (“pipe”)
between client and server

Application Layer 2-101 Application Layer 2-102

Client/server socket interaction: TCP Example app: TCP client

server (running on hostid) client Python TCPClient
create socket, from socket import *
port=x, for incoming
request: serverName = ’servername’
serverSocket = socket()
create TCP socket for serverPort = 12000
server, remote port 12000
wait for incoming
TCP create socket, clientSocket = socket(AF_INET, SOCK_STREAM)
connection request connect to hostid, port=x
connectionSocket = connection setup clientSocket = socket() clientSocket.connect((serverName,serverPort))
serverSocket.accept()
sentence = raw_input(‘Input lowercase sentence:’)
send request using
No need to attach server
read request from clientSocket
name, port
clientSocket.send(sentence)
connectionSocket
modifiedSentence = clientSocket.recv(1024)
write reply to
connectionSocket read reply from print ‘From Server:’, modifiedSentence
clientSocket
close clientSocket.close()
connectionSocket close
clientSocket

Application Layer 2-103 Application Layer 2-104

 Example app: TCP server Chapter 2: summary
Python TCPServer our study of network apps now complete!
from socket import *
v application architectures v specific protocols:
create TCP welcoming serverPort = 12000
socket serverSocket = socket(AF_INET,SOCK_STREAM)
§ client-server § HTTP
serverSocket.bind((‘’,serverPort)) § P2P § FTP
server begins listening for
serverSocket.listen(1) v application service
incoming TCP requests
requirements: § SMTP, POP, IMAP
print ‘The server is ready to receive’
loop forever § reliability, bandwidth, delay § DNS
while 1:
server waits on accept() v Internet transport service § P2P: BitTorrent, DHT
connectionSocket, addr = serverSocket.accept()
for incoming requests, new
socket created on return
model v socket programming: TCP,
§ connection-oriented, UDP sockets
sentence = connectionSocket.recv(1024)
read bytes from socket (but reliable: TCP
not address as in UDP) capitalizedSentence = sentence.upper()
§ unreliable, datagrams: UDP
close connection to this connectionSocket.send(capitalizedSentence)
client (but not welcoming
socket) connectionSocket.close()
Application Layer 2-105 Application Layer 2-106

Chapter 2: summary
most importantly: learned about protocols!

v typical request/reply important themes:

Chapter 1
message exchange:
§ client requests info or
v control vs. data msgs Additional Slides
service § in-band, out-of-band
§ server responds with v centralized vs. decentralized
data, status code v stateless vs. stateful
v message formats:
v reliable vs. unreliable msg
§ headers: fields giving
info about data transfer
§ data: info being v “complexity at network
communicated edge”

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