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.
They obviously represent a lot of work on our part. In return for use, we only
ask the following: Computer
 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, Global Edition
Thanks and enjoy! JFK/KWR Jim Kurose, Keith Ross
Pearson
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

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

Application Layer 2-4

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)
• commands: ASCII text
• response: status code and phrase
 messages must be in 7-bit ASCI

Application Layer 2-5

Scenario: Alice sends message to Bob
1) Alice uses UA to compose 4) SMTP client sends Alice’s
message “ to” message over the TCP
[email protected] connection
2) Alice’s UA sends message to 5) Bob’s mail server places the
her mail server; message message in Bob’s mailbox
placed in message queue 6) Bob invokes his user agent to
3) client side of SMTP opens read message
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-6
Sample SMTP interaction
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <[email protected]>
S: 250 [email protected]... Sender ok
C: RCPT TO: <[email protected]>
S: 250 [email protected] ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection

Application Layer 2-7

Try SMTP interaction for yourself:
 telnet servername 25
 see 220 reply from server
 enter HELO, MAIL FROM, RCPT TO, DATA, QUIT
commands

above lets you send email without using email client (reader)

Application Layer 2-8

SMTP: final words
 SMTP uses persistent comparison with HTTP:
connections
 HTTP: pull
 SMTP requires message
(header & body) to be in  SMTP: push
7-bit ASCII  both have ASCII
 SMTP server uses command/response
CRLF.CRLF to determine interaction, status codes
end of message
 HTTP: each object
encapsulated in its own
response message
 SMTP: multiple objects
sent in multipart message

Application Layer 2-9

Mail message format
SMTP: protocol for
exchanging email messages header
blank
RFC 822: standard for text line
message format:
 header lines, e.g.,
• To: body
• From:
• Subject:
different from SMTP MAIL
FROM, RCPT TO:
commands!
 Body: the “ message”
• ASCII characters only

Application Layer 2-10

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 messages on server
• HTTP: gmail, Hotmail, Yahoo! Mail, etc.

Application Layer 2-11

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

Application Layer 2-13

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

Application Layer 2-14

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:
datagrams hosts, name servers
• “ name” , e.g., communicate to resolve
www.yahoo.com - names (address/name
used by humans translation)
• 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-15
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-16

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

 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)

m. WIDE Tokyo
e. NASA Mt View, CA (5 other sites)
f. Internet Software C.
Palo Alto, CA (and 48 other sites)

13 logical root name “servers”

a. Verisign, Los Angeles CA
(5 other sites)
worldwide
b. USC-ISI Marina del Rey, CA •each “server” replicated many times
l. ICANN Los Angeles, CA
(41 other sites)
g. US DoD Columbus,
OH (5 other sites)

Application Layer 2-18

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

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

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 replies 7 6
1 8
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-21

DNS name root DNS server
resolution example
2 3
recursive query: 7
6
 puts burden of name TLD DNS
resolution on contacted server
name server
local DNS server
 heavy load at upper dns.poly.edu 5 4
levels of hierarchy?
1 8

authoritative DNS server

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

gaia.cs.umass.edu

Application Layer 2-22

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

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
 www.ibm.com is really
type=NS
• 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-24

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

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

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
• potentially more
spoofed source
dangerous address: target IP
 requires amplification
Application Layer 2-28
Chapter 2: outline
2.1 principles of network 2.7 socket programming
applications with UDP and TCP
2.2 Web and HTTP
2.3 electronic mail
• SMTP, POP3, IMAP
2.4 DNS

Application Layer 2-29

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

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

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-33
 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
message; send into socket
clientSocket.sendto(message.encode(),
(serverName, serverPort))
read reply characters from
modifiedMessage, serverAddress =
socket into string
clientSocket.recvfrom(2048)
print out received string
and close socket
print modifiedMessage.decode()
clientSocket.close()
Application Layer 2-34
 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, getting client’s
message, clientAddress = serverSocket.recvfrom(2048)
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-35

Socket programming with TCP
client must contact server  when contacted by client,
 server process must first be server TCP creates new
running socket for server process to
 server must have created communicate with that
socket (door) that welcomes particular client
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-36

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

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

Application Layer 2-38

 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

read bytes from socket (but

sentence = connectionSocket.recv(1024).decode()
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-39
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 model  socket programming:
• connection-oriented, TCP, UDP sockets
reliable: TCP
• unreliable, datagrams: UDP

Application Layer 2-40

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 edge”
being communicated

Application Layer 2-41