Transcript ch2_APPL_0708 - Universiteit Gent

Communication Networks
P. Demeester
Chapter 2
Application Layer
Computer networking A top-down approach featuring the
internet
4th Edition, 2008
Addison Wesley
James F. Kurose, Keith W. Ross
ISBN 0-321-49770-8
Application Layer
Part of slides provided by J.F Kurose and K.W. Ross, All Rights Reserved
2-1
Focus : Application Layer
find info about Internet
on the Web !
RFC
client
Remote login : Telnet
URL:
www.ietf.org
Web access
: HTTP
File transfer : FTP
1011: :SMTP/POP/IMAP
“Internet Protocols”
E-mail
Address resolution : DNS
IETF web
page
server
TCP-Connection
router
Internet Protocol
56.6 kbit/s
modem connection
local telephone
switch
10 Mbit/s local area network
2 Mbit/s
140 Mbit/s
100 Gbit/s WDM PDH link
ISDN link
transatlantic optical cable
Application Layer
2-2
Chapter 2 outline
 2.1 Principles of app layer protocols
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail
 2.5 DNS
Application Layer
2-3
Applications and application-layer protocols
 Application : communicating, distributed processes
(e.g. e-mail, Web, P2P file sharing, …)
 Applications offer services to human users (or
other applications) via a User Interface:


Text-oriented User Interface (Telnet, FTP)
Graphical User Interface (GUI) (WWW)
 Applications use an application-layer protocol to
implement these services
(protocol commands “independent” of user interface)
 The application layer is the collection of these
protocols (FTP, SMTP, POP, IMAP, HTTP, etc.)
Example :
FTP user interface : PUT and GET
or drag-and-drop
FTP protocol : STOR and RETR
Application Layer
2-4
Applications and application-layer protocols
APPLICATION
CLIENT
APPLICATION
SERVER
HTML
Web
browser documents
GUI
Web
server
GUI
...
Application Layer
Protocol
communicating
processes
HTML
documents
...
Application Layer
Protocol
API:socket interface
transport
transport
network
network
network
network
data link
data link data link
data link data link
data link
physical
physical physical
physical physical
physical
terminal
router
router
terminal
Note : server program <> server-class computer
Application Layer
2-5
Processes communicating across network
 process sends/receives
messages to/from its
socket (=SAP)
 socket analogous to door


sending process shoves
message out door
sending process assumes
transport infrastructure
on other side of door which
brings message to socket
at receiving process
host or
server
host or
server
process
controlled by
app developer
process
socket
socket
TCP with
buffers,
variables
Internet
TCP with
buffers,
variables
controlled
by OS
 API or socket : (1) choice of transport protocol; (2)
ability to fix a few parameters
Application Layer
2-6
Application-layer protocol defines:
 Types of messages
exchanged, e.g., request
& response messages
 Syntax of message types:
what fields in messages &
how fields are delineated
 Semantics of the fields,
i.e., meaning of
information in fields
 Rules for when and how
processes send & respond
to messages
Public-domain protocols:
 defined in RFCs
 allows for
interoperability
 eg, HTTP, SMTP
Proprietary protocols:
 eg, KaZaA
Application Layer
2-7
Application Client - Server
CLIENT : “active open”
•
•
•
•
•
•
•
invoked directly by user
local on user’s personal computer
actively initiates contact with server
one session at a time
access multiple services as needed
simple hardware and software
e.g. : Eudora, Internet Explorer
SERVER : “passive open”
•
•
•
•
•
•
•
application
transport
network
data link
physical
request
special purpose program for one service
can handle multiple remote clients at same time
runs on a shared computer
waits passively for contact from arbitrary remote client
powerful hardware and sophisticated operating system
server program also called daemon (e.g. FTP daemon)
e.g.: Apache, Sendmail
reply
application
transport
network
data link
physical
• Information can flow in both directions between client and server
Application Layer
2-8
• An application program can act as client and server
thread
pool
Dynamic Server Process creation
request
request
handler 1 handler 2
...
request
handler N
server
request reception and thread creation
IP address: 148.35. 2.205
TCP protocol: 6
HTTP port: 80
network
CLIENT 1
CLIENT 2
IP address: 157.193.122.12
IP address: 157.193.122.112
TCP protocol: 6
TCP protocol: 6
HTTP port: 1173
HTTP port: 1212
CLIENT N
IP address: 134.182.113.65
TCP protocol: 6
HTTP port: 1540
Application Layer
2-9
What transport service does an app need?
Data loss
 some apps (e.g., audio) can
