Chapter 2:

Application Layer
Computer Networking: A Top-Down
Approach
6th edition
Jim Kurose, Keith Ross
Addison-Wesley

01/22/2024 1
Outline
2.1 Principles of network applications
2.2 Web and HTTP
2.3 FTP
2.4 Electronic Mail (SMTP, POP3, IMAP)
2.5 DNS
2.6 P2P Applications
2.7 Socket programming with UDP and
TCP

01/22/2024 2
Chapter 2: Application Layer
• learn about
Our goals: protocols by
• conceptual, implementation examining popular
aspects of network application application-level
protocols protocols
– HTTP
• transport-layer service models
– FTP
• client-server paradigm – SMTP / POP3 /
• peer-to-peer paradigm IMAP
– DNS
• creating network
applications
– socket API
01/22/2024 3
Some network apps
• e-mail • voice over IP
• web • real-time video conferencing
• instant messaging • cloud computing
• remote login • Social networking
• P2P file sharing • streaming stored video
• multi-user network games (YouTube)

01/22/2024 4
 Creating a network app
application

write programs that:

transport
network
data link
• run on (different) end physical

systems
• communicate over network
e.g., web server software
communicates with browser
software
no need to write software
for network-core devices application

• network-core devices do transport

network

not run user

data link application
physical transport

applications
network
data link
physical
• applications on end
systems allows for
rapid app development,
propagation
01/22/2024 5
Application architectures

• client-server
• peer-to-peer (P2P)
• hybrid of client-server and P2P

01/22/2024 6
Client-server architecture
server:
• always-on host
• permanent IP address
• data centers for
scaling
clients:
• communicate with
client/server
server
• may be intermittently
connected
• may have dynamic IP
addresses
• do not communicate
01/22/2024
directly with each 7
P2P architecture
• no always-on server
• arbitrary end systems
directly communicate
• peers are intermittently
connected and change IP
addresses
highly scalable but difficult
to manage

01/22/2024 8
Hybrid of client-server and P2P
Skype
• voice-over-IP P2P application
• centralized server: finding address of remote party
• client-client connection: direct (not through server)
Instant messaging
• chatting between two users is P2P
• centralized service: client presence detection/location
• user registers its IP address with central server when it comes online
• user contacts central server to find IP addresses of buddies

01/22/2024 9
Processes communicating
• client process: process
process: program running within a that initiates
host. communication
• within same host, two processes • server process: process
communicate using inter- that waits to be contacted
process communication (defined
by OS). • aside: applications with
P2P architectures have
• processes in different hosts client processes & server
communicate by exchanging processes
messages

01/22/2024 10
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 which brings 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

01/22/2024 11
Addressing processes • example port
• to receive numbers:
messages, – HTTP server: 80
process must – mail server: 25
have identifier • to send HTTP
• host device has message to
unique 32-bit IP tdtu.edu.vn web
address server:
• identifier – IP address:
128.119.245.12
includes both IP – port number: 80
address and port • A list of well-known
numbers port number can be
01/22/2024 associated with found at 12
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
described
• message semantics
– meaning of
information in
fields
01/22/2024 13
•
 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
“effective”
transfer  other apps
other apps (e.g.,
•timing (“elastic apps”)
• audio) can (e.g.,
some apps tolerate make use of
some loss
Internet whatever
telephony, security
throughput they
 encryption, data
interactive get
games) require integrity, …
low delay to be
01/22/2024
“effective” 14
 Transport service requirements
of 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
video:10kbps-5Mbps
stored audio/video loss-tolerant same as above yes, few secs
interactive games loss-tolerant few kbps up yes
text messaging no loss elastic no

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

01/22/2024 17
Securing TCP
TCP & UDP
• no encryption SSL is at app layer
• cleartext passwds sent • Apps use SSL
into socket traverse libraries, which
Internet in cleartext “talk” to TCP
SSL SSL socket API
 cleartext passwds
