Application protocols define how distributed processes communicate over a network. A typical network application uses a client-server model, with the client initiating requests and the server providing responses. Common application layer protocols include HTTP (for the web), SMTP (for email), FTP (for file transfer), SNMP (for network management), and POP3/IMAP (for accessing email stored on a server). These protocols use various message formats and interactions to provide user services over the underlying transport and network layers.

1. Application Protocols
1

2. Network applications: some jargon
• A process is a program that is • A user agent is an
running within a host. interface between the
• Within the same host, two user and the network
processes communicate with
application.
inter process communication
defined by the OS. – Web:browser
• Processes running in different – E-mail: mail reader
hosts communicate with an – streaming
application-layer protocol audio/video: media
player
2

3. Applications and application-layer protocols
Application: communicating, distributed application
transport
processes network
data link
– running in network hosts in “user physical
space”
– exchange messages to
implement app
– e.g., email, file transfer, the Web
Application-layer protocols
– one “piece” of an app
– define messages exchanged by application
application
transport
apps and actions taken transport
network
network
data link
data link
– user services provided by lower physical
physical
layer protocols
3

4. Client-server paradigm
Typical network app has two application
pieces: client and server transport
network
data link
physical
Client:
Ì initiates contact with server (“speaks request
first”)
Ì typically requests service from
server,
Ì for Web, client is implemented in
reply
browser; for e-mail, in mail reader
Server: application
transport
Ì provides requested service to client network
data link
Ì e.g., Web server sends requested physical
Web page, mail server delivers e-mail
2: Application Layer 44

5. Application-layer protocols (cont).
Q: how does a process “identify”
API: application programming the other process with which it
interface wants to communicate?
• defines interface between – IP address of host running
other process
application and transport – “port number” - allows
layer receiving host to determine
to which local process the
• socket: Internet API message should be
– two processes communicate delivered
by sending data into socket,
reading data out of socket
5

6. What transport service does an application need?
Data loss
• some apps (e.g., audio) can tolerate some loss
• other apps (e.g., file transfer, telnet) require 100% reliable data transfer
Bandwidth
• some apps (e.g., multimedia) require minimum amount of bandwidth to
be “effective”
• other apps (“elastic apps”) make use of whatever bandwidth they get
Timing
• some apps (e.g., Internet telephony, interactive games) require low delay
to be “effective”
6

7. The Web: some jargon
• Web page:
– consists of “objects”
– addressed by a URL
• Most Web pages consist of:
– base HTML page, and
– several referenced objects.
• User agent for Web is called a browser:
– MS Internet Explorer
– Netscape Communicator
• Server for Web is called Web server:
– Apache (public domain)
– MS Internet Information Server
7

8. The Web: the http protocol
http: hypertext transfer protocol
htt
• Web’s application layer protocol preq
PC running ues
htt t
• client/server model Explorer
pr
e sp
ons
– client: browser that requests, e
receives, “displays” Web objects
st
– server: Web server sends objects ue
eq Server
ttpr on
se
in response to requests h
res
p running
tp NCSA Web
• http1.0: RFC 1945 ht
server
• http1.1: RFC 2068
Mac running
Navigator
8

