Application Layer PDF

Chapter 2
Application Layer
Application Layer 2-1

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/
Chapter 2: outline
2.1 principles of network 2.6 P2P applications
applications 2.7 socket programming
2.2 Web and HTTP with UDP and TCP
2.3 FTP
2.4 electronic mail
▪ SMTP, POP3, IMAP
2.5 DNS
http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-2

Chapter 2: application layer
our goals: ❖ learn about protocols by
❖ conceptual, examining popular
implementation aspects application-level
of network applications protocols
▪ Define key ▪ HTTP
application layer ▪ FTP
concepts ▪ SMTP / POP3 / IMAP
▪ transport-layer ▪ DNS
service models ❖ creating network
▪ client-server applications
paradigm ▪ socket API
▪ peer-to-peer
paradigm

Chapter 2: Application Layer
Network applications:
❖ If we could not conceive of any useful applications, there
would not be any need to design networking protocols to
support them
❖ Applications
▪ Classic text based applications
▪ Multimedia applications

Some network apps
❖ e-mail ❖ voice over IP (e.g., Skype)
❖ web ❖ real-time video
❖ File transfer conferencing
❖ DNS ❖ social networking
❖ text messaging ❖ search
❖ remote login ❖ …
❖ P2P file sharing ❖ …
❖ multi-user network games
❖ streaming stored video
(YouTube, Hulu, Netflix)

Creating a network app application
transport
network
data link
physical
write programs that:
❖ run on (different) end systems
❖ communicate over network
❖ e.g., Web Application - web
server program/software
communicates with browser
program/software
application
no need to write software for transport
network
network-core devices data link
physical
application
transport
network
❖ network-core devices do not data link
physical
run user applications
❖ applications on end systems
allows for rapid app
development, propagation

Network Application architectures
possible structure of applications:

❖ Broad architectural plan of the application
❖ Application Architecture vs Network Architecture
▪ Network architecture is fixed and provide services to applications
▪ Application architecture is designed by the application developer
and dictates how the application is organized over the various end
systems
❖ Three architectures
▪ Client-server
▪ Peer-to-peer (P2P)
▪ Hybrid of client-server and P2P

Client-server architecture
server:
❖ always-on host
❖ permanent IP address –
wellknown address
❖ data centers for scaling
▪ Google 30 to 50 data centers
▪ Search, youtube, gmail…
clients:
❖ Sometimes on or always on
client/server
❖ communicate with server
❖ may be intermittently
connected
❖ may have dynamic IP addresses
❖ do not communicate directly
Example: with each other
m Web, FTP, telnet, email …
P2P architecture
❖ no always-on server peer-peer
❖ arbitrary end systems directly
communicate
❖ Peers are not owned by
service providers
❖ 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
❖ Examples – file sharing
(BitTorrent)
P2P architecture
❖ Major challenges peer-peer
▪ ISP Friendly
▪ Security
▪ Incentives

Hybrid of client-server and P2P
Combining both the architectures
Napster
▪ MP3 file sharing application
▪ File transfer P2P
▪ File search centralized:
• Peers register content at central server
• Peers query same central server to locate content
Instant messaging
▪ Chatting between two users is P2P
▪ Presence detection/location centralized:
• User registers its IP address with central server
when it comes online
• User contacts central server to find IP addresses of
buddies
Processes communicating
process: program running clients, servers
within a host client process: process
❖ within same host, two that initiates
processes communicate communication
using inter-process server process: process
communication (defined by that waits to be contacted
OS)
❖ processes in different hosts
communicate by exchanging ❖ aside: applications with P2P
messages architectures have client
processes & server
processes

Sockets
❖ Interface between the process host or host or
server server
and the computer network
❖ process sends/receives controlled by
messages to/from its socket app developer
process process
❖ Analogy socke socke
▪ A process is analogous to house t t
▪ socket analogous to door TCP with TCP with
Internet
▪ sending process shoves message buffers, buffers,
variables variables
out door
▪ sending process relies on
transport infrastructure on controlled
other side of door to deliver by OS
message to socket at receiving
process
❖ Socket is the interface between the application layer and the
transport layer within a host
❖ It is the programming interface (API) with which network
applications are built
Sockets
host or host or
server server
❖ API between the application and
controlled by
the network app developer
process process
❖ Application developer has
socke
▪ Control of everything on socke
t
t
application layer side of socket TCP with TCP with
▪ Little control of the transport layer buffers, Internet buffers,
side of the socket variables variables
❖ The control on transport layer
side controlled
by OS
1) choice of transport protocol;

2) ability to fix a few parameters – max buffer and max segment
sizes

Addressing processes
❖ to receive messages, ❖ identifier includes both IP
process must have address and port numbers
identifier associated with process on
❖ host device has unique host.
32-bit IP address ❖ example port numbers:
❖ Q: does IP address of host ▪ HTTP server: 80
on which process runs ▪ mail server (SMTP): 25
suffice for identifying the ❖ to send HTTP message to
▪ A: no, many processes
process? gaia.cs.umass.edu web
can be running on same server:
host ▪ IP address: 128.119.245.12
▪ port number: 80
❖ more shortly…

App-layer protocol
r An application layer protocol defines how an application’s processes,
running on different end systems, pass messages to each other.
r An application protocols defines:
❖ types of messages exchanged,
open protocols:
▪ e.g., request, response
❖ defined in RFCs
❖ message syntax:
❖ allows for interoperability
▪ what fields in messages &
❖ e.g., HTTP, SMTP
how fields are delineated
❖ message semantics proprietary protocols:
▪ meaning of information in ❖ e.g., Skype
fields
❖ rules for when and how
processes send & respond to
messages

Distinction between network applications and
application layer protocols
❖ An application layer protocol is only one piece of a network

application.
❖ Example – web client/server application
▪ Web application consists of many components – standard for
document formats (HTML), web browsers, web servers, and an
application layer protocol (HTTP).
❖ Example - Internet e-mail application
▪ Mail servers that house user mailboxes, mail readers, a standard for
defining the structure of email message and a application layer
protocol (SMTP) that defines
• how messages are passed between servers,
• how messages are passed between servers and mail readers,
• how the contents of certain parts of the mail message are to be
interpreted.

What transport service does an app need?
❖ Socket – interface between app process and transport protocol
❖ More than one transport protocol - train vs airplane
❖ Application’s service requirements along four dimensions: reliable data
transfer, throughput, timing and security
Reliable data transfer Throughput/bandwidth

❖ some apps (e.g., file transfer,
❖ some apps (e.g.,
web transactions) require multimedia) require
minimum amount of
100% reliable data transfer
throughput to be
❖ other apps (e.g., audio) can
“effective”
tolerate some loss
❖ other apps (“elastic apps”)
timing make use of whatever
❖ some apps (e.g., Internet throughput they get
telephony, interactive security
games) require low delay
❖ encryption, data integrity,
to be “effective”
… Application Layer 2-18
Transport service requirements: common apps
application data loss Throughput/bandwidth time sensitive
file transfer/download no loss elastic no

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

Internet transport protocols services
TCP services: UDP services:

❖ connection-oriented: setup ❖ Lightweight protocol
required between client and ❖ Connectionless
server processes
❖ unreliable data transfer
❖ reliable transport between
sending and receiving between sending and
process receiving process
❖ flow control: sender won’t ❖ does not provide:
overwhelm receiver reliability, flow control,
❖ congestion control: throttle congestion control,
sender when network timing, throughput
overloaded guarantee, security, or
❖ does not provide: timing, connection setup,
minimum throughput
guarantee
Q: why bother? Why is
there a UDP? Application Layer 2-20
Internet apps: application, transport protocols
application underlying
application layer protocol transport protocol
e-mail SMTP [RFC 5321] 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

