Download chap2_2ed_5July02 - National Tsing Hua University

Chapter 7
The Application Layer (Cont’d)
 Network Security
 Domain Name Server
 Network management
 Applications
 File Transfer Protocol, Email, Http, Telnet, ….
© All rights reserved. No part of these slides may be reproduced, in any
form or by any means, without permission in writing from
Professor Wen-Tsuen Chen (email: [email protected]).
2: Application Layer
1
Email Security
 PGP: Pretty Good Privacy, by Phil Zimmermaun in 1995.
 Support text compression, secrecy and digital signatures.
2: Application Layer
2
PGP message format
2: Application Layer
3
PEM: Privacy Enhanced Mail
 An official Internet standard described in
RFC 1421-1424.
 Support privacy and authentication for RFC
822 based email systems.
 The message together with its message
digest is encrypted using DES with a onetime key that is enclosed along with the
message.
 The key can be protected with RSA and
certified by certification authorities.
2: Application Layer
4
2: Application Layer
5
DNS: Domain Name System
People: many identifiers:

SSN, name, passport #
Internet hosts, routers:


IP address (32 bit) used for addressing
datagrams
“name”, e.g.,
gaia.cs.umass.edu - used
by humans
Q: map between IP
addresses and name ?
Domain Name System:
 A distributed database
implemented in hierarchy of
many name servers
 An application-layer protocol
that allows host, routers, name
servers to communicate to
resolve names (address/name
translation)
 DNS provides a core
Internet function,
implemented as applicationlayer protocol
 DNS is an example of the
Internet design philosophy
of placing complexity at
network’s “edge”
2: Application Layer
6
DNS
DNS services
 Hostname to IP
address translation
 Host aliasing

Canonical and alias
names
 Mail server aliasing
 Load distribution
 Replicated Web
servers: set of IP
addresses for one
canonical name
Why not centralize DNS?
 single point of failure
 traffic volume
 distant centralized
database
 maintenance
doesn’t scale!
2: Application Layer
7
Distributed, Hierarchical
Database
Root DNS Servers
com DNS servers
yahoo.com
amazon.com
DNS servers DNS servers
org DNS servers
pbs.org
DNS servers
edu DNS servers
poly.edu
umass.edu
DNS serversDNS servers
Client wants IP for www.amazon.com; 1st approx:
 Client queries a 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
2: Application Layer
8
DNS name servers
The DNS is a distributed
design
 A large number of name
servers organized in a
hierarchical fashion and
distributed around the world
 no server has all name-to-IP
address mappings
There are three types of name
servers:
(1) local name servers:


each ISP, company has local
(default) name server
host DNS query first goes to
local name server
(2) root name servers: top level
name servers ( to be explained
next)
(3) authoritative name servers:


for a host: stores that host’s
IP address, name
can perform name/address
translation for that host’s
name
2: Application Layer
9
DNS: Root name servers
 contacted by local name server that can not resolve name
 root name server:



gets mapping
returns mapping to local name server
contacts authoritative name server if name mapping not known
a NSI Herndon, VA
c PSInet Herndon, VA
d U Maryland College Park, MD
g DISA Vienna, VA
h ARL Aberdeen, MD
j NSI (TBD) Herndon, VA
k RIPE London
i NORDUnet Stockholm
m WIDE Tokyo
e NASA Mt View, CA
f Internet Software C. Palo Alto,
CA
b USC-ISI Marina del Rey, CA
l ICANN Marina del Rey, CA
13 root name
servers worldwide
2: Application Layer
10
TLD and Authoritative Servers
 Top-level domain (TLD) servers: responsible
for com, org, net, edu, etc, and all top-level
country domains uk, fr, ca, jp.
Network Solutions maintains servers for com TLD
 Educause for edu TLD

 Authoritative DNS servers: organization’s
DNS servers, providing authoritative
hostname to IP mappings for organization’s
servers (e.g., Web and mail).

