Chapter_2 App-layer.ppt

Chapter 2 Application Layer Computer Networking: A Top Down Approach 7th edition Jim Kurose, Keith Ross Pearson/Addison Wesley April 2016 Application Layer 2-1 Chapter 2: o...

Chapter 2 Application Layer Computer Networking: A Top Down Approach 7th edition Jim Kurose, Keith Ross Pearson/Addison Wesley April 2016 Application Layer 2-1 Chapter 2: outline 2.1 principles of network applications 2.2 Web and HTTP 2.3 electronic mail SMTP, POP3, IMAP 2.4 DNS Application Layer 2-2 Some network apps  e-mail  voice over IP (e.g.,  web Skype)  text messaging  real-time video  conferencing remote login   social networking P2P file sharing  search  multi-user network games  …  streaming stored  … video (YouTube, Hulu, Netflix) Application Layer 2-3 Creating a network app application transport network data link physical 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 application transport for network-core network data link application transport devices physical network data link  network-core devices do not physical run user applications  applications on end systems allows for rapid app development, propagation Application Layer 2-4 Application architectures possible structure of applications:  client-server  peer-to-peer (P2P) Application Layer 2-5  Client-server architecture server:  always-on host  permanent IP address  data centers for scaling clients:  communicate with server  may be intermittently client/server connected  may have dynamic IP addresses  do not communicate directly with each other Application Layer 2-6 P2P architecture  no always-on server peer-peer  arbitrary end systems directly communicate  peers request service from other peers, provide service in return to other peers self scalability – new peers bring new service capacity, as well as new service demands  peers are intermittently connected and change IP addresses complex management Application Layer 2-7 Processes communicating process: program clients, servers running within a client process: host process that initiates  within same host, two communication processes server process: communicate using process that waits to inter-process be contacted communication (defined by OS)  aside: applications  processes in different with P2P architectures hosts communicate have client processes by exchanging & server processes messages Application Layer 2-8 Sockets  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 to deliver message to socket at receiving process application application socket controlled by process process app developer transport transport network network controlled by OS link Internet link physical physical Application Layer 2-9 Addressing processes  to receive messages,  example port numbers: process must have HTTP server: 80 identifier mail server: 25  host device has  to send HTTP message unique 32-bit IP to gaia.cs.umass.edu address web server:  identifier includes IP address: both IP address and 128.119.245.12 port numbers port number: 80 associated with process on host. Application Layer 2-10 App-layer protocol defines  types of messages open protocols: exchanged,  defined in RFCs e.g., request,  e.g., HTTP, SMTP response  message syntax: what fields in proprietary protocols: messages & how  e.g., Skype fields are delineated  message semantics meaning of information in fields  rules for when and how processes send & respond to messages Application Layer 2-11 What transport service does an app need? data integrity throughput  some apps (e.g., file  some apps (e.g., transfer, web transactions) multimedia) require require 100% reliable data minimum amount of throughput to be transfer “effective”  other apps (e.g., audio)  other apps (“elastic apps can tolerate some loss ”) make use of whatever timing throughput they get  some apps (e.g., Internet telephony, security interactive games)  encryption, data require low delay to integrity, … be “effective” Application Layer 2-12  Transport service requirements: common apps application data loss throughput time sensitive file transfer no loss elastic no e-mail no loss elastic no Web documents no loss elastic no real-time audio/video loss-tolerant audio: 5kbps-1Mbps yes, 100’s msec video:10kbps-5Mbps stored audio/video loss-tolerant same as above yes, few secs interactive games loss-tolerant few kbps up yes, 100’s msec text messaging no loss elastic yes and no Application Layer 2-13 Internet transport protocols services TCP service: UDP service:  reliable transport between  unreliable data sending and receiving transfer between process sending and  flow control: sender won’t receiving process overwhelm receiver  does not provide:  congestion control: reliability, flow throttle sender when control, congestion network overloaded control, timing,  does not provide: timing, throughput minimum throughput guarantee, security, guarantee, security or connection setup,  connection-oriented: setup required between Q: Why is there a client and server UDP? processes Application Layer 2-14 Internet apps: application, transport protocols application underlying application layer protocol transport protocol e-mail SMTP [RFC 2821] TCP remote terminal access Telnet [RFC 854] TCP Web HTTP [RFC 2616] TCP file transfer FTP [RFC 959] TCP streaming multimedia HTTP (e.g., YouTube), TCP or UDP RTP [RFC 1889] Internet telephony SIP, RTP, proprietary (e.g., Skype) TCP or UDP Application Layer 2-15 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, www.someschool.edu/someDept/pic.gif e.g., host name path name Application Layer 2-16 HTTP overview HTTP: hypertext transfer protocol  Web’s application layer HT TP req protocol PC running ues t HT  client/server model Firefox browser TPr esp client: browser that ons e requests, receives, (using HTTP u es t protocol) and req server T P n se “displays” Web HT s po running objects re Apache Web T TP server: Web server H server sends (using HTTP protocol) objects in iPhone running response to requests Safari browser Application Layer 2-17 HTTP overview (continued) uses TCP: HTTP is “stateless”  client initiates TCP  server maintains connection (creates no information socket) to server, port about past client 80 requests  server accepts TCP connection from client  HTTP messages (application-layer protocol messages) exchanged between browser (HTTP client) and Web server (HTTP server)  TCP connection closed Application Layer 2-18 HTTP connections non-persistent HTTP persistent HTTP  at most one  multiple objects object sent over can be sent over TCP connection single TCP connection then connection closed between client,  downloading server multiple objects required multiple connections Application Layer 2-19  Non-persistent HTTP suppose user enters URL: (contains text, www.someSchool.edu/someDepartment/home.index references to 10 jpeg images) 1a. HTTP client initiates TCP connection to HTTP server (process) at 1b. HTTP server at host www.someSchool.edu on www.someSchool.edu port 80 waiting for TCP connection at port 80. “accepts” connection, notifying client 2. HTTP client sends HTTP request message (containing URL) into TCP connection socket. Message indicates that client wants object 3. HTTP server receives someDepartment/home.index request message, forms response message containing requested object, and sends message into its socket time Application Layer 2-20  Non-persistent HTTP (cont.) 4. HTTP server closes TCP connection. 5. HTTP client receives response message containing html file, displays html. Parsing html file, finds 10 referenced jpeg objects time 6. Steps 1-5 repeated for each of 10 jpeg objects Application Layer 2-21 Non-persistent HTTP: response time RTT (definition): time for a small packet to travel from client to server and back HTTP response time: initiate TCP connection  one RTT to initiate TCP RTT connection  one RTT for HTTP request request file and first few bytes of time to RTT HTTP response to return transmit file  file transmission time file  non-persistent HTTP received response time = 2RTT+ file transmission time time time Application Layer 2-22 Persistent HTTP non-persistent HTTP persistent HTTP: issues:  server leaves  requires 2 RTTs per connection open after sending object response  OS overhead for each  subsequent HTTP TCP connection messages between  browsers often open same client/server parallel TCP sent over open connections to fetch connection referenced objects  client sends requests as soon as it encounters a referenced object Application Layer 2-23  HTTP request message  two types of HTTP messages: request, response  HTTP request message: ASCII (human-readable format) carriage return character line-feed character request line (GET, POST, GET /index.html HTTP/1.1\r\n HEAD commands) Host: www-net.cs.umass.edu\r\n User-Agent: Firefox/3.6.10\r\n Accept: text/html,application/xhtml+xml\r\n headerAccept-Language: en-us,en;q=0.5\r\n linesAccept-Encoding: gzip,deflate\r\n carriage return, Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n line feed at start Keep-Alive: 115\r\n Connection: keep-alive\r\n of line indicates \r\n end of header lines * Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ Application Layer 2-24 HTTP request message: general format method sp URL sp version cr lf request line header field name value cr lf header ~ ~ ~ ~ lines header field name value cr lf cr lf ~ ~ entity body ~ ~ body Application Layer 2-25 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 Application Layer 2-26 Method types HTTP/1.0: HTTP/1.1:  GET  GET, POST, HEAD  POST  PUT  HEAD uploads file in asks server to entity body to leave requested path specified in object out of URL field response  DELETE deletes file specified in the URL field Application Layer 2-27  HTTP response message status line (protocol status code HTTP/1.1 200 OK\r\n status phrase) 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 header ETag: "17dc6-a5c-bf716880"\r\n Accept-Ranges: bytes\r\n lines Content-Length: 2652\r\n Keep-Alive: timeout=10, max=100\r\n Connection: Keep-Alive\r\n Content-Type: text/html; charset=ISO-8859-1\ r\n data, e.g., \r\n requested data data data data data... HTML file * Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ Application Layer 2-28 HTTP response status codes  status code appears in 1st line in server-to-client 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 server 404 Not Found requested document not found on this server 505 HTTP Version Not Supported Application Layer 2-29  Trying out HTTP (client side) for yourself 1. Telnet to your favorite Web server: telnet gaia.cs.umass.edu 80 opens TCP connection to port 80 (default HTTP server port) at gaia.cs.umass. edu. anything typed in will be sent to port 80 at gaia.cs.umass.edu 2. type in a GET HTTP request: GET /kurose_ross/interactive/index.php HTTP/1.1 Host: gaia.cs.umass.edu 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! or use Wireshark to look at captured HTTP request/response) Application Layer 2-30 User-server state: cookies example: many Web sites use cookies  Susan always access Internet from PC four components:  visits specific e- 1) cookie header line of HTTP response commerce site for first message time 2) cookie header line in  when initial HTTP next HTTP request requests arrives at message site, site creates: 3) cookie file kept on unique ID user’s host, entry in backend managed by user’s database for ID browser 4) back-end database at Web site Application Layer 2-31  Cookies: keeping “state” (cont.) client server ebay 8734 usual http request msg Amazon server cookie file creates ID usual http response 1678 for user create backend ebay 8734 set-cookie: 1678 entry database amazon 1678 usual http request msg cookie: 1678 cookie- access specific usual http response msg action one week later: access ebay 8734 usual http request msg amazon 1678 cookie: 1678 cookie- specific usual http response msg action Application Layer 2-32 Cookies (continued) aside what cookies can cookies and privacy: be used for:  cookies permit sites  authorization to learn a lot about  shopping carts you  recommendations  you may supply name  user session state and e-mail to sites (Web e-mail) how to keep “state”:  protocol endpoints: maintain state at sender/receiver over multiple transactions  cookies: http messages carry state Application Layer 2-33 Web caches (proxy server) goal: satisfy client request without involving origin server  user sets browser: Web accesses via cache  browser sends all proxy HTTP requests to HT TP est cache req server req u HT ues P se object in cache: client TP t H TT po n res res origin pon P cache returns se HT T server object ues t else cache P req ns e TT po requests object H res from origin server, T TP H then returns object to client client origin server Application Layer 2-34 More about Web caching  cache acts as why Web caching? both client and  reduce response time server for client request server for original  reduce traffic on an requesting client institution’s access client to origin server link  typically cache is  Internet dense with installed by ISP caches: enables “poor” content (university, providers to company, effectively deliver residential ISP) content (so too does P2P file sharing) Application Layer 2-35 Caching example: assumptions:  avg object size: 100K bits origin  avg request rate from servers browsers to origin public servers:15/sec Internet  avg data rate to browsers: 1.50 Mbps  RTT from institutional router 1.54 Mbps to any origin server: 2 sec access link  access link rate: 1.54 Mbps problem! institutional consequences: network 1 Gbps LAN  LAN utilization: 15%  access link utilization = 99%  total delay = Internet delay + access delay + LAN delay = 2 sec + minutes + usecs Application Layer 2-36  Caching example: fatter access link assumptions:  avg object size: 100K bits origin  avg request rate from servers browsers to origin public servers:15/sec Internet  avg data rate to browsers: 1.50 Mbps  RTT from institutional router 1.54 Mbps to any origin server: 2154 sec 154 Mbps access link Mbps  access link rate: 1.54 Mbps institutional consequences: 9.9% network 1 Gbps LAN  LAN utilization: 15%  access link utilization = 99%  total delay = Internet delay + access delaymsecs + LAN delay = 2 sec + minutes + usecs Cost: increased access link speed (not cheap!) Application Layer 2-37 Caching example: install local cache Calculating access link utilization, delay with cache: origin  suppose cache hit rate is 0.4 servers 40% requests satisfied at cache, public 60% requests satisfied at origin Internet  access link utilization:  60% of requests use access link  data rate to browsers over 1.54 Mbps access link access link = 0.6*1.50 Mbps =.9 Mbps institutional  network utilization = 0.9/1.54 =.58 1 Gbps LAN  total delay  = 0.6 * (delay from origin local web servers) +0.4 * (delay when cache satisfied at cache)  = 0.6 (2.01) + 0.4 (~msecs) = ~ 1.2 secs  less than with 154 Mbps link Application Layer 2-38 (and cheaper too!) Conditional GET client server  Goal: don’t send object if cache has up- to-date cached version HTTP request msg no object transmission If-modified-since: object delay not lower link utilization modified HTTP response before  cache: specify date of HTTP/1.0 304 Not Modified cached copy in HTTP request If-modified-since:  server: response HTTP request msg If-modified-since: object contains no object if modified cached copy is up-to- after HTTP response date: HTTP/1.0 200 OK HTTP/1.0 304 Not Modified Application Layer 2-39 Electronic mail outgoing message queue user mailbox Three major user components: agent  user agents  mail servers mail user server agent  simple mail transfer protocol: SMTP SMTP mail user server agent User Agent SMTP  a.k.a. “mail reader”  composing, editing, SMTP user reading mail messages mail agent  e.g., Outlook, server Thunderbird, iPhone mail user client agent  outgoing, incoming user messages stored on agent server Application Layer 2-40 Electronic mail: mail servers mail servers: user agent  mailbox contains incoming messages for mail user user server agent  message queue of SMTP mail user outgoing (to be sent) server agent mail messages  SMTP protocol between SMTP mail servers to send email messages SMTP user agent mail client: sending mail server server user agent “server”: receiving mail server user agent Application Layer 2-41 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 (like HTTP) commands: ASCII text response: status code and phrase  messages must be in 7-bit ASCI Application Layer 2-42 Scenario: Alice sends message to Bob 1) Alice uses UA to 4) SMTP client sends compose message “to” Alice’s message over [email protected] the TCP connection 2) Alice’s UA sends 5) Bob’s mail server message to her mail places the message in server; message Bob’s mailbox placed in message queue 6) Bob invokes his user 3) client side of SMTP agent to read message opens TCP connection with Bob’s mail server 1 user mail user mail agent agent server server 2 3 6 4 5 Alice’s mail server Bob’s mail server Application Layer 2-43 Sample SMTP interaction S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: S: 250 [email protected]... Sender ok C: RCPT TO: S: 250 [email protected]... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Do you like ketchup? C: How about pickles? C:. S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection Application Layer 2-44 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) Application Layer 2-45 SMTP: final words  SMTP uses persistent comparison with connections HTTP:  SMTP requires  HTTP: pull message (header &  SMTP: push body) to be in 7-bit  both have ASCII ASCII command/response  SMTP server uses interaction, status \r\n. \r\n to determine codes end of message  HTTP: each object encapsulated in its own response message  SMTP: multiple objects sent in multipart message Application Layer 2-46 Mail message format SMTP: protocol for exchanging email header messages blank line RFC 822: standard for text message format:  header lines, e.g., To: body From: Subject: different from SMTP MAIL FROM, RCPT TO: commands!  Body: the “message” ASCII characters only Application Layer 2-47 Mail access protocols user mail user SMTP SMTP access agent agent protocol (e.g., POP, IMAP) sender’s mail receiver’s mail server server  SMTP: delivery/storage to receiver’s server  mail access protocol: retrieval from server POP: Post Office Protocol [RFC 1939]: authorization, download IMAP: Internet Mail Access Protocol [RFC 1730]: more features, including manipulation of stored messages on server HTTP: gmail, Hotmail, Yahoo! Mail, etc. Application Layer 2-48 POP3 protocol S: +OK POP3 server ready C: user bob authorization phase S: +OK  client commands: C: pass hungry user: declare username S: +OK user successfully logged on pass: password C: list  server responses S: 1 498 +OK S: 2 912 -ERR S:. C: retr 1 transaction phase, S: client: S:.  list: list message numbers C: dele 1  retr: retrieve message by C: retr 2 number S:  dele: delete S:.  quit C: dele 2 C: quit S: +OK POP3 server signing off Application Layer 2-49 POP3 (more) and IMAP more about POP3 IMAP  previous example  keeps all messages in uses POP3 “download one place: at server and delete” mode  allows user to Bob cannot re-read organize messages in e-mail if he folders changes client  keeps user state  POP3 “download-and- across sessions: keep”: copies of names of folders messages on different and mappings clients between message  POP3 is stateless IDs and folder across sessions name Application Layer 2-50 DNS: domain name system people: many Domain Name System: identifiers:  distributed database SSN, name, passport # implemented in Internet hosts, routers: hierarchy of many name IP address (32 bit) - servers used for  application-layer addressing protocol: hosts, name datagrams servers communicate to “name”, e.g., resolve names www.yahoo.com - (address/name used by humans translation). Q: how to map between IP address and name, and vice versa ? Application Layer 2-51 DNS: services, structure DNS services why not centralize  hostname to IP DNS?  single point of failure address translation  traffic volume  host aliasing  distant centralized canonical, alias names database  mail server aliasing  maintenance  load distribution replicated Web servers: many IP addresses correspond to one name Application Layer 2-52 DNS: a distributed, hierarchical database Root DNS Servers … … com DNS servers org DNS servers edu DNS servers pbs.org poly.edu umass.edu yahoo.com amazon.com DNS servers DNS serversDNS servers DNS servers DNS servers client wants IP for www.amazon.com; 1 st approximation:  client queries 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 Application Layer 2-53  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 c. Cogent, Herndon, to local VA (5 other sites) name server d. U Maryland College Park, MDk. RIPE London (17 other sites) h. ARL Aberdeen, MD j. Verisign, Dulles VA (69 other sites ) i. Netnod, Stockholm (37 other sites) m. WIDE Tokyo e. NASA Mt View, CA (5 other sites) f. Internet Software C. Palo Alto, CA (and 48 other sites) 13 logical root name a. Verisign, Los Angeles CA “servers” worldwide (5 other sites) b. USC-ISI Marina del Rey, CA each “server” replicated many l. ICANN Los Angeles, CA times (41 other sites) g. US DoD Columbus, OH (5 other sites) Application Layer 2-54 TLD, authoritative servers top-level domain (TLD) servers: responsible for com, org, net, edu, aero, jobs, museums, and all top-level country domains, e.g.: uk, fr, ca, jp Network Solutions maintains servers for.com TLD Educause for.edu TLD authoritative DNS servers: organization’s own DNS server(s), providing authoritative hostname to IP mappings for organization’s named hosts can be maintained by organization or service provider Application Layer 2-55 Local DNS 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 has local cache of recent name-to-address translation pairs (but may be out of date!) acts as proxy, forwards query into hierarchy Application Layer 2-56 DNS name resolution root DNS server example 2  host at cis.poly.edu 3 TLD DNS server wants IP address 4 for gaia.cs.umass.edu 5 local DNS server iterated query: dns.poly.edu  contacted server 7 6 replies with name 1 8 of server to contact authoritative DNS server  “I don’t know this dns.cs.umass.edu requesting host name, but ask this cis.poly.edu server” gaia.cs.umass.edu Application Layer 2-57 DNS name root DNS server resolution example 2 3 recursive query: 7 6  puts burden of name TLD DNS resolution on server contacted name server local DNS server  heavy load at upper dns.poly.edu 5 4 levels of hierarchy? 1 8 authoritative DNS server dns.cs.umass.edu requesting host cis.poly.edu gaia.cs.umass.edu Application Layer 2-58 DNS: caching, updating records  once (any) name server learns mapping, it caches mapping cache entries timeout (disappear) after some time (TTL) TLD servers typically cached in local name servers thus root name servers not often visited  cached entries may be out-of-date (best effort name-to-address translation!) if name host changes IP address, may not be known Internet-wide until all TTLs expire  update/notify mechanisms proposed IETF standard RFC 2136 Application Layer 2-59 DNS records DNS: distributed database storing resource records (RR) RR format: (name, value, type, ttl) type=A type=CNAME  name is hostname  name is alias name for some  value is IP address “canonical” (the real) name  www.ibm.com is really type=NS name is domain (e.g., servereast.backup2.ibm.com foo.com)  value is canonical name value is hostname of authoritative name server for this type=MX domain  value is name of mailserver associated with name Application Layer 2-60