Chapter 2

Application Layer

A note on the use of these ppt slides:

We’re making these slides freely available to all (faculty, students, readers).
They’re in PowerPoint form so you can add, modify, and delete slides
(including this one) and slide content to suit your needs. They obviously
Computer Networking:
represent a lot of work on our part. In return for use, we only ask the A Top Down Approach,
following:
 If you use these slides (e.g., in a class) in substantially unaltered form,
5th edition.
that you mention their source (after all, we’d like people to use our book!) Jim Kurose, Keith Ross
 If you post any slides in substantially unaltered form on a www site, that
you note that they are adapted from (or perhaps identical to) our slides, and
Addison-Wesley, April
note our copyright of this material. 2009.
Thanks and enjoy! JFK/KWR

All material copyright 1996-2009

J.F Kurose and K.W. Ross, All Rights Reserved
2: Application Layer 1
Chapter 2: Application layer
 2.1 Principles of  2.6 P2P applications
network applications  2.7 Socket programming
 2.2 Web and HTTP with TCP
 2.3 FTP  2.8 Socket programming
 2.4 Electronic Mail with UDP
 SMTP, POP3, IMAP
 2.5 DNS

2: Application Layer 2
Chapter 2: Application Layer
Our goals:  learn about protocols
 conceptual, by examining popular
implementation application-level
aspects of network protocols
application protocols  HTTP
 transport-layer  FTP
service models  SMTP / POP3 / IMAP
DNS
 client-server


paradigm  programming network

 peer-to-peer
applications
paradigm  socket API

2: Application Layer 3
Some network apps
 e-mail  voice over IP
 web  real-time video
 instant messaging conferencing
 remote login  grid computing
 P2P file sharing 
 multi-user network 
games 
 streaming stored video
clips

2: Application Layer 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

No need to write software

transport
network
data link
for network-core devices
application
physical
transport
network
 Network-core devices do data link
physical
not run user applications
 applications on end systems
allows for rapid app
development, propagation
2: Application Layer 5
Chapter 2: Application layer
 2.1 Principles of  2.6 P2P applications
network applications  2.7 Socket programming
 2.2 Web and HTTP with TCP
 2.3 FTP  2.8 Socket programming
 2.4 Electronic Mail with UDP
 SMTP, POP3, IMAP  2.9 Building a Web
 2.5 DNS server

2: Application Layer 6
Application architectures
 Client-server
 Peer-to-peer (P2P)
 Hybrid of client-server and P2P

2: Application Layer 7
Client-server architecture
server:
 always-on host
 permanent IP address
 server farms for
scaling
clients:
client/server  communicate with server
 may be intermittently
connected
 may have dynamic IP
addresses
 do not communicate
directly with each other
2: Application Layer 8
Pure P2P architecture
 no always-on server
 arbitrary end systems
directly communicate peer-peer
 peers are intermittently
connected and change IP
addresses

Highly scalable but

difficult to manage

2: Application Layer 9
Hybrid of client-server and P2P
Skype
 voice-over-IP P2P application
 centralized server: finding address of remote
party:
 client-client connection: direct (not through
server)
Instant messaging
 chatting between two users is P2P
 centralized service: client presence
detection/location
• user registers its IP address with central
server when it comes online
• user contacts central server to find IP
addresses of buddies
2: Application Layer 10
Processes communicating
Process: program running Client process: process
within a host. that initiates
 within same host, two
communication
processes communicate Server process: process
using inter-process that waits to be
communication (defined contacted
by OS).
 processes in different  Note: applications with
hosts communicate by P2P architectures have
exchanging messages client processes &
server processes

2: Application Layer 11
 Sockets

 process sends/receives
host or host or
server server
messages to/from its
socket controlled by
app developer
 socket analogous to door process process

 sending process shoves socket socket

message out door TCP with TCP with
Internet buffers,
 sending process relies on buffers,
variables variables
transport infrastructure
on other side of door which
brings message to socket controlled
by OS
at receiving process

 API: (1) choice of transport protocol; (2) ability to fix

a few parameters (lots more on this later)
2: Application Layer 12
Addressing processes
 to receive messages,
process must have
identifier
 host device has unique
32-bit IP address
 Q: does IP address of
host suffice for
identifying the process?

2: Application Layer 13
Addressing processes
 to receive messages,  identifier includes both
process must have IP address and port
identifier numbers associated with
 host device has unique process on host.
32-bit IP address  Example port numbers:
 Q: does IP address of  HTTP server: 80
host on which process  Mail server: 25
runs suffice for  to send HTTP message
identifying the to gaia.cs.umass.edu web
process? server:
 A: No, many  IP address: 128.119.245.12
processes can be  Port number: 80
running on same host  more shortly…
2: Application Layer 14
App-layer protocol defines
 Types of messages Public-domain protocols:
exchanged,  defined in RFCs
 e.g., request, response  allows for
 Message syntax: interoperability
 what fields in messages &
 e.g., HTTP, SMTP
how fields are delineated
Proprietary protocols:
 Message semantics
 meaning of information in
 e.g., Skype
fields
 Rules for when and how
processes send &
respond to messages
2: Application Layer 15
 What transport service does an app need?
