Application Level Protocols Outline Simple Mail Transfer Protocol

  • Slides: 32
Download presentation
Application Level Protocols Outline Simple Mail Transfer Protocol (SMTP) Hyper. Text Transport Protocol (HTTP)

Application Level Protocols Outline Simple Mail Transfer Protocol (SMTP) Hyper. Text Transport Protocol (HTTP) Spring 2002 CMSC 332 1

Three Points • Application protocols are not application programs – HTTP is a protocol

Three Points • Application protocols are not application programs – HTTP is a protocol used to fetch web pages, while Netscape and Mosaic are programs that use HTTP • Both protocols examined here use request/reply paradigm, yet they are not implemented on top of RPC (but instead on TCP) • Both have a companion protocol that specifies the format of data that can be exchanged – RFC 822 and Multipurpose Internet Mail Extensions (MIME) are companion to SMTP – HTML is companion that specifies form of web pages Spring 2002 CMSC 332 2

RFC 822 • Defines header and body, both ASCII – Augmented by MIME to

RFC 822 • Defines header and body, both ASCII – Augmented by MIME to allow message body to carry all sorts of data, but data still represented as ASCII text • Header – Series of <CRLF> terminated lines (<CRLF> stands for carriage return + linefeed ASCII characters) – Separated from body by blank line – Each header line has form <type>: <value> – Ex. To: , Subject: , Date: , From: Spring 2002 CMSC 332 3

MIME • RFC 822 extended in 1993 & 1996 to allow email to carry

MIME • RFC 822 extended in 1993 & 1996 to allow email to carry video, Word files, etc. • Three basic pieces – Header lines augmenting RFC 822 – Set of content types and subtypes – Encoding schemes for various data types to allow shipment as ASCII Spring 2002 CMSC 332 4

MIME (cont. ) • Header extensions describe data being carried by message body –

MIME (cont. ) • Header extensions describe data being carried by message body – MIME-Version: – Content-Description: human readable description of what’s in message – Content-Type: type of data – Content-Transfer-Encoding: how data is encoded Spring 2002 CMSC 332 5

