0% found this document useful (0 votes)
20 views72 pages

Lec 02 Application Layer

Uploaded by

Najib Hasan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
20 views72 pages

Lec 02 Application Layer

Uploaded by

Najib Hasan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 72

Chapter 2

Application Layer

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


applications
2.2 Web and HTTP
2.3 FTP

Application Layer 2-2


Application layer
 This layer allows people to use the Internet
 Other 4 layers are just made so people can use application programs

07/31/2024
Internet applications

Application Application layer Transport protocol


protocol
E-mail SMTP TCP

Remote terminal access telnet TCP

Web HTTP TCP

File transfer FTP TCP

Streaming multimedia Proprietary TCP or UDP

Internet telephony Proprietary Typically UDP

07/31/2024
Application layer

07/31/2024
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
 network-core devices do not data link application
transport
physical

run user applications network


data link
physical
 applications on end systems
allows for rapid app
development, propagation

Application Layer 2-6


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

Application Layer 2-7


Client-server architecture
server:
 always-on host
 permanent IP address
 data centers for scaling

clients:
 communicate with server
client/server
 may be intermittently
connected
 may have dynamic IP
addresses
 do not communicate directly
with each other

Application Layer 2-8


P2P architecture
 no always-on server peer-peer
 arbitrary end systems
directly communicate
 peers request service from
other peers, provide service
in return to other peers
 self scalability – new
peers bring new service
capacity, as well as new
service demands
 peers are intermittently
connected and change IP
addresses
 complex management

Application Layer 2-9


Processes communicating
process: program running clients, servers
within a host client process: process that
 within same host, two initiates communication
processes communicate server process: process
using inter-process that waits to be contacted
communication (defined by
OS)
 processes in different hosts
communicate by  aside: applications with P2P
exchanging messages architectures have client
processes & server
processes

Application Layer 2-10


Sockets
 process sends/receives messages to/from its socket
 socket analogous to door
 sending process shoves message out door
 sending process relies on transport infrastructure on other
side of door to deliver message to socket at receiving
process

application application
socket controlled by
process process app developer

transport transport
network network controlled
link
by OS
link Internet
physical physical

Application Layer 2-11


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…

Application Layer 2-12


Network applications vs.
Application-layer protocols
 Network application: communicating, distributed
processes
 Processes running in different host communicate by an
application-layer protocol
• SMTP, HTTP..

 Application-layer protocols
 one piece of an application
 define messages exchanged by applications and & actions taken
 implementing services by using the service provided by lower
layers

07/31/2024
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

Application Layer 2-14


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
tolerate some loss “effective”
 other apps (“elastic apps”)
make use of whatever
timing
throughput they get
 some apps (e.g., Internet
telephony, interactive security
games) require low delay
 encryption, data integrity,
to be “effective”

Application Layer 2-15


Transport service requirements: common apps

application data loss throughput time sensitive

file transfer no loss elastic no


e-mail no loss elastic no
Web documents no loss elastic no
real-time audio/video loss-tolerant audio: 5kbps-1Mbps yes, 100’s msec
video:10kbps-5Mbps
stored audio/video loss-tolerant same as above yes, few secs
interactive games loss-tolerant few kbps up yes, 100’s msec
text messaging no loss elastic yes and no

Application Layer 2-16


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

Application Layer 2-17


Internet apps: application, transport protocols

application underlying
application layer protocol transport protocol

e-mail SMTP [RFC 2821] TCP


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

Application Layer 2-18


Chapter 2: outline

2.1 principles of network


applications
 app architectures
 app requirements
2.2 Web and HTTP
2.3 FTP

Application Layer 2-19


WWW
 World Wide Web
 Introduced in 1991
 originated from the CERN High-Energy Physics
laboratories in Geneva, Switzerland.

07/31/2024
The Web: Some Jargon
 Web page
 consists of objects (HTML file, JPEG image, GIF image…)
 addressed by URL
 Most Web pages consist of
 base HTML page
 several referenced objects
 URL
 A standard way of specifying the location of an object, typically
a web page, on the Internet
 User agent for Web is called a browser
 MS Internet Explorer
 Server for Web is called a Web server

