* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Data Modeling - Hiram College
Survey
Document related concepts
Distributed firewall wikipedia , lookup
Server Message Block wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
SIP extensions for the IP Multimedia Subsystem wikipedia , lookup
Dynamic Host Configuration Protocol wikipedia , lookup
Internet protocol suite wikipedia , lookup
Remote Desktop Services wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Transcript
Applications CPSC 363 Computer Networks Ellen Walker Hiram College (Includes figures from Computer Networking by Kurose & Ross, © Addison Wesley 2002) Review of Layers • Layer 5: Application (messages) – Implemented on hosts • Layer 4: Transport (segments) – Connection-oriented service (connects hosts) • Layer 3: Network (datagrams / packets) – Routing service (packets between hosts) • Layer 2: Link (frames) • Layer 1: Physical (bits - electric or light) – Layers 2 & 1 in network card. Accurate transmission of bit sequences across physical links (wires, cable, radio, etc.). Application Layer point of view • Client requests/establishes a connection with server (via the network layer) • Client sends and receives messages across the connection • Client (or server) closes the connection (again via the network layer) • A host can maintain multiple connections at the same time! – Multiple ports – Multiple processes Application vs. Protocol • Network application can consist of many components – – – – Data storage & retrieval Data formatting & presentation Encoding / decoding encrypted data Messages between client & server (or peers) • Only the last of these uses network application protocol Not all standards are protocols • Web services – Browser-server communication (HTTP) – Document formatting standard (HTML or XML or PDF or JPG or …) • Email services – Client-server communication (SMTP, IMAP, POP) – Message attachment formatting (MIME) Protocols define… • What types of messages are exchanged? • How is the message formatted into fields? (Syntax) • What do the fields mean? (Semantics) • What are legal messages and responses to messages? (Rules) Finding Internet Protocols • Internet protocols are defined in RFC (Request for Comments) documents • A searchable database of these documents is available at http://www.rfc-editor.org • Not all RFC documents are standards; some are informational, experimental, etc. Client and Server • Client – Where the “user” sits, usually – Initiates the conversation (in nearly all cases) • Server – Responds to client’s requests – Provides “services” such as file storage, database query, etc. • Peer to Peer – Both hosts play both roles Process Communication • A process is a running program with its own program counter, registers and memory • Most modern operating systems run many processes simultaneously • Processes communicate with each other through sockets (also called APIs) – Limited interaction with network layer – Establish type of transport protocol and a few parameters (e.g. segment size) only Message Addressing • Which host is this message going to? – IP address (e.g. 143.206.149.21) – We’ll discuss in detail later (network layer) • Which process on that host will receive the message? – Port number (e.g. 80 for HTTP) – Standard port numbers have been assigned (see http://www.iana.org/assignments/port-numbers) – We’ll discuss ports in detail later (transport layer) Applications’ Demands on Transport Layer • Reliable Data Transfer – How much loss is acceptable? – None (e.g. financial applications) vs. some (e.g multimedia) • Bandwidth – What transmission rate is necessary? – Minimum requirements (e.g. streaming video) vs. use whatever is available (e.g. web, file transfer) • Timing – What end-to-end delay is acceptable? – Some applications (e.g. telephony) have strict constraints Transport Layer Services • TCP – – – – Connection-oriented (handshake) Reliable transmission Congestion control (throttling) No guaranteed minimum transmission rate • UDP – Connectionless (no handshake) – Unreliable (no guarantee of receipt or ordering) – No guaranteed minimum transmission rate Examples (fig. 2.5) Application App-Layer Protocol SMTP Transport Protocol TCP Remote terminal Web Telnet TCP HTTP TCP File Transfer FTP TCP E-mail Streaming MM Proprietary UDP or TCP Internet Telephony UDP Proprietary Telnet • Perhaps the simplest protocol • Opens a TCP connection between two hosts through a specified port • Whatever you type is sent through the connection • Typically used for terminal connection (now superseded by SSH for secure connections) • Can telnet to any port – telnet cs.hiram.edu 23 (terminal connection; default) – telnet cs.hiram.edu 80 (web server connection) The WorldWide Web • Basis in hyperlinks and hypertext (documents) – – – – – Proposed by Vannevar Bush (Memex) 1945 “Hypertext” coined by Ted Nelson 1965 Hypertext in education at Brown (FRESS) 1966 - 198x? Hypercard (Apple) 1987 See http://ei.cs.vt.edu/book/chap1/htx_hist.html • Historical path… – FTP (file transfer protocol - files aren’t displayed) – Gopher (displays directories & text files) – Web (embedded links can link to any document) • • • • Search engines Multimedia indexes Front ends to databases ETC! Web Application Vocabulary • Web page (document) - collection of objects – Usually base HTML file + several referenced objects • Object - any file addressable by a single URL • URL (Uniform Resource Locator) - how to reach an object – Host address + object’s path name • Browser - user agent (client) for the web • Web server - houses objects HyperText Transfer Protocol (HTTP) • Request / response protocol – Client requests an object (URL) – Server provides the object(s) corresponding to that URL – Non-persistent (1 object only) vs persistent (explicit close) • Stateless protocol – The server doesn’t store any knowledge (state) of the client – E.g. server doesn’t remember what pages client looked at HTTP Uses TCP • Client initiates TCP connection to server, port 80 • Server accepts connection • Client sends HTTP message & Server responds (one or more times) • TCP connection closed Non-persistent HTTP conversation • • • • Client to server: “[address] I’d like to talk to you” Server to client: “OK, I will talk with you” Client to server: “Thanks. Please send me [path]” Server to Client: “Here’s the object you asked for. [Object] Goodbye.” • Client to server: “Got it. Goodbye” • If the object contains embedded links, an additional complete conversation is needed for each! How long does it take? • Define RTT (Round Trip Time) as time for one message to travel from client to server & server to client (includes all delays) • Total time is 2*RTT+ file transmission – Beginning of handshake (1 RTT) – End of handshake + transmit request + first packet of response (1 RTT) – Transmit the rest of the file (depends on file size) • If file has 10 images, 22*RTT + file times Persistent Transmission • TCP connection remains open until explicitly closed. • Previous example now takes 2 RTT for setup, plus 1 RTT per request, plus file time (12RTT+ file time) • With pipelining, new requests are sent as files are received, so server is never idle. Only 1RTT for setup, plus 1 RTT for all objects. Example now takes 2RTT + file time. Message Format (Request) • Request line (command, addr, protocol) GET /~walkerel/cs363/index.html HTTP/1.1 • Header lines (fields & values) Host: cs.hiram.edu Connection: close User-agent: Mozilla/4.0 Accept-language: en nonpersistent browser id preferred lang. • Entity body (for POST) contains contents of forms filled out • End with 2 CR/LFs HTTP Commands • GET path – Get a file • GET path?var=val… – Get a file, specify values (from form) • POST path – Run a program that resides at the specified path – Program will generate a web page, which is the server’s response Additional Commands • HEAD – Requests header lines but not the actual file • PUT (1.1 only) – Uploads file to path specified in URL field • DELETE (1.1 only) – Deletes file specified by URL field Message Format (Response) • Status line (protocol, status code, message) HTTP/1.1 200 OK • Header lines Connection: close Date: Sat, 25 Jan 2003 12:15:00 EDT Server: Apache/1.3.0 (Unix) Last-Modified: … Content-Length: … Content-Type: text/html • Data Status Codes • 200 OK • 301 Moved Permanently (new URL provided in Location: header) • 400 Bad Request (generic error message) • 404 Not Found • 505 HTTP Version Not Supported (on this server) Practice HTTP • Telnet to your favorite server, e.g. cs.hiram.edu, using port 80 telnet cs.hiram.edu 80 • Enter HTTP message, followed by a blank line GET /~walkerel/cs363/index.html Host: cs.hiram.edu Cookies • Information stored by the client to identify the client to the server • The “cookie” is a unique identification number for the user. (e.g. to index purchase history) • It is stored in a “cookie file” on the client machine, and provided to the server as part of a request message • The server can then create “personalized” responses • Cookies can also authenticate, so you can “save your password” Cookies in HTTP • In the HTTP Response message (from the server) – Set-cookie: 1253261 • In future HTTP Request messages (from the client) – Cookie: 1253261 Web Cache (Proxy Server) • Stores copies of recently requested items • Browser first requests item from Proxy Server – If item is stored, it is sent – Otherwise, item is retrieved from external server, stored, then sent • Proxy Server acts as both client and server • Proxy server can also refuse requests – Prevent browsing to “inappropriate” sites • Risk: page has changed since saved (stale page) Advantage of Web Cache • Increases average response time – Response time of “hit” is very fast (item in cache) – Response time across network much slower than LAN response time – Hit rates 0.2 - 0.7 in practice (20%-70% of accesses are repeats) • Average response time = – Hit rate * LAN delay + (1-Hit rate) * net delay Example: Cache Advantage • Assumptions (Section 2.2.6) – LAN delay = 0.01 sec – Net delay = 2.01 sec – Hit rate = 40% (0.4) • No cache – 2.01 seconds delay • With cache – .4 * 0.01 + .6 * 2.01 = 0.004+ 01.206 = – 1.21 seconds delay Protocol for Avoiding Stale Pages • Server requests page only if changed (Conditional GET) GET file HTTP/1.1 Host: Ipaddress If-modified-since: date • Response if not changed: HTTP/1.1 304 Not Modified Date: date Server: server • Response if changed is the same as before HTTP:/1.1 200 OK Additional headers + data File Transfer (FTP) • Send a file from one host to another – User can sit on “donor” or “recipient” host • User provides authentication information once for all transfers – Username & password, or ‘anonymous’ & email address • Connection is persistent until an explicit close • Example: ftp pub/reid.txt from rtfm.mit.edu FTP Uses 2 Connections • Control connection – Sends user id, password, commands – “Out of band” because not interspersed with data – Port 21 (TCP) • Data connection (TCP) – Sends actual files – A new data connection is created for each file Unlike HTTP, State is maintained • Server remembers which user is connected – vs. HTTP Authorization header in every message • Server remembers current directory – vs. HTTP full path in every message • Because state is maintained, the number of simultaneous connection is limited, relative to HTTP FTP Commands • • • • • USER username PASS password LIST (list the files in the current directory) RETR filename (retrieve from remote host) STOR filename (store onto remote host) • Client commands aren’t quite identical (eg. GET, PUT) and may allow additional arguments Electronic Mail • User Agent – Allows user to send and receive email – Generally allows access to stored email – e.g. MS Outlook, Eudora • Mail Server – Delivers email, stores it in user’s mailbox (at least) until read – Sends off-site email; queues and retries if external host isn’t available SMTP (Simple Mail Transfer Protocol) • All messages (not just headers) restricted to 7-bit ASCII (must be encoded/decoded by user agent) • Transfers mail from origin host to destination host (no intermediate servers) • Commands include HELO, MAIL FROM, RCPT TO, and DATA • To try it: telnet serverName 25 SMTP vs. HTTP • HTTP is “pull protocol”, SMTP is “push protocol” • SMTP requires 7-bit ASCII, even for data; HTTP allows any format • SMTP puts all data into one message – MIME encoding (Multipurpose Internet Mail Extensions) • Content-Type: and Content-Transfer-Encoding: headers MIME Types • Multipart/mixed – Look for part boundaries, content headers • • • • Text/plain Text/html Image/gif or image/jpeg Application/msword, application/pdf, etc. Mail Headers • Some from user (e.g. To, cc) • Some from user agent (e.g. Date, From, MIME headings) • Some from servers (e.g. Received) • Most user agents allow “full headers” to be viewed. Mail Header Example • • • • • • • • • From: Thomas Bagley [email protected] Subject: ACM Member Technical Interest Service January 2010 Date: January 26, 2010 5:46:47 PM EST To: Ellen Walker [email protected] Received: from mail.hiram.edu ([206.57.41.42]) by hiramr.hiram.edu with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 17:46:54 -0500 Received: from smtp161.redcondor.net ([206.57.41.40]) by mail.hiram.edu with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 17:46:54 -0500 Received: from acm26-2.acm.org ([199.222.69.107]) by smtp161.redcondor.net ({6c7b74fb-260e-4729-9476-f743470f315e}) via TCP (inbound) with ESMTP id 20100126224651153 for <[email protected]>; Tue, 26 Jan 2010 22:46:51 +0000 Received: from acm28-8 ([192.168.1.104]) by acm26-2.acm.org (IceWarp 9.4.2) with SMTP id IXU98141 for <[email protected]>; Tue, 26 Jan 2010 17:46:41 -0500 Mail Header Example (Cont’d) • • • • • • • • • X-Rc-From: [email protected] X-Rc-Rcpt: [email protected] Message-Id: 10171514.34121264546007418.JavaMail.Administrator@acm28-8 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: ColdFusion 8 Application Server Return-Path: [email protected] X-Originalarrivaltime: 26 Jan 2010 22:46:54.0837 (UTC) FILETIME=[7568BA50:01CA9ED9] Mail Access Protocols • Protocols for conversation between user agent and mail server (SMTP is for mail server to mail server communication) • POP3 – Authorization, transaction, update (after client quit) • IMAP – Allows users to store mail in folders on server – Clients can access message components (e.g. headers only) • WebMail (HTTP) – Mail accessed through a web page using a browser; no application-specific client or protocol Domain Name System (DNS) • Translates between mnemonic hostnames and numeric IP addresses – www.hiram.edu = 206.57.41.47 – Command “host” can look up an address • Distributed database implemented in hierarchy of DNS servers • Application-layer protocol that allows hosts to query this database – Used by other application-layer protocols such as HTTP for name-address translation – This adds a delay to each HTTP request Database is Distributed • • • • Root servers (13) point to… Top-level domain servers (com, org, edu, uk,…) point to… Authoritative servers (per organization) Local servers (per ISP) a Verisign, Dulles, VA c Cogent, Herndon, VA (also LA) d U Maryland College Park, MD g US DoD Vienna, VA h ARL Aberdeen, MD j Verisign, ( 21 locations) b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA k RIPE London (also 16 other locations) i Autonomica, Stockholm (plus 28 other locations) m WIDE Tokyo (also Seoul, Paris, SF) Translating a Domain (iterative) • Ask local DNS • Local DNS asks root DNS • Root DNS responds with appropriate toplevel DNS • Local DNS asks top-level DNS • TL DNS responds with appropriate organization’s authoritative DNS • Local DNS asks Authoritative DNS, and receives address (which it probably caches) Translating a Domain (recursive) • • • • Ask local DNS Local DNS asks root DNS Root DNS asks top-level DNS TL DNS asks organization’s authoritative DNS • Organization’s DNS responds to TL DNS, which forwads to Root DNS, which forwards to local DNS, which responds to original client • (Caching as appropriate throughout) DNS Record Types • A – Name = hostname, value = IP address • NS – Name = domain (hiram.edu), value = hostname of authoritative DNS • CNAME – Name = canonical hostname (foo.com), value = real hostname (relay1.bar.foo.com) • MX – Name = canonical mail name (gmail.com), value = real hostname (gsmtp183.google.com) Creating a new DNS Record • Entity “registers” the site, by paying a registrar and providing authoritative DNS server IP addresses • Registrar verifies uniqueness of name and enters NS and A type records into database • You provide A and MX records for your own servers at your authoritative DNS servers Why Not Central Name Server? • Single point of failure • Too many requests • Does not scale !!!!! P2P (Peer to Peer) Applications • All content transferred directly between peers without passing through third-party servers – Does not rely on always-on (24/7) servers • When a client requests an object – Find a server, currently connected that has that object – Server transmits object to client • A given host can be both client and (transient) server • Applications include: – File distribution – VOIP (e.g. Skype) File Sharing • Goal: Distribute a file from a single server to many hosts • Client-server – Huge burden on source host (must connect to all recipients) • P2P – Any host that has received some portion of the file can redistribute to others (sharing the burden) – Most popular (2009): BitTorrent How long does it take? (C/S) • N bits in file, u = upload rate, dmin = min download rate • 1 server -> N clients • Upload time = N*F/u • Max download time = F / dmin • Overall: max (N*F/u, F/dmin) • Assume N is big enough, result is N*F/u How Long Does It Take? (P2P) • To get file out, server must send every bit once (F/u) • Slowest recipient will take F/dmin time to get its complete file • Total upload capacity is sum of upload capacity of all uploaders: – uTotal = u + u1 + u2… • Overall time = max (F/u, F/dmin, N*F/uTotal) • When N gets bigger, so does uTotal! BitTorrent • P2P Protocol for file distribution • Torrent = collection of all peers involved in distribution of a single file • Chunks = equal-sized pieces of file (e.g. 256K) • Tracker = special infrastructure node (one tracker per torrent) When a peer joins a torrent… • Tracker sends peer N (say 50) random addresses of hosts in the torrent • Try to connect to all of them. (Successful connections called ‘neighbors’) • Ask each neighbor for lists of chunks they have • Request (from appropriate neighbor) each chunk you don’t have Rarest First • Ask for the chunk which is held by the fewest of my neighbors • Result: more copies of that chunk, roughly equalizing the availability of chunks Responding to Requests (Tit for Tat) • Host receives many requests • Respond to requests from 4 neighbors sending bits at highest rate (unchoked) – These are fastest – These are ‘most generous’ • Respond to requests from a fifth neighbor at random (optimistically unchoked) – Might become ‘top-4’ of this neighbor! – Allows more neighbors to get in on the action. Distributed Hash Tables • Need to maintain searchable index of (key, value) pairs • Cannot contain it on a single host (point of failure) – Napster did this in the early days of P2P • Distribute pairs among hosts – How to avoid having all hosts contain all pairs? – How to avoid having all hosts contact all hosts? Answer: Use the Hash Value! • Assign an integer to each host (same range as hash values) • Assign each (key, value) pair to the host whose integer is closest to hash(key) – Equal is closest, then successor (wraps around) • Each host knows its successor (last -> first) – circular overlay network To Add or Find • Peer receives message with hash(key) • If ID is closer to hash(key) than successor’s ID, then peer responds directly to message’s sender – ID ≥ hash(key) – Successor ID < hash(key) • Else peer passes on the message to its successor Evaluating Circular Network • Advantage: – Every peer needs to keep track of only 2 neighbors (predecessor and successor) • Disadvantage: – When the circle gets big, messages take a long time to go around! • Solution: – Add a few “shortcut” links across the circle – Trades off more neighbors vs. shorter travel time Peer Churn • Remember, hosts come & go, not 24/7 • By the original plan, if my successor is lost, I am disconnected! • Instead – Each node tracks 2 successors – Periodically check both your successors are there – If one is gone, find the other’s successor so you still have 2 successors • To join, pass a message around the circle P2P Case study: Skype Skype clients (SC) • inherently P2P: pairs of users communicate. • proprietary applicationSkype layer protocol (inferred login server via reverse engineering) • hierarchical overlay with SNs • Index maps usernames to IP addresses; distributed over SNs From Kurose & Ross Slides v. 5 Supernode (SN) 67