tolerate some loss
 other apps (e.g., file
transfer, telnet) require
100% reliable data
transfer
Timing
 some apps (e.g.,
Internet telephony,
interactive games)
require low delay to be
“effective”
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
Application Layer
2-10
Transport service requirements of common apps
Application Data loss
file transfer
e-mail
Web documents
real-time audio/video
no loss
no loss
no loss
loss-tolerant
Time Sensitive
Bandwidth
elastic
elastic
elastic
audio: 5kbps-1Mbps
video:10kbps-5Mbps
stored audio/video loss-tolerant same as above
interactive games loss-tolerant few kbps up
instant messaging no loss
elastic
no
no
no
yes, 100’s msec
yes, few secs
yes, 100’s msec
yes and no
Application Layer
2-11
Internet transport protocols services
TCP service:
UDP service:
 connection-oriented: setup
 unreliable data




required between client and
server processes
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 bandwidth
guarantees
transfer between
sending and receiving
process
 does not provide:
connection setup,
reliability, flow control,
congestion control,
timing, or bandwidth
guarantee
Application Layer
2-12
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
Application Layer
2-13
Simple example : Telnet
Telnet
Telnet
client
a
TCP
TCP connection
server
TCP
Login shell
(ksh, csh,
command.com)
login on a remote machine
‘a’
(different location, different operating system)
‘a’
‘a’
‘a’
‘a’
‘a’
‘a’
‘a’
‘a’
‘a’
I/O :
keyboard
screen
Telnet
client
program
socket
interface
Note : a socket connection has to be set up before info can be exchanged
socket
interface
Telnet
server
login shell
program
Application Layer 2-14
Simple example : Telnet
• standard Telnet port : 23
==> in general response is prompt for “login: ” and “password: ”
(does not belong to Telnet protocol)
• also other ports possible (server side should not run Telnet deamon)
example : ECHO (port 7), DAYTIME (port 13), HTTP (80), …
Telnet client : - send characters from keyboard
- show received characters on display
Ask creation of a socket to eduserv2 at port 7
first name to address translation is done : 157.193.40.10
then connection is set-up
Echo example
$ telnet eduserv2 7
Trying 157.193.40.10...
Connected to eduserv2.rug.ac.be.
Hallo
Hallo
^C
Daytime example
$ telnet eduserv2 13
Trying 157.193.40.10...
Connected to eduserv2.rug.ac.be.
Mon Oct 2 14:27:43 1998
Connection closed by foreign host.
We type Hallo and see it on the display (Telnet operation)
We receive it a second time on the display (Echo operation)
^C will close the connection
Application Layer
2-15
Chapter 2 outline
 2.1 Principles of app layer protocols
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail
 2.5 DNS
Application Layer
2-16
Web and HTTP
First some jargon
 Web page consists of objects
 Object can be HTML file, JPEG image, Java
applet, audio file,…
 Web page consists of base HTML-file which
includes several referenced objects
 Each object is addressable by a URL
 Example URL:
www.ibcn.intec.UGent.be/courses/CommNet.html
host name
path name
Application Layer
2-17
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 2068
PC running
Explorer
Server
running
Apache Web
server
Mac running
Navigator
Application Layer
2-18
HTTP overview (continued)
Uses TCP:
HTTP is “stateless”
 server is listening (open socket)
 server maintains no
 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
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
Application Layer
2-19
Web page example
ietf.gif
rug.gif
CommNet.html
(contains text,
references to 4
gif images)
intec.gif
atlantis.gif
Application Layer 2-20
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.
 HTTP/1.1 uses
