Web and HTTP Protocol in computer networks

Progress Through Quality Education
Computer Networks
(CSE302)
Dr.P.Anu
Assistant Professor/CSE/School of Computing
1

Progress Through Quality Education 2

HTTP connections: two types
Non-persistent HTTP
1. TCP connection opened
2. at most one object sent
over TCP connection
3. TCP connection closed
downloading multiple
objects required multiple
connections
Persistent HTTP
TCP connection
opened to a server
multiple objects
can be sent over
single TCP
connection
between client,
and that server
TCP connection
closed Application Layer: 2-8

▪GET is used to request data from a specified
resource.
▪Note that the query string (name/value pairs) is
sent in the URL of a GET request:
/test/demo_form.php?name1=value1&name2=val
ue2
• GET requests can be cached
• GET requests remain in the browser history
• GET requests can be bookmarked
• GET requests should never be used when dealing with sensitive
data
• GET requests have length restrictions Transport
Layer: 3-20
The GET Method

▪POST is used to send data to a server to
create/update a resource.
▪The data sent to the server with POST is
stored in the request body of the HTTP
request:
▪POST
/test/demo_form.php
HTTP/1.1 Host:
www.sastra.edu
name1=value1&name2=value2
• POST requests are never cached
• POST requests do not remain in the browser history
• POST requests cannot be bookmarked
Transport
Layer: 3-22
The POST Method

▪ PUT is used to send data to a server to create/update a
resource.
▪ The difference between POST and PUT is that PUT
requests are idempotent.
▪ Calling the same PUT request multiple times will
always produce the same result.
▪ Calling a POST request repeatedly have side effects
of creating the same resource multiple times.
Transport
Layer: 3-24
The PUT Method

▪ The HEAD method is identical to GET except that the
server MUST NOT return a message-body in the response.
▪ The metainformation contained in the HTTP headers in
response to a HEAD request SHOULD be identical to the
information sent in response to a GET request.
▪ The HEAD method is used to ask only for information about a
document, not for the document itself.
▪ HEAD is much faster than GET, as a much smaller amount of
data is transferred.
▪ It's often used by clients who use caching, to see if the
document has changed since it was last accessed.
▪ If it was not, then the local copy can be reused, otherwise the
updated version must be retrieved with a GET.
▪ This method is often used for testing hypertext links for
validity, accessibility, and recent modification.
Transport
Layer: 3-25
The HEAD Method

▪ The DELETE Method - Deletes the specified resource.
▪
The PATCH Method - Partial modifications to a resource.
▪
The OPTIONS Method - Describes the communication
options for the target resource.
▪
The CONNECT Method - Used to start a two-way
communications (a tunnel) with the requested resource.
▪
The TRACE Method - Used to perform a message loop-back
test that tests the path for the target resource (useful for
debugging purposes).
Transport
Layer: 3-26

Maintaining user/server state: cookies
Recall: HTTP GET/response interaction
is stateless
 no notion of multi-step exchanges of
HTTP messages to complete a Web
“transaction”
• no need for client/server to track
“state” of multi-step exchange
• all HTTP requests are
independent of each other
• no need for client/server to
“recover” from a partially-
completed-but-never-completely-
completed transaction
a stateful protocol: client
makes two changes to X,
or none at all
time time
X
X
X
’
X
’’
X’’
t’
Q: what happens if network
connection or client crashes at t’ ?
Application Layer: 2-31

Web sites and client browser use
cookies to maintain some state
between transactions
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:
 Susan uses browser on
laptop, visits specific e-
commerce site for first
time
 when initial HTTP requests
arrives at site, site creates:
• unique ID (aka
“cookie”)
• entry in backend
database for ID
• subsequent HTTP
requests from Susan to
this site will contain
cookie ID value, allowing
site to “identify” Susan

client
Amazon server
usual HTTP
response msg
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 usercreate
entry
usual HTTP
response
set-cookie:
1678
ebay 8734
amazon
1678
usual HTTP request
msg
cookie: 1678
cookie-
specific
action
access
ebay 8734
amazon
1678
backend
database
time time Application Layer: 2-33

HTTP cookies: comments
What cookies can be
used for:
 authorization
 shopping carts
 recommendations
 user session state (Web e-mail)
cookies and privacy:
 cookies permit
sites to learn a lot
about you on their
site.
 third party
persistent cookies
(tracking cookies)
allow common
identity (cookie
value) to be
tracked across
multiple web sites
aside
Challenge: How to keep state?
 at protocol endpoints: maintain
