Network Applications Outline Simple Mail Transfer Protocol The

  • Slides: 17
Download presentation
Network Applications Outline Simple Mail Transfer Protocol The Web, HTTP CS 640 1

Network Applications Outline Simple Mail Transfer Protocol The Web, HTTP CS 640 1

Simple Mail Transfer Protocol • Basic protocol for email exchange over the Internet •

Simple Mail Transfer Protocol • Basic protocol for email exchange over the Internet • Runs on top of TCP • SMTP is NOT an interactive protocol, unlike, say, FTP – Messages are queued and spooled by SMTP agent • Users interact with email application – Lots! • Application interfaces with Message Transfer Agent or mail daemon – Sendmail on UNIX – Setup and configured by admins. • SMTP specifies how MTA’s pass email across the Internet CS 640 2

Simple Mail Transfer Protocol • Client uses email application to construct and send messages

Simple Mail Transfer Protocol • Client uses email application to construct and send messages – Addresses consist of machine name and mailbox address • Mailbox is usually the same as one’s login but you can have aliases • Destination machine can also be an alias@cs. wisc. edu • Message is passed to mail spooler which is part of MTA – Application communicates with MTA via email transfer protocol • Post Office Protocol (POP 3) is common, but not very secure • Our department uses IMAP • MTA’s on remote systems listen for incoming mail on well known port (25) • Messages are delivered in two parts – header and body – Header format has exact specification = RFC 822 – Body content types are specified by MIME CS 640 3

SMTP Example Aditya Akella UW-madison Srini Seshan CMU From: akella@cs. wisc. edu To: “Srini"

SMTP Example Aditya Akella UW-madison Srini Seshan CMU From: akella@cs. wisc. edu To: “Srini" <seshan@cs. cmu. edu> Subject: Hi Date: Tues, 11 Aug 2001 10: 46: 16 -0400 MIME-Version: 1. 0 X-Mailer: Internet Mail Service (5. 5. 1960. 3) Content-Type: text/plain Content-Transfer-Encoding: 7 bit header Hi, Srini! Blah! body -Aditya CS 640 4

Sample SMTP Session tux 34(21)% telnet smtp. cs. wisc. edu 25 Trying 128. 105.

Sample SMTP Session tux 34(21)% telnet smtp. cs. wisc. edu 25 Trying 128. 105. 6. 11. . . Connected to schroeder. cs. wisc. edu (128. 105. 6. 11). 220 schroeder. cs. wisc. edu ESMTP Sendmail 8. 11. 3; Tue, 11 Sep 2001 14: 09: 52 -0500 HELO akella. cs. wisc. edu 250 schroeder. cs. wisc. edu Hello tux 34. cs. wisc. edu [128. 105. 111. 134], pleased to meet you MAIL FROM: <akella@cs. wisc. edu> 250 2. 1. 0 <akella@cs. wisc. edu>. . . Sender ok Envelope RCPT TO: <someone@tds. net> 250 2. 1. 5 <jgast@tds. net>. . . Recipient ok DATA 354 Enter mail, end with ". " on a line by itself Header To: someone@tds. net Test for CS 640. 250 2. 0. 0. f 8 BJAeq 14849 Message accepted for delivery QUIT 221 2. 0. 0 schroeder. cs. wisc. edu closing connection Connection closed by foreign host. tux 34(22)% CS 640 Body 5

Web/WWW Components • Structural Components – – Clients/browsers – to dominant implementations Servers –

Web/WWW Components • Structural Components – – Clients/browsers – to dominant implementations Servers – run on sophisticated hardware Caches – many interesting implementations Internet – the global infrastructure which facilitates data transfer • Semantic Components – Hyper Text Transfer Protocol (HTTP) – Hyper Text Markup Language (HTML) • e. Xtensible Markup Language (XML) – Uniform Resource Identifiers (URIs) CS 640 6

WWW Structure • Clients use browser application to send URIs via HTTP to servers

WWW Structure • Clients use browser application to send URIs via HTTP to servers requesting a Web page • Web pages constructed using HTML (or other markup language) and consist of text, graphics, sounds plus embedded files • Servers (or caches) respond with requested Web page – Or with error message • Client’s browser renders Web page returned by server – Page is written using Hyper Text Markup Language (HTML) – Displaying text, graphics and sound in browser – Writing data as well • The entire system runs over standard networking protocols (TCP/IP, DNS, …) CS 640 7