persistent connections
in default mode
Application Layer
2-21
Nonpersistent HTTP
Suppose user enters URL
www.ibcn.intec.UGent.be/courses/CommNet.html
1a. HTTP client initiates TCP
connection to HTTP server
(process) at
www.ibcn.intec.UGent.be on port
80
2. HTTP client sends HTTP
request message (containing
URL) into TCP connection
socket. Message indicates
that client wants object
courses/CommNet.html
time
1b. HTTP server at host
www.ibcn.intec.UGent.be
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
Application Layer 2-22
Nonpersistent HTTP (cont.)
4. HTTP server closes TCP
connection.
5. HTTP client receives response
time
message containing html file,
displays html and closes TCP
connection. Parsing html file,
finds 4 referenced .gif
objects
6. Steps 1-5 repeated for each
of 4 gif objects
Application Layer 2-23
Response time modeling
 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
e.g.: 50 msec RTT, 1 kB
 (1000 x 8)/0.1 = 80 kb/s
initiate TCP
connection
RTT
request
file
RTT
time to
transmit
file
file
received
time
Definition of RTT (Round Trip Time) : time to send
a small packet to travel from client to server and back.
time
Application Layer 2-24
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
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
Application Layer 2-25
HTTP : Request Message
method SP URL SP version CR/LF
...
request line
header field name CO value CR/LF
header lines
header field name CO value CR/LF
new line
CR/LF
Entity Body
used with POST
(e.g. when a form is filled and
transferred with the request)
method
POST, HEAD (e.g.: GET http://www.ietf.org/
GET: GET,
http://www.ietf.org/
HTTP/1.0HTTP/1.0)
header
:
Connection:
close
connection
: indicateMozilla/4.0
if the TCP connection should be closed after the transfer
User-agent:
user-agent
software used on client
side (e.g. Mozilla/4.0)
Accept: : text/html,
image/gif,
image/jpeg
Accept-language:
fracceptable (e.g. text/html, image/gif, image/jpeg)
accept : list of what formats are
Application
accept-language : preferred language to receive information (e.g.:
fr) Layer 2-26
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
Application Layer 2-27
Method types
HTTP/1.0
 GET
 POST
 HEAD

asks server to leave
requested object out of
response
HTTP/1.1
 GET, POST, HEAD
 PUT

uploads file in entity
body to path specified
in URL field
 DELETE
 deletes file specified in
the URL field
Application Layer 2-28
HTTP : Response Message
version SP Status code SP phrase CR/LF
...
response line
header field name CO value CR/LF
header lines
header field name CO value CR/LF
new line
CR/LF
Entity Body
the requested
information
HTTP/1.1 200 OK
Date: Fri, 18 Feb 2000 15:46:11 GMT
Server: Apache/1.3.6 (Unix)
Last-Modified:
21 Dec 1999 13:44:47 GMT
version
: HTTP/1.0 or Tue,
HTTP/1.1
ETag: "a-8ae-385f844f"
status
code : number bytes
Accept-Ranges:
Content-Length:
2222 code
phrase
: explanation of status
Connection:
close
header
:
Connection:
, Date: , Server: , Last-Modified: ,
Content-Type: text/html
Application Layer 2-29
Content-Length: , Content-Type: , ...
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
Application Layer 2-30
HTTP example
$ telnet www.UGent.be 80
Trying 157.193.40.33...
Connected to sangoku.ugent.be.
GET HTTP://www.UGent.be/ HTTP/1.0
HTTP/1.1 200 OK
Date: Fri, 18 Feb 2000 15:46:11 GMT
Server: Apache/1.3.6 (Unix)
Last-Modified: Tue, 21 Dec 1999 13:44:47 GMT
ETag: "a-8ae-385f844f"
Accept-Ranges: bytes
Content-Length: 2222
Connection: close
Content-Type: text/html
<html>
<head>
<title>UNIVERSITEIT GENT - UNIVERSITY OF
GHENT</title>
<style type="text/css">
...
</style>
</head>
<body bgcolor="#000066" link="#cccccc"
vlink="#cccccc" alink="#666666">
...
</body>
</html>
Connection closed by foreign host
connection set-up
request to get
UGent homepage
reply header
HTML document
UGent homepage
close connection
Application Layer
2-31
User-server interaction: authorization
client
Authorization : control access to
server content
 authorization credentials: typically
name, password
 stateless: client must present
authorization in each request
 authorization: header line in
each request
 if no authorization: header,