state at sender/receiver over
multiple transactions
 in messages: cookies in HTTP
messages carry state

Example: displaying a NY Times web page
nytimes.com
AdX.com
1
HTT
P
GET
2 HTT
P
repl
y
4
3
5
6
NY times page
with embedded
ad displayed
GET base html
file from
nytimes.com
1
2
fetch ad from
AdX.com
4
5
display
composed
page
7

nytimes.com (sports)
AdX.com
1634: sports, 2/15/22
NY Times: 1634
7493: NY Times sports, 2/15/22
HTT
P
repl
y
Set cookie:
1634
4
HTTP GET
Referrer: NY Times
Sports
5
HTTP
reply
Set cookie: 7493
HTTP
GET
AdX: 7493
Cookies: tracking a user’s browsing behavior
“first party”
cookie – from
website you chose
to visit (provides
base html file)
“third party”
cookie – from
website you did
not choose to visit

nytimes.com
AdX.com
1634: sports, 2/15/22
NY Times: 1634
AdX: 7493
socks.com
1
HTT
P
GET
2
4
HTTP GET
Referrer: socks.com,
cookie: 7493
5
HTTP
reply
Set cookie: 7493
7493: socks.com, 2/16/22
AdX:
 tracks my web
browsing over sites
with AdX ads
 can return targeted
ads based on
browsing history

Cookies: tracking a user’s browsing behavior (one day later)
nytimes.com (arts)
AdX.com
1634: sports, 2/15/22
NY Times: 1634
AdX: 7493
socks.com
4
HTTP GET
Referrer: nytimes.com,
cookie: 7493
5
HTTP
reply
Set cookie: 7493
7493: socks.com, 2/16/22
cookie: 1634
HTT
P
repl
y
HTTP
GET
Set cookie:
1634
1634: arts, 2/17/22
7493: NY Times arts, 2/15/22
Returned ad for socks!

Cookies can be used to:
 track user behavior on a given website (first party
cookies)
 track user behavior across multiple websites (third
party cookies) without user ever choosing to visit
tracker site (!)
 tracking may be invisible to user:
• rather than displayed ad triggering HTTP GET to tracker,
could be an invisible link
third party tracking via cookies:
 disabled by default in Firefox, Safari browsers
 to be disabled in Chrome browser in 2023

GDPR (EU General Data Protection Regulation) and cookies
“Natural persons may be associated
with online identifiers […] such as
internet protocol addresses, cookie
identifiers or other identifiers […].
This may leave traces which, in
particular when combined with unique
identifiers and other information
received by the servers, may be used to
create profiles of the natural persons
and identify them.”
GDPR, recital 30 (May 2018)
User has explicit
control over whether
or not cookies are
allowed
when cookies can identify an
individual, cookies are considered
personal data, subject to GDPR
personal data regulations

Web caches
 user configures browser to
point to a (local) Web cache
 browser sends all HTTP
requests to cache
• if object in cache: cache
returns object to client
• else cache requests object
from origin server, caches
received object, then
returns object to client
Goal: satisfy client requests without involving
origin server
client
Web
cache
client
origin
server

Web caches (aka proxy servers)
 Web cache acts as both
client and server
• server for original
requesting client
• client to origin server
Why Web caching?
 reduce response time for client
request
• cache is closer to client
 reduce traffic on an institution’s
access link
 Internet is dense with caches
• enables “poor” content
providers to more effectively
deliver content
 server tells cache
about object’s
allowable caching in
response header:

Caching example
origin
servers
public
Internet
institutional
network
1 Gbps LAN
1.54 Mbps
access link
Performance:
 access link utilization = .97
 LAN utilization: .0015
 end-end delay = Internet delay +
access link delay + LAN delay
= 2 sec + minutes + usecs
Scenario:
 access link rate: 1.54 Mbps
 RTT from institutional router to server: 2
sec
 web object size: 100K bits
 average request rate from browsers to
origin servers: 15/sec
 avg data rate to browsers: 1.50 Mbps
problem: large queueing delays at high utilization!

Performance:
 access link utilization = .97
 LAN utilization: .0015
 end-end delay = Internet delay +
access link delay
+ LAN delay
= 2 sec + minutes
+ usecs
Option 1: buy a faster access link
origin
servers
public
Internet
institutional
network
1 Gbps LAN
1.54 Mbps
access link
Scenario:
 RTT from institutional router to
server: 2 sec
 average request rate from
browsers to origin servers:
15/sec
154 Mbps
154 Mbps
.0097
msec
s
Cost: faster access link
(expensive!) Application Layer: 2-44

