3rd Edition: Chapter 2 - UF CISE

1 .2: Application Layer 1 Chapter 2 Application Layer Computer Networking: A Top Down Approach , 4 th edition. Jim Kurose, Keith Ross Addison-Wesley, July 2007. (Updated Apr 09, Sept 10). (Updated Aug 2012).

2 .2: Application Layer 2 Creating a network app write programs that run on (different) end systems communicate over network e.g., web server software communicates with browser software No need to write software for network-core devices network core devices do not run user 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

3 .2: Application Layer 3 Application architectures Client-server Peer-to-peer (P2P) Hybrid of client-server and P2P

4 .2: Application Layer 4 Client-server architecture server: always-on host permanent IP address server farms for scaling Clients (in general): communicate with server intermittently connected have dynamic IP addresses do not communicate directly with each other client/server

5 .2: Application Layer 5 Pure P2P architecture there is no always-on server arbitrary end systems directly communicate peers intermittently connected & change IP addresses example: Gnutella Highly scalable but difficult to manage peer-peer

6 .2: Application Layer 6 Hybrid of client-server and P2P Skype voice-over-IP P2P application centralized server: finding address of remote party client-client connection: direct (not through server) Instant messaging chatting between two users is P2P centralized service: client presence detection & location user registers IP address with central server when it comes online u ser contacts central server to find IP addresses of buddies

7 .2: Application Layer 7 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: www.someschool.edu/someDept/pic.gif host name path name

8 .2: Application Layer 8 HTTP overview HTTP: hypertext transfer protocol client/server model client: browser that requests, receives, displays Web objects server: Web server sends objects in response to requests HTTP 1.0: RFC 1945 HTTP 1.1: RFC 2068 (persistent TCP) PC running Explorer Server running Apache Web server Mac running FireFox /Chrome HTTP request HTTP request HTTP response HTTP response

9 .2: Application Layer 9 HTTP overview (continued) Uses TCP: 1. client initiates TCP connection to server,port 80 2. server accepts TCP connection from client 3. HTTP (application-layer) messages exchanged between HTTP client and HTTP server 4. TCP connection closed HTTP is “stateless” server maintains no information about past client requests Protocols that maintain “state” are complex! Past history (state) must be maintained if server/client crashes, views of “state” may be inconsistent, must be reconciled state is added via ‘cookies’ Design Issues: - Stateful vs Stateless vs Hybrid - Hard vs Soft State vs Hybrid A ‘state’ is information kept in memory of a host, server or router to reflect past events: such as routing tables, data structures or database entries

10 .2: Application Layer 10 HTTP connections I. Nonpersistent HTTP At most one object is sent over a TCP connection. HTTP/1.0 uses nonpersistent HTTP II. Persistent HTTP Multiple objects can be sent over single TCP connection between client and server. Used in HTTP/1.1 by default: A. persistent with pipelining B. persistent without pipelining

11 .2: Application Layer 11 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 Persistent without pipelining: client issues new request only when previous response has been received one RTT for each referenced object Persistent with pipelining: default in HTTP/1.1 client sends requests as soon as it encounters a referenced object as little as one RTT for all the referenced objects

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

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

14 .2: Application Layer 14 Web caches & proxy servers user sets browser: Web accesses via cache browser sends all HTTP requests to cache object in cache (cache hit): cache returns object else (cache miss) cache requests object from origin server, then returns object to client Cache keeps copy of object for future use Goal: satisfy client request without involving origin server client Proxy server client HTTP request HTTP response HTTP request HTTP request origin server origin server HTTP response HTTP response - Can all objects be cached? - Proxy vs. local browser cache

15 .2: Application Layer 15 More about Web caching cache acts as both client and server typically cache is installed by ISP (university, company, residential ISP) Why Web caching? 1. reduce response time for client request 2. reduce traffic on an institution’s access link 3. other: hiding original requester!

16 .2: Application Layer 16 Caching example Assumptions average object size = 100k bits avg. request rate from institution’s browsers = 15 req/sec delay from institutional router to any origin server and back = 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 institutional network 10 Mbps LAN 1.5 Mbps access link

