Application layer. Some network apps. Client-server architecture. Hybrid of client-server and P2P. Pure P2P architecture. Creating a network app

Transcription

1 Application layer Some network apps e- web instant messaging remote login P2P file sharing multi- network games streaming stored video (YouTube) voice over IP real-time video conferencing cloud computing Application 2-1 Application 2-2 Creating a network app write programs that run on (different) end systems communicate over network e.g., web software communicates with browser software No need to write software for network-core devices network-core devices do not run applications applications on end systems allows for rapid app development, propagation application transport network data link physical application transport network data link physical application transport network data link physical Client- architecture / : always-on host permanent IP address farms for scaling s: communicate with may be intermittently connected may have dynamic IP addresses do not communicate directly with each other Application 2-3 Application 2-4 Pure P2P architecture Hybrid of - and P2P no always-on end systems directly communicate peers are intermittently connected and change IP addresses peer-peer Skype voice-over-ip P2P application centralized : finding address of remote party: - connection: direct (not through ) Instant messaging chatting between two s is P2P centralized service: presence detection/location Application 2-5 Application 2-6 1

2 Processes communicating Sockets process: program running within a host. processes in different hosts communicate by exchanging messages process: process that initiates communication process: process that waits to be contacted process sends/receives messages to/from its socket socket analogous to door sending process shoves message out door sending process relies on transport infrastructure on other side of door which brings message to socket at receiving process host or process socket TCP with buffers, variables controlled by app developer controlled by OS Internet host or process socket TCP with buffers, variables Application 2-7 Application 2-8 Addressing processes to receive messages, process must have identifier host device has unique 32-bit IP address Q: does IP address of host on which process runs suffice for identifying the process? A: No, many processes can be running on same host identifier includes both IP address and port numbers associated with process on host. example port numbers: HTTP : 80 Mail : 25 to send HTTP message to gaia.cs.umass.edu web : IP address: Port number: 80 App-layer protocol defines types of messages e.g., request, response message syntax: what fields in messages message semantics meaning of information in fields rules for when and how processes send & respond to messages public-domain protocols: defined in RFCs e.g., HTTP, proprietary protocols: e.g., Skype Application 2-9 Application 2-10 What transport service does an app need? Data loss some apps (e.g., audio) can tolerate some loss other apps (e.g., file transfer) require 100% reliable data transfer Timing some apps (e.g., Internet telephony, interactive games) require low delay to be effective Throughput some apps (e.g., multimedia) require minimum amount of throughput to be effective other apps ( elastic apps ) make use of whatever throughput they get Internet transport protocols services TCP service: connection-oriented: setup required between and processes reliable transport flow control congestion control does not provide: timing, minimum throughput guarantees UDP service: unreliable data transfer between sending and receiving process Application 2-11 Application

3 Web and HTTP Web and HTTP First, a review web page consists of objects object can be 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 example URL: host name path name Application 2-13 Application 2-14 HTTP overview HTTP overview (continued) HTTP: hypertext transfer protocol Web s application layer protocol / model : browser that requests, receives, displays Web objects : Web sends objects in response to requests PC running Explorer Mac running Navigator Server running Apache Web Uses TCP: initiates TCP connection (creates socket) to, port 80 accepts TCP connection from HTTP messages (applicationlayer protocol messages) exchanged between browser (HTTP ) and Web (HTTP ) TCP connection closed HTTP is stateless maintains no information about past requests aside protocols that maintain state are complex! past history (state) must be maintained if / crashes, their views of state may be inconsistent Application 2-15 Application 2-16 HTTP connections HTTP request message non-persistent HTTP at most one object sent over TCP connection. persistent HTTP multiple objects can be sent over single TCP connection between,. Application 2-17 two types of HTTP messages: request, response HTTP request message: ASCII (human-readable format) request line (GET, POST, HEAD commands) header lines carriage return, line feed at start of line indicates end of header lines carriage return character line-feed character GET /index.html HTTP/1.1\r\n Host: www-net.cs.umass.edu\r\n User-Agent: Firefox/3.6.10\r\n Accept: text/html,application/xhtml+xml\r\n Accept-Language: en-us,en;q=0.5\r\n Accept-Encoding: gzip,deflate\r\n Accept-Charset: ISO ,utf-8;q=0.7\r\n Keep-Alive: 115\r\n Connection: keep-alive\r\n \r\n Application

