Application Layer - Chapter - 2 - Version 7.1

Chapter 2
Application Layer
A note on the use of these ppt slides: Computer

We’re making these slides freely available to all (faculty, students, readers).
They’re in PowerPoint form so you see the animations; and can add, modify, Networking: A
and delete slides (including this one) and slide content to suit your needs.
They obviously represent a lot of work on our part. In return for use, we only Top Down
ask the following:
 If you use these slides (e.g., in a class) that you mention their source Approach
(after all, we’d like people to use our book!)
 If you post any slides on a www site, that you note that they are adapted
6th edition
from (or perhaps identical to) our slides, and note our copyright of this Jim Kurose, Keith Ross
material. Addison-Wesley
Thanks and enjoy! JFK/KWR March 2012
All material copyright 1996-2012
J.F Kurose and K.W. Ross, All Rights Reserved
Application Layer 2-1

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

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

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

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
no need to write software for application
network-core devices transport

network
application
data link
 network-core devices do not physical transport
network
run user applications data link
physical
 applications on end systems

allows for rapid app
development, propagation

Application architectures
possible structure of applications:
 client-server
 peer-to-peer (P2P)

Client-server architecture
server:
 always-on host
 permanent IP address
 data centers for scaling
clients:
 communicate with server
client/server  may be intermittently
connected
 may have dynamic IP
addresses
 do not communicate directly
with each other
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

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

Addressing processes
 to receive messages, process  identifier includes both IP
must have identifier address and port numbers
 host device has unique 32- associated with process on
bit IP address host.
 Q: does IP address of host  example port numbers:
on which process runs  HTTP server: 80
suffice for identifying the  mail server: 25
process?  to send HTTP message to
 A: no, many processes 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 defines
 types of messages open protocols:
exchanged,  defined in RFCs
 e.g., request, response  allows for interoperability
 message syntax:  e.g., HTTP, SMTP
 what fields in messages proprietary protocols:
& how fields are  e.g., Skype
delineated
 message semantics
 meaning of information
in fields
 rules for when and how
processes send & respond
to messages

What transport service does an app need?
data integrity throughput
 some apps (e.g., file transfer,  some apps (e.g.,
web transactions) require multimedia) require
100% reliable data transfer minimum amount of
 other apps (e.g., audio) can throughput to be “ effective
tolerate some loss ”
 other apps (“ elastic apps” )
timing make use of whatever

throughput they get
 some apps (e.g., Internet
telephony, interactive security
games) require low delay
 encryption, data integrity,
to be “ effective”
…

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

Internet transport protocols services
TCP service: UDP service:

 reliable transport between  unreliable data transfer
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
overloaded timing, throughput
 does not provide: timing, guarantee, security,
minimum throughput orconnection setup,
guarantee, security
 connection-oriented: setup Q: why bother? Why is
required between client and there a UDP?
server processes
Internet apps: application, transport protocols
application underlying
application layer protocol transport protocol
e-mail SMTP [RFC 2821] TCP

remote terminal access Telnet [RFC 854] TCP
Web HTTP [RFC 2616] TCP
file transfer FTP [RFC 959] TCP
streaming multimedia HTTP (e.g., YouTube), TCP or UDP
RTP [RFC 1889]
Internet telephony SIP, RTP, proprietary
(e.g., Skype) TCP or UDP

Chapter 2: outline
2.1 principles of network 2.6 P2P applications
applications 2.7 socket programming
 app architectures with UDP and TCP
 app requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
 SMTP, POP3, IMAP
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

HTTP overview
HTTP: hypertext transfer
protocol HT
 Web’s application layer TP
req
ues
protocol PC running HT t
Firefox browser TPr
 client/server model esp
ons
 client: browser that e
requests, receives, t
(using HTTP protocol) u es
req server
and “ displays” Web T P n se
HT s po running
objects TP
re Apache Web
T
 server: Web server H server
sends (using HTTP
protocol) objects in iphone running
response to requests Safari browser

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 aside
protocols that maintain
 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 sent  multiple objects can
over TCP connection be sent over single
 connection then TCP connection
closed between client, server
 downloading multiple
objects required
multiple connections

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 port 80 www.someSchool.edu waiting
for TCP connection at port 80.
“ accepts” connection, notifying
2. HTTP client sends HTTP request message client
(containing URL) into TCP connection
socket. Message indicates that client wants
object someDepartment/home.index 3. HTTP server receives request
message, forms response
message containing requested
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. Parsing html file,
finds 10 referenced jpeg objects
time
6. Steps 1-5 repeated for each of 10
jpeg objects

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
 one RTT to initiate TCP connection
