Transcript Application Layer

CMPT 371
Data Communications
and Networking
Chapter 2
Application Layer
2: Application Layer
1
Chapter 2: Application Layer
Our goals:
 conceptual,
implementation
aspects of network
application protocols
 transport-layer
service models
 client-server
paradigm

peer-to-peer
paradigm
 learn about protocols
by examining popular
application-level
protocols




HTTP
FTP
SMTP / POP3 / IMAP
DNS
 programming network
applications

socket API
2: Application Layer
2
Chapter 2 outline
 2.1 Principles of app layer protocols
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Content distribution
 Network Web caching
 Content distribution networks
 P2P file sharing
2: Application Layer
3
Some network apps
 e-mail
 voice over IP (e.g.,
 web
 text messaging
 remote login
 P2P file sharing
 multi-user network
games
 streaming stored video
(YouTube, Hulu,
Netflix)





Skype)
real-time video
conferencing
social networking
search
…
…
Application Layer
2-4
Network applications
 Applications -> Software
 What exactly running in a computer ?
2: Application Layer
5
Network applications: some jargon
Process: program running
within a host.
 implements user
interface &
application-level
protocol



Web: browser
E-mail: mail reader
streaming audio/video:
media player
 within same host, two
processes communicate
using interprocess
communication (defined
by OS).
 processes running in
different hosts
communicate with an
application-layer
protocol
2: Application Layer
6
Creating a network app
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
 (user) applications on end
systems allows for rapid app
development, propagation
application
transport
network
data link
physical
application
transport
network
data link
physical
application
transport
network
data link
physical
Application Layer
2-7
Applications and application-layer protocols
Application: communicating,
distributed processes



e.g., e-mail, Web, P2P file
sharing, instant messaging
running in end systems
(hosts)
exchange messages to
implement application
application
transport
network
data link
physical
Application-layer protocols



one “piece” of an app
define messages
exchanged by apps and
actions taken
use communication services
provided by lower layer
protocols (TCP, UDP)
application
transport
network
data link
physical
application
transport
network
data link
physical
2: Application Layer
8
App-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, Skype
 BitTorrent (?)
2: Application Layer
9
Client-server paradigm
Typical network app has two
pieces: client and server
Client:
application
transport
network
data link
physical
 initiates contact with server
(“speaks first”)
 typically requests service from
server,
 Web: client implemented in
browser; e-mail: in mail reader
Server:
 provides requested service to client
request
reply
application
transport
network
data link
physical
 e.g., Web server sends requested Web
page, mail server delivers e-mail
2: Application Layer
10
Programming - Socket
clients, servers
client process: process that
 process sends/receives
initiates communication
messages to/from its
socket
application
process
server process: process that
waits to be contacted
socket
application
process
transport
transport
network
network
link
physical
Internet
link
controlled by
app developer
controlled
by OS
physical
2: Application Layer
11
Programming - Socket
 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/UDP
with
buffers,
variables
Internet
TCP/UDP
with
buffers,
variables
controlled
by OS
 API: Application Programmer’s Interface
(1) choose transport protocol; (2) set parameters
2: Application Layer
12
Socket Example: UDP
server (running on serverIP)
create socket, port= x:
serverSocket =
socket(AF_INET,SOCK_DGRAM)
read datagram from
serverSocket
write reply to
serverSocket
specifying
client address,
port number
client
create socket:
clientSocket =
socket(AF_INET,SOCK_DGRAM)
Create datagram with server IP and
port=x; send datagram via
clientSocket
read datagram from
clientSocket
close
clientSocket
Application 2-13
Socket Example: UDP
include Python’s socket
library
create UDP socket for
server
get user keyboard
input
Attach server name, port to
message; send into socket
read reply characters from
socket into string
print out received string
and close socket
from socket import *
serverName = ‘hostname’
serverPort = 12000
clientSocket = socket(socket.AF_INET,
socket.SOCK_DGRAM)
message = raw_input(’Input lowercase sentence:’)
clientSocket.sendto(message,(serverName, serverPort))
modifiedMessage, serverAddress =
clientSocket.recvfrom(2048)
print modifiedMessage
clientSocket.close()
Application Layer
214
Outside of the door – Transport Layer Service
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
2: Application Layer
15
Transport service requirements of common apps
Data loss
Bandwidth
Time Sensitive
file transfer
e-mail
Web documents
real-time audio/video
no loss
no loss
no loss
loss-tolerant
no
no
no
yes, 100’s msec
stored audio/video
interactive games
instant messaging
loss-tolerant
loss-tolerant
no loss
elastic
elastic
elastic
audio: 5kbps-1Mbps
video:10kbps-5Mbps
same as above
few kbps up
elastic
Application
yes, few secs
yes, 100’s msec
yes and no
2: Application Layer
16
Internet apps: application, transport protocols
Application
e-mail
remote terminal access
Web
file transfer
streaming multimedia
Internet telephony
Application
layer protocol
SMTP [RFC 2821]
Telnet [RFC 854]
HTTP [RFC 2616]
FTP [RFC 959]
proprietary
(e.g. YouTube)
proprietary
(e.g., Skype)
Underlying
transport protocol
TCP
TCP
TCP
TCP
TCP or UDP
TCP or UDP
2: Application Layer
17
Chapter 2 outline
 2.1 Principles of app layer protocols
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Content distribution
 Network Web caching
 Content distribution networks
 P2P file sharing
