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
material.
Addison-Wesley
March 2012
Thanks and enjoy! JFK/KWR

All material copyright 1996-2012

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

2-1 2-2

Chapter 2: application layer Some network apps

our goals: v learn about protocols by
examining popular v e-mail v voice over IP (e.g., Skype)
v conceptual,
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 …
§ DNS v multi-user network games v
§ client-server …
creating network v streaming stored video v
paradigm v
(YouTube, Hulu, Netflix)
§ peer-to-peer applications
paradigm § socket API

2-3 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

2-5 2-6

Client-server architecture P2P architecture

v no always-on server
server: peer-peer
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

2-7 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
v processes in different hosts socket controlled by
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

2-9 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
host device has unique 32- associated with process on § e.g., request, response
v v allows for interoperability
bit IP address host.
v message syntax: v e.g., HTTP, SMTP
Q: does IP address of host v example port numbers:
v
§ 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
§ A: no, many processes gaia.cs.umass.edu web v message semantics
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

2-11 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.,
multimedia) require application data loss throughput time sensitive
web transactions) 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
timing make use of whatever video:10kbps-5Mbps msec
throughput they get stored audio/video loss-tolerant same as above
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
…

2-13 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 receiving process e-mail SMTP [RFC 2821] TCP
v flow control: sender won’t remote terminal access Telnet [RFC 854] 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
2-15 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
2-17 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
v object can be HTML file, JPEG image, Java applet, protocol PC running HT
req
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) eq
ue
server
v each object is addressable by a URL, e.g., and “displays” Web T Pr ns
e
HT po running
objects res Apache Web
TP
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

2-19 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 multiple objects can
v
connection (creates information about
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 past history (state) must be v downloading multiple
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

2-21 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 on port www.someSchool.edu waiting finds 10 referenced jpeg objects
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
2-23 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: v OS overhead for each TCP open after sending
initiate TCP
connection response
v one RTT to initiate TCP
connection

connection RTT v browsers often open v subsequent HTTP

v one RTT for HTTP request
request parallel TCP connections messages between same
and first few bytes of HTTP
file
to fetch referenced objects client/server sent over
time to
RTT open connection
response to return transmit

v file transmission time

file
v client sends requests as
file
received soon as it encounters a
v non-persistent HTTP referenced object
response time = v as little as one RTT for all
time time
2RTT+ file transmission the referenced objects
time
2-25 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
line feed at start Connection: keep-alive\r\n
\r\n
of line indicates
end of header lines
2-27 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

2-29 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 § requested object moved, new location specified later in this msg
Content-Length: 2652\r\n
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
2-31 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 § entry in backend
Host: cis.poly.edu return twice), you send
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
2-33 2-34

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

client server what cookies can be used aside
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
set-cookie: 1678 1678 for user create backend v recommendations
ebay 8734 entry database 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
2-35 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
TP est § client to origin server v reduce traffic on an
req server equ
§ object in cache: cache clientHTTP
res
ues
t H TTP
r
se
pon origin v typically cache is institution’s access link
res
returns object pon
se HT
T P server installed by ISP v Internet dense with
st
§ else cache requests eq
ue (university, company, caches: enables “poor”
object from origin T Pr ns
e
HT
Pr
es
po residential ISP) content providers to
server, then returns HT
T
effectively deliver
object to client
client
content (so too does
origin
server P2P file sharing)

2-37 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 network
v access link utilization = 99% 1 Gbps LAN v access link utilization = 99% 9.9% 1 Gbps LAN
v total delay = Internet delay + access v total delay = Internet delay + access
delay + LAN delay
delay + LAN delay
= 2 sec + minutes + usecs
= 2 sec + minutes + usecs msecs
Cost: increased access link speed (not cheap!)
2-39 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 v data rate to browsers over access link 1.54 Mbps
access link = 0.6*1.50 Mbps = .9 Mbps access link
consequences:
institutional § utilization = 0.9/1.54 = .58 institutional
v LAN utilization: 15%
v ?
access link utilization = 100%
network
1 Gbps LAN v total delay network
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!)
2-41 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 § app requirements
before
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
2-43 2-44
FTP: the file transfer protocol FTP: separate control, data connections
file transfer
FTP
user
FTP FTP v FTP client contacts FTP server TCP control connection,
server port 21
interface
client server at port 21, using TCP
user
at host remote file v client authorized over control 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
2-45 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
v LIST return list of file in v 125 data 2.2 Web and HTTP
current directory connection
already open; 2.3 FTP
v RETR filename transfer starting 2.4 electronic mail
retrieves (gets) file 425 Can’t open
v § SMTP, POP3, IMAP
v STOR filename stores data connection
2.5 DNS
(puts) file onto remote v 452 Error writing
host file