connection RTT
 one RTT for HTTP request request
file
and first few bytes of HTTP time to
response to return RTT transmit
file
 file transmission time
file
 non-persistent HTTP received
response time =
2RTT+ file transmission time time
time

Persistent HTTP
non-persistent HTTP persistent HTTP:

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

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
Uploading form input
POST method:
 web page often includes
form input
 input is uploaded to server
in entity body
URL method:
 uses GET method
 input is uploaded in URL
field of request line:
www.somesite.com/animalsearch?monkeys&banana

HTTP 1.x Key Characteristics:
1. Text-Based: HTTP 1.x is text-based, with both requests and responses
being human-readable. This simplicity made it easy for developers to
debug, but it also resulted in larger message sizes and higher
bandwidth consumption.
2. Stateless: Each HTTP request-response cycle is independent, and the
server doesn't maintain any knowledge of previous interactions. This
statelessness simplifies server design but can lead to inefficiencies
when multiple requests are needed to load a web page.
3. Blocking: HTTP 1.x is blocking in nature, meaning that the client
must wait for a response to a request before making the next request,
even if there are other resources it could be fetching concurrently. This
blocking behavior can cause latency and slower page loading times.
4. Connection Overhead: A new TCP connection is typically
established for each request-response cycle. This results in connection
overhead and can slow down web page loading, especially when many
resources need to be fetched.

HOL Problem in HTTP 1.x:
HTTP 1.x, the first generation of the HTTP protocol, uses a simple and
straightforward request-response model, where each client request is processed
sequentially. While this model is easy to understand, it leads to the Head-of-Line
(HOL) problem.
1. Serial Processing: In HTTP 1.x, the client sends a request for a resource, and the
server processes it one at a time. The server can't start processing another request
until it has completed the current one. This sequential processing of requests and
responses creates a bottleneck.
2. Blocked Resources: If a web page includes multiple resources (e.g., HTML, CSS,
JavaScript, images, and more), and any of these resources takes a while to load, it
blocks subsequent resources from being requested and loaded. For example, if an
image resource is slow to load, it can delay the loading of critical resources like CSS or
JavaScript files.
3. Impact on Page Load Time: The HOL problem directly impacts the page load time.
Since resources are loaded serially, the total time to load a web page can be
significantly longer, especially if there are latency issues or slow-loading resources.
Users may experience slower page rendering and interactivity.
4. Latency Issues: High network latency further exacerbates the HOL problem. For each
resource request, there's a delay due to the round-trip time between the client and
server. This latency adds up when multiple resources need to be fetched.

HOL Problem in HTTP 1.x:
Example: Imagine a scenario where a web page consists of several resources:
• HTML document
• CSS stylesheet
• JavaScript files
• Multiple images
In an HTTP 1.x scenario, if the HTML document is slow to load due to a large size or
network latency, the subsequent resources, such as CSS, JavaScript, and images, will be
delayed. The browser has to wait for the HTML document to finish loading before it can
parse it and discover other resources that need to be fetched. This results in a situation
where even fast-loading resources are held back by slower resources.
This delay has a cascading effect, leading to slower web page rendering and reduced user
experience. The HOL problem makes it difficult to fully utilize available network
bandwidth and parallelize resource retrieval effectively.
HTTP/2.0, with its multiplexing and concurrent processing capabilities, addresses the
HOL problem by allowing multiple resources to be requested and delivered in parallel
over a single connection, significantly improving web page loading times and user
experience.

HTTP /2.0 Key Features:
1. Binary Framing: HTTP/2.0 uses a binary protocol for its messages. Data is divided
into smaller frames, which are more efficiently processed by both the client and server.
Binary framing allows for better multiplexing and prioritization of requests and
responses.
2. Multiplexing: Multiplexing is one of the most significant improvements in HTTP/2.0.
It allows multiple requests and responses to be sent concurrently over a single
connection. This reduces latency, as clients no longer have to wait for one resource to
download before requesting another.
3. Header Compression: HTTP/2.0 uses header compression techniques to reduce
redundancy in header data. This reduces the overhead of sending headers with each
request and response, making data transfer more efficient.
4. Server Push: With HTTP/2.0, servers can proactively push resources to the client.
For
example, if a web page requires multiple resources, the server can push some of these
resources to the client before the client requests them. This feature improves the
efficiency of loading complex web pages.

