Lecture 2

Application Layer

Computer Networks
The slides are made by J.F Kurose and K.W. Ross,
adapted by Phuong Vo and Tan Le

Instructor: Le Duy Tan, Ph.D

Email: [email protected]
Application Layer 2-1
Lecture 2: application
layer
our goals:  learn about
 conceptual, protocols by
implementation examining popular
aspects of network application-level
application protocols
protocols  HTTP
 transport-layer  SMTP / POP3 / IMAP
service models  DNS
 client-server
paradigm

Application Layer 2-2

Lecture 2: outline
2.1 Principles of network applications
2.2 Web and HTTP
2.3 electronic mail
 SMTP, POP3, IMAP
2.4 DNS
2.5 Socket programming

Application Layer 2-3

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

Application Layer 2-4

Creating a network app application
transport
network
data link

write programs that: physical

 run on (different) end

systems
 communicate over
network
 e.g., web server
software communicates
with browser software application
transport
network
no need to write software data link
physical
application
transport
for network-core network
data link
devices physical

 network-core devices
do not run user
applications
 applications on end
systems allows for Application Layer 2-5
Application architectures
possible structure of applications:
 client-server
 peer-to-peer (P2P)

Application Layer 2-6

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

clients:
 communicate with
server
client/server  may be intermittently
connected
 may have dynamic IP
addresses
 do not communicate
directly with each
other Application Layer 2-7
P2P architecture
 no always-on server peer-peer
 arbitrary end systems
directly communicate
 peers request service
from other peers,
provide service in
return to other peers
 self scalability –
new peers bring
new service
capacity, as well as
new service
demands
 peers are
intermittently
connected and change
Application Layer 2-8
IP addresses
Processes communicating
process: program clients, servers
running within a client process:
host process that initiates
(process stored in communication
RAM, while server process:
program is stored process that waits to
in SSD, HDD) be contacted
 within same host, two
processes
communicate using
inter-process
communication
(defined by OS)
 processes in different
hosts communicate Application Layer 2-9
Sockets
 process sends/receives messages to/from its
socket
 socket analogous to door
 sending process shoves message out door
 sending process relies on transport
infrastructure on other side of door to deliver
message to socket at receiving process
application application
socket controlled by
process process app developer

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

Application Layer 2-10

Addressing processes
 to receive messages,  identifier includes both
process must have IP address and port
identifier numbers associated
 host device has with process on host.
unique 32-bit IP  (port: a number to
address identify which network
 Q: is IP address of host application)
associated with one  example port numbers:
process?
 A: no, many  HTTP server: 80
processes can be  mail server: 25
running on same  to send HTTP message
host to gaia.cs.umass.edu
web server:
 IP address:
128.119.245.12
 port number: 80
Application Layer 2-11
What transport service does an
app need?
data integrity throughput
 some apps (e.g., file  some apps (e.g.,
transfer, web multimedia) require
transactions) require minimum amount of
100% reliable data throughput to be
transfer “effective”
 other apps (e.g., audio)  other apps (“elastic

can tolerate some loss apps”) make use of

timing
whatever throughput
 some apps (e.g.,
they get
Internet telephony, security
interactive games)
 encryption, data
require low delay to
be “effective” integrity, …

Application Layer 2-12

 Transport service requirements:
common apps

application data loss throughput time sensitive

file transfer no loss elastic no

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

Application Layer 2-13

Internet transport protocols
services
TCP service: UDP service:
 reliable transport  unreliable data
between sending and transfer between
receiving process sending and
 flow control: sender receiving process
won’t overwhelm
receiver
 does not provide:
 congestion control: reliability, flow
throttle sender when control, congestion
network overloaded control, timing,
 does not provide: throughput
timing, minimum guarantee, security,
throughput guarantee, or connection setup,
security  (do nothing, just
 connection-oriented: send  faster  use
setup required for video, audio
between client and streaming) Application Layer 2-14
server processes
Internet apps: application, transport
protocols
application underlying
application layer protocol transport protocol

e-mail SMTP [RFC 2821] TCP

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

Application Layer 2-15

Securing TCP

TCP & UDP SSL is at app layer

 no encryption  apps use SSL
 cleartext passwds libraries, that “talk”
