14-740: Networks

1. 14-740: Networks Lecture 3 * application layer * Spring 2018 (Kesden) Based upon slides from Prof. Bill Nace, Fall 2017

2. One Addition to last class:The end-to-end argument in system design • I did a slight refactoring of the schedule and intended to move this to last lecture, but opened the wrong version of the slides • I’ve added it to last classes deck for topical cohesion • It is also in today’s deck • The reading is Saltzer84. See class schedule.

3. Network Reference Model • Application – Establish an idiom for communicating with a particular application • Transport – Establish endpoints useful to a programmer • Network – Given multiple inter-connected LANs, achieve cross-connectivity, • Link – Manage the channel to enable actual communication, i.e. establish a LAN • Physical – Establish a channel with connectivity and signaling

4. EnD-To-End Protocols Client Server

5. End-To-End Argument • “Functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level.” • Examples include, “Bit-error recovery, security using encryption, duplicate message suppression, recovery from system crashes, and delivery acknowledgment. “ • “Low-level mechanisms to support these functions are justified only as performance enhancements. “

6. Application Layer • We’ve reviewed the layered architecture, generally • Now we begin working through the details, top-down • Today: The Application Layer

7. The Application Layer • Many different application layers share different • instances of common transport layer protocols • The transport layer forms a convenient, abstracted communication channel • Recall: TCP is reliable, and session-oriented • Recall: UDP is unreliable datagram service without sessions • Recall: Sessions require resources to maintain state DNS (queries) HTTP SMTP VOIP TCPUDP IP Ethernet Wi-Fi Fiber Telephony

8. SetupOverhead (Session-Oriented) Client Server initiate transport connection • Client initiatestransport connection toserver • API: Createssocket • Server acceptsconnection • Application-layer protocol messages exchangedbetween browser and webserver • Transport connectionclosed accept connection request file sendfile file received; close connection closed

9. HTTP Overview HTTPRequest HTTPResponse • HTTP: hypertext transferprotocol • Web’s application layer protocol • Client / servermodel • Client: browser that requests, receives, renders webobject • Server: stores objects, sendsin response torequests • Many implementations in variousoperating systems communicate usingHTTP HTTPRequest Linux running Apache (webserver) HTTPResponse Mac runningSafari

10. Quick History of HTTP • HTTP 0.9, circa1990 • Original release, first described in W3 mailinglist • “HTTP as implemented in WWW”, by TimBerners-Lee • http://lists.w3.org/Archives/Public/www-talk/1992JanFeb/0000.html • HTTP 1.0, started1993 • RFCs for HTML and URI published the sameyear • Informational RFC-1945, 1996 • Not a standards document, merely commonusages • A number ofproblems • Cachingcontrol • TCP overhead for shortresponses

11. HTTP History, cont. • HTTP/1.1 • Backward compatibility big issue RFC 2068, proposed standard, 1997 • RFC 2616, draft standard, 1999 • Some web server products claimed complianceto HTTP 1.1 even before it became standard! • RFC 2616 had to be “backward compatible”with 2068 • Pressures from vendors, technologist,etc • This lecture focuses on HTTP/1.1

12. HTTP History, cont again • HTTP/2 approved May 2015 (RFC 7540) • Somewhat slow adoption rate • Changes how data istransferred • Avoid head-of-lineblocking • Compressheaders • Allow server push • Violates layered architectureprinciples

13. HTTP Messages • 2 types ofmessages • Requests from client to server,and • Responses from server toclient • RFCs use Backus-Naur Form (BNF) to formally specify formats (RFC5234) HTTP-message = Request |Response or

14. Request/Response • Both request and response consistof: Start line, followed by… • Zero or more headers, followed by... • An empty line, followed by... • Message body(optional) generic-message =start-line Zero or moretimes optional *( message-header CRLF ) CRLF [ message-body] start-line = Request-line |status-line

15. Request Format Request =Request-Line *((general-header |request-header |entity-header ) CRLF) CRLF [ message-body] Zero or more of general, request or entity headers followed by CRLF, followed by an optional messagebody

16. REQUEST FORMAT: Headers • Headers provide metadata aboutthe request orresponse • Dates/times • Application and/or Serverinformation • Cachingcontrol • 46 definedheaders • Host:Header is required on requests (Virtual Hosting)

17. Request Format: REQUEST LINE Request-Line = Method SP Request-URI SP HTTP-Version CRLF Method =“OPTIONS” |“GET” |“HEAD” |“POST” |“PUT” |“DELETE” You get the idea....

