CS计算机代考程序代写 scheme javascript dns database chain Java file system distributed system cache FTP algorithm 3.Intro_Applications

3.Intro_Applications

Application Layer (Principles, Web,
Email)

Computer Networks and Applications

Week 2
COMP 3331/COMP 9331

Chapter 2, Sections 2.1-2.3

2. Application Layer: outline

2.1 principles of network
applications

2.2 Web and HTTP
2.3 electronic mail

§ SMTP
2.4 DNS

2.5 P2P applications
2.6 video streaming and

content distribution
networks (CDNs)

2.7 socket programming
with UDP and TCP

2. Application layer

our goals:
v conceptual,

implementation aspects
of network application
protocols
§ transport-layer

service models
§ client-server

paradigm
§ peer-to-peer

paradigm

v learn about protocols by
examining popular
application-level
protocols
§ HTTP
§ SMTP / POP3 / IMAP
§ DNS

v creating network
applications
§ socket API

Creating a network app
Write programs that:
v run on (different) end systems
v communicate over network
v e.g., web server software communicates

with browser software

No need to write software for network-
core devices

v network-core devices do not run user
applications

v applications on end systems allows for
rapid app development

application
transport
network
data link
physical

Interprocess Communication (IPC)

v Processes talk to each other through Inter-
process communication (IPC)

v On a single machine:
§ Shared memory

v Across machines:
§ We need other abstractions (message passing)

Shared
Segment

Interprocess Communication (IPC)

• In order to cooperate, need to communicate
• Achieved via IPC: interprocess communication

– ability for a process to communicate with another

• On a single machine:
– Shared memory

• Across machines:

– We need other abstractions (message passing)

Text

Data

Stack

Text

Data

Stack
P1 P2

Sockets
v process sends/receives messages to/from its socket
v socket analogous to door

§ sending process shoves message out through the door
§ sending process relies on transport infrastructure on other

side of door to deliver message to socket at receiving
process

v Application has a few options, OS handles the details

Internet

controlled
by OS

controlled by
app developer

transport

application

physical
link

network

process

transport

application

physical
link

network

process
socket

Addressing processes

v to receive messages,
process must have identifier

v host device has unique 32-
bit IP address

v Q: does IP address of host
on which process runs
suffice for identifying the
process?

v identifier includes both IP
address and port numbers
associated with process on
host.

v example port numbers:
§ HTTP server: 80
§ mail server: 25

v to send HTTP message to
cse.unsw.edu.au web server:
§ IP address: 129.94.242.51
§ port number: 80

§ A: no, many processes
can be running on same
host

Client-server architecture
server:
v Exports well-defined

request/response interface
v long-lived process that waits for

requests
v Upon receiving request, carries

it out

clients:
v Short-lived process that makes

requests
v “User-side” of application
v Initiates the communication

client/server

Client versus Server

v Server
§ Always-on host
§ Permanent IP address

(rendezvous location)
§ Static port conventions

(http: 80, email: 25,
ssh:22)

§ Data centres for scaling
§ May communicate with

other servers to respond

v Client
§ May be intermittently

connected
§ May have dynamic IP

addresses
§ Do not communicate

directly with each other

P2P architecture
v no always-on server

§ No permanent rendezvous
involved

v arbitrary end systems (peers)
directly communicate

v Symmetric responsibility (unlike
client/server)

v Often used for:
§ File sharing (BitTorrent)
§ Games
§ Blockchain and cryptocurrencies
§ Video distribution, video chat
§ In general: “distributed systems”

peer-peer

P2P architecture: Pros and Cons
+ 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

+ Speed: parallelism, less contention
+ Reliability: redundancy, fault tolerance
+ Geographic distribution

-Fundamental problems of decentralized
control

§ State uncertainty: no shared memory or
clock

§ Action uncertainty: mutually conflicting
decisions

-Distributed algorithms are complex

peer-peer

App-layer protocol defines
v types of messages

exchanged,
§ e.g., request, response

v message syntax:
§ what fields in messages

& how fields are
delineated

v message semantics
§ meaning of information

in fields
v rules for when and how

processes send & respond
to messages

open protocols:
v defined in RFCs
v allows for interoperability
v e.g., HTTP, SMTP,

WebRTC
proprietary protocols:
v e.g., Skype, Teams, Zoom