Securing TCP
TCP & UDP SSL is at app layer

❖ no encryption ❖ Apps use SSL libraries,
❖ cleartext passwds sent which “talk” to TCP
into socket traverse SSL socket API
Internet in cleartext ❖ cleartext passwds sent
SSL into socket traverse
❖ provides encrypted Internet encrypted
TCP connection ❖ See Chapter 7
❖ data integrity
❖ end-point
authentication

Chapter 2: outline
▪ app architectures with UDP and TCP
▪ app requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
2.5 DNS

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

Web and HTTP
First, a review
❖ Browser
▪ Implements the client side of HTTP
▪ Displays the requested web page to the user
▪ Provides numerous navigational and configuration features
▪ Examples : microsoft internet explorer and firefox
❖ Web server
▪ Implements the server side of HTTP
▪ A web server houses web objects, each addressable by a URL.
▪ Examples : Apache and Microsoft Internet Information Server.

HTTP overview
HTTP: hypertext transfer
protocol HT
❖ Web’s application layer TP
re que
protocol PC running HT st
Firefox browser TP
❖ client/server model res
pon
▪ client: browser that requests, se
receives, (using HTTP protocol)
and “displays” Web objects s t
ue
▪ server: Web server sends (using P req
se server
HTTP protocol) objects in HTT p on running
response to requests r es Apache Web
P
H TT server
❖ HTTP 1.0: RFC 1945 – before 1997
❖ HTTP 1.1: RFC 2616 – beginning1998
iphone running
Safari browser
❖ HTTP defines the structure of the messages and how the
client and server exchange the messages.
HTTP overview (continued)
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 asid
protocols that maintain e
❖ HTTP messages
“state” are complex!
(application-layer protocol
❖ past history (state) must be
messages) exchanged maintained
between browser (HTTP
❖ if server/client crashes, their
client) and Web server views of “state” may be
(HTTP server) inconsistent, must be
❖ TCP connection closed reconciled

HTTP connections
non-persistent HTTP persistent HTTP
❖ at most one object ❖ multiple objects can
sent over TCP be sent over single
connection TCP connection
▪ connection then between client, server
closed ❖ HTTP/1.1 uses
❖ downloading multiple persistent connections
objects required in default mode
multiple connections
❖ HTTP/1.0 uses
nonpersistent HTTP