Can be maintained by organization or service
provider
2: Application Layer
11
Local Name Server
 Does not strictly belong to hierarchy
 Each ISP (residential ISP, company,
university) has one.

Also called “default name server”
 When a host makes a DNS query, query is
sent to its local DNS server

Acts as a proxy, forwards query into hierarchy.
2: Application Layer
12
Example
root DNS server
 Host at cis.poly.edu
2
wants IP address for
gaia.cs.umass.edu
3
TLD DNS server
4
5
local DNS server
dns.poly.edu
1
8
requesting host
7
6
authoritative DNS server
dns.cs.umass.edu
cis.poly.edu
gaia.cs.umass.edu
2: Application Layer
13
Recursive queries
recursive query:
2
 puts burden of name
resolution on
contacted name
server
 heavy load?
iterated query:
 contacted server
replies with name of
server to contact
 “I don’t know this
name, but ask this
server”
root DNS server
3
7
6
EDU DNS server
local DNS server
dns.poly.edu
1
5
4
8
requesting host
authoritative DNS server
dns.cs.umass.edu
cis.poly.edu
gaia.cs.umass.edu
2: Application Layer
14
Recursive and iterated queries
root DNS server
Typically, all queries
are iterated except
for the query from
the host to the local
name server.
2
3
TLD DNS server
4
5
local DNS server
dns.poly.edu
recursive query
1
8
requesting host
7
6
iterated query
authoritative DNS server
dns.cs.umass.edu
cis.poly.edu
gaia.cs.umass.edu 2: Application Layer
15
DNS: caching and updating records
 once (any) name server learns mapping, it caches
mapping
 cache entries timeout (disappear) after some
time (usually two days)
 Until recently, the contents of each DNS
servers were configured statically from a
configuration file created by a system manager.
 More recently, an UPDATE option has been
added to the DNS protocol to allow data to be
added or deleted from the database via DNS
messages.
 DNS dynamic update mechanism is specified in
RFC 2136
2: Application Layer
16
DNS records
DNS: distributed database storing resource records (RR)
RR format: (name,
 Type=A
 name is hostname
 value is IP address
value, type, ttl)
 Type=CNAME
 name is alias name for some
“cannonical” (the real) name
www.ibm.com is really
servereast.backup2.ibm.com
 Type=NS


 value is cannonical name
name is domain (e.g.
foo.com)
 Type=MX
value is IP address of
 name is alias name for some
authoritative name server
for this domain
mail server

value is the canonical name
of the mail server
2: Application Layer
17
DNS protocol, messages
DNS protocol : 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
2: Application Layer
18
DNS protocol, messages
Name, type fields
for a query
RRs
in reponse to query
A hostname can have
multiple IP addresses
records for other
authoritative servers
additional “helpful”
information that may be used
e.g. IP address for the canonical
hostname of the mail server
2: Application Layer
19
Inserting records into DNS
 Example: just created startup “Network Utopia”
 Register name networkuptopia.com at a registrar
(e.g., Network Solutions)


Need to provide registrar with names and IP addresses of
your authoritative name server (primary and secondary)
Registrar inserts two RRs into the com TLD server:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
 Put in authoritative server Type A record for
www.networkuptopia.com and Type MX record for
networkutopia.com
 How do people get the IP address of your Web site?
2: Application Layer
20
Network Management Systems
 A network management system is a collection of
tools for network monitoring and control.
 It has the following key elements:




Management station, or manager.
Agent in managed nodes, equipments etc.
Management Information base (MIB).
Network management protocol.
2: Application Layer
21
2: Application Layer
22
 The management station will have
 A set of management applications for data
analysis, fault recovery etc.
 An Interface by which the network manager
may monitor and control the network.
 The capability of translating the network
manager’s requirements into the actual
monitoring and control of remote elements in
the network.
 A database of network management information
