Chapter 2

Application Layer Computer

Networking: A Top
Down Approach
6th edition
Jim Kurose, Keith Ross
Addison-Wesley
March 2012

Application Layer 2-1

s

Application layer: overview

▪ Principles of network ▪ video streaming and content
applications distribution networks
▪ Web and HTTP
▪ FTP
▪ E-mail, SMTP, IMAP
▪ The Domain Name
System DNS
 Application layer
❖ This layer allows people to use the Internet
❖ Other 4 layers are just made so people can use application programs

11/17/2024
Internet applications

Application Application layer Transport protocol

protocol
E-mail SMTP TCP

Remote terminal access telnet TCP

Web HTTP TCP

File transfer FTP TCP

Streaming multimedia Proprietary TCP or UDP

Internet telephony Proprietary Typically UDP

11/17/2024
Application layer

11/17/2024
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

no need to write software for application

network-core devices transport

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

❖ applications on end systems

allows for rapid app
development, propagation

Application Layer2-6
 Application architectures
possible structure of applications:
❖ client-server
❖ peer-to-peer (P2P)

Application Layer2-7
 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 Layer2-8
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 IP
addresses
▪ complex management

Application Layer2-9
P2P file distribution: BitTorrent
❖ file divided into 256Kb chunks
❖ peers in torrent send/receive file chunks

tracker: tracks peers torrent: group of peers

participating in torrent exchanging chunks of a file

Alice arrives …
… obtains list
of peers from tracker
… and begins exchanging
file chunks with peers in torrent

Application Layer2-10
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 (selfishly) leave or
(altruistically) remain in torrent

Application Layer2-11
Processes communicating
process: program running clients, servers
within a host client process: process that
❖ within same host, two initiates communication
processes communicate server process: process that
using inter-process waits to be contacted
communication (defined by
OS)
❖ processes in different hosts
communicate by exchanging ❖ aside: applications with P2P
messages architectures have client
processes & server
processes

Application Layer2-12
Addressing processes
❖ to receive messages, ❖ identifier includes both IP
process must have identifier address and port numbers
❖ host device has unique 32- associated with process on
bit IP address host.
❖ Ports are identified for each ❖ example port numbers:
protocol and It is ▪ HTTP server: 80
considered as a ▪ mail server: 25
communication endpoint. ❖ to send HTTP message to
❖ Ports are represented by gaia.cs.umass.edu web
16-bit numbers. There are server:
2^16 port numbers i.e ▪ IP address: 128.119.245.12
65536 ▪ port number: 80
❖ Q: does IP address of host ▪ A: no, many processes
(on which process runs) can be running on same
suffice for identifying the host
process?
Application Layer2-13
App-layer protocol defines
❖ types of messages open protocols:
exchanged, ❖ defined in RFCs
▪ e.g., request, response ❖ allows for interoperability
❖ message syntax: ❖ e.g., HTTP, SMTP
▪ what fields in messages proprietary protocols:
& how fields are
❖ e.g., Skype
delineated
❖ message semantics
▪ meaning of information
in fields
❖ rules for when and how
processes send & respond
to messages

Application Layer2-14
s

Application layer: overview

▪ Principles of network ▪ video streaming and
applications content distribution
▪ Web and HTTP networks
▪ FTP
▪ E-mail, SMTP, IMAP
▪ The Domain Name
System DNS
WWW
❖ World Wide Web
❖ Introduced in 1991
❖ originated from the CERN High-Energy Physics laboratories in
Geneva, Switzerland.

11/17/2024
The Web: Some Jargon
❖ Web page
▪ consists of objects (HTML file, JPEG image, GIF image…)
▪ addressed by URL
❖ Most Web pages consist of
▪ base HTML page
▪ several referenced objects
❖ URL
▪ A standard way of specifying the location of an object, typically a web page,
on the Internet
❖ User agent for Web is called a browser
▪ MS Internet Explorer
❖ Server for Web is called a Web server
11/17/2024
HyperText Transfer Protocol
❖ Web’s application layer protocol
▪ Used to access data on the World Wide Web
▪ Rapid jump from one document to another
❖ Client-server model
▪ client: browser that requests, receives, “displays” web objects
▪ server: Web server sends objects in response to request
❖ uses one TCP connection on the well-known port 80

11/17/2024
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, e.g.,
www.someschool.edu/someDept/pic.gif

host name path name

Application Layer2-19
URL - continued