07/31/2024
HyperText Transfer Protocol
 Web’s application layer protocol
 Used to access data on the World Wide Web
 Rapid jump from one document to another
 Client-server model
 client: browser that requests, receives, “displays” web objects
 server: Web server sends objects in response to request
 uses one TCP connection on the well-known port 80

07/31/2024
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

Application Layer 2-23


URL - continued

 method
 protocol used to retrieve the document (FTP, HTTP, …)
 host
 a computer where the info is located
 the name of the computer can be an alias (not necessary
www)
 port
 optional port # of the server
 path
 the path name of the file where the info is located
Figure 27.1 Architecture of WWW

27.25
Figure 27.2 Browser

27.26
27-2 WEB DOCUMENTS

The documents in the WWW can be grouped into three


broad categories: static, dynamic, and active. The
category is based on the time at which the contents of
the document are determined.

Topics discussed in this section:


Static Documents
Dynamic Documents
Active Documents

27.27
Figure 27.4 Static document

27.28
Figure 27.6 Effect of boldface tags

27.29
Figure 27.8 Dynamic document using CGI

27.30
Figure 27.9 Dynamic document using server-site script

27.31
HTTP overview
HTTP: hypertext transfer
protocol HT
 Web’s application layer TP
req
protocol PC running ues
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 nse
HT po running
objects P res
Apache Web
T
 server: Web server HT server
sends (using HTTP
protocol) objects in iphone running
response to requests Safari browser

Application Layer 2-32


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
 HTTP messages protocols that maintain
(application-layer protocol “state” are complex!
messages) exchanged
 past history (state) must be
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

Application Layer 2-33


HTTP connections
non-persistent HTTP
 at most one object sent over persistent
TCP connection
HTTP
 connection then closed  multiple objects can
be sent over
 downloading multiple objects required single
multiple
connections TCP connection
between client, server

Application Layer 2-34


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 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
Application Layer 2-35
Non-persistent HTTP (cont.)
4. HTTP server closes TCP
connection.
5. HTTP client receives response
message containing html file,
displays html. Parsing html file,
finds 10 referenced jpeg objects

time
6. Steps 1-5 repeated for each of 10
jpeg objects

Application Layer 2-36


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
RTT
response to return transmit
file
 file transmission time
file
 non-persistent HTTP received

response time =
2RTT+ file transmission time time
time

Application Layer 2-37


Non-persistent and persistent connections

Non-persistent Persistent
 HTTP/1.0  default for HTTP/1.1
 requires 2 RTTs per object  server leaves connection
 OS overhead for each open after sending
TCP connection response
 browsers often open  subsequent HTTP

parallel TCP connections messages between same


to fetch referenced objects client/server sent over
open connection
 Client sends requests for
all referenced objects as
soon as it receives base
HTML.
 Fewer RTTs and less slow
But most 1.0 browsers use
parallel TCP connections.
start.

2: Application Layer 2-38


Pipelining
 Issue multiple requests at a time
 Don’t have to wait for previous response
 More efficient use of link

 Use carefully
 POST requests should not be pipelined (changes server state)
 GET/HEAD requests are usually okay

39
Persistent HTTP
Non-persistent HTTP issues: Persistent without pipelining:
 Connection setup for each  Client issues new request only
request when previous response has
 But browsers often open been received
parallel connections  One RTT for each object

Persistent HTTP: Persistent with pipelining:


 Server leaves connection open  Default in HTTP/1.1 spec
after sending response  Client sends multiple requests
 Subsequent HTTP messages  As little as one RTT for all the
between same client/server referenced objects
are sent over connection  Server must handle responses in
same order as requests

40
“Persistent without pipelining”
most common
 When does pipelining work best?
 Small objects, equal time to serve each object
• Because pipelining simply removes additional 1 RTT delay to
request new content

 Head-of-line blocking: if big item is the first request, smaller


requests are stuck behind
• Could be issued as a parallel connection

41
HTTP – message format
 two types of messages: request & response
 ASCII (human-readable format)

07/31/2024
HTTP protocol – message format
 HTTP request message

HTTP 0.9
HTTP 1.0
HTTP 1.1

GET – when the client wants to retrieve a document


from the server
HEAD – when the client wants some info about a
document but not document itself
COPY – copies the file to another location