2: Application Layer
18
Web and HTTP
First some jargon
 Web page consists of objects
 Object can be HTML file, JPEG image, Java
applet, audio file,…
 Most Web sites have a base HTML-file which
includes several referenced objects
 Each object is addressable by a URL
 Example URL:
http://www.cs.sfu.ca/~jcliu/cmpt371/index.htm
host name
path name
2: Application Layer
19
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
Firefox browser
server
running
Apache Web
server
iphone running
Safari browser
2: Application Layer
20
Is it difficult to write a Browser ?
MS Internet Explorer/Edge
Safari
FireFox
Chrome
…
2: Application Layer
21
Trying out HTTP (client side) for yourself
1. Telnet to your favorite Web server:
telnet www.cs.sfu.ca 80
Opens TCP connection to port 80
(default HTTP server port) at www.cs.sfu.ca
Anything typed in sent
to port 80
2: Application Layer
22
Trying out HTTP (client side) for yourself
1. Telnet to your favorite Web server:
telnet www.cs.sfu.ca 80
Opens TCP connection to port 80
(default HTTP server port) at www.cs.sfu.ca
Anything typed in sent
to port 80
2. Type in a GET HTTP request:
GET
or
GET /~jcliu/index.htm
You have sent this minimal (but complete)
GET request to HTTP server
And you have received HTML objects !
2: Application Layer
23
Is it difficult to write a Browser ?
Internet Explorer
Chrome
FireFox
…
 Implement HTTP - network
 Implement a GUI - local
 Anymore ?

Efficiency, fault-tolerant, compatibility, security, Javasupport, multi-language …
2: Application Layer
24
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
25
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
26
HTTP request message: general format
method
sp
URL
header field name
sp
value
version
cr
cr
value
cr
request
line
header
lines
~
~
header field name
lf
lf
~
~
~
~
cr
lf
lf
entity body
~
~
body
2: Application Layer
27
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
28
Method types
HTTP/1.0
 GET
 POST
 HEAD


asks server to leave
requested object out of
response
debugging
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
2: Application Layer
29
HTTP response message
status line
(protocol
status code
status phrase)
header
lines
data, e.g.,
requested
HTML file
HTTP/1.1 200 OK
Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html
data data data data data ...
2: Application Layer
30
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
31
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
2: Application Layer
32
Nonpersistent HTTP
(contains text,
Suppose user enters URL
references to 10
www.someSchool.edu/someDepartment/home.index jpeg images)
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
33
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 referenced jpeg
objects
time 6. Steps 1-5 repeated for each
of 10 jpeg objects
2: Application Layer
34
None-Persistent HTTP: Response time
RTT (definition): 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
initiate TCP
connection
RTT
request
file
RTT
file
received
time
time
2: Application Layer
35
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
2: Application Layer
36
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
2: Application Layer
37
HTTP Request Format: Update
 HTTP request message:
 ASCII (human-readable format)
request line
(GET, POST,
HEAD commands)
header
lines
carriage return,
line feed at start
of line indicates
end of header lines
carriage return character
line-feed character
GET /index.html HTTP/1.1\r\n
Host: www-net.cs.umass.edu\r\n
User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
Keep-Alive: 115\r\n
Connection: keep-alive\r\n
\r\n
User-server interaction: authorization
Authorization : control access to
server
client
server content
usual http request msg
 authorization credentials:
typically name, password
401: authorization req.
WWW authenticate:
 stateless: client must present
authorization in each request
 authorization: header line in
usual http request msg
+ Authorization: <cred>
each request
 if no authorization: header,
usual http response msg
server refuses access,
sends
WWW authenticate:
header line in response
usual http request msg
+ Authorization: <cred>
usual http response msg
time
2: Application Layer
39
Cookies: keeping “state”
Many Web sites use
cookies
Example:



You access Internet
always from same PC
You visit 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
2: Application Layer
40
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
2: Application Layer
41
Cookies: keeping “state” (cont.)
client
Cookie file
server
usual http request msg
usual http response +
ebay: 8734
Cookie file
amazon: 1678
ebay: 8734
Set-cookie: 1678
usual http request msg
cookie: 1678
usual http response msg
one week later:
Cookie file
amazon: 1678
ebay: 8734
usual http request msg
cookie: 1678
usual http response msg
server
creates ID
1678 for user
cookiespecific
action
cookiespectific
action
2: Application Layer
42
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
2: Application Layer
43
Cookies: Enable/Disable
2: Application Layer
44
Cookies: Delelte
2: Application Layer
45
Chapter 2 outline
 2.1 Principles of app layer protocols
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Content distribution
 Network Web caching
 Content distribution networks
 P2P file sharing
2: Application Layer
46
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

2: Application Layer
47
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
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
48
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
2: Application Layer
49
FTP Client Software
2: Application Layer
50
Port 21 ?
2: Application Layer
51
Secure FTP (http://www.ssh.com/)
“ssh never trusts the net; somebody
hostile who has taken over the network
can only force ssh to disconnect, but
cannot decrypted or play back the
traffic, or hijack the connection. “
2: Application Layer
52
Key differences between HTTP & FTP
 Stateless vs. stateful
 Inband control vs. outband control
 Why ?
2: Application Layer
53
Chapter 2 outline
 2.1 Principles of app layer protocols
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Content distribution
 Network Web caching
 Content distribution networks
 P2P file sharing
2: Application Layer
54
Electronic Mail
outgoing
message queue
user mailbox
user
agent
Three major components:
 user agents
 mail servers
mail
server
user
agent
 mail transfer protocol
User Agent
 a.k.a. “mail reader”
 composing, editing, reading
mail messages
 e.g., Eudora, Outlook, elm,
Netscape Messenger
 outgoing, incoming messages
stored on server
mail
server
user
agent
mail
server
user
agent
user
agent
user
agent
2: Application Layer
55
Electronic Mail: mail servers
?
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
user
agent
mail
server
SMTP
SMTP
mail
server
user
agent
SMTP
user
agent
mail
server
user
agent
user
agent
user
agent
2: Application Layer
56
Electronic Mail: SMTP [RFC 2821]
 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
57
Scenario: Alice sends message to Bob
1) Alice uses UA to compose
message and “to”
[email protected]
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
1
user
agent
2
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
mail
server
4
5
6
user
agent
2: Application Layer
58
Sample SMTP interaction
S:
C:
S:
C:
S:
C:
S:
C:
S:
C:
C:
C:
S:
C:
S:
220 hamburger.edu
HELO crepes.fr
250 Hello crepes.fr, 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
Do you like ketchup?
How about pickles?
.
250 Message accepted for delivery
QUIT
221 hamburger.edu closing connection
2: Application Layer
59
Try SMTP interaction for yourself:
 telnet servername 25
2: Application Layer
60
Try SMTP interaction for yourself:
 telnet smtp.sfu.ca 25
(mailgate.sfu.ca 465
SSLv2
http://www.sfu.ca/itservices/sfuconnect/getstarted/accessmethods/ssl_background_
)
 see 220 reply from server
 enter HELO, MAIL FROM, RCPT TO, DATA, QUIT
commands
above lets you send email without using email client
(reader)
info.html
-- note: SFU IT service has upgraded their system
and now supports only SSL connections
2: Application Layer
61
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 msg
 SMTP: multiple objects
sent in multipart msg
2: Application Layer
62
Message format: multimedia extensions
 ASCII: http://www.asciitable.com/
 MIME: 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
2: Application Layer
63
MIME types
Content-Type: type/subtype; parameters
Text
 example subtypes: plain,
html
Image
 example subtypes: jpeg,
gif
Audio
 example subtypes: basic