Non-persistent HTTP
Steps of transferring a web page from server to client
suppose user enters URL (for base HTML file): (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 port www.someSchool.edu waiting
80 for TCP connection at port 80.
“accepts” connection, notifying
2. HTTP client sends HTTP client
request message (containing
URL) into TCP connection 3. HTTP server receives request
socket. Message indicates that message, forms response
client wants object message containing requested
someDepartment/home.index object, and sends message into
its socket
time
Non-persistent HTTP (cont.)
4. HTTP server closes TCP
connection.
5. HTTP client receives response
message containing html file,
displays html. TCP connection
terminates. Parsing html file, finds Two different browsers may
10 referenced jpeg objects interpret a web page in
somewhat different ways.
time
6. Steps 1-5 repeated for each of In this example, 11 TCP
10 jpeg objects connections are generated.
10 serial TCP connections or
some parallel connections.
Users can configure modern
browsers to control the
degree of parallelism.
Default, open 5 to 10 parallel
TCP connections

Non-persistent HTTP: response time
❖ Estimate the amount of time that elapses from when a client requests the
base HTML file until the entire file is received by the client
RTT (definition): time for a small
packet to travel from client to
server and back initiate TCP
RTT includes dproc , dprop , dqueue connection
❖ When a user clicks on a RTT

hyperlink request
file
▪ Browser initiate TCP connection time to
▪ Three way handshake RTT transmit
file
HTTP response time: file
❖ one RTT to initiate TCP connection received
❖ one RTT for HTTP request and first few
bytes of HTTP response to return time time
❖ file transmission time
❖ non-persistent HTTP response time =
2RTT+ file transmission time
Persistent HTTP
Nonpersistent HTTP issues:
❖ Brand new connection for each object
❖ OS must work and allocate host Persistent without pipelining:
resources for each TCP connection - ❖ client issues new request only
TCP buffer and TCP variables when previous response has been
❖ Requires 2 RTTs per object received
❖ one RTT for each referenced
❖ but browsers often open parallel TCP
connections to fetch referenced object
objects ❖ Connection idles – wastes server
Persistent HTTP resources
❖ server leaves connection open after Persistent with pipelining:
sending response ❖ default in HTTP/1.1
❖ subsequent HTTP messages between ❖ client sends requests as soon as it
same client/server are sent over the encounters a referenced object
same connection ❖ Back-to-back requests – new
❖ Single connection request before receiving a
▪ Entire web page response to a previous request
▪ Multiple web pages from the same ❖ as little as one RTT for all the
server to the same client referenced objects
❖ HTTP server closes the connection
when it is not used for a certain time
(a configurable timeout interval)

HTTP request message
❖ two types of HTTP messages: request, response

❖ HTTP request message:
▪ ASCII (human-readable format)
carriage return character
Method URL Version
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:
header text/html,application/xhtml+xml\r\n
lines Accept-Language: en-us,en;q=0.5\r\n
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
HTTP request message: general format

Uploading form input
POST method: URL method:
❖ Used when a user fill out ❖ uses GET method
a form ❖ input is uploaded in URL
❖ For example, when a user field of request line:
provides search words to
a search engine
❖ User is still requesting a
web page but with specific
contents
❖ Input is uploaded to
server in entity body
www.somesite.com/animalsearch?monkeys&banan
a
HTTP/1.1:
Method types ❖ GET, POST, HEAD
❖ PUT
HTTP/1.0: ▪ Used in conjunction with
❖ GET web publishing tools
▪ uploads file in entity body
❖ POST to path specified in URL
❖ HEAD field
▪ When the client wants ▪ Used by the client to
some information about provide a new or
the document but not replacement document to
the document itself be stored on the server.
▪ The document is included
▪ asks server to leave in the body of the request
requested object out of and will be stored in the
response location defined by the URL
▪ It is similar to GET, but ❖ DELETE
the response from the ▪ Used to remove a
server does not contain document on the server
the body. ▪ deletes file specified in the
URL field Application Layer 2-36
HTTP response message
status line
Version Status code Phrase
(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
lines Accept-Ranges: bytes\r\n
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

HTTP response message: general format

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: header of the response message)
400 Bad Request
▪ request msg not understood by server
404 Not Found
▪ requested document not found on this server
505 HTTP Version Not Supported

Trying out HTTP (client side) for yourself
1. Telnet to your favorite Web server:
telnet cis.poly.edu opens TCP connection to port 80

80 (default HTTP server port) at cis.poly.edu.
anything typed in sent
to port 80 at cis.poly.edu
2. type in a GET HTTP request:

GET /~ross/ by typing this in (hit carriage
HTTP/1.1 return twice), you send
Host: cis.poly.edu this minimal (but complete)
GET request to HTTP server
3. look at response message sent by HTTP server!

(or use Wireshark to look at captured HTTP request/response)
Header
❑ Exchanges additional information between the client and the
server
For example, the client can request that the document be sent in a
special format or the server can send extra information about the
document.
❑ The header can be one or more header lines
Header name : Header value

Header (2)
❑ Categories of header lines
General header
Request header
Response header
Entity header

Header (3)
Request line Status line
General headers General headers

Request headers Response headers
Entity headers Entity headers
A blank line A blank line
Body Body
Request message Response message

General Header
❑ The general header gives general information about the
message and can be present in both a request and a
response
Header Description
Cache-control Specifies information about caching
Connection Shows whether the connection should be closed
or not
Date Shows the current date
MIME-version Shows the MIME version used
Upgrade Specifies the preferred communication protocol

Request Header
❑ Can be present only in a request message
❑ It specifies the client’s configuration and the client’s preferred document
format
Header Description
Accept Shows the media format the client can accept
Accept-charset Shows the character set the client can handle
Accept-encoding Shows the encoding scheme the client can handle
Accept-language Shows the language the client can accept
Authorization Shows what permissions the client has
From Shows the email address of the user
Host Shows the host and port number of the client
If-modified-since Send the document if newer than specified date
If-match Send the document only if it matches given tag
If-non-match Send the document only if it does not match given tag

Request Header (2)
Header Description
If-range Send only the portion of the document that is missing
If-unmodified-since Send the document if not changed since specified date
Referrer Specifies the URL of the linked document
User-agent Identifies the client program

Response Header
❑ Can be present only in a response message
❑ It specifies the server’s configuration and special information about the
request
Header Description
Accept-range Shows if server accepts the range requested by the
client
Age Shows the age of the document
Public Shows the specified list of methods
Retry-after Specifies the date after which the server is available
Server Shows server name and version number

Entity Header
❑ Gives information about the body of the document
❑ Although it is present in response messages, some request messages, such as POST or
PUT methods, that contain a body also use this type of header
Header Description
Allow List valid methods that can be used with a URL
Content-encoding Specifies the encoding scheme
Content-language Specifies the language
Content-length Shows the length of the document
Content-range Specifies the range of the document
Content-type Specifies the media type
Etag Gives an entity tag
expires Gives the date and time when contents may change
Last-modified Gives the date and time of the last change
location Specifies the location of the created or moved
document

How many Header lines?
❑ How does a browser decide which header lines to include
in a request message?
A browser will generate header lines as a function of
▪ The browser type and version
▪ The user configuration of the browser
▪ Whether the browser currently has a cached , but possibly
out-of-date, version of the object
❑ How does a web server decide which header lines to
include in a response message?
There are different products, versions and configurations

Methods
❑ PATCH method
PATCH is similar to PUT except that the request contain only a list
of differences that should be implemented in the existing file.
❑ COPY method
The COPY method is used to copy a file to another location
The location of the source file is given in the request line (URL)
The location of the destination is given in the entity header.

Methods (2)
❑ MOVE method
The MOVE method is used to move a file to another location.
The location of the source file is given in the request line (URL)
The location of the destination is given in the entity header
❑ LINK method
The LINK method is used to create a link or links from a document
to another location
The location of the file is given in the request line (URL)
The location of the destination is given in the entity header

Methods (3)
❑ UNLINK method
The UNLINK method is used to delete links created by the LINK
method
❑ OPTION method
The OPTION method is used by the client to ask the server about
available options.

Status Codes
❑ Categories of status codes
Informational
Success
Redirection
Client Error
Server Error

Status Codes (2)
Code Phrase Description
Informational
100 Continue The initial part of the request has been
received and the client may continue with its
request
101 Switching The server is complying with a client request to
switch protocols defined in the upgrade header
Success
200 OK The request is successful
201 Created A new URL is created
202 Accepted The request is accepted, but it is not
immediately acted upon
204 No Content There is no content in the body

Status Codes (3)
Redirection
301 Multiple choices The requested URL refers to more than one
resource
302 Moved The requested URL is no longer used by the
permanently server
304 Moved The requested URL has moved temporarily
temporarily
Client error
400 Bad request There is a syntax error in the request
401 Unauthorized The request lacks proper authorization
403 Forbidden Service is denied
404 Not found The document is not found
405 Method not The method is not supported in this URL
allowed
406 Not acceptable The format requested is not acceptable

Status Codes (4)

Server error
500 Internal server There is an error, such as a crash, in the server
error site
501 Not The action requested can not be performed
implemented
503 Service The service is temporarily unavailable, but may
unavailable be requested in the future

User-server Interaction: cookies
❑ HTTP server is Stateless
Simplifies server design
Allow to develop high performance web server
❑ Desirable for a web site to identify users. Why?
Server to restrict user access
It wants to serve content as a function of the user identity
❑ HTTP uses cookies.
❑ Cookies defined in RFC 6265
❑ Allow sites to keep track of users
❑ Many major websites use cookies
❑ portals, e-commerce and advertising sites
http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 257

User-server state: cookies
example:
many Web sites use cookies ❖ Susan always access Internet
four components: from PC
1) cookie header line in ❖ visits specific e-commerce
HTTP response site for first time
message ❖ The site uses cookies
2) cookie header line in ❖ when initial HTTP requests
next HTTP request arrives at site, site creates:
message ▪ unique ID
3) cookie file kept on ▪ entry in backend
user’s host, managed database for ID
by user’s browser
4) back-end database at
Web site
Cookies: keeping “state” (cont.)
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

usual http request msg
ebay 8734 cookie: 1678 cookie-
amazon 1678
specific
usual http response msg action

Cookies (continued)
what cookies can be aside
used for: cookies and privacy:
❖ authorization ❖ cookies permit sites to
❖ shopping carts learn a lot about you
❖ recommendations ❖ you may supply name and
❖ user session state (Web e-mail to sites
e-mail)
how to keep “state”:
❖ protocol endpoints: maintain state Cookies can be
at sender/receiver over multiple used to create a
transactions user session
❖ cookies: http messages carry state layer on top of
Cookie Central – includes stateless HTTP
extensive information on the
cookie
Web caches (proxy server)
goal: satisfy client request without involving origin server
❖ user sets browser: Web
accesses via cache
❖ browser sends all HTTP
HT proxy
requests to cache TP u e st
req server req
▪ Browser establishes a TCP H
client TTP
u e st HT
T P
ons
e
connection to the web res
pon r esp origin
se TP server
cache and sends an HTTP t HT
request for the object to u es
r eq e
the web cache TP o ns
HT es
p
▪ object in cache: cache T TP
r
returns object H
▪ else cache requests object client
from origin server, then origin
returns object to client server
▪ Store a copy
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
(university, company,
residential ISP)

Caching example: origin
assumptions: public
servers
❖ avg object size: 1Mbits (L) Internet
❖ avg request rate from browsers to origin
servers:15/sec (a)
❖ HTTP request messages are negligibly 15 Mbps
small access link
❖ RTT from Internet-side router to any institutional
origin server: 2 sec (Internet delay) network 100 Mbps LAN
❖ access link rate: 15 Mbps (R)
❖ LAN Rate = 100 Mbps (R)
Total response time = LAN delay + Access delay+ Internet delay