Performance:
 LAN utilization: .?
 access link utilization = ?
 average end-end delay = ?
Option 2: install a web cache
origin
servers
public
Internet
institutional
network
1 Gbps LAN
1.54 Mbps
access link
Scenario:
 RTT from institutional router to
server: 2 sec
 average request rate from
browsers to origin servers:
15/sec
 avg data rate to browsers:
1.50 Mbps
How to compute link
utilization, delay?
Cost: web cache (cheap!)
local web cache

Calculating access link utilization, end-
end delay with cache:
origin
servers
public
Internet
institutional
network
1 Gbps LAN
1.54 Mbps
access link
local web cache
suppose cache hit rate is 0.4:
 40% requests served by cache, with
low (msec) delay
 60% requests satisfied at origin
• rate to browsers over access link
= 0.6 * 1.50 Mbps = .9 Mbps
• access link utilization = 0.9/1.54 = .58 means
low (msec) queueing delay at access link
 average end-end delay:
= 0.6 * (delay from origin servers)
+ 0.4 * (delay when satisfied at cache)
= 0.6 (2.01) + 0.4 (~msecs) = ~ 1.2 secs
lower average end-end delay than with 154 Mbps link (and cheaper

Browser caching: Conditional GET
Goal: don’t send object if browser
has up-to-date cached version
• no object transmission delay (or
use of network resources)
 client: specify date of browser-
cached copy in HTTP request
If-modified-since: <date>
 server: response contains no object
if browser-cached copy is up-to-
date:
HTTP/1.0 304 Not Modified
HTTP request msg
If-modified-since:
<date>
HTTP response
HTTP/1.0
304 Not Modified
object
not
modified
before
<date>
HTTP request msg
If-modified-since:
<date>
HTTP response
HTTP/1.0 200 OK
<data>
object
modified
after
<date>
client server

HTTP/2
Key goal: decreased delay in multi-object
HTTP requests
HTTP1.1: introduced multiple, pipelined GETs
over single TCP connection
 server responds in-order (FCFS: first-come-first-
served scheduling) to GET requests
 with FCFS, small object may have to wait for
transmission (head-of-line (HOL) blocking) behind
large object(s)
 loss recovery (retransmitting lost TCP segments)
stalls object transmission

HTTP/2
HTTP/2: [RFC 7540, 2015] increased flexibility at
server in sending objects to client:
 methods, status codes, most header fields
unchanged from HTTP 1.1
 transmission order of requested objects based on
client-specified object priority (not necessarily FCFS)
 push unrequested objects to client
 divide objects into frames, schedule frames to
mitigate HOL blocking
Key goal: decreased delay in multi-object
HTTP requests

HTTP/2: mitigating HOL blocking
HTTP 1.1: client requests 1 large object (e.g., video file)
and 3 smaller objects
client
server
GET
O1
GET
O2
GET
O3
GET
O4
O
1 O
2 O
3
O
4
object data
requested
O1
O2
O3
O4
objects delivered in order requested: O2, O3, O4

HoL
▪ Head-of-line (HoL) blocking occurs if there is a single
queue of data packets waiting to be transmitted, and the
packet at the head of the queue (line) cannot move forward
due to congestion, even if other packets behind this one
could.
▪ HTTP/2 (h2) solves the HOL issue by means of
multiplexing requests over the same TCP connection, so a
client can make multiple requests to a server without
having to wait for the previous ones to complete as the
responses can arrive in any order.
Transport
Layer: 3-51

HTTP/2: mitigating HOL blocking
HTTP/2: objects divided into frames, frame
transmission interleaved
client
server
GET
O1
GET
O2
GET
O3
GET
O4
O
2 O
4
object data
requested
O1
O2
O3
O4
O2, O3, O4 delivered quickly, O1
slightly delayed
O
3
O
1

HTTP/2 to HTTP/3
HTTP/2 over single TCP connection means:
 recovery from packet loss still stalls all
object transmissions
• as in HTTP 1.1, browsers have incentive to open
multiple parallel TCP connections to reduce
stalling, increase overall throughput
 no security over vanilla TCP connection
 HTTP/3: adds security, per object error- and
congestion-control (more pipelining) over
UDP
• more on HTTP/3 in transport layer Application Layer: 2-53

Web and HTTP Protocol in computer networks

More Related Content

Similar to Web and HTTP Protocol in computer networks

More from abhirudh456

Recently uploaded

Web and HTTP Protocol in computer networks