9. The http protocol: more
http: TCP transport service: http is “stateless”
• client initiates TCP connection • server maintains no
(creates socket) to server, port 80
information about past
• server accepts TCP connection from client requests
client
• http messages (application-layer Protocols that maintain “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
9

10. Non-persistent and persistent connections
Non-persistent Persistent
• HTTP/1.0 • default for HTTP/1.1
• server parses request, • on same TCP connection: server,
responds, and closes TCP parses request, responds,
connection parses new request,..
But most 1.0 browsers use parallel TCP connections.
10

11. http message format: request
11

12. http message format: response
status line
(protocol
status code HTTP/1.0 200 OK
status phrase) Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
header Last-Modified: Mon, 22 Jun 1998 …...
lines Content-Length: 6821
Content-Type: text/html
data data data data data ...
data, e.g.,
requested
html file
12

13. http response status codes
In first line in server->client response message.
A few 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
(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 13

14. Trying out http (client side) for yourself
1. Telnet to your favorite Web server:
telnet www.eurecom.fr 80 Opens TCP connection to port 80
(default http server port) at www.eurecom.fr.
Anything typed in sent
to port 80 at www.eurecom.fr
2. Type in a GET http request:
GET /~ross/index.html HTTP/1.0 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!
14

15. User-server interaction: authentication
client server
Authentication goal: control access to server usual http request msg
documents 401: authorization req.
• stateless: client must present authorization WWW authenticate:
in each request
• authorization: typically name, password usual http request msg
– authorization: header line in + Authorization:line
request usual http response msg
– if no authorization presented, server
refuses access, sends
usual http request msg
WWW authenticate: + Authorization:line
header line in response usual http response msg time
Browser caches name & password so
that user does not have to repeatedly enter it. 15

16. User-server interaction: cookies
client server
• server sends “cookie” to client in
response msg usual http request msg
Set-cookie: 1678453 usual http response +
• client presents cookie in later Set-cookie: #
requests
cookie: 1678453 usual http request msg
cookie: # cookie-
• server matches presented-cookie specific
with server-stored info usual http response msg action
– authentication
– remembering user usual http request msg
preferences, previous cookie-
cookie: #
choices specific
usual http response msg action
16

17. User-server interaction: conditional GET
client server
• Goal: don’t send object if client
has up-to-date stored (cached) http request msg
version If-modified-since: object
<date> not
• client: specify date of cached
http response modified
copy in http request HTTP/1.0
If-modified-since: 304 Not Modified
<date>
• server: response contains no
object if cached copy up-to- http request msg
date: If-modified-since:
<date>
object
HTTP/1.0 304 Not modified
http response
Modified HTTP/1.1 200 OK
…
17
<data>

18. Web Caches (proxy server)
Goal: satisfy client request without involving origin server origin
• user sets browser: Web server
accesses via web cache htt
Proxy
st
pr server reque
• client sends all http requests client http equest tp on
se
res ht p
to web cache pon res
se ttp h
– if object at web cache, web st
ue htt
cache immediately returns re q se
p req
http pon htt ues
object in http response re s p res t
tp pon
ht se
– else requests object from
origin server, then returns http client
origin
response to client server
18

19. Why Web Caching?
origin
Assume: cache is “close” to servers
client (e.g., in same network) public
Internet
• smaller response time: cache
“closer” to client
1.5 Mbps
• decrease traffic to distant access link
servers institutional
network
– link out of institutional/local 10 Mbps LAN
ISP network often bottleneck
institutional
cache
19

20. ftp: the file transfer protocol
FTP file transfer
FTP FTP
user client server
interface
user
at host local file remote file
system system
• transfer file to/from remote host
• client/server model
– client: side that initiates transfer (either to/from remote)
– server: remote host
• ftp: RFC 959
• ftp server: port 21
20

21. ftp: separate control, data connections
• ftp client contacts ftp server at port 21, TCP control connection
specifying TCP as transport protocol port 21
• two parallel TCP connections opened:
– control: exchange commands, TCP data connection
responses between client, server. FTP port 20 FTP
“out of band control” client server
– data: file data to/from server
• ftp server maintains “state”: current
directory, earlier authentication
21

22. ftp commands, responses
Sample commands: Sample return codes
• sent as ASCII text over control channel • status code and phrase (as in
• USER username http)
• PASS password • 331 Username OK,
• LIST return list of file in current password required
directory • 125 data connection
• RETR filename retrieves (gets) file already open;
transfer starting
• STOR filename stores (puts) file
• 425 Can’t open data
onto remote host
connection
• 452 Error writing
file
22

23. outgoing
message queue
Electronic Mail user
user mailbox
agent
Three major components: mail
user
• user agents server
agent
• mail servers SMTP mail
• simple mail transfer protocol: smtp server user
SMTP agent
User Agent
• a.k.a. “mail reader” SMTP
mail user
• composing, editing, reading mail server agent
messages
• e.g., Eudora, Outlook, elm, Netscape user
agent
Messenger user
• outgoing, incoming messages stored on agent
server
23

24. Electronic Mail: mail servers
user
agent
Mail Servers mail
user
• mailbox contains incoming server
agent
messages (yet to be read) for user
SMTP mail
• message queue of outgoing (to be
server user
sent) mail messages
SMTP agent
• smtp protocol between mail
servers to send email messages SMTP
mail user
– client: sending mail server agent
server
– “server”: receiving mail server
user
agent
user
agent
24

25. Electronic Mail: smtp [RFC 821]
• uses tcp to reliably transfer email msg 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
– commands: ASCII text
– response: status code and phrase
• messages must be in 7-bit ASCII
25

26. smtp: final words
• smtp uses persistent connections Comparison with http
• smtp requires that message (header & • http: pull
body) be in 7-bit ascii
• email: push
• certain character strings are not
permitted in message (e.g., • both have ASCII
CRLF.CRLF). Thus message has to be command/response interaction,
encoded (usually into either base-64 or status codes
quoted printable)
• http: each object is encapsulated
• smtp server uses CRLF.CRLF to
in its own response message
determine end of message
• smtp: multiple objects message
sent in a multipart message
26

27. Mail message format
smtp: protocol for exchanging header
blank
email msgs
line
RFC 822: standard for text
message format:
• header lines, e.g., body
– To:
– From:
– Subject:
different from smtp
commands!
• body
– the “message”, ASCII
characters only
27

28. Mail access protocols
SMTP SMTP POP3 or user
user
agent IMAP agent
sender’s mail receiver’s mail
server server
• SMTP: delivery/storage to receiver’s server
• Mail access protocol: retrieval from server
– POP: Post Office Protocol [RFC 1939]
• authorization (agent <-->server) and download
– IMAP: Internet Mail Access Protocol [RFC 1730]
• more features (more complex)
• manipulation of stored msgs on server
– HTTP: Hotmail , Yahoo! Mail, etc.
28

29. POP3 protocol
S:
C:
+OK POP3 server ready
user alice
S: +OK
C: pass hungry
authorization phase S: +OK user successfully logged on
• client commands: C: list
– user: declare username S: 1 498
– pass: password S: 2 912
S: .
• server responses C: retr 1
– +OK S: <message 1 contents>
– -ERR S: .
C: dele 1
transaction phase, client: C: retr 2
• list: list message numbers S: <message 1 contents>
• retr: retrieve message by number S: .
C: dele 2
• dele: delete C: quit
• quit S: +OK POP3 server signing off
29

30. What is SNMP?
• SNMP is a tool (protocol) that allows for remote and local
management of items on the network including servers,
workstations, routers, switches and other managed
devices.
• Comprised of agents and managers
•Agent - process running on each managed node collecting
information about the device it is running on.
•Manager - process running on a management workstation that
requests information about devices on the network.
30

31. Advantages of using SNMP
• Standardized
• universally supported
• extendible
• portable
• allows distributed management access
• lightweight protocol
31

32. Client Pull & Server Push
• SNMP is a “client pull” model
The management system (client) “pulls” data from the
agent (server).
 SNMP is a “server push” model
The agent (server) “pushes” out a trap message to a
(client) management system
32

33. The Three Parts of SNMP
SNMP network management is based on three parts:
•SNMP Protocol
•Defines format of messages exchanged by management
systems and agents.
•Specifies the Get, GetNext, Set, and Trap operations
•Structure of Management Information (SMI)
•Rules specifying the format used to define objects managed
on the network that the SNMP protocol accesses
•Management Information Base (MIB)
•A map of the hierarchical order of all managed objects and
how they are accessed
33