• provides encrypted TCP
sent into socket
connection
traverse Internet
• data integrity encrypted
• end-point authentication  See Chapter 7

01/22/2024 18
Outline
2.1 Principles of network applications
2.2 Web and HTTP
2.3 FTP
2.4 Electronic Mail (SMTP, POP3, IMAP)
2.5 DNS
2.6 P2P Applications
2.7 Socket programming with UDP and
TCP

01/22/2024 19
 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 URL
 example URL:

www.someschool.edu/someDept/pic.gif

host name path name

01/22/2024 20
 HTTP overview
HTTP: hypertext
transfer protocol HT
TP
req
 Web’s application PC running ues
HT t
T
layer Firefox browser Pr
esp
ons
protocol e
 client/server modelthat
 client: browser t
u es
requests, receives, req server
T P se
“displays” Web objects HT s po
n running
re Apache Web
 server: Web server T P
HT server
sends objects in
response to requests iphone running
Safari browser

01/22/2024 21
 HTTP overview (continued)

Uses TCP: HTTP is “stateless”

 client initiates TCP  server maintains no
connection (creates socket) information about
to server, port 80 past client requests
 server accepts TCP
connection from client aside
protocols that maintain
 HTTP messages (application- “state” are complex!
layer protocol messages)
 past history (state) must
exchanged between browser
be maintained
(HTTP client) and Web
 if server/client crashes,
server (HTTP server)
their views of “state” may
 TCP connection closed
be inconsistent, must be
reconciled

01/22/2024 22
 HTTP connections

non-persistent HTTP persistent HTTP

• at most one object  multiple objects can
sent over TCP be sent over single
connection TCP connection
– connection then between client, server.
closed
• downloading multiple
objects required
multiple connections

01/22/2024 23
 Nonpersistent HTTP
suppose user enters URL: (contains text,
references to 10
www.someSchool.edu/someDepartment/home.index
jpeg images)
1a. HTTP client
initiates TCP 1b. HTTP server at host
connection to HTTP www.someSchool.edu
server (process) at waiting for TCP
www.someSchool.edu on connection at port 80.
port 80 “accepts” connection,
2. HTTP client sends HTTP notifying client
request message
(containing URL) into 3. HTTP server receives
TCP connection socket. request message, forms
Message indicates that response message
client wants object containing requested
someDepartment/home.ind object, and sends
ex message into its socket
time
01/22/2024 24
 Nonpersistent HTTP (cont.)
4. HTTP server closes TCP
connection.
5. HTTP client receives
response message
containing html file,
displays html. Parsing
html file, finds 10
time
6. referenced jpeg
Steps 1-5 repeated for
objects
each of 10 jpeg objects

01/22/2024 25
Non-Persistent HTTP: Response time
definition of RTT: time for a small
packet to travel from client to
server and back. initiate TCP
response time: connection
 one RTT to initiate TCP RTT

connection request
file
 one RTT for HTTP request and time to
RTT
first few bytes of HTTP transmit
file
response to return file
 file transmission time received
 Non-persistent HTTP
time time
response time
total = 2RTT+transmit time

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

01/22/2024 27
 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
header Accept: text/
lines html,application/xhtml+xml\r\n
Accept-Language: en-us,en;q=0.5\r\
carriage return, n Accept-Encoding: gzip,deflate\
r\n
line feed at start Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\
of line indicates n Keep-Alive: 115\r\n
end of header lines Connection: keep-alive\r\n
01/22/2024 \r\n 28
 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

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

01/22/2024 30
 Method types

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

01/22/2024 31
 HTTP response message