2-47 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

User Agent SMTP mail servers to send email SMTP

messages
v a.k.a. “mail reader” SMTP user SMTP user
agent § client: sending mail agent
v composing, editing, reading mail
server server
mail
server
mail messages user user
§ “server”: receiving mail
v e.g., Outlook, Thunderbird, agent
server
agent

iPhone mail client user user

agent agent
v outgoing, incoming
messages stored on server
2-49 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 over the TCP
message “to”
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) user
1 user mail mail
§ commands: ASCII text agent server server agent
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
2-51 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

2-53 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
(header & body) to be in v SMTP: push line
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

2-55 2-56
Mail access protocols POP3 protocol
S: +OK POP3 server ready
C: user bob
mail access
user
agent
SMTP SMTP protocol
user
agent
authorization phase S:
C:
+OK
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
S: 1 498
server server v server responses S: 2 912
v SMTP: delivery/storage to receiver’s server § +OK S: .
§ -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
number
features, including manipulation of stored msgs on 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
2-57 2-58

POP3 (more) and IMAP Chapter 2: outline

more about POP3 IMAP
previous example uses 2.1 principles of network 2.6 P2P applications
v v keeps all messages in one
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 2.5 DNS
sessions

2-59 2-60
DNS: domain name system DNS: services, structure
DNS services why not centralize DNS?
people: many identifiers: Domain Name System:
v hostname to IP address v single point of failure
§ SSN, name, passport # v distributed database translation
implemented in hierarchy of v traffic volume
Internet hosts, routers:
many name servers v host aliasing 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”

2-61 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:
org DNS servers edu DNS servers § contacts authoritative name server if name mapping not known
com DNS servers
§ 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)

m. W IDE Tokyo
v client queries root server to find com DNS server e. NASA Mt View, CA
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)

2-63 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

2-65 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
server
5 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
server” cis.poly.edu cis.poly.edu

gaia.cs.umass.edu gaia.cs.umass.edu

2-67 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

2-69 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 #
v flags: name, type fields
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
2-71 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)
with traffic § Intercept queries
§ provide names, IP addresses of authoritative name server
(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
server bypass
www.networkuptopia.com; type MX record for v Send queries with
networkutopia.com v Bombard TLD servers
spoofed source
§ Potentially more address: target IP
dangerous
v Requires amplification
2-73 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)

2-75 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 us
u1 d1 u2 capacity § dmin = min client download rate
d2
server § min client download time: F/dmin
di
uN network (with abundant time to distribute F
bandwidth) ui to N clients using
dN Dc-s > max{NF/us,,F/dmin}
client-server approach
ui: peer i upload
capacity
increases linearly in N
2-77 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
2-79 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

2-81 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 !

2-83 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

2-85 2-86

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

2-87 2-88
 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 60 12
§ If key = 60, then assigned to peer 60
§ If key = 61, then assigned to peer 1 13
48
25
40
32 “overlay network”
2-89 2-90

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
40 • possible to design shortcuts with O(log N) neighbors, O(log N)
query, when there 32 messages in query
are N peers
2-91 2-92
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
15 3 two successors 15 3 two successors
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
v peer 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.
2-93 2-94

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

2-95 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
§ TCP: reliable, byte stream-oriented
v sender explicitly attaches IP destination address and
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.
2-97 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
serverSocket
input message = raw_input(’Input lowercase sentence:’)
Attach server name, port to
message; send into socket clientSocket.sendto(message,(serverName, serverPort))
write reply to read reply characters from modifiedMessage, serverAddress =
serverSocket read datagram from 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()
2-992-99
Application 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
v server must have created communicate with that
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()
v when client creates socket: application viewpoint:
serverSocket.sendto(modifiedMessage, clientAddress) TCP provides reliable, in-order
send upper case string
back to this client
client TCP establishes
connection to server TCP byte-stream transfer (“pipe”)
between client and server

2-101 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 create socket, clientSocket = socket(AF_INET, SOCK_STREAM)
connection request TCP 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

2-103 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 v application service
incoming TCP requests serverSocket.listen(1) § SMTP, POP, IMAP
requirements:
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()
2-105 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”

2-107 1-108
 application
packet (www browser,

analyzer email client)

application

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

2-109