consequences: [(15requests/sec)(1Mbits/request)/(100
❖ LAN utilization: 15% Mbps)=0.15] Traffic Intensity=La/R
❖ access link utilization = 100% problem!
❖ total delay = Internet delay + access [(15requests/sec)(1Mbits/request)/(15
delay + LAN delay Mbps)=1] Traffic Intensity
= 2 sec + minutes + 10’s of msecs
≈ minutes Application Layer 2-63
Caching example: fatter access link
assumptions:
❖ avg object size: 1Mbits origin
❖ avg request rate from browsers to origin servers
servers:15/sec public
❖ HTTP request messages are negligibly small Internet
❖ RTT from institutional router to any origin
server: 2 sec
❖ access link rate: 15 Mbps 15 Mbps
100 Mbps 100 Mbps
consequences: access link
❖ LAN utilization: 15% institutional
❖ access link utilization = 100% network
15% 100 Mbps LAN
❖ total delay = Internet delay + access delay +
LAN delay
= 2 sec + minutes + usecs
≈ 2 secs msecs
Cost: increased access link speed (not cheap!)
Caching example: install local cache
assumptions:
❖ avg object size: 1 Mbits origin
❖ avg request rate from browsers to servers
origin servers:15/sec public
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
? 100 Mbps LAN
❖ total delay = Internet delay + access
?
delay + LAN delay local web
= 2 secHow to compute
+ minutes + usecs cache
link
utilization, delay?
Cost: web cache (cheap!)
Hit Rate: Fraction of requests that are satisfied by a cache (0.2 to 0.7)
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
15 Mbps
❖ total delay access link
▪ LAN delay + (Internet delay + Access delay)
▪ = 0.4 * (delay when satisfied at cache) + 0.6 * institutional
(delay from origin servers) network
100 Mbps LAN
▪ = 0.4 (~ 10 msecs) + 0.6 (2 sec + 10’s msecs)
▪ = 0.4 * (0.01 secs) + 0.6 (2 + 0.01 secs) local web
▪ = 0.004 secs + 0.6 * (2.01 secs) cache
▪ ≈ 1.2 secs
▪ less than with 100 Mbps link (and cheaper
too!)
❖ Content Distribution Network
(CDN)
▪ Uses Web caches origin
servers
▪ A CDN company installs public
many geographically Internet
distributed caches
throughout the Internet,
thereby, localizing much of 15 Mbps
the traffic access link
institutional
network
100 Mbps LAN
local web
cache

Conditional GET
❖ Caching reduces response time

❖ Problem
▪ The copy of the object residing in the cache may be stale
❖ HTTP has a mechanism that allows a cache to verify
that its objects are up to date.
❖ Conditional GET
▪ GET method
▪ If-modified-since: <date> header line

Conditional GET
r Example
r Example (contd…)
o On behalf of a requesting
o The cache forwards the
browser, a proxy cache sends
object to browser and
a request message to a web
cache the object locally
server
GET /fruit/kiwi.gif HTTP/1.1 o Cache also stores the
Host: www.exotiquecuisine.com last-modified date
o The web server sends the
along with the object
response message with the
requested object to the o One week later
cache o Another browser request
HTTP/1.1 200 OK the same object via the
Date: Sat, 8 Oct 2011, 15:39:29
cache.
Server: Apache/1.3.0 (Unix)
Last-Modified: Wed, 7 Sep 2011 09:23:24 o Cache performs a check
Content-Type: image/gif by issuing conditional
GET
(data data data data ...)

Conditional GET Client/cache server
❖ Goal: don’t send object if

cache has up-to-date cached
version
▪ no object transmission delay HTTP request msg
object
▪ lower link utilization If-modified-since: <date>
not
❖ cache: specify date of cached modified
copy in HTTP request HTTP response
before
HTTP/1.0
GET /fruit/kiwi.gif
304 Not Modified <date>
HTTP/1.1
Host:
www.exotiquecuisine.com
If-modified-since: <date>
❖ server: response contains no HTTP request msg
object if cached copy is If-modified-since: <date> object
up-to-date: modified
HTTP/1.0 304 Not Modified HTTP response after
Date: Sat, 15 Oct 2011, 15:39:29 HTTP/1.0 200 OK <date>
Server: Apache/1.3.0 (Unix)
<data>
(empty entity body)
Chapter 2: outline
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
2.5 DNS

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

FTP: separate control, data connections
FTP Session
❖FTP client contacts FTP server at
port 21, using TCP TCP control connection,
server port 21
❖client authorized over control
connection
TCP data connection,
❖client browses remote directory, FTP server port 20 FTP
sends commands over control client server
connection
❖when server receives file transfer ❖ control connection: “out of
command, server opens 2nd TCP band”
data connection (for file) to client ❖ HTTP, SMTP : “in-band”
❖after transferring one file, server
❖ FTP server maintains
closes data connection
“state”: current directory,
❖server opens another TCP data
earlier authentication
connection to transfer another file

FTP commands, responses
sample commands: sample return codes
❖ sent as ASCII text over ❖ status code and phrase (as
control channel in HTTP)
❖ USER username ❖ 331 Username OK,
❖ PASS password password required
❖ 125 data
❖ LIST return list of file in
current directory connection already
open; transfer
❖ RETR filename starting
retrieves (gets) file ❖ 425 Can’t open
❖ STOR filename stores data connection
(puts) file onto remote ❖ 452 Error writing
host file
r For other FTP commands and replies – refer RFC
959
Chapter 2: outline
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
2.5 DNS

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” agent
mail
❖ composing, editing, reading server
user
mail messages agent
❖ e.g., Outlook, Thunderbird, user
iPhone mail client agent
❖ outgoing, incoming
messages stored on server
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
server agent
SMTP protocol: SMTP
between mail servers to send SMTP user
email messages mail
agent
▪ client: sending mail server
user
server agent
▪ “server”: receiving mail user
server agent

Electronic Mail: SMTP [RFC 5321]
❖ 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 ASCII
Scenario: Alice sends message to Bob
1) Alice uses UA to compose 4) After some initial SMTP
message “to” handshaking, SMTP client
bob@someschool.edu sends Alice’s message over
2) Alice’s UA sends message to the TCP connection
her mail server; message 5) Bob’s mail server places the
placed in message queue message in Bob’s mailbox
3) client side of SMTP opens 6) Bob invokes his user agent
TCP connection with Bob’s to read message
mail server
1user mail user

mail agent
agent server server
2 3 6
4
5
Alice’s mail server Bob’s mail server
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

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)

SMTP: final words
❖ SMTP uses persistent connections

❖ SMTP requires message (header & body) to be in 7-bit
ASCII
❖ SMTP server uses CRLF.CRLF to determine end of
message

Comparison with HTTP
Similarities
❖Both transfer files
▪ HTTP – web document transfer
▪ SMTP – Email transfer
❖Both uses persistent connections
Differences
❖HTTP: pull SMTP: push
❖Both have ASCII command/response interaction, status codes
▪ SMTP – non-ASCII/binary data converted to ASCII

▪ HTTP - no ASCII conversion
❖HTTP: each object encapsulated in its own response msg

❖SMTP: multiple objects sent in multipart msg

Mail message format
SMTP: protocol for

exchanging email msgs header
blank
RFC 5322: standard for text line
message format:
❖ header lines, e.g.,
▪ To: body
▪ From:
▪ Subject:
different from SMTP MAIL
FROM, RCPT TO:
commands! ❖ Example
❖ Body: the “message” From: alice@crepes.fr
▪ ASCII characters only To: bob@hamburger.edu
Subject: Searching for the meaning of life.

Mail access protocols
user mail access user
SMTP SMTP protocol agent
agent
(e.g., POP,
IMAP)
sender’s mail receiver’s mail