status line
(protocol
status code HTTP/1.1 200 OK\r\n
status phrase) Date: Sun, 26 Sep 201020:09:20 GMT\r\
n Server: Apache/2.0.52
(CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007
header 17:00:02 GMT\r\n
ETag: "17dc6-a5c-bf716880"\r\n
lines
Accept-Ranges: bytes\r\n
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
data, e.g., \r\n
requested data data data data data ...
HTML file
01/22/2024 32
 HTTP response status codes
 status code appears in 1st line in server->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
01/22/2024 33
 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!

(or use Wireshark to look at captured HTTP request/response)
01/22/2024 34
 User-server state: cookies
many Web sites use example:
cookies  Susan always access

four components: Internet from PC

1) cookie header line of HTTP  visits specific e-
response message commerce site for first
2) cookie header line in HTTP
request message
time
3) cookie file kept on user’s host,  when initial HTTP
managed by user’s browser requests arrives at site,
4) back-end database at Web site creates:
site
 unique ID
 entry in backend
database for ID
01/22/2024 35
 Cookies: keeping “state” (cont.)
server
client

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
01/22/2024 36
 Web caches (proxy server)
goal: satisfy client request without
involving origin server
• user sets
browser: Web
accesses via HT proxy
st
cache HT
TP
req server
ues P req
u e
client TP t TT nse
• browser sends all res
pon
H
P res
po origin
se T server
HTTP requests to ues
t
HT

cache TT P req
po ns
e
H es
– object in HT TP
r

cache: cache
returns object client origin
server
– else cache
01/22/2024
requests object 38
from origin
 More about Web caching

• cache acts as both why Web caching?

client and server
• reduce response time for
– server for original client request
requesting client
• reduce traffic on an
– client to origin institution’s access link
server
• Internet dense with
• typically cache is
caches: enables “poor”
installed by ISP content providers to
(university, company, effectively deliver
residential ISP) content (so too does P2P
file sharing)
01/22/2024 39
 Web Caching Example (1)
Assumptions: origin
• Avg object size: 1 Mbits servers
• Avg request rate from browsers to origin servers: 15 Public
request/sec
Internet
• Avg data rate to browsers: 1.50 Mbps
• RTT from institutional router to any origin server: 2
sec
• Access link rate: 15 Mbps
15 Mbps
Consequences: access link
- (15 req/sec).(1 Mbits/req)/(100 Mbps) = 0.15
Institutional
- (15 req/sec).(1 Mbits/req)/(15 Mbps) = 1
network
100Mbps LAN
• problem!
Total delay = Internet delay + access delay + LAN
delay
= 2 sec + minutes + microseconds

01/22/2024 40
 Web Caching Example (1)
Assumptions: origin
• Avg object size: 1 Mbits servers
• Avg request rate from browsers to origin servers: 15 Public
request/sec
Internet
• Avg data rate to browsers: 1.50 Mbps
• RTT from institutional router to any origin server: 2
sec
• Access link rate: 15 Mbps = 100 Mbps
15 Mbps 100 Mbps
Consequences: access link
- (15 req/sec).(1 Mbits/req)/(100 Mbps) = 0.15
Institutional
- (15 req/sec).(1 Mbits/req)/(100 Mbps) = 0.15
network
• Total delay = Internet delay + access delay + LAN 100Mbps LAN
delay
= 2 sec + microseconds+ microseconds

Cost: increased access link speed (not cheap!)

01/22/2024 41
 Web Caching Example (3)
Assumptions:
 Avg object size: 1 Mbits
 Avg request rate from browsers to origin origin
servers: 15/sec servers
 Avg data rate to browsers: 1.50 Mbps Public
 RTT from institutional router to any Internet
origin server: 2 sec
 Access link rate: 15 Mbps
Consequences: 15 Mbps
 LAN utilization: 0.15%
 Access link utilization?= 100% access link
 Total delay ?= Internet delay + access Institutional
delay + LAN delay network
= 2 sec + minutes + usecs 100 Mbps LAN

How to compute link Local web

utilization, delay? cache
Cost: Web cache (cheap!)
01/22/2024 42
 Web Caching Example (4)
