Chapter 2

Application Layer

Computer
Networking: A Top
Down Approach
7th edition
Jim Kurose, Keith Ross
The Powerpoint slides are from Kurose and Ross’s Pearson/Addison Wesley
book’s website. April 2016

Application Layer 1
 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
 Chapter 2: application layer
our goals: ▪ learn about protocols by
▪ conceptual, examining popular
implementation aspects application-level
of Internet application protocols
protocols • HTTP
• client-server • SMTP / POP3 / IMAP
paradigm • DNS
• transport-layer ▪ programming network
service models applications
• socket API

Application Layer 3
 Some Internet 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,
Netflix)

Application Layer 4
 Creating an Internet app application
transport
network
data link
physical
need to write programs that:
▪ run on (different) end systems
▪ communicate over network
▪ e.g., browser software
communicates with web server
software

no need to write software for

application
transport
network
network-core devices data link
physical
application
transport
network
▪ network-core devices do not data link
physical
run user applications
▪ writing applications on end
systems allows for rapid app
development

Application Layer 5
 Application architectures
possible application structures:
▪ client-server
▪ peer-to-peer (P2P)

Application Layer 6
 Client-server architecture
server:
▪ always-on host
▪ permanent IP address

clients:
▪ communicate with server
▪ may be intermittently
client/server connected
▪ may have dynamic IP
addresses
▪ do not communicate directly
with each other

Application Layer 7
 P2P architecture
▪ no permanent 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
• need complex management

Application Layer 8
 Inter-process communication

process: program running in clients, servers

a host client process: process that
▪ within same host, two initiates communication
processes can 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 architecture have both
client processes and server
processes

Application Layer 9
 Sockets
▪ process sends/receives messages to/from its socket
▪ socket analogous to door
• sending process pushes message out door
• sending process relies on transport service out of the
door to deliver message to door 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 10
 Addressing processes

▪ to receive messages, process ▪ identifier includes both IP

must have identifier address and port numbers
▪ host device has unique 32-bit associated with process on
IP address host
▪ IP address of a host cannot ▪ example port numbers:
identify a process which runs • HTTP server: 80
on the host • mail server: 25
• many processes can be running ▪ to send HTTP message to
on same host [Link] web
server:
• IP address: [Link]
• port number: 80

Application Layer 11
 What transport service does an app need?
data loss bandwidth
▪ some apps (e.g., file transfer, ▪ some apps (e.g., video)
stock transaction) require require minimum
100% reliable data transfer bandwidth to be usable
▪ some other apps (e.g., audio) ▪ some other apps (e.g., web)
can tolerate some loss make use of whatever
bandwidth they get
delay sensitive
▪ some apps (e.g., Internet
telephony, interactive
games) require low delay
to be usable
▪ some other apps (e.g., e-
mail) don’t care
Application Layer 12
 Transport service requirements: common apps

application data loss bandwidth delay 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 ms
video:10kbps-5Mbps
stored audio/video loss-tolerant same as above yes, few secs
interactive games loss-tolerant few kbps up yes, 100’s ms
text messaging no loss elastic yes and no

Application Layer 13
 Internet transport layer services
TCP service: UDP service:
▪ connection-oriented: setup is ▪ unreliable data transfer
required between client and between sending and
server processes receiving processes
▪ reliable data transfer between ▪ does not provide:
sending and receiving ▪ reliability,
processes ▪ flow control,
▪ flow control: sender won’t ▪ congestion control,
overwhelm receiver ▪ timing,
▪ congestion control: throttle ▪ bandwidth guarantee,
sender when network ▪ or connection setup
overloaded
▪ does not provide: timing, Q: why bother? Why is
minimum bandwidth there a UDP?
guarantee
Application Layer 14
 Internet apps: application / transport layer protocols

application Underlying transport

application layer protocol layer 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 15
 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 16
 Web and HTTP
First, some terms…
▪ 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 (Uniform
Resource Locator), e.g.,
[Link]/someDept/[Link]

host name path name

Application Layer 17
 HTTP overview
HTTP: hypertext
transfer protocol
▪ Web’s application layer
protocol
▪ client/server model PC running
Firefox browser
• client: browser that
requests / receives
(using HTTP protocol),
and displays Web server
objects running
• server: Web server Apache Web
sends objects (using server
HTTP protocol) in
response to client’s iPhone running
requests Safari browser
▪ two types of messages:
request, response
Application Layer 18
 HTTP overview