server server
❖ Mail access uses client server architecture
❖ Placing a mail server on local PC
❖ SMTP: delivery/storage to receiver’s server
❖ mail access protocol: retrieval from server
▪ POP3: Post Office Protocol – version 3 [RFC 1939]:
• Port 110, TCP
• authorization (agent <-->server) , transaction, and update
▪ IMAP: Internet Mail Access Protocol [RFC 3501]:
• more features (more complex)
• manipulation of stored msgs on server
▪ HTTP: gmail, Hotmail, Yahoo! Mail, etc.
POP3 protocol
S: +OK POP3 server ready
authorization phase C: user bob
❖ client commands: S: +OK
▪ user: declare username C: pass hungry
▪ pass: password S: +OK user successfully logged on
❖ server responses
▪ +OK C: list
▪ -ERR S: 1 498
transaction phase S: 2 912
S: .
Retrieves messages, mark messages for
deletion, remove deletion marks, obtain C: retr 1
mail statistics S: <message 1 contents>
client: S: .
❖ list: list message numbers C: dele 1
❖ retr: retrieve message by number C: retr 2
❖ dele: delete S: <message 1 contents>
❖ Quit S: .
update phase C: dele 2
Delete the messages that were marked for C: quit
deletion S: +OK POP3 server signing
off
POP3 Protocol
Try yourself – telnet yourself directly into a POP 3
server using port 110
telnet mailServer 110
+OK POP3 server ready
user bob
+OK
pass hungry
+OK user successfully logged on

POP3 Protocol
more about POP3
❖ previous example uses POP3 “download and delete” mode
▪ Bob cannot re-read e-mail if he changes client
❖ POP3 “download-and-keep”: copies of messages on
different clients
❖ POP3 is stateless across sessions

IMAP Protocol
IMAP
❖ keeps all messages in one place: at server
❖ allows user to organize messages in folders
❖ keeps user state across sessions:
▪ names of folders and which messages are associated
with which folders
❖ IMAP permits a user agent to obtain components of
messages.

Web-Based E-mail
❖ Accessing email through
❖ User agent to sender’s
web browsers
mail server
❖ Hotmail introduced ▪ HTTP rather than over SMTP
web-based access in the
❖ Receiver’s mail server to
mid 1990s user agent
❖ User agent is web ▪ HTTP protocol rather than
browser POP3 or IMAP
❖ User communicates with ❖ Sender’s mail server to
its remote mailbox via Receiver’s mail server
HTTP ▪ SMTP
user mail access user

HTTP SMTP protocol agent
agent
(HTTP)
sender’s mail receiver’s mail

server server
Chapter 2: outline
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
2.5 DNS

DNS: domain name system
A directory service that translates host names to IP addresses
people: many identifiers:

Domain Name System:
▪ name, SSN-Aadhar,
driver’s license #, UDP, port 53, RFC 1034,1035
passport # ❖ distributed database
Internet hosts, routers: implemented in hierarchy of
▪ “host-name”, e.g., many DNS servers
www.yahoo.com - used ❖ application-layer protocol: hosts,
by humans name servers communicate to
▪ IP address (32 bit) - used resolve names (address/name
for addressing datagrams translation)
Q: how to map between IP
address and name, and vice
versa ?

DNS Example
DNS is commonly employed by other application layer protocols –
including HTTP, SMTP and FTP
3. The DNS client sends a query

Browser (HTTP client) requests the URL containing the hostname to a
DNS server
www.someschool.edu/index.html 4. The DNS client eventually
receives a reply, which
includes the IP address for the
1.The same user machine runs the client side hostname.
of the DNS application
5. Once the browser receives
2.The browser extracts the hostname,
the IP address from DNS, it
www.someschool.edu, from the URL and can initiate a TCP connection
passes the hostname to the client side of to the HTTP server process
the DNS application located at that IP address
DNS adds additional delay

DNS: services, structure
DNS services
❖ hostname to IP address translation
❖ host aliasing
▪ canonical, alias names
▪ relay1.west-cost.enterprise.com can have aliases enterprise.com or
www.enterprise.com
▪ Obtain canonical hostname for an alias hostname as well as the IP
address of the host
❖ mail server aliasing
▪ E-mail addresses be mnemonic
▪ Canonical name for mail server - relay1.west-coast.hotmail.com
▪ Alias – bob@htomail.com
▪ Obtain canonical hostname for an alias hostname as well as the IP
address of the host
❖ load distribution
▪ replicated Web servers: many IP addresses correspond to one name

DNS: services, structure
why not centralize DNS?
❖ single point of failure
❖ traffic volume
❖ distant centralized database
❖ Maintenance – huge database, update required
A: doesn’t scale!

DNS: a distributed, hierarchical database
❖ Root DNS servers
❖ Top-Level Domain (TLD) DNS
servers Root DNS Servers
❖ Authoritative DNS servers
… …
com DNS servers org DNS servers edu DNS servers
yahoo.com amazon.com pbs.org poly.edu umass.edu

DNS servers DNS servers DNS servers DNS servers DNS servers
DNS client wants IP for www.amazon.com; 1st approx:

❖ client queries one of the root servers, which returns IP addresses
for TLD servers for the top level domain com
❖ client then queries one of these com DNS servers, which returns
IP address of authoritative server for amazon.com
❖ client queries one of the authoritative servers for amazon.com,
which returns the IP address for the hostname www.amazon.com

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
▪ List of current root DNS servers is available at
http://www.root-servers.org/
Oct 2006 map
c. Cogent, Herndon, VA (5 other sites) 13 root name
d. U Maryland College Park, MD
h. ARL Aberdeen, MD
k. RIPE London (17 other sites)
“servers”
j. Verisign, Dulles VA (69 other sites ) i. Netnod, Stockholm (37 other sites) worldwide
e. NASA Mt View, CA m. WIDE Tokyo
f. Internet Software C. (5 other sites)
Palo Alto, CA (and 48 other Each server is actually a
sites)
network of replicated
a. Verisign, Los Angeles CA servers
(5 other sites)
b. USC-ISI Marina del Rey, CA
l. ICANN Los Angeles, CA
247 root servers as of
(41 other sites) fall 2011
g. US DoD Columbus,
OH (5 other sites) >1000 as of Jan 2019

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
▪ Verisign Global Registry Services maintains servers for
.com TLD
▪ Educause for .edu TLD
▪ List of all TLDs available at
https://www.iana.org/domains/root/db
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

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

DNS name root DNS server
resolution example
2
3
❖ host at cis.poly.edu TLD DNS server
4
wants IP address for
gaia.cs.umass.edu 5
local DNS server

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

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

DNS: caching, updating records
❖ Benefits of DNS caching
▪ Improve the delay performance
▪ Reduce the number of DNS messages
❖ 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 host-name changes IP address, may not be known
Internet-wide until all TTLs expire
❖ update/notify mechanisms proposed IETF standard
▪ RFC 2136
❖ dynamic DNS update
Delete DNS cache
❖ The contents of a local DNS cache can be viewed in
Windows using the command
ipconfig /displaydns
❖ Clearing cache in firefox
▪Open Firefox and type in about:config in the address bar.
▪Accept the on-screen warning to proceed to Firefox’s
preferences.
▪Search for the following preference and set its value to 0.
network.dnsCacheExpiration
❖ Clearing cache in Windows
▪Open a Command Prompt window with administrative rights.
▪Enter the following and tap Enter.
ipconfig /flushdns