Uniform Resource Identifiers • Web resources need names/identifiers – Uniform Resource Identifiers (URIs) –

Uniform Resource Identifiers • Web resources need names/identifiers – Uniform Resource Identifiers (URIs) – Resource can reside anywhere on the Internet • URIs are a somewhat abstract notion – A pointer to a resource to which request methods can be applied to generate potentially different responses • A request method is eg. fetching or changing the object • Instance: http: //www. foo. com/index. html – Protocol, server, resource • Most popular form of a URI is the Uniform Resource Locator (URL) – Differences between URI and URL are beyond scope – RFC 2396 CS 640 8

HTTP Basics • Protocol for client/server communication – The heart of the Web –

HTTP Basics • Protocol for client/server communication – The heart of the Web – Very simple request/response protocol • Client sends request message, server replies with response message – Stateless – Relies on URI naming mechanism • Three versions have been used – 09/1. 0 • RFC 1945 (original RFC is now expired) – 1. 1 – developed to enhance performance, caching, compression • RFC 2068 – 1. 0 dominates today but 1. 1 is catching up CS 640 9

HTTP Request Messages • • GET – retrieve document specified by URL PUT –

HTTP Request Messages • • GET – retrieve document specified by URL PUT – store specified document under given URL HEAD – retrieve info. about document specified by URL POST – give information (eg. annotation) to the server Less common ones… • OPTIONS – retrieve information about available options • DELETE – remove document specified by URL • TRACE – loopback request message • CONNECT – for use by caches CS 640 10

HTTP Request Format request-line ( request-URI HTTP-version) headers (0 or more) <blank line> body

HTTP Request Format request-line ( request-URI HTTP-version) headers (0 or more) <blank line> body (only for POST request) • First type of HTTP message: requests – Client browsers construct and send message • Typical HTTP request: – GET http: //www. cs. wisc. edu/index. html HTTP/1. 0 CS 640 11

HTTP Response Format status-line (HTTP-version response-code response-phrase) headers (0 or more) <blank line> body

HTTP Response Format status-line (HTTP-version response-code response-phrase) headers (0 or more) <blank line> body • Second type of HTTP message: response – Web servers construct and send response messages • Typical HTTP response: – HTTP/1. 0 301 Moved Permanently Location: http: //www. wisc. edu/cs/index. html CS 640 12

HTTP Response Codes • • • 1 xx – Informational – request received, processing

HTTP Response Codes • • • 1 xx – Informational – request received, processing 2 xx – Success – action received, understood, accepted 3 xx – Redirection – further action necessary 4 xx – Client Error – bad syntax or cannot be fulfilled 5 xx – Server Error – server failed CS 640 13

HTTP Headers • Both requests and responses can contain a variable number of header

HTTP Headers • Both requests and responses can contain a variable number of header fields – Consists of field name, colon, space, field value – 17 possible header types divided into three categories • Request • Response • Body • Example: Date: Friday, 27 -Apr-01 13: 30: 01 GMT • Example: Content-length: 3001 CS 640 14

HTTP/1. 0 Network Interaction • Clients make requests to port 80 on servers –

HTTP/1. 0 Network Interaction • Clients make requests to port 80 on servers – Uses DNS to resolve server name • Clients make separate TCP connection for each URL – Some browsers open multiple TCP connections • Netscape default = 4 • Server returns HTML page – Many types of servers with a variety of implementations – Apache is the most widely used • Freely available in source form • Client parses page – Requests embedded objects CS 640 15

HTTP/1. 1 Performance Enhancements • HTTP/1. 0 is a “stop and wait” protocol –

HTTP/1. 1 Performance Enhancements • HTTP/1. 0 is a “stop and wait” protocol – Separate TCP connection for each file • Connect setup and tear down is incurred for each file • Inefficient use of packets • Server must maintain many connections in TIME_WAIT • Mogul and Padmanabahn studied these issues in ’ 95 – Resulted in HTTP/1. 1 specification focused on performance enhancements • • Persistent connections Pipelining Enhanced caching options Support for compression CS 640 16

Persistent Connections and Pipelining • Persistent connections – Use the same TCP connection(s) for

Persistent Connections and Pipelining • Persistent connections – Use the same TCP connection(s) for transfer of multiple files – Reduces packet traffic significantly – May or may not increase performance from client perspective • Load on server increases • Pipelining – Pack as much data into a packet as possible – Requires length field(s) within header – May or may not reduce packet traffic or increase performance • Page structure is critical CS 640 17