extracted from the database of all the
managed entities in the network.
2: Application Layer
23
 The agent is an active element residing in hosts, bridges,
routers, and hubs etc. that responds to requests for
information or actions from a management station, and may
provide the management station (through trap) with
important but unsolicited information.
 An MIB is a collection of objects which are resources in the
network that may be managed.
 Network management protocol for TCP/IP networks is SNMP
(Simple network management protocol), and for OSI-based
networks is CMIP (Common Management Information
Protocol).
2: Application Layer
24
SNMP: Simple Network Management Protocol
 First Proposed in 1988, RFC 1028, RFC
1067 Version 1 of SNMP in May 1990, RFC
1157 SNMPv2 issued in 11993, RFCs 1441
to 1452.
 SNMP provides the infrastructure for
network management applications.
 The object definition language ASN.1
(Abstract Syntax Notation One), taken
from OSI, is used for defining objects in
MIBs.
2: Application Layer
25
Structure of Management Information
 The SMI defines the general framework within
which an MIB can be defined and constructed.
 The SMI identifies the data types (only simple)
the scalars and two-dimensional arrays of scalars,
called tables) that can be used in the MIB, and
how resources within the MIB are represented
and named.
2: Application Layer
26
2: Application Layer
27
SNMP Protocol
 Provides a basic mechanism for the exchange of




management information between manager and
agent.
Get-bulk-request, Inform-request, Response, and
SNMPv2-trap are SNMPv2 specific.
An SNMPv2-trap is generated by an agent for
reporting unusual events.
Inform-request is sent by a manager on behalf of
an application, to another manager for providing
management information to an application.
The manager receiving an Inform Request
acknowledges receipt with Response.
2: Application Layer
28
in lexicographic order
Response
Acknowledgement of receipt by Inform-request
2: Application Layer
29
Internet apps: application, transport protocols
Application
e-mail
remote terminal access
Web
file transfer
streaming multimedia
Internet telephony
Application
layer protocol
Underlying
transport protocol
SMTP [RFC 2821]
Telnet [RFC 854]
HTTP [RFC 2616]
FTP [RFC 959]
proprietary
(e.g. RealNetworks)
proprietary
(e.g., Dialpad)
TCP
TCP
TCP
TCP
TCP or UDP
typically UDP
2: Application Layer
30
FTP: the file transfer protocol
user
at host
FTP
FTP
user
client
interface
file transfer
local file
system
FTP
server
remote file
system
 transfer file to/from remote host
 client/server model
Client side: the side that initiates transfer (either
to/from remote)
 Server side: remote host
 ftp: RFC 959
 ftp server: port 21

2: Application Layer
31
FTP: separate control, data connections
TCP control connection
port 21
 FTP client contacts FTP




server at port 21, specifying
TCP as transport protocol
Client obtains authorization
over control connection –username, password
Client browses remote
directory by sending
commands over control
connection.
When server receives a
command for a file transfer,
the server opens a TCP data
connection to client
After transferring one file,
server closes connection.
FTP
client
TCP data connection
port 20
FTP
server
 Server opens a second TCP
data connection to transfer
another file.
 Control connection: “out of
band”
 FTP server maintains “state”:
current directory, earlier
authentication
2: Application Layer
32
FTP commands, responses
Sample commands:
Sample return codes
sent as ASCII text over control status code and phrase (as in
channel
HTTP)
 331 Username OK,
 USER username
password required
 PASS password
 125 data connection
 LIST -- return list of file in
already open;
current directory
transfer starting
 RETR filename -- retrieves  425 Can’t open data
(gets) file
connection
 STOR filename -- stores
 452 Error writing
(puts) file onto remote host
file
2: Application Layer
33
Electronic Mail
outgoing
message queue
user mailbox
Three major components
of a mail system:
 user agents
user
agent
mail
server
 mail servers
SMTP
 simple mail transfer
protocol: SMTP
User Agent
 Also known as “mail reader”
 composing, editing, reading
