9/18/2024

Application Layer
Recall / Basics
Computer Networking: A
Top-Down Approach
8th edition n
Jim Kurose, Keith Ross
Pearson, 2020
Application Layer: 2-1

Some network apps

 social networking  voice over IP (e.g., Skype)
 Web  real-time video conferencing
 text messaging (e.g., Zoom)
 e-mail  Internet search
 multi-user network games  remote login
 streaming stored video …
(YouTube, Hulu, Netflix)
 P2P file sharing

Application Layer: 2-2

1
 9/18/2024

Creating a network app

application
transport
write programs that: network
mobile network
data link
physical
 run on (different) end systems national or global ISP

 communicate over network

 e.g., web server software
communicates with browser software
local or
no need to write software for regional ISP

network-core devices home network content

application
 network-core devices do not run user transport
network
provider
network datacenter
applicationnetwork
applications data link
physical
transport
network

 applications on end systems allows data link

physical

for rapid app development, enterprise

propagation network

Application Layer: 2-3

Client-server paradigm
server: mobile network
 always-on host national or global ISP

 permanent IP address
 often in data centers, for scaling
clients: local or
regional ISP
 contact, communicate with server
 may be intermittently connected home network content
provider
 may have dynamic IP addresses network datacenter
network

 do not communicate directly with

each other
enterprise
 examples: HTTP, IMAP, FTP network

Application Layer: 2-4

2
 9/18/2024

Peer-peer architecture
 no always-on server mobile network
 arbitrary end systems directly national or global ISP

communicate
 peers request service from other
peers, provide service in return to
other peers local or
regional ISP
• self scalability – new peers bring new
service capacity, as well as new service home network content
demands provider
network datacenter

 peers are intermittently connected network

and change IP addresses

• complex management enterprise
 example: P2P file sharing [BitTorrent] network

Application Layer: 2-5

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

3
 9/18/2024

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
• two sockets involved: one on each side

application application
socket controlled by
process process app developer

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

Application Layer: 2-7

Addressing processes
 to receive messages, process  identifier includes both IP address
must have identifier and port numbers associated with
 host device has unique 32-bit process on host.
IP address  example port numbers:
 Q: does IP address of host on • HTTP server: 80
which process runs suffice for • mail server: 25
identifying the process?  to send HTTP message to
 A: no, many processes gaia.cs.umass.edu web server:
can be running on • IP address: 128.119.245.12
same host • port number: 80

Application Layer: 2-8

4
 9/18/2024

An application-layer protocol defines:

 types of messages exchanged, open protocols:
• e.g., request, response  defined in RFCs, everyone
 message syntax: has access to protocol
• what fields in messages & definition
how fields are delineated  allows for interoperability
 message semantics  e.g., HTTP, SMTP
• meaning of information in proprietary protocols:
fields
 e.g., Skype, Zoom
 rules for when and how
processes send & respond to
messages
Application Layer: 2-9

What transport service does an app need?

data integrity throughput
 some apps (e.g., file transfer,  some apps (e.g., multimedia)
web transactions) require require minimum amount of
100% reliable data transfer throughput to be “effective”
 other apps (e.g., audio) can  other apps (“elastic apps”)
tolerate some loss make use of whatever
throughput they get
timing
 some apps (e.g., Internet security
telephony, interactive games)  encryption, data integrity,
require low delay to be “effective” …
Application Layer: 2-10

5
 9/18/2024

Transport service requirements: common apps

application data loss throughput time sensitive?

file transfer/download 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, 10’s msec
video:10Kbps-5Mbps
streaming audio/video loss-tolerant same as above yes, few secs
interactive games loss-tolerant Kbps+ yes, 10’s msec
text messaging no loss elastic yes and no
Application Layer: 2-11

Internet transport protocols services

TCP service: UDP service:
 reliable transport between sending  unreliable data transfer
and receiving process between sending and receiving
 flow control: sender won’t process
overwhelm receiver  does not provide: reliability,
 congestion control: throttle sender flow control, congestion
when network overloaded control, timing, throughput
guarantee, security, or
 connection-oriented: setup required connection setup.
between client and server processes
 does not provide: timing, minimum Q: why bother? Why
throughput guarantee, security is there a UDP?
Application Layer: 2-12

6
 9/18/2024

Internet applications, and transport protocols

application
application layer protocol transport protocol

file transfer/download FTP [RFC 959] TCP

e-mail SMTP [RFC 5321] TCP
Web documents HTTP [RFC 7230, 9110] TCP
Internet telephony SIP [RFC 3261], RTP [RFC TCP or UDP
3550], or proprietary
streaming audio/video HTTP [RFC 7230], DASH TCP
interactive games WOW, FPS (proprietary) UDP or TCP

Application Layer: 2-13

Securing TCP
Vanilla TCP & UDP sockets: TLS implemented in
 no encryption application layer
 cleartext passwords sent into socket  apps use TLS libraries, that
traverse Internet in cleartext (!) use TCP in turn
Transport Layer Security (TLS)  cleartext sent into “socket”
 provides encrypted TCP connections traverse Internet encrypted
 data integrity  more: Chapter 8
 end-point authentication

Application Layer: 2-14

7
 9/18/2024

Thank You

Application Layer: 2-15

Application layer: overview

HTTP: hypertext transfer protocol

Application Layer: 2-16

