1 / 29

CSE 524: Lecture 6

Application layer protocols. CSE 524: Lecture 6. Where we’re at…. Internet architecture and history Internet protocols in practice Application layer Overview and functions Network programming interface Specific application protocols HTTP DNS, SMTP/POP, FTP, P2P Transport layer

Download Presentation

CSE 524: Lecture 6

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Application layer protocols CSE 524: Lecture 6

  2. Where we’re at… • Internet architecture and history • Internet protocols in practice • Application layer • Overview and functions • Network programming interface • Specific application protocols • HTTP • DNS, SMTP/POP, FTP, P2P • Transport layer • Network layer • Data-link layer • Physical layer

  3. First….a quick refresher

  4. DNS lookup methods • Recursive queries • Server goes out and searches for more info on behalf of the client (recursive) • Only returns final answer or “not found” • Iterative • Server responds with as much as it knows (i.e. name of server to contact next) • Client iteratively queries additional servers

  5. root & edu DNS server www.cse.ogi.edu www.cse.ogi.edu NS ogi.edu ogi.edu DNS server Local DNS server NS cse.ogi.edu Client cse.ogi.edu DNS server www=IPaddr AL: DNS Lookup Caching Example

  6. cse.ogi.edu entry cached root & edu DNS server ftp.cse.ogi.edu ogi.edu DNS server Local DNS server Client ftp.cse.ogi.edu cse.ogi.edu DNS server ftp=IPaddr AL: Subsequent Lookup Example

  7. And now…

  8. AL: A word about iterated queries and caching • Recall • Recursive query to local DNS server • Iterative query from local DNS server on • Why not do iterative queries from host? • Win2k client • Does iterative queries from host • Caching implications?

  9. AL: DNS dig example • Real example using dig and named • Shows iterative queries, recursive queries, and caching • dig • cat /etc/resolv.conf • dig +norecurse www.thefengs.com. • dig @M.GTLD-SERVERS.NET. +norecurse www.thefengs.com. • dig @dns1.register.com. +norecurse www.thefengs.com. • dig +norecurse www.thefengs.com. • dig +recurse www.thefengs.com. • dig +norecurse www.thefengs.com.

  10. msg header • identification: 16 bit # for query, reply to query uses same # • flags: • query or reply • recursion desired • recursion available • reply is authoritative AL: DNS protocol, messages DNS protocol :queryand repy messages, both with same message format

  11. Name, type fields for a query RRs in reponse to query records for authoritative servers additional “helpful” info that may be used AL: DNS protocol, messages

  12. AL: DNS issues • Poor static configuration (root server list) • Lack of exponential backoff • No centralized caching per site • Each machine runs on caching local server • UDP used for queries • Need reliability -> Why not TCP? • Vulnerability of 13 TLD servers • Jon Postel and his mobility “experiment” • Attacks on TLD have occurred

  13. outgoing message queue user mailbox user agent mail server user agent SMTP mail server user agent SMTP SMTP user agent mail server user agent user agent AL: Electronic Mail Three major components: • user agents (i.e. mail readers) • Mozilla, Eudora, pine • compose, edit, read, send • mail servers • Message storage and transfer • Sendmail, postfix, etc. • Can sometimes be co-located with user agents • Transfer protocol • SMTP • simple mail transfer protocol

  14. user agent mail server user agent SMTP mail server user agent SMTP SMTP user agent mail server user agent user agent AL: Mail servers • Stores mailbox which contains incoming messages for user • Stores message queue of outgoing mail messages • Storage for messages where destination is temporarily unavailable • Uses SMTP to send email messages to other mail servers • Mail servers are both clients and servers to each other

  15. AL: Electronic Mail: smtp [RFC 821] • Uses TCP to reliably transfer email message from client to server, port 25 • direct transfer: sending server to receiving server • relay: intermediate server transfer • three phases of transfer • handshaking (greeting) • transfer of messages • closure • command/response interaction • commands: ASCII text • response: status code and phrase

  16. S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <alice@crepes.fr> S: 250 alice@crepes.fr... Sender ok C: RCPT TO: <bob@hamburger.edu> S: 250 bob@hamburger.edu ... 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 AL: Sample smtp interaction

  17. AL: 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)

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

  19. header blank line body AL: Mail message format smtp: protocol for exchanging email msgs RFC 822: standard for text message format: • header lines, e.g., • To: • From: • Subject: differentfrom smtp commands! • body • the “message”, ASCII characters only • HTTP->html as SMTP->e-mail

  20. MIME version method used to encode data multimedia data type, subtype, parameter declaration encoded data AL: Message format: multimedia extensions • MIME: multimedia mail extension, RFC 2045, 2056 • additional lines in msg header declare MIME content type From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......................... ......base64 encoded data

  21. Video example subtypes: mpeg, quicktime Application other data that must be processed by reader before “viewable” example subtypes: msword, octet-stream AL: MIME typesContent-Type: type/subtype; parameters Text • example subtypes: plain, html Image • example subtypes: jpeg, gif Audio • exampe subtypes: basic (8-bit mu-law encoded), 32kadpcm (32 kbps coding)

  22. AL: Multipart Type From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=98766789 --98766789 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Dear Bob, Please find a picture of a crepe. --98766789 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......................... ......base64 encoded data --98766789--

  23. SMTP SMTP POP3 or IMAP user agent user agent sender’s mail server receiver’s mail server POP3 or IMAP SMTP web server web server HTTP HTTP user agent user agent AL: Mail access protocols • Mail delivery/transfer protocol • SMTP • 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, Horde/IMP etc.

  24. S: +OK POP3 server ready C: user alice S: +OK C: pass hungry S: +OK user successfully logged on 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 AL: POP3 protocol authorization phase • client commands: • user: declare username • pass: password • server responses • +OK • -ERR transaction phase • client commands: • list: list message numbers • top: get head of message • retr: retrieve message by number • dele: delete • quit

  25. FTP user interface FTP client FTP server AL: 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 user at host remote file system local file system

  26. TCP control connection port 21 TCP data connection port 20 FTP client FTP server AL: ftp: separate control, data connections • Client contacts server at port 21 using TCP • “Control connection” for exchanging commands and responses • Out-of-band signalling between end-points • Server maintains “state”: current directory, earlier authentication • Note the difference to HTTP authentication • When files need to be transferred • Request goes through control connection • A new TCP connection for data transfer is negotiated and created • Negotiation determines end-points of transfer and ports to use for new connection • Protocol allows one ftp client to initiate a transfer between two ftp servers

  27. 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 AL: ftp commands, responses Sample commands: • sent as ASCII text over control channel • USER username • PASS password • LISTreturn list of file in current directory • RETR filenameretrieves (gets) file • STOR filenamestores (puts) file onto remote host

  28. AL: ftp, NAT and the PORT command • Normal FTP mode • Server has port 20, 21 reserved • Client initiates control connection by connecting to port 21 on server • Client allocates port X for data connection • Client passes the data connection port (X) and its IP address in a PORT command to server • Server parses PORT command and initiates connection from its own port 20 to the client on port X • What if client is behind a NAT device? • NAT must capture outgoing connections destined for port 21 and look to translate X within payload • What if NAT doesn’t parse PORT command correctly? • What if ftp server is running on a different port than 21? • http://www.practicallynetworked.com/support/linksys_ftp_port.htm

  29. AL: ftp, NAT, and the PORT command • Passive (PASV) mode • Client initiates control connection by connecting to port 21 on server • Client enables “Passive” mode • Server responds with PORT command giving client the IP address and port to use for subsequent data connection (usually port 20, but can be bypassed) • Client initiates data connection by connecting to specified port on server • Most web browsers do PASV-mode ftp • What if server is behind a NAT device? • See client issues • What if both client and server are behind NAT devices? • Problem • Similar to P2P xfers

More Related