mail messages
 e.g., Eudora, Outlook, elm,
Netscape Messenger
 outgoing, incoming messages
stored on server
SMTP
mail
server
user
agent
SMTP
user
agent
mail
server
user
agent
user
agent
user
agent
2: Application Layer
34
Electronic Mail: mail servers
outgoing
message queue
user mailbox
user
agent
Mail Servers
 mailbox contains incoming
mail
server
messages for user
 message queue of outgoing
(to be sent) mail messages
 SMTP protocol between mail
SMTP
servers to send email
messages
 client: sending mail
mail
server
server
 “server”: receiving mail
server
message queue
user
mailbox
SMTP
SMTP
user
agent
mail
server
user
agent
user
agent
user
agent
agent
2: Application Layer
35
Electronic Mail: SMTP [RFC 2821]
Simple Mail Transfer Protocol (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
 commands: ASCII text
 response: status code and phrase
 messages must be in 7-bit ASCII
2: Application Layer
36
Scenario: Alice sends message to Bob
1) Alice uses user agent to
compose message and “to”
[email protected]
2) Alice’s user agent sends
message to her mail server;
message placed in message
queue
3) Alice’s mail server (Client
side) of SMTP opens TCP
connection with Bob’s mail
server (server side)
1
user
agent
2
message queue
mail
server
3
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
outgoing
message queue
user mailbox
mail
server
4
mailbox
5
6
user
agent
2: Application Layer
37
Sample SMTP interaction
The following transcript begins as soon as the TCP
connection is established:
server
S: 220 hamburger.edu
C: HELO crepes.fr
client
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <[email protected]>
S: 250 [email protected]... Sender ok
C: RCPT TO: <[email protected]>
S: 250 [email protected] ... 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
2: Application Layer
38
Try SMTP interaction for yourself:
 telnet servername 25
 see 220 reply from server
 enter HELO, MAIL FROM, RCPT TO, DATA, QUIT
commands
above lets you send email without using email client
(reader)
2: Application Layer
39
SMTP: final words
 SMTP uses persistent
connections
 SMTP requires message
(header & body) to be in 7bit ASCII
 SMTP server uses
CRLF.CRLF to determine
end of message
Comparison with HTTP:
 HTTP: pull protocol (client’s
point of view)
 SMTP: push protocol
 both have ASCII
command/response
interaction, status codes
 HTTP does not require
message to be in 7-bit ASCII
 HTTP: one object in one
response message
 SMTP: multiple objects can
be sent in one message
2: Application Layer
40
Mail message format
SMTP: protocol for
exchanging email messages
RFC 822: standard for text
message format:
 header lines, e.g.,
To:
 From:
 Subject:
different from SMTP
commands!

header
blank
line
body
 body

the “message”, ASCII
characters only
2: Application Layer
41
Message format: multimedia extensions
 MIME (Multipurpose Internet Mail extensions) :
multimedia mail extension, RFC 2045, 2056
 additional lines in message header declare MIME content
type
MIME version
method used
to encode data
multimedia data
type, subtype,
parameter declaration
encoded data
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
2: Application Layer
42
MIME types
Content-Type: type/subtype; parameters
Currently, seven types are (5)Application
defined:
 other data that must be processed
(1) Text
by reader before “viewable”
 example subtypes: plain,
html
(2) Image
 example subtypes: jpeg,
gif
 example subtypes: msword,
octet-stream
(6) Multipart
 one or more different sets of data
 exampe subtypes: basic (8-
are combined in a single body
 example subtypes: mixed,
alternative (alternative version of
the same information)
(4) Video
 example subtypes: rfc822, partial
(3) Audio
bit mu-law encoded),
32kadpcm (32 kbps Adaptive
Differential Pulse Code
(7) Message
Modulation coding)
 encapsulate another mail message
 example subtypes: mpeg,