❖ method
▪ protocol used to retrieve the document (FTP, HTTP, …)
❖ host
▪ a computer where the info is located
▪ the name of the computer can be an alias (not necessary
www)
❖ port
▪ optional port # of the server
❖ path
▪ the path name of the file where the info is located
 Figure 27.1 Architecture of WWW

27.21
Static Documents
1. Static documents are fixed-content documents that are created and stored
in a server.
2. The client can get a copy of the document only.
3. In other words, the contents of the file are determined when the file is
created, not when it is used.
4. Of course, the contents in the server can be changed, but the user
cannot change them.
5. When a client accesses the document, a copy of the document is sent.
6. The user can then use a browser to see the document.
Dynamic Documents
1. A dynamic document is created by a web server whenever a browser requests
the document.
2. When a request arrives, the web server runs an application program or a
script that creates the dynamic document.
3. The server returns the result of the program or script as a response to the
browser that requested the document
4. Because a fresh document is created for each request, the contents of a
dynamic document may vary from one request to another.
5. A very simple example of a dynamic document is the retrieval of
the time and date from a server.
6. Time and date are kinds of information that are dynamic in that they change
from moment to moment.
 Active Documents
1. For many applications, we need a program or a script to be run at the
client site.
2. These are called active documents.
3. For example, suppose we want to run a program that creates animated graphics on
the screen or a program that interacts with the user.
4. The program definitely needs to be run at the client site where the animation or
interaction takes place.
5. When a browser requests an active document, the server sends a copy of the
document or a script.
6. The document is then run at the client (browser) site.
1. Java Applet – A program written in Java on the server. It is compiled and
ready to be run. The document is in bytecode format.
2. Java Script - Download and run the script at
the client site.
 Figure 27.6 Effect of boldface tags

27.26
HTTP overview
HTTP: hypertext
transfer protocol
❖ Web’s application layer
protocol PC running
Firefox browser
❖ client/server model
▪ client: browser that
requests, receives,
(using HTTP protocol) server
and “displays” Web running
objects Apache Web
▪ server: Web server server
sends (using HTTP
protocol) objects in iphone running
response to requests Safari browser

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

Application Layer2-28
HTTP connections
non-persistent HTTP persistent HTTP
❖ at most one object sent over ❖ multiple objects can
TCP connection be sent over single
▪ connection then closed TCP connection
❖ downloading multiple objects
between client, server
required multiple connections

Application Layer2-29
Application Layer2-30
 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 port www.someSchool.edu waiting
80 for TCP connection at port 80.
“accepts” connection, notifying
2. HTTP client sends HTTP request client
message (containing URL) into
TCP connection socket. 3. HTTP server receives request
Message indicates that client message, forms response
wants object message containing requested
someDepartment/home.index object, and sends message into
its socket
time
Application Layer2-31
 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 Layer2-32
Non-persistent HTTP: response time

RTT (definition): time for a

small packet to travel from
client to server and back
HTTP response time: initiate TCP
connection
❖ one RTT to initiate TCP
connection RTT
request
❖ one RTT for HTTP request file
and first few bytes of HTTP RTT
time to
response to return transmit
file
❖ file transmission time file
received
❖ non-persistent HTTP
response time =
time time
2RTT+ file transmission
time

Application Layer2-33
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 ❖ subsequent HTTP
parallel TCP connections messages between same
to fetch 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

Application Layer2-34
❖ Most Web Browsers use persistent connection

Application Layer2-35
HTTP – message format
❖ two types of messages: request & response
▪ ASCII (human-readable format)

11/17/2024
HTTP protocol – message format
❖ HTTP request message
HTTP 0.9
HTTP 1.0
HTTP 1.1

GET – when the client wants to retrieve a document

from the server
HEAD – when the client wants some info about a
document but not document itself
COPY – copies the file to another location

11/17/2024
 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
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
carriage return, Keep-Alive: 115\r\n
Connection: keep-alive\r\n
line feed at start
\r\n
of line indicates
end of header lines
Application Layer2-38
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
requested object out in URL field
of response ❖ DELETE
▪ deletes file specified in
the URL field

Application Layer2-39
HTTP request message: general format

method sp URL sp version cr lf request

line
header field name value cr lf
header
~
~ ~
~ lines

header field name value cr lf

cr lf

~
~ entity body ~
~ body

Application Layer2-40
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

