Data Communication Networks

EEL3080

Lecture – 5 (Application Layer)

Prof. Manoj Choudhary

IIT Jodhpur
17 Jan 2022
Recap
Services, Layering and Encapsulation

application M application
Application exchanges messages to implement some
application service using services of transport layer
transport H
M
transport
Transport-layer protocolt transfers M (e.g., reliably) from
one process to another, using services of network layer
network network
▪ transport-layer protocol encapsulates
link application-layer message, M, with link
transport layer-layer header Ht to create a
transport-layer segment
physical • Ht used by transport layer protocol to physical
implement its service

source destination

Source: Kurose 3/41

Services, Layering and Encapsulation

application M application

transport H
M
transport
Transport-layer protocolt transfers M (e.g., reliably) from
one process to another, using services of network layer
network H H
network
M
n t
Network-layer protocol transfers transport-layer segment
link [Ht | M] from one host to another, using link layer services link
▪ network-layer protocol encapsulates
physical transport-layer segment [Ht | M] with physical
network layer-layer header Hn to create a
network-layer datagram
source • Hn used by network layer protocol to destination
implement its service
Source: Kurose 4/41
Services, Layering and Encapsulation

application M application

transport H
M
transport
t

network H H
network
M
n t
Network-layer protocol transfers transport-layer segment
link [Ht | M] from one host to another, using link layer services link
H H H
M
n t
Link-layer protocoll transfers datagram [Hn| [Ht |M] from
physical host to neighboring host, using physical-layer services physical
▪ link-layer protocol encapsulates network
datagram [Hn| [Ht |M], with link-layer header
source Hl to create a link-layer frame destination

Source: Kurose 5/41

Services, Layering and Encapsulation

application M application
M
message
transport H
M
transport
H
t M
t
segment
network H H H H
network
M M
n t n t
datagram
link H H H link
H H H M
M
l n t
l n t
frame
physical physical

source destination

Source: Kurose 6/41

 source
message M application
Encapsulation: an
segment
H
H H
M transport end-end view
t
datagram M network
H H
n H
t
frame M link
l n t physical
link
physical

switch

H H
destination M network
H H
n H
t H H
M application M link M
H l n t
M transport physical n t
H H
t
M network
H H
n H
t
M link router
l n t
physical
Source: Kurose 7/41
ISO/OSI reference model

Two layers not found in Internet

application
protocol stack!
presentation
▪ presentation: allow applications to
interpret meaning of data, e.g., encryption, session
compression, machine-specific conventions transport
▪ session: synchronization, checkpointing, network
recovery of data exchange link
▪ Internet stack “missing” these layers! physical
• these services, if needed, must be
implemented in application The seven layer OSI/ISO
reference model
• needed?
Source: Kurose 8/41
The OSI Reference Model

Source: Kurose 9/41

The TCP/IP Reference Model

Source: Kurose 10/41

The TCP/IP Reference Model

Protocols and networks in the TCP/IP model initially.

Source: Kurose 11/41

Application layer: overview

▪ P2P applications
▪ Principles of network ▪ video streaming and content
applications distribution networks
▪ Web and HTTP ▪ socket programming with
▪ E-mail, SMTP, IMAP UDP and TCP
▪ The Domain Name System
DNS

Source: Kurose 12/41

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, Netflix)
▪ P2P file sharing

Source: Kurose 13/41

Creating a network app

application
transport
write programs that: mobile network
network
data link

▪ run on (different) end systems

physical
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

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

▪ applications on end systems allows

data link
physical

for rapid app development, enterprise

propagation network

Source: Kurose 14/41

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
▪ examples: HTTP, IMAP, FTP
enterprise
network

Source: Kurose 15/41

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

Source: Kurose 16/41

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
Source: Kurose 17/41
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
proce socket proce controlled by
ss ss app developer

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

Source: Kurose 18/41

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
▪ more shortly…
Source: Kurose 19/41
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
Source: Kurose 20/41
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” …
Source: Kurose 21/41
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
Source: Kurose 22/41
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
throughput guarantee, security
Source: Kurose 23/41
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

Source: Kurose 24/41

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

Source: Kurose 25/41

HTTP overview

HTTP: hypertext transfer protocol

▪ Web’s application-layer protocol HT
▪ client/server model: PC running H
TP
que re
st
TTP
• client: browser that requests, Firefox browser res
pon
se
receives, (using HTTP protocol) and
“displays” Web objects e st
r equ
• server: Web server sends (using TP nse server running
HT po Apache Web
r es
HTTP protocol) objects in response HT
T P
server
to requests
iPhone running
Safari browser

Source: Kurose 26/41

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
▪ HTTP messages (application-layer protocols that maintain “state”
protocol messages) exchanged are complex!
▪ past history (state) must be
between browser (HTTP client) and maintained
Web server (HTTP server) ▪ if server/client crashes, their views
▪ TCP connection closed of “state” may be inconsistent, must
be reconciled

Source: Kurose 27/41

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

Source: Kurose 28/41

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
(process) at www.someSchool.edu on www.someSchool.edu waiting for TCP
port 80 connection at port 80 “accepts”
connection, notifying client
2. HTTP client sends HTTP
request message (containing
URL) into TCP connection 3. HTTP server receives request message,
socket. Message indicates forms response message containing
time that client wants object requested object, and sends message
someDepartment/home.index into its socket
Source: Kurose 29/41
Non-persistent HTTP: example (cont.)

User enters URL: www.someSchool.edu/someDepartment/home.index

(containing text, references to 10 jpeg images)

4. HTTP server closes TCP

5. HTTP client receives response connection.
message containing html file,
displays html. Parsing html file,
finds 10 referenced jpeg objects

6. Steps 1-5 repeated for

each of 10 jpeg objects
time

Source: Kurose 30/41

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
▪ obect/file transmission time

time time
Non-persistent HTTP response time = 2RTT+ file transmission time
Source: Kurose 31/41
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)
Source: Kurose 32/41
HTTP request message (Homework)

▪ two types of HTTP messages: request, response

▪ HTTP request message:
• ASCII (human-readable format)
carriage return character
line-feed character
request line (GET, POST,
GET /index.html HTTP/1.1\r\n
HEAD commands) Host: www-net.cs.umass.edu\r\n
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X
10.15; rv:80.0) Gecko/20100101 Firefox/80.0 \r\n
header Accept: text/html,application/xhtml+xml\r\n
lines Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
Connection: keep-alive\r\n
\r\n
carriage return, line feed
at start of line indicates
end of header lines * Check out the online interactive exercises for more
examples: http://gaia.cs.umass.edu/kurose_ross/interactive/
Source: Kurose 33/41
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

Source: Kurose 34/41

Other HTTP request messages (Homework)

POST method: HEAD method:

▪ web page often includes form ▪ requests headers (only) that
input would be returned if specified URL
▪ user input sent from client to were requested with an HTTP
server in entity body of HTTP GET method.
POST request message
PUT method:
▪ uploads new file (object) to server
GET method (for sending data to server): ▪ completely replaces file that exists
▪ include user data in URL field of HTTP at specified URL with content in
GET request message (following a ‘?’): entity body of POST HTTP request
www.somesite.com/animalsearch?monkeys&banana
message

Source: Kurose 35/41

HTTP response message

status line (protocol HTTP/1.1 200 OK

status code status phrase) Date: Tue, 08 Sep 2020 00:53:20 GMT
Server: Apache/2.4.6 (CentOS)
OpenSSL/1.0.2k-fips PHP/7.4.9
mod_perl/2.0.11 Perl/v5.16.3
header Last-Modified: Tue, 01 Mar 2016 18:57:50 GMT
lines ETag: "a5b-52d015789ee9e"
Accept-Ranges: bytes
Content-Length: 2651
Content-Type: text/html; charset=UTF-8
\r\n
data, e.g., requested data data data data data ...
HTML file

* Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/

Source: Kurose 36/41

HTTP response status codes (Homework)

▪ status code appears in 1st line in server-to-client response message.

▪ some sample codes:
200 OK
• request succeeded, requested object later in this message
301 Moved Permanently
• requested object moved, new location specified later in this message (in
Location: field)
400 Bad Request
• request msg not understood by server
404 Not Found
• requested document not found on this server
505 HTTP Version Not Supported
Source: Kurose 37/41
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
▪ no notion of multi-step exchanges of
X

lock data
HTTP messages to complete a Web record X
X
“transaction” OK
update X
• no need for client/server to track X’
X’
“state” of multi-step exchange OK
t’ update X
X’’
• all HTTP requests are independent of X’’
each other unlock X
OK

• no need for client/server to “recover”

OK X’’
from a
time time
partially-completed-but-never-complete
Q: what happens if network connection or
ly-completed transaction client crashes at t’ ?
Source: Kurose 38/41
Maintaining user/server state: cookies

Web sites and client browser use Example:

cookies to maintain some state ▪ Susan 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 Susan to this site will
managed by user’s browser contain cookie ID value,
4) back-end database at Web site allowing site to “identify”
Susan
Source: Kurose 39/41
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
time time
Source: Kurose 40/41
HTTP cookies: comments

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