quicktime
2: Application Layer
43
Example of Multipart Type
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=StartOfNextPart
--StartOfNextPart
Dear Bob, Please find a picture of a crepe.
--StartOfNextPart
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
--StartOfNextPart
Do you want the reciple?
2: Application Layer
44
Header line inserted by the receiving
server
Received: from crepes.fr by hamburger.edu; 12 Oct 98
15:27:39 GMT
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
2: Application Layer
45
Mail access protocols
user
agent
SMTP
SMTP
sender’s mail
server
Mail access user
protocol agent
receiver’s mail
server
 SMTP: delivery/storage to receiver’s server
 Mail access protocol: retrieval from server



POP3: Post Office Protocol, version 3 [RFC 1939]
• authorization (agent <--> server) and download
IMAP: Internet Mail Access Protocol [RFC 2060]
• more features (more complex)
• manipulation of stored messages on server
HTTP: Hotmail , Yahoo! Mail, etc.
2: Application Layer
46
POP3 protocol
(1) Client opens a TCP connection to
the mail server on port 110
(2) authorization phase
 client commands:
 user: declare username
 pass: password
 server responses
 +OK
 -ERR
(3) transaction phase, client:
 list: list message numbers
 retr: retrieve message by
number
 dele: delete
 Quit
(4) update phase : mail server
deletes the messages marked
for deletion
S:
C:
S:
C:
S:
+OK POP3 server ready
user bob
+OK
pass hungry
+OK user successfully logged
C:
S:
S:
S:
C:
S:
S:
C:
C:
S:
S:
C:
C:
S:
list
1 498
Message size
2 912
.
Message number
retr 1
<message 1 contents>
.
dele 1
retr 2
<message 1 contents>
.
dele 2
quit
+OK POP3 server signing off
2: Application Layer
on
47
POP3 (more) and IMAP
More about POP3
 Previous example uses
“download and delete”
mode.
 Bob cannot re-read e-mail
if he changes client
 “Download-and-keep”
mode: copies of messages
on different clients
 POP3 is stateless across
sessions
IMAP
 Keep all messages in
one place: the server
 Allows user to
organize messages in
folders
 IMAP keeps user state
across sessions:

names of folders and
mappings between
message IDs and folder
name
2: Application Layer
48
Web and HTTP
First some jargon
 Web page consists of objects
 An object is a file such as an HTML file, a JPEG
image, a Java applet, an audio file,…
 A Web page consists of a base HTML-file and
several referenced objects
 The base HTML file references the other objects
in the page with the object’s URLs (Uniform
Resource Locators)
 Example URL:
www.someschool.edu/someDept/pic.gif
host name
path name
2: Application Layer
49
HTTP overview
HTTP: hypertext
transfer protocol
 Web’s application layer
protocol
 client/server model
 client: browser that
requests, receives,
“displays” Web objects
 server: Web server
sends objects in
response to requests
 HTTP 1.0: RFC 1945
 HTTP 1.1: RFC 2616
PC running
Explorer
Server
running
Apache Web
server
Mac running
Navigator
2: Application Layer
50
HTTP overview (continued)
Uses TCP:
 client initiates TCP
connection (creates socket)
to server, port 80
 server accepts TCP
connection from client
 HTTP messages (applicationlayer protocol messages)
exchanged between browser
(HTTP client) and Web
server (HTTP server)
 TCP connection closed
HTTP is “stateless”
 server maintains no
information about
past client requests
aside
Protocols that maintain
“state” are complex!
 past history (state) must
be maintained
 if server/client crashes,
their views of “state” may
be inconsistent, must be
reconciled
2: Application Layer
51
HTTP connections
Nonpersistent HTTP
 At most one object is
sent over a TCP
connection.
 HTTP/1.0 uses
nonpersistent HTTP
Persistent HTTP
 Multiple objects can be
sent over single TCP
connection between
client and server.
 A new connection need
not be set up for the
transfer of each Web
object
 HTTP/1.1 uses persistent