Data loss Throughput
 some apps (e.g., audio) can  some apps (e.g.,
tolerate some loss multimedia) require
 other apps (e.g., file minimum amount of
transfer, telnet) require throughput to be
100% reliable data “effective”
transfer
 other apps (“elastic apps”)
Timing make use of whatever
 some apps (e.g., throughput they get
Internet telephony,
interactive games) Security
require low delay to be  Encryption, data
“effective” integrity, …

2: Application Layer 16
 Transport service requirements of common apps

Application Data loss Throughput Time Sensitive

file transfer no loss elastic no

e-mail no loss elastic no
Web documents no loss elastic no
real-time audio/video loss-tolerant audio: 5kbps-1Mbps yes, 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
instant messaging no loss elastic yes and no

2: Application Layer 17
Internet transport protocols services

TCP service: UDP service:

 connection-oriented: setup  unreliable data transfer
required between client and between sending and
server processes receiving process
 reliable transport between  does not provide:
sending and receiving process connection setup,
 flow control: sender won’t reliability, flow control,
overwhelm receiver congestion control, timing,
throughput guarantee, or
 congestion control: throttle
security
sender when network
overloaded
 does not provide: timing, Q: why bother? Why is
minimum throughput there a UDP?
guarantees, security
2: Application Layer 18
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 (eg Youtube), TCP or UDP
RTP [RFC 1889]
Internet telephony SIP, RTP, proprietary
(e.g., Skype) typically UDP

2: Application Layer 19
Chapter 2: Application layer
 2.1 Principles of  2.6 P2P applications
network applications  2.7 Socket programming
 2.2 Web and HTTP with TCP
 2.3 FTP  2.8 Socket programming
 2.4 Electronic Mail with UDP
 SMTP, POP3, IMAP  2.9 Building a Web
 2.5 DNS server

2: Application Layer 20
DNS: Domain Name System

People: many identifiers: Domain Name System:

 SSN, name, passport #  distributed database
Internet hosts, routers: implemented in hierarchy of
many name servers
 IP address (32 bit) -
 application-layer protocol
used for addressing
host, routers, name servers to
datagrams
communicate to resolve names
 “name”, e.g., (address/name translation)
ww.yahoo.com - used by
 note: core Internet
humans
function, implemented as
Q: map between IP application-layer protocol
addresses and name ?  complexity at network’s
“edge”

2: Application Layer 21
 DNS
DNS services Why not centralize DNS?
 hostname to IP  single point of failure
address translation  traffic volume
 host aliasing  distant centralized
 Canonical, alias names database
 mail server aliasing  maintenance
 load distribution
 replicated Web doesn’t scale!
servers: set of IP
addresses for one
canonical name

2: Application Layer 22
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 approx:

 client queries a root server to find com DNS server
 client queries com DNS server to get amazon.com
DNS server
 client queries amazon.com DNS server to get IP
address for www.amazon.com
2: Application Layer 23
 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
a Verisign, Dulles, VA
c Cogent, Herndon, VA (also LA)
d U Maryland College Park, MD k RIPE London (also 16 other locations)
g US DoD Vienna, VA
h ARL Aberdeen, MD i Autonomica, Stockholm (plus
j Verisign, ( 21 locations) 28 other locations)
e NASA Mt View, CA m WIDE Tokyo (also Seoul,
f Internet Software C. Palo Alto, Paris, SF)
CA (and 36 other locations)

13 root name
servers worldwide
b USC-ISI Marina del Rey, CA
l ICANN Los Angeles, CA

2: Application Layer 24
TLD and Authoritative Servers
 Top-level domain (TLD) servers:
 responsible for com, org, net, edu, etc, and all
top-level country domains uk, fr, ca, jp.
 Network Solutions maintains servers for com TLD
 Educause for edu TLD
 Authoritative DNS servers:
 organization’s DNS servers, providing
authoritative hostname to IP mappings for
organization’s servers (e.g., Web, mail).
 can be maintained by organization or service
provider

2: Application Layer 25
Local 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
 acts as proxy, forwards query into hierarchy

2: Application Layer 26
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

iterated query: local DNS server

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

gaia.cs.umass.edu

2: Application Layer 27
DNS name
resolution example root DNS server

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

1 8

authoritative DNS server

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

gaia.cs.umass.edu

2: Application Layer 28
DNS: caching and updating records
 once (any) name server learns mapping, it caches
mapping
 cache entries timeout (disappear) after some
time
 TLD servers typically cached in local name
servers
• Thus root name servers not often visited
 update/notify mechanisms under design by IETF
 RFC 2136
 http://www.ietf.org/html.charters/dnsind-charter.html

2: Application Layer 29
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
servereast.backup2.ibm.com
 name is domain (e.g.
 value is canonical name
foo.com)
 value is hostname of
 Type=MX
authoritative name
 value is name of mailserver
server for this domain
associated with name

2: Application Layer 30
DNS protocol, messages
DNS protocol : query and reply messages, both with
same message format

msg header
 identification: 16 bit #
for query, reply to query
uses same #
 flags:
 query or reply
 recursion desired
 recursion available
 reply is authoritative

2: Application Layer 31
DNS protocol, messages

Name, type fields

for a query

RRs in response
to query

records for
authoritative servers

additional “helpful”
info that may be used

2: Application Layer 32
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
 How do people get IP address of your Web site?

2: Application Layer 33