sent into socket to TCP
traverse Internet in SSL socket API
cleartext  cleartext passwords
SSL sent into socket
 provides encrypted traverse Internet
TCP connection encrypted
 data integrity  see Chapter 8
 end-point
authentication
Application Layer 2-16
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 protocols:
messages & how  e.g., Skype
fields are defined
 message semantics
 meaning of
information in
fields
 rules for when and
how processes send &
respond to messages
Application Layer 2-17
Lecture 2: outline
2.1 principles of network applications
 app architectures
 app requirements
2.2 Web and HTTP
2.3 electronic mail
 SMTP, POP3, IMAP
2.4 DNS
2.5 Socket programming

Application Layer 2-18

Web and HTTP
First, a review…
 web page consists of objects
 object can be HTML file, JPEG image,
Java applet, audio file,…
 web page consists of base HTML-file
(index file) which includes several
referenced objects
 each object is addressable by a URL,
www.someschool.edu/someDept/pic.gif
e.g.,
host name path name

Application Layer 2-19

HTTP overview
HTTP: hypertext
transfer protocol HT
 Web’s application TP
req
layer protocol PC running HT
ues
t
Firefox browser TPr
 client/server model esp
ons
 client: browser e
that requests, t
receives, (using u es
req server
HTTP protocol) T P nse
HT po running
and “displays” P res
Apache Web
Web objects HT
T
server
 server: Web
server sends iphone running
(using HTTP Safari browser
protocol) objects
in response to
requests
Application Layer 2-20
HTTP overview (continued)
uses TCP:
 client initiates TCP connection (creates socket)
to server, port 80
 server accepts TCP connection from client
 HTTP messages (application-layer protocol
messages) exchanged between browser (HTTP
client) and Web server (HTTP server)
 TCP connection closed

Application Layer 2-21

HTTP connections
non-persistent HTTP persistent HTTP
 at most one object sent
 multiple
over TCP
objects
connection can be sent over
single TCP
 connection then closed
connection
 downloading multiple objects required
multiple connections between client,
 (connection closed)
server
 (keep connection)

Application Layer 2-22

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

Application Layer 2-24

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

2RTT+ file Application Layer 2-25

Persistent HTTP

non-persistent HTTP persistent HTTP:

issues:  server leaves
 requires 2 RTTs per connection open
object after sending
 OS overhead for each response
TCP connection  subsequent HTTP
 browsers often open messages between
parallel TCP same client/server
connections to fetch sent over open
referenced objects connection
 client sends requests
as soon as it
encounters a
referenced object
 as little as one RTT
for all the referenced 2-26
Example 1 (Problem 8)
Suppose that the Web page associated
with the link contains exactly one object,
consisting of a small amount of HTML text
which references to eight very small
objects on the same server. Let RTT0
denote the RTT between the local host
and server. Neglecting transmission
times, how much time elapses with
a. Non-persistent HTTP with no parallel
TCP connections?
b. Non-persistent HTTP with the browser
configured for 5 parallel connections?
c. Persistent HTTP?
Application Layer 2-27
Example 1 - answer
a) 2RTT0 + 8*2RTT0
= 18RTT0
b) 2RTT0 + 2* (RTT0 + RTT0)
= 6RTT0
c) Persistent connection with pipelining.
This is the default mode of HTTP
2RTT0 + RTT0 = 3RTT0
Persistent connection without pipelining,
without parallel connections.
2RTT0 + 8RTT0 = 10RTT0
Application Layer 2-28
Example 2 (Problem 10)
Consider a short, 10-meter link, over which a
sender can transmit at a rate of 150 bits/sec in
both directions. Suppose that packets
containing data (HTML and 10 objects) are
100,000 bits long each, and packets
containing only control (e.g., ACK or
handshaking) are 200 bits long.

1) How much time elapses with non-persistent HTTP

and parallel downloads? Draw the figure before the
calculation.

2) How about persistent HTTP. Do you expect

significant gains over the non-persistent case? Draw
the figure before the calculation. 2-29
Application Layer
Example 2 - answer
1) Non-persistent with parallel
download:
(200/150 + Tp + 200/150 + Tp +
200/150+Tp + 100,000/150+ Tp )
+
(200/(150/10)+Tp + 200/(150/10) +
Tp + 200/(150/10)+Tp +
100,000/(150/10) + Tp )
= 7377 + 8 * Tp (seconds)