Application Layer2-41
HTTP – message format
❖ HTTP response message http://www.w3.org/Protocols/HTTP/HTRESP.html

explains the status code

in text form

200 OK – request succeeded

301 Moved Permanently – object
moved
400 Bad Request – not understood by
server
11/17/2024
404 Not Found – req. document not found
 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 Layer2-43
HTTP response status codes
❖ status code appears in 1st line in server-to-
client response message.
❖ some sample codes:

Application Layer2-44
 HTTP response status codes

27.45
HTTP messages – an example

This example retrieves a document.

We use the GET method to retrieve an image with the path/usr/bin/image1.
The request line shows the method (GET), the URL, and the HTTP version
(1.1).
The header has two lines that show that the client can accept images in GIF
11/17/2024 and JPEG format.
User-server state: cookies
example:
many Web sites use cookies ❖ Susan always access Internet
four components: from PC
1) cookie header line of ❖ visits specific e-commerce
HTTP response site for first time
message ❖ when initial HTTP requests
2) cookie header line in arrives at site, site creates:
next HTTP request ▪ unique ID
message ▪ entry in backend
3) cookie file kept on database for ID
user’s host, managed
by user’s browser
4) back-end database at
Web site
Application Layer2-47
 Cookies: keeping “state” (cont.)
client server

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

one week later:

access
ebay 8734 usual http request msg
amazon 1678 cookie: 1678 cookie-
specific
usual http response msg action
Application Layer2-48
Cookies (continued)
aside
what cookies can be used cookies and privacy:
for: ❖ cookies permit sites to
❖ authorization learn a lot about you
❖ shopping carts
❖ you may supply name and
❖ recommendations
e-mail to sites
❖ user session state (Web
e-mail)

how to keep “state”:

❖ protocol endpoints: maintain state at
sender/receiver over multiple
transactions
❖ cookies: http messages carry state

Application Layer2-49
Web caches (proxy server)
goal: satisfy client request without involving origin server
❖ user sets browser: Web
accesses via cache
❖ browser sends all HTTP proxy
requests to cache server
▪ object in cache: cache client
origin
returns object server
▪ else cache requests
object from origin
server, then returns
object to client
client origin
server

Application Layer2-50
More about Web caching
❖ cache acts as both why Web caching?
client and server ❖ reduce response time
▪ server for original for client request
requesting client
▪ client to origin server ❖ reduce traffic on an
❖ typically cache is institution’s access link
installed by ISP ❖ Internet dense with
(university, company, caches: enables “poor”
residential ISP) content providers to
effectively deliver
content (so too does
P2P file sharing)

Application Layer2-51
Caching example:
assumptions:
❖ avg object size: 100K bits origin
❖ avg request rate from browsers to servers
origin servers:15/sec public
❖ avg data rate to browsers: 1.50 Mbps Internet
❖ RTT from institutional router to any
origin server: 2 sec
❖ access link rate: 1.54 Mbps 1.54 Mbps
access link
consequences:
❖ LAN utilization: 15% problem! institutional
network
❖ access link utilization = 99% 1 Gbps LAN
❖ total delay = Internet delay + access
delay + LAN delay
= 2 sec + minutes + usecs

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

Application layer: overview

▪ Principles of network ▪ video streaming and
applications content distribution
▪ Web and HTTP networks
▪ FTP
▪ E-mail, SMTP, IMAP
▪ The Domain Name
System DNS
FTP: the file transfer protocol
file transfer
FTP FTP FTP
user client server
interface
user
at host remote file
local file system
system

❖ transfer file to/from remote host

❖ client/server model
▪ client: side that initiates transfer (either to/from remote)
▪ server: remote host
❖ ftp: RFC 959
❖ ftp server: port 21
Application Layer2-57
 1. The two connections in FTP
have different lifetimes.
2. The control connection remains
connected during the entire
interactive FTP session.
3. The data connection is opened
and then closed for each file
transfer activity.
4. When a user starts an FTP
session, the control connection
opens.
5. While the control connection is
FTP uses two well-known TCP ports: open, the data connection can
1. Port 21 is used for the control be opened and closed multiple
connection times if several files are
2. Port 20 is used for the data transferred.
connection.
FTP: separate control, data connections
TCP control connection,
❖ FTP client contacts FTP server server port 21
at port 21, using TCP
❖ client authorized over control TCP data connection,
connection FTP server port 20 FTP
client server
❖ client browses remote
directory, sends commands
over control connection ❖ server opens another TCP
data connection to transfer
❖ when server receives file another file
transfer command, server
opens 2nd TCP data ❖ control connection: “out of
connection (for file) to client band” invalid command
❖ after transferring one file, ❖ FTP server maintains
server closes data connection “state”: current directory,
earlier authentication