8
 9/18/2024

Web and HTTP

First, a quick review…
 web page consists of objects, each of which can be stored on
different Web servers
 object can be HTML file, JPEG image, Java applet, audio file,…
 web page consists of base HTML-file which includes several
referenced objects, each addressable by a URL, e.g.,
www.someschool.edu/someDept/pic.gif

host name path name

Application Layer: 2-17

HTTP overview
HTTP: hypertext transfer protocol
 Web’s application-layer protocol
 client/server model: PC running
• client: browser that requests, Firefox browser
receives, (using HTTP protocol) and
“displays” Web objects
server running
• server: Web server sends (using Apache Web
HTTP protocol) objects in response server
to requests
iPhone running
Safari browser

Application Layer: 2-18

9
 9/18/2024

HTTP overview (continued)

HTTP uses TCP: HTTP is “stateless”
 client initiates TCP connection  server maintains no
(creates socket) to server, port 80 information about past client
 server accepts TCP connection requests
from client aside
protocols that maintain
 HTTP messages (application-layer “state” are complex!
protocol messages) exchanged
 past history (state) must be
between browser (HTTP client) and maintained
Web server (HTTP server)  if server/client crashes, their
 TCP connection closed views of “state” may be
inconsistent, must be reconciled

Application Layer: 2-19

HTTP connections: two types

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

Application Layer: 2-20

10
 9/18/2024

Non-persistent HTTP: response time

RTT (definition): time for a small

packet to travel from client to initiate TCP
server and back connection
RTT
HTTP response time (per object):
 one RTT to initiate TCP connection request file
 one RTT for HTTP request and first few RTT time to
transmit
bytes of HTTP response to return file
file received
 object/file transmission time

time time
Non-persistent HTTP response time = 2RTT+ file transmission time
Application Layer: 2-21

Persistent HTTP (HTTP 1.1)

Non-persistent HTTP issues: Persistent HTTP (HTTP1.1):
 requires 2 RTTs per object  server leaves connection open after
 OS overhead for each TCP sending response
connection  subsequent HTTP messages
 browsers often open multiple between same client/server sent
parallel TCP connections to over open connection
fetch referenced objects in  client sends requests as soon as it
parallel encounters a referenced object
 as little as one RTT for all the
referenced objects (cutting
response time in half)
Application Layer: 2-22

11
 9/18/2024

HTTP Request / Response messages

Application Layer: 2-23

HTTP request message: general format

method sp URL sp version cr lf request
line
header field name value cr lf
header
~
~ ~
~ lines

header field name value cr lf

cr lf

~
~ entity body ~
~ body

Application Layer: 2-24

12
 9/18/2024

Maintaining user/server state: cookies

a stateful protocol: client makes
Recall: HTTP GET/response two changes to X, or none at all
interaction is stateless
X
 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
t’
• all HTTP requests are independent of X’’
each other
• no need for client/server to “recover”
X’’
from a partially-completed-but-never-
time time
completely-completed transaction
Q: what happens if network connection or
client crashes at t’ ?
Application Layer: 2-25

Maintaining user/server state: cookies

Web sites and client browser use cookies to maintain some
state between transactions
User has explicit control over
whether or not cookies are
four components: allowed

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

Application Layer: 2-26

13
 9/18/2024

Maintaining user/server state: cookies

client
Amazon server
ebay 8734 usual HTTP request msg Amazon server
cookie file creates ID
usual HTTP response 1678 for user backend
create
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
time time Application Layer: 2-27

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

14
 9/18/2024

Example: displaying a NY Times web page

1 GET base html file
2
from nytimes.com

4 fetch ad from nytimes.com

5
AdX.com
HTTP 1 2 HTTP
7 display composed GET reply
page

3 4
6 5

NY times page with

embedded ad displayed AdX.com

Cookies: tracking a user’s browsing behavior

1634: sports, 2/15/22

nytimes.com (sports) “first party” cookie –

from website you chose
to visit (provides base
HTTP HTTP
GET reply html file)
Set cookie: 1634

HTTP GET
Referrer: NY Times Sports
4
7493: NY Times sports, 2/15/22
5
“third party” cookie – HTTP reply
from website you did not NY Times: 1634 Set cookie: 7493
choose to visit AdX: 7493
AdX.com

15
 9/18/2024

Cookies: tracking a user’s browsing behavior

1634: sports, 2/15/22

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

Cookies: tracking a user’s browsing behavior (one day later)

1634: sports, 2/15/22

1634: arts, 2/17/22

nytimes.com (arts)
socks.com HTTP HTTP
GET reply
cookie: 1634 Set cookie: 1634

HTTP GET
Referrer: nytimes.com, cookie: 7493
4
7493: NY Times sports, 2/15/22
5 7493: socks.com, 2/16/22
HTTP reply 7493: NY Times arts, 2/15/22
NY Times: 1634 Set cookie: 7493
AdX: 7493 Returned ad for socks!
AdX.com

16
 9/18/2024

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

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

17
 9/18/2024

HTTP Versions

Transport Layer: 3-35

HTTP/1.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-36

18
 9/18/2024

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

HTTP/3
 HTTP/3: adds security, per object error- and congestion-
control (more pipelining) over UDP

Application Layer: 2-38

19
 9/18/2024

Thank You

Application Layer: 2-39

20