What transport service does an app need?

data integrity
v some apps (e.g., file transfer,

web transactions) require
100% reliable data transfer

v other apps (e.g., audio) can
tolerate some loss

timing
v some apps (e.g., Internet

telephony, interactive
games) require low delay
to be “effective”

throughput
v some apps (e.g.,

multimedia) require
minimum amount of
throughput to be
“effective”

v other apps (“elastic apps”)
make use of whatever
throughput they get

security
v encryption, data integrity,

…

Transport service requirements: common apps

application

file transfer
e-mail

Web documents
real-time audio/video

stored audio/video
interactive games

Chat/messaging

data loss

no loss
no loss
no loss
loss-tolerant

loss-tolerant
loss-tolerant
no loss

throughput

elastic
elastic
elastic
audio: 50kbps-1Mbps
video:100kbps-5Mbps
same as above
few kbps up
elastic

time sensitive

no
no
no
yes, 100’s msec

yes, few secs
yes, 100’s msec
yes and no

Internet transport protocols services

TCP service:
v reliable transport between

sending and receiving
process

v flow control: sender won’t
overwhelm receiver

v congestion control: throttle
sender when network
overloaded

v does not provide: timing,
minimum throughput
guarantee, security

v connection-oriented: setup
required between client and
server processes

UDP service:
v unreliable data transfer

between sending and
receiving process

v does not provide:
reliability, flow control,
congestion control,
timing, throughput
guarantee, security,
orconnection setup,

Q: why bother? Why
is there a UDP?

NOTE: More on transport later on 15

Internet apps: application, transport protocols

application

e-mail
remote terminal access

Web
file transfer

streaming multimedia

Internet telephony

application
layer protocol

SMTP [RFC 2821]
Telnet [RFC 854]
HTTP [RFC 2616]
FTP [RFC 959]
HTTP (e.g., YouTube),
RTP [RFC 1889]
SIP, RTP, proprietary
(e.g., Skype)

underlying
transport protocol

TCP
TCP
TCP
TCP
TCP or UDP

TCP or UDP

Quiz: Transport
Pick the true statement

A. TCP provides reliability and guarantees a minimum bandwidth

B. TCP provides reliability while UDP provides bandwidth
guarantees

C. TCP provides reliability while UDP does not

D. Neither TCP nor UDP provides reliability

Open a browser and type: www.zeetings.com/salil

Answer: C

2. Application Layer: outline

2.1 principles of network
applications
§ app architectures
§ app requirements

2.2 Web and HTTP
2.3 electronic mail

§ SMTP
2.4 DNS

2.5 P2P applications
2.6 video streaming and

content distribution
networks (CDNs)

2.7 socket programming
with UDP and TCP

The Web – Precursor
v 1967, Ted Nelson, Xanadu:

§ A world-wide publishing network that
would allow information to be stored
not as separate files but as connected
literature

§ Owners of documents would be
automatically paid via electronic
means for the virtual copying of their
documents

v Coined the term “Hypertext”Ted Nelson

The Web – History
v World Wide Web (WWW): a

distributed database of “pages” linked
through Hypertext Transport Protocol
(HTTP)
§ First HTTP implementation – 1990

• Tim Berners-Lee at CERN
§ HTTP/0.9 – 1991

• Simple GET command for the Web
§ HTTP/1.0 –1992

• Client/Server information, simple caching
§ HTTP/1.1 – 1996
§ HTTP2.0 – 2015

Tim Berners-Lee

http://info.cern.ch/hypertext/WWW/TheProject.html

Web and HTTP

First, a review…
v web page consists of objects
v object can be HTML file, JPEG image, Java applet,

audio file,…
v web page consists of base HTML-file which

includes several referenced objects
v each object is addressable by a URL, e.g.,

www.someschool.edu/someDept/pic.gif

host name path name

Web and HTTP

Hyperlink Example

Click the following link

CNN

Uniform Resource Locator (URL)

protocol://host-name[:port]/directory-path/resource

v protocol: http, ftp, https, smtp etc.
v hostname: DNS name, IP address
v port: defaults to protocol’s standard port; e.g. http: 80 https: 443
v directory path: hierarchical, reflecting file system
v resource: Identifies the desired resource

HTTP overview

HTTP: hypertext
transfer protocol

v Web’s application layer
protocol