2)Persistent HTTP:
(200/150+Tp + 200/150 + Tp +
200/150 + Tp + 100,000/150 + Tp )
+
10 * (200/(150/10) + Tp +
100,000/(150/10)+ Tp )

=7351 + 24 * Tp (seconds)

Application Layer 2-30

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

Application Layer 2-32

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

Application Layer 2-33

 HTTP response message
status line
(protocol
status code HTTP/1.1 200 OK\r\n
status phrase) Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n
Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 17:00:02
GMT\r\n
header ETag: "17dc6-a5c-bf716880"\r\n
Accept-Ranges: bytes\r\n
lines Content-Length: 2652\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html; charset=ISO-8859-1\
r\n
\r\n
data, e.g., data data data data data ...
requested
HTML file
Application Layer 2-34
HTTP response status codes
 status code appears in 1st line in server-to-
client response message.
 some sample codes:
200 OK
 request succeeded, requested object later in this msg
301 Moved Permanently
 requested object moved, new location specified later in
this msg (Location: header of the response message. The
client software will automatically retrieve the new URL)
400 Bad Request
 request msg not understood by server
404 Not Found
 requested document not found on this server
505 HTTP Version Not Supported
Application Layer 2-35
Quiz - Problems 4&5
 Answer the questions in Problems 4 and
5, pages 171 - 172.

Application Layer 2-36

User-server state: cookies
example:
many Web sites use  Susan always access
cookies Internet from PC
four components:  visits specific e-
1) cookie header line commerce site for first
of HTTP response time
message  when initial HTTP

2) cookie header requests arrives at

line in next HTTP site, site creates:
request message  unique ID
3) cookie file kept  entry in backend
on user’s host, database for ID
managed by
user’s browser
4) back-end
Application Layer 2-37
database at Web
 Cookies: keeping “state” (cont.)
client server

Shopee 8734
usual http request msg Tiki server
cookie file creates ID
usual http response
1678 for user create backend
Shopee 8734
set-cookie: 1678 entry database
Tiki 1678
usual http request msg
cookie: 1678 cookie- access
specific
usual http response msg action

one week later:

access
Shopee 8734 usual http request msg
Tiki 1678 cookie: 1678 cookie-
specific
usual http response msg action
Application Layer 2-38
Cookies (continued)
aside
what cookies can cookies and privacy:
be used for:  cookies permit sites
 authorization to learn a lot about
 shopping carts you
 recommendations  you may supply
 user session state
(Web e-mail) name and e-mail to
sites
how to keep “state”:
 protocol endpoints: maintain
state at sender/receiver over
multiple transactions
 cookies: http messages carry
state
Application Layer 2-39
Web caches (proxy server)
goal: satisfy client request without involving
origin
 user server
sets browser:
Web accesses via
cache
proxy
 browser sends all HT
TP
req server u est
req
HTTP requests to HT
client TP
ues
t H TTP
o nse
res p origin
cache pon P res
se T server
HT
 object in cache: ues
t
cache returns req e
TT P o ns
p
object H res
T TP
 else cache H

requests object client origin

from origin server, server
then returns
object to client
Application Layer 2-40
More about Web caching
 cache acts as why Web caching?
both client and  reduce response
server time for client
 server for original
requesting client
request
 client to origin server  reduce traffic on an
 typically cache is institution’s access