(8-bit mu-law encoded),
32kadpcm (32 kbps
coding)
Video
 example subtypes: mpeg,
quicktime
Application
 other data that must be
processed by reader
before “viewable”
 example subtypes:
msword, octet-stream
2: Application Layer
64
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 recipe?
2: Application Layer
65
MIME types
Content-Type: type/subtype; parameters
An Example: MailEncodingExample.txt
------=_NextPart_000_0010_8CEC7DC6.92E25D8C
Content-Type: application/octet-stream;
name="readme.scr"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="readme.scr"
TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUA
AEwBAwAAAAAAAAAAAAAAAADgAA8BCwEHAABQAAAAEAAAAGAAAGC+AAAAcAAAAMAAAAAASgAAEAAA
AAIAAAQAAAAAAAAABAAAAAAAAAAA0AAAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQ
AAAAAAAAAAAAAADowQAAMAEAAADAAADoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAABVUFgwAAAAAABgAAAAEAAAAAAAAAAEAAAAAAAAAAAAAAAAAACAAADg
VVBYMQAAAAAAUAAAAHAAAABQAAAABAAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADAAAAA
BAAAAFQAAAAAAAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
……
2: Application Layer
66
Coding for MIME
Key issue: Binary data (bit string) to plain text (SMTP
message)
Simple solution: 8 bit -> one plain text symbol (?)
2: Application Layer
67
ASCII Table

Beyond 7 bit?


Extended ASCII
Never “well defined”
2: Application Layer
68
Base 64 coding – more info (RFC1521)
A 65-character subset of US-ASCII is used, enabling 6
bits to be represented per printable character. (The
extra 65th character, "=", is used to signify a special
processing function.)
NOTE: This subset has the important property that it is represented
identically in all versions of ISO 646, including US ASCII, and all
characters in the subset are also represented identically in all versions
of EBCDIC. Other popular encodings, such as the encoding used by the
uuencode utility and the base85 encoding specified as part of Level 2
PostScript, do not share these properties, and thus do not fulfill the
portability requirements a binary transport encoding for mail must
meet.
2: Application Layer
69
Base 64 coding – more info (RFC1521)
The 64 characters
A-Z a-z 0-9 + / =
2: Application Layer
70
Mail access protocols
user
agent
?
SMTP
sender’s mail
server
?
user
agent
receiver’s mail
server
2: Application Layer
71
Mail access protocols
user
agent
SMTP
SMTP
sender’s mail
server
access
protocol
user
agent
receiver’s mail
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.
2: Application Layer
72
WebMail
 Hotmail/Gmail
 SFU Webmail:
webmail.sfu.ca (old)/connect.sfu.ca
2: Application Layer
73
POP3 protocol
authorization phase
 client commands:
user: declare username
 pass: password
 server responses
 +OK
 -ERR

transaction phase, client:
 list: list message numbers
 retr: retrieve message by
number
 dele: delete
 quit
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
2 912
.
retr 1
<message 1 contents>
.
dele 1
retr 2
<message 1 contents>
.
dele 2
quit
+OK POP3 server signing off
2: Application Layer
on
74
POP3 (more) and IMAP
More about POP3
 Previous example uses
“download and delete”
mode.
 Bob cannot re-read email if he changes
client
 “Download-and-keep”:
copies of messages on
different clients
 POP3 is stateless
across sessions
 newpop.sfu.ca 995
SSLv2
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
2: Application Layer
75
Chapter 2 outline
 2.1 Principles of app layer protocols
 2.2 Web and HTTP
 2.3 FTP
 2.4 Electronic Mail
 SMTP, POP3, IMAP
 2.5 DNS
 2.6 Content distribution
 Network Web caching
 Content distribution networks
 P2P file sharing
2: Application Layer
76
Name vs. ID
 People: many identifiers:
 name, passport #, driving license ID, SIN
 Example:
I want to talk to J.C. Liu. -- from Friend
Please tell me you driving license ID. -- from
Visa card service
2: Application Layer
77
DNS: Domain Name System
People: many identifiers:

SIN, name, passport #
Internet hosts, routers:


IP address (32 bit) used for addressing
datagrams
“name”, e.g.,
www.sfu.ca- used by
humans
Q: map between IP
addresses and name ?
Domain Name System:
 distributed database
implemented in hierarchy of
many name servers
 application-layer protocol
host, routers, name servers to
communicate to resolve names
(address/name translation)
 note: core Internet