17 .2: Application Layer 17 Caching example (cont) one solution: install cache suppose cache 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 institutional network 10 Mbps LAN 1.5 Mbps access link institutional cache

18 .2: Application Layer 18 FTP: the file transfer protocol client/server model client: side initiating transfer, server: remote host ftp: RFC 959, ftp server: port 21 Separate data and control connections Control connection “out of band” FTP server maintains “state”: current directory, earlier authentication file transfer FTP server FTP user interface FTP client local file system remote file system user at host FTP client FTP server TCP control connection port 21 TCP data connection port 20

19 .2: Application Layer 19 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 1. handshake, 2. transfer of messages, 3. closure SMTP uses persistent connections: sending mail server sends all its messages to the receiving mail server over one TCP connection Email Scenario: user agent mail server mail server user agent 1 2 3 4 5 6 Send mail Rcv mail user agent sender’s mail server user agent SMTP SMTP access protocol receiver’s mail server

20 .2: Application Layer 20 SMTP: 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 Protocol Design Issue: Pull vs. Push vs. Hybrid (spectrum) how far do we push/pull Issues & factors to analyze: access pattern, delay, object dynamics, …

21 .2: Application Layer 21 DNS: Domain Name System Internet identifiers for hosts, routers: IP address used for addressing datagrams “name”, e.g., ww.yahoo.com - used by humans Q: map between IP addresses and name, and vice versa ? Domain Name System: distributed database implemented in hierarchy of many name servers application-layer protocol host, routers, name servers to communicate to resolve names (address/name translation) note: core Internet function, implemented as application-layer protocol complexity at network’s “edge”

22 .2: Application Layer 22 Root DNS Servers com DNS servers org DNS servers edu DNS servers poly.edu DNS servers umass.edu DNS servers yahoo.com DNS servers amazon.com DNS servers pbs.org DNS servers Distributed, Hierarchical Database Client wants IP for www.amazon.com; 1 st 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

23 .2: Application Layer 23 DNS: Root 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 13 root name servers worldwide b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA e NASA Mt View, CA f Internet Software C. Palo Alto, CA (and 36 other locations) i Autonomica, Stockholm (plus 28 other locations) k RIPE London (also 16 other locations) m WIDE Tokyo (also Seoul, Paris, SF) 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)

24 .2: Application Layer 24 TLD and Authoritative Servers I. Top-level domain (TLD) servers: responsible for com, org, net, edu, etc, and all top-level country domains uk, fr, ca, jp. Network Solutions maintains servers for com TLD Educause for edu TLD II. Authoritative DNS servers: organization’s DNS servers, providing authoritative hostname to IP mappings for organization’s servers (e.g., Web, mail). can be maintained by organization or service provider

25 .2: Application Layer 25 III. Local Name Server does not strictly belong to hierarchy each ISP (residential ISP, company, university) has one. also called “default name server” when host makes DNS query, query is sent to its local DNS server acts as proxy, forwards query into hierarchy

26 .2: Application Layer 26 requesting host cis.poly.edu gaia.cs.umass.edu root DNS server local DNS server dns.poly.edu 1 2 3 4 5 6 authoritative DNS server dns.cs.umass.edu 7 8 TLD DNS server DNS name resolution example Host at cis.poly.edu wants IP address for gaia.cs.umass.edu A. iterative query: contacted server replies with name of server to contact “I don’t know this name, but ask this server”

27 .2: Application Layer 27 requesting host cis.poly.edu gaia.cs.umass.edu root DNS server local DNS server dns.poly.edu 1 2 4 5 6 authoritative DNS server dns.cs.umass.edu 7 8 TLD DNS server 3 B. recursive query: puts burden of name resolution on contacted name server heavy load? DNS name resolution example

28 .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 Application 2- 28

29 .2: Application Layer 29 P2P: centralized directory original “Napster” design 1) when peer connects, it informs central server: IP address content 2) Alice queries for “Hey Jude” 3) Alice requests file from Bob centralized directory server peers Alice Bob 1 1 1 1 2 3