server refuses access, sends
WWW authenticate:
header line in response
server
usual http request msg
401: authorization req.
WWW authenticate:
usual http request msg
+ Authorization: <cred>
usual http response msg
usual http request msg
+ Authorization: <cred>
usual http response msg
time
Application Layer 2-32
Cookies: keeping “state”
Many major Web sites
use cookies
Four components:
1) cookie header line in
the HTTP response
message
2) cookie header line in
HTTP request message
3) cookie file kept on
user’s host and managed
by user’s browser
4) back-end database at
Web site
Example:



Susan access Internet
always from same PC
She visits a specific ecommerce site for first
time
When initial HTTP
requests arrives at site,
site creates a unique ID
and creates an entry in
backend database for
ID
Application Layer 2-33
Cookies: keeping “state” (cont.)
client
Cookie file
usual http request msg
usual http response +
ebay: 8734
Cookie file
Set-cookie: 1678
usual http request msg
amazon: 1678
cookie: 1678
ebay: 8734
usual http response msg
CP_GUTC
128.107.241.139.211311061359797259
one week later:
cisco.com/
usual http request msg
Cookie file
0
cookie: 1678
2037491840
amazon: 1678
ebay: 8734
31418710
usual http response msg
3071359392
29583073
*
server
server
creates ID
1678 for user
cookiespecific
action
cookiespectific
action
Application Layer 2-34
Cookies (continued)
What cookies can bring:
 authorization
 shopping carts
 recommendations
 user session state
(Web e-mail)
aside
Cookies and privacy:
 cookies permit sites to
learn a lot about you
 you may supply name
and e-mail to sites
 search engines use
redirection & cookies
to learn yet more
 advertising companies
obtain info across
sites
Application Layer 2-35
Conditional GET: client-side caching
server
client
HTTP request msg
 Goal: don’t send object if client
has up-to-date cached version
 client: specify date of cached
copy in HTTP request
If-modified-since: <date>
 server: response contains no
object if cached copy is up-todate:
HTTP/1.0 304 Not Modified
If-modified-since:
<date>
HTTP response
object
not
modified
HTTP/1.0
304 Not Modified
HTTP request msg
If-modified-since:
<date>
HTTP response
object
modified
HTTP/1.0 200 OK
<data>
Application Layer 2-36
Chapter 2 outline
 2.1 Principles of app layer protocols
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail
 2.5 DNS
Application Layer 2-37
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 that initiates transfer (either to/from
remote)
 server: remote host
 ftp: RFC 959
 ftp server: port 21 (control), port 20 (data)

Application Layer 2-38
FTP: separate control, data connections
 FTP client contacts FTP server





at port 21, specifying TCP as
transport protocol
Client obtains authorization
USER, PASS, PWD, CWD, LIST,
PORT, RETR, STOR, QUIT
over control connection
Client browses remote directory
TCP control connection
by sending commands over
port 21
control connection.
When server receives a
TCP data connection
command for a file transfer,
port 20
the server opens a TCP data
FTP
connection to client
FTP
client
server
After transferring file,
server closes data connection
 Control connection: “out of
Server opens a new TCP data
band”
connection to transfer another
 FTP server maintains “state”:
file.
current directory, earlier
authentication
Application Layer 2-39
FTP commands, responses
Sample commands:
Sample return codes
 sent as ASCII text over
 status code and phrase (as
control channel
 USER username
 PASS password
 LIST return list of file in


current directory
 RETR filename retrieves

 STOR filename stores

(gets) file
(puts) file onto remote
host
in HTTP)
331 Username OK,
password required
125 data connection
already open;
transfer starting
425 Can’t open data
connection
452 Error writing
file
Application Layer 2-40
FTP example
$ Telnet ftp.microsoft.com 21
220 CPMSFTFTPA06 Microsoft FTP Service (Version 5.0).
Connected to: Microsoft
USER anonymous
331 Anonymous access allowed, send identity (e-mail name) as password.
PASS
230-This is FTP.MICROSOFT.COM Please see the dirmap.txt
230-file for more information.
230 Anonymous user logged in.
SYST
215 Windows2000
PWD
257 "/" is current directory.
TYPE A
200 Type set to A.
PORT 157,193,122,155,4,18
200 PORT command successful.
LIST
CWD /products/
150 Opening ASCII mode data connection
forcommand
/bin/ls.
250 CWD
successful.
226 Transfer complete.
TYPE A
200 Type set to A.
PORT 157,193,122,155,4,19
200 PORT command successful.
LIST
150 Opening ASCII mode data connection for /bin/ls.
Application Layer 2-41
226 Transfer complete.
FTP example
Application Layer 2-42
Chapter 2 outline
 2.1 Principles of app layer protocols
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail
 SMTP, POP3, RFC822, IMAP
 2.5 DNS