DNS records
DNS: distributed db storing resource records (RR)
RR format: (name, value, type, ttl)
type=A type=CNAME
▪ name is hostname ▪ name is alias name for some “canonical”
▪ value is IP address (the real) name
▪ value is canonical name
▪ Provide standard hostname to IP
▪ Provide querying hosts the canonical name
address mapping
for a host name
▪ (relay1.bar.foo.com, 145.37.93.126, A)
▪ www.ibm.com is really
servereast.backup2.ibm.com
type=NS ▪ (foo.com, relay1.bar.foo.com, CNAME)
▪ name is domain (e.g., foo.com)
▪ value is hostname of authoritative type=MX
name server for this domain ▪ value is canonical name of a
▪ Used to route DNS queries further mailserver associated with alias
along in the query chain host-name name
▪ (foo.com, dns.foo.com, NS) ▪ (foo.com, mail.bar.foo.com, MX)
▪ Allow hostnames of mail servers to
have simple aliases Application Layer 2-104
DNS protocol, messages
❖ query and reply messages, both with same
message format 2 bytes 2 bytes
msg header identification flags

12 bytes
❖ identification: 16 bit # for # questions # answer RRs
query, reply to query uses Header section
same # # authority RRs # additional RRs
❖ flags: questions (variable # of questions)

▪ Query (0) or reply (1)
▪ recursion desired answers (variable # of RRs)
▪ recursion available Data Section
▪ reply is authoritative authority (variable # of RRs)
additional info (variable # of RRs)

DNS protocol, messages
2 bytes 2 bytes
identification flags
12 bytes
# questions # answer RRs
Header section
# authority RRs # additional RRs
name, type fields questions (variable # of questions)

for a query
RRs in response answers (variable # of RRs)
to query Data Section
records for authority (variable # of RRs)

authoritative servers
additional “helpful” additional info (variable # of RRs)
info that may be used
Eg.: the answer field in a reply to an MX query contains a resource record providing the canonical
hostname of a mail server. The additional section contains a Type A record providing the IP
address for the canonical hostname of the mail server.
nslookup program
❖ How would you send a DNS query message to DNS server?
❖ After invoking nslookup program, you can send a DNS query
to any DNS server (root, TLD or authoritative)
nslookup www.pec.ac.in
❖ After receiving the reply message from the DNS server,
nslookup will display the records included in the reply.
❖ As an alternative to running nslookup from your own host,
you can visit one of many web sites that allow you to
remotely employ nslookup.
http://www.kloth.net/services/nslookup.php

Inserting records into DNS Database
❖ example: new startup “Network Utopia”
❖ Register domain name networkuptopia.com at
DNS registrar
❖ Registrar is a commercial entity
▪ verifies uniqueness of domain name
▪ enters the domain name into the DNS database
❖ Prior to 1999, a single registrar, Network Solutions,
had monopoly for com, net and org domains
❖ ICANN accredits registrars
❖ List of accredited registrars available at
http://www.internic.net

Inserting records into DNS Database
❖ Register domain name networkuptopia.com
▪ provide names and IP addresses of authoritative name server
(primary and secondary)
dns1.networkutopia.com, 212.212.212.1
dns2.networkutopia.com, 212.212.212.2
▪ registrar inserts two RRs into .com TLD server:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
❖ Create following records in authoritative server
▪ type A record for web server www.networkuptopia.com
▪ type MX record for mail server mail.networkutopia.com
How do people get the IP address of your Web site?

Chapter 2: outline
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
2.5 DNS

Pure P2P architecture
❖ no always-on server
❖ arbitrary end systems directly
communicate
❖ peers are intermittently connected
and change IP addresses
❖ Peers are not owned by service
provider
▪ Desktops and laptops controlled
by users
Two applications:
▪ File distribution
(BitTorrent system)
▪ Database distributed over large
number of peers
(Distributed Hash Table – DHT)

File distribution: client-server vs P2P
Distributing a large file from a single server to a large number of
hosts (called peers)
Client server file distribution
❖ Server send a copy to each of the peers
❖ Enormous Burden on server
❖ Consumes large amount of server bandwidth
P2P file distribution

❖ Each peer can re-distribute any portion of the file it has
received to any other peers
❖ Assist server in distribution process
BitTorrent:
❖ P2P file distribution protocol
❖ Originally developed by Bram Cohen
❖ Different BitTorrent clients conforming to BitTorrent protocol
Eg. Different web browser clients conforming to HTTP
Scalability of P2P Architectures
Simple Quantitative model for distributing a file to a
fixed set of peers for both architecture types
us: server upload N: Number of peers
capacity/rate
di: peer i download

u1 d1 capacity/rate
us u2 d2
file, size F bits server
di
uN network (with abundant
bandwidth) - Internet ui
dN
ui: peer i upload
Distribution time capacity/rate
❖Time to get a copy of the file to all N peers
Assumptions
❖Internet
core has abundant bandwidth (bottleneck – access links)
❖No other download/upload
File distribution time: client-server (Dcs )
❖ server transmission: must
transmit one copy of the file to F
us
each of the N peers, N*F bits:
di
▪ min time to send one copy: F/us
network
▪ min time to send N copies: NF/us ui
❖ client: each client must download file copy

▪ dmin = download rate of the peer with the lowest download rate
▪ dmin = min{d1, d2, …..,dN}
Lower bound on min
▪ min client download time: F/dmin seconds distribution time
▪ min distribution time is at least F/dmin seconds
time to distribute F bits
to N clients using
client-server approach
increases linearly in N Application Layer 2-114

File distribution time: P2P (DP2P )
❖ server transmission: must
upload at least one copy F
us
▪ min time to send one copy: F/us di
❖ client: each client must download network
file copy ui
▪ min client download time: F/dmin
▪ min distribution time is at least F/dmin
sec
time to distribute F
to N clients using
P2P approach
If each peer can redistribute a bit as soon as it receives the bit,

then there is a redistribution scheme that actually achieves this lower bound

File distribution time: P2P (DP2P )
F
us
di
network
ui
increases linearly in N … … but so does this, as each peer brings service capacity

Client-server vs. P2P: example
peer upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us
(same for all peers)

P2P file distribution: BitTorrent
torrent: tracker: infrastructure node,
group of peers exchanging tracks peers participating in
torrent
equal-sized chunks of a file (typical
size 256 kbytes)
❖ peer joining torrent (first time):
▪ has no chunks, but will
accumulate them over time
from other peers
❖ peers in torrent send/receive
file chunks ❖ Any peer may leave torrent
❖ once peer has acquired entire ▪ With only a subset of
file, it may chunks
(selfishly) leave ▪ Later rejoin the torrent
or
(altruistically) remain in torrent
How BitTorrent operates
❖ 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”)
Alice arrives …
… obtains list of peers from tracker

…tracker sends the IP addresses
… establish concurrent TCP connections with “neighbours”

…and begins exchanging file chunks with peers in torrent

How BitTorrent operates
❖ churn: peers may come and
go
❖ peer may change peers with
whom it exchanges chunks
❖ while downloading, peer
uploads chunks to other
peers

BitTorrent: requesting, sending file chunks
requesting chunks: sending chunks: tit-for-tat

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

BitTorrent: tit-for-tat
(1) Alice “optimistically unchokes”
BobAlice becomes one of Bob’s top-four providers; Bob
(2)
reciprocates
(3) Bob becomes one of Alice’s top-four
providers
higher upload rate: find better

trading partners, get file faster !

BitTorrent: Operation
Animation of protocol
use:
❖ The colored dots beneath
each computer in the
animation represent
different parts of the file
being shared.
❖ By the time a copy to a
destination computer of
each of those parts
completes, a copy to
another destination
computer of that part (or
other parts) is already
taking place between users.
Distributed Hash Table (DHT)
❖ Hash table
❖ DHT paradigm
❖ Circular DHT and overlay networks
❖ Peer churn

Simple Database
❖ How to implement a simple database in P2P
Network?
▪ Centralized (central server)
• For client server architecture
▪ Distributed
• For P2P architecture

Simple Database :Centralized
❖ Building central database for client server architecture
▪ that stores all the (key, value) pairs in one central server
❖ Simple database with (key, value) pairs
❖ Example 1
▪ key: social security # ; value: human name
Key Value
132-54-3570 John Washington ❖ Query the
761-55-3791 Diana Louise Jones database with key
385-41-0902 Xiaoming Liu
▪ If match
441-89-1956 Rakesh Gopal
217-66-5609 Linda Cohen
▪ Returns values
……… …….
177-23-0199 Lisa Kobayashi

Simple Database :Centralized
❖ Example 2
▪ key: content name (e.g., names of movies, albums and
software)
▪ value: IP address at which content is stored
key: movie title; value: IP address

(Led Zeppelin, 128.17.123.38)
❖ Query the database with key

▪ If match
▪ Returns values

Simple Database : Distributed
❖ Building distributed database for P2P architecture
▪ that will store (key, value) pairs over millions of peers
❖ Each peer will only hold a small subset of the totality of the
(key, value) pairs
❖ Query the distributed database with key
▪ Distributed Database will locate the peers that have the
corresponding (key, value) pairs
▪ Return the (key, value) pairs to the querying peer
❖ Any peer will also be allowed to insert new (key, value) pairs
into the database
❖ Distributed Hash Table (DHT) – Distributed Database

DHT Example: P2P File Sharing
❖ (key, value) : (content name, IP address of the peer)
❖ Peers Bob and Charlie – Linux distribution
❖ DHT database: distributed over peers
(Linux, IPBob) and (Linux, IPCharlie)
❖ Peer Dave
▪ Responsible for the key “Linux”
▪ Will have key-value pairs
❖ Peer Alice wants to obtain a copy of Linux

DHT Example: P2P File Sharing
❖ Peer Alice wants to obtain a copy of Linux
▪ which peers have a copy of Linux
▪ queries the DHT with “Linux” as the key
▪ DHT determines that the peer Dave is responsible for the
key “Linux.”
▪ DHT contacts peer Dave
• obtains from Dave the key-value pairs (Linux, IPBob) and
(Linux, IPCharlie),
• passes them on to Alice
▪ Alice can then download the latest Linux distribution from
either IPBob or IPCharlie.

Designing a DHT
❖ Naive approach
❖ Elegant approach

Designing a DHT: Naive Approach
❖ Randomly scatter (key, value) pairs across all peers
▪ pairs are evenly distributed over peers
▪ Each peer maintains a list of the IP addresses of all
participating peers
❖ Querying peer sends its query to all other peers with
a key
▪ database returns value for the key
▪ To resolve query, number of messages exchanged among
peers
❖ Unscalable
▪ Requires each peer knows about all other peers
▪ Each query is sent to all peers

Designing a DHT: Elegant Approach
❖ Assign an ID to each peer
▪ ID is integer in the range [0, 2n -1] for some fixed n
▪ ID expressed as n-bit representation
❖ Each key to be an integer in the same range
❖ Example keys described earlier are not integers
▪ Social security numbers and content names
❖ To create integers out of such keys
▪ use a hash function that maps each key (e.g., human names)
to an integer in the range [0, 2n -1].

Designing a DHT: Elegant Approach
❖ hash function
▪ one-to-one
▪ many-to-one
available to all peers in the system
❖ “key,” hash of the original key
❖ For example,
▪ if the original key is “Led Zeppelin IV”
▪ key used in the DHT will be the integer that equals the
hash of “Led Zeppelin IV.”

Hash Table
❖ More convenient to store and search on
numerical representation of key
key = hash(original key)
Original Key Key Value
John Washington 8962458 132-54-3570
Diana Louise Jones 7800356 761-55-3791
Xiaoming Liu 1567109 385-41-0902
Rakesh Gopal 2360012 441-89-1956
Linda Cohen 5430938 217-66-5609
……. ………
Lisa Kobayashi 9290124 177-23-0199

Storing key-value pairs in DHT
❖ Assign key-value pairs to peers
❖ Define the rule for assigning keys to peers
❖ rule: assign each (key, value) pair to the peer whose ID is closest
to the key
❖ convention: closest is the immediate/closest successor of the key.
❖ Example
▪ Suppose n=4, peer and key identifiers are in the range [0, 15]
▪ ID space {0, 1,2,3,…, 15}
{0000, 0001, 0010, 0011, 0100, 0101,0110, …….. 1111)
▪ suppose 8 peers: 1, 3, 4, 5, 8, 10, 12, and 15
▪ Suppose we want to store the (key, value) pair (11, Johnny
Wu) in one the 8 peers
▪ Which peer?
• If key = 11, then assigned to peer 12 (successor of 11)
❖ Complete definition of closest:

▪ If key = peer ID, store (key, value) pair in that peer
▪ If key > all peer IDs, modulo-2n convention, store (key, value)
pair in the peer with the smallest ID

Example:
❖Suppose a peer, Alice, wants to insert a (key, value) pair into the
DHT
▪ first determines the peer whose identifier is closest to the key
▪ send a message to that peer to store the (key, value) pair
❖How does Alice determine the peer that is closest to the key?
▪ If Alice were to keep track of all the peers in the system (peer
IDs and corresponding IP addresses),
she could locally determine the closest peer.
❖Requires each peer to keep track of all other peers in the DHT
▪ completely impractical for a large-scale system with millions of
peers
❖Problem of Scale

Circular DHT
• each peer only aware of immediate
successor and predecessor (peer ID
and IP address)
• Example: n=4
8 peers: 1, 3, 4, 5, 8, 10, 12, and 15
1 (0001)
3 (0011)
15
(1111)
4 (0100)
12
(1100) 5 (0101)
10 (1010 “overlay network”

8 (1000)
“special case of overlay network” “abstract logical network”
“circular overlay network” “Underlay Network”
Resolving a query
Who is responsible
O(N) messages for key 11 ?
on average to resolve 1
query, when there
are N peers 3
Tradeoff between 15
❖Number of
value
neighbors each 4
peer has to track
❖Number of 12
messages that 5
DHT needs to
send to resolve as 10
single query 8
Circular DHT with shortcuts
1 What is the value for
key 11?
3
15 value
4
12
5
10
8
• each peer keeps track of IP addresses of predecessor,
successor, short cuts.
• reduced from 6 to 3 messages.
• possible to design shortcuts with O(log N) neighbors, O(log
N) messages in query

Peer churn: Maintaining DHT
handling peer churn (Leave):
1
❖peers may come and go (churn)
without warning
3
15 ❖To
handle peer churn, require
each peer to know the IP address
4
of its two successors
12
5 ❖each peer periodically pings its
two successors to check aliveness
10
8 ❖if immediate successor leaves,
example: peer 5 abruptly leaves choose next successor as new
immediate successor

handling peer churn (Leave):
1
❖peers may come and go (churn)
without warning
15 3
❖To
handle peer churn, require
each peer to know the IP address
4
of its two successors
12 ❖each peer periodically pings its
two successors to check aliveness
10
8 ❖if immediate successor leaves,
example: peer 5 abruptly leaves choose next successor as new
immediate
❖peer 4 detects peer 5’s departure; makes 8 itssuccessor
immediate
successor
❖ 4 asks 8 who its immediate successor is; makes 8’s immediate
successor its second successor.
1 handling peer churn (join):
❖Peer with ID 13 wants to join the
15 3 DHT
❖ At the time of joining, it only
4 knows about peer 1’s existence in
12 the DHT.
❖Peer
13 would first send peer 1 a
10 message, saying “what will be 13’s
8
❖
predecessor
This message gets forwarded through the DHT and
untilsuccessor?”
it reaches peer
12, who realizes that it will be 13’s predecessor and that its current
successor, peer 15, will become 13’s successor.
❖ Next, peer 12 sends this predecessor and successor information to
peer 13. Peer 13 can now join the DHT by making peer 15 its
successor and by notifying peer 12 that it should change its
immediate successor to 13.
Chapter 2: outline
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
2.5 DNS

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
proce socket proce controlled by
ss ss app developer
transport transport
network network controlled
link link by OS
Internet
physical physical

Socket programming
Two types of network applications: open vs
proprietary
Open: Proprietary:
❖ Rules of operation are ❖ Rules of operation are not
known to all known to public
❖ Operation is specified in a ❖ No RFC or other standards
protocol standard such as
RFC or other standards
❖ Well known ports ❖ Ephemeral ports
❖ Independent developers: ❖ Single developer or team
▪ Firefox browser ▪ Other developer code
communicates to Apache may not interoperate
web server
❖ HTTP, FTP etc. ❖ Protocol defined by user
Socket programming
Two socket types for two transport services:
▪ UDP: connectionless, unreliable datagram
▪ TCP: connection-oriented, reliable, byte
stream-oriented
Application Example:
1. Client reads a line of characters (data) from its
keyboard and sends the data to the server.
2. The server receives the data and converts
characters to uppercase.
3. The server sends the modified data to the client.
4. The client receives the modified data and displays
the line on its screen.
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
❖ rcvr 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

Socket programming with UDP
Example client-server app:
1) A client reads a line from
standard input (keyboard)
and sends the line out its
socket to the server
2) server reads line from its
socket Client
3) server converts the line to Input: receives
uppercase process
packet (TCP
4) Server sends the modified received “byte
line out its socket to the Output: sends
client packet (TCP sent stream”)
5) client reads the modified “byte stream”)
line from its socket and
prints the line on its
standard output (monitor) client UDP
socket

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
http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application 2-151

Example app: UDP client
Python UDPClient
include Python’s socket
from socket import *
library
serverName = ‘hostname’
serverPort = 12000
create UDP socket for
Client clientSocket = socket(socket.AF_INET,
get user keyboard
socket.SOCK_DGRAM)
input
Attach server name, port to message = raw_input(’Input lowercase sentence:’)
message; send into socket
read reply characters from clientSocket.sendto(message,(serverName, serverPort))

socket into string
modifiedMessage, serverAddress =
print out received string clientSocket.recvfrom(2048)
and close socket Buffer size
print modifiedMessage
clientSocket.close()
Example app: UDP server
Python UDPServer
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
Read from UDP socket into while 1:

message, getting client’s
address (client IP and port)
message, clientAddress = serverSocket.recvfrom(2048)
send upper case string modifiedMessage = message.upper()
back to this client
serverSocket.sendto(modifiedMessage, clientAddress)

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

Client socket, Welcoming socket and Connection socket

Stream jargon
❖ A stream is a sequence of
characters that flow into or out
of a process.
❖ An input stream is attached to Client
some input source for the process
process, eg, keyboard or
socket.
❖ An output stream is attached
to an output source, eg,
monitor or socket.
client TCP
socket

Socket programming with TCP
Example client-server app:
1) client reads line from standard
input (inFromUser stream) ,
sends to server via socket
(outToServer stream)
Client
2) server reads line from socket
3) server converts line to uppercase, process
sends back to client
4) client reads, prints modified line
from socket (inFromServer
stream)
client TCP
socket