Binary Frame Structure: Binary frames in HTTP/2.0 are the fundamental units used to
structure and transmit data efficiently over the network. These frames are essential for
multiplexing, flow control, and prioritization. Let's dive into the binary frame structure and its
components with an example:
A binary frame in HTTP/2.0 consists of three parts:
1.Frame Header: This is a fixed-size section of the frame that contains essential
information such as the frame length, type, flags, stream identifier, and, in some cases, a
priority field.
2.Frame Payload: This is the variable-sized portion of the frame that carries the actual
data. The structure of the payload depends on the frame type.
3.Padding: Padding can be added to a frame if necessary, but it's optional. Padding is
used to increase the size of the frame, for example, to obfuscate the actual payload size.
Example: A DATA Frame

Let's take a look at the structure of a DATA frame in HTTP/2.0 as an example:
• Frame Type: DATA (0x0)
• Flags: DATA frames have three flags: END_STREAM (0x1), END_HEADERS
(0x4), and PADDED (0x8). These flags indicate, respectively, whether this is the last
frame for the associated stream, the end of the header block, and if padding is included.
• Stream Identifier: A 31-bit identifier indicating which stream this frame belongs to.
• Payload: The actual binary data that the frame carries. This is typically the content of
an HTTP message or a part of it.
• Padding: If the PADDED flag is set, there may be padding included, and the length of
the padding is determined by the length of a padding field. The padding field can be up
to 255 bytes long.
Here's how a DATA frame might look in binary for
+-----------------------------------------------+
|Frame Type (8 bits) | Flags (8 bits) | Stream Identifier (31 bits) |
+-----------------------------------------------+
| Data (binary content) |
+-----------------------------------------------+
| Padding (optional) |
+-----------------------------------------------+

Example: Sending a DATA Frame
Let's say you're the client, and you're sending an HTTP request for an image resource to
the server:
1. You initiate a new stream with the server and send a DATA frame with the following
structure:
o Frame Type: DATA
o Flags: END_STREAM (indicating that this is the last frame for the stream)
o Stream Identifier: 1 (assuming this is the first stream you've created)
o Payload: The binary content of the HTTP request, which includes the resource
URL, headers, and other request data.
o Padding: None in this case (PADDED flag is not set).
2. The server receives the DATA frame, processes the request, and responds with a
DATA frame of its own, containing the binary content of the image you requested.
The binary frame structure and multiplexing capabilities of HTTP/2.0 allow multiple
streams to be managed concurrently, optimizing data transmission and improving the
overall performance of web applications.
HTTPS (HTTP Secure)
SSL (Secure Sockets Layer):
1. Encryption: SSL was the original protocol designed for securing data transmission between
a client and a server. It uses encryption algorithms to ensure that data exchanged over the
network is encrypted, making it unreadable to any third parties intercepting the traffic.
2. Authentication: SSL also provides a level of authentication. It verifies that the server is
indeed the one it claims to be, helping to prevent man-in-the-middle attacks.
TLS (Transport Layer Security):
1. Encryption Standards: TLS builds upon SSL but uses more modern and secure encryption
standards. It has evolved to address vulnerabilities found in SSL.
2. Security: TLS is generally considered more secure and robust than SSL. It's the protocol
that is used to secure most HTTPS connections today.
3. Versions: SSL has multiple versions, including SSL 2.0 and SSL 3.0, which have known
security issues. TLS, on the other hand, has versions like TLS 1.0, TLS 1.1, TLS 1.2, and TLS
1.3, with each newer version improving security and performance. TLS 1.3, in particular,
focuses on minimizing latency.
In summary, HTTP/2.0 brings significant improvements over HTTP 1.x, including binary
framing, multiplexing, header compression, and server push. HTTPS, secured by SSL or TLS,
is vital for protecting data in transit, with TLS being the more secure and modern option
compared to SSL, due to its stronger encryption standards and better security practices.
HTTPS (HTTP Secure)
Exchange of Messages between Host and Server in HTTPs:
Client (Host): Your web browser, for example, Google Chrome.
Server: The web server hosting a website, such as an online shopping site like
"ExampleShop.com."
Message Exchange Steps in HTTPS:
1.Client Hello (TLS Handshake):
o Client: The client initiates the connection by sending a "Client Hello" message to
the server.
o Server: The server receives the "Client Hello" message and processes it.
2. Server Hello (TLS Handshake):
o Client: The client receives the "Server Hello" message and checks the server’s
certificate for authenticity. The certificate might be issued by a trusted Certificate
Authority (CA). If it's trusted, the client proceeds.
o Server: The server responds with a "Server Hello" message, which includes
information like the selected encryption protocol, a random number, and the
server's digital certificate.

HTTPS (HTTP Secure)
3. Key Exchange (TLS Handshake):
o Client: The client generates a random "pre-master secret" and encrypts it with
the server's public key (extracted from the server's certificate).
o Client: The client sends this encrypted "pre-master secret" to the server.
o Server: The server decrypts the "pre-master secret" using its private key.
4. Session Key Derivation (TLS Handshake):
o Both the client and server use the "pre-master secret" to independently derive a
shared "session key." This key is used for encrypting and decrypting the actual
data exchanged during the session.
5. Finished Messages (TLS Handshake):
o Both the client and server send "Finished" messages to confirm that they have
successfully established a secure connection.
o The "Finished" messages are encrypted using the shared session key, ensuring
that further communication will be secure.