v client/server model
§ client: browser that

requests, receives,
(using HTTP protocol)
and “displays” Web
objects

§ server: Web server
sends (using HTTP
protocol) objects in
response to requests

PC running
Firefox browser

server
running

Apache Web
server

iphone running
Safari browser

HTTP requestHTTP response

HT
TP

req
ues

HT
TP

res
pon

HTTP overview (continued)

uses TCP:
v client initiates TCP

connection (creates
socket) to server, port 80

v server accepts TCP
connection from client

v HTTP messages
(application-layer protocol
messages) exchanged
between browser (HTTP
client) and Web server
(HTTP server)

v TCP connection closed

HTTP is “stateless”
v server maintains no

information about
past client requests

protocols that maintain
“state” are complex!

v past history (state) must
be maintained

v if server/client crashes,
their views of “state”
may be inconsistent, must
be reconciled

aside

HTTP request message

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

§ ASCII (human-readable format)

request line
(GET, POST,
HEAD commands)

header
lines

carriage return,
line feed at start
of line indicates
end of header lines

GET /index.html HTTP/1.1\r\n
Host: www-net.cs.umass.edu\r\n
User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
Keep-Alive: 115\r\n
Connection: keep-alive\r\n
\r\n

carriage return character
line-feed character

HTTP response message

status line
(protocol
status code
status phrase)

header
lines

data, e.g.,
requested
HTML file

HTTP/1.1 200 OK\r\n
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
ETag: “17dc6-a5c-bf716880″\r\n
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 data data data data …

HTTP response status codes

200 OK
§ request succeeded, requested object later in this msg

301 Moved Permanently
§ requested object moved, new location specified later in this msg

(Location:)
400 Bad Request

§ request msg not understood by server

404 Not Found
§ requested document not found on this server

505 HTTP Version Not Supported
451 Unavailable for Legal Reasons
429 Too Many Requests
418 I’m a Teapot

v status code appears in 1st line in server-to-client response message.
v some sample codes:

HTTP is all text

v Makes the protocol simple
§ Easy to delineate messages (\r\n)
§ (relatively) human-readable
§ No issues about encoding or formatting data
§ Variable length data

v Not the most efficient
§ Many protocols use binary fields

• Sending “12345678” as a string is 8 bytes
• As an integer, 12345678 needs only 4 bytes

§ Headers may come in any order
§ Requires string parsing/processing

v Non-text content needs to be encoded
30

Request Method types (“verbs”)

HTTP/1.0:
v GET

§ Request page
v POST

§ Uploads user response to a
form

v HEAD
§ asks server to leave

requested object out of
response

HTTP/1.1:
v GET, POST, HEAD
v PUT

§ uploads file in entity body
to path specified in URL
field

v DELETE
§ deletes file specified in the

URL field
v TRACE, OPTIONS,

CONNECT, PATCH
§ For persistent connections

Uploading form input

POST method:
v web page often includes form input
v input is uploaded to server in entity body

Get (in-URL) method:
v uses GET method
v input is uploaded in URL field of request line:

www.somesite.com/animalsearch?monkeys&banana

User-server state: cookies
many Web sites use cookies
four components:

1) cookie header line of
HTTP response
message

2) cookie header line in
next HTTP request
message

3) cookie file kept on
user’s host, managed
by user’s browser

4) back-end database at
Web site

example:
v Susan always access Internet

from PC
v visits specific e-commerce

site for first time
v when initial HTTP requests

arrives at site, site creates:
§ unique ID
§ entry in backend

database for ID

Cookies: keeping “state” (cont.)

client server

usual http response msg

cookie file

one week later:

usual http request msg
cookie: 1678 cookie-

specific
action

access

ebay 8734 usual http request msg Amazon server
creates ID

1678 for user create
entry

usual http response
set-cookie: 1678ebay 8734

amazon 1678

usual http request msg
cookie: 1678 cookie-

specific
action

access
ebay 8734
amazon 1678

backend
database

The Dark Side of Cookies

v Cookies permit sites to learn a lot about you

v You may supply name and e-mail to sites (and more)

v 3rd party cookies (from ad networks, etc.) can follow you
across multiple sites
§ Ever visit a website, and the next day ALL your ads are from them ?

• Check your browser’s cookie file (cookies.txt, cookies.plist)
• Do you see a website that you have never visited