Application Layer2-59
FTP COMMUNICATION
1. FTP Communication is achieved through commands and responses.
2. FTP Commands are sent from the client to the server
3. FTP responses are sent from the server to the client.
4. FTP Commands are in the form of ASCII uppercase, which may or
may not be followed by an argument.
1. Every FTP command generates at least one response.
2. A response has two parts: a three-digit number followed by text.
3. The numeric part defines the code; the text part defines needed parameter
FTP commands, responses
sample commands: sample return codes
❖ sent as ASCII text over ❖ status code and phrase (as
control channel in HTTP)
❖ USER username ❖ 331 Username OK,
❖ PASS password password required
❖ LIST return list of file in ❖ 125 data
current directory connection
already open;
❖ RETR filename transfer starting
retrieves (gets) file ❖ 425 Can’t open
❖ STOR filename stores data connection
(puts) file onto remote ❖ 452 Error writing
host file

Application Layer2-63
s

Application layer: overview

▪ Principles of network ▪ video streaming and
applications content distribution
▪ Web and HTTP networks
▪ FTP
▪ E-mail, SMTP, POP, IMAP
▪ The Domain Name
System DNS
Architecture of Email

Application Layer2-66
E-Mail Scenarios
Push and Pull operation in E-Mail:
E-Mail Architecture
1. User Agent:
❖ It is the first component in ‘E-Mail System
Architecture’.
❖ It provides services to the ‘User’ for sending and
receiving a message easier.
E-Mail Architecture:
Address
❖ To deliver a mail, the mail handling system must use
an addressing system with unique address.
❖ In the internet, the address consists of two parts:
“Local Part” and “Domain Part”, both are separated
by ‘@’ symbol. Example: [email protected].

Local Part @ Domain Part

 E-Mail Architecture
2. Message Transfer Agent (MTA): SMTP
❖ The actual mail transfer is done through ‘MTAs’.
❖ To send a mail, both sender and receiver must have ‘Client MTA’ and
‘Receiver MTA’.
❖ So the protocol which defines the “MTA client and server” is called as
“Simple Mail Transfer Protocol” (SMTP).
❖ 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
E-Mail Architecture
2. Message Transfer Agent (MTA): SMTP
❖ The SMTP is used at only two-stages between the
“sender and sender’s mail server” and “between the
two mail servers”.
E-Mail Architecture
2. Message Transfer Agent (MTA): SMTP
❖ The SMTP uses “Commands” and “Responses” to
transfer messages between the “MTA Client and
Server”.
❖ The Commands are sent from the client to server. It
consists of ‘keywords’ such as: ‘HELO’, ‘MAIL
FROM’, ‘RCPT TO’, ‘DATA’, ‘HELP’ etc.
E-Mail Architecture
3. Message Access Agent (MAA):
The SMTP is a ‘push’ protocol, it pushes the message
from client to server and it involved in first and second
stages.
❖ Now the third stage needs ‘pull’ protocol, it pulls the
message from server to client.

▪ 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.

These two protocols used in fourth scenario.

E-Mail Architecture
3. Message Access Agent (MAA):
E-Mail Architecture
3. Message Access Agent (MAA): POP
E-Mail Architecture
3. Message Access Agent (MAA): IMAP4
❖ It is similar to POP3 protocol with some more
features.
❖ It provides the following functions:
1. A user can search the content.
2. Partial download can possible if the bandwidth is limited.
3. A user can create, delete and rename mailboxes.
4. User can create hierarchy of mailboxes in folder wise.
A comparison of POP3 and IMAP
Feature POP3 IMAP
Where is emails stored? User’s PC Server
Where is emails read? Off-line On-line
Connect time required Little Much
Use of server resources Minimal Extensive
Multiple mailboxes No Yes
User control over downloading Little Great
Partial message downloads No Yes
Are disk quotas a problem? No Could be
Simple to implement Yes No
Keeps user state No Yes
Application Layer 2-77
Mail message format

SMTP: protocol for

exchanging email msgs header
blank
RFC 822: standard for text line
message format:
❖ header lines, e.g.,
▪ To: body
▪ From:
▪ Subject:
❖ Body: the “message”
▪ ASCII characters only

