Chapter 2

Application Layer

A note on the use of these Powerpoint slides:

We’re making these slides freely available to all (faculty, students, readers).
They’re in PowerPoint form so you see the animations; and can add, modify,
and delete slides (including this one) and slide content to suit your needs.

Computer
They obviously represent a lot of work on our part. In return for use, we only
ask the following:
§ If you use these slides (e.g., in a class) that you mention their source
(after all, we’d like people to use our book!) Networking: A Top
§ If you post any slides on a www site, that you note that they are adapted
from (or perhaps identical to) our slides, and note our copyright of this Down Approach
material.
7th edition
Thanks and enjoy! JFK/KWR Jim Kurose, Keith Ross
Pearson/Addison Wesley
All material copyright 1996-2016
April 2016
J.F Kurose and K.W. Ross, All Rights Reserved
Application Layer 2-1
Chapter 2: outline
2.1 principles of network 2.5 P2P applications
applications 2.6 video streaming and
2.2 Web and HTTP content distribution
2.3 electronic mail networks
• SMTP, POP3, IMAP 2.7 socket programming
2.4 DNS with UDP and TCP

Application Layer 2-2

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-
address and name, and layer protocol
vice versa ? • complexity at network’s
“edge”

Application Layer 2-3

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 Layer 2-4

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

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

§ 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 Layer 2-5

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-6

 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 logical root name
(5 other sites)
b. USC-ISI Marina del Rey, CA
“servers” worldwide
l. ICANN Los Angeles, CA •each “server” replicated
(41 other sites)
g. US DoD Columbus, many times
OH (5 other sites)

Application Layer 2-7

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-8

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 Layer 2-9

DNS name root DNS server
resolution example
2 3
recursive query: 7
6
§ puts burden of name TLD DNS
server
resolution on
contacted name local DNS server
server dns.poly.edu 5 4

§ heavy load at upper 1 8

levels of hierarchy?
authoritative DNS server
dns.cs.umass.edu
requesting host
cis.poly.edu

gaia.cs.umass.edu

Application Layer 2-10

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-11

DNS records
DNS: distributed database 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 Layer 2-12

DNS protocol, messages
§ query and reply messages, both with same message
format 2 bytes 2 bytes

message header identification flags

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

query, reply to query uses
# authority RRs # additional RRs
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-13

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-14
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-15

Attacking DNS
DDoS attacks redirect attacks
§ bombard root servers § man-in-middle
with traffic • Intercept queries
• not successful to date § DNS poisoning
• traffic filtering § Send bogus relies to
• local DNS servers cache DNS server, which
IPs of TLD servers, caches
allowing root server exploit DNS for DDoS
bypass
§ bombard TLD servers § send queries with
spoofed source
• potentially more
dangerous address: target IP
§ requires amplification
Application Layer 2-16
Chapter 2: outline
2.1 principles of network 2.5 P2P applications
applications 2.6 video streaming and
2.2 Web and HTTP content distribution
2.3 electronic mail networks
• SMTP, POP3, IMAP 2.7 socket programming
2.4 DNS with UDP and TCP

Application Layer 2-17

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)
• VoIP (Skype)

Application Layer 2-18

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

di: peer i download

file, size F u1 d1 capacity
us u2 d2
server
di
uN network (with abundant
bandwidth) ui
dN
ui: peer i upload
capacity

Application Layer 2-19

File distribution time: client-server
§ server transmission: must
sequentially send (upload) N F
us
file copies:
di
• time to send one copy: F/us
network
• time to send N copies: NF/us ui

§ client: each client must

download file copy
• dmin = min client download rate
• min client download time: F/dmin

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

increases linearly in N
Application Layer 2-20
File distribution time: P2P
§ server transmission: must
upload at least one copy F
us
• time to send one copy: F/us
di
§ client: each client must network
download file copy ui
• min client download time: F/dmin
§ clients: as aggregate must download NF bits
• max upload rate (limiting max download rate) is us + Sui

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

increases linearly in N …
… but so does this, as each peer brings service capacity
Application Layer 2-21
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
Application Layer 2-22
Chapter 2: outline
2.1 principles of network 2.5 P2P applications
applications 2.6 video streaming and
2.2 Web and HTTP content distribution
2.3 electronic mail networks
• SMTP, POP3, IMAP 2.7 socket programming
2.4 DNS with UDP and TCP

Application Layer 2-23

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-24

 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-25
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-26

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-27
 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-28
 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-29

Socket programming with TCP
client must contact server § when contacted by client,
§ server process must first be server TCP creates new socket
running for server process to
§ server must have created communicate with that
socket (door) that particular client
welcomes client’s contact • allows server to talk with
multiple clients
client contacts server by: • source port numbers used
§ Creating TCP socket, to distinguish clients
specifying IP address, port (more in Chap 3)
number of server process
§ when client creates socket: application viewpoint:
client TCP establishes TCP provides reliable, in-order
connection to server TCP byte-stream transfer (“pipe”)
between client and server

Application Layer 2-30

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-31

 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-32

 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()
for incoming requests, new
connectionSocket, addr = serverSocket.accept()
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
socket) encode())
connectionSocket.close()
Application Layer 2-33
Chapter 2: summary
our study of network apps now complete!
§ application architectures § specific protocols:
• client-server • HTTP
• P2P • SMTP, POP, IMAP
§ application service
requirements: • DNS
• reliability, bandwidth, delay • P2P: BitTorrent
§ Internet transport service § video streaming, CDNs
model § socket programming:
• connection-oriented,
TCP, UDP sockets
reliable: TCP
• unreliable, datagrams: UDP

Application Layer 2-34

Chapter 2: summary
most importantly: learned about protocols!

§ typical request/reply important themes:

message exchange:
§ control vs. messages
• 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 message
• headers: fields giving
info about data transfer
• data: info(payload) § “complexity at network
being communicated edge”

Application Layer 2-35