MIME Content Types • image/gif, image/jpeg • text/plain, text/rich: “marked up” text (I. e.

MIME Content Types • image/gif, image/jpeg • text/plain, text/rich: “marked up” text (I. e. special fonts, etc) • application/ – application/postscript, etc • multipart: how a message carrying more than one data type is structured – Like a programming language with base types and structs, etc Spring 2002 CMSC 332 6

MIME Encoding • Ex. JPEG: Each byte can assume one of 256 values, not

MIME Encoding • Ex. JPEG: Each byte can assume one of 256 values, not all of which are valid ASCII characters – Must use ASCII encoding because gateways can corrupt non-ASCII portions – Solution is the base 64 encoding scheme: • Three bytes of binary data converted to four ASCII characters • 24 bits divided into four groups of 6 bits, each of which maps to a valid ASCII character (so note that such an encoding only contains alphanumeric and + and – characters) • Regular text can be encoded using 7 -bit ASCII Spring 2002 CMSC 332 7

Example MIME-Version: 1. 0 Content-Type: multipart/mixed; boundary=“-------417 CA 6 E 2 DE 4 ABCAFBC

Example MIME-Version: 1. 0 Content-Type: multipart/mixed; boundary=“-------417 CA 6 E 2 DE 4 ABCAFBC 5” From: Doug Szajda <dszajda@richmond. edu> To: registrar@richmond. edu Subject: grades for CMSC 332 class this semester Date: Thurs, 11 April 2002 12: 22: 19 -0400 -------417 CA 6 E 2 DE 4 ABCAFBC 5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7 bit Dear Ron, I’ve decided to fail them all! It will save me the trouble of having to grade their finals. I’ve also included the picture you requested, and a copy of my latest paper. Doug Spring 2002 CMSC 332 8

Example -------417 CA 6 E 2 DE 4 ABCAFBC 5 Content-Type: image/jpeg Content-Transfer-Encoding: base

Example -------417 CA 6 E 2 DE 4 ABCAFBC 5 Content-Type: image/jpeg Content-Transfer-Encoding: base 64. . Unreadable encoding of a jpeg image. -------417 CA 6 E 2 DE 4 ABCAFBC 5 Content-Type: application/postscript; name=“draft. ps” Content-Transfer-Encoding: 7 bit. . Readable encoding of a Post. Script document. Spring 2002 CMSC 332 9

SMTP • SMTP is the protocol that handles the actual transfer • The players:

SMTP • SMTP is the protocol that handles the actual transfer • The players: – mail reader: program with which user interacts (I. e. Pine, Elm, Netscape Mail, etc. ). Transfers messages to/from mail daemon – mail daemon: process running on each host. Uses SMTP over TCP to transfer message to mail daemon running on other host. Though any code implementing SMTP could be used, typical daemon is descendent of original Berkeley implementation of sendmail Spring 2002 CMSC 332 10

SMTP • Players (cont. ) – mail gateway: similar to an IP gateway (what

SMTP • Players (cont. ) – mail gateway: similar to an IP gateway (what we have called a router), but willing to buffer messages and retry sending for days Spring 2002 CMSC 332 11

Why Gateways? • I. e. why not just send message directly to receiver’s host?

Why Gateways? • I. e. why not just send message directly to receiver’s host? • Receiver doesn’t want to include specific host on which he/she reads email – May read mail on several hosts – Host on which mail is read may not be connected to network • Solution: have mail delivered to a mail gateway at destination (I. e. at umiacs. umd. edu) – Mail then forwarded (using another SMTP/TCP connection) to user (after dbase lookup) OR – User fetches mail from server using something like Post Office Protocol (POP 3) Spring 2002 CMSC 332 12

SMTP (cont. ) • Independent SMTP connection used between each mail gateway. • SMTP

SMTP (cont. ) • Independent SMTP connection used between each mail gateway. • SMTP sessions are dialog between two daemons, one acting as client, the other as server • SMTP is ASCII based (makes sense since RFC 822 defines messages using this base representation) – Means a human at a keyboard can pretend to be an SMTP client program Spring 2002 CMSC 332 13

Example SMTP Dialogue HELO richmond. edu 250 Hello daemon@mail. richmond. edu [141. 166. 127.

Example SMTP Dialogue HELO richmond. edu 250 Hello daemon@mail. richmond. edu [141. 166. 127. 54] MAIL FROM: <Ron@registrar. richmond. edu> 250 OK RCPT TO: <dszajda@richmond. edu> 250 OK DATA 354 Start mail input; end with <CRLF> Hi Doug, I realize they whine a lot, and they probably deserve to fail, but they’ll be alums some day and that means money! And thanks for the picture. Ron <CRLF> 250 OK QUIT 221 Closing connection Spring 2002 CMSC 332 14

SMTP (cont. ) • Client posts commands: HELO, MAIL, etc • Server responds with

SMTP (cont. ) • Client posts commands: HELO, MAIL, etc • Server responds with a numeric code along with human readable explanation • Note the server verifies that name supplied in HELO command corresponds to IP address being used for TCP connection • Mail daemon parses message for info needed to run SMTP (info is called envelope for message). Daemon then uses this to parameterize SMTP exchange. sendmail popular because no on wanted to reimplement parsing function! Spring 2002 CMSC 332 15

HTTP • Assume you know and understand the following terms – Universal Resource Locator

HTTP • Assume you know and understand the following terms – Universal Resource Locator (URL) – Web browser – Hypertext link • Basic Web mechanism – User “selects” page, browser (client) fetches page from server using HTTP running over TCP Spring 2002 CMSC 332 16

HTTP (cont. ) • Like SMTP, HTTP is text-oriented • HTTP message form –

HTTP (cont. ) • Like SMTP, HTTP is text-oriented • HTTP message form – – START_LINE <CRLF> : request or response MESSAGE_HEADER <CRLF> : as in email messages <CRLF> : blank line that terminates header MESSAGE_BODY <CRLF> : typically empty for requests Spring 2002 CMSC 332 17

HTTP Request Messages • START_LINE specifies: – Operation to be performed (see next slide)

HTTP Request Messages • START_LINE specifies: – Operation to be performed (see next slide) • GET: retrieve and display a web page • HEAD: test validity of a hypertext link or check if page has been modified since last fetched – Web page operation should be performed on – Version of HTTP being used – Ex. GET http: www. mathcs. richmond. edu/index. html HTTP/1. 1 – Ex. GET index. html HTTP/1. 1 Host: www. mathcs. richmond. edu Spring 2002 CMSC 332 18

HTTP Request Operations OPTIONS: request information about available options GET: retrieve document identified in

HTTP Request Operations OPTIONS: request information about available options GET: retrieve document identified in URL HEAD: retrieve metainformation about document identified in URL POST: give information (e. g. annotation) to server PUT: store document under specified URL DELETE: delete specified URL TRACE: loopback request message CONNECT: for use by proxies Spring 2002 CMSC 332 19

HTTP Response Message • START_LINE specifies: – – – Version of HTTP being used

HTTP Response Message • START_LINE specifies: – – – Version of HTTP being used Three digit code indicating success/failure of request Text string giving reason for response Ex. HTTP/1. 1 202 Accepted Ex. HTTP/1. 1 404 Not Found Spring 2002 CMSC 332 20

HTTP Response Message • Possible header lines: – Location: requested URL available at another

HTTP Response Message • Possible header lines: – Location: requested URL available at another location – Content-length – Expires – Last-modified: time at which contents last modified at server • HTTP/1. 1 301 Moved Permanently Location: http: //www. mathcs. richmond. edu/cs/ind ex. html Spring 2002 CMSC 332 21

HTTP Result Codes Code Type Example Reasons 1 xx Informational Request received, continuing process

HTTP Result Codes Code Type Example Reasons 1 xx Informational Request received, continuing process 2 xx Success Action successfully received, understood, and accepted 3 xx Redirection Further action must be taken to complete the request 4 xx Client error Request contains bad syntax or cannot be filled 5 xx Server error Server failed to fulfill an apparently valid request Spring 2002 CMSC 332 22

HTTP and TCP • HTTP Version 1. 0 – Separate TCP connection established for

HTTP and TCP • HTTP Version 1. 0 – Separate TCP connection established for each data item retrieved from server • Connection setup and teardown required even if just checking on page status • Text plus a dozen icons requires more than 13 separate connections being established and closed – Needless to say, efficiency concerns Spring 2002 CMSC 332 23

HTTP and TCP • HTTP Version 1. 1 (latest) – Persistent connections: client and

HTTP and TCP • HTTP Version 1. 1 (latest) – Persistent connections: client and server can exchange multiple request/response messages over same TCP connection • Eliminate connection setup/teardown, reducing load on server, load on network, and delay perceived by user • TCP congestion window operates more efficiently, because it is not necessary to go through slow start phase for each page – The cost (there always is one): Neither client nor server knows how long to keep connection open. • Especially problematic for server • Both sides must watch for signal to close their side of connection Spring 2002 CMSC 332 24

Caching Web Pages • Active area of research (and entrepreneurship) • Advantages: – Pages

Caching Web Pages • Active area of research (and entrepreneurship) • Advantages: – Pages can be displayed faster is fetched from closer server – Reduced server load since less requests to handle • Where to cache? – User’s browser – Sitewide cache (user browsers configured to check this proxy cache first) – ISPs: router snoops packets on way in and way out • Various HTTP design features support this – Server assigns expiration date to each page it sends to client – Various cache directives (can a document be caches, how long, etc) Spring 2002 CMSC 332 25

Simple Network Management Protocol (SNMP) • As sysadmin, might want to know about state

Simple Network Management Protocol (SNMP) • As sysadmin, might want to know about state info at any of dozens of routers, hundreds of hosts – – Address translation tables Routing tables TCP connection state Number of IP datagram reassemblies aborted (does timeout that garbage collects IP fragments need to be tuned? ) – Loads on various nodes Spring 2002 CMSC 332 26

SNMP • Allows reading and writing of various pieces of state information on different

SNMP • Allows reading and writing of various pieces of state information on different nodes • Specialized request/response protocol (that runs over UDP) supporting – GET – SET – GET-NEXT (explained below) • Typically, sysadmin uses browser like interface, which turns requests into SNMP operations, which are in turn fulfilled by SNMP server running on host in question Spring 2002 CMSC 332 27

Management Information Base (MIB) • Two questions – How does client indicate which piece

Management Information Base (MIB) • Two questions – How does client indicate which piece of info it wants to retrieve? – How does server know which variable in memory to read to satisfy request? • MIB is a companion specification that defines specific pieces of information (MIB variables) that can be retrieved from network node • Current version: MIB-II Spring 2002 CMSC 332 28

MIB-II • Variables organized in 10 groups – System: general system (node) parameters (name,

MIB-II • Variables organized in 10 groups – System: general system (node) parameters (name, location, etc) – Interfaces: address(es), how many packets sent/received – Address translation: ARP info, including ARP table – IP: routing table entries, how many packets forwarded, stats about datagram reassembly, dropped packets, etc. – TCP: number of open connections, timeouts, default timeout settings. Also per-connection info while connection exists – UDP: total number of UDP datagrams sent/received – Also groups for Internet Control Message Protocol (ICMP) , EGP, SNMP, “different media” Spring 2002 CMSC 332 29

Two More Problems • Precise syntax used to state which MIB variables wanted •

Two More Problems • Precise syntax used to state which MIB variables wanted • Precise representation for values returned by server • ASN. 1/BER: Abstract Syntax Notation One/ Basic Encoding Rules (Recall text Section 7. 1) – Takes care of second problem – ASN. 1/BER also defines an object identification system (not described in text) and this is used to give globally unique ID to all MIB variables Spring 2002 CMSC 332 30

Example • 1. 3. 6. 1. 2. 1. 4. 3 is unique ASN. 1

Example • 1. 3. 6. 1. 2. 1. 4. 3 is unique ASN. 1 identifier for IP related MIB variable ip. In. Receives – 1. 3. 6. 1. 2: prefix identifies MIB database (ASN. 1 object ID’s are for all possible objects in world) – 4: IP grou – 3 for third variable in this group Spring 2002 CMSC 332 31

SNMP Summary • SNMP client puts ASN. 1 identifier for MIB variable into request

SNMP Summary • SNMP client puts ASN. 1 identifier for MIB variable into request message, sends this to server • Server maps identifier into a local variable, retrieves value held in variable, uses ASN. 1/BER to encode value it sends back to client • GET-NEXT: Many MIB variables are structs or tables. GET-NEXT, when applied to a variable ID, returns the value of variable plus the ID of the next variable (next table entry or field in struct). Thus helps walk through data structures. Spring 2002 CMSC 332 32