Chapter 2:

Networking
Applications areas

Application Layer 2-1

Chapter 2: outline
2.1 principles of 2.6 P2P applications
network
applications
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
 SMTP, POP3,
IMAP
2.5 DNS

Application Layer 2-2

Chapter 2: application
areas
our goals:  learn about protocols by
 conceptual, examining popular
implementation application-level
aspects of network protocols
application  HTTP
protocols  FTP
 transport-layer  SMTP / POP3 / IMAP
service models  DNS
 client-server
paradigm
 peer-to-peer
paradigm

Application Layer 2-3

Network apps
 Are the driving
force behind the
Internet

 Without useful
networking
applications, there
would be no need
for networks !

 Since the Internet’s

inception, a huge
number of useful
applications have
been developed
Application Layer 2-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
transport
network
no need to write software data link
physical
application
transport
for network-core network
data link
devices physical

 network-core devices
do not run user
applications
 applications on end
systems allows for Application Layer 2-5
Application architectures
possible structure of applications:
 client-server
 peer-to-peer (P2P)

Application Layer 2-6

 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 Layer 2-7
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
Application Layer 2-8
IP addresses
Processes communicating
process: program clients, servers
running within a client process:
host process that initiates
 within same host, two communication
processes server process:
communicate using process that waits to
inter-process be contacted
communication
(defined by OS)  aside: applications
 processes in different with P2P architectures
hosts communicate have client processes
by exchanging & server processes
messages

Application Layer 2-9

Sockets
 process sends/receives messages to/from its
socket
 socket analogous to door
 sending process shoves message out door
 sending process relies on transport
infrastructure on other side of door to deliver
message to socket 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 2-10

Addressing processes
 to receive messages,  identifier includes both
process must have IP address and port
identifier numbers associated
 host device has with process on host.
unique 32-bit IP  example port numbers:
address  HTTP server: 80
 Q: does IP address of  mail server: 25
host on which process  to send HTTP message
runs
 A:suffice for
no, many to gaia.cs.umass.edu
identifying
processesthecan be web server:
process?
running on same  IP address:
host 128.119.245.12
 port number: 80
 Check
http://www.iana.org for
well known port
numbers Application Layer 2-11
App-layer protocol defines
 types of messages open protocols:
exchanged,  defined in RFCs
 e.g., request,  allows for
response interoperability
 message syntax:  e.g., HTTP, SMTP
 what fields in proprietary protocols:
messages & how  e.g., Skype
fields are
delineated
 message semantics
 meaning of
information in
fields
 rules for when and
how processes send &
respond to messages Application Layer 2-12
What transport service does an
app need?
data integrity throughput
 some apps (e.g., file  some apps (e.g.,
transfer, web multimedia) require
transactions) require minimum amount of
100% reliable data throughput to be
transfer “effective”
 other apps (e.g., audio)  other apps (“elastic

can tolerate some loss apps”) make use of

timing
whatever throughput
 some apps (e.g.,
they get
Internet telephony, security
interactive games)
 encryption, data
require low delay to
be “effective” integrity,
authentication, …
Application Layer 2-13
 Transport service requirements:
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
text messaging no loss elastic yes and no

Application Layer 2-14

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

Application Layer 2-16

Securing TCP

TCP & UDP

 no encryption
 cleartext passwds
sent into socket
traverse Internet
in cleartext
SSL
 provides
encrypted TCP
connection
 data integrity
 end-point
authentication Application Layer 2-17
Chapter 2: outline
2.1 principles of 2.6 P2P applications
network
applications
 app architectures
 app requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
 SMTP, POP3,
IMAP
2.5 DNS

Application Layer 2-18

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,
www.someschool.edu/someDept/pic.gif
e.g.,
host name path name

Application Layer 2-19

HTTP overview
HTTP: hypertext
transfer protocol HT
 Web’s application TP
req
layer protocol PC running HT
ues
t
Firefox browser TPr
 client/server model esp
ons
 client: browser e
that requests, t
receives, (using u es
req server
HTTP protocol) T P nse
HT po running
and “displays” P res
Apache Web
Web objects HT
T
server
 server: Web
server sends iphone running
(using HTTP Safari browser
protocol) objects
in response to
requests
Application Layer 2-20
HTTP overview (continued)
uses TCP: HTTP is
 client initiates TCP “stateless”
connection (creates  server maintains
socket) to server, no information
port 80 about past client
requests
 server accepts TCP aside
connection from client protocols that maintain
 HTTP messages “state” are complex!
