Lecture 6

Chapter 2
Application Layer
Computer Networking: A
Top-Down Approach
8th Edition, Global Edition
Jim Kurose, Keith Ross
Copyright © 2022 Pearson Education
Ltd
Application Layer: 2-1
Internet protocol stack
application application
presentation
transport
session
network transport
link network
link
physical physical
The seven layer OSI/ISO
reference model
Introduction: 1-2
Internet protocol stack
▪ application: supporting network applications
• IMAP, SMTP, HTTP
application
▪ transport: process-process data transfer
(recognize source and dest processes for a
specific message) transport
• TCP, UDP
▪ network: routing of datagrams from source to network
destination
• IP, routing protocols link
▪ link: data transfer between neighboring physical
network elements
• Ethernet, 802.11 (WiFi), PPP
▪ physical: bits “on the wire”
Introduction: 1-3
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?
Introduction: 1-4
Application layer: overview
Our goals: ▪ learn about protocols by

▪ conceptual and examining popular
implementation aspects of application-layer protocols
application-layer protocols • HTTP
• transport-layer service • SMTP, IMAP
models • DNS
• client-server paradigm ▪ programming network
• peer-to-peer paradigm applications
• socket API

▪ Internet applications include:
• Text e-mail,
▪ Computer Network • Remote access to computers,
• Needless without Network applications • File transfers,
• Newsgroups.
• The driving force behind the Internet’s • The World Wide Web, encompassing Web
success surfing, search, and electronic commerce.
• Instant messaging and P2P file sharing,
• Voice over IP and video conferencing such as
Skype, Facetime, and Google Hangouts;
• User generated video such as YouTube and
movies on demand such as Netflix;
• Multiplayer online games such as Second Life
and World of Warcraft
• Social networking applications—such as
Facebook, Instagram, Twitter, and WeChat—
• Most recently, along with the arrival of the
smartphone, there has been a profusion of
location based mobile apps, including popular
check-in, Weather, and road-traffic forecasting
apps

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

Principles of Network Applications
As another example, in a P2P file-sharing system
there is a program in each host that participates
▪ writing programs that run on different end in the file-sharing community
systems and communicate with each other
application
over the network transport
mobile network
network
▪ For example, in the Web application there are data link
physical
national or global ISP
two distinct programs that communicate with
each other:
▪ The browser program running in the user’s
host (desktop, laptop, tablet, smartphone, and
so on); and
local or
▪ The Web server program running in the Web regional ISP
server host.
▪ They communicate with each other home network content
application provider
transport
network network datacenter
application
data link network
transport
physical network
data link
physical
enterprise
network Application Layer: 2-8
Network Application Architectures
▪ Before diving into software coding, you should have a broad architectural plan
for your application
▪ The application architecture will likely draw on one of the two predominant
architectural paradigms used in modern network applications:
➢ The client-server architecture
➢ The peer-to-peer (P2P) architecture

(Network Application Architectures)
Client-server paradigm mobile network
national or global ISP
server:
▪ always-on host
▪ permanent IP address
▪ often in data centers, for scaling
local or
regional ISP
clients:
▪ contact, communicate with server home network content
provider
▪ may be intermittently connected network datacenter
network
▪ may have dynamic IP addresses
▪ do not communicate directly with each other
▪ examples: HTTP, IMAP, FTP enterprise
network

Peer-Peer Architecture mobile network
▪ no always-on server national or global ISP
▪ arbitrary end systems directly communicate
▪ peers are intermittently connected and change
IP addresses
▪ example: P2P file sharing, BitTorrent
local or
▪ Internet telephony and video conference (e.g., regional ISP
Skype)
home network content
provider
network datacenter
network
enterprise
network

mobile network
Peer-Peer Architecture national or global ISP
▪ Advantages:
• Self scalability (new added system capable of providing
resources)
• Cost effective, since they normally don’t require
significant server infrastructure and server bandwidth local or
▪ Disadvantages: regional ISP
• Security, performance, and reliability due to their highly home network content
decentralized structure provider
network datacenter
network
enterprise
network

Processes Communicating
▪ Also before building a network application, you also need a basic
understanding of how the programs, running in multiple end systems,
communicate with each other.
▪ That program is called process
▪ Processes on two different end systems communicate by exchanging

messages across the computer network.
▪ A sending process creates and sends messages into the network;
▪ a receiving process receives these messages and possibly responds by
sending messages back

(Processes Communicating)
Client and Server Processes
▪ In the context of a communication session between a pair of processes, the process that
initiates the communication (that is, initially contacts the other process at the beginning
of the session) is labeled as the client. The process that waits to be contacted to begin
the session is the server.
The Interface Between the Process and the Computer Network
▪ A process sends messages into, and receives messages from, the network through a
software interface called a socket

Sockets
▪ Socket is the interface between the application process and the transport-layer protocol.
▪ 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

Addressing processes
▪ to receive messages, process
must have identifier
▪ host device has unique 32-bit
IP address
▪ Q: does IP address of host on
which process runs suffice for
identifying the process?

▪ to receive messages, process
must have identifier
▪ host device has unique 32-bit
IP address
▪ Q: does IP address of host on
which process runs suffice for
identifying the process?
▪ A: no, many processes
can be running on
same host
▪ 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
https://www.yzu.edu.tw/ web
▪ A: no, many processes
can be running on server:
same host • IP address: 140.138.2.104
• port number: 80 Application Layer: 2-18
Requirements for transport services of an app
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” …
Transport service requirements: common apps
application data loss Tolerance throughput time sensitive?
file transfer/download ? ? ?
e-mail ? ? ?
Web documents ? ? ?
real-time audio/video ? ? ?
?
streaming audio/video ? ? ?
interactive games ? ? ?
text messaging ? ? ?
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
Transport Services Provided by the Internet
TCP service: UDP service:

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
▪ does not provide: timing, minimum connection setup.
throughput guarantee, security
▪ connection-oriented: setup required Q: why bother? Why
between client and server processes is there a UDP?
Internet transport protocols services
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
Securing TCP
Vanilla TCP & UDP sockets: TSL implemented in
▪ no encryption application layer
▪ cleartext passwords sent into socket ▪ apps use TSL libraries, that
traverse Internet in cleartext (!) use TCP in turn
Transport Layer Security (TLS) TLS socket API
▪ provides encrypted TCP connections ▪ cleartext sent into socket
▪ data integrity traverse Internet encrypted
▪ end-point authentication ▪ see Chapter 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
▪ rules for when and how
processes send & respond to
messages
▪ 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

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
Each URL has two components: the hostname of the server that houses the object and the object’s path name.
HTTP overview
HTTP: hypertext transfer protocol
▪ Web’s application layer
protocol PC running
▪ client/server model: Firefox browser
• client: browser that requests,
receives, (using HTTP protocol) and
“displays” Web objects server running
Apache Web
• server: Web server sends (using server
HTTP protocol) objects in response
to requests iPhone running
Safari browser

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 “state”
▪ HTTP messages (application-layer 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 views
▪ TCP connection closed of “state” may be inconsistent,
must be reconciled

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

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

Non-persistent HTTP: response time
RTT (definition): time for a small
packet to travel from client to
server and back initiate TCP
connection
HTTP response time (per object): RTT
▪ one RTT to initiate TCP connection
request file
▪ one RTT for HTTP request and first few
RTT time to
bytes of HTTP response to return transmit
▪ object/file transmission time file received
file
time time
Non-persistent HTTP response time = 2RTT+ file transmission time
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)
HTTP request message
▪ two types of HTTP messages: request, response
▪ HTTP request message:
• ASCII (human-readable format)
request line (GET, POST,

HEAD commands)
header
lines
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/ Application Layer: 2-36
HTTP request message
▪ 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: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
header Accept-Language: en-us,en;q=0.5\r\n
lines Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
Keep-Alive: 115\r\n
Connection: keep-alive\r\n
carriage return, line feed \r\n
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/ Application Layer: 2-37
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

Other HTTP request messages
POST method: HEAD method:
▪ web page often includes form ▪ requests headers (only) that
input would be returned if specified
▪ user input sent from client to URL were requested with an
server in entity body of HTTP 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

HTTP response message
status line (protocol
status code status phrase)
header
lines
data, e.g., requested

HTML file
* Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/
status line (protocol HTTP/1.1 200 OK\r\n
status code status phrase) Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n
Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 17:00:02
GMT\r\n
header ETag: "17dc6-a5c-bf716880"\r\n
Accept-Ranges: bytes\r\n
lines Content-Length: 2652\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html; charset=ISO-8859-
1\r\n
\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/

HTTP response status codes
▪ 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
Trying out HTTP (client side) for yourself
1. Telnet to your favorite Web server:
telnet gaia.cs.umass.edu 80 ▪ opens TCP connection to port 80 (default HTTP server
port) at gaia.cs.umass. edu.
▪ anything typed in will be sent to port 80 at
gaia.cs.umass.edu
2. type in a GET HTTP request:
GET /kurose_ross/interactive/index.php HTTP/1.1
Host: gaia.cs.umass.edu
▪ by typing this in (hit carriage return twice), you send
this minimal (but complete) GET request to HTTP
server
3. look at response message sent by HTTP server!

(or use Wireshark to look at captured HTTP request/response)
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’ ?
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
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 Application Layer: 2-47
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
▪ protocol endpoints: maintain state at
web sites
sender/receiver over multiple transactions
▪ cookies: HTTP messages carry state

Lecture 6

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lecture 6

Uploaded by

Copyright:

Available Formats

Chapter 2

Our goals: ▪ learn about protocols by

Application Layer: 2-5

Application Layer: 2-6

Application Layer: 2-7

Application Layer: 2-9

Application Layer: 2-10

Application Layer: 2-11

Application Layer: 2-12

▪ Processes on two different end systems communicate by exchanging

Application Layer: 2-13

The Interface Between the Process and the Computer Network

Application Layer: 2-14

Application Layer: 2-15

Application Layer: 2-16

file transfer/download no loss elastic no

TCP service: UDP service:

Application Layer: 2-22

file transfer/download FTP [RFC 959] TCP

Application Layer: 2-25

Application Layer: 2-27

host name path name

Application Layer: 2-29

Application Layer: 2-30

Application Layer: 2-31

1a. HTTP client initiates TCP

4. HTTP server closes TCP

6. Steps 1-5 repeated for

Application Layer: 2-33

request line (GET, POST,

carriage return, line feed

header field name value cr lf

Application Layer: 2-38

Application Layer: 2-39

data, e.g., requested

Application Layer: 2-42

3. look at response message sent by HTTP server!

usual HTTP request msg

one week later:

Application Layer: 2-48

You might also like