Presentation is loading. Please wait.

Presentation is loading. Please wait.

Chapter 8 Application Layer based on: Computer Networking: A Top Down Approach, 5 th edition. Jim Kurose, Keith Ross Addison-Wesley, April 2009. A note.

Similar presentations

Presentation on theme: "Chapter 8 Application Layer based on: Computer Networking: A Top Down Approach, 5 th edition. Jim Kurose, Keith Ross Addison-Wesley, April 2009. A note."— Presentation transcript:

1 Chapter 8 Application Layer based on: Computer Networking: A Top Down Approach, 5 th edition. Jim Kurose, Keith Ross Addison-Wesley, April 2009. A note on the use of these ppt slides: We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following:  If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we’d like people to use our book!)  If you post any slides in substantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material. Thanks and enjoy! JFK/KWR All material copyright 1996-2010 J.F Kurose and K.W. Ross, All Rights Reserved Application 8-1

2 Application Layer 8-2 Chapter 8: Application Layer Our goals: r conceptual / implementation aspects of network application protocols m transport-layer service models m client-server paradigm m peer-to-peer paradigm r learn about application-layer protocols by looking at examples: m HTTP (web) m DNS(web addressing) r mention briefly other application protocols

3 Application Layer 8-3 Creating network applications Write programs that m run on different end systems and m communicate over a network. m e.g., Web server software talks to browser software No app. software written for devices in network core m Network core devices do not function at application layer m This design allows for rapid app development application transport network data link physical application transport network data link physical application transport network data link physical

4 Application Layer 8-4 App-layer protocol defines r Types of messages exchanged, e.g. request & response messages r Semantics: list of needed fields per msg & meaning of each field r Syntax of each message type: where fields are located, how they are formatted r Rules for when and how processes send & respond to messages 2TYPES OF PROTOCOLS: Public-domain protocols: r defined in RFCs (mostly) r enable interoperability r e.g: HTTP, SMTP, SIP Proprietary protocols: r owned by a company r eg: Skype, Messenger

5 Application Layer 8-5 Client / Server concepts r Hardware view r Process / interaction view r Client-Server architecture r Peer-to-Peer architecture

6 Application Layer 8-6 Client Host /Server Host server host : m always-on host m serves remote users m permanent IP address m server farms for scaling client host (=workstation): m located next to user m may be intermittently connected m may have dynamic IP address Note: r Both client and server are called hosts

7 Application Layer 8-7 Process: program running within a host. r processes in different hosts communicate by exchanging messages r when processes cooperate for a common purpose, there must be one of them that initiates the common work m Sends the first message Client process: process that initiates communication Server process: process that waits to be contacted by client Note: r Client process may run on a client host or on a server host r Server process may run on a server host or a client host (see Peer to Peer architecture) Client Process/Server Process

8 Note: r Server host usually runs several server processes in parallel server process: m waits all the time for work m its IP address must be known to the client process at interaction start. WHY? client process: m initiates interaction with server process when it needs server’s help m if server process agrees : m they exchange messages m the messages enable them to cooperate in order to get the work done m Does client address have to be known in advance? Why? Application Layer 8-8 Process Interaction Scenario Client process 1 Client process 2 Server proc. 1 Server proc. 2

9 Application Layer 8-9 Client-Server architecture server process: m runs on server host only m the server host’s IP address is publicly known client process: m runs on client host (usually) or on a server host m example: in e-mail appl. the sender mail server runs a client process, while the receiving MS runs a server process

10 Pure P2P architecture r no always-on server r arbitrary end systems (usually workstations) directly communicate r peers are intermittently connected and change IP addresses highly scalable but difficult to manage peer-peer Application 8-10

11 Hybrid of client-server and P2P Skype m voice-over-IP P2P application m centralized server: finding address of remote party: m client-client connection: direct voice communication Instant messaging m chatting btw. two users is P2P m centralized service: client presence detection/location user registers its IP address with central server when it comes online initiating user contacts central server to find IP addresses of buddies Application 8-11 data initializatio n C-S P2P

