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

no need to write software for transport

network
network-core devices data link
physical
application
transport
network
 network-core devices do data link

not run user applications physical

 applications on end
systems allows for rapid
app development,
propagation
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
 may be intermittently
client/server 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
IP addresses
 complex
management Application Layer 2-8
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
 mail server: 25
 Q: does IP address of
host on which process  to send HTTP message
 A: no,
runs suffice
manyfor
processes to gaia.cs.umass.edu
can be running
identifying the on web server:
same host  IP address:
process?
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
messages & how proprietary protocols:
fields are delineated  e.g., Skype
 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 integrity,
require low delay to authentication, …
be “effective”

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 receiving
 flow control: sender process
won’t overwhelm
receiver
 does not provide:
 congestion control: reliability, flow
throttle sender when control, congestion
network overloaded control, timing,
 does not provide: timing, throughput
minimum throughput guarantee, security,
guarantee, security orconnection setup,
 connection-oriented:
setup required between Q: why bother? Why is
client and server
processes there a UDP?
Application Layer 2-15
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
T
 client/server model Firefox browser Pr
esp
ons
 client: browser that e
requests, receives,
(using HTTP t
u es
protocol) and req server
T P n se
“displays” Web HT s po running
re Apache Web
objects T TP
H server
 server: Web server
sends (using HTTP
protocol) objects in iphone running
response to Safari browser
requests

Application Layer 2-20

HTTP overview (continued)
uses TCP: HTTP is “stateless”
 client initiates TCP  server maintains no
connection (creates information about
past client requests
socket) to server, port
80
 server accepts TCP aside
connection from client protocols that maintain
 HTTP messages “state” are complex!
(application-layer  past history (state) must
protocol messages) be maintained
exchanged between  if server/client crashes,
browser (HTTP client) their views of “state”
and Web server (HTTP may be inconsistent,
server) must be reconciled
 TCP connection closed
Application Layer 2-21
HTTP connections
non-persistent HTTP persistent HTTP
 at most one  multiple objects
object sent over can be sent over
TCP connection single TCP
 connection then connection
closed between client,
 downloading server
multiple objects
required multiple
connections

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. “accepts”
2. HTTP client sends HTTP request message
connection, notifying client
(containing URL) into TCP connection
socket. Message indicates that client
wants object 3. HTTP server receives
someDepartment/home.index
request message, forms
response message
containing requested
object, and sends
time 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
HTTP response time: initiate TCP
connection
 one RTT to initiate TCP
RTT
connection
 one RTT for HTTP request
request
file
and first few bytes of time to
RTT
HTTP response to return transmit
file
 file transmission time
file
 non-persistent HTTP received
response time =
2RTT+ file transmission time time
time

Application Layer 2-25

Persistent HTTP

non-persistent HTTP persistent HTTP:

issues:  server leaves
 requires 2 RTTs per connection open after
sending response
object  subsequent HTTP
 OS overhead for each messages between
TCP connection same client/server sent
 browsers often open over open connection
parallel TCP  client sends requests
connections to fetch as soon as it
referenced objects encounters a
referenced object
 as little as one RTT for
all the referenced
objects

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 server

 user sets browser: Web

accesses via cache
 browser sends all HTTP
requests to cache HT proxy
TP u est
 object in cache: req server req
HT ues P se
client TP t H TT o n
cache returns object res
pon res
p origin
T P server
 else cache requests se
t
HT
es
object from origin req
u
e
server, then returns TT P o ns
p
H res
object to client T TP
H

client origin
server

Application Layer 2-31

More about Web caching
 cache acts as why Web caching?
both client and  reduce response time
server for client request
 server for original  reduce traffic on an
requesting client
 client to origin server institution’s access
link
 typically cache is  Internet dense with
installed by ISP caches: enables
(university, “poor” content
company, providers to
residential ISP) effectively deliver
content (so too does
P2P file sharing)
Application Layer 2-32
Conditional GET
client server
 Goal: don’t send
object if cache has up-
to-date cached HTTP request msg
object
version If-modified-since: <date>
not
 no object transmission
modified
delay HTTP response
 lower link utilization before
HTTP/1.0
304 Not Modified <date>
 cache: specify date of
cached copy in HTTP
request
If-modified-since:
<date> HTTP request msg
If-modified-since: <date> object
 server: response modified
contains no object if after
HTTP response
cached copy is up-to- HTTP/1.0 200 OK <date>
date: <data>
HTTP/1.0 304 Not
Modified 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
 FTP client contacts FTP TCP control connection,
server port 21
server at port 21, using
TCP
 client authorized over TCP data connection,
FTP server port 20 FTP
control connection client server
 client browses remote
directory, sends  server opens another
commands over control
connection TCP data connection
to transfer another file
 when server receives file
transfer command, server  control connection:
opens 2nd TCP data “out of band”
connection (for file) to  FTP server maintains
client “state”: current
 after transferring one file, directory, earlier
server closes data authentication
connection 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
components: agent
 user agents mail user
 mail servers server agent
 simple mail transfer
protocol: SMTP SMTP mail user
server agent
User Agent SMTP
 a.k.a. “mail reader” user
 composing, editing, SMTP agent
mail
reading mail messages
server
 e.g., Outlook, Thunderbird, user
iPhone mail client agent
 outgoing, incoming user
messages stored on server agent

Application Layer 2-38

Electronic mail: mail servers
mail servers: user
agent
 mailbox contains
incoming messages for mail user
user server agent
 message queue of SMTP mail user
outgoing (to be sent) server agent
mail messages
SMTP
 SMTP protocol between
mail servers to send SMTP user
email messages mail
agent
 client: sending mail server
user
server agent
 “server”: receiving user
mail server agent

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
bob@someschool.edu the TCP connection
2) Alice’s UA sends 5) Bob’s mail server
message to her mail places the message in
server; message placed Bob’s mailbox
in message queue 6) Bob invokes his user
3) client side of SMTP agent to read message
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: <alice@crepes.fr>
S: 250 alice@crepes.fr... Sender ok
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburger.edu ... 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 &  SMTP: push
body) to be in 7-bit
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 msg
Application 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 identifiers: Domain Name System:
 SSN, name,  distributed database
passport # implemented in hierarchy
Internet hosts, routers: of many name servers
 IP address (32 bit) -  application-layer protocol:
used for addressing hosts, name servers
datagrams communicate to resolve
 “name”, e.g., names (address/name
www.yahoo.com - translation)
used by humans  note: core Internet
function, implemented as
Q: how to map between application-layer protocol
IP address and name,  complexity at network’s
and vice versa ?
“edge”

Application Layer 2-48

DNS: services, structure
DNS services why not centralize DNS?
 hostname to IP
 single point of failure
address translation  traffic volume
 host aliasing  distant centralized
 canonical, alias database
names  maintenance
 mail server aliasing 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
replies with name 1 8
of 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

Application Layer 2-53

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

authoritative DNS server

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

Application Layer 2-59