18. Example request Request-line (GET,POST,...commands) GET /images/logos.htmlHTTP/1.1 Host:www.cmu.edu User-agent: mozilla/5.0... Connection: close Accept-language: en-US ¶ ¶ (extra carriage return, linefeed) message-header(x4) CRLF: Carriage return,line feed 2nd CRLF indicates no message-body, thus end ofmessage Note: ASCII (human-readableformat)

19. Request MethoDS: GET • GET:Retrieve an object • “Conditional GET” if header includes • If-Modified-Since, If-Match,etc • “Partial GET” if header includesa Rangefield • Essential for restartable transferssuch as scrubbing and buffering a media stream

20. REQUEST METHOD: HEAD • HEAD: Retrieve metadata about an object (validity, modification time,etc) • Same as GET but MUST NOT return a messagebody

21. Request Methods: OPTIONS • OPTIONS: Request info about the capabilities of server (or a resource) without requesting theresource

22. Request methods: post • POST: Upload data toserver • E.g. posting a message to mailinglist, submitting a form,etc

23. Example Response start-line = Request-line |status-line Recall: Definedas: status-line = HTTP-version SP Status-Code SP Reason-PhraseCRLF Status code HTTP/1.1 200 OK Connection close Date: Wed, 01 Feb 2017 12:00:15 GMT Server: Apache/1.3.0(Unix) Last-Modified: Mon, 22 Jun 2016 ... Content-Length: 6821 Content-Type:text/html data data data data data... Headerlines data, e.g. requested HTML file

24. Status Code resultcode • In first line of response from server toclient 3-digit integer • 1xx: Informational – Request received, continuing process • 2xx: Success – Actionsuccessful • 3xx: Redirection – Further action needed tocomplete request • 4xx: Client Error – Request has bad syntax or cannot befulfilled • 5xx: Server Error – Server failed to fulfill a validrequest

25. Examples status codes • 200OK • request succeeded, requested object includedin this message • 301 Moved Permanently • requested object moved, new locationspecified later in this message(Location:) • 404 NotFound • requested document not found on thisserver • 505 HTTP Version NotSupported

26. Remember Doing this in 213/513/600? Telnet to your favorite webserver telnet www.google.com 80 Opens TCP connection to port80 (default HTTP server port) at www.google.com. Anything typed in getssent to port 80 atwww.google.com Type in a GET HTTPrequest: GET /index.html HTTP/1.1 <CR> By typing this in, yousend Host: www.google.com<CR> <CR> this minimal (but complete) GET request to HTTPserver Examine the response message

27. Google.com/index.html HTML file (index.html)describes layout,links,scripts,etc Includes a reference to the logo image file (logo.gif)

28. question Does the following request retrievethe logo file aswell? GET /index.html HTTP/1.1 <CR> Host: www.google.com<CR><CR>

29. Answer: nope • Each HTTP Request retrieves a single object permessage • An object (e.g. HTML file) can contain links to other objects (e.g. images,HTML files) • Client must send separate requestto retrieve each additionalobject • Note: HTTP/2 allows server to push thelogo file

30. Connection Management • HTTP uses TCP as its transportprotocol • TCP not optimized for short-lived connections typical of HTTPmessage exchange • Why not? What are the costs and/or symptoms? • Simple pages, which result inshort messages, are common • Same overhead per message

31. Non-Persistent HTTP Suppose user wantscmu.edu/index.html (1) Client initiates TCP connection to cmu.eduon port80 (3) Client sendsHTTP request message (containingURL /index.html) into connectionsocket (2) Web server at cmu.edu waiting for connectionon port 80 “accepts” connection, responds to sender (4) Server receives request message, fetches object, formats responsemessage, sends message into connection

32. Non-Persistent HTTP, CONTSuppose user wantscmu.edu/index.html (5) Server closesconnection (6) HTTP client receives responsemessage.Parses HTML file, discovering 10 referenced image files Repeat steps 1-6foreach of 10 imageobjects

33. Response time model Client Server initiate transport • RoundTripTime(RTT):timetosenda small packet from client to server and back • Calculation for HTTP response time • One RTT to initiate TCPconnection • One RTT for HTTP request and first byte of response • file transmissiontime • response time = 2RTT + transmittime RTT accept connection Requestfile RTT sendfile Transmit Time file received;close connection closed

34. Much Overhead • A separate transport connectionis established to fetch eachobject • Requires at least 2 RTTs perobject • High overhead in terms of packetsin thenetwork • Long user-perceivedlatency

35. Looking deeper: Consider TCP • Transport protocol (TCP) is optimized for large data transfers. • Recall conversation about congestion control and ramping up. • HTTP request for small objects never getspast initialphase • Connection closed before window size canbe increasedsignificantly • Available bandwidth never fullyused.