07/31/2024
Method types
HTTP/1.0: HTTP/1.1:
 GET  GET, POST, HEAD
 POST  PUT
 HEAD  uploads file in entity
 asks server to leave body to path specified
requested object out of in URL field
response  DELETE
 i.e. request info about a  deletes file specified in
doc the URL field

Application Layer 2-44


HTTP – message format
 HTTP response message
http://www.w3.org/Protocols/HTTP/HTRESP.html

explains the status code


in text form

200 OK – request succeeded


301 Moved Permanently – object
moved
400 Bad Request – not understood by
server

07/31/2024 404 Not Found – req. document not found


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

Application Layer 2-46


HTTP response status codes

27.47
HTTP – message format
 Headers
 exchange additional information between the client & the
server
 example
• doc in a special format
• extra info about document

07/31/2024
HTTP – message format- headers

Table 27.3 General headers

27.49
HTTP – message format

Table 27.4 Request headers 27.50


HTTP – message format
Table 27.5 Response headers

27.51
HTTP – message format
Table 27.6 Entity headers

27.52
HTTP messages – an example

This example retrieves a document.


We use the GET method to retrieve an image with the path/usr/bin/image1.
The request line shows the method (GET), the URL, and the HTTP version
(1.1).
The header has two lines that show that the client can accept images in GIF
and JPEG format.
07/31/2024
HTTP request message- example
 HTTP request message:

carriage return character


line-feed character
request line
(GET, POST, GET /index.html HTTP/1.1\r\n
HEAD commands) Host: www-net.cs.umass.edu\r\n
User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
headerAccept-Language: en-us,en;q=0.5\r\n
linesAccept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
carriage return, Keep-Alive: 115\r\n
line feed at start Connection: keep-alive\r\n
\r\n
of line indicates
end of header lines
Application Layer 2-54
HTTP response message
status line
(protocol
status code HTTP/1.1 200 OK\r\n
status phrase) Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n
Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 17:00:02
GMT\r\n
header ETag: "17dc6-a5c-bf716880"\r\n
Accept-Ranges: bytes\r\n
lines Content-Length: 2652\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html; charset=ISO-8859-1\
r\n
\r\n
data, e.g., data data data data data ...
requested
HTML file
Application Layer 2-55
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

Application Layer 2-56


User-server state: cookies
example:
many Web sites use cookies  Susan always access
four components: Internet from PC
1) cookie header line of  visits specific e-commerce
HTTP response site for first time
message  when initial HTTP requests
2) cookie header line in arrives at site, site creates:
next HTTP request  unique ID
message  entry in backend
3) cookie file kept on database for ID
user’s host, managed
by user’s browser
4) back-end database at
Web site
Application Layer 2-57
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
ebay 8734 usual http request msg
amazon 1678 cookie: 1678 cookie-
specific
usual http response msg action
Application Layer 2-58
Cookies (continued)
aside
what cookies can be used cookies and privacy:
for:  cookies permit sites to
 authorization learn a lot about you
 shopping carts  you may supply name and
 recommendations
e-mail to sites
 user session state (Web e-
mail)

how to keep “state”:


 protocol endpoints: maintain state at
sender/receiver over multiple transactions
 cookies: http messages carry state

Application Layer 2-59


Web caches (proxy server)
• HTTP supports Proxy servers
• Proxy server
• a computer that keeps copies of responses to recent requests
• Goal: satisfy a client’s request without involving the original server

proxy
 user sets browser: Web HT
TP u est
req server req
accesses via cache HT
client TP
ues
t H TTP
o nse
res p origin
 browser sends all HTTP pon P res
se T server
HT
requests to cache ues
t
req e
 object in cache: cache TT P
po ns
H es
returns object T TP
r
H
 else cache requests
object from origin client origin
server, then returns server
object to client
Application Layer 2-60
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)

Application Layer 2-61


Caching example:
assumptions:
 avg object size: 100K bits origin
 avg request rate from browsers to servers
origin servers:15/sec public
 avg data rate to browsers: 1.50 Mbps Internet
 RTT from institutional router to any
origin server: 2 sec
 access link rate: 1.54 Mbps
1.54 Mbps
consequences: access link
 LAN utilization: 15% problem! institutional
 access link utilization = 99% network