(application-layer
 past history (state) must
be maintained
protocol messages)  if server/client crashes,
exchanged between their views of “state”
browser (HTTP client) may be inconsistent,
and Web server (HTTP must be reconciled
server)
 TCP connection closed
Application Layer 2-21
HTTP connections
non-persistent HTTP persistent HTTP
 at most one object sent
 multiple
over TCP
objects
connection can be sent over
single TCP
 connection then closed
connection
 downloading multiple objects required
multiple connections between client,
server

Application Layer 2-22

 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 www.someSchool.edu
port 80 waiting for TCP
connection at port 80.
2. HTTP client sends HTTP “accepts” connection,
request message notifying client
(containing URL) into TCP 3. HTTP server receives
connection socket. request message, forms
Message indicates that response message
client wants object containing requested
someDepartment/home.i object, and sends
time ndex message into its socket
Application Layer 2-23
 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 Layer 2-24

Non-persistent HTTP: response
time
RTT (definition): 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
time to
RTT
request and first few transmit
file
bytes of HTTP file
response to return received
 file transmission time
 non-persistent HTTP time time
response time =

2RTT+ file Application Layer 2-25

Persistent HTTP

non-persistent HTTP persistent HTTP:

issues:  server leaves
 requires 2 RTTs per connection open
object after sending
 OS overhead for each response
TCP connection  subsequent HTTP
 browsers often open messages between
parallel TCP same client/server
connections to fetch sent over open
referenced objects connection
 client sends requests
as soon as it
encounters a
referenced object
 as little as one RTT
for all the referenced
Application Layer 2-26
 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
headerAccept-Language: en-us,en;q=0.5\r\n
linesAccept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
carriage return, Keep-Alive: 115\r\n
line feed at start Connection: keep-alive\r\n
\r\n
of line indicates
end of header lines
Application Layer 2-27
 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 Layer 2-28
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 2-29

 Trying out HTTP (client side) for
yourself
1. Telnet to your favorite Web server:

telnet www.google.ae 80 opens TCP connection to port 80

(default HTTP server port) at google.ae
anything typed in sent
to port 80 at cis.poly.edu

2. type in a GET HTTP request:

GET http://www.amazon.com HTTP/1.1 by typing this in (hit carriage
Host: amazon.com return twice), you send
this minimal (but complete)
GET request to HTTP server

3. look at response message sent by HTTP server!

use Wireshark to look at captured HTTP request/response)
Application Layer 2-30
Web caches (proxy server)
goal: satisfy client request without involving
origin
 user server
sets browser:
Web accesses via
cache
proxy
 browser sends all HT
TP
req server u est
req
HTTP requests to HT
client TP
ues
t H TTP
o nse
res p origin
cache pon P res
se T server
HT
 object in cache: ues
t
cache returns req e
TT P o ns
p
object H res
T TP
 else cache H

requests object client origin

from origin server, server
then returns
object to client
Application Layer 2-31
More about Web caching
 cache acts as why Web caching?
both client and  reduce response
server time for client
 server for original
requesting client
request
 client to origin server  reduce traffic on an
 typically cache is institution’s access
installed by ISP link
(university,  Internet dense with
company, caches: enables
residential ISP) “poor” content
providers to
effectively deliver
content (so too
Application Layer 2-32
Conditional GET
client server
 Goal: don’t send
object if cache has
up-to-date cached HTTP request msg
object
If-modified-since: <date>
version not
 no object modified
transmission delay HTTP response
before
HTTP/1.0
 lower link utilization <date>
304 Not Modified
 cache: specify date
of cached copy in
HTTP request
If-modified-since: HTTP request msg
<date> If-modified-since: <date> object
 server: response modified
after
contains no object if HTTP response
HTTP/1.0 200 OK <date>
cached copy is up-
<data>
to-date:
HTTP/1.0 304 Not Application Layer 2-33
Chapter 2: outline
2.1 principles of 2.6 P2P applications
network
applications
 app architectures
 app requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
 SMTP, POP3,
IMAP
2.5 DNS

Application Layer 2-34

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 Layer 2-35
FTP: separate control, data
connections
TCP control connection,
 FTP client contacts FTP server port 21
server at port 21, using
TCP
TCP data connection,
 client authorized over FTP server port 20 FTP
control connection client server
 client browses remote
directory, sends  server opens another
commands over control TCP data connection to
connection transfer another file
 when server receives  control connection:
file transfer command, “out of band”
server opens 2nd TCP  FTP server maintains
data connection (for file) “state”: current
to client directory, earlier
 after transferring one authentication
file, server closes data Application Layer 2-36
Chapter 2: outline
2.1 principles of 2.6 P2P applications
network
applications
 app architectures
 app requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
 SMTP, POP3,
IMAP
2.5 DNS

Application Layer 2-37

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

mail server
Application Layer 2-39
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, FTP)
 commands: ASCII text
 response: status code and phrase
 messages must be in 7-bit ASCI