Calculating access link utilization, delay with
cache:
origin
• Suppose cache hit rate is 0.4
servers
– 40% requests satisfied at cache, 60% Public
requests satisfied at origin Internet
• Access link utilization:
– 60% of requests use access link
• Data rate to browsers over access 1.54 Mbps
link = 0.6*1.50 Mbps = 0.9 Mbps access link
– Utilization = 0.9/1.54 = 0.58
Institutional
• Total delay network 100 Mbps LAN
– = 0.6 * (delay from origin servers)
+0.4 * (delay when satisfied at cache) Local web
– = 0.6 .(2) + 0.4 (~msecs)
– = ~ 1.2 secs cache
– Less than with 15 Mbps link
(and cheaper too!)
01/22/2024 43
Outline
2.1 Principles of network applications
2.2 Web and HTTP
2.3 FTP
2.4 Electronic Mail (SMTP, POP3, IMAP)
2.5 DNS
2.6 P2P Applications
2.7 Socket programming with UDP and
TCP

01/22/2024 45
 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
01/22/2024 46
 FTP: separate control, data
connections
• FTP client contacts FTP TCP control connection,
server at port 21, server port 21
using TCP
• client authorized over FTP
TCP data connection,
server port 20 FTP
control connection client server
• client browses remote
directory, sends  server opens
commands over control another TCP data
connection connection to
transfer another
• when server receives file
file transfer command,  control connection:
server opens 2nd TCP “out of band”
data connection (for  FTP server
file) to client maintains “state”:
01/22/2024 • after transferring one current directory, 2-47
earlier
 FTP commands,
responses
sample commands: sample return
• sent as ASCII text codes
over control channel
• status code and
• USER username phrase (as in HTTP)
• PASS password
• 331 Username OK,
• LIST return list of password required
file in current
directory • 125 data connection
• RETR filename
already open;
retrieves (gets) file
transfer starting
• STOR filename stores • 425 Can’t open data
(puts) file onto connection
remote host • 452 Error writing
file
01/22/2024 48
Outline
2.1 Principles of network applications
2.2 Web and HTTP
2.3 FTP
2.4 Electronic Mail (SMTP, POP3, IMAP)
2.5 DNS
2.6 P2P Applications
2.7 Socket programming with TCP
2.8 Socket programming with UDP

01/22/2024 49
 Electronic mail
outgoing
Three major components: user message queue
• user agents agent
user mailbox
• mail servers mail user
server
• simple mail transfer agent
protocol: SMTP SMTP mail user
User Agent server agent

• a.k.a. “mail reader” SMTP

• composing, editing, SMTP user
reading mail messages mail
agent
• e.g., Outlook, server
Thunderbird, iPhone mail user
agent
client
• outgoing, incoming user
agent
messages stored on
server
01/22/2024 50
 Electronic mail: mail
servers
mail servers: user
agent
• mailbox contains
incoming messages for mail user
user server agent

• message queue of SMTP mail user

outgoing (to be sent) server agent
mail messages SMTP
• SMTP protocol between user
mail servers to send SMTP agent
mail
email messages server
• client: sending user
mail server agent

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

1 user mail user

mail agent
agent server server
2 3 6
4
5
Alice’s mail server Bob’s mail server
01/22/2024 53
 Sample SMTP
interaction
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <[email protected]>
S: 250 [email protected]... Sender ok
C: RCPT TO: <[email protected]>
S: 250 [email protected] ... 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

01/22/2024 2-54
 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)

01/22/2024 2-55
 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.

01/22/2024 56
 POP3 protocol
S: +OK POP3 server ready
authorization phase C: user bob
S: +OK
• client commands: C: pass hungry
• user: declare username S: +OK user successfully logged on
• pass: password
C: list
• server responses S: 1 498
• +OK S: 2 912
• -ERR S: .
transaction phase,
C: retr 1
S: <message 1 contents>
client: S: .
• list: list message numbers C: dele 1
• retr: retrieve message by C: retr 2
number S: <message 1 contents>
• dele: delete S: .
C: dele 2
• quit
C: quit
S: +OK POP3 server signing off
01/22/2024 57
 POP3 (more) and