uses TCP: HTTP is “stateless”
▪ client initiates TCP ▪ server maintains no
connection (creates socket) information about
to server, port 80 past client requests
▪ server accepts TCP
connection from client aside
▪ HTTP messages protocols that maintain
(application-layer protocol “state” are complex!
messages) exchanged ▪ past history (state) must be
between browser (HTTP maintained
client) and Web server ▪ if server/client crashes, their
(HTTP server) views of “state” may be
▪ TCP connection closed inconsistent, must be
reconciled

Application Layer 19
 HTTP connections

non-persistent HTTP persistent HTTP

▪ at most one object ▪ multiple objects can
sent over TCP be sent over single
connection TCP connection
• TCP connection between client and
then closed server
▪ downloading multiple
objects requires
multiple connections

Application Layer 20
 Non-persistent HTTP
suppose user enters URL: (contains text,
[Link]/someDepartment/[Link] references to 10
jpeg images)
1a. HTTP client initiates TCP
connection to HTTP server
(process) at 1b. HTTP server at host
[Link] on port 80 [Link] waiting
for TCP connection at port 80.
“accepts” connection, notifies
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/[Link] object, and sends message into
its socket
time

Application Layer 21
 Non-persistent HTTP (cont’d)

4. HTTP server closes TCP

connection.
5. HTTP client receives response
message containing html file,
displays html; further parses html
file, finds 10 referenced jpeg
objects
time
6. Steps 1-5 repeated for each of
10 jpeg objects

Application Layer 22
 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 request time to
RTT
and first few bytes of HTTP transmit
file
response to return file
▪ file transmission time received

time time

non-persistent HTTP response time = 2RTT+ file transmission time

Application Layer 23
 Persistent HTTP
non-persistent HTTP issues: persistent HTTP:
▪ requires 2 RTTs per object ▪ server leaves connection
▪ overhead for each TCP open after sending
connection response
▪ browsers often open ▪ subsequent HTTP
parallel TCP connections to messages between same
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 Layer 24
 HTTP request message
▪ HTTP request message:
• ASCII (human-readable 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 Layer 25
 HTTP request message (example)
carriage return character
line-feed character
request line
(GET, POST, GET /[Link] HTTP/1.1\r\n
HEAD commands) Host: [Link]\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
carriage return, Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
line feed at start Keep-Alive: 115\r\n
Connection: keep-alive\r\n
of line indicates \r\n
end of header lines

Application Layer 26
 Uploading form input
POST method:
▪ web page can include form input
▪ input is uploaded to server in entity body

URL method:
▪ uses GET method
▪ input is uploaded in URL field of request line:
[Link]/animalsearch?monkeys&banana

Application Layer 27
 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 Layer 28
 HTTP response message
status line
(protocol
status code HTTP/1.1 200 OK\r\n
status phrase) Date: Sun, 26 Sep 2010 [Link] GMT\r\n
Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 [Link]
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 29
 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:)
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 30
 User-server state: cookies
many Web sites use cookies
four components: example:
1) cookie header line of ▪ Susan always access Internet
HTTP response from PC
message ▪ visits specific e-commerce
2) cookie header line in site for first time
next HTTP request ▪ when initial HTTP request
message arrives at site, site creates:
3) cookie file kept on • unique ID
user’s host, managed • entry in back-end
by user’s browser database for ID
4) back-end database at
Web site

Application Layer 31
 Cookies: keeping “state”
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 Layer 32
 Cookies
what cookies can be used for: aside
▪ authorization cookies and privacy:
▪ shopping carts ▪ cookies permit sites to
▪ recommendations learn a lot about you
▪ user session state (Web e-mail) ▪ you may supply name and
e-mail to sites

how to keep “state”:

▪ protocol endpoint entities: maintain state at
sender/receiver over multiple transactions
▪ cookies: http messages carry state

Application Layer 33
 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 found in cache: client
origin
cache returns object server
• else (object not found
in cache): cache
requests object from
origin server, then
returns object to client client origin
server

Application Layer 34
 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 does P2P file
sharing)

Application Layer 35
 Caching example:
assumptions: origin
▪ avg object size: 1M bits servers
public
▪ avg request rate from browsers to origin Internet
servers:15/sec
▪ avg data rate to browsers: 15 Mbps
▪ RTT from institutional router to any origin
server: 2 sec 15 Mbps
▪ access link rate: 15 Mbps access link
institutional
consequences: network
▪ LAN utilization: 15% problem! 100Mbps LAN