Application Layer 2-43
Electronic mail
User agent (UA)
Email client
(e.g. Pine, Eudora)
Message Transfer Agent (MTA)
Email server, SMTP server
(e.g. sendmail)
SMTP
SMTP
Port 25
mail
server
Simple Mail Transfer Protocol
Internet
SMTP
SMTP
Port 25
POP3
Post Office Protocol
POP3
Port 110
there may be
intermediate
MTA’s
mail
server
outgoing
message queue
user mailbox
Application Layer 2-44
Electronic mail protocols/formats
SMTP (Simple Mail Transfer Protocol) :
transfer e-mail message from UA to MTA or between MTAs
POP3 (Post Office Protocol 3)
retrieve e-mail from MTA
IMAP (Internet Message Access Protocol)
advanced retrieve of e-mail from MTA
intelligence in MTA (also advanced database structure)
RFC 822 (message format)
format of a plain text message
MIME (Multipurpose Internet Mail Extensions)
format and coding of non plain text messages (e.g. JPEG, Word)
and split into several sub-messages (e.g. attachments)
Application Layer 2-45
Electronic mail : SMTP
acnet0:/home/staff/janedoe$
telnet mailserver 25
Trying 157.193.84.4...
Connected to mailserver.intec.rug.ac.be.
Escape character is '^]'.
220 mailserver.intec.rug.ac.be ESMTP Sendmail 8.9.0/8.9.0; Fri, 11 Feb 2000 10:36:18
+0100 (MET)
HELO intec.rug.ac.be
250 mailserver.intec.rug.ac.be Hello acnet0.intec.rug.ac.be [157.193.84.63],
pleased to meet you
MAIL FROM:<[email protected]>
250 <[email protected]>... Sender ok
RCPT TO:<[email protected]>
250 <[email protected]>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Subject: example message
John,
hier een kleine test-boodschap.
.
250 KAA29013 Message accepted for delivery
Application Layer 2-46
Electronic mail : POP3
intec2:home/staff/johndoe$
telnet allserv 110
Trying 157.193.40.42...
Connected to allserv.rug.ac.be.
Escape character is '^]'.
+OK QPOP (version 2.2) at allserv.rug.ac.be starting.
<[email protected]>
USER johndoe
+OK Password required for johndoe.
PASS <right password>
+OK johndoe has 145 messages (8421978 octets).
STAT
+OK 145 8421978
LIST 125
+OK 125 1596
RETR 125
+OK 1596 octets
< RFC822-headers + MIME-headers + message contents> (see next slide)
POP3 (also HTTP) : pull protocol <> SMPT : push protocol
Application Layer 2-47
IMAP (Internet Message Access Protocol)
 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
IMAP3
(port 220)
Web based e-mail access : HTTP protocol
IMAP
mail
server
+ archive
(port 25)
SMTP
Application Layer 2-48
Mail message format
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
Application Layer 2-49
Message format: multimedia extensions
 MIME (Multipurpose Internet Mail Extensions) : multimedia
mail extension, RFC 2045, 2056
 additional lines in msg 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
