CCS2201

Introduction to
Networks
Fall 2023-2024

Lecture #4
Principles of network applications,
Web and HTTP

1
 Application Layer
 Principles of network applications
 Web and HTTP
 E-mail, SMTP, IMAP
 The Domain Name System: DNS
 P2P applications
 video streaming, CDNs
 socket programming with UDP and TCP

2
 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 Q: your favorites?

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
 contact, communicate with server regional ISP

 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

4
 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 network

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

6
 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

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 studentportal.aast.edu web server:
can be running on • IP address: 128.119.245.12
same host • port number: 80
 more shortly…
8
 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
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” …
10
 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
11
 Internet transport protocols services
TCP service: UDP service:
 reliable transport between sending and  unreliable data transfer
receiving process between sending and receiving
 flow control: sender won’t overwhelm process
receiver  does not provide: reliability,
 congestion control: throttle sender when flow control, congestion
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?
12
 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 1.1 [RFC 7320] TCP
Internet telephony SIP [RFC 3261], RTP [RFC TCP or UDP
3550], or proprietary
streaming audio/video HTTP [RFC 7320], DASH TCP
interactive games WOW, FPS (proprietary) UDP or TCP

13
 Application Layer
 Principles of network applications
 Web and HTTP (part 1)
 E-mail, SMTP, IMAP
 The Domain Name System: DNS
 P2P applications
 video streaming, CDNs
 socket programming with UDP and TCP

14
 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

15 host name path name

 HTTP overview
HTTP: hypertext transfer protocol
 Web’s application-layer protocol
HT T
 client/server model: PC running
P re
que
st
HTT
• client: browser that requests, Firefox browser P re
spo
nse
receives, (using HTTP protocol) and
“displays” Web objects uest
req
• server: Web server sends (using HT
TP
p onse
server running
res Apache Web
HTTP protocol) objects in response HT
T P
server
to requests
iPhone running
Safari browser

16
 HTTP overview (continued)
HTTP uses TCP: HTTP is “stateless”
 client initiates TCP connection (creates  server maintains no information
socket) to server, port 80 about past client requests
 server accepts TCP connection from
client aside
 HTTP messages (application-layer protocols that maintain “state” are
protocol messages) exchanged between  complex!
past history (state) must be
browser (HTTP client) and Web server maintained
(HTTP server)  if server/client crashes, their views of
 TCP connection closed “state” may be inconsistent, must be
reconciled
17
 HTTP connections: two types
Non-persistent HTTP Persistent HTTP
1. TCP connection opened  TCP connection opened to a
2. at most one object sent over server
TCP connection  multiple objects can be sent
3. TCP connection closed over single TCP connection
between client, and that server
downloading multiple objects  TCP connection closed
required multiple connections

18
 Non-persistent HTTP: example
User enters URL: www.someSchool.edu/someDepartment/home.index
(containing text, references to 10 jpeg images)

1a. HTTP client initiates TCP

connection to HTTP server 1b. HTTP server at host www.someSchool.edu
(process) at www.someSchool.edu on waiting for TCP connection at port 80
port 80 “accepts” connection, notifying client

2. HTTP client sends HTTP request

message (containing URL) into 3. HTTP server receives request message,
TCP connection socket. Message forms response message containing
indicates that client wants object requested object, and sends message
time someDepartment/home.index into its socket

19
 Non-persistent HTTP: example (cont.)
User enters URL: www.someSchool.edu/someDepartment/home.index
(containing text, references to 10 jpeg images)

5. HTTP client receives response 4. HTTP server closes TCP

message containing html file, connection.
displays html. Parsing html file,
finds 10 referenced jpeg objects

6. Steps 1-5 repeated for

each of 10 jpeg objects
time

20
 Non-persistent HTTP: response time
RTT: Round Trip Time
RTT (definition): time for a small packet
to travel from client to server and back
HTTP response time (per object): initiate TCP
connection
 one RTT to initiate TCP connection
RTT
 one RTT for HTTP request and first few bytes
request file
of HTTP response to return
 obect/file transmission time RTT time to
transmit
file
file received

time time
Non-persistent HTTP response time = 2RTT+ file transmission time
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)
22
 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

23
 Other HTTP request messages
POST method: HEAD method:
 web page often includes form  requests headers (only)
input

PUT method:
 uploads new file (object) to server
GET method (for sending data to server):

24
25
 Maintaining user/server state: cookies
Web sites and client browser use Example:
cookies to maintain some state  Aly uses browser on laptop,
visits specific e-commerce site
between transactions for first time
four components:  when initial HTTP requests
1) cookie header line of HTTP response arrives at site, site creates:
message • unique ID (aka “cookie”)
• entry in backend database
2) cookie header line in next HTTP for ID
request message
• subsequent HTTP requests
3) cookie file kept on user’s host, from Aly to this site will
managed by user’s browser contain cookie ID value,
4) back-end database at Web site allowing site to “identify” Aly
26
 Maintaining user/server state: cookies
client
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
27 time time
 HTTP cookies: comments
aside
What cookies can be used for:
 authorization cookies and privacy:
 cookies permit sites to
 shopping carts
learn a lot about you on
 recommendations their site.
 user session state (Web e-mail)  third party persistent
cookies (tracking cookies)
allow common identity
Challenge: How to keep state? (cookie value) to be
 at protocol endpoints: maintain state at tracked across multiple
sender/receiver over multiple web sites
transactions
 in messages: cookies in HTTP messages
carry state
28
 Web caches
Goal: satisfy client requests without involving origin server
 user configures browser to
point to a (local) Web cache HT T
P re
Web
uest
que cache P re
q
 browser sends all HTTP client HT TP r
esp
st H T T
resp onse
origin
ons T P server
requests to cache est
e HT
u
• if object in cache: cache P req se
T T o n
H esp
returns object to client HT
TP
r

• else cache requests object

client
from origin server, caches
received object, then
returns object to client
29
 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

30
 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 institutional
queueing delays at network
 LAN utilization: .0015 high utilization!
1 Gbps LAN

 end-end delay = Internet delay +

access link delay + LAN delay
= 2 sec + minutes + usecs
31
 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
32Cost: faster access link (expensive!)
msecs
 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

33
 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)
+ 0.4 * (delay when satisfied at cache)
= 0.6 (2.01) + 0.4 (~msecs) = ~ 1.2 secs local web cache

34
lower average end-end delay than with 154 Mbps link (and cheaper too!)