HTTPS (HTTP Secure)
6. Data Exchange (HTTP Messages):
o With the secure TLS connection established, the client and server can exchange
data, such as HTTP requests and responses.
o Client: The client sends an HTTP request, such as requesting the homepage of
"ExampleShop.com."
o Server: The server receives the request, processes it, and sends back the
requested web page, along with an encrypted HTTP response.
7. Secure Data Exchange (TLS Encyption):

o All data exchanged between the client and server, including the web page content,
is encrypted using the shared session key.
o This encryption ensures that any data intercepted during transmission remains
unreadable to eavesdroppers.
8. End of Session:
o When the client has received the data it needs, it may choose to terminate the
session. The client and server exchange "goodbye" messages and close the
connection.

HTTPS (HTTP Secure)
Example Scenario:
Imagine you're shopping online on "ExampleShop.com." Your web browser establishes a
secure HTTPS connection with the server hosting the website. During the TLS
handshake, encryption keys are exchanged, ensuring that your sensitive information, such
as your payment details, remains confidential. When you make a purchase, your payment
details are encrypted and securely transmitted to the server, providing you with a safe and
private shopping experience.

Web caches (proxy server)
goal: satisfy client request without involving origin server
 user sets browser: Web
accesses via cache
 browser sends all HTTP proxy
HT
requests to cache TP
req server u est
HT ues P req
 object in cache: cache client TP
res
t H TT po n se
origin
pon res
returns object se HT
T P server
t
 else cache requests ues
req e
object from origin TT P o ns
p
H res
server, then returns HT TP
object to client
client origin
server

More about Web caching
 cache acts as both why Web caching?
client and server  reduce response time for
 server for original client request
requesting client
 client to origin server  reduce traffic on an
 typically cache is institution’s access link
installed by ISP  Internet dense with
(university, company, caches: enables “ poor”
residential ISP) content providers to
effectively deliver
content (so too does P2P
file sharing)

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
TCP control connection,
 FTP client contacts FTP server server port 21
at port 21, using TCP
 client authorized over control TCP data connection,
connection FTP server port 20 FTP
client server
 client browses remote
directory, sends commands
over control connection  server opens another TCP
data connection to transfer
 when server receives file another file
transfer command, server
opens 2nd TCP data connection  control connection: “out of
(for file) to client band”
 after transferring one file,  FTP server maintains “ state
server closes data connection ” : current directory, earlier
authentication

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

Scenario: Alice sends message to Bob
1) Alice uses UA to compose 4) SMTP client sends Alice’s
message “ to” message over the TCP
[email protected] connection
2) Alice’s UA sends message to 5) Bob’s mail server places the
her mail server; message message in Bob’s mailbox
placed in message queue 6) Bob invokes his user agent to
3) client side of SMTP opens read message
TCP connection with Bob’s
mail server
1 user mail user

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

DNS: domain name system
people: many identifiers: Domain Name System:
 SSN, name, passport #  distributed database
Internet hosts, routers: implemented in hierarchy of
 IP address (32 bit) - many name servers
used for addressing  application-layer protocol:
datagrams hosts, name servers
 “ name” , e.g., communicate to resolve
www.yahoo.com - names (address/name
used by humans translation)
 note: core Internet function,