12 What transport service does an app need? Data loss r some apps (e.g., file transfer, telnet) require 100% reliable data transfer r other apps (e.g., audio) can tolerate some loss Timing r 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 Security  encryption, data integrity, … Application 8-12

13 Application Layer 8-13 Transport service requirements of common apps Application file transfer e-mail Web documents real-time audio/video stored audio/video interactive games instant messaging Data loss no loss loss-tolerant no loss Bandwidth elastic audio: 5kbps-1Mbps video:10kbps-5Mbps same as above few kbps up elastic Time Sensitive no yes, 100’s msec yes, a few secs yes, 100’s msec sometimes

14 #14 HTTP Application Layer

15 8-15 Web and HTTP First a review r Web page consists of objects r Object can be HTML file, JPEG image, Java applet, audio file, … r Web page consists of base HTML-file which includes several referenced objects r Each object is addressable by a URL r Example URL: host name path name

16 Application Layer 8-16 HTTP overview HTTP: hypertext transfer protocol r Web’s application layer protocol r client/server model m client : browser that requests, receives and “displays” Web objects m server : Web server that sends objects in response to requests r HTTP 1.0 : RFC 1945 r HTTP 1.1 : RFC 2616 PC running Explorer Server running Apache Web server Mac running Navigator HTTP request HTTP response Note: r Different H/W and S/W r use the same protocol

17 Application Layer 8-17 HTTP overview (continued) HTTP uses TCP: r client initiates TCP connection (creates socket) to server port 80 (WKP) r server accepts TCP connection from client r HTTP messages (application- layer protocol messages) exchanged between browser (HTTP client) and Web server (HTTP server) r TCP connection closed HTTP is “stateless” r HTTP keeps no information about past client requests m BUT, cookies allow Web server to run stateful applications Protocols that maintain “state” are complex! r past history (state) must be maintained r if server/client crashes, their views of “state” may be inconsistent, must be reconciled note

18 Application Layer 8-18 HTTP connections Nonpersistent HTTP r At most one object sent over a TCP connection. r is default in HTTP/1.0 m use Keep Alive header to force Persistent mode r Disadvantages : 1. wastes 1 RTT per message 2. adds overhead packets 3. stays most of the time in Slow Start Cong. Ctrl r Partial help: m use parallel connections Persistent HTTP r Multiple objects sent over single TCP connection between client and server. m Last request contains the Close Connection header r is default in HTTP/1.1 Persistent with Pipelining r Send requests for referenced objects one after the other, without waiting for response to previous requests r saves another RTT per object

19 r two types of HTTP messages: request, response r all msgs in ASCII (human-readable) format r HTTP request message example: GET HTTP/1.1\r\n Host:\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-8859-1,utf-8;q=0.7\r\n Connection: Close\r\n \r\n carriage return, line feed at start of line indicates end of header lines HTTP request message request line header lines Application 8-19 carriage return character line-feed character method (other methods: POST, HEAD, …)

20 HTTP request message: general format Application 8-20 request line header lines body

21 Uploading form input POST method: r browser sends to server data that was input by user into a page form r data appended in entity body of message Such input can be also sent using GET r in this case the data is loaded onto the URL field of the request line r appears after a “?” sign; example of such URL: Application 8-21

22 Application Layer 8-22 Methods HTTP/1.0 r GET r POST r HEAD m asks server to leave requested object out of response m Used for: debugging troubleshooting HTTP/1.1 r GET, POST, HEAD r PUT m uploads file in the entity body to the server to be saved path specified in the path stated in the URL field r DELETE m deletes file specified in the URL field

23 HTTP response message status line header lines data, e.g., requested HTML file Application 8-23 HTTP/1.1 200 OK\r\n Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n Server: Apache/2.0.52 (CentOS)\r\n Last-Modified: Tue, 30 Oct 2007 17:00:02 GMT\r\n ETag: "17dc6-a5c-bf716880"\r\n Accept-Ranges: bytes\r\n Content-Length: 2652\r\n Connection: Close\r\n Content-Type: text/html;charset=ISO-8859-1\r\n \r\n status codestatus phraseprotocol entity body