4 HTTP request message: general format HTTP response message request line header lines body status line (protocol status code status phrase) header lines data, e.g., requested HTML file HTTP/ OK\r\n Date: Sun, 26 Sep :09:20 GMT\r\n Server: Apache/ (CentOS)\r\n Last-Modified: Tue, 30 Oct :00:02 GMT\r\n ETag: "17dc6-a5c-bf716880"\r\n Accept-Ranges: bytes\r\n Content-Length: 2652\r\n Keep-Alive: timeout=10, max=100\r\n Connection: Keep-Alive\r\n Content-Type: text/html; charset=iso \r\n \r\n data data data data data... Application 2-19 Application 2-20 HTTP response status codes status code appears in 1st line in -> response message. some sample codes: 200 OK request succeeded, requested object later in this msg 301 Moved Permanently requested object moved, new location specified later in this msg (Location:) 400 Bad Request request msg not understood by 404 Not Found requested document not found on this 505 HTTP Version Not Supported User- state: cookies many 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 s host, managed by s browser 4) back-end database at Web site example: Susan always access Internet 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 Application 2-21 Application 2-22 Cookies: keeping state (cont.) Web caches (proxy ) Goal: satisfy request without involving origin ebay 8734 cookie file ebay 8734 amazon 1678 one week later: ebay 8734 amazon 1678 usual http request msg usual http response Set-cookie: 1678 usual http request msg cookie: 1678 usual http response msg usual http request msg cookie: 1678 usual http response msg Amazon creates ID 1678 for create entry cookiespecific action cookiespecific action access access backend database 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, then returns object to Proxy origin origin Application 2-23 Application

5 More about Web caching Conditional GET cache acts as both and typically cache is installed by ISP (university, company, residential ISP) why Web caching? reduce response time for request reduce traffic on an institution s access link. Internet dense with caches: enables poor content providers to effectively deliver content 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> : response contains no object if cached copy is up-to-date: HTTP/ Not Modified cache HTTP request msg If-modified-since: <date> HTTP response HTTP/ Not Modified HTTP request msg If-modified-since: <date> HTTP response HTTP/ OK <data> object not modified before <date> object modified after <date> Application 2-25 Application 2-26 : the file transfer protocol at host interface local file system file transfer remote file system transfer file to/from remote host / model : side that initiates transfer (either to/from remote) : remote host ftp: RFC 959 ftp : port 21 Application 2-27 Application 2-28 : separate control, data connections commands, responses contacts at port 21, TCP is transport protocol authorized over control connection browses remote directory by sending commands over control connection. when receives file transfer command, opens 2 nd TCP connection (for file) to after transferring one file, closes data connection. TCP control connection, port 21 TCP data connection, port 20 opens another TCP data connection to transfer another file. maintains state : current directory, earlier authentication some commands: sent as ASCII text over control channel USER name PASS password LIST return list of file in current directory RETR filename retrieves (gets) file STOR filename stores (puts) file onto remote host some 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 Application 2-29 Application

6 E Electronic Mail outgoing message queue Three major components: s s simple transfer protocol: User Agent reader composing, editing, reading messages e.g., Outlook, elm, Mozilla Thunderbird, iphone outgoing, incoming messages stored on box Application 2-31 Application 2-32 Electronic Mail: s Electronic Mail: [RFC 2821] Mail Servers box contains incoming messages for message queue of outgoing (to be sent) messages protocol between s to send e messages : sending : receiving uses TCP to reliably transfer e message from to, port 25 direct transfer: sending to receiving three phases of transfer handshaking (greeting) transfer of messages closure command/response interaction commands: ASCII text response: status code and phrase Application 2-33 Application 2-34 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 ; message placed in message queue 3) Client side of opens TCP connection with Bob s ) sends Alice s message over the TCP connection 5) Bob s places the message in Bob s box 6) Bob invokes his to read message 5 6 Mail message format : protocol for exchanging e msgs RFC 822: standard for text message format: header lines, e.g., To: From: Subject: different from commands! body the message header body blank line Application 2-35 Application