Application Layer2-78
s

Application layer: overview

▪ Principles of network ▪ video streaming and
applications content distribution
▪ Web and HTTP networks
▪ FTP
▪ E-mail, SMTP, IMAP
▪ The Domain Name
System DNS
DNS: domain name system
people: many identifiers: Domain Name System:
▪ SSN, name, passport # ❖ distributed database
Internet hosts, routers: implemented in hierarchy of
▪ IP address (32 bit) - many name servers
used for addressing ❖ application-layer protocol: hosts,
datagrams name servers communicate to
▪ “name”, e.g., resolve names (address/name
www.yahoo.com - translation)
used by humans ▪ note: core Internet function,
Q: how to map between IP implemented as application-
layer protocol
address and name, and
vice versa ? ▪ complexity at network’s
“edge”

Application Layer2-80
DNS: services, structure
DNS services why not centralize DNS?
❖ hostname to IP address ❖ single point of failure
translation ❖ traffic volume
❖ host aliasing ❖ distant centralized database
▪ canonical, alias names ❖ maintenance
❖ mail server aliasing
❖ load distribution A: doesn’t scale!
▪ replicated Web
servers: many IP
addresses correspond
to one name

Application Layer2-81
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 servers DNS servers
DNS servers DNS servers

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

❖ client queries root server to find com DNS server
❖ client queries .com DNS server to get amazon.com DNS server
❖ client queries amazon.com DNS server to get IP address for
www.amazon.com

Application Layer2-82
 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 name server

c. Cogent, Herndon, 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 Layer2-83
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 Layer2-84
 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 Layer2-85
DNS name root DNS server
resolution example
2
❖ host at cis.poly.edu 3
TLD DNS server
wants IP address for 4
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 contact
authoritative DNS server
❖ “I don’t know this dns.cs.umass.edu
name, but ask this requesting host
cis.poly.edu
server”
gaia.cs.umass.edu

Application Layer2-86
DNS name
resolution example root DNS server

recursive query: 2 3

❖ puts burden of name 7 6

resolution on TLD DNS server
contacted name
server local DNS server
5 4
dns.nyu.edu
❖ heavy load at upper gaia.cs.umass.edu
levels of hierarchy? 1 8

authoritative DNS server

dns.cs.umass.edu

requesting host at
engineering.nyu.edu
Application Layer2-87
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 Layer2-88
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 (e.g., servereast.backup2.ibm.com
foo.com) ▪ value is canonical name
▪ value is hostname of
authoritative name type=MX
server for this domain ▪ value is name of mailserver
associated with name

Application Layer2-89
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 Layer2-90
Attacking DNS
DDoS attacks Redirect attacks
❖ Bombard root servers with ❖ Man-in-middle
traffic ▪ Intercept queries
▪ Not successful to date ❖ DNS poisoning
▪ Traffic Filtering ▪ Send bogus relies to DNS server,
▪ Local DNS servers cache IPs of which caches
TLD servers, allowing root Exploit DNS for DDoS
server bypass
❖ Send queries with spoofed
❖ Bombard TLD servers
source address: target IP
▪ Potentially more dangerous
❖ Requires amplification

Application Layer2-91
s

Application layer: overview

▪ Principles of network ▪ video streaming and
applications content distribution
▪ Web and HTTP networks
▪ FTP
▪ E-mail, SMTP, IMAP
▪ The Domain Name
System DNS
Video Streaming and CDNs: context
▪ stream video traffic: major consumer of Internet bandwidth
• Netflix, YouTube, Amazon Prime: 80% of residential ISP traffic (2020)
▪ challenge: scale - how to reach ~1B users?

▪ 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-93
Multimedia: video spatial coding example: instead
of sending N values of same
color (all purple), send only two
values: color value (purple) and

▪ video: sequence of images number of repeated values (N)

displayed at constant rate ……………………..

……………….…….
• e.g., 24 images/sec
▪ digital image: array of pixels
• each pixel represented by bits
▪ coding: use redundancy within and frame i
between images to decrease # bits
used to encode image
• spatial (within image) temporal coding example:
instead of sending
• temporal (from one image to complete frame at i+1,
send only differences from
next) frame i frame i+1

Application Layer: 2-94

Multimedia: video spatial coding example: instead
of sending N values of same
color (all purple), send only two
values: color value (purple) and

▪ CBR: (constant bit rate): video number of repeated values (N)