v You COULD turn them off
§ But good luck doing anything on the Internet !!

Third party cookies

Doubleclick server

Banner 1 url

Create cookie for
doubleclick: 3445

Banner 2 url

Cookie:3445

Website A Website B

For more, check the following link and follow
the references:
http://en.wikipedia.org/wiki/HTTP_cookie

36In practice the banner can be a single pixel (invisible to the user)

Performance of HTTP

Ø Page Load Time (PLT) as the metric
• From click until user sees page
• Key measure of web performance

Ø Depends on many factors such as
• page content/structure,
• protocols involved and
• Network bandwidth and RTT

Performance Goals

v User
§ fast downloads
§ high availability

v Content provider
§ happy users (hence, above)
§ cost-effective infrastructure

v Network (secondary)
§ avoid overload

Solutions?

v User
§ fast downloads
§ high availability

v Content provider
§ happy users (hence, above)
§ cost-effective infrastructure

v Network (secondary)
§ avoid overload

Improve HTTP to
achieve faster
downloads

Solutions?

v User
§ fast downloads
§ high availability

v Content provider
§ happy users (hence, above)
§ cost-effective delivery infrastructure

v Network (secondary)
§ avoid overload

Caching and Replication

Improve HTTP to
achieve faster
downloads

Solutions?

v User
§ fast downloads
§ high availability

v Content provider
§ happy users (hence, above)
§ cost-effective delivery infrastructure

v Network (secondary)
§ avoid overload

Caching and Replication

Exploit economies of scale
(Webhosting, CDNs, datacenters)

Improve HTTP to
achieve faster
downloads

How to improve PLT

Ø Reduce content size for transfer
• Smaller images, compression

Ø Change HTTP to make better use of available
bandwidth
• Persistent connections and pipelining

Ø Change HTTP to avoid repeated transfers of
the same content
• Caching and web-proxies

Ø Move content closer to the client
• CDNs

HTTP Performance
v Most Web pages have multiple objects

§ e.g., HTML file and a bunch of embedded images
v How do you retrieve those objects (naively)?

§ One item at a time
v New TCP connection per (small) object!

non-persistent HTTP
v at most one object sent over TCP connection

§ connection then closed
v downloading multiple objects required multiple

connections

Non-persistent HTTP: response time

RTT (definition): time for a
small packet to travel from
client to server and back

HTTP response time:
v one RTT to initiate TCP

connection
v one RTT for HTTP request

and first few bytes of HTTP
response to return

v file transmission time
v non-persistent HTTP

response time =
2RTT+ file transmission
time

time to
transmit
file

initiate TCP
connection

RTT
request
file

RTT

file
received

time time

Internet

2-45

HTTP/1.0
Ø Non-Persistent: One TCP

connection to fetch one web
resource

Ø Fairly poor PLT
Ø 2 Scenarios

• Multiple TCP connections
setups to the same server

• Sequential request/responses
even when resources are
located on different servers

Ø Multiple TCP slow-start
phases (more in lecture on
TCP)

HTTP

Improving HTTP Performance:
Concurrent Requests & Responses

v Use multiple connections in
parallel

v Does not necessarily
maintain order of responses R1

R2 R3

T2 T3

v What are potential downsides of parallel HTTP
connections, i.e., can opening too many parallel
connections be harmful and if so in what way?

v Answer: Extra load on the server for managing
parallel connections

Quiz: Parallel HTTP Connections

Open a browser and type: www.zeetings.com/salil

Persistent HTTP
v server leaves TCP connection

open after sending response
v subsequent HTTP messages

between same client/server are
sent over the same TCP
connection

v Allow TCP to learn more
accurate RTT estimate
(APPARENT LATER IN THE
COURSE)

v Allow TCP congestion window
to increase (APPARENT LATER)

v i.e., leverage previously
discovered bandwidth
(APPARENT LATER)

Persistent without pipelining:
v client issues new request only

when previous response has
been received

v one RTT for each referenced
object

Persistent with pipelining:
v introduced in HTTP/1.1
v client sends requests as soon as

it encounters a referenced
object

v as little as one RTT for all the
referenced objects

Persistent HTTP

HTTP 1.1: response time with
pipelining

initiate TCP
connection

RTT
request
file

RTT

file
received