connections in default
mode – can be configured
to use nonpersistent
connection
2: Application Layer
52
Nonpersistent HTTP
(contains text,
references to 10
www.someSchool.edu/someDepartment/home.index
jpeg images)
Suppose user enters URL
1a. HTTP client initiates TCP
connection to HTTP server
(process) at
www.someSchool.edu on port 80
2. HTTP client sends HTTP
request message (containing
URL) into TCP connection
socket. Message indicates
that client wants object
someDepartment/home.index
1b. HTTP server at host
www.someSchool.edu waiting
for TCP connection at port 80.
“accepts” connection, notifying
client
3. HTTP server receives request
message, forms response
message containing requested
object, and sends message
into its socket
time
2: Application Layer
53
Nonpersistent HTTP (cont.)
4. HTTP server closes TCP
5. HTTP client receives response
connection.
message containing html file,
displays html. Parsing html
file, finds 10 references to
the 10 jpeg objects
time 6. Steps 1-5 repeated for each
of 10 jpeg objects
2: Application Layer
54
Response time modeling
Definition of RRT: time to send
a small packet to travel from
client to server and back.
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
total = 2RTT+transmit time
initiate TCP
connection
RTT
request
file
time to
transmit
file
RTT
file
received
time
time
2: Application Layer
55
Persistent HTTP
Nonpersistent HTTP issues:
 requires 2 RTTs per object
 OS must work and allocate
host resources for each TCP
connection
 but 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
are sent over connection
Two versions of persistent
connections:
Persistent without pipelining:
 client issues new request
only when previous
response has been received
 one RTT for each
referenced object
Persistent with pipelining:
 default in HTTP/1.1
 client sends requests as
soon as it encounters a
referenced object
 as little as one RTT for all
the referenced objects
2: Application Layer
56
HTTP request message
 two types of HTTP messages: request, response
 HTTP request message:
 ASCII (human-readable format)
request line
(GET, POST,
HEAD commands)
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
User-agent: Mozilla/4.0
header Connection: close
lines Accept-language:fr
Carriage return,
line feed
indicates end
of message
(extra carriage return, line feed)
2: Application Layer
57
Explanation of the example
GET /somedir/page.html HTTP/1.1
-- Request to return the object /somedir/page.html
-- The browser implements version HTTP/1.1
Host: www.someschool.edu
-- Specifies the host on which the object resides
User-agent: Mozilla/4.0
-- Specifies the browser type that is making the request
Connection: close
-- Indicates that the connection SHOULD NOT be considered
`persistent‘. It wants the server to close the connection after the
current request/response is complete
Accept-language:fr
-- Indicates that the user prefers to receive a French
version of the object
2: Application Layer
58
HTTP request message: general
format
2: Application Layer
59
Method types
HTTP/1.0
 GET : Return the object
 POST : Send information
to be stored on the
server
 HEAD

Return only information
about the object, such as
how old it is, but not the
object itself
HTTP/1.1
 GET, POST, HEAD
 PUT

Uploads a new copy of
existing object in entity
body to path specified
in URL field
 DELETE
 deletes object
specified in the URL
field
2: Application Layer
60
Uploading form input
Post method:
 Web page often
includes form input
 Input is uploaded to
server in entity body
URL method:
 Uses GET method
 Input is uploaded in
URL field of request
line:
www.somesite.com/animalsearch?monkeys&banana
2: Application Layer
61
HTTP response message
An HTTP response consists of the following:
1.
2.
3.
A status line, which indicates the success or failure of the request
Header lines: A description of the information in the response. This is
the metadata or meta information
The actual information requested
status line
(protocol status code status phrase)
HTTP/1.1 200 OK
Connection close
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
blank line
data, e.g.,
requested
HTML file
data data data data data ...
2: Application Layer
62
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
2: Application Layer
63
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 is 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!
2: Application Layer
64