encoding rate fixed ……………………..

……………….…….
▪ VBR: (variable bit rate): video
encoding rate changes as
amount of spatial, temporal
coding changes
▪ examples: frame i
• MPEG 1 (CD-ROM) 1.5 Mbps
• MPEG2 (DVD) 3-6 Mbps
temporal coding example:
• MPEG4 (often used in instead of sending
complete frame at i+1,
send only differences from
Internet, 64Kbps – 12 Mbps) frame i frame i+1

Application Layer: 2-95

Streaming stored video
simple scenario:

Internet
video server
client
(stored video)

Main challenges:
❖ server-to-client bandwidth will vary over time, with changing network
congestion levels (in house, access network, network core, video
server)
❖ packet loss, delay due to congestion will delay playout, or result in
poor video quality
Application Layer: 2-96
Streaming stored video

2. video
sent
1. video 3. video received, played out at client
recorded (30 frames/sec)
(e.g., 30 time
network delay
frames/sec) (fixed in this
example)
streaming: at this time, client playing out
early part of video, while server still sending
later part of video
Application Layer: 2-97
Streaming stored video: challenges
▪ continuous playout constraint: during client
video playout, playout timing must match
original timing
• … but network delays are variable (jitter), so will
need client-side buffer to match continuous playout
constraint
▪ other challenges:
• client interactivity: pause, fast-forward, rewind,
jump through video
• video packets may be lost, retransmitted
Application Layer: 2-98
Streaming stored video: playout buffering
constant bit
rate video client video constant bit
transmission reception rate video
playout at client
variable

buffered
network

video
delay

client playout time

delay

▪client-side buffering and playout delay: compensate for

network-added delay, delay jitter
Application Layer: 2-99
Streaming multimedia: DASH Dynamic, Adaptive
Streaming over HTTP
server:
▪ divides video file into multiple chunks ...
▪ each chunk encoded at multiple different rates ...
▪ different rate encodings stored in different files ?
▪ files replicated in various CDN nodes
...
▪ manifest file: provides URLs for different chunks client

client:
▪ periodically estimates server-to-client bandwidth
▪ consulting manifest, requests one chunk at a time
• chooses maximum coding rate sustainable given current bandwidth
• can choose different coding rates at different points in time (depending
on available bandwidth at time), and from different servers
Application Layer: 2-100
Streaming multimedia: DASH
▪“intelligence” at client: client
determines ...
• when to request chunk (so that buffer ...

starvation, or overflow does not occur) ?

• what encoding rate to request (higher ...
client
quality when more bandwidth
available)
• where to request chunk (can request
from URL server that is “close” to
client or has high available
bandwidth)

Streaming video = encoding + DASH + playout buffering Application Layer: 2-101

Content distribution networks (CDNs)
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 (and possibly congested) path to
distant clients

….quite simply: this solution doesn’t scale

Application Layer: 2-102
Content distribution networks (CDNs)
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
• Akamai: 240,000 servers deployed
in > 120 countries (2015)
• bring home: smaller number (10’s) of
larger clusters in POPs near access nets
• used by Limelight
Application Layer: 2-103
How does Netflix work?
▪ Netflix: stores copies of content (e.g., MADMEN) at its
(worldwide) OpenConnect CDN nodes
▪ subscriber requests content, service provider returns manifest
• using manifest, client retrieves content at highest supportable rate
• may choose different rate or copy if network path congested

manifest file
where’s Madmen?

Application Layer: 2-104

Content distribution networks (CDNs)

OTT: “over the top”

Internet host-host communication as a service

OTT challenges: coping with a congested Internet from the “edge”

▪ what content to place in which CDN node?
▪ from which CDN node to retrieve content? At which rate?
Application Layer: 2-105
Chapter 2: summary
our study of network apps now complete!
❖ application architectures ❖ specific protocols:
▪ client-server ▪ HTTP
▪ P2P ▪ FTP
❖ application service
requirements: ▪ SMTP, POP, IMAP
▪ reliability, bandwidth, delay ▪ DNS
❖ Internet transport service ▪ P2P: BitTorrent, DHT
model ❖ socket programming:TCP,
▪ connection-oriented, UDP sockets
reliable: TCP
▪ unreliable, datagrams: UDP

Application Layer2-106
Chapter 2: summary
most importantly: learned about protocols!

❖ typical request/reply important themes:

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

Application Layer2-107