time time

Internet

time to
transmit
file

Website with one
index page and three
embedded objects

How to improve PLT

Ø Reduce content size for transfer
• Smaller images, compression

Ø Change HTTP to make better use of available
bandwidth
• Persistent connections and pipelining

Ø Change HTTP to avoid repeated transfers of
the same content
• Caching and web-proxies

Ø Move content closer to the client
• CDNs

Improving HTTP Performance: Caching

Ø Why does caching work?
• Exploit locality of reference

Ø How well does caching work?
• Very well, up to a limit
• Large overlap in content
• But many unique requests

Ø Trend: increase in dynamic content
• For example, customization of web pages
• Reduces benefits of caching
• Some exceptions, for example, video content

Web caches (proxy server)

v user sets browser: Web
accesses via cache

v browser sends all HTTP
requests to cache
§ object in cache: cache

returns object
§ else cache requests

object from origin
server, then returns
object to client

goal: satisfy client request without involving origin server

client

proxy
server

client

HT
TP

req
ues

HT
TP

res
pon

HTTP request HTT
P re

que
st

origin
server

HTTP response HTT
P re

spo
nse

More about Web caching

v cache acts as both
client and server
§ server for original

requesting client
§ client to origin server

v typically, cache is
installed by ISP
(university, company,
residential ISP)

why Web caching?
v reduce response time

for client request
v reduce traffic on an

institution’s access link
v Internet dense with

caches: enables “poor”
content providers to
effectively deliver
content

Caching example:

origin
servers

public
Internet

institutional
network

1 Gbps LAN

1.54 Mbps
access link

assumptions:
v avg object size: 100K bits
v avg request rate from

browsers to origin
servers:15/sec

v avg data rate to browsers: 1.50
Mbps

v RTT from access router to any
origin server: 2 sec

v access link rate: 1.54 Mbps

consequences:
v LAN utilization: 0.15%
v access link utilization = 99%
v total delay = Internet delay +

access delay + LAN delay
= 2 sec + minutes + usecs

problem! 54

Access
Router

assumptions:
v avg object size: 100K bits
v avg request rate from

browsers to origin
servers:15/sec

v avg data rate to browsers: 1.50
Mbps

v RTT from access router to any
origin server: 2 sec

v access link rate: 1.54 Mbps

consequences:
v LAN utilization: 0.15%
v access link utilization = 99%
v total delay = Internet delay + access

delay + LAN delay
= 2 sec + minutes + usecs

Caching example: fatter access link

origin
servers

1.54 Mbps
access link

154 Mbps

msecs
Cost: increased access link speed (not cheap!)

0.99%

public
Internet

institutional
network

1 Gbps LAN

institutional
network

1 Gbps LAN

Caching example: install local cache

origin
servers

1.54 Mbps
access link

local web
cache

assumptions:
v avg object size: 100K bits
v avg request rate from

browsers to origin
servers:15/sec

v avg data rate to browsers: 1.50
Mbps

v RTT from access router to any
origin server: 2 sec

v access link rate: 1.54 Mbps

consequences:
v LAN utilization:
v access link utilization =
v total delay =

?
?

How to compute link
utilization, delay?

Cost: web cache (cheap!)

public
Internet

Caching example: install local cache

Calculating access link
utilization, delay with cache:

v suppose cache hit rate is 0.4
§ 40% requests satisfied at cache;

60% requests satisfied at origin

origin
servers

1.54 Mbps
access link

v access link utilization:
§ 60% of requests use access link

v data rate to browsers over access
link = 0.6*1.50 Mbps = .9 Mbps
§ utilization = 0.9/1.54 = .58

v total delay
§ = 0.6 * (delay from origin servers) +0.4

* (delay when satisfied at cache)
§ = 0.6 (2.01) + 0.4 (~msecs)
§ = ~ 1.2 secs
§ less than with 154 Mbps link (and

cheaper too!)

public
Internet

institutional
network

1 Gbps LAN

local web
cache

Conditional GET

v Goal: don’t send object if
cache has up-to-date
cached version
§ no object transmission

delay
§ lower link utilization

v cache: specify date of
cached copy in HTTP
request
If-modified-since:

v server: response contains
no object if cached copy
is up-to-date:
HTTP/1.0 304 Not
Modified

HTTP request msg
If-modified-since:

HTTP response
HTTP/1.0

304 Not Modified

object
not

modified
before

HTTP request msg
If-modified-since:

HTTP response
HTTP/1.0 200 OK

object
modified

after

client server

Example Cache Check Request

Example Cache Check Response

Etag: Usually used for dynamic content. The value is often a
cryptographic hash of the content.

Ø Replicate popular Web site across many machines
• Spreads load on servers
• Places content closer to clients
• Helps when content isn’t cacheable

Ø Problem:
• Want to direct client to a particular replica

• Balance load across server replicas
• Pair clients with nearby servers

• Expensive

Ø Common solution:
• DNS returns different addresses based on client’s geo-

location, server load, etc.

Improving HTTP Performance: Replication

Ø Caching and replication as a service
Ø Large-scale distributed storage infrastructure (usually)

administered by one entity
• e.g., Akamai has servers in 20,000+ locations

Ø Combination of (pull) caching and (push) replication
• Pull: Direct result of clients’ requests
• Push: Expectation of high access rate

Ø Also do some processing
• Handle dynamic web pages
• Transcoding

Improving HTTP Performance: CDN
More on this later

What about HTTPS?

Ø HTTP is insecure
Ø HTTP basic authentication: password sent using

base64 encoding (can be readily converted to
plaintext)

Ø HTTPS: HTTP over a connection encrypted by
Transport Layer Security (TLS)

Ø Provides:
• Authentication
• Bidirectional encryption

Ø Widely used in place of plain vanilla HTTP

Issues with HTTP

Ø Head of line blocking: “slow” objects delay later requests
• Example objects from remote storage vs from local memory

Ø Browsers often open multiple TCP connections for
parallel transfers
• Increases throughput and reduces impact of HOL blocking
• Increases load on servers and network

Ø HTTP headers are big
• Overheads higher for small objects

Ø Objects have dependencies, different priorities
• Javascript vs images
• Extra RTTs for “dependent” objects

Head of Line Blocking Example

What’s on the horizon: HTTP/2
Ø Google SPDY (speedy) -> HTTP/2: (RFC 7540 May 2015)
Ø Binary instead of text

• Efficient to parse, more compact and much less error-prone
Ø Responses are multiplexed over a single TCP connection

• Server can send response data whenever it is ready
• “Fast” objects can bypass “slow” objects – avoid HOL blocking
• Fewer handshakes, more traffic (helps congestion control)

Ø Multiplexing uses prioritized flow-controlled schemes
• Urgent responses can bypass non-critical responses

Ø Single TCP connection
Ø HTTP headers are compressed
Ø Push feature allows server to push embedded objects to

the client without waiting for request
• Saves RTT

More details: https://http2.github.io/faq/
Demo: http://www.http2demo.io

https://http2.github.io/faq/
http://www.http2demo.io/

Quiz: HTTP (1)
Consider an HTML page with a base file of size S0 bits and N inline
objects each of size S bits. Assume a client fetching the page across a
link of capacity C bits/s and RTT of D. How long does it take to download
the page using non-persistent HTTP (without parallelism)?

A. D + (S0 + NS)/C

B. 2D + (S0 + NS)/C

C. N(D + S/C)

D. 2D + S0/C + N(2D + S/C)

E. 2D + S0/C + N(D + S/C)

Open a browser and type: www.zeetings.com/salil

Answer: D
(see picture on next slide)

N=2

Quiz: HTTP (2)
Consider an HTML page with a base file of size S0 bits and N inline
objects each of size S bits. Assume a client fetching the page across a
link of capacity C bits/s and RTT of D. How long does it take to
download the page using persistent HTTP (without parallelism or
pipelining)?

A. 2D + (S0 + NS)/C

B. 3D + (S0 + NS)/C

C. N(D + S/C)

D. 2D + S0/C + N(2D + S/C)

E. 2D + S0/C + N(D + S/C)

Open a browser and type: www.zeetings.com/salil

Answer: E
(see picture on next slide)

N=2

Quiz: HTTP (3)
Consider an HTML page with a base file of size S0 bits and N inline
objects each of size S bits. Assume a client fetching the page across a
link of capacity C bits/s and RTT of D. How long does it take to
download the page using persistent HTTP with pipelining?

A. 2D + (S0 + NS)/C