24 Application Layer 8-24 HTTP response status codes 200 OK m request succeeded, requested object later in this message 301 Moved Permanently m requested object moved, new location specified later in this message (“Location”: header line) 400 Bad Request m request message not understood by server 404 Not Found m requested document not found on this server 505 HTTP Version Not Supported In first line of the response message. A few examples of status codes:

25 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 anything typed is sent to port 80 at telnet 80 2. type in a GET HTTP request: GET /~ross/ HTTP/1.1 Host: by typing this in (hit carriage return twice), you send this minimal (but complete) GET request to HTTP server 3. look at response message sent by HTTP server! Application 8-25 (or use wireshark!)

26 Application Layer 8-26 User-server “state”: cookies Many Web sites use cookies Four components: 1) the HTTP server sends response message with a ‘ Set-Cookie:’ header 2) user’s browser puts the ‘ Set-Cookie:’ header content ( “cookie”), labeled with server name, in the cookie file on user’s host, 3) next request message to this server will contain Cookie: header containing the relevant cookie 4) cookie points to database record at server site (or holds client data for server) Example: m Susan accesses Internet always from same PC m She visits a specific e-commerce site for first time m When initial HTTP requests arrives at site, site creates a unique ID and an entry in backend database for that ID m The ID is the cookie between them

27 Cookies: keeping “state” (cont.) client server 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- specific action access ebay 8734 amazon 1678 backend database Application 8-27

28 Application Layer 8-28 Cookies (continued) What cookies can bring: r user session state (e.g. in Web e-mail) r user identification m on given workstation r shopping carts r recommendations Cookies and privacy: r cookies permit sites to learn a lot about you o you may supply name and e-mail to sites r advertising companies obtain info across sites from inserted banner adds o info collected by the advertizing server o there are regulatory restrictions on releasing it aside

29 Application Layer 8-29 Web cache (proxy server) r user sets up browser to access Web via proxy r browser sends all HTTP requests to proxy m IF object in the proxy’s cache: proxy returns object m ELSE proxy requests object from origin server, then returns object to client  and keeps file in its cache  Note: user’s browser has a private cache on its host. Goal: satisfy client request without involving origin server client Proxy Server (web cache) client HTTP request HTTP response HTTP request HTTP response origin server origin server

30 Application Layer 8-30 More about Web caching r proxy acts as HTTP client and server r Typically proxy is installed by ISP or user’s organization. Caching advantages r Reduces response time for client request. r Reduces traffic on an institution’s access link. r Internet dense with proxies enables “poor” content providers to effectively deliver content Qn :what is the main problem with caching as described? Caching rules r Origin server may : m forbid caching m allow caching by private cache only (privacy) r Origin server sends: m Last Modified date/time m Expiration time or m Max. time to hold object r Proxy should respect age and other restrictions

31 Caching example (1) assumptions r average object size = 100,000 bits r average request rate from institution’s browsers to origin servers = 15/sec r delay from institutional router to any origin server and back to router = 2 sec consequences r utilization on LAN = 15% r utilization on access link = 100% r total delay = Internet delay + access link delay + LAN delay = 2 sec + minutes + milliseconds origin servers public Internet institutional network 10 Mbps LAN 1.5 Mbps access link institutional cache Application 8-31

32 Caching example (2) possible solution r increase bandwidth of access link to, say, 10 Mbps consequence r utilization on LAN = 15% r utilization on access link = 15% r Total delay = Internet delay + access delay + LAN delay = 2 sec + msecs + msecs r often a costly upgrade origin servers public Internet institutional network 10 Mbps LAN 10 Mbps access link institutional cache Application 8-32

33 Caching example (3) possible solution: r install cache locally consequence r suppose hit rate is 0.4 m 40% requests will be satisfied almost immediately m 60% requests satisfied by origin server r utilization of access link reduced to 60%, resulting in negligible delays (say 10 msec) r 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 Application 8-33

