1 / 57

Computer Networks CSE 434 Fall 2009

Computer Networks CSE 434 Fall 2009. Sandeep K. S. Gupta Arizona State University. http://impact.asu.edu/cse434fa09.html. http://impact.asu.edu. Research Experience for Undergraduates (REU). Agenda. Midterm dates Midterm 1: Oct 14 th , 2009 (revised)

katima
Télécharger la présentation

Computer Networks CSE 434 Fall 2009

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. Computer NetworksCSE 434 Fall 2009 Sandeep K. S. Gupta Arizona State University http://impact.asu.edu/cse434fa09.html http://impact.asu.edu Research Experience for Undergraduates (REU)

  2. Agenda • Midterm dates • Midterm 1: Oct 14th, 2009 (revised) • Midterm 2; Nov 9th, 2009 (TENTATIVE) • Term Project Group membership and topic due today. • Summary last class • HTTP • Electronic Mail • P2P intro

  3. Application Transport Requirements TCP service: connection-oriented reliable transport flow control congestion control does not provide: timing, minimum throughput guarantees, security UDP service: unreliable data transfer does not provide: connection setup, reliability, flow control, congestion control, timing, throughput guarantee, or security • Several dimensions to Application Requirements: • Data loss (reliability) (loss-tolerant versus non loss-tolerant) • Throughput (elastic versus non-elastic) • Timeliness • Security • Internet provides two basic transport services:

  4. Time Sensitive no no no yes, 100’s msec yes, few secs yes, 100’s msec yes and no Application file transfer e-mail Web documents real-time audio/video stored audio/video interactive games instant messaging Throughput elastic elastic elastic audio: 5kbps-1Mbps video:10kbps-5Mbps same as above few kbps up elastic Data loss no loss no loss no loss loss-tolerant loss-tolerant loss-tolerant no loss Application layer protocol SMTP [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] HTTP (eg Youtube), RTP [RFC 1889] SIP, RTP, proprietary (e.g., Skype) Underlying transport protocol TCP TCP TCP TCP TCP or UDP typically UDP Application e-mail remote terminal access Web file transfer streaming multimedia Internet telephony

  5. Additionally Some Apps May Require: Support for Group Communication Broadcast: one to all Multicast: one to many (some) Anycast: one to any (from a group) Requires Membership management – who is in and who is not: IGMP – Internet Group Mgmt. Protocol Routing protocol Tree based (source-based, group/shared tree, …) Usually constructed in a distributed manner Transport level services – similar to unicast communication: reliability, throughput, timeliness, and security (in general not supported in Internet)

  6. DNS: Domain Name System 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 services • hostname to IP address translation • host aliasing • Canonical, alias names • mail server aliasing • load distribution • replicated Web servers: set of IP addresses for one canonical name 2: Application Layer 6

  7. Distributed, Hierarchical Database Client wants IP for www.amazon.com; 1st approx: client queries a root server to find com DNS server client queries com DNS server to get amazon.com DNS server client queries amazon.com DNS server to get IP address for www.amazon.com Root DNS Servers org DNS servers edu DNS servers com DNS servers poly.edu DNS servers umass.edu DNS servers pbs.org DNS servers yahoo.com DNS servers amazon.com DNS servers 2: Application Layer 7

  8. Design Principles embodied in DNS Hierarchical Design – improve scalability Distributed Design – improve scalability Replication – avoid single point of failure Caching – improve performance, scalability

  9. Design Issue: control and data signaling PSTN (public switched telephone network): SS7 (packets-switched control network) separate from (circuit-switched) call trunk lines earlier tone-based (in-band signaling) Internet: RSVP (signaling) separate from routing, forwarding. http: in-band signaling; ftp: out-of-band signaling

  10. Web and HTTP Web page consists of objects such as: HTML file, JPEG image, Java applet, audio file,… Web page consists of base HTML-file which includes several referenced objects Each object is addressable by a URL: www.someschool.edu/someDept/pic.gif path name host name HTTP: hypertext transfer protocol • Web’s application layer protocol • client/server model • Uses TCP; server listens on port 80 • Stateless • Two types: persistent and non-persistent

  11. Non Persistent versus Persistent HTTP Nonpersistent HTTP issues: requires 2 RTTs per object OS overhead for each TCP connection browsers often open parallel TCP connections to fetch referenced objects Persistent HTTP server leaves connection open after sending response subsequent HTTP messages between same client/server sent over open connection client sends requests as soon as it encounters a referenced object as little as one RTT for all the referenced objects

  12. HTTP request message two types of HTTP messages: request, response HTTP request message: ASCII (human-readable format) request line (GET, POST, HEAD commands) GET /somedir/page.html HTTP/1.1 Host: www.someschool.edu User-agent: Mozilla/4.0 Connection: close Accept-language:fr (extra carriage return, line feed) header lines Carriage return, line feed indicates end of message

  13. Uploading form input Post method: Web page often includes form input Input is uploaded to server in entity body URL method: Uses GET method Input is uploaded in URL field of request line: www.somesite.com/animalsearch?monkeys&banana 2: Application Layer 13

  14. Method types HTTP/1.0 GET POST HEAD asks server to leave requested object out of response Used for debugging purpose HTTP/1.1 GET, POST, HEAD PUT uploads file in entity body to path specified in URL field DELETE deletes file specified in the URL field 2: Application Layer 14

  15. HTTP response message status line (protocol status code status phrase) 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 …... Content-Length: 6821 Content-Type: text/html data data data data data ... header lines data, e.g., requested HTML file 2: Application Layer 15

  16. HTTP response status codes 200 OK request succeeded, requested object later in this message 301 Moved Permanently requested object moved, new location specified later in this message (Location:) 400 Bad Request request message not understood by server 404 Not Found requested document not found on this server 505 HTTP Version Not Supported In first line in server->client response message. A few sample codes: 2: Application Layer 16

  17. Trying out HTTP (client side) for yourself 1. Telnet to your favorite Web server: Opens TCP connection to port 80 (default HTTP server port) at cis.poly.edu. Anything typed in sent to port 80 at cis.poly.edu telnet cis.poly.edu 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/ HTTP/1.1 Host: cis.poly.edu 3. Look at response message sent by HTTP server! 2: Application Layer 17

  18. User-server state: cookies Many major Web sites use cookies Four components: 1) cookie header line of HTTP response message 2) cookie header line in HTTP request message 3) cookie file kept on user’s host, managed by user’s browser 4) back-end database at Web site Example: Susan always access Internet always from PC visits specific e-commerce site for first time when initial HTTP requests arrives at site, site creates: unique ID entry in backend database for ID 2: Application Layer 18

  19. Cookies: keeping “state” (cont.) ebay 8734 usual http request msg Amazon server creates ID 1678 for user usual http response Set-cookie: 1678 create entry ebay 8734 amazon 1678 ebay 8734 amazon 1678 usual http request msg cookie: 1678 access cookie- specific action usual http response msg usual http response msg access usual http request msg cookie: 1678 cookie- spectific action client server cookie file backend database one week later: 2: Application Layer 19

  20. Cookies (continued) What cookies can bring: authorization shopping carts recommendations user session state (Web e-mail) aside Cookies and privacy: • cookies permit sites to learn a lot about you • you may supply name and e-mail to sites How to keep “state”: • protocol endpoints: maintain state at sender/receiver over multiple transactions • cookies: http messages carry state 2: Application Layer 20

  21. Web caches (proxy server) user sets browser: Web accesses via cache browser sends all HTTP requests to cache object in cache: cache returns object else cache requests object from origin server, then returns object to client HTTP request HTTP request HTTP response HTTP response HTTP request HTTP response Goal: satisfy client request without involving origin server origin server Proxy server client client origin server 2: Application Layer 21

  22. More about Web caching cache acts as both client and server typically cache is installed by ISP (university, company, residential ISP) Why Web caching? reduce response time for client request reduce traffic on an institution’s access link. Internet dense with caches: enables “poor” content providers to effectively deliver content (but so does P2P file sharing) 2: Application Layer 22

  23. Caching Principle Cache: A Fast but Small Storage Access time Tc Main Memory: A “Slow” but Large Storage Acess time Tm (Tm >> Tc) Cache Hit Ratio - probability that item is found in the cache – 0< h < 1 Average data access time Ta: Ta = h*Tc + (1-h)*Tm Goal of caching system: ensure h to be closer to 1.

  24. Remember Queueing delay (from L4-L5) R=link bandwidth (bps) L=packet length (bits) a=average packet arrival rate traffic intensity = La/R • La/R ~ 0: average queueing delay small • La/R -> 1: delays become large • La/R > 1: more “work” arriving than can be serviced, average delay infinite! Introduction 1-24

  25. Web Proxy Caching example Assumptions average object size = 100,000 bits avg. request rate from institution’s browsers to origin servers = 15/sec delay from institutional router to any origin server and back to router = 2 sec Consequences utilization on LAN = 15% utilization on access link = 100% total delay = Internet delay + access delay + LAN delay = 2 sec + minutes + milliseconds origin servers public Internet 1.5 Mbps access link institutional network 10 Mbps LAN institutional cache 2: Application Layer 25

  26. Caching example (cont) possible solution increase bandwidth of access link to, say, 10 Mbps consequence utilization on LAN = 15% utilization on access link = 15% Total delay = Internet delay + access delay + LAN delay = 2 sec + msecs + msecs often a costly upgrade Still min of 2 sec (Internet delay) is needed origin servers public Internet 10 Mbps access link institutional network 10 Mbps LAN institutional cache 2: Application Layer 26

  27. Caching example (cont) possible solution: install cache suppose hit rate is 0.4 consequence 40% requests will be satisfied almost immediately 60% requests satisfied by origin server utilization of access link reduced to 60%, resulting in negligible delays (say 10 msec) total avg delay = Internet delay + access delay + LAN delay = .6*(2.01) secs + .4*milliseconds < 1.4 secs origin servers public Internet 1.5 Mbps access link institutional network 10 Mbps LAN institutional cache 2: Application Layer 27

  28. Conditional GET Goal: don’t send object if cache has up-to-date cached version cache: specify date of cached copy in HTTP request If-modified-since: <date> server: response contains no object if cached copy is up-to-date: HTTP/1.0 304 Not Modified HTTP response HTTP/1.0 304 Not Modified server cache HTTP request msg If-modified-since: <date> object not modified HTTP request msg If-modified-since: <date> object modified HTTP response HTTP/1.0 200 OK <data> 2: Application Layer 28

  29. Electronic Mail Three major components: user agents mail servers simple mail transfer protocol: SMTP User Agent a.k.a. “mail reader” composing, editing, reading mail messages e.g., Eudora, Outlook, elm, Mozilla Thunderbird 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 2: Application Layer 29

  30. Electronic Mail: mail servers Mail Servers mailbox contains incoming messages for user messagequeue of outgoing (to be sent) mail messages SMTP protocol 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 2: Application Layer 30

  31. Electronic Mail: SMTP [RFC 2821] uses TCP to reliably transfer email message from client to server, 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 2: Application Layer 31

  32. Scenario: Alice sends message to Bob 1) Alice uses UA to compose message and “to” bob@someschool.edu 2) Alice’s UA sends message to her mail server; message placed in message queue 3) Client side of SMTP opens TCP connection with Bob’s mail server 4) SMTP client sends Alice’s message over the TCP connection 5) Bob’s mail server places the message in Bob’s mailbox 6) Bob invokes his user agent to read message user agent user agent mail server mail server 1 2 6 3 4 5 2: Application Layer 32

  33. 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) 2: Application Layer 33

  34. SMTP: final words SMTP uses persistent connections SMTP requires message (header & body) to be in 7-bit ASCII SMTP server uses CRLF.CRLF to determine end of message Comparison with HTTP: HTTP: pull SMTP: push both have ASCII command/response interaction, status codes HTTP: each object encapsulated in its own response msg SMTP: multiple objects sent in multipart msg 2: Application Layer 34

  35. Mail access protocols SMTP: delivery/storage to receiver’s server 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: gmail, Hotmail, Yahoo! Mail, etc. user agent user agent sender’s mail server SMTP SMTP access protocol receiver’s mail server 2: Application Layer 35

  36. POP3 protocol authorization phase client commands: user: declare username pass: password server responses +OK -ERR transaction phase, client: list: list message numbers retr: retrieve message by number dele: delete quit S: +OK POP3 server ready C: user bob 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 2: Application Layer 36

  37. POP3 (more) and IMAP More about POP3 Previous example uses “download and delete” mode. Bob cannot re-read e-mail if he changes client “Download-and-keep”: copies of messages on different clients POP3 is stateless across sessions IMAP Keep all messages in one place: the server Allows user to organize messages in folders IMAP keeps user state across sessions: names of folders and mappings between message IDs and folder name 2: Application Layer 37

  38. Pure P2P architecture no always-on server arbitrary end systems directly communicate peers are intermittently connected and change IP addresses Three topics: File distribution Searching for information Case Study: Skype peer-peer 2: Application Layer 38

  39. File Distribution: Server-Client vs P2P Question : How much time to distribute file from one server to N peers? us: server upload bandwidth Server ui: peer i upload bandwidth u2 u1 d1 d2 us di: peer i download bandwidth File, size F dN Network (with abundant bandwidth) uN 2: Application Layer 39

  40. Remember Throughput: Internet scenario End-to-end throughput constrained by bottleneck link per-connection end-end throughput: min(Rc,Rs,R/10) in practice: Rc or Rs is often bottleneck Rs Rs Rs R Rc Rc Rc 10 connections (fairly) share backbone bottleneck link Rbits/sec Introduction 1-40

  41. File distribution time: server-client server sequentially sends N copies: NF/ustime client i takes F/di time to download Time to distribute F to N clients using client/server approach = dcs = max {NF/us, F/min(di)} i Server u2 F u1 d1 d2 us Network (with abundant bandwidth) dN uN increases linearly in N (for large N) 2: Application Layer 41

  42. server must send one copy: F/ustime client i takes F/di time to download NF bits must be downloaded (aggregate) File distribution time: P2P dP2P = max {F/us, F/min(di) , NF/(us + Sui)} i Server u2 F u1 d1 d2 us Network (with abundant bandwidth) dN uN • fastest possible upload rate: us + Sui 2: Application Layer 42

  43. Server-client vs. P2P: example Client upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us 2: Application Layer 43

  44. File distribution: BitTorrent obtain list of peers trading chunks peer • P2P file distribution tracker: tracks peers participating in torrent torrent: group of peers exchanging chunks of a file 2: Application Layer 44

  45. BitTorrent (1) file divided into 256KB chunks. peer joining torrent: has no chunks, but will accumulate them over time registers with tracker to get list of peers, connects to subset of peers (“neighbors”) while downloading, peer uploads chunks to other peers. peers may come and go once peer has entire file, it may (selfishly) leave or (altruistically) remain 2: Application Layer 45

  46. BitTorrent (2) Pulling Chunks at any given time, different peers have different subsets of file chunks periodically, a peer (Alice) asks each neighbor for list of chunks that they have. Alice sends requests for her missing chunks rarest first Sending Chunks: tit-for-tat • Alice sends chunks to four unchoked neighbors currently sending her chunks at the highest rate • re-evaluate top 4 every 10 secs • every 30 secs: randomly select another peer, starts sending chunks • newly chosen peer may join top 4 • “optimistically unchoke” 2: Application Layer 46

  47. BitTorrent: Tit-for-tat (1) Alice “optimistically unchokes” Bob (2) Alice becomes one of Bob’s top-four providers; Bob reciprocates (3) Bob becomes one of Alice’s top-four providers With higher upload rate, can find better trading partners & get file faster! 2: Application Layer 47

  48. What’s Next? HW 3 Will be posted soon Programming Assignment due next Wednesday Next Class: Chapter 2 cont. P2P (cont.) Chapter 4: Routing (Skip Ch3 for now)

  49. Distributed Hash Table (DHT) • DHT = distributed P2P database • Database has (key, value) pairs; • key: ss number; value: human name • key: content type; value: IP address • Peers query DB with key • DB returns values that match the key • Peers can also insert (key, value) peers

  50. DHT Identifiers • Assign integer identifier to each peer in range [0,2n-1]. • Each identifier can be represented by n bits. • Require each key to be an integer in same range. • To get integer keys, hash original key. • eg, key = h(“Led Zeppelin IV”) • This is why they call it a distributed “hash” table

More Related