installed by ISP link
(university,  Internet dense with
company, caches: enables
residential ISP) “poor” content
providers to
effectively deliver
content (so too
Application Layer 2-41
Caching example:
assumptions:
 avg object size (L): 100K bits
 avg request rate from browsers origin
servers
to origin servers (a):15 public
requests/sec Internet
 avg data rate to browsers (R):
1.50 Mbps
 RTT from institutional router to
any origin server: 2problem:
sec large 1.54 Mbps
 access link rate: 1.54 Mbps
queueing delays access link
at high utilization institutional
consequences: network
 LAN utilization: 0.0015 1 Gbps LAN
 access link utilization = 97%
 total delay = Internet delay +
access delay + LAN delay
= 2 sec + minutes + usecs
traffic intensity = La/R
L: packet length (bits)
a: average packet arrival rate. R: link bandwidth (bps)
Application Layer 2-42
 Caching example: fatter
access link
assumptions:
 avg object size: 100K bits
origin
 avg request rate from servers
browsers to origin public
servers:15/sec Internet
 avg data rate to browsers:
1.50 Mbps
 RTT from institutional router
to any origin server: 2154
sec 1.54 Mbps
154 Mbps
 access link rate: 1.54 Mbps access link
Mbps
institutional
consequences: network
 9.9%
LAN utilization: 0.0015 1 Gbps LAN
 access link utilization = 99%
 total delay = Internet delay +
access delay + LAN delay
msecs + usecs
= 2 sec + minutes
Cost: increased access link speed (not cheap!)
Application Layer 2-43
 Caching example: install local
cache
assumptions:
 avg object size: 100K bits
origin
 avg request rate from servers
browsers to origin public
servers:15/sec Internet
 avg data rate to browsers:
1.50 Mbps
 RTT from institutional router
to any origin server: 2 sec 1.54 Mbps
 access link rate: 1.54 Mbps access link
institutional
consequences: network
 ?
LAN utilization: 0.0015 1 Gbps LAN
 ?
access link utilization = 100% local web
 Howdelay
total to compute
= Internetlink
delay + cache
utilization,
access delay + LANdelay?
delay
= 2 sec + minutes + usecs
Cost: web cache (cheap!)
Application Layer 2-44
Caching example: install local
cache
Calculating access link
utilization, delay with
origin
cache: servers
 suppose cache hit rate is public
0.4 Internet
 40% requests satisfied at
 access link utilization:
cache, 60% requests
 60% of requests use access link
satisfied at origin
 data rate to browsers over 1.54 Mbps
access link
access link
= 0.6*1.50 Mbps = .9 Mbps institutional
 utilization = 0.9/1.54 = .58 network
1 Gbps LAN
or La/R = (15 * 60%) * 0.1 /1.54 =
 total
0.58 delay local web
 = 0.6 * (delay from origin cache
servers) +0.4 * (delay when
satisfied at cache)
 = 0.6 (2.01) + 0.4 (~msecs) =
~ 1.2 secs
Application Layer 2-45
 less than with 154 Mbps link
Conditional GET
client server
 Goal: don’t send
object if cache has
up-to-date cached HTTP request msg
object
If-modified-since: <date>
version not
 no object modified
transmission delay HTTP response
before
HTTP/1.0
 lower link utilization <date>
304 Not Modified
 cache: specify date
of cached copy in
HTTP request
If-modified-since: HTTP request msg
<date> If-modified-since: <date> object
 server: response modified
after
contains no object if HTTP response
HTTP/1.0 200 OK <date>
cached copy is up-
<data>
to-date:
HTTP/1.0 304 Not Application Layer 2-46
Lecture 2: outline
2.1 principles of network applications
 app architectures
 app requirements
2.2 Web and HTTP
2.3 electronic mail
 SMTP, POP3, IMAP
2.4 DNS
2.5 Socket programming

Application Layer 2-47

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

mail server
Application Layer 2-49
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 ASCII
Application Layer 2-50
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 Bob’s mailbox
placed in message 6) Bob invokes his user
queue agent to read message
3) client side of SMTP
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
Application Layer 2-51
Sample SMTP interaction
C: telnet hamburger.edu 25
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

Application Layer 2-52

SMTP: final words
 SMTP uses persistent comparison with
connections HTTP:
 SMTP requires  HTTP: pull
message (header &
body) to be in 7-bit
 SMTP: push
ASCII  both have ASCII
command/response
interaction, status
codes
 HTTP: each object
encapsulated in its
own response msg
 SMTP: multiple
objects sent in
multipart msgApplication Layer 2-53
Mail message format
SMTP: protocol for
exchanging email header
msgs blank
line
RFC 822: standard for
text message
format:
 header lines, e.g.,
body
 To:
 From:
 Subject:
 Body: the “message”
 ASCII characters only

Application Layer 2-54

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

sender’s mail receiver’s mail

server server

 SMTP: delivery/storage to receiver’s server

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

Application Layer 2-55

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

Application Layer 2-57