34 Application Layer 8-34 Conditional GET r Don’t send object if cached version is up-to-date m used if proxy has object but cacheability conditions are missing or not satisfied r proxy specifies date of cached copy in HTTP request header: r server sends short response if cached copy is up-to-date: (see Case 1 on this slide) HTTP/1.0 304 Not Modified (contains no object) If-modified-since: proxy server HTTP request msg If-modified-since: HTTP response HTTP/1.0 304 Not Modified object not modified Case 1 HTTP request msg If-modified-since: HTTP response HTTP/1.0 200 OK object modified proxy server Case 2

35 Application Layer 8-35 Legacy Internet Applications Telnet r Remote terminal r Enables user to enter line commands to remote host r Remote host returns display to user. r characters sent one by one and echoed on display r sets char. encoding rules Client-Server Email r Mail client on user’s host m e.g. Outlook r User mailbox on his Server r Msg prepared on client, sent to origin user’s Mail Server (MS) m may use SMTP r MS sends to dest. MS using SMTP (a PUSH protocol) r dest. MS stores msg in mailbox r User collects msg using PULL protocol (POP3 or IMAP) Webmail r Client functionality is on Server r User has an HTTP GUI terminal FTP r File transfer and remote control of a file server r Uses Telnet encoding rules o as do most other applications

36 #36 DNS Application Layer

37 8-37 DNS: Domain Name System People: many identifiers: m SSN, name, passport # Internet hosts, routers: m IP address (32 bit) - used for addressing datagrams (packets) – good for routers m “name”, e.g., – good for human use Q: map between name and IP addresses ? Domain Name System: 1. Distributed database implemented in hierarchy of many name servers (NS’s) 2. application-layer protocol host, routers, name servers communicate to resolve names (name-to-address translation) (WKP: UDP 53) m Note: Internet infrastructure function, implemented as an application-layer protocol m all the work at network’s “edge”, not in the core

38 Application Layer 8-38 DNS Why not centralize DNS? r difficult to manage and maintain r single point of failure r traffic volume r distant centralized database r doesn’t scale! DNS services r Hostname to IP address translation r Host aliasing m canonical name = main name of computer m alias = additional name r Finding server names m e.g hostname of mail server for domain r Load distribution m Replicated Web servers: set of IP addresses for one canonical name

39 Application Layer 8-39 Root DNS Servers (*) com DNS servers org DNS serversedu DNS servers DNS servers DNS servers DNS servers DNS servers DNS servers Distributed, Hierarchical Database Client wants IP address for : (**)  Client’s NS queries a root server to find com DNS server’s addr. (by sending message to UDP port 53)  It then queries the com NS to get the NS for  It then queries the NS to get IP address for (*) The addresses of root servers are known to all name servers (**) One possible scenario

40 Application Layer 8-40 The DNS Database architecture: Authoritative NS’s, Zones, TLD’s r Root NS’s: hold addresses of all Top Level Domain NSs r Top-level domains : domains with single word name m generic TLD’s: com, org, net, edu, etc, e.g. Network Solutions maintains servers for com TLD m top-level country domains: uk, fr, ca, jp, il, etc. r Authoritative DNS server: organization’s DNS server, providing authoritative hostname-to-IP mappings for organization’s servers m It is responsible for a “zone” (or several zones) m Zone = Domain \ υ { subdomains that have their own zones } r Example: m zone includes all university servers except dep”ts that have their own zones (e.g. & )

41 Application Layer 8-41 DNS Name Resolution: Resolver and Local Name Server r Each host has a Resolver = a function that resides in the host and nows how to communicate with the DNS system r Each ISP (residential ISP, company, university) has a “Local name server” (it was called “Client’s NS” above) m Also called “default name server” r When application needs to translate a DNS name, it calls the resolver on its computer m thus, resolver acts as a kind of ‘proxy’ for the application r Resolver sends a DNS query to its local name server (LNS) m here again the LNS gives a proxy type service to the resolver r LNS finds the answer in its cache or by querying other name servers and sends answer to Resolver r Resolver supplies answer to the application

42 requesting host root DNS server local DNS server 1 2 3 4 5 6 authoritative DNS server 7 8 TLD DNS server DNS name resolution example r host at wants IP address for iterated query:  contacted server replies with name of server to contact  “I don’t know this name, please ask this server”  There are 2 iterated queries in the example Application 8-42