Application Layer 2-40
Scenario: Alice sends message
to Bob
1) Alice uses UA to 4) SMTP client sends
compose message “to” Alice’s message over
[email protected] the TCP connection
2) Alice’s UA sends 5) Bob’s mail server
message to her mail places the message in
server; message Bob’s mailbox
placed in message 6) Bob invokes his user
queue agent to read message
3) client side of SMTP
opens 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-41
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-42

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

SMTP: final words
 SMTP uses persistent comparison with
connections HTTP:
 SMTP requires  HTTP: pull
message (header &
body) to be in 7-bit
 SMTP: push
ASCII  both have ASCII
 SMTP server uses command/response
CRLF.CRLF to interaction, status
determine end of codes
message
 HTTP: each object
encapsulated in its
own response msg
 SMTP: multiple
objects sent in
multipart msgApplication Layer 2-44
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 msgs on server
 HTTP: gmail, Hotmail, Yahoo! Mail, etc.

Application Layer 2-45

POP3 (more) and IMAP
more about POP3 IMAP
 previous example  keeps all messages
uses POP3 in one place: at
“download and server
delete” mode  allows user to
 Bob cannot re- organize messages
read e-mail if he in folders
changes client  keeps user state
 POP3 “download- across sessions:
and-keep”: copies of  names of folders
messages on and mappings
different clients between message
 POP3 is stateless IDs and folder
across sessions name

Application Layer 2-46

Chapter 2: outline
2.1 principles of 2.6 P2P applications
network
applications
 app architectures
 app requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
 SMTP, POP3,
IMAP
2.5 DNS

Application Layer 2-47

DNS: domain name system
people: many Domain Name System:
identifiers:  distributed database
 SSN, name, implemented in
passport # hierarchy of many name
Internet hosts, routers: servers
 IP address (32 bit)  application-layer
- used for protocol: hosts, name
addressing servers communicate to
datagrams resolve names
 “name”, e.g., (address/name
www.yahoo.com - translation)
used by humans  note: core Internet
Q: how to map function, implemented
between IP address as application-layer
and name, and vice protocol
versa ?  complexity atApplication Layer 2-48
DNS: services, structure
DNS services why not centralize
 hostname to IP DNS?
address translation  single point of failure
 host aliasing  traffic volume
 canonical, alias  distant centralized
names database
 mail server aliasing maintenance

A: doesn’t scale!
 load distribution
 replicated Web
servers: many IP
addresses
correspond to one
name

Application Layer 2-49

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

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-51
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-52

DNS name
resolution root DNS server

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

Application Layer 2-53

DNS name
resolution root DNS server

example 2 3
7
recursive query: 6
 puts burden of TLD DNS
server
name resolution
on contacted local DNS server
name server dns.poly.edu 5 4
 heavy load at 1 8
upper levels of
authoritative DNS server
hierarchy? dns.cs.umass.edu
requesting host
cis.poly.edu

gaia.cs.umass.edu

Application Layer 2-54

Chapter 2: outline
2.1 principles of 2.6 P2P applications
network
applications
 app architectures
 app requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
 SMTP, POP3,
IMAP
2.5 DNS

Application Layer 2-55

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

 P2P file distribution:
BitTorrent
 file divided into 256Kb chunks
 peers in torrent send/receive file chunks

tracker: tracks peers torrent: group of

participating in torrent peers exchanging
chunks of a file

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

Application Layer 2-57

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 Layer 2-58
BitTorrent: requesting, sending file
chunks
requesting chunks: sending chunks: tit-for-
 at any given time, tat
different peers have  Alice sends chunks to
different subsets of those four peers currently
file chunks sending her chunks at
 periodically, Alice highest rate
asks each peer for list  other peers are choked by
of chunks that they Alice (do not receive
have chunks from her)
 re-evaluate top 4 every10
 Alice requests missing
secs
chunks from peers,
rarest first
 every 30 secs: randomly
select another peer,
starts sending chunks
 “optimistically unchoke”
this peer
Application Layer 2-59
 newly chosen peer may join