Download - Chapter 2 outline
2: Application Layer 1
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
2.6 Socket programming with TCP
2.7 Socket programming with UDP
2.8 Building a Web server 2.9 Content distribution
Network Web caching Content distribution networks P2P file sharing
2: Application Layer 2
FTP: the file transfer protocol
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
file transfer FTPserver
FTPuser
interface
FTPclient
local filesystem
remote filesystem
user at host
2: Application Layer 3
FTP: separate control, data connections
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.
FTPclient
FTPserver
TCP control connection
port 21
TCP data connectionport 20
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 4
FTP commands, responses
Sample commands: sent as ASCII text over
control channel USER username PASS password LIST return list of file in
current directory RETR filename retrieves
(gets) file STOR filename stores
(puts) file onto remote host
Sample return codes status code and phrase
(as 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 5
Electronic Mail: components
Three major components: user agents, mail servers, SMTP
User Agent a.k.a. “mail reader” composing, editing, reading
mail messages e.g., Eudora, Outlook, elm,
Netscape MessengerMail 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 mailbox
outgoing message queue
mailserver
useragent
useragent
useragent
mailserver
useragent
useragent
mailserver
useragent
SMTP
SMTP
SMTP
2: Application Layer 6
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 7
Electronic Mail: scenario
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
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
useragent
mailserver
mailserver user
agent
1
2 3 4 56
Q: Why not route mail hop by hop toward destination?
2: Application Layer 8
Try SMTP interaction for yourself
% telnet po.cwru.edu 25 S: 220 ims-msg.TIS.CWRU.Edu – Server ESMTP??? C: HELO po S: 250 ims-msg.TIS.CWRU.Edu OK, csa.bu.edu [128.197.12.3] C: MAIL FROM: <[email protected]> S: 250 2.5.0 Address Ok C: RCPT TO: <[email protected]> S: 250 ??? 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 2.3.0 Bye received. Goodbye. Connection closed bu foreign host.
2: Application Layer 9
Electronic Mail: more on SMTP
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 10
Electronic Mail: message format
SMTP: protocol for exchanging email msgs
RFC 822: standard for text message format:
header lines, e.g., To: From: Subject:different from SMTP
commands! body
the “message”, ASCII characters only
header
body
blankline
2: Application Layer 11
Electronic Mail: MIME
MIME: multimedia mail extension, RFC 2045, 2056 additional lines in msg header declare MIME content type
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
multimedia datatype, subtype,
parameter declaration
method usedto encode data
MIME version
encoded data
2: Application Layer 12
Electronic Mail: MIME typesContent-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 13
Electronic Mail: mail access protocols
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• Originally designed more for connected operation
HTTP: Hotmail , Yahoo! Mail, etc.
useragent
sender’s mail server
useragent
SMTP SMTP accessprotocol
receiver’s mail server
2: Application Layer 14
Electronic Mail: 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
C: list S: 1 498 S: 2 912 S: . C: retr 1 S: <message 1 contents> S: . C: dele 1 C: retr 2 S: <message 1 contents> S: . C: dele 2 C: quit S: +OK POP3 server signing off
S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on
2: Application Layer 15
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: 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 16
DNS name servers
no server has all name-to-IP address mappings
local name servers: each ISP, company has local
(default) name server host DNS query first goes to
local name serverauthoritative name server:
for a host: stores that host’s IP address, name
can perform name/address translation for that host’s name
Why not centralize DNS? single point of failure traffic volume distant centralized database maintenance
doesn’t scale!
2: Application Layer 17
DNS: 13 root name servers
contacted by local name server that can not resolve name root name server:
contacts authoritative name server if name mapping not known gets mapping returns mapping to local name server
b USC-ISI Marina del Rey, CAl ICANN Marina del Rey, CA
e NASA Mt View, CAf Internet Software C. Palo Alto, CA
i NORDUnet Stockholm
k RIPE London
m WIDE Tokyo
a NSI Herndon, VAc PSInet Herndon, VAd U Maryland College Park, MDg DISA Vienna, VAh ARL Aberdeen, MDj NSI (TBD) Herndon, VA
13 root name servers worldwide
2: Application Layer 18
DNS: example name resolution
host surf.eurecom.fr wants IP address of gaia.cs.umass.edu
1. contacts its local DNS server, dns.eurecom.fr
2. dns.eurecom.fr contacts root name server, if necessary
3. may not know authoritative name server, but knows intermediate name server
4. who to contact to find authoritative name server
requesting hostsurf.eurecom.fr
gaia.cs.umass.edu
root name server
local name serverdns.eurecom.fr
1
23
4 5
6
authoritative name serverdns.cs.umass.edu
intermediate name serverdns.umass.edu
7
8
2: Application Layer 19
DNS: recursive versus iterative queries
recursive query: puts burden of name
resolution on contacted name server
heavy load?
iterative query: contacted server
replies with name of server to contact
“I don’t know this name, but ask this server” requesting host
surf.eurecom.fr
gaia.cs.umass.edu
root name server
local name serverdns.eurecom.fr
1
23
4
5 6
authoritative name serverdns.cs.umass.edu
intermediate name serverdns.umass.edu
7
8
iterative query
2: Application Layer 20
DNS: records, and caching/updating
DNS: distributed db storing resource records (RR) once (any) name server learns mapping, it caches mapping
cache entries timeout (disappear) after some time update/notify mechanisms under design by IETF
RFC 2136, http://www.ietf.org/html.charters/dnsind-charter.html
Type=NS name is domain (e.g. foo.com) value is IP address of
authoritative name server for this domain
RR format: (name, value, type, ttl)
Type=A name is hostname value is IP address
Type=CNAME name is alias name for some
“canonical” (the real) name www.ibm.com is really servereast.backup2.ibm.com value is canonical name
Type=MX value is name of mailserver
associated with name
2: Application Layer 21
DNS protocol, messages
Query and reply messages, both with same message format
msg header identification: 16-bit #,
reply uses same # flags:
query or reply recursion desired recursion available reply is
authoritative
Name, type fields for a query
RRs in responseto query
records forauthoritative servers
additional “helpful”info that may be used