43 requesting host root DNS server local DNS server 1 2 4 5 6 authoritative DNS server 7 8 TLD DNS server 3 recursive query:  puts burden of name resolution on contacted name server  heavy load? Note: r actual scenario may involve a mix of the two modes. r root name servers are usually iterative  NS may act iteratively on one type of queries, recursively on another DNS name resolution example Application 8-43

44 Application Layer 8-44 DNS: caching and mirroring r once (any) name server learns mapping, it caches mapping m cache entries timeout (disappear) after some time (each response includes a TTL) m TLD servers typically cached in all local name servers Thus root name servers less often visited r Usually zone database is duplicated on several authoritative name servers (mirroring) m the main one is updated: administrator downloads a file m the others copy the zone from the main one m main NS notifies them when update available

45 Application Layer 8-45 DNS records DNS: distributed db storing resource records (RR) r Type=NS  name is domain (e.g.  value is IP address of authoritative name server for this domain RR format: (name, value, type, ttl) r Type=A  name is hostname  value is IP address r Type=CNAME  name is alias name of server  value is the canonical (“real”) name of that server e.g., has real name: r Type=MX m name is domain, e.g. m value is hostname of mail server

46 DNS protocol, messages DNS protocol : query and reply messages, both with same message format msg header  identification: 16 bit query # ; reply to query uses same #  flags:  query or reply  recursion desired  recursion available  reply is authoritative Application 8-46

47 DNS protocol, messages Name, type fields for a query RRs in response to query records for authoritative servers additional “helpful” info that may be used Application 8-47

48 Inserting records into DNS r example: new domain (startup) “Network Utopia” r register name at DNS registrar (e.g., Network Solutions) m provide names, IP addresses of authoritative name servers (primary and secondary) of this domain m registrar inserts two RRs into com TLD server: (,, NS) (,, A) (,, NS) (,, A) (,, MX) (,, CNAME) etc. r What does each of these RRs define? r What RRs are missing? Application 8-48

49 #49 Peer to Peer Applications Application Layer

50 Pure P2P architecture r no always-on server r arbitrary end systems directly communicate r peers are intermittently connected and change IP addresses r No background server to initialize the system r Pure P2P appl. are rare. we discuss three topics: m file distribution m searching for information m case Study: Skype peer-peer Application 8-50

51 File Distribution: Server-Client vs P2P Question : How much time it takes to distribute file from one server to N peers? usus u2u2 d1d1 d2d2 u1u1 uNuN dNdN Server Network (with abundant bandwidth) File, size F u s : server upload bandwidth u i : peer i upload bandwidth d i : peer i download bandwidth Application 8-51 upload : sending to Network download : receiving from Network

52 = d cs ≥ max { NF/u s +F/max(d i ), F/u s +F/min(d i ) } Time to distribute F to N clients by client/server i File distribution time: server-client usus u2u2 d1d1 d2d2 u1u1 uNuN dNdN Server Network (with abundant bandwidth) F r server sequentially sends N copies: m NF/u s time r client i takes F/d i time to download increases linearly in N (for large N) Application 8-52 equal under best server scheduling arrangement i

53 File distribution time: P2P usus u2u2 d1d1 d2d2 u1u1 uNuN dNdN Server Network (with abundant bandwidth) F r server must send one copy: F/u s time r client i takes F/d i time to download r NF bits must be downloaded (aggregate)  fastest possible upload rate: u s +  u i d P2P ≥ max { F/u s, F/min(d i ), NF/(u s +  u i ) } i i=1 Application 8-53 N independent of N if the u i are all of same order of magnitude equal under best data distribution arrangement

54 Server-client vs. P2P: example Client upload rate = u, F/u = 1 hour, u s = 10u, d min ≥ u s Application 8-54

55 File distribution: BitTorrent tracker: tracks peers participating in torrent torrent: group of peers exchanging chunks of a file obtain list of peers trading chunks peer P2P file distribution Application 8-55

56 BitTorrent (1) r file divided into 256KB chunks. r peer joining torrent: m has no chunks, but will accumulate them over time m registers with tracker to get list of peers, connects to a chosen subset of peers (“neighbors”) r while downloading, peer uploads chunks to other peers. r peers may come and go r once peer has entire file, it may (selfishly) leave (“leech”) or (cooperatively) remain (“seed”) Application 8-56

57 BitTorrent (2) Pulling Chunks r at any given time, different peers have different subsets of file chunks r periodically, a peer (Alice) asks each neighbor for list of chunks that they have. r then sends requests for her missing chunks m rarest first Sending Chunks: tit-for-tat  Alice sends chunks to four neighbors currently sending to her chunks at the highest rate  Alice re-evaluates her “top 4” list every 10 sec  each 30 sec she randomly selects another peer, starts sending chunks  “optimistically unchoke”  he may be better than current neighbors  newly chosen peer may join top 4, if sends fast to her Application 8-57

58 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 “optimistic unchoke” procedure helps find better trading partners & get file faster! Application 8-58

59 Distributed Hash Table (DHT) r DHT: distributed P2P database r database has (key, value) pairs; e.g: m key: Soc.Security number; value: human name m key: content title; value: IP address r peers query DB with key m DB returns values that match the key r peers can also insert (key, value) pairs Application 8-59

60 DHT Identifiers r assign to each peer an integer identifier in range [0,2 n -1]. m Each identifier can be represented by n bits. r require each key to also be an integer in [0,2 n -1]. r since original key may be a string, we build an integer key by applying an n-bit hash function h to the original key. m e.g., key = h(“Led Zeppelin IV”) = 231567935 m this is why they call it a distributed “hash” table Application 8-60

61 How to assign keys to peers? r central issue: m assigning (key, value) pairs to peers that will store them. r rule: assign key to the peer that has the closest ID. r convention in our presentation: “closest” is the closest from above or equal. r e.g.,: n=4; peers: 1,3,4,5,8,10,12,15; m key = 13, then successor peer = 15 m key = 17, then successor peer = 1 o the numbers are arranged in a ring (cyclic order) Application 8-61

62 1 3 4 5 8 10 12 15 Circular DHT (1) r each peer only aware of immediate successor and predecessor and communicates only with them. r this forms the “overlay network” Application 8-62

63 Circular DHT (2) 0001 0011 0100 0101 1000 1010 1100 1111 Who’s resp for key 1110 ? I am O(N) messages on avg required to resolve query in overlay network, when there are N peers 1110 Application 8-63

64 Circular DHT with Shortcuts r each peer keeps track of IP addresses of predecessor, successor and shortcuts (call all of them “neighbors”). r reduced from 6 to 2 messages. r possible to design shortcuts so O(log N) neighbors and O(log N) messages per query 1 3 4 5 8 10 12 15 Who’s resp for key 1110? Application 8-64

65 Peer Churn r Example: peer 5 abruptly leaves r Peer 4 detects; makes 8 its immediate successor; asks 8 who its immediate successor is; makes 8’s immediate successor (10) its second successor. How? r Who else needs to update its neighbor list? r What happens with the database info held by peer 5? r What if peer 13 wants to join? 1 3 4 5 8 10 12 15  To handle peer churn, require each peer to know the IP address of its two successors.  Each peer periodically pings its two successors to see if they are still alive. Application 8-65

66 P2P Case study: Skype r inherently P2P: pairs of users communicate. r proprietary application- layer protocol (inferred via reverse engineering) r hierarchical overlay with Supernodes (SNs) r Index maps usernames to IP addresses; distributed over SNs Skype clients (SC) Supernode (SN) Skype login server Application 8-66 r Note: SNs are hosts with non-NAT addresses, so any host can contact them

67 Peers as relays r problem when both Alice and Bob are behind “NATs”. m NAT prevents an outside peer from initiating a call to insider peer r solution: m using Alice’s and Bob’s SNs, relay host is chosen m each peer initiates a TCP session with relay. m peers can now transfer their realtime data through NATs via relay m Note: relay is another Skype user Application 8-67

68 EXTRA SLIDES 68 Application Layer

69 8-69 Nonpersistent HTTP Suppose user enters URL of a page : 1a. HTTP client initiates TCP connection to HTTP server (process) at 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 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 (page contains text and references to 10 jpeg images) Client Server time

70 Application Layer 8-70 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. after sending the object, HTTP server closes TCP connection. time

71 request file RTT time Application Layer 8-71 Response time modeling Definition of RTT: time to send a small packet to travel from client to server and back. Response time: r one RTT to initiate TCP connection r one RTT for HTTP request and first few bytes of HTTP response to return r file transmission time total = 2 RTT + transmit time initiate TCP connection RTT file received time to transmit file

72 Application Layer 8-72 Persistent HTTP Nonpersistent HTTP issues: r 2 RTT overhead per object Extra Delay r OS must work and allocate host resources for each TCP connection r browsers often open parallel TCP connections to fetch referenced objects Persistent HTTP r server leaves connection open after sending response r subsequent HTTP messages between same client/server are sent over same connection Persistent without pipelining: r client issues new request only when previous response has been received r one RTT overhead for each referenced object r Qn: What time is saved? Persistent with pipelining: r default in HTTP/1.1 r client sends requests as soon as it encounters a referenced object r only one RTT for all the referenced objects r Qn: Can you see an advantage of NonPersistent?

73 Application Layer 8-73 FTP: the file transfer protocol (RFC 959) r transfer file to/from remote host m remote management of a file system r client/server model m client (user’s workstation) initiates the connection m server (file server) responds to client’s commands mainly files transfers to or from client r ftp Well Known Port for control traffic: 21 r ftp Well Known Port for data traffic : 20 file transfer FTP server FTP user interface FTP client local file system remote file system user at host

74 Application Layer 8-74 FTP: separate control, data connections r FTP client contacts FTP server by TCP at port 21, sets up control connection r client obtains authorization over control connection r client browses remote directory by sending commands over control connection. r before a file transfer, client asks server to open a data- connection to a client port N (from server port 20)  client sends command: RETR or STOR (see next slide) r After sending/receiving one file, data connection is closed FTP client FTP server TCP control connection, server port 21 TCP data connection, server port 20 r Server opens a second TCP data connection to transfer another file. r Control connection: “out of band” r FTP server maintains “state” throughout the session: current directory, authentication state

75 Application Layer 8-75 FTP commands, responses Sample commands: (sent as ASCII text over control channel)  USER username  PASS password  LIST - list the files in current directory  CWD – change working dir.  PORT N – set up data connect. to my port N  RETR - download a file from server to client  STOR - upload a file from client to server Sample return codes (status code and phrase: same as in HTTP) r 331 Username OK, password required r 125 data connection already open; transfer starting r 425 Can’t open data connection r 452 Error writing file r 226 File transfer OK, closing connection Note: in Windows FTP user writes  GET for RETR  PUT for STOR

76 אפקה תשע " א ס " א Applic ation Layer 8-76 Electronic Mail Four major components: r user agents r mail servers r SMTP protocol btw servers r POP3/ IMAP protocols to retrieve mail by user agent User Agent r a.k.a. “mail reader” r composing, editing, reading mail messages r e.g., Outlook, Eudora, elm, Netscape Messenger r sends outgoing messages to server r collects incoming messages from server user mailbox outgoing message queue mail server user agent user agent user agent mail server user agent user agent mail server user agent SMTP

77 אפקה תשע " א ס " א Applic ation Layer 8-77 Electronic Mail: mail servers Mail Servers r mailbox contains incoming messages for user r message queue of outgoing (to be sent) mail messages r SMTP protocol used between mail servers to send email messages m SMTP client: the sending mail server m SMTP server: the receiving mail server mail server user agent user agent user agent mail server user agent user agent mail server user agent SMTP Note: Some user agents use SMTP to send mail to their mail server

78 אפקה תשע " א ס " א Applic ation Layer 8-78 Electronic Mail: SMTP [RFC 821, 2821] r uses TCP to reliably transfer email messages from client to server m SMTP server port 25 (WKP) r direct transfer: sending-server to receiving-server r three phases of transfer m handshaking (greeting) m transfer of messages m closing connection r command/response interaction m commands: ASCII text m response: status code (number) and phrase r messages must be in 7-bit US-ASCII m both the SMTP handshake and the message itself

79 אפקה תשע " א ס " א Applic ation Layer 8-79 Scenario: Alice sends message to Bob 1) Alice uses UA (*) to compose message with “to” field: 2) Alice’s UA sends message to her mail server; message placed in message queue 3) Alice’s mail server (=SMTP client) opens TCP connection to 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 uses his user agent to retrieve message from mailbox and reads it * UA=User agent (e.g. Outlook) user agent mail server mail server user agent 1 2 3 4 5 6