Application Layer 2-50
Mail message format example
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: from mserv.rug.ac.be (mserv.rug.ac.be [157.193.40.37])
by allserv.rug.ac.be (8.9.3/8.9.3) with ESMTP id RAA19192
for <[email protected]>; Fri, 11 Feb 2000 10:39:45 +0100
(MET)
Received: from mailserver.intec.rug.ac.be (mailserver.intec.rug.ac.be
[157.193.84.3])
by mserv.rug.ac.be (8.9.3/8.9.3) with ESMTP id RAA21860
for <[email protected]>; Fri, 11 Feb 2000 10:39:19 +0100 (MET)
Received: from acnet0.intec.rug.ac.be (acnet0.intec.rug.ac.be
[157.193.84.63])
by mailserver.intec.rug.ac.be (8.9.3/8.9.3) with SMTP id RAA19039
for <[email protected]>; Fri, 11 Feb 2000 10:38:41 +0100 (MET)
Date: Fri, 11 Feb 2000 10:38:41 +0100 (MET)
From: Jane Doe <[email protected]>
Subject: example message
Message-Id: <[email protected]>
MIME-Version: 1.0
Content-Type: text
Content-Length: 34
John,
hier een kleine test-boodschap.
.
RFC 822
headers
MIME
headers
Message
Application Layer
2-51
Mail message format example
<RFC822 headers left away>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_909671503==_"
X-UIDL: 8adae81620fdf73614975fcaa08a3ed5
Status: O
X-Status:
--=====================_909671503==_
Content-Type: text/plain; charset="us-ascii"
RFC 822 headers
John,
This is an email message with two attached MS-Word documents.
Message
--=====================_909671503==_
Content-Type: application/msword; name="MIMEtest1.doc";
x-mac-type="42494E41"; x-mac-creator="4D535744"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="MIMEtest1.doc"
MIME
header
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAIQAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
...
AAAAAAAAAAAAAAAAAAAAAAAAAA==
--=====================_909671503==_
Content-Type: application/msword; name="MIMEtest2.doc";
x-mac-type="42494E41"; x-mac-creator="4D535744"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="MIMEtest2.doc"
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAIQAAAAAAAAAA
EAAAIwAAAAEAAAD+////AAAAACAAAAD/////////////////////////////////////////////
...
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAA==
--=====================_909671503==_-.
Les 3-4
MIME
header
Attachment1
MIME
header
Attachment2
End Of Message
Application Layer 2-52
Chapter 2 outline
 2.1 Principles of app layer protocols
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail
 2.5 DNS