Lecture 2: outline
2.1 principles of network applications
 app architectures
 app requirements
2.2 Web and HTTP
2.3 electronic mail
 SMTP, POP3, IMAP
2.4 DNS
2.5 Socket programming

Application Layer 2-58

DNS: domain name system
people: many Domain Name System:
identifiers:  distributed database
 SSN, name, implemented in
passport # hierarchy of many name
Internet hosts, routers: servers
 IP address (32 bit)  application-layer
- used for protocol: hosts, name
addressing servers communicate to
datagrams resolve names
 “name”, e.g., (address/name
www.yahoo.com - translation)
used by humans  note: core Internet
Q: how to map function, implemented
between IP address as application-layer
and name, and vice protocol
versa ?  complexity atApplication Layer 2-59
DNS: services
 hostname to IP address
translation
 host aliasing
 canonical, alias names
 mail server aliasing
 load distribution

 replicated Web servers: many IP

addresses correspond to one
name

Application Layer 2-60

DNS: a distributed, hierarchical
database
Root DNS Servers

… …

com DNS servers org DNS servers edu DNS servers

pbs.org poly.edu umass.edu

yahoo.com amazon.com
DNS servers DNS serversDNS servers
DNS servers DNS servers

why not centralize DNS?

 single point of failure
 traffic volume
 distant centralized database
 maintenance

Application Layer 2-61

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

e. NASA Mt View, CA m. WIDE Tokyo

f. Internet Software C. (5 other sites)
Palo Alto, CA (and 48 other
sites)

a. Verisign, Los Angeles CA 13 root name

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

Application Layer 2-62

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

Application Layer 2-64

DNS name
resolution root DNS server

example 2
 host at cis.poly.edu 3
TLD DNS server
wants IP address 4
for
gaia.cs.umass.edu 5

local DNS server

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

Application Layer 2-65

DNS name
resolution root DNS server

example 2 3
7
recursive query: 6
 puts burden of TLD DNS
server
name resolution
on contacted local DNS server
name server dns.poly.edu 5 4
 heavy load at 1 8
upper levels of
authoritative DNS server
hierarchy? dns.cs.umass.edu
requesting host
cis.poly.edu

gaia.cs.umass.edu

Application Layer 2-66

Problem 7
Suppose within your Web browser you click on a
link to obtain a Web page. The IP address for the
associated URL is not cached in your local host,
so a DNS lookup is necessary to obtain the IP
address. Suppose that n DNS servers are visited
before your host receives the IP address from
DNS; the successive visits incur an RTT of RTT1,
…, RTTn. Further suppose that the Web page
associated with the link contains exactly one
object, consisting of a small amount of HTML
text. Let RTT0 denote the RTT between the local
host and the server containing the object.
Assuming zero transmission time of the object,
how much time elapses from when the client
clicks on the link until the client receives the
object? Application Layer 2-67
Problem 7 - answer
 The total amount of time to get the IP
address is
RTT1 + RTT2 + … + RTTn
 Once the IP address is known, elapses
to set up the TCP connection and
another RTT0 elapses to request and
receive the small object. The total
response time is
2RTT0 + RTT1 + RTT2 + ... + RTTn

Application Layer 2-68

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

type=A type=CNAME
 name is hostname  name is alias name for some
 value is IP address “canonical” (the real) name
 www.ibm.com is really
type=NS
 name is domain servereast.backup2.ibm.com
(e.g., foo.com)  value is canonical name
 value is hostname
of authoritative type=MX
name server for this  value is name of
domain
mailserver associated with
name
Application Layer 2-70
DNS protocol, messages
 query and reply messages, both with
same message format2 bytes 2 bytes

msg header identification flags

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