80 אפקה תשע " א ס " א Application Layer 8-80 Sample SMTP interaction S: 220 C: HELO S: 250 Hello, pleased to meet you C: MAIL FROM: S: 250 Sender ok C: RCPT TO: S: 250 Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Do you like ketchup? Mail headers skipped here C: How about pickles? ( see a full mail example C:. on slide 73) S: 250 Message accepted for delivery C: QUIT S: 221 closing connection

81 אפקה תשע " א ס " א Applic ation Layer 8-81 SMTP: final words r SMTP uses persistent connections r SMTP requires message (header & body) to be in 7-bit ASCII  SMTP server uses CRLF.CRLF (single dot in a line) to signal end of message Comparison with HTTP: r HTTP: (mainly) PULL r SMTP: always PUSH r both have ASCII command/response interaction, status codes r HTTP: a page may contain pictures and other objects m each object in own message r SMTP: m originally only ASCII text m with MIME format, can include any type of objects m objects sent inside msg.

82 אפקה תשע " א ס " א Applic ation Layer 8-82 Original Email msg format [RFC 822] SMTP: protocol for transferring email msgs Original email msg FORMAT: RFC 822: standard for text message format: r header lines, e.g., m To: m From: m Subject: different from SMTP commands ! r body m the “message” text, ASCII characters only header body blank line