1 Gbps LAN
 total delay = Internet delay + access
delay + LAN delay
= 2 sec + minutes + usecs

Application Layer 2-62


Caching example: fatter access link
assumptions:
 avg object size: 100K bits origin
 avg request rate from browsers to servers
origin servers:15/sec public
 avg data rate to browsers: 1.50 Mbps Internet
 RTT from institutional router to any
origin server: 2 sec
 access link rate: 1.54 Mbps
15.4 Mbps 1.54 Mbps
15.4 Mbps
consequences: access link
 LAN utilization: 15% institutional
 access link utilization = 99% network
9.9% 1 Gbps LAN
 total delay = Internet delay + access
delay + LAN delay
= 2 sec + minutes + usecs
msecs
Cost: increased access link speed (not cheap!)
Application Layer 2-63
Caching example: install local cache
assumptions:
 avg object size: 100K bits origin
 avg request rate from browsers to servers
origin servers:15/sec public
 avg data rate to browsers: 1.50 Mbps Internet
 RTT from institutional router to any
origin server: 2 sec
 access link rate: 1.54 Mbps
1.54 Mbps
consequences: access link
 LAN utilization: 15% institutional
 access link utilization = 100% network
? 1 Gbps LAN
 total delay = Internet delay + access
?
delay + LAN delay local web
= 2 How to compute
sec + minutes + usecs link cache
utilization, delay?
Cost: web cache (cheap!)
Application Layer 2-64
Caching example: install local cache
Calculating access link
utilization, delay with origin
cache: servers
 suppose public
cache hit rate is 0.4 Internet
 40% requests satisfied at cache,
60% link
 access requests satisfied at origin
utilization:
 60% of requests use access link
 data rate to browsers over access link = 1.54 Mbps
0.6*1.50 Mbps = .9 Mbps access link
 utilization = 0.9/1.54 = .58 institutional
 total delay network
1 Gbps LAN
 = 0.6 * (delay from origin servers) +0.4
* (delay when satisfied at cache) local web
 = 0.6 (2.01) + 0.4 (~msecs) cache
 = ~ 1.2 secs
 less than with 15.4 Mbps link (and
cheaper too!)
Application Layer 2-65
Consistency of Web caching
 The major issue: How to maintain consistency?
 Two ways:
 Pull
• Web caches periodically pull the web server to see if a
document is modified
 Push
• Whenever a server gives a copy of a web page to a web cache,
they sign a lease with an expiration time; if the
web page is modified before the lease, the server notifies the
cache

07/31/2024
Conditional GET
client server
 Goal: don’t send object if
cache has up-to-date
cached version HTTP request msg
object
If-modified-since: <date>
 no object transmission not
delay modified
 lower link utilization HTTP response
before
HTTP/1.0
 cache: specify date of 304 Not Modified <date>
cached copy in HTTP
request
If-modified-since:
<date> HTTP request msg
 server: response contains If-modified-since: <date> object
no object if cached copy modified
HTTP response after
is up-to-date:
HTTP/1.0 200 OK <date>
HTTP/1.0 304 Not
Modified <data>
Application Layer 2-67
Chapter 2: outline

2.1 principles of network


applications
 app architectures
 app requirements
2.2 Web and HTTP
2.3 FTP

Application Layer 2-68


FTP: the file transfer protocol
file transfer
FTP FTP FTP
user client server
interface
user
at host remote file
local file system
system

 transfer file to/from remote host


 client/server model
 client: side that initiates transfer (either to/from remote)
 server: remote host
 ftp: RFC 959
 ftp server: port 21
Application Layer 2-69
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
 when server receives file data connection to transfer
transfer command, server another file
opens 2nd TCP data connection  control connection: “out of
(for file) to client band”
 after transferring one file,  FTP server maintains
server closes data connection “state”: current directory,
earlier authentication

Application Layer 2-70


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
 LIST return list of file in
 125 data
current directory connection
already open;
 RETR filename transfer starting
retrieves (gets) file  425 Can’t open
 STOR filename stores data connection
(puts) file onto remote  452 Error writing
host file

Application Layer 2-71


Thank You!

Application Layer 2-72

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy