PowerPoint Presentation
Computer Systems
Application Layer
Dr. Mian M. Hamayun
m.m. .uk
Based on material and slides from
Computer Networking: A Top Down
Approach, 7th
Edition – Chapter 2
,
Pearson/
Slide #2 of 57
Lecture Objective
The objective of this lecture is to understand the
conceptual and implementation aspects of
network application protocols
Slide #3 of 57
Lecture Outline
Principles of Network Applications
Web & HTTP
Electronic Mail (SMTP)
Domain Name System (DNS)
Summary
Slide #4 of 57
Recap – Network Layers
Slide #5 of 57
Some Network Applications
E-Mail & Web
Text Messaging
Remote login (SSH, Telnet, …)
P2P File sharing (Bittorrents, …)
Multi-user network games
Streaming stored video (YouTube, Netflix, …)
Voice over IP (VoIP) (Skype, Hangouts, …)
Social Networking (Facebook, Twitter, …)
Search (Google, Yahoo, Bing, …)
…
Slide #6 of 57
Creating a Network Application
Write programs that:
run on (different) end systems
communicate over network
e.g., web server software
communicates with browser
software
No need to write software
for network-core devices
network-core devices do not run
user applications
applications on end systems
allows for rapid application
development, propagation
Slide #7 of 57
Network Application Architectures
Possible structure of network applications
Client Server
Peer-to-Peer (P2P)
Slide #8 of 57
Client-Server Architecture
Server
always-on host
permanent IP address
data centers for scaling
Clients
communicate with server
may be intermittently connected
may have dynamic IP addresses
do not communicate directly
with each other
Slide #9 of 57
P2P Architecture
No always-on server
Arbitrary end systems directly
communicate
Peers request service from other
peers, provide service in return to
other peers
Self-Scalability – new peers bring new
service capacity, as well as new
service demands
Peers are intermittently
connected and change IP
addresses
Complex management
Slide #10 of 57
Communicating Processes
Process: A program running within a host
within same host, two processes communicate using inter-process
communication (defined by OS)
processes in different hosts communicate by exchanging
messages
Client Process: A process that initiates communication
Server Process: A process that waits to be contacted
Applications with P2P architectures have both client
processes & server processes
Slide #11 of 57
Sockets – Process to Network Interface
A 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
Process
Socket
Slide #12 of 57
Sockets – Process to Network Interface
Slide #13 of 57
How do we Address Processes on a Host?
To receive messages, each
process must have an
identifier (!=PID)
Every host device has
unique 32-bit IP address
Q: Does IP address of host
on which process runs
suffice for identifying the
process?
No, many processes can be
running on same host!
Identifier includes both IP
address and port numbers
associated with process
on host.
Example port numbers:
HTTP server: 80
Mail server: 25
…
Slide #14 of 57
What Transport Services does an
Application Need?
Data Integrity
Some apps (e.g., file transfer, web transactions) require 100% reliable data
transfer
Other apps (e.g., audio) can tolerate some loss
Timing
Some apps (e.g., Internet telephony, interactive games) require low delay to
be “effective”
Throughput
Some apps (e.g., multimedia) require minimum amount of throughput to be
“effective”
Other apps (“elastic apps”) make use of whatever throughput they get
Security
Encryption, data integrity, …
Slide #15 of 57
Common Transport Services Requirements
Slide #16 of 57
Internet Transport Protocol Services – TCP
Reliable Transport between sending and receiving
process
Flow Control: sender won’t overwhelm receiver
Congestion Control: throttle sender when network
overloaded
Does not provide: timing, minimum throughput
guarantee, security
Connection-oriented: setup required between client and
server processes
Slide #17 of 57
Internet Transport Protocol Services – UDP
Unreliable data transfer between sending and receiving
process
Does not provide: reliability, flow control, congestion
control, timing, throughput guarantee, security, or
connection setup, …
Q: Why bother? Why is there a UDP?
Slide #18 of 57
Internet Applications – Transport Protocols
Slide #19 of 57
Web and HTTP
A web page consists of objects
An object can be HTML file, JPEG image, Java applet,
audio file, …
A web page consists of base HTML-file which includes
several referenced objects
Each object is addressable by a URL, e.g.,
www.someschool.edu/someDept/pic.gif
host name path name
Slide #20 of 57
HTTP Overview
HTTP: HyperText Transfer
Protocol
Web’s application layer
protocol
Client/Server model
Client: browser that requests,
receives, (using HTTP protocol)
and “displays” Web objects
Server: Web server sends (using
HTTP protocol) objects in
response to requests
PC running
Firefox browser
server
running
Apache Web
server
iphone running
Safari browser
HTTP requestHTTP response
HT
TP
re
qu
es
t
HT
TP
re
sp
on
se
Slide #21 of 57
HTTP Overview (cont’d)
HTTP uses TCP Protocol
Client initiates TCP connection (creates socket) to server,
port 80
Server accepts TCP connection from client
HTTP messages (application-layer protocol messages)
exchanged between browser (HTTP client) and Web
server (HTTP server)
TCP connection closed
HTTP is “stateless”
Server does not maintains information about past client
requests
Slide #22 of 57
Non-persistent HTTP – Example (1 of 2)
Suppose user enters URL:
www.someSchool.edu/someDepartment/home.index
(contains text,
references to 10
jpeg images)
1a. HTTP client initiates TCP
connection to HTTP server at
www.someSchool.edu on
port 80
1b. HTTP server at host
www.someSchool.edu
waiting for TCP connection
at port 80. “accepts”
connection, notifying client
2. HTTP client sends HTTP
request message (containing
URL) into TCP connection
socket. Message indicates
that client wants object
someDepartment/home.index
3. HTTP server receives
request message, forms
response message
containing requested object,
and sends message into its
socket
time
http://www.someSchool.edu/someDepartment/home.index
Slide #23 of 57
Non-persistent HTTP – Example (2 of 2)
time
4. HTTP server closes TCP
connection.
(waits until the response
message is received by the
client)
5. HTTP client receives response
message containing html file,
displays html. Parsing html
file, finds 10 referenced jpeg
objects
6. Steps 1-5 repeated for each
of the 10 jpeg objects
Slide #24 of 57
Non-persistent HTTP: Response Time
RTT: Round-Trip Time:
Time for a small packet to
travel from client to server
and back
HTTP response time:
One RTT to initiate TCP
connection
One RTT for HTTP request
and first few bytes of HTTP
response to return
File transmission time
Non-persistent HTTP
Response time = 2RTT+ file
transmission time
Slide #25 of 57
Persistent HTTP
Non-persistent HTTP issues:
Requires 2 RTTs per object
OS overhead for each TCP
connection
Browsers often open parallel
TCP connections to fetch
referenced objects
Persistent HTTP:
Server leaves connection
open after sending response
Subsequent HTTP
messages between same
client/server sent over open
connection
Client sends requests as
soon as it encounters a
referenced object
As little as one RTT for all
the referenced objects
Slide #26 of 57
HTTP Request Message
ASCII (Human-readable format)
GET /somedir/page.html HTTP/1.1 \r\n
Host: www.someschool.edu \r\n
Connection: close \r\n
User-agent: Mozilla/5.0 \r\n
Accept-language: fr \r\n
\r\n
request line
(GET, POST,
HEAD commands)
carriage return,
line feed at start
of line indicates
end of header lines
carriage return character
line-feed character
header
lines
http://www.someschool.edu/
Slide #27 of 57
HTTP Request Message: General Format
Slide #28 of 57
HTTP Response Message
ASCII (Human-readable format)
HTTP/1.1 200 OK\r\n
Connection: close\r\n
Date: Tue, 09 Aug 2011 15:44:04 GMT\r\n
Server: Apache/2.2.3 (CentOS)\r\n
Last-Modified: Tue, 09 Aug 2011 15:11:03 GMT\r\n
Content-Length: 6821\r\n
Content-Type: text/html\r\n
\r\n
data data data data data …
status line
(protocol,
status code,
status phrase)
header
lines
Data, e.g.
requested HTML file
Slide #29 of 57
HTTP Response Message: General Format
Slide #30 of 57
HTTP Response Status Codes
Status code appears in 1st line in server-to-client
response message.
Some sample codes are:
200 OK
request succeeded, requested object later in this msg
301 Moved Permanently
requested object moved, new location specified later in this msg
(Location:)
400 Bad Request
request message not understood by server
404 Not Found
requested document not found on this server
505 HTTP Version Not Supported
Slide #31 of 57
Electronic Mail
Three major components
User Agents
Mail Servers
Simple Mail Transfer
Protocol (SMTP)
User Agent
a.k.a “Mail Reader”
composing, editing, reading mail
messages
e.g., Outlook, Thunderbird,
iPhone mail client
outgoing, incoming messages
stored on server
Slide #32 of 57
Electronic Mail
Mail Servers
mailbox contains incoming
messages for user
message queue of outgoing (to
be sent) mail messages
SMTP protocol between mail
servers to send email messages
client: sending mail server
“server”: receiving mail server
Slide #33 of 57
Electronic Mail : SMTP
Uses TCP to reliably transfer email message from client
to server, port 25
Direct transfer: sending server to receiving server
Three phases of transfer
handshaking (greeting)
transfer of messages
closure
Command/Response interaction (like HTTP, FTP)
Commands: ASCII text
Response: status code and phrase
Messages must be in 7-bit ASCII
Slide #34 of 57
Scenario: Alice sends message to Bob
1) Alice uses UA to compose
message “to”
2) Alice’s UA sends message to
her mail server; message
placed in message queue
3) client side of SMTP opens
TCP connection with Bob’s
mail server
4) SMTP client sends Alice’s
message over the TCP
connection
5) Bob’s mail server places the
message in Bob’s mailbox
6) Bob invokes his user agent
to read message
Slide #35 of 57
Sample SMTP Interaction
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: < >
S: 250 … Sender ok
C: RCPT TO: < >
S: 250 … Recipient ok
C: DATA
S: 354 Enter mail, end with “.” on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection
Slide #36 of 57
Try SMTP Interaction for Yourself
telnet servername 25
see 220 reply from server
enter HELO, MAIL FROM, RCPT TO, DATA, QUIT
commands
The above lets you send email without using email client!
Slide #37 of 57
SMTP: Final Words
SMTP uses persistent
connections
SMTP requires message
(header & body) to be in 7-
bit ASCII
SMTP server uses
CRLF.CRLF to determine
end of message
Comparison with HTTP:
HTTP: pull
SMTP: push
Both have ASCII
command/response
interaction, status codes
HTTP: each object
encapsulated in its own
response message
SMTP: multiple objects
sent in multipart messages
Slide #38 of 57
Mail Access Protocols
SMTP: delivery/storage to receiver’s server
mail access protocol: retrieval from server
POP: Post Office Protocol [RFC 1939]: authorization, download
IMAP: Internet Mail Access Protocol [RFC 1730]: more features,
including manipulation of stored message on server
HTTP: gmail, Hotmail, Yahoo! Mail, etc.
Slide #39 of 57
Authorization phase
client commands:
user: declare username
pass: password
server responses
+OK
-ERR
S: +OK POP3 server ready
C: user bob
S: +OK
C: pass hungry
S: +OK user successfully logged on
C: list
S: 1 498
S: 2 912
S: .
C: retr 1
S:
S: .
C: dele 1
C: retr 2
S:
S: .
C: dele 2
C: quit
S: +OK POP3 server signing off
POP3 Protocol
Transaction phase,
client:
list: list message numbers
retr: retrieve message by
number
dele: delete
quit
Slide #40 of 57
POP3 and IMAP
More about POP3
Previous example uses
POP3 “download and
delete” mode
Bob cannot re-read e-mail if
he changes client
POP3 “download-and-
keep”: copies of
messages on different
clients
POP3 is stateless
across sessions
IMAP
Keeps all messages in
one place: at server
Allows user to organize
messages in folders
Keeps user state
across sessions:
Names of folders and
mappings between
message IDs and folder
name
Slide #41 of 57
DNS: Domain Name System
The Internet’s Directory Service
People have many identifiers:
SSN, name, passport #
Internet hosts, routers:
IP address (32 bit) – used for addressing datagrams
“name”, e.g., www.yahoo.com – used by humans
Q: How to map between IP address and name, and vice
versa ?
Slide #42 of 57
DNS: Domain Name System
The Internet’s Directory Service
DNS is a distributed database implemented in hierarchy
of many name servers
Application-layer protocol: hosts, name servers
communicate to resolve names (address/name
translation)
Note: DNS is a core Internet function and it is implemented as an
application-layer protocol
Complexity at network’s “edge”
Slide #43 of 57
DNS: Services & Structure
DNS services
hostname to IP address
translation
host aliasing
canonical, alias names
mail server aliasing
load distribution
replicated Web servers: many
IP addresses correspond to
one name
Why not centralize DNS?
single point of failure
traffic volume
distant centralized database
maintenance
A: Doesn’t scale!
Slide #44 of 57
DNS: A Distributed Hierarchical Database
Client wants IP for www.amazon.com; 1st
approx
client queries root server to find com DNS server
client queries .com DNS server to get amazon.com DNS server
client queries amazon.com DNS server to get IP address for
www.amazon.com
Top-Level Domain
(TLD) DNS servers
Authoritative DNS
Servers
http://www.amazon.com/
Slide #45 of 57
DNS: Root Name Servers
There are 13 root DNS servers (labelled A to M) worldwide
Each “server” is actually a network of replicated servers
Slide #46 of 57
DNS: TLD & Authoritative Servers
Top-level Domain (TLD) servers:
Responsible for com, org, net, edu, gov and all top-level country
domains, e.g.: uk, fr, ca, jp
Verisign Global Registry Services maintains the TLD servers for the
com top-level domain.
Educause for .edu TLD
Authoritative DNS servers:
Organization’s own DNS server(s), providing authoritative hostname
to IP mappings for organization’s named hosts
Can be maintained by organization or service provider
Slide #47 of 57
DNS: Local DNS Name Server
Does not strictly belong to hierarchy
Each ISP (residential ISP, company, university) has
its own local DNS server
Also called “default name server”
When a host makes DNS query, the query is sent to
its local DNS server
Has local cache of recent name-to-address translation pairs
(but may be out of date!)
Acts as proxy, forwards query into hierarchy
Slide #48 of 57
DNS: Name Resolution Example
host at cis.poly.edu wants
IP address for
gaia.cs.umass.edu
Iterated Query:
Contacted server replies
with name of server to
contact
“I don’t know this name, but
ask this server”
Slide #49 of 57
DNS: Name Resolution Example
host at cis.poly.edu wants
IP address for
gaia.cs.umass.edu
Recursive Query:
Puts burden of name
resolution on contacted
name server
Heavy load at upper levels
of hierarchy?
Slide #50 of 57
DNS: Caching & Updating Records
Once (any) name server learns mapping, it caches
mapping
Cache entries timeout (disappear) after some time (TTL)
TLD servers typically cached in local name servers thus root
name servers not often visited
Cached entries may be out-of-date (best effort name-
to-address translation!)
If name host changes IP address, it may not be known Internet-
wide until all TTLs expire
Update/notify mechanisms proposed IETF standard
RFC 2136 (https://tools.ietf.org/html/rfc2136)
Slide #51 of 57
DNS Records
DNS: distributed db storing resource records (RR)
RR format: (name, value, type, ttl)
type=A
name is hostname
value is IP address
type=NS
name is domain (e.g., foo.com)
value is hostname of
authoritative name server for this
domain
type=CNAME
name is alias name for some
“canonical” (the real) name
www.ibm.com is really
servereast.backup2.ibm.com
value is canonical name
type=MX
value is name of mailserver
associated with name
Slide #52 of 57
DNS Protocol, Messages
Query and Reply messages, both with same message format
Message Header
identification: 16 bit #
for query, reply to
query uses same #
flags:
query or reply
recursion desired
recursion
available
reply is
authoritative
Slide #53 of 57
DNS Protocol, Messages
Query and Reply messages, both with same message format
name, type fields
for a query
RRs in response
to query
records for
authoritative servers
additional “helpful”
info that may be used
Slide #54 of 57
Inserting Records into DNS
Example: new start-up “Network Utopia”
Register name networkuptopia.com at DNS registrar
(e.g., Network Solutions)
provide names, IP addresses of authoritative name server (primary
and secondary)
registrar inserts two RRs into .com TLD server:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
Create authoritative server type A record for
www.networkuptopia.com; type MX record for
networkutopia.com
Slide #55 of 57
Summary
We have studied:
Application architectures
client-server
P2P
Application service
requirements:
reliability, bandwidth,
delay, security
Internet transport service
model
connection-oriented,
reliable: TCP
unreliable, datagrams: UDP
Specific protocols:
HTTP
SMTP, POP, IMAP
DNS
Slide #56 of 57
Summary
Most Importantly: We have learned about protocols!
Typical request/reply
message exchange:
client requests info or
service
server responds with
data, status code
Message formats:
headers: fields giving
info about data
data: info being
communicated
Important themes:
control vs. data msgs
centralized vs. decentralized
stateless vs. stateful
reliable vs. unreliable
message transfer
“complexity at network edge”
Slide #57 of 57
References / Links
Chapter #2: Application Layer, Computer
Networking: A Top-Down Approach (7th
edition) by
Kurose & 1
Slide 2
Slide 3
Slide 4
Slide 5
Slide 6
Slide 7
Slide 8
Slide 9
Slide 10
Slide 11
Slide 12
Slide 13
Slide 14
Slide 15
Slide 16
Slide 17
Slide 18
Slide 19
Slide 20
Slide 21
Slide 22
Slide 23
Slide 24
Slide 25
Slide 26
Slide 27
Slide 28
Slide 29
Slide 30
Slide 31
Slide 32
Slide 33
Slide 34
Slide 35
Slide 36
Slide 37
Slide 38
Slide 39
Slide 40
Slide 41
Slide 42
Slide 43
Slide 44
Slide 45
Slide 46
Slide 47
Slide 48
Slide 49
Slide 50
Slide 51
Slide 52
Slide 53
Slide 54
Slide 55
Slide 56
Slide 57