7 Mail access protocols POP3 and IMAP access protocol sender s receiver s : delivery/storage to receiver s access protocol: retrieval from POP: Post Office Protocol [RFC 1939] authorization ( <-->) and download IMAP: Internet Mail Access Protocol [RFC 1730] more features (more complex) manipulation of stored msgs on HTTP: g, Hot, Yahoo! Mail, etc. POP3 previous example uses download and delete mode. Bob cannot re-read e- if he changes download-and-keep : copies of messages on different s IMAP keeps all messages in one place: at allows to organize messages in folders keeps state across sessions: names of folders and mappings between message IDs and folder name Application 2-37 Application 2-38 DNS DNS DNS services hostname to IP address translation host aliasing Canonical, alias names aliasing load distribution replicated Web s: set of IP addresses for one canonical name Why not centralize DNS? single point of failure traffic volume distant centralized database maintenance doesn t scale! Application 2-39 Application 2-40 Distributed, Hierarchical Database Root DNS Servers com DNS s org DNS s edu DNS s yahoo.com DNS s amazon.com DNS s pbs.org DNS s poly.edu umass.edu DNS s DNS s wants IP for 1 st approx: queries a root to find com DNS queries com DNS to get amazon.com DNS queries amazon.com DNS to get IP address for DNS: Root name s contacted by local name that can not resolve name root name : contacts authoritative name if name mapping not known gets mapping returns mapping to local name e NASA Mt View, CA f Internet Software C. Palo Alto, CA (and 36 other locations) b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA 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) k RIPE London (also 16 other locations) i Autonomica, Stockholm (plus 28 other locations) m WIDE Tokyo (also Seoul, Paris, SF) 13 root name s worldwide Application 2-41 Application

8 TLD and Authoritative Servers DNS name resolution example root DNS Top-level domain (TLD) s: responsible for com, org, net, edu, aero, jobs, museums, and all top-level country domains, e.g.: uk, fr, ca, jp Authoritative DNS s: organization s DNS s, providing authoritative hostname to IP mappings for organization s s (e.g., Web, ). can be maintained by organization or service provider host at cis.poly.edu wants IP address for gaia.cs.umass.edu iterated query: contacted replies with name of to contact I don t know this name, but ask this local DNS dns.poly.edu requesting host cis.poly.edu TLD DNS 6 authoritative DNS dns.cs.umass.edu gaia.cs.umass.edu Application 2-43 Application 2-44 DNS name resolution example root DNS DNS: caching and updating records recursive query: puts burden of name resolution on contacted name local DNS dns.poly.edu TLD DNS once (any) name learns mapping, it caches mapping cache entries timeout (disappear) after some time TLD s typically cached in local name s Thus root name s not often visited requesting host cis.poly.edu authoritative DNS dns.cs.umass.edu gaia.cs.umass.edu Application 2-45 Application 2-46 DNS protocol, messages P2P DNS protocol : query and reply messages, both with same message format msg header identification: 16 bit # for query, reply to query uses same # flags: query or reply recursion desired recursion available reply is authoritative Application 2-47 Application

9 Minimum Distribution Time Pure P2P architecture File Distribution: Server-Client vs P2P no always-on arbitrary end systems directly communicate peers are intermittently connected and change IP addresses peer-peer Question : How much time to distribute file from one to N peers? File, size F Server u 1 d 1 u 2 u s d2 u s : upload bandwidth u i : peer i upload bandwidth d i : peer i download bandwidth d N u N Network (with abundant bandwidth) Application 2-49 Application 2-50 Server- vs. P2P: example Client upload rate = u, F/u = 1 hour, u s = 10u, d min u s P2P Client-Server File distribution: BitTorrent P2P file distribution tracker: tracks peers participating in torrent torrent: group of peers exchanging chunks of a file obtain list of peers trading chunks N peer Application 2-51 Application 2-52 BitTorrent 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 BitTorrent 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 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 Application 2-53 Application

10 P2P example: Skype pairs of s communicate proprietary application-layer protocol hierarchical overlay with SNs Index maps names to IP addresses; distributed over SNs Skype login Skype s (SC) Supernode (SN) Application