function, implemented as
application-layer protocol
 complexity at network’s
“edge”
2: Application Layer
78
DNS name servers
Centralize DNS? No
 single point of failure
 traffic volume
 distant centralized
database
 maintenance
 no server has all name-to-IP
address mappings
doesn’t scale!
2: Application Layer
79
Name servers: Authoritative
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
2: Application Layer
80
Name servers: Local
 each ISP (residential ISP, company, university) has
one

also called “default name server”
 when host makes DNS query, 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
2: Application Layer
81
DNS: Client Settings
2: Application Layer
82
DNS: Root name servers
 contacted by local name server that can not resolve name
 root DNS server:



contacts authoritative name server if name mapping not known
gets mapping
returns mapping to local name server
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
83
Name servers: Top-level
top-level domain (TLD) servers:



responsible for com, org, net, edu, aero, jobs, museums, and
all top-level country domains, e.g.: uk, fr, ca, jp
Network Solutions maintains servers for .com TLD
Educause for .edu TLD
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
2: Application Layer
84
Simple DNS example
host surf.eurecom.fr
wants IP address of
gaia.cs.umass.edu
root name server
2
4
5
1. contacts its local DNS
server, dns.eurecom.fr
2. dns.eurecom.fr contacts local name server
dns.eurecom.fr
root name server, if
necessary
1
6
3. root name server contacts
authoritative name server,
dns.umass.edu, if
requesting host
necessary
surf.eurecom.fr
3
authorititive name server
dns.umass.edu
gaia.cs.umass.edu
2: Application Layer
85
DNS example
root name server
Root name server:
 may not know
authoritative name
server
 may know
intermediate name
server: who to
contact to find
authoritative name
server
6
2
7
local name server
dns.eurecom.fr
1
8
requesting host
3
intermediate name server
dns.umass.edu
4
5
authoritative name server
dns.cs.umass.edu
surf.eurecom.fr
gaia.cs.umass.edu
2: Application Layer
86
DNS: iterated queries
recursive query:
iterated query:
3
4
7
local name server
dns.eurecom.fr
1
8
 contacted server
replies with name of
server to contact
 “I don’t know this
name, but ask this
server”
iterated query
2
 puts burden of name
resolution on
contacted name
server
 heavy load at upper
nodes?
root name server
requesting host
intermediate name server
dns.umass.edu
5
6
authoritative name server
dns.cs.umass.edu
surf.eurecom.fr
gaia.cs.umass.edu
2: Application Layer
87
DNS: caching and updating records
 once (any) name server learns mapping, it caches
mapping
 cache entries timeout (disappear) after some
time (Time-to-Live, TTL)
 TLD servers typically cached in local name
servers
• thus root name servers not often visited
 update/notify mechanisms under design by IETF
 RFC 2136

http://www.ietf.org/html.charters/dnsind-charter.html
2: Application Layer
88
DNS records
DNS: distributed db 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
“canonical” (the real) name
www.ibm.com is really
 Type=NS
servereast.backup2.ibm.com
 name is domain (e.g.
 value is canonical name
foo.com)
 value is IP address of
 Type=MX
authoritative name
 value is name of mailserver
server for this domain
associated with name
2: Application Layer
89
DNS protocol, messages
DNS protocol : query and reply messages, both with
same message format
2 bytes
2 bytes
msg header
identification
flags
 identification: 16 bit #
# questions
# answer RRs
# authority RRs
# additional RRs
for query, reply to query
uses same #
 flags:
 query or reply
 recursion desired
 recursion available
 reply is authoritative
questions (variable # of questions)
answers (variable # of RRs)
authority (variable # of RRs)
additional info (variable # of RRs)
2: Application Layer
90
DNS protocol, messages
Name, type fields
for a query
RRs in response
to query
records for
authoritative servers
additional “helpful”
info that may be used
2: Application Layer
91
Attacking DNS
DDoS (Distributed Denial-of-Service)
attacks
 Bombard root servers
with traffic



Not successful to date
Traffic Filtering
Local DNS servers
cache IPs of TLD
servers, allowing root
server bypass
 Bombard TLD servers
 Potentially more
dangerous
Redirect attacks
 Man-in-middle

Intercept queries
 DNS poisoning
 Send bogus relies to
DNS server, which
caches
Exploit DNS for DDoS
 Send queries with
spoofed source
address: target IP
 Requires amplification
2: Application Layer
92