▪ access link utilization = 100%

▪ total delay
= Internet delay + access delay + LAN delay
= 2 sec + minutes + msecs

Application Layer 36
 Caching example: wider access link
assumptions:
▪ avg object size: 1M bits origin
▪ avg request rate from browsers to servers
origin servers:15/sec public
▪ avg data rate to browsers: 15 Mbps Internet
▪ RTT from institutional router to any
origin server: 2 sec
▪ access link rate: 15 Mbps
150 Mbps 15 Mbps
150 Mbps
consequences: access link

▪ LAN utilization: 15% institutional

▪ access link utilization = 100% 10% network
100 Mbps LAN
▪ total delay = Internet delay + access
delay + LAN delay
= 2 sec + minutes + msecs
msecs

Cost: increased access link speed (not cheap!)

Application Layer 37
 Caching example: install local cache
assumptions:
▪ avg object size: 1M bits origin
▪ avg request rate from browsers to servers
origin servers:15/sec public
▪ avg data rate to browsers: 15 Mbps Internet
▪ RTT from institutional router to any
origin server: 2 sec
▪ access link rate: 15 Mbps 15 Mbps
consequences: access link

▪ LAN utilization: 15% institutional

▪ access link utilization = 100% network
? 100Mbps 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 Layer 38
 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
60% requests satisfied at origin Internet

▪ access link utilization:

▪ 60% of requests use access link
▪ data rate to browsers over access link 15 Mbps
access link
= 0.6*15 Mbps = 9 Mbps
institutional
▪ utilization = 9/15 = 60%
network
100Mbps LAN
▪ total delay
▪ = 0.6 * (delay from origin servers) +0.4 local web
* (delay when satisfied at cache) cache
▪ = 0.6 (2.01) + 0.4 (~msecs) = ~ 1.2 secs
▪ less than with 150 Mbps access link (and
cheaper too!)
Application Layer 39
 Conditional GET
client server
▪ Goal: don’t send object if
cache has up-to-date
cached version HTTP request msg
object
If-modified-since: <date>
• no object transmission not
delay modified
• lower down link usage HTTP response
after
HTTP/1.0
▪ cache: specify date of 304 Not Modified <date>
cached copy in HTTP
request
If-modified-since:
<date> HTTP request msg
▪ server: response contains If-modified-since: <date> object
modified
no object if cached copy after
HTTP response
is up-to-date: HTTP/1.0 200 OK <date>
HTTP/1.0 304 Not <data>
Modified
Application Layer 40
 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 41
 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
server
mail messages user
▪ e.g., Outlook, Thunderbird, agent
iPhone mail client user
agent
▪ outgoing, incoming
messages stored on server
Application Layer 42
 Electronic mail: mail servers
mail servers: user
agent
▪ mailbox contains incoming
messages for user mail user
server
▪ message queue of outgoing agent

(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
• “server”: receiving mail user
agent
server
user
agent

Application Layer 43
 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 ASCII
Application Layer 44
 Scenario: Alice sends message to Bob
1) Alice uses UA to compose 4) SMTP client sends Alice’s
message “to” message over the TCP
bob@[Link] connection
2) Alice’s UA sends message 5) Bob’s mail server places the
to her mail server; message message in Bob’s mailbox
placed in message queue 6) Bob invokes his user agent
3) client side of SMTP opens to 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 45
 Sample SMTP interaction
S: 220 [Link]
C: HELO [Link]
S: 250 Hello [Link], pleased to meet you
C: MAIL FROM: <alice@[Link]>
S: 250 alice@[Link]... Sender ok
C: RCPT TO: <bob@[Link]>
S: 250 bob@[Link] ... 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 [Link] closing connection

Application Layer 46
 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
[Link] to interaction, status codes
determine end of message
▪ HTTP: each object
encapsulated in its own
response message
▪ SMTP: multiple objects
sent in multipart message

Application Layer 47
 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 48
 Mail access protocols