83 אפקה תשע " א ס " א Applic ation Layer 8-83 MIME format: multimedia extensions r MIME: Multimedia Mail Extension, RFC 2045, 2056 r additional lines in msg header declare MIME content type and encoding method, m this enables multimedia content From: To: Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data....................................base64 encoded data multimedia data type, subtype, parameters method used to encode data (*) MIME version encoded data (*) data always encoded into 7-bit ASCII

84 אפקה תשע " א ס " א Applic ation Layer 8-84 Mail access protocols r SMTP: mail delivery to receiver’s server – PUSH r Mail access protocols: retrieval from server to agent – PULL m they require authentication of agent by server m POP: Post Office Protocol [RFC 1939] download all messages and keep at your workstation m IMAP: Internet Mail Access Protocol [RFC 1730] enables organizing mail folders on server you can read mail conveniently from any workstation r HTTP: (e.g. gmail) - display tool for agent located at the server user agent sender’s mail server user agent SMTP access protocol receiver’s mail server

85 אפקה תשע " א ס " א Applic ation Layer 8-85 POP3 protocol authorization phase r client commands:  user: declare username  pass: password r server responses m +OK  -ERR transaction phase, client:  list: list message numbers  retr: retrieve message by number  dele: delete r quit C: list S: 1 498 S: 2 912 S:. C: retr 1 S: S:. C: dele 1 C: retr 2 S: S:. C: dele 2 C: quit S: +OK POP3 server signing off S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on

86 אפקה תשע " א ס " א Applic ation Layer 8-86 POP3 (more) and IMAP More about POP3 r Previous example uses “download and delete” mode. r Bob cannot re-read e- mail if he changes client r “Download-and-keep”: can get messages on different clients r POP3 is stateless across sessions IMAP r Keep all messages in one place: the server r Allows user to organize messages in folders r IMAP keeps user state across sessions: m names of folders and mappings between message IDs and folder name

Download ppt "Chapter 8 Application Layer based on: Computer Networking: A Top Down Approach, 5 th edition. Jim Kurose, Keith Ross Addison-Wesley, April 2009. A note."

Similar presentations

Ads by Google