additional info (variable # of RRs)

Application Layer 2-71

DNS protocol, messages

2 bytes 2 bytes

identification flags

# questions # answer RRs

# authority RRs # additional RRs

name, type fields

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

Application Layer 2-73

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

Application Layer 2-74

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

Application Layer 2-75

 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 data to
server
2. server receives the data and converts
characters to uppercase
3. server sends modified data to client
4. client receives modified data and
displays line on its screen Application Layer 2-76
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
 receiver extracts sender IP address and
port# from received packet
UDP: transmitted data may be lost or
received out-of-order
Application viewpoint:
 UDP provides unreliable transfer of groups
of bytes (“datagrams”) between client and
server
Application Layer 2-77
Client/server socket interaction:
UDP
server (running on serverIP) client
create socket:
create socket, port= x: clientSocket =
serverSocket = socket(AF_INET,SOCK_DGRAM)
socket(AF_INET,SOCK_DGRAM)
Create datagram with server IP and
port=x; send datagram via
read datagram from clientSocket
serverSocket

write reply to
serverSocket read datagram from
specifying clientSocket
client address,
port number close
clientSocket

Application 2-78
 Example app: UDP client
Python UDPClient
include Python’s socket
library from socket import *
serverName = ‘hostname’
serverPort = 12000
create UDP socket for clientSocket = socket(AF_INET,
server
SOCK_DGRAM)
get user keyboard
input message = raw_input(’Input lowercase sentence:’)
Attach server name, port to clientSocket.sendto(message.encode(),
message; send into socket
(serverName, serverPort))
read reply characters from modifiedMessage, serverAddress =
socket into string
clientSocket.recvfrom(2048)
print out received string print modifiedMessage.decode()
and close socket
clientSocket.close()
Application Layer 2-79
 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 True:
Read from UDP socket into message, clientAddress = serverSocket.recvfrom(2048)
message, getting client’s
address (client IP and port) modifiedMessage = message.decode().upper()
send upper case string serverSocket.sendto(modifiedMessage.encode(),
back to this client clientAddress)

Application Layer 2-80

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

wait for incoming create socket,

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

send request using

read request from clientSocket
connectionSocket

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

Application Layer 2-82

 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.encode())
name, port
modifiedSentence = clientSocket.recv(1024)
print (‘From Server:’, modifiedSentence.decode())
clientSocket.close()

Application Layer 2-83

 Example app: TCP server
Python 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 True:
server waits on accept() connectionSocket, addr = serverSocket.accept()
for incoming requests, new
socket created on return
sentence = connectionSocket.recv(1024).decode()
read bytes from socket (but
not address as in UDP) capitalizedSentence = sentence.upper()
close connection to this
connectionSocket.send(capitalizedSentence.
client (but not welcoming encode())
socket)
connectionSocket.close()
Application Layer 2-84
Video streaming and CDN

Application Layer 2-85

Video Streaming and CDNs:
context
 video traffic: major consumer of Internet bandwidth
• Netflix, YouTube: 37%, 16% of downstream
residential ISP traffic
• ~1B YouTube users, ~75M Netflix users
 challenge: scale - how to reach ~1B
users?
• single mega-video server won’t work (why?)
 challenge: heterogeneity
 different users have different capabilities (e.g.,
wired versus mobile; bandwidth rich versus
bandwidth poor)
 solution: distributed, application-level
infrastructure

Application Layer 2-86

Multimedia: spatial coding example: instead
of sending N values of same

video
color (all purple), send only two
values: color value (purple) and
number of repeated values (N)
 video: sequence of
images displayed at ……………………..
……………….…….
constant rate
 e.g., 24 images/sec
 digital image: array of
pixels
 each pixel
represented by bits frame i
 coding: use
