400 likes | 469 Views
Computer Networks 364 Protocols. John Morris Computer Science/Electrical Engineering University of Auckland Email: jmor159@cs.auckland.ac.nz URL: http:/www.cs.auckland.ac.nz/~jmor159. Protocols - HTTP. HyperText Transfer Protocol (HTTP) WWW application layer protocol
E N D
Computer Networks 364Protocols John Morris Computer Science/Electrical Engineering University of Auckland Email: jmor159@cs.auckland.ac.nz URL: http:/www.cs.auckland.ac.nz/~jmor159
Protocols - HTTP • HyperText Transfer Protocol (HTTP) • WWW application layer protocol • Client: browser (Netscape, Opera, that other one, … ) • Server: a web server (source of Web pages - Apache, … ) • Defines the language used by clients to request web pages • RFC 2616 (HTTP/1.1) [ RFC 1945 (HTTP/1.0) ] • Default port is 80 • RFC = Request for Comment • Now managed by the Internet Engineering Task Force (IETF)Over 2000 RFCs • Standards for the Internet
Protocols - HTTP • HyperText Transfer Protocol (HTTP) • Web pages consist of a number of objects • Basic page • Embedded images, etc • Each object is fetched from the server in a single session • Open TCP connection • GET message from client • Response from server with object • Close connection • HTTP is stateless • Server does not keep track of state of session with client • Each request/response pair is independent of any other • Suitable for information serving only applications • Transaction oriented applications egdatabase update • generally require some state to be maintained • HTTP makes it difficult to implement ‘safe’ transaction based systems but • Cookies provide a simple mechanism for maintaining state Stateless protocols are simpler!
Protocols - HTTP • HyperText Transfer Protocol (HTTP) • Web pages consist of a number of objects • ... • Each object is fetched from the server in a single session • Open TCP connection • GET message from client • Response from server with object • Close connection • Obviously rather inefficient • TCP connection establishment is expensive • Persistent connections • TCP connection is left open for subsequent requests • Further efficiency from pipelining • Send additional requests before first response received • Allows browser to do useful work while server is fetching objects • Parsing to discover embedded objects, • Formatting and displaying pages, etc
HTTP example Method URL Version GET /somedir/page.html HTTP/1.1 Host: www.someschool.edu Connection: close User-agent: Mozilla/4.0 Accept-language:fr (extra carriage return, line feed) Request line } Header lines Methods: GET POST HEAD
HTTP request messages General form
HTTP response Version Status code Status message Status line 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 09:23:24 GMT Content-Length: 6821 Content-Type: text/html (data data data data data . . .) Header lines Entity body
HTTP response - common status codes • * 200 OK: Request succeeded and the information is returned in the response. • * 301 Moved Permanently: Requested object has been permanently moved; new URL is specified in Location: header of the response message. The client software will automatically retrieve the new URL. • * 400 Bad Request: A generic error code indicating that the request could not be understood by the server. • * 404 Not Found: The requested document does not exist on this server. • * 505 HTTP Version Not Supported: The requested HTTP protocol version is not supported by the server.
Try out http (client side) for yourself 1. Telnet to your favorite Web server: Opens TCP connection to port 80 (default http server port) at www.eurecom.fr. Anything typed in sent to port 80 at www.eurecom.fr telnet www.eurecom.fr 80 2. Type in a GET http request: By typing this in (hit carriage return twice), you send this minimal (but complete) GET request to http server GET /~ross/index.html HTTP/1.0 3. Look at response message sent by http server!
usual http request msg + Authorization: <cred> usual http request msg + Authorization: <cred> usual http response msg usual http response msg time User-server interaction: authentication Authentication :control access to server content • authorization credentials: typically name, password • stateless:client must present authorization in each request • authorization: header line in each request • if noauthorization:header, server refuses access, sends WWW authenticate: header line in response server client usual http request msg 401: authorization req. WWW authenticate:
usual http request msg cookie: # usual http request msg cookie: # usual http response msg usual http response msg Cookies: keeping “state” client server • Server-generated # • rembered by server • Later used for: • authentication • remembering • user preferences, • previous choices • Server sends “cookie” to client in response msg Set-cookie: 1678453 • Client presents cookie in later requests cookie: 1678453 usual http request msg usual http response + Set-cookie: # cookie- spectific action cookie- spectific action
http response HTTP/1.0 304 Not Modified Conditional GET: client-side caching server client • Goal • Don’t send object if client has up-to-date cached version • Client • specify date of cached copy in http request If-modified-since: <date> • Server • response has no object if cached copy is up-to-date: HTTP/1.0 304 Not Modified http request msg If-modified-since: <date> object not modified http request msg If-modified-since: <date> object modified http response HTTP/1.1 200 OK <data>
User sets browser Web accesses via web cache Client sends all http requests to web cache Object in web cache web cache returns object else web cache requests object from original server, returns object to client Web Caches (proxy server) Goal Satisfy client request without involving original server origin server Proxy server http request http request client http response http response http request http response client origin server
Assume Cache is “close” to client eg in same network Smaller response time Cache “closer” to client Decrease traffic to distant servers Link out of local network often bottleneck Cache works on locality of reference principle Recently used objects more likely to be needed again Temporal locality Keep them ‘closer’ Processor caches use the same principle (+ spatial locality!) Why Web Caching? origin servers public Internet 1.5 Mbps access link institutional network 10 Mbps LAN institutional cache
Transfer file(s) to/from remote host Client/Server model Client: side that initiates transfer (either to/from remote) Server: remote host RFC 959 ftp server: port 21 FTP user interface FTP client FTP: File Transfer Protocol file transfer FTP server 21 user at host remote file system local file system
FTP client contacts server at port 21 Specifies TCP as transport protocol Two parallel TCP connections opened: Control Exchange commands, responses between client and server Out of band control Data File data to / from server FTP server maintains state Current directory Earlier authentication TCP control connection port 21 TCP data connection port 20 FTP client FTP server FTP: Separate Control and Data Connections
Sample commands: Sent as ASCII text over control channel USER username PASS password LIST Return list of files 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 FTP Commands and Responses
Three major components: User agents Mail servers Simple Mail Transfer Protocol: SMTP User Agent Mail reader Composing, editing, reading mail messages Examples Eudora, Outlook, elm, Netscape Messenger Outgoing, incoming messages stored on server user agent user agent user agent user agent user agent user agent SMTP SMTP SMTP mail server mail server mail server outgoing message queue user mailbox Electronic Mail
Mail Servers Mailbox contains incoming messages (yet to be read) for user Message queue of outgoing (to be sent) mail messages SMTP protocol Used between mail servers to send email messages Client: sending mail server “Server”: receiving mail server user agent user agent user agent user agent user agent user agent SMTP SMTP SMTP mail server mail server mail server eMail: Mail servers
RFC 821 First published: 1982 Uses TCP to reliably transfer email message 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 Legacy of 1982 Binary data must be encoded before transfer eMail: SMTP
Sample SMTP interaction 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 This is why 7-bit ASCIIis required!
Try SMTP yourself • telnet servername 25 • See 220 reply from server • Enter • HELO • MAIL FROM • RCPT TO • DATA • QUIT • HELP • commands • You can send email • Using telnet to send commands yourself • By writing a simple program to do it for you! • Try making a simple Java mail sender
Uses persistent connections Requires message (header & body) to be in 7-bit ASCII Certain character strings not permitted in message Example CRLF.CRLF Thus message has to be encoded Usually base-64 or quoted printable Server uses CRLF.CRLF to determine end of message Comparison with HTTP: HTTP: pull eMail: push Command and response, interaction and status codes All ASCII in both HTTP Each object encapsulated in its own response message SMTP Multiple objects sent in multipart message SMTP: Final Words
RFC 821 SMTP protocol for exchanging email messages RFC 822 Text message format Header lines, e.g. To: From: Subject: Differentfrom SMTP commands! Defines semantics (interpretation) also Body The “message” ASCII characters only! Mail message format header blank line body
RFC 822 format OK for text messages Inefficient for multimedia Multipurpose Internet Mail Extensions (MIME) RFC 2045, 2056 Additional lines in message 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 Message format: Multimedia extensions MIME version Method used to encode data Multimedia data type, subtype, parameters Encoded data
Text Subtypes: plain, html, ... Image Subtypes: jpeg, gif Audio Subtypes basic 8-bit -law encoded 32kadpcm 32 Kbps coding (RFC 1911) Video Subtypes: mpeg, quicktime Application Other data that must be processed by reader before becoming “viewable” Subtypes msword octet-stream Arbitrary binary data MIME typesContent-Type: type/subtype; parameters
MIME: 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-- Arbitrary ASCII string which defines boundaries of a part
SMTP: delivery to and storage on receiver’s server Mail access protocol: retrieval from server POP: Post Office Protocol [RFC 1939] Simple, limited functions Authorization (agent server) and download IMAP: Internet Mail Access Protocol [RFC 2060] More features (more complex) Manipulation of stored messages on server Set up, search folders, etc HTTP: Hotmail , Yahoo! Mail, etc user agent user agent sender’s mail server SMTP Mail Access Protocols SMTP POP3 or IMAP receiver’s mail server
Authorization phase Client commands: user: declare username pass: password Server responses +OK -ERR Transaction phaseclient: list: list message numbers retr: retrieve message by number dele: delete quit POP3 Protocol 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
People: Many identifiers: IRD #, name, passport # Internet hosts, routers: IP address (32 bit) Used for in datagrams “name” eg gaia.cs.umass.edu Used by humans(with some exceptions!) ? 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 resolvenames (address name translation) Note Core Internet function, implemented as application-layer protocol Complexity at network’s “edge” DNS: Domain Name System
No server has all name IP address mappings Local name servers: Each ISP, company has local (default) name server DNS query first goes to local name server Authoritative 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 Congestion Traffic volume on central server Distance Time to reach centralized database Maintenance Doesn’t scale! DNS 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 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 DNS: Root Name Servers 13 root name servers worldwide
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. Root name server contacts authoritative name server, dns.umass.edu, if necessary local name server dns.eurecom.fr Simple DNS example root name server 2 4 3 5 authorititive name server dns.umass.edu 1 6 requesting host surf.eurecom.fr gaia.cs.umass.edu
Root name server: May not know authoritative name server May know intermediate name server: who to contact to find authoritative name server local name server dns.eurecom.fr intermediate name server dns.umass.edu DNS example root name server 6 2 3 7 5 4 1 8 authoritative name server dns.cs.umass.edu requesting host surf.eurecom.fr gaia.cs.umass.edu
Recursive query: Puts burden of name resolution on contacted name server Heavy load? Iterated query: Contacted server replies with name of server to contact “I don’t know this name, but ask this server” local name server dns.eurecom.fr intermediate name server dns.umass.edu DNS: iterated queries root name server iterated query 2 3 4 7 5 6 1 8 authoritative name server dns.cs.umass.edu requesting host surf.eurecom.fr gaia.cs.umass.edu
Once (any) name server learns mapping, it caches mapping Cache entries timeout (disappear) after some time Update/notify mechanisms being designed by IETF RFC 2136 http://www.ietf.org/html.charters/dnsind-charter.html DNS: Caching and updating records
DNS: Distributed database storing resource records (RR) Type=NS name is domain (eg foo.com) value is IP address of authoritative name server for this domain RR format: (name, value, type, ttl) DNS records • Type=A • name is hostname • value is IP address • Type=CNAME • name is alias name for some “cannonical” (real) name • www.ibm.comis reallyservereast.backup2.ibm.com • value is cannonical name • Type=MX • value is name of mailserver associated with name
DNS protocol queryand reply messages both with same message format DNS protocol, messages Message header • identification • 16 bit # for query, reply to query uses same # • flags • query or reply • recursion desired • recursion available • reply is authoritative
DNS protocol, messages Name, type fields for a query RRs in reponse to query records for authoritative servers additional “helpful” info that may be used