Chapter 2

Application Layer

Application Layer: 2-1

Application layer: overview

▪ Principles of network
applications
▪ Web and HTTP
▪ Web Cache and HTTP/2
Web caches
Goal: satisfy client requests without involving origin server

▪ user configures browser to

point to a (local) Web cache HTT
P re
Web
q u est
que cache P re
▪ browser sends all HTTP client HTTP st T T e
H ons
resp
ons P resp origin
e TT server
requests to cache e st
H
u
• if object in cache: cache P req se
T T o n
H esp
r
returns object to client HT
TP

• else cache requests object

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

Application Layer: 2-4

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

▪ end-end delay = Internet delay +

access link delay + LAN delay
= 2 sec + minutes + usecs
Application Layer: 2-5
Caching example

Application Layer: 2-6

Caching example
Performance:
▪ access link utilization = .97

problem: large queueing delays at

high utilization!

ρ = Average incoming traffic load / Link capacity

If ρ < 0.6, queueing delay ≈ milliseconds (tiny compared to RTT).
If ρ ≈ 1, queueing delay dominates (seconds).

Application Layer: 2-7

Option 1: buy a faster access link
Scenario: 154 Mbps
▪ access link rate: 1.54 Mbps origin
▪ RTT from institutional router to server: 2 sec servers
▪ web object size: 100K bits public
Internet
▪ average request rate from browsers to origin
servers: 15/sec
▪ avg data rate to browsers: 1.50 Mbps 154 Mbps
1.54 Mbps
access link
Performance:
▪ access link utilization = .97 .0097 institutional
network
▪ LAN utilization: .0015 1 Gbps LAN

▪ end-end delay = Internet delay +

access link delay + LAN delay
= 2 sec + minutes + usecs
Cost: faster access link (expensive!) msecs
Application Layer: 2-8
Option 2: install a web cache
Scenario:
▪ access link rate: 1.54 Mbps origin
▪ RTT from institutional router to server: 2 sec servers
▪ web object size: 100K bits public
Internet
▪ average request rate from browsers to origin
servers: 15/sec
▪ avg data rate to browsers: 1.50 Mbps 1.54 Mbps
access link
Cost: web cache (cheap!)
institutional
network
Performance: 1 Gbps LAN

▪ LAN utilization: .? How to compute link

▪ access link utilization = ? utilization, delay?
▪ average end-end delay = ? local web cache

Application Layer: 2-9

Calculating access link utilization, end-end delay
with cache:
suppose cache hit rate is 0.4:
▪ 40% requests served by cache, with low origin
servers
(msec) delay public
▪ 60% requests satisfied at origin Internet

• rate to browsers over access link

= 0.6 * 1.50 Mbps = .9 Mbps
1.54 Mbps
• access link utilization = 0.9/1.54 = .58 means access link
low (msec) queueing delay at access link institutional
▪ average end-end delay: network
1 Gbps LAN
= 0.6 * (delay from origin servers + queuing
delay) + 0.4 * (delay when satisfied at cache)
= 0.6 (2sec + .01sec) + 0.4 (~msecs) = ~ 1.2 secs local web cache

lower average end-end delay than with 154 Mbps link (and cheaper too!)
Application Layer: 2-10
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
Browser caching: Conditional GET
client server
Goal: don’t send object if browser
HTTP request msg
has up-to-date cached version If-modified-since: <date> object
not
• no object transmission delay (or use modified
of network resources) HTTP response
before
HTTP/1.0
▪ client: specify date of 304 Not Modified <date>

browser-cached copy in HTTP

request
If-modified-since: <date> HTTP request msg
If-modified-since: <date> object
▪ server: response contains no modified
object if browser-cached copy is HTTP response after
HTTP/1.0 200 OK <date>
up-to-date: <data>
HTTP/1.0 304 Not Modified
Application Layer: 2-12
Content Delivery Network (CDN) – Self Study

https://www.cloudflare.com/learning/cdn/what-is-a-cdn/
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-14

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-15

HTTP/2: mitigating HOL blocking
HTTP 1.1: client requests 1 large object (e.g., video file) and 3 smaller
objects server

GET O4 GET O3 GET O

2 GET O1 object data requested
client

O1

O2
O1 O3
O2
O3
O4
O4

objects delivered in order requested: O2, O3, O4 wait behind O1 Application Layer: 2-16
HTTP/2: mitigating HOL blocking
HTTP/2: objects divided into frames, frame transmission interleaved
server

GET O4 GET O3 GET O

2 GET O1 object data requested
client
O2
O4
O3 O1

O2
O3
O1 O4

O2, O3, O4 delivered quickly, O1 slightly delayed

Application Layer: 2-17
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-18

References
▪ Computer Networking: A Top-Down Approach
▪ Chapter 2
▪ Why Web Cache? Example 1
▪ Why Web Cache? Example 2
▪ Why Web Cache? Example 3
▪ Content Delivery Network
▪ HTTP/2 vs HTTP/1.1
▪ HTTP/2 Explained
Thank You