redundancy within
and between images temporal coding example:
to decrease # bits instead of sending
used to encode image complete frame at i+1,
send only differences from
 spatial (within frame i frame i+1
image)
 temporal (from one Application Layer 2-87
 Multimedia: spatial coding example: instead
of sending N values of same

video
color (all purple), send only two
values: color value (purple) and
 CBR: (constant bit number of repeated values (N)

rate): video encoding ……………………..

……………….…….
rate fixed
 VBR: (variable bit
rate): video encoding
rate changes as
amount of spatial,
temporal coding
frame i
changes
 examples:
• MPEG 1 (CD-ROM)
temporal coding example:
1.5 Mbps instead of sending
complete frame at i+1,
• MPEG2 (DVD) 3-6 send only differences from
frame i+1
Mbps frame i

• MPEG4 (often used

Application Layer 2-88
in Internet, < 1
Dynamic Adaptive
Streaming over HTTP
(DASH)

Application Layer 2-89

Streaming multimedia:
DASH
 DASH: Dynamic, Adaptive Streaming
over HTTP
 server:
 divides video file into multiple chunks
 each chunk stored, encoded at different
rates
 manifest file: provides URLs for different
chunks
 client:
 periodically measures server-to-client
bandwidth
 consulting manifest, requests one chunk at
a time
• chooses maximum coding rate
Application Layer 2-90
sustainable given current bandwidth
 Dynamic Adaptive
Streaming over HTTP
(DASH)

O. Oyman and S. Singh. “Quality of experience for HTTP adaptive streaming

services" IEEE Communications Magazine, vol. 50, no. 4 (2012): 20-27. 91
Media Presentation
Description XML file

Application Layer 2-92

Streaming multimedia:
DASH
 DASH: Dynamic, Adaptive Streaming
over HTTP
 “intelligence” at client: client
determines
 when to request chunk (so that buffer
starvation, or overflow does not occur)
 what encoding rate to request (higher
quality when more bandwidth available)
 where to request chunk (can request from
URL server that is “close” to client or has
high available bandwidth)

Application Layer 2-93

Streaming stored video:
simple scenario:

Internet

video server client

(stored video)

Application Layer 2-94

Content distribution
networks
 challenge: how to stream content
(selected from millions of videos) to
hundreds of thousands of simultaneous
users?

 option 1: single, large “mega-server”

 single point of failure
 point of network congestion
 long path to distant clients
 multiple copies of video sent over outgoing
link

….quite simply: this solution doesn’t scale

Application Layer 2-95
Content distribution
networks
 challenge: how to stream content
(selected from millions of videos) to
hundreds of thousands of simultaneous
users?

 option 2: store/serve multiple copies of

videos at multiple geographically
distributed sites (CDN)
 enter deep: push CDN servers deep into
many access networks
• close to users
• used by Akamai, 1700 locations
 bring home: smaller number (10’s) of larger
clusters in POPs near (but not within) access
networks Application Layer 2-96
 Content Distribution Networks
(CDNs)
 CDN: stores copies of content at CDN
nodes
 subscriber
• e.g. Netflixrequests
stores copies of MadMen
content from CDN
• directed to nearby copy, retrieves content
• may choose different copy if network path
congested

… …

…
manifest file
…

where’s Madmen?

… …
Application Layer 2-97
 CDN content access: a closer
look
Bob (client) requests video http://netcinema.com/6Y7B23
 video stored in CDN at http://KingCDN.com/NetC6y&B23V

1. Bob gets URL for video

http://netcinema.com/6Y7B23V
from netcinema.com web page 2. resolve http://netcinema.com/6Y7B23V
2 via Bob’s local DNS
1
6. request video from 5 Bob’s
KINGCDN server, local DNS
streamed via HTTP server
3. netcinema’s DNS returns URL 4&5. Resolve
netcinema.com 4 http://KingCDN.com/NetC6y&B23
http://KingCDN.com/NetC6y&B23V
via KingCDN’s authoritative DNS,
3 which returns IP address of KingCDN
server with video
netcinema’s
authoratative DNS KingCDN.com KingCDN
authoritative DNS Application Layer 2-98
 Case study: Netflix
Amazon cloud upload copies of
multiple versions of
video to CDN servers
CDN
server
Netflix registration,
accounting servers
3. Manifest file
2. Bob browses returned for
CDN
Netflix video 2 requested video server
3
1

1. Bob manages
Netflix account CDN
server

4. DASH streaming

Application Layer 2-99

Lecture 2:
summary
our study of network apps now
complete!
 application architectures  specific protocols:
 client-server  HTTP
 P2P  SMTP, POP, IMAP
 application service  DNS
requirements:
 reliability, bandwidth,
delay
 Internet transport
service model
 connection-oriented,
reliable: TCP
 unreliable,
datagrams: UDP
Application Layer 2-100
Lecture 2:
summary
most importantly: learned about
protocols!
 typical request/reply
important themes:
message exchange:
 client requests
 control vs. data msgs
info or service  in-band, out-of-band
 server responds  centralized vs.
with data, status decentralized
code  stateless vs. stateful
 message formats:
 headers: fields  reliable vs. unreliable
giving info about msg transfer
data  “complexity at
 data: info being network edge”
communicated
Application Layer 2-101