IMAP
more about POP3 IMAP
• previous example • keeps all messages
uses POP3 in one place: at
“download and server
delete” mode
• allows user to
• Bob cannot re- organize messages
read e-mail if in folders
he changes
client • keeps user state
across sessions:
• POP3 “download-
• names of folders
and-keep”: copies
and mappings
of messages on
between message
different clients
IDs and folder
• POP3 is stateless name
across sessions
01/22/2024 58
 Break Time

01/22/2024 59
Outline
2.1 Principles of network applications
2.2 Web and HTTP
2.3 FTP
2.4 Electronic Mail (SMTP, POP3, IMAP)
2.5 DNS
2.6 P2P Applications
2.7 Socket programming with TCP
2.8 Socket programming with UDP

01/22/2024 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
01/22/2024
function, 61
DNS: Services, structure
DNS services Why not centralize DNS?
 hostname to IP  single point of failure
address translation  traffic volume
 host aliasing  distant centralized
 Canonical, alias names database
 mail server aliasing  maintenance
 load distribution
 replicated Web
doesn’t scale!
servers: set of IP
addresses for one
canonical name

01/22/2024 62
 DNS: 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
DNS servers DNS servers
servers

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

 client queries a 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

01/22/2024 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 to local
k. RIPE Londonname server
c. Cogent, Herndon, VA (5 other sites)
d. U Maryland College Park, MD (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 “servers”
(5 other sites) worldwide
b. USC-ISI Marina del Rey, CA
l. ICANN Los Angeles, CA
(41 other sites) g. US DoD Columbus,
OH (5 other sites)

01/22/2024 64
 TLD and 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 DNS servers, providing
authoritative hostname to IP mappings for
organization’s servers (e.g., Web, mail).
 can be maintained by organization or service
01/22/2024
provider 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

01/22/2024 2-66
 DNS name resolution
example
root DNS server

• host at 2
3
cis.poly.edu TLD DNS server
wants IP address 4

for 5
iterated query:
gaia.cs.umass.ed local DNS server
 contacted server
u dns.poly.edu
replies with 7 6
name of server 1 8
to contact
 “I don’t know authoritative DNS server
this name, but requesting host
dns.cs.umass.edu

ask this server” cis.poly.edu

gaia.cs.umass.edu
01/22/2024 67
 DNS name resolution example
root DNS server

recursive query:
 puts burden of name 2 3
resolution on
contacted name 7 6
server TLD DNS server
 heavy load?
local DNS server
dns.poly.edu 5 4

1 8

authoritative DNS server

dns.cs.umass.edu
requesting host
cis.poly.edu

01/22/2024 g 68
 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 some
 value is IP address “canonical” (the real)
name
type=NS  www.ibm.com is really
• name is domain servereast.backup2.ibm.com
(e.g., foo.com)  value is canonical name
• value is hostname of
authoritative name
server for this type=MX
domain  value is name of
mailserver associated
with name
01/22/2024 2-69
 DNS protocol,
messages
• query and reply messages, both with same message format

2 bytes 2 bytes

msg header identification flags

 identification: 16 bit # questions # answer RRs
# for query, reply to
query uses same # # authority RRs # additional RRs
 flags:
 query or reply questions (variable # of questions)
 recursion desired
 recursion available
answers (variable # of RRs)
 reply is
authoritative
authority (variable # of RRs)

additional info (variable # of RRs)

01/22/2024 2-70
 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
01/22/2024 2-71
 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

01/22/2024 2-72
 Attacking DNS
DDoS attacks Redirect attacks
• Bombard root • Man-in-middle
servers with • Intercept queries
traffic • DNS poisoning
• Not successful to • Send bogus relies to DNS
date server, which caches
• Traffic Filtering Exploit DNS for
• Local DNS servers DDoS
cache IPs of TLD
servers, allowing • Send queries with
root server spoofed source address:
bypass target IP
• Bombard TLD • Requires amplification
01/22/2024
servers 2-73
Outline
2.1 Principles of network applications
2.2 Web and HTTP
2.3 FTP
2.4 Electronic Mail (SMTP, POP3, IMAP)
2.5 DNS
2.6 P2P Applications
2.7 Socket programming with TCP
2.8 Socket programming with UDP

01/22/2024 74
 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)
01/22/2024 • VoIP (Skype) 75
 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

01/22/2024 76
 File distribution time:
client-server
• server transmission:
must sequentially F
us
send (upload) N file di
copies: network
• time to send one copy: ui
F/us
time to
 • client: send
eachN client
copies: must download file copy
NF/u
dmins = min client download rate
 min client download time: F/dmin

time to distribute F
to N clients using
Dc-s
client-server approach > max{NF/us,,F/dmin}

increases linearly in N
01/22/2024 77
 File distribution time:
P2P
• server transmission:
must upload at least
F
us
one copy di
• time to send one network
 client: each client
copy: F/u u i

must download file

s

copy
 min client download
 clients:
time: F/das aggregate must download NF bits
 max upload min
rate (limting max download rate) is us +
Sui
time to distribute F
D > max{F/us,,F/dmin,,NF/(us + Sui)}
to N clients using
P2P approachP2P

increases linearly in N …
… but so does this, as each peer brings service capacity
01/22/2024
78
 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
01/22/2024 79
 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

01/22/2024 80
 P2P file distribution:
BitTorrent
peer joining torrent:
 has no chunks, but
will accumulate
them over time from
other peers
 registers with
tracker to get list
of peers, connects
to subset of peers
(“neighbors”)
 while downloading, peer uploads chunks to
other peers
 peer may change peers with whom it
exchanges chunks
 churn: peers may come and go
 once peer has entire file, it may
01/22/2024 81
(selfishly) leave or (altruistically)
 BitTorrent: requesting, sending
file chunks

requesting chunks: sending chunks: tit-

• at any given time, for-tat
different peers have  Alice sends chunks to
different subsets of
file chunks
those four peers
currently sending her
• periodically, Alice chunks at highest
asks each peer for list rate
of chunks that they  other peers are choked
have by Alice (do not
• Alice requests missing receive chunks from
chunks from peers, her)
rarest first  re-evaluate top 4
every10 secs
 every 30 secs:
randomly select
another peer, starts
01/22/2024 sending chunks 82
 BitTorrent: tit-
for-tat
(1) Alice “optimistically unchokes” Bob
(2) Alice becomes one of Bob’s top-four providers; Bob reciprocates
(3) Bob becomes one of Alice’s top-four providers

higher upload rate:

find better trading
partners, get file
01/22/2024 faster ! 83
Outline
2.1 Principles of network applications
2.2 Web and HTTP
2.3 FTP
2.4 Electronic Mail (SMTP, POP3, IMAP)
2.5 DNS
2.6 P2P Applications
2.7 Socket programming with UDP and
TCP

01/22/2024 84
2.7 Socket programming
- goal: learn how to build client/server
applications that communicate using sockets
- socket: door between application process and
end-end-transport protocol
application application
socket controlled by
process process app developer

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

01/22/2024 85
2.7 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 data and displays the
line on its screen.
01/22/2024 86
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
01/22/2024
server 87
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

01/22/2024 88
Example app: UDP client
Python UDPClient.py
include Python’s socket
library from socket import *
serverName = ‘hostname’
serverPort = 12000
create UDP socket for clientSocket = socket(socket.AF_INET,
server

get user keyboard

socket.SOCK_DGRAM)
input message = raw_input(’Input lowercase sentence:’)
Attach server name, port to
message; send into socket clientSocket.sendto(message,(serverName, serverPort))
read reply characters from modifiedMessage, serverAddress =
socket into string
clientSocket.recvfrom(2048)
print out received string print modifiedMessage
and close socket
clientSocket.close()

01/22/2024 89
Example app: UDP server
Python UDPServer
from socket import *
serverPort = 12000
create UDP socket serverSocket = socket(AF_INET, SOCK_DGRAM)
bind socket to local port
number 12000
serverSocket.bind(('', serverPort))
print “The server is ready to receive”
loop forever while 1:
Read from UDP socket into message, clientAddress = serverSocket.recvfrom(2048)
message, getting client’s
address (client IP and port) modifiedMessage = message.upper()
send upper case string serverSocket.sendto(modifiedMessage, clientAddress)
back to this client

01/22/2024 90
Socket-programming using TCP
Socket: a door between application process and end-
end-transport protocol (UCP or TCP)
TCP service: reliable transfer of bytes from one
process to another

controlled by
controlled by process application
application process
developer
developer socket socket
TCP with TCP with controlled by
controlled by
buffers, operating
operating buffers, internet system
system variables variables

host or host or
server server

01/22/2024 91
Socket programming
client must contact
with TCP
• when contacted by
server client, server TCP
creates new socket for
• server process must
server process to
first be running
communicate with that
• server must have
particular client
created socket (door) – allows server to
that welcomes
talk with multiple
client’s contact
clients
client contacts – source port numbers
server by: used to distinguish
application viewpoint:
clients (more in
• Creating TCP socket,
specifying IP TCP provides reliable, in-order
Chap 3)
address, port numberbyte-stream transfer (“pipe”)
of server process between client and server
01/22/2024 • when client creates 92
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

01/22/2024 93
Client/server socket interaction: TCP

01/22/2024 94
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 clientSocket.send(sentence)
name, port
modifiedSentence = clientSocket.recv(1024)
print ‘From Server:’, modifiedSentence
clientSocket.close()

01/22/2024 95
Example app: TCP
Python server
TCPServer
from socket import *
create TCP welcoming
serverPort = 12000
socket serverSocket = socket(AF_INET,SOCK_STREAM)
serverSocket.bind((‘’,serverPort))
server begins listening for
incoming TCP requests
serverSocket.listen(1)
print ‘The server is ready to receive’
loop forever while 1:
server waits on accept() connectionSocket, addr = serverSocket.accept()
for incoming requests, new
socket created on return
sentence = connectionSocket.recv(1024)
read bytes from socket (but
not address as in UDP) capitalizedSentence = sentence.upper()
close connection to this
connectionSocket.send(capitalizedSentence)
client (but not welcoming connectionSocket.close()
socket)

01/22/2024 96
Chapter 2: of
our study Summary
network apps now
• complete!
application architectures  specific
– client-server protocols:
– P2P  HTTP
 FTP
 SMTP, POP, IMAP
• application service
requirements:  DNS
– reliability, bandwidth,  P2P: BitTorrent,
DHT
delay

• Internet transport service

 socket
model programming: TCP,
UDP sockets
– connection-oriented,
01/22/2024 reliable: TCP 97
 Chapter 2:
summary
most importantly: learned about
protocols!
• typical request/reply
message exchange:
important themes:
• client requests info
 control vs. data
or service msgs
• server responds with  in-band, out-of-
data, status code
band
• message formats:  centralized vs.
• headers: fields
giving info about decentralized
data  stateless vs.
• data: info being stateful
communicated  reliable vs.
unreliable msg
transfer
“complexity at
01/22/2024 98

Additional Slides
application
packet (www browser,

analyzer email client)

application

OS
packet Transport (TCP/UDP)

capture copy of all Network (IP)

Ethernet
frames Link (Ethernet)
(pcap) sent/receive
d Physical

01/22/2024 99
Exercises
 Ex1. You use Wireshark to investigate and
explore several aspects of the HTTP
protocol:
 the basic GET/reply interaction,
 HTTP message formats,
 retrieving large HTML files,
 retrieving HTML files with embedded URLs,
 persistent and non-persistent connections,
 and HTTP authentication and security

01/22/2024 100