Application Layer 2-53
DNS : Domain Name System
DNS : application layer protocol using distributed database
to provide name to address translation
• Two possible identifications : name or address
• Name : used by Internet users
• Address : used by Internet hardware
Address : 4 bytes (4 numbers with values between 0 and 255)
example : 157.193.40.7 (corresponding to inf6serv.ugent.be server)
advantage : fixed limited length, hierarchical, easy to handle
in the network, physical structure of the network
Name : mnemonic : xxx.xxx. … .xxx
- example : intec.ugent.be
- advantage : readable, independence of name and address,
logical structure of an organization
Some examples (at INTEC):
www.intec.ugent.be <==> 157.193.173.228 (Web server) [<==> webserver3.intec.ugent.be]
mail.intec.ugent.be <==> 157.193.172.4 (Mail server) [<==> mail-tech.intec.ugent.be]
mail2.intec.ugent.be <==> 157.193.214.4 (Mail server) [<==> plinius.intec.ugent.be]
Application Layer 2-54
plato.intec.ugent.be <==> 157.193.173.140 (a host)
DNS : Domain Name System
root
com
alcatel
org
...
ac
rug.ac.be
fr
be
com
gov
ac
rug
vub
kuleuven
telin intec2
recently : rug.ac.be ugent.be
elis
ovidius
host
• hierarchical
beckket
• distributed assignment
• relative distinguished names
• logical structure of organization
alcatel
domain
lucent
edu
ovidius.intec2.rug.ac.be
Application Layer 2-55
DNS : Domain Name System
• different names for same IP address : aliases
www.intec.ugent.be and webserver3.intec.ugent.be
• different IP addresses for one name
www.cnn.com : Addresses: 64.236.24.20, 64.236.24.28, 64.236.16.20, 64.236.16.52,
64.236.16.84, 64.236.16.116, 64.236.24.4, 64.236.24.12
• absolute name : intec.ugent.be.
full name specification (up to highest level) : end with a “.”
• relative name : intec.ugent
only lower level specified (higher level is known from the context)
• location of name server should not be within the domain
e.g. ugent.be has a (back-up) name server at ns.belnet.be (193.190.198.10)
• transport layer : UDP for DNS queries and answers
• transport layer : TCP for zone transfers
(=exchange of data between name servers)
Application Layer 2-56
DNS : Domain Name System
Questions to be answered :
-1- What is the IP address of tacitus.intec.ugent.be ?
-2- Who is the name server for the “ugent.be” domain ?
-3- Who is the mail server for [email protected] ?
-4- What is the canonical name of mail.intec.ugent.be ?
Application Layer 2-57
DNS : mapping name to address
• Resolver : local program (client side) sending
out
a NSI Herndon,
VA a mapping request
k RIPE London
c PSInet Herndon, VA
d
U
Maryland
College
Park,
MD
i NORDUnet Stockholm
(allserv.ugent.be ?) to local
name server
g DISA Vienna, VA
m WIDE Tokyo
(TBD) Herndon, VArequest from client
• Local name server (default name server)j NSI: handles
e NASA Mt View, CA
f Internet Software
Palo Alto,
contacts other
nameC. server(s)
to resolve the name
CA
h ARL Aberdeen, MD
• Root name server : top level root server (13 in total)
• Authoritative name server : where host (requested name) is registered
b USC-ISI Marina del Rey, CA
l ICANN Marina
del Rey, CA
(at least two authoritative
name
servers for each host)
allserv.ugent.be ?
Local
DNS server
resolver
client
1
Root
DNS server
2
5
4
6
157.193.40.42
recursive
3
Authoritative
DNS server
Application Layer 2-58
DNS : mapping name to address
Root
DNS server
2
3
4
Local
DNS server
resolver
client
1
5
Intermediate
DNS server
6
8
7
Authoritative
DNS server
iterative
Application Layer 2-59
DNS : mapping name to address
Root
DNS server
2
3
Local
DNS server
resolver
1
8
4
7
Intermediate
DNS server
iterative + recursive
client
6
5
Authoritative
DNS server
caching of name/address translation pairs
•
•
•
•
caching in intermediate name servers
improve delay performance of name/address translation
reduce number of DNS queries on the network
Layer 2-60
cached record is valid limited in timeApplication
(few days)
DNS : Resource Records (RR)
What to store in a DNS :
-
list of the worldwide root servers
list of names (host, name server, …) and their corresponding address
alias names and their canonical name
list of addresses and their corresponding names (for inverse look-up)
- ...
How to store information in the DNS databases ?
Resource Record (RR) :
[name], [TTL], [class], record-type, record-data
name : name to be resolved
TTL : how long record may be cached
class : IN (for Internet)
record-type : e.g.: NS, A, MX, CNAME
record-data : e.g.: IP address
Application Layer 2-62
DNS : Resource Records (RR)
Record-Types / Record-Data :
A : the name is a hostname and the record-data is the IP-address
plinius.intec.ugent.be IN A 157.193.214.4
NS : the name is a domain and the record-data is the hostname of
a server that knows how to obtain the IP addresses in that domain
ugent.be IN NS ugdns1.ugent.be (authoritative name server for ugent.be)
intec2.ugent.be IN NS ugdns1.ugent.be (intermediate name server for intec2.ugent.be)
CNAME : the name is an alias for a hostname and the record-data
is the corresponding canonical hostname
mail2.intec.ugent.be IN CNAME plinius.intec.ugent.be
MX : the name is a domain name and the record-data
is the corresponding name of a mail server (MTA), preference
indicates the primary, secondary, … mail servers for the domain
intec.ugent.be
IN
MX
preference=10 mail-tech.intec.ugent.be
preference=30 cedar.ugent.be
preference=30 pecan.ugent.be
Application Layer 2-63
DNS : Messages
header
ID
QR|Op Code|AA|TC|RD|RA|Z|RCODE
questions
number of questions
answers
number of answers
authority
additional
number of authority records
number of additional records
Application Layer 2-64
DNS : Message : Request
$
>
>
Working on local PC
nslookup
set type=A
debug mode
set d2
plinius.intec2.ugent.be
>
Server: dns5.intec.ugent.be
Address: 157.193.122.2
dns5.intec.ugent.be is the default DNS server
-----------SendRequest(), len 41
HEADER:
opcode = QUERY, id = 111, rcode = NOERROR
header flags: query, want recursion
questions = 1, answers = 0, authority records = 0,
additional = 0
IP address for host plinius.intec2.ugent.be
QUESTIONS:
plinius.intec2.ugent.be, type = A, class = IN
Application Layer 2-65
DNS : Messages : Answer
Got answer (162 bytes):
HEADER:
opcode = QUERY, id = 111, rcode = NOERROR
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 1, additional = 1
QUESTIONS:
plinius.intec2.ugent.be, type = A, class = IN
ANSWERS:
This is the requested answer :
-> plinius.intec2.rug.ac.be
plinius has IP address 157.193.122.4
type = A, class = IN, dlen = 4
(it is an A record)
internet address = 157.193.122.4
ttl = 86400 (1 day)
This is the nameserver that was able to give the answer
AUTHORITY RECORDS:
(it is an NS record)
-> intec2.ugent.be
type = NS, class = IN, dlen = 10
nameserver = tacitus.intec2.ugent.be
ttl = 86400 (1 day)
ADDITIONAL RECORDS:
-> tacitus.intec2.ugent.be
type = A, class = IN, dlen = 4
This is the IP address of the nameserver
internet address = 157.193.122.1
(it is an
A record)
ttl = 86400 (1 day)
Application
Layer 2-66
Example : DNS + e-mail
email client
at intec2
Local MTA
plinius.intec2
MTA 2
1
email to
jane.doe@
cse.ucsc.edu
19
18
13
12
MTA 4
MTA 3
20
resolve (MX)
cse.ucsc.edu
2
resolve (MX)
it.cse.ucsc.edu
11
14
local DNS intec2
3
root DNS
4
17
.forward :
jane.doe@
it.cse.ucsc.edu
10
5
cse.ucsc.edu
DNS
edu
DNS
6
9
ucsc.edu
DNS
15
it.cse.ucsc.edu
DNS
16
7
8
MTA2 = terra.cse.ucsc.edu
MTA3 = sundance.cse.ucsc.edu
MTA4 = mail.it.cse.ucsc.edu
Application Layer 2-67
Example : multiple MTA’s
Received: by plinius (mbox pietdm)
...
Received: from mail-tech.intec.ugent.be
by plinius.intec2.ugent.be
for <[email protected]
Received: from allserv.ugent.be
by mail-tech.intec.ugent.be
for <[email protected]>
Received: from mserv.ugent.be
by allserv.ugent.be
for <[email protected]>
Received: from plinius.intec2.ugent.be
by mserv.ugent.be
for <[email protected]>
Received: from ECO.intec2.ugent.be
by plinius.intec2.ugent.be
SMTP server = mail.intec2.ugent.be
for <[email protected]> (alias for plinius.intec2.ugent.be)
Application Layer 2-68
Example : multiple MTA’s
my computer
eco.intec2.ugent.be
email to
piet.demeester@
ugent.be
my local mail server
at INTEC2 (Urbis)
mail.intec2.ugent.be
=plinius.intec2.ugent.be
mail server for ugent.be
mserv.ugent.be
Split mails to :
eduserv1
eduserv2
allserv
Split mails to :
INTEC (local)
INTEC2 (Urbis)
mail server
for intec.ugent.be
.forward
to intec.ugent.be
mail-tech.intec.ugent.be
allserv.ugent.be
Application Layer 2-69
Chapter 2 Summary
Our study of network apps now complete!
 application service
 specific protocols:
requirements:
 HTTP
 reliability, bandwidth,
 FTP
delay
 SMTP, POP, IMAP
 client-server paradigm
 DNS
 Internet transport
service model


connection-oriented,
reliable: TCP
unreliable, datagrams:
UDP
Application Layer 2-70
Chapter 2 Summary
Most importantly: learned about protocols
 typical request/reply
message exchange:
 control vs. data msgs
 in-band, out-of-band
client requests info or
 centralized vs. decentralized
service
 stateless vs. stateful
 server responds with
 reliable vs. unreliable msg
data, status code
transfer
 message formats:
 “complexity at network
 headers: fields giving
edge”
info about data
 security: authentication
 data: info being
communicated

Application Layer
2-71
Table of contents
 2.1 Principles of app layer protocols
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail
 2.5 DNS
 Summary
 Table of contents
3
16
37
43
53
70
72
Application Layer 2-72