Computer Networks
(CSE302)
[Link]
Assistant Professor/CSE/School of Computing
Progress Through Quality Education 1
Progress Through Quality Education 2
Progress Through Quality Education 3
Progress Through Quality Education 4
Progress Through Quality Education 5
Progress Through Quality Education 6
Progress Through Quality Education 7
HTTP connections: two types
Non-persistent HTTP Persistent HTTP
1. TCP connection opened TCP connection
2. at most one object sent opened to a server
over TCP connection
multiple objects
3. TCP connection closed
can be sent over
downloading multiple single TCP
objects required multiple connection
connections between client,
and that server
TCP connection
closed Application Layer: 2-8
Progress Through Quality Education 9
Progress Through Quality Education 10
Progress Through Quality Education 11
Progress Through Quality Education 12
Progress Through Quality Education 13
Progress Through Quality Education 14
Progress Through Quality Education 15
Progress Through Quality Education 16
Progress Through Quality Education 17
Progress Through Quality Education 18
Progress Through Quality Education 19
The G E T Method
▪G E T is used to request data from a specified
resource.
▪Note that the query string (name/value pairs) is
sent in the URL of a G E T request:
/test/demo_form.php?name1=value1&name2=val
ue2
• G E T requests can be cached
• G E T requests remain in the browser history
• G E T requests can be bookmarked
• G E T requests should never be used when dealing with sensitive
data
• G E T requests have length restrictions Transport
Layer: 3-20
Transport
Layer: 3-21
The POST 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:
[Link]
name1=value1&name2=value2
• POST requests are never cached
• POST requests do not remain in the browser history
Transport
• POST requests cannot be bookmarked Layer: 3-22
T ransport
Layer: 3-23
The PUT 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 HEAD Method
▪ The H EA D method is identical to G E T except that the
server M U ST NOT return a message-body in the response.
▪ The metainformation contained in the HTTP headers in
response to a H EA D request S H O U L D be identical to the
information sent in response to a G E T request.
▪ The H EA D method is used to ask only for information about a
document, not for the document itself.
▪ H E A D is much faster t han G E T , as a m u ch 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 l in k s for
validity, accessibilit y, and recent modification.
Transport
Layer: 3-25
▪ The DE L E T E 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 CO N N E C T 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
Progress Through Quality Education 27
Progress Through Quality Education 28
Progress Through Quality Education 29
Progress Through Quality Education 30
Maintaining user/server state: cookies
Recall: HTTP GET/response interaction a stateful protocol: client
is stateless makes two changes to X,
or none at all
no notion of multi-step exchanges of
HTTP messages to complete a Web X
“transaction”
• no need for client/server to track X
“state” of multi-step exchange
• all HTTP requests are
independent of each other X
’
• no need for client/server to t’
“recover” from a partially- X
completed-but-never-completely- ’’
completed transaction
X’’
time time
Q: what happens if network
connection or client crashes at t’ ?
Application Layer: 2-31
Maintaining user/server state: cookies
Web sites and client browser use Example:
cookies to maintain some state Susan uses browser on
between transactions laptop, visits specific e-
commerce site for first
four components: time
1) cookie header line of HTTP when initial HTTP requests
response message arrives at site, site creates:
2) cookie header line in next • unique ID (aka
“cookie”)
HTTP request message
• entry in backend
3) cookie file kept on user’s host, database for ID
managed by user’s browser • subsequent HTTP
4) back-end database at Web requests from Susan to
site this site will contain
cookie ID value, allowing
site to “identify” Susan
Application Layer: 2-32
Maintaining user/server state: cookies
client
Amazon server
ebay 8734 usual HTTP request Amazon server
cookie file msg creates ID
usual HTTP 1678 for usercreate backend
ebay 8734 response entry database
amazon set-cookie:
1678
1678
usual HTTP request
msg cookie- access
cookie: 1678 specific
usual HTTP action
response msg
one week later:
access
ebay 8734 usual HTTP request
amazon msg cookie-
1678
cookie: 1678 specific
usual HTTP action
time
response msg
time Application Layer: 2-33
HTTP cookies: comments
aside
What cookies can be cookies and privacy:
used for: cookies permit
authorization sites to learn a lot
about you on their
shopping carts site.
recommendations third party
user session state (Web e-mail) persistent cookies
Challenge: How to keep state? (tracking cookies)
at protocol endpoints: maintain allow common
state at sender/receiver over identity (cookie
multiple transactions value) to be
in messages: cookies in HTTP tracked across
messages carry state multiple web sites
Application Layer: 2-34
Example: displaying a NY Times web page
1 GET base html
2
file from
[Link]
4 fetch ad from [Link]
5
[Link]
HTT 1 2 HTT
7 display P P
GET repl
composed y
page
3 4
6 5
NY times page
with embedded [Link]
ad displayed
Cookies: tracking a user’s browsing behavior
1634: sports, 2/15/22
[Link] (sports) “first party”
cookie – from
website you chose
HTTP HTT
GET P to visit (provides
repl
Set cookie: base html file)
y 1634
HTTP GET
Referrer: NY Times
Sports
4
7493: NY Times sports, 2/15/22
5
“third party” HTTP
cookie – from reply
NY Times: 1634 Set cookie: 7493
website you did AdX: 7493
[Link]
not choose to visit
Cookies: tracking a user’s browsing behavior
1634: sports, 2/15/22
[Link] AdX:
tracks my web
[Link] browsing over sites
2
with AdX ads
HTT 1
P can return targeted
GET HTTP GET ads based on
Referrer: [Link],
cookie: 7493
4
browsing history
7493: NY Times sports, 2/15/22
5 7493: [Link], 2/16/22
HTTP
NY Times: 1634reply
Set cookie: 7493
AdX: 7493
[Link]
Cookies: tracking a user’s browsing behavior (one day later)
1634: sports, 2/15/22
1634: arts, 2/17/22
[Link] (arts)
[Link] HTTP HTT
GET P
cookie: 1634 repl
Set cookie:
y 1634
HTTP GET
Referrer: [Link],
cookie: 7493
4
7493: NY Times sports, 2/15/22
5 7493: [Link], 2/16/22
HTTP 7493: NY Times arts, 2/15/22
reply
Set
NY Times: 1634 cookie: 7493
[Link]
AdX: 7493Returned ad for socks!
Cookies: tracking a user’s browsing behavior
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
when cookies can identify an control over whether
individual, cookies are considered or not cookies are
personal data, subject to GDPR allowed
personal data regulations
Web caches
Goal: satisfy client requests without involving
origin server
user configures browser to
point to a (local) Web cache
Web
browser sends all HTTP cache
requests to cache client
origin
• if object in cache: cache server
returns object to client
• else cache requests object
from origin server, caches
received object, then
returns object to client client
Application Layer: 2-41
Web caches (aka proxy servers)
Web cache acts as both Why Web caching?
client and server
• server for original reduce response time for client
requesting client request
• client to origin server • 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
server tells cache deliver content
about object’s
allowable caching in
response header:
Application Layer: 2-42
Caching example
problem: large queueing delays at high utilization!
Scenario:
access link rate: 1.54 Mbps
RTT from institutional router to server: 2 origin
sec servers
web object size: 100K bits public
average request rate from browsers to Internet
origin servers: 15/sec
avg data rate to browsers: 1.50 Mbps
1.54 Mbps
Performance: access link
access link utilization = .97 institutional
LAN utilization: .0015 network
1 Gbps LAN
end-end delay = Internet delay +
access link delay + LAN delay
= 2 sec + minutes + usecs
Application Layer: 2-43
Option 1: buy a faster access link
Scenario: 154 Mbps
access link rate: 1.54 Mbps origin
RTT from institutional router to servers
server: 2 sec public
Internet
web object size: 100K bits
average request rate from
browsers to origin servers: 154 Mbps
15/sec 1.54 Mbps
access link
Performance:
access link utilization = .97 .0097 institutional
network
1 Gbps LAN
LAN utilization: .0015
end-end delay = Internet delay +
access link delay
+ LAN delay msec Cost: faster access link
= 2 sec + minutes s (expensive!) Application Layer: 2-44
+ usecs
Option 2: install a web cache
Scenario:
access link rate: 1.54 Mbps origin
RTT from institutional router to servers
server: 2 sec public
Internet
web object size: 100K bits
average request rate from
browsers to origin servers:
15/sec 1.54 Mbps
access link
avg data rate to browsers:
institutional
1.50 Mbps network
Performance: 1 Gbps LAN
LAN utilization: .? How to compute link
access link utilization = ? utilization, delay?
average end-end delay = ? local web cache
Cost: web cache (cheap!)
Application Layer: 2-45
Calculating access link utilization, end-
end delay with cache:
suppose cache hit rate is 0.4:
40% requests served by cache, with origin
low (msec) delay servers
public
60% requests satisfied at origin Internet
• 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 1.54 Mbps
access link
institutional
average end-end delay: network
= 0.6 * (delay from origin servers) 1 Gbps LAN
+ 0.4 * (delay when satisfied at cache)
= 0.6 (2.01) + 0.4 (~msecs) = ~ 1.2 secs
local web cache
lower average end-end delay than with 154 Mbps link (and cheaper
Application Layer: 2-46
Browser caching: Conditional GET
client server
Goal: don’t send object if browser
has up-to-date cached version HTTP request msg
object
• no object transmission delay (or If-modified-since:
<date> not
use of network resources)
modified
client: specify date of browser- HTTP response
before
HTTP/1.0
cached copy in HTTP request 304 Not Modified
<date>
If-modified-since: <date>
server: response contains no object
if browser-cached copy is up-to-
date: HTTP request msg
HTTP/1.0 304 Not Modified If-modified-since: object
<date> modified
HTTP response after
HTTP/1.0 200 OK <date>
<data>
Application Layer: 2-47
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
Application Layer: 2-48
HTTP/2
Key goal: decreased delay in multi-object
HTTP requests
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
Application Layer: 2-49
HTTP/2: mitigating HOL blocking
HTTP 1.1: client requests 1 large object (e.g., video file)
and 3 smaller objects
server
GET GET GET GET object data
O4 O3 O2
client O1 requested
O1
O2
O O3
1 O
2 O
O
O4
3
4
objects delivered in order requested: O2, O3, OApplication
4 Layer: 2-50
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
server
GET GET GET GET object data
O4 O3 O2
client O1 requested
O
2O
4 O O1
3
O2
O3
O
O4
1
O2, O3, O4 delivered quickly, O1
Application Layer: 2-52
slightly delayed
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