B. 4D + (S0 + NS)/C

C. N(D + S/C)

D. 3D + S0/C + NS/C

E. 2D + S0/C + N(D + S/C)

Open a browser and type: www.zeetings.com/salil

Answer: D
(see picture on next slide)

N=2

Application Layer: outline

2.1 principles of network
applications
§ app architectures
§ app requirements

2.2 Web and HTTP
2.3 electronic mail

§ SMTP
2.4 DNS

2.5 P2P applications
2.6 video streaming and

content distribution
networks (CDNs)

2.7 socket programming
with UDP and TCP

Electronic mail

Three major components:
v user agents
v mail servers
v simple mail transfer

protocol: SMTP

User Agent
v a.k.a. “mail reader”
v composing, editing, reading

mail messages
v e.g., Outlook, Thunderbird,

iPhone mail client
v outgoing, incoming

messages stored on server

user mailbox

outgoing
message queue

mail
server

SMTP

user
agent

Electronic mail: mail servers

mail servers:
v mailbox contains incoming

messages for user
v message queue of outgoing

(to be sent) mail messages
v SMTP protocol between

mail servers to send email
messages
§ client: sending mail

server
§ “server”: receiving mail

server

mail
server

SMTP

user
agent

Electronic Mail: SMTP [RFC 2821]

v uses TCP to reliably transfer email message from
client to server, port 25

v direct transfer: sending server to receiving
server

v three phases of transfer
§ handshaking (greeting)
§ transfer of messages
§ closure

v command/response interaction (like HTTP, FTP)
§ commands: ASCII text
§ response: status code and phrase

v messages must be in 7-bit ASCII
76

user
agent

Scenario: Alice sends message to Bob

1) Alice uses UA to compose
message “to”

2) Alice’s UA sends message
to her mail server; message
placed in message queue

3) client side of SMTP opens
TCP connection with Bob’s
mail server

4) SMTP client sends Alice’s
message over the TCP
connection

5) Bob’s mail server places the
message in Bob’s mailbox

6) Bob invokes his user agent
to read message

mail
server

2 3 4
5

Alice’s mail server Bob’s mail server

user
agent

Sample SMTP interaction

S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: < >
S: 250 … Sender ok
C: RCPT TO: < >
S: 250 … 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

SMTP: final words

v SMTP uses persistent
connections

v SMTP requires message
(header & body) to be in
7-bit ASCII

v SMTP server uses
CRLF.CRLF to
determine end of message

comparison with HTTP:
v HTTP: pull
v SMTP: push

v both have ASCII
command/response
interaction, status codes

v HTTP: each object
encapsulated in its own
response msg

v SMTP: multiple objects
sent in multipart msg

Mail message format

SMTP: protocol for
exchanging email msgs

RFC 5322 (822,2822):
standard for text message
format (Internet Message
Format, IMF):

v header lines, e.g.,
§ To:
§ From:
§ Subject:
different from SMTP MAIL

FROM, RCPT TO:
commands!

v Body: the “message”
§ ASCII characters only

header

body

blank
line

Not on exam

Mail access protocols

v SMTP: delivery/storage to receiver’s server
v 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(S): Gmail, Yahoo! Mail, etc.

sender’s mail
server

SMTP SMTP
mail access

protocol

receiver’s mail
server

(e.g., POP,
IMAP)

user
agent

81
Read about POP and IMAP from the text in your own time

POP/IMAP Not on exam

Quiz: SMTP

Why do we have Sender’s mail server?
Ø User agent can directly connect with recipient mail server

without the need of sender’s mail server? What’s the catch?

ANSWER: TO ENSURE THAT THE MAIL CAN BE DELIVERED
IF THE RECEIVER’S MAIL SERVER IS DOWN MOMENTARILY

Open a browser and type: www.zeetings.com/salil

Quiz: SMTP

Why do we have a separate Receiver’s mail server?
Ø Can’t the recipient run the mail server on own end system?

ANSWER: THE RECIPIENT MAY NOT BE ALWAYS
CONNECTED

Open a browser and type: www.zeetings.com/salil

Summary

v Application Layer (Chapter 2)
§ Principles of Network Applications
§ HTTP
§ E-mail

v Next:
§ DNS
§ P2P

Reading Exercise for next week
Chapter 2: 2.4 – 2.7

Related Posts