1. Ch 2. Application Layer Myungchul Kim mckim@icu.ac.kr

2. 2 Principles of network applications – Develping new applications -> writing software running on multiple end systems

3. 3 o Network application architecture – Network architecture – Application architecture  Client-server architecture  P2P architecture

4. 4 o Client and server processes o The interface between the process and the computer network – Application programming interface (API)

5. 5 o Transport service available to applications – Reliable data data transfer – Throughput: bandwidth-sensitive applications and elastic applications – Timing – Security

6. 6 o Transport services provided by the Internet – TCP services  Connection-oriented service: handshaking, connection establishment, tearing down the connection  Reliable data transfer service  Congestion-control mechanism – UDP services  Connectionless  No handshaking  An unreliable data transfer service

7. 7

8. 8 o Today’s Internet can often provide satisfactory service to timesentive applications, but it cannot provide any timing or bandwidth guarantees. o Addressing processes: host by IP address + process by port number

9. 9 o Application-layer protocols – The types of messages exchanged – The syntax of the various message types – The semantics of the fields – Rules for examining when and how a process a sends messages and responds to messages – e.g., HTTP – Web’s application-layer protocol

10. 10 The Web and HTTP o Overview of HTTP – HyperText Transfer Protocol – Web page = a set of objects: an object = a file – Web browser = the client of HTTP – Web server = the server of HTTP – A stateless protocol o Non-persistent and persistent connections – HTTP with non-persistent connections  Each TCP connection is closed after the server sends the object.  (next slide) – HTTP with persistent connections  The server leaves the TCP connection open after sending a response.

11. 11 Nonpersistent HTTP Suppose user enters URL www.someSchool.edu/someDepartment/home.index 1a. HTTP client initiates TCP connection to HTTP server (process) at www.someSchool.edu on port 80 2. HTTP client sends HTTP request message (containing URL) into TCP connection socket. Message indicates that client wants object someDepartment/home.index 1b. HTTP server at host www.someSchool.edu waiting for TCP connection at port 80. “ accepts ” connection, notifying client 3. HTTP server receives request message, forms response message containing requested object, and sends message into its socket time (contains text, references to 10 jpeg images)

12. 12 Nonpersistent HTTP (cont.) 5. HTTP client receives response message containing html file, displays html. Parsing html file, finds 10 referenced jpeg objects 6. Steps 1-5 repeated for each of 10 jpeg objects 4. HTTP server closes TCP connection. time

13. 13

14. 14 o HTTP message format – Request messages and response messages – HTTP request message 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) request line (GET, POST, HEAD commands) Carriage return, line feed indicates end of message

15. 15

16. 16 HTTP response message 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... status line (protocol status code status phrase) header lines data, e.g., requested HTML file

17. 17 – HTTP response message:

18. 18 o User-server interaction: Cookies – Identify users – One-click shopping; shopping cart service

19. 19 o Web caching – Web cache = proxy server – A cache is both a server and a client at the same time.

20. 20

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

22. 22 FTP – Out-of-band, stateful protocol

23. 23 Electronic Mail o Simple Mail Transfer Protocol (SMTP)

24. 24 – The body of SMTP: 7-bit ASCII – Use persistent connections – Push protocol (cf. pull protocol e.g. HTTP)

25. 25 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

26. 26 o Mail Message Formats and MIME – Multipurpose Internet Mail Extensions (MIME)  Content-Type  Content-Transfer-Encoding o Mail Access Protocols – Post Office Protocol - Verson 3 (POP3), Internet Mail Acess Protocol (IMAP), and HTTP

27. 27 DNS – The Internet’s Directory Service – Domain name system – Identifer: hostname, IP address – Translate hostnames to IP addresses – Host aliasing: canonical hostname – Mail server aliasing – Load distribution: DNS rotation – A centralized design  A single point of failure  Traffic volume  Distant centralized database  Maintenance

28. 28 o A distributed, hierachical database – Root DNS servers – Top-level domain (TLD) servers – Authoritative DNS servers

29. 29

30. 30

31. 31

32. 32 – DNS caching: cache the mapping in its local memory o DNS records and messages – Resource records (RRs) – RR: (Name, Value, Type, TTL) – Type = A: hostanme and its IP address – Type = NS: domain and hostname of an authoritative DNS server – Type = CNAME: cananical hostname – Type = MX: canaonical name of a mail server

33. 33

34. 34 o Inserting records into the DNS database – Registrar – Internet Corporation for Assigned Names and Numbers (ICANN)

35. 35 Peer-to-Peer Applications – Peers vs service providers – File distribution, organizing and searching for information and Internet telephony application o P2P file distribution – Scalability of P2P architectures

36. 36 o BitTorrent – File distribution – Torrent: the collection of all peers participating in the distribution of a particular file – Chungs of a file (256KBytes) – Each torrent has an infrasturecture node called a tracker – Rarest first: from neighbors – Trading algorithm: gives priority to the neighbors that are currently supplying data at the highest rate – Four top peers and one probing peer – Free-riding

37. 37

38. 38 o Searching for information in a P2P community – Information index – a mapping of information to host locations – File sharing: files to peers – Instant message: username to locations (IP addresses) – Centralized index  Napster  A hybird of P2P and client-server architecture  Copyright infringement

39. 39 – Query flooding  Gnutella  The index is fully distributed over the community peers  Overlay network  Limited-scope query flooding  New peers join: bootstrap problem

40. 40 Gnutella: Peer joining 1. joining peer Alice must find another peer in Gnutella network: use list of candidate peers 2. Alice sequentially attempts TCP connections with candidate peers until connection setup with Bob 3. Flooding: Alice sends Ping message to Bob; Bob forwards Ping message to his overlay neighbors (who then forward to their neighbors ….) r peers receiving Ping message respond to Alice with Pong message 4. Alice receives many Pong messages, and can then setup additional TCP connections

41. 41 – Hierarchical overlay  FastTrack, Kazaa and Morpheus  Limited-scope flooding in the overlay network of super peers

42. 42 o Case study: P2P Internet Telephony with Skype – Real time – P2P for user location and for NAT traversal

43. 43 P2P Case study: Skype o P2P (pc-to-pc, pc-to-phone, phone-to-pc) Voice-Over-IP (VoIP) application – also IM o proprietary application-layer protocol (inferred via reverse engineering) o hierarchical overlay Skype clients (SC) Supernode (SN) Skype login server

44. 44 Skype: making a call o User starts Skype Skype login server o SC registers with SN – list of bootstrap SNs o SC logs in (authenticate) o Call: SC contacts SN will callee ID – SN contacts other SNs (unknown protocol, maybe flooding) to find addr of callee; returns addr to SC o SC directly contacts callee, overTCP