user
mail access user
SMTP SMTP protocol
agent agent
(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 49
 POP3 protocol
S: +OK POP3 server ready
C: user bob
authorization phase S:
C:
+OK
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 2 contents>
▪ dele: delete S: .
▪ quit C: dele 2
C: quit
S: +OK POP3 server signing off

Application Layer 50
 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 51
 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 52
 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
[Link] - 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 Layer 53
 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 54
 DNS: a distributed, hierarchical database
Root DNS Servers

… …

com DNS servers org DNS servers edu DNS servers

[Link] [Link] [Link]

[Link] [Link]
DNS servers DNS serversDNS servers
DNS servers DNS servers

client wants IP for [Link]; 1st approximation:

▪ client queries root server to find com DNS server
▪ client queries .com DNS server to get [Link] DNS server
▪ client queries [Link] DNS server to get IP address for
[Link]

Application Layer 55
 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 56
 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 57
 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 58
 DNS name root DNS server
resolution example
2
▪ host at [Link] 3
TLD DNS server
wants IP address for 4
[Link]
5

iterated query: local DNS server

[Link]
▪ contacted server 7 6
1 8
replies with name of
server to contact
authoritative DNS server
▪ “I don’t know this [Link]
name, but ask this requesting host
server” [Link]

[Link]

Application Layer 59
 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 [Link] 5 4

▪ heavy load at upper 1 8

levels of hierarchy?
authoritative DNS server
[Link]
requesting host
[Link]

[Link]

Application Layer 60
 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 61
 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 ▪ [Link] is really
• name is domain (e.g., [Link]
[Link]) ▪ 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 62
 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 63
 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 64
 Inserting records into DNS
▪ example: new startup “Network Utopia”
▪ register name [Link] 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:
([Link], [Link], NS)
([Link], [Link], A)

Application Layer 65
 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 66
 Socket programming
goal: learn how to build client/server applications that
communicate using sockets
Socket API socket
▪ introduced in BSD4.1 UNIX,
1981 a host-local,
▪ explicitly created, used, released application-created,
by apps OS-controlled interface
▪ client/server paradigm into which
▪ two types of transport service application process can
via socket API: both send and
• unreliable datagram receive messages to/from
• reliable, byte stream- another application
oriented process

Application Layer 67
 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 68
 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 69
 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 Layer 70
 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 = input(’Input lowercase sentence:’)
Attach server name, port to [Link]([Link](),
message; send into socket
(serverName, serverPort))
read reply characters from modifiedMessage, serverAddress =
socket into string
[Link](2048)
print out received string print ([Link]())
and close socket
[Link]()
Application Layer 71
 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
[Link](('', serverPort))
print (‘The server is ready to receive’)
loop forever while True:
Read from UDP socket into message, clientAddress = [Link](2048)
message, getting client’s
address (client IP and port) modifiedMessage = [Link]().upper()
send upper case string [Link]([Link](),
back to this client
clientAddress)

Application Layer 72
 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 73
 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()
[Link]()

send request using

read request from clientSocket
connectionSocket

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

Application Layer 74
 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)
[Link]((serverName,serverPort))
sentence = input(‘Input lowercase sentence:’)
No need to attach server [Link]([Link]())
name, port
modifiedSentence = [Link](1024)
print (‘From Server:’, [Link]())
[Link]()

Application Layer 75
 Example app: TCP server
Python TCPServer
from socket import *
create TCP welcoming serverPort = 12000
socket serverSocket = socket(AF_INET,SOCK_STREAM)
[Link]((‘’,serverPort))
server begins listening for
incoming TCP requests [Link](1)
print (‘The server is ready to receive’)
loop forever
while True:
server waits on accept()
for incoming requests, new
connectionSocket, addr = [Link]()
socket created on return

sentence = [Link](1024).decode()
read bytes from socket (but
not address as in UDP) capitalizedSentence = [Link]()
close connection to this [Link](capitalizedSentence.
client (but not welcoming
socket) encode())
[Link]()
Application Layer 76
 Chapter 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 ▪ socket programming:
▪ Internet transport service TCP, UDP sockets
model
• connection-oriented,
reliable: TCP
• unreliable, datagrams: UDP

Application Layer 77
 Chapter 2: summary
most importantly: learned about protocols!
▪ typical request/reply
message exchange: important themes:
• client requests info or ▪ control vs. data messages
service ▪ stateless vs. stateful
• server responds with ▪ reliable vs. unreliable message
data, status code
transfer
▪ message formats:
• headers: fields giving ▪ “complexity at network
info about data edge”
• data: info(payload)
being communicated

Application Layer 78