36. Parallel sessions • Browser opens several sessions in parallel, and downloads embedded images separately butsimultaneously • Early Netscape browser, circa1994 • Pros • User feels webpage is loadingfaster • Cons • Does not solve the TCP overhead and ramp-up problem • Impose considerable load on network – increases congestion • Server juggles more TCPconnections, and associated overhead • Actually reduces effectivethroughput

37. User Behavior: Aborted Requests • A page is not what we wanted (or we are just bored), so we click “Back”button • Similar to TV channelsurfing • If browser is using parallel connections,... • Already started to download allembedded objects! • Connections must beaborted • But, the cost of establishing them hasalready been paid, and thus iswasted

38. Persistent HTTP • Reuse existing transportconnection • Server leaves connection openafter sending response • Subsequent HTTP messages between same client/server sent over open connection • Pipelining at application protocollevel • HTTP/1.0: Requires Keep-alive header • HTTP/1.1: Persistent, unless Connection: keep-alive Connection: close

39. To Pipeline, or not to pipeline? Client Server initiate transport connection • Persistent withoutpipelining: • client issues new request only upon receipt of previous response • one RTT for each referenced object ... • plus one setup/closeoverhead accept connection request object sendobject object received; request nextobject sendobject

40. To Pipeline, or not to pipeline? Client Server initiate transport connection • Persistent withpipelining: • client issues new request as soon as it encounters a referencedobject • default inHTTP/1.1 • server sends objects inorder • as little as one RTT for all referenced objects accept connection requestobject requestobject requestobject sendobject receiveobject sendobject sendobject receiveobject receiveobject

41. Persistent HTTP Advantages • Reduce transport-layer connectioncosts Fewer setups andteardowns • Saves CPU time in routers andhosts • Savesmemory for transport state (buf, counts,...) • Reduce latency by avoiding multiple TCP slow-starts • Does opening handshake once to establishconnection • Ramps up (TCP slow-start) once to get to ideal sendingrate • Avoid bandwidth wastage and reduce overallcongestion • Fewer number of packetssent

42. Origin Server HTTPRequest Web Proxy Caching HTTPResponse Origin Server Request Proxy Server Client Response • Goals: • Satisfy client request without involving origin server • Reducelatency and bandwidthrequirements • Mechanism: • client sendsrequests tocache • cache responds if it has a copy,otherwise • uses HTTP to request a copy fromthe originserver

43. WEB CACHE Consistency • HTTP ensures correctness ofcaching • Eliminate need to send requests to originserver • Specifies cacheabilityof responses, e.g. CanI cache thisobject? • Specifies expiration mechanisms, e.g.When does this object becomestale? • Eliminate need to send full responses fromorigin server • Specifies validation mechanisms, e.g. Is this object fresh orstale?

44. Request-Response protocol vsWeb Cache Policies • Web cache policies are separate from protocol • Sample policyquestions: • If cache is full, which object toevict? • Should we replace a stale object thatis very popular with a fresh object that might not be requestedoften? • Etc?

45. Expiration model • Server-specifiedexpiration • UsesExpiresheaderormax-agedirectiveinCache-Controlheader • Recommended Heuristicexpiration • Server does not specify explicit expiration times: Up to the web cacheimplementation • Usage determines if fresh enough • Freshnesscalculation • Age and Expirationcalculations

46. Cache Server Validation Model HTTP requestmsg If-modified-since: <date> object not modified • If response is not fresh, needto validate withserver • don’t send object if cache still has up-to-date cachedversion • cache: specify date of cachedcopy in HTTPrequest • If-modified-since:<date> • HTTP/1.0 304 NotModified • server: response contains no object if cached copy is up-to-date: HTTPresponse HTTP/1.0 304 NotModified HTTP requestmsg If-m50odified-since: <date> object modified HTTPresponse HTTP/1.0 200OK <data>

47. Question • Is a web proxy (cache) better for performance than the browsercache?

48. ANSWER • Is a web proxy (cache) better for performance than the browsercache? • YES! Browser cache can only respond with an object if same browserrequested it previously, whereas... • Proxy cache responses from otherclients in thenetwork • AND • NO! Browser cache can be accessed without network (i.e. betterperformance)

49. Mission Accomplished?Can you…? • Describe the mission, scope, addressing mechanism and data types of the ApplicationLayer? • Explain the HTTP protocol, includingmessage format, interaction model and connection management • Calculate response time for an HTTP request over nonpersistent, parallel or persistent connections, including the pipelinedvariant • Describe how web proxies work to cache HTTP responses, including how they ensureconsistency