Q: how to map between IP
implemented as application-
address and name, and
layer protocol
vice versa ?
 complexity at network’s
“ edge”
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

DNS: root name servers
 contacted by local name server that can not resolve name
 root name server:
 contacts authoritative name server if name mapping not known
 gets mapping
 returns mapping to local name server
c. Cogent, Herndon, VA (5 other sites)

d. U Maryland College Park, MD k. RIPE London (17 other sites)
h. ARL Aberdeen, MD
j. Verisign, Dulles VA (69 other sites ) i. Netnod, Stockholm (37 other sites)
m. WIDE Tokyo
e. NASA Mt View, CA (5 other sites)
f. Internet Software C.
Palo Alto, CA (and 48 other sites)
a. Verisign, Los Angeles CA 13 root name

(5 other sites)
b. USC-ISI Marina del Rey, CA
“servers” worldwide
l. ICANN Los Angeles, CA
(41 other sites)
g. US DoD Columbus,
OH (5 other sites)

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

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

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)

File distribution: client-server vs P2P
Question: how much time to distribute file (size F) from one server to N
peers?
 peer upload/download capacity is limited resource
us: server upload

capacity
u1 di: peer i download

file, size F us d1 u2 capacity
d2
server
di
uN network (with abundant
bandwidth) ui
dN
ui: peer i upload
capacity

File distribution time: client-server
 server transmission: must
sequentially send (upload) N F
us
file copies:
di
 time to send one copy: F/us
network
 time to send N copies: NF/us ui
 client: each client must

download file copy
 dmin = min client download rate
 min client download time: F/dmin
time to distribute F
to N clients using
Dc-s > max{NF/us,,F/dmin}
client-server approach
increases linearly in N
File distribution time: P2P
 server transmission: must
upload at least one copy F
us
 time to send one copy: F/us
di
 client: each client must network
download file copy ui
 min client download time: F/dmin
 clients: as aggregate must download NF bits
 max upload rate (limting max download rate) is us + ui
time to distribute F
DP2P
to N clients using > max{F/us,,F/dmin,,NF/(us + ui)}
P2P approach
increases linearly in N …
… but so does this, as each peer brings service capacity
Client-server vs. P2P: example
client upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us
3.5
P2P
Minimum Distribution Time
3
Client-Server
2.5
1.5
0.5
0
0 5 10 15 20 25 30 35
N
P2P file distribution: BitTorrent
 file divided into 256Kb chunks
 peers in torrent send/receive file chunks
tracker: tracks peers torrent: group of peers

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

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

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

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

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

Application Layer - Chapter - 2 - Version 7.1

Uploaded by

Copyright:

Available Formats

Application Layer - Chapter - 2 - Version 7.1

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 - Chapter - 2 - Version 7.1

Uploaded by

Copyright:

Available Formats

Chapter 2

A note on the use of these ppt slides: Computer

Application Layer 2-1

Application Layer 2-2

Application Layer 2-3

Application Layer 2-4

write programs that: physical

 run on (different) end systems

no need to write software for application

network-core devices transport

 applications on end systems

Application Layer 2-5

Application Layer 2-6

Application Layer 2-8

Application Layer 2-9

Application Layer 2-10

Application Layer 2-11

timing make use of whatever

Application Layer 2-12

application data loss throughput time sensitive

file transfer no loss elastic no

Application Layer 2-13

TCP service: UDP service:

e-mail SMTP [RFC 2821] TCP

Application Layer 2-15

Application Layer 2-16

host name path name

Application Layer 2-17

Application Layer 2-18

Application Layer 2-19

Application Layer 2-20

Application Layer 2-22

Application Layer 2-23

non-persistent HTTP persistent HTTP:

Application Layer 2-24

Application Layer 2-26

Application Layer 2-27

Application Layer 2-28

Application Layer 2-29

Application Layer 2-30

Example: A DATA Frame

Application Layer 2-32

Application Layer 2-35

Application Layer 2-36

7. Secure Data Exchange (TLS Encyption):

Application Layer 2-37

Application Layer 2-38

Application Layer 2-39

Application Layer 2-40

 transfer file to/from remote host

Application Layer 2-42

Application Layer 2-44

1 user mail user

sender’s mail receiver’s mail

 SMTP: delivery/storage to receiver’s server

Application Layer 2-46

com DNS servers org DNS servers edu DNS servers

pbs.org poly.edu umass.edu