Client/server socket interaction: TCP
server (running on serverIP) client
create socket, port=x,
for incoming request:
serverSocket = socket()
wait for incoming create socket,

connection request
TCP connect to serverIP, 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

Example app: TCP client
Python TCPClient
serverName = ’servername’
create TCP socket for serverPort = 12000
server, remote port 12000
clientSocket = socket(AF_INET, SOCK_STREAM)
clientSocket.connect((serverName,serverPort))
No need to attach server sentence = raw_input(‘Input lowercase sentence:’)

name, port
clientSocket.send(sentence)
modifiedSentence = clientSocket.recv(1024)
print ‘From Server:’, modifiedSentence
clientSocket.close()
Example app: TCP server
Python TCPServer
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 1:
server waits on accept() connectionSocket, addr = serverSocket.accept()
for incoming requests, new
socket created on return
sentence = connectionSocket.recv(1024)
read bytes from socket (but
not address as in UDP)
capitalizedSentence = sentence.upper()
connectionSocket.send(capitalizedSentence)
close connection to this connectionSocket.close()
client (but not welcoming
socket)
Chapter 2: summary
our study of network apps now complete!
❖ application architectures ❖ specific protocols:
▪ client-server ▪ HTTP
▪ P2P ▪ FTP
❖ application service
requirements: ▪ SMTP, POP, IMAP
▪ reliability, bandwidth, delay ▪ DNS
❖ Internet transport service ▪ P2P: BitTorrent, DHT
model ❖ socket programming: TCP,
▪ connection-oriented, UDP sockets
reliable: TCP
▪ unreliable, datagrams: UDP

Chapter 2: summary
most importantly: learned about protocols!
❖ typical request/reply important themes:

message exchange:
❖ control vs. data msgs
▪ 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 msg
▪ headers: fields giving
info about data transfer
▪ data: info being ❖ “complexity at network
communicated edge”

END

Application Layer PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Application Layer PDF

Uploaded by

Copyright:

Available Formats

Chapter 2

Application Layer 2-1

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-2

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-3

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-4

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-5

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-6

possible structure of applications:

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-7

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-10

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-12

1) choice of transport protocol;

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-14

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-15

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-16

❖ An application layer protocol is only one piece of a network

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-17

Reliable data transfer Throughput/bandwidth

application data loss Throughput/bandwidth time sensitive

file transfer/download no loss elastic no

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-19

TCP services: UDP services:

e-mail SMTP [RFC 5321] TCP

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-21

TCP & UDP SSL is at app layer

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-22

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-23

host name path name

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-24

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-25

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-27

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-28

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-30

❖ When a user clicks on a RTT

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-32

❖ two types of HTTP messages: request, response

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-34

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-37

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-38

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-39

telnet cis.poly.edu opens TCP connection to port 80

2. type in a GET HTTP request:

3. look at response message sent by HTTP server!

Header name : Header value

Application Layer 2-41

Application Layer 2-42

General headers General headers

A blank line A blank line

Request message Response message

Application Layer 2-43

Application Layer 2-44

Application Layer 2-45

Application Layer 2-46

Application Layer 2-47

Application Layer 2-48

http://gaia.cs.umass.edu/kurose-ross-ppt-6e/ Application Layer 2-49

Application Layer 2-50

Application Layer 2-51

Application Layer 2-52

